K8S简介及概念介绍

K8S简介及概念介绍

认识 Kubernetes

什么是Kubernetes

image-20250125184932012

​ 如图所见,k8s是一个船舵的logo,联想docker的logo:装满集装箱的船,预示着k8s是用来管理容器的。kubernetes简称k8s,因为k和s间隔着8个字符。Google 在 2014 年开源了 Kubernetes 项目。 Kubernetes 建立在 Google 大规模运行生产工作负载十几年经验的基础上, 结合了社区中最优秀的想法和实践。最初由谷歌开发,后贡献给云原生计算基金会(CNCF)进行维护和发展。

​ 一句话来说,k8s是一个开源的容器编排和管理平台。

​ 对标的产品有Docker Swarm、Apache Mesos

为什么需要Kubernetes

应用部署的三个阶段

传统部署:购买物理机,环境不隔离

虚拟化部署:通过虚拟机隔离不同的应用,资源隔离了,但是虚拟机过重占用资源过多

容器化部署:环境隔离,不像虚拟机那么重

image-20250125191219282

K8S的特点

  • 自动化部署
    • Kubernetes可以根据预定定义好的YAML配置文件,自动创建部署容器服务,在不同的环境一致地运行同一套代码
  • 弹性伸缩
    • 能够根据应用的负载情况(cpu使用率,内存使用率)自动调整应用实例的数量以满足业务使用需求,提高资源利用率
  • 服务发现和负载均衡
    • 服务发现
      • k8s为每个应用程序定义了一个稳定的网络地址,使得不同容器之间能通过这个地址或者域名来互相通信,无需手动配置ip和端口
    • 负载均衡
      • 将外部请求均匀地发到多个实力上,避免单点故障
  • 自我修复
    • 会持续检测容器运行状态,当容器崩溃或者不可用时,会自动重启,并且把请求流量调度到其他健康的节点上。
  • 存储编排
    • 支持多种存储系统(如 NFS、iSCSI、Ceph 等),可以为容器化应用动态地挂载和管理存储卷,确保数据的持久化和可访问性
  • 滚动更新与回滚
    • 滚动更新
      • 在更新应用程序时,Kubernetes 可以逐步替换旧版本的容器为新版本的容器,确保在更新过程中应用的正常运行,减少停机时间。比如容器实例是2,发布时容器实例会这样演变 2旧 -> 2旧1新(启动中) -> 1旧1新(已更新) -> 1旧1新(已更新)1新(启动中) -> 2新(已更新)
    • 版本回滚
      • 如果更新过程中出现问题,可以快速将应用程序回滚到上一个稳定版本,回滚过程与发布更新类型
  • 机密和配置管理
    • k8s提供了配置管理服务,并且支持对敏感数据加密

集群架构与组件

控制面板组件(Master)

  • kube-apiserver
    • API 服务器是 Kubernetes 控制平面的组件, 该组件负责公开了 Kubernetes API,负责处理接受请求的工作。 API 服务器是 Kubernetes 控制平面的前端。
  • kube-controller-manager
    • kube-controller-manager 是控制平面的组件, 负责运行控制器进程。
      • 节点控制器(Node Controller):负责在节点出现故障时进行通知和响应
      • 任务控制器(Job Controller):监测代表一次性任务的 Job 对象,然后创建 Pods 来运行这些任务直至完成
      • 端点分片控制器(EndpointSlice controller):填充端点分片(EndpointSlice)对象(以提供 Service 和 Pod 之间的链接)。
      • 服务账号控制器(ServiceAccount controller):为新的命名空间创建默认的服务账号(ServiceAccount)。
  • cloud-controller-manager
    • 嵌入了特定于云平台的控制逻辑。 云控制器管理器(Cloud Controller Manager)允许你将你的集群连接到云提供商的 API 之上, 并将与该云平台交互的组件同与你的集群交互的组件分离开来。
  • kube-scheduleer
    • scheduler 负责资源的调度,按照预定的调度策略将 Pod 调度到相应的机器上;
  • etcd
    • 一致且高度可用的键值存储,用作 Kubernetes 的所有集群数据的后台数据库。

节点组件

  • kubelet
    • kubelet 负责维护容器的生命周期,同时也负责 Volume(CVI)和网络(CNI)的管理;
  • kube-proxy
    • kube-proxy 负责为 Service 提供 cluster 内部的服务发现和负载均衡;
  • containner-runtime
    • Container runtime 负责镜像管理以及 Pod 和容器的真正运行(CRI);
    • Kubernetes 支持许多容器运行环境,例如 containerd、 CRI-O 以及 Kubernetes CRI (容器运行环境接口) 的其他任何实现。

附加组件

  • kube-dns
    • kube-dns 负责为整个集群提供 DNS 服务
  • Ingress Controller
    • Ingress Controller 为服务提供外网入口
  • Prometheus
    • Prometheus 提供资源监控
  • Dashboard
    • Dashboard 提供 GUI
  • Federation
    • Federation 提供跨可用区的集群
  • Fluentd-elasticsearch
    • Fluentd-elasticsearch 提供集群日志采集、存储与查询

image-20250125204106849

核心概念与专业术语

服务的分类

有状态

​ 服务存在状态,一般指服务需要存储数据,这种服务就是有状态的,比如redis,mysql这些。

优点:可以独立存储数据,实现数据管理

缺点:集群环境下需要实现主从、数据同步、备份、水平扩容复杂

无状态

​ nginx等,重启前后不影响服务的正常运行

优点:对客户端透明,无依赖关系,可以高效实现扩容、迁移

缺点:不能存储数据,需要额外的数据服务支撑

资源和对象

资源分类

image-20250206220209341

image-20250206221035336

元数据级

Horizontal Pod Autoscaler(HPA)

Pod 自动扩容缩容:可以根据 CPU 使用率或自定义指标(metrics)自动对 Pod 进行扩/缩容。
控制管理器每隔30s(可以通过–horizontal-pod-autoscaler-sync-period修改)查询metrics的资源使用情况
支持三种metrics类型
​ 预定义metrics(比如Pod的CPU)以利用率的方式计算
​ 自定义的Pod metrics,以原始值(raw value)的方式计算
​ 自定义的object metrics

支持两种metrics查询方式:Heapster和自定义的REST API,支持多metrics

PodTemplate

​ 顾名思义:pod创建的模版,是关于 Pod 的定义,但是被包含在其他的 Kubernetes 对象中(例如 Deployment、StatefulSet、DaemonSet 等控制器)。控制器通过 Pod Template 信息来创建 Pod

LimitRange

​ 可以对集群内 Request 和 Limits 的配置做一个全局的统一的限制,相当于批量设置了某一个范围内(某个命名空间)的 Pod 的资源使用限制

集群级

Namespace

1
2
Kubernetes 支持多个虚拟集群,它们底层依赖于同一个物理集群,这些虚拟集群被称为命名空间。
作用是用于实现多团队/环境的资源隔离。命名空间 namespace 是 k8s 集群级别的资源,可以给不同的用户、租户、环境或项目创建对应的命名空间。

默认 namespace:

  • kube-system 主要用于运行系统级资源,存放 k8s 自身的组件
  • kube-public 此命名空间是自动创建的,并且可供所有用户(包括未经过身份验证的用户)读取。此命名空间主要用于集群使用,关联的一些资源在集群中是可见的并且可以公开读取。此命名空间的公共方面知识一个约定,但不是非要这么要求。
  • default 未指定名称空间的资源就是 default,即你在创建pod 时如果没有指定 namespace,则会默认使用 default

Node:

ClusterRole

​ ClusterRole 是一组权限的集合,但与 Role 不同的是,ClusterRole 可以在包括所有 Namespace 和集群级别的资源或非资源类型进行鉴权。

ClusterRoleBinding

​ ClusterRoleBinding:将 Subject 绑定到 ClusterRole,ClusterRoleBinding 将使规则在所有命名空间中生效。

命名空间别

image-20250206221652637

工作负载型

Pod

​ pod大致分为副本(replicas)和控制器

​ Pod(容器组)是 Kubernetes 中最小的可部署单元。一个 Pod(容器组)包含了一个应用程序容器(某些情况下是多个容器)、存储资源、一个唯一的网络 IP 地址、以及一些确定容器该如何运行的选项。Pod 容器组代表了 Kubernetes 中一个独立的应用程序运行实例,该实例可能由单个容器或者几个紧耦合在一起的容器组成。

​ Docker 是 Kubernetes Pod 中使用最广泛的容器引擎;Kubernetes Pod 同时也支持其他类型的容器引擎。

Kubernetes 集群中的 Pod 存在如下两种使用途径:

  1. 一个 Pod 中只运行一个容器。”one-container-per-pod” 是 Kubernetes 中最常见的使用方式。此时,您可以认为 Pod 容器组是该容器的 wrapper,Kubernetes 通过 Pod 管理容器,而不是直接管理容器。
  2. 一个 Pod 中运行多个需要互相协作的容器。您可以将多个紧密耦合、共享资源且始终在一起运行的容器编排在同一个 Pod 中
副本

先引入“副本”的概念——一个 Pod 可以被复制成多份,每一份可被称之为一个“副本”,这些“副本”除了一些描述性的信息(Pod 的名字、uid 等)不一样以外,其它信息都是一样的,譬如 Pod 内部的容器、容器数量、容器里面运行的应用等的这些信息都是一样的,这些副本提供同样的功能。

Pod 的“控制器”通常包含一个名为 “replicas” 的属性。“replicas”属性则指定了特定 Pod 的副本的数量,当当前集群中该 Pod 的数量与该属性指定的值不一致时,k8s 会采取一些策略去使得当前状态满足配置的要求。

控制器

ReplicationController(RC):动态保证副本数
ReplicaSet(RS):打标签,支持selector
Deployment:Deployment 为 Pod 和 Replica Set 提供声明式更新。你只需要在 Deployment 中描述你想要的目标状态是什么,Deployment controller 就会帮你将 Pod 和 Replica Set 的实际状态改变到你的目标状态。你可以定义一个全新的 Deployment,也可以创建一个新的替换旧的 Deployment。

image-20250206222211431

StatefulSet:

1
2
3
4
5
StatefulSet 中每个 Pod 的 DNS 格式为 
statefulSetName-{0..N-1}.serviceName.namespace.svc.cluster.local
serviceName 为 Headless Service 的名字0..N-1 为 Pod 所在的序号,从 0 开始到 N-1
statefulSetName 为 StatefulSet 的名字namespace 为服务所在的 namespace,Headless Servic 和 StatefulSet 必须在相同的 namespace
.cluster.local 为 Cluster Domain

Daemonet:

1
2
3
4
DaemonSet 保证在每个 Node 上都运行一个容器副本,常用来部署一些集群的日志、监控或者其他系统管理应用。典型的应用包括:
日志收集,比如 fluentd,logstash 等
系统监控,比如 Prometheus Node Exporter,collectd,New Relic agent,Ganglia gmond 等
系统程序,比如 kube-proxy, kube-dns, glusterd, ceph 等

Job和CronJob:

1
2
Job:一次性任务,运行完成后Pod销毁,不再重新启动新容器。
CronJob:CronJob 是在 Job 基础上加上了定时功能。

image-20250206222946057

服务发现

Service
“Service” 简写 “svc”。Pod 不能直接提供给外网访问,而是应该使用 service。Service 就是把 Pod 暴露出来提供服务,Service 才是真正的“服务”,它的中文名就叫“服务”。

​ 可以说 Service 是一个应用服务的抽象,定义了 Pod 逻辑集合和访问这个 Pod 集合的策略。Service 代理 Pod 集合,对外表现为一个访问入口,访问该入口的请求将经过负载均衡,转发到后端 Pod 中的容器。

Ingress
Ingress 可以提供外网访问 Service 的能力。可以把某个请求地址映射、路由到特定的 service。

​ ingress 需要配合 ingress controller 一起使用才能发挥作用,ingress 只是相当于路由规则的集合而已,真正实现路由功能的,是 Ingress Controller,ingress controller 和其它 k8s 组件一样,也是在 Pod 中运行。

image-20250206224859211

存储

Volume

​ 数据卷,共享 Pod 中容器使用的数据。用来放持久化的数据,比如数据库数据。

CSI
Container Storage Interface 是由来自 Kubernetes、Mesos、Docker 等社区成员联合制定的一个行业标准接口规范,旨在将任意存储系统暴露给容器化应用程序。
CSI 规范定义了存储提供商实现 CSI 兼容的 Volume Plugin 的最小操作集和部署建议。CSI 规范的主要焦点是声明 Volume Plugin 必须实现的接口。

特殊类型配置

ConfigMap

​ 用来放配置,与 Secret 是类似的,只是 ConfigMap 放的是明文的数据,Secret 是密文存放。

Secret
1
2
3
4
5
Secret 解决了密码、token、密钥等敏感数据的配置问题,而不需要把这些敏感数据暴露到镜像或者 Pod Spec 中。Secret 可以以 Volume 或者环境变量的方式使用。
Secret 有三种类型:
Service Account:用来访问 Kubernetes API,由 Kubernetes 自动创建,并且会自动挂载到 Pod 的 /run/secrets/kubernetes.io/serviceaccount 目录中;
Opaque:base64 编码格式的 Secret,用来存储密码、密钥等;
kubernetes.io/dockerconfigjson:用来存储私有 docker registry 的认证信息。
DownwardAPI
1
2
3
4
downwardAPI 这个模式和其他模式不一样的地方在于它不是为了存放容器的数据也不是用来进行容器和宿主机的数据交换的,而是让 pod 里的容器能够直接获取到这个 pod 对象本身的一些信息。
downwardAPI 提供了两种方式用于将 pod 的信息注入到容器内部:
环境变量:用于单个变量,可以将 pod 信息和容器信息直接注入容器内部
volume 挂载:将 pod 信息生成为文件,直接挂载到容器内部中去

其他

Role:

​ Role 是一组权限的集合,例如 Role 可以包含列出 Pod 权限及列出 Deployment 权限,Role 用于给某个 Namespace 中的资源进行鉴权。

RoleBinding

​ RoleBinding将Subject 绑定到 Role,RoleBinding 使规则在命名空间内生效。

资源清单

对象规约和状态

规约(Spec)

状态(Status)

DevOps

image-20250330220009904

image-20250330220301196