Kubernetes系列：俯瞰Kubernetes全貌

type

status

date

slug

summary

1、Kubernetes简介

Kubernetes 是 Google 开源的一套微服务，容器化的编排引擎，提供容器化应用的自动化部署，横向扩展和管理，是 Google 内部容器十多年实战沉淀的结晶，已战胜 Swarm、Mesos 成为容器编排的行业标准。

容器编排引擎：
Docker-Compose：Docker 原生提供的容器编排工具，只需要一个配置文件即可管理多个容器的启动，但是只适用于单机环境。
Swarm：Docker 原生提供的容器化编排引擎，支持多节点的容器管理，弥补了 Docker-Compose 单节点的缺陷，随着 Docker 支持 Kubernetes 逐渐废弃。
Mesos：结合 Marathon 提供容器调度编排的能力，还能提供其他 framwork 的调度。
Kubernetes：已成为容器编排引擎的唯一标准，越来越多程序支持 Kubernetes。

Kubernetes 内置有很多非常优秀的特性使开发者专注于业务本身，其包含的功能如下：

Service discovery and load balancing，服务发现和负载均衡，通过DNS实现内部解析，service实现负载均衡

Storage orchestration，存储编排，通过 plugin 的形式支持多种存储，如本地，nfs，ceph，公有云快存储等

Automated rollouts and rollbacks，自动发布与回滚，通过匹配当前状态与目标状态一致，更新失败时可回滚

Automatic bin packing，自动资源调度，可以设置 pod 调度的所需（requests）资源和限制资源（limits）

Self-healing，内置的健康检查策略，自动发现和处理集群内的异常，更换，需重启的 pod 节点

Secret and configuration management，密钥和配置管理，敏感信息通过 secret 存储，应用的配置文件通过 configmap 存储，避免将配置文件固定在镜像中，增加容器编排的灵活性

Batch execution，批处理执行，通过 job 和 cronjob 提供单次批处理任务和循环计划任务功能的实现

Horizontal scaling，横向扩展功能，包含有 HPA 和AS，即应用的基于 CPU 利用率的弹性伸缩和基于平台级的弹性伸缩，如自动增加和删除 node 节点。

2、Kubernetes的核心概念

2.1 Node

k8s 中通过将容器放入到节点 Node 上运行的 Pod 中来执行工作负载。 k8s 中的计算能力就是由 node 提供。

节点可以是物理机也可以是虚拟机，取决于集群的配置，通常 k8s 集群中，有越多的 node 节点，意味着有更强的计算能力。

2.2 Namespace

命名空间为 Kubernetes 集群提供虚拟的隔离作用，Kubernetes 集群初始有两个命名空间，分别是默认命名空间 default 和系统命名空间 kube-system，除此以外，管理员可以可以创建新的命名空间满足需要。

名字空间适用于存在很多跨多个团队或项目的用户的场景。对于只有几到几十个用户的集群，根本不需要创建或考虑名字空间。

2.3 Pod

Pod 是 k8s 中集群部署应用和服务的最小单元，一个 pod 中可以部署多个容器。

Pod 的设计理念是支持多个容器在一个 Pod 中共享网络地址和文件系统，可以通过进程间通信和文件共享这种简单高效的方式组合完成服务。Pod 对多容器的支持是 K8 最基础的设计理念。

2.4 Replication Controller(RC)

RC 是 k8s 集群中最早的保证 Pod 高可用的 API 对象。它的作用就是保证集群中有指定数目的 pod 运行。

当前运行的 pod 数目少于指定的数目，RC 就会启动新的 pod 副本，保证运行 pod 数量等于指定数目。

当前运行的 pod 数目大于指定的数目，RC 就会杀死多余的 pod 副本。

2.5 Replica Set(RS)

RS 是新一代 RC，提供同样的高可用能力，区别主要在于 RS 后来居上，能支持更多种类的匹配模式。副本集对象一般不单独使用，而是作为 Deployment 的理想状态参数使用。

2.6 Deployment

Deployment 提供了一种对 Pod 和 ReplicaSet 的管理方式，每一个 Deployment 都对应集群中的一次部署，是非常常见的 Kubernetes 对象。

Deployment 是一个比 RS 应用模式更广的 API 对象，可以用来创建一个新的服务，更新一个新的服务，也可以用来滚动升级一个服务。

滚动升级一个服务，滚动升级一个服务，实际是创建一个新的 RS，然后逐渐将新 RS 中副本数增加到理想状态，将旧 RS 中的副本数减小到 0 的复合操作；这样一个复合操作用一个 RS 是不太好描述的，所以用一个更通用的 Deployment 来描述。

2.7 Service

RC、RS 和 Deployment 只是保证了支撑服务的微服务 Pod 的数量。但是没有解决如何访问这些服务的问题。

一个 Pod 只是一个运行服务的实例，随时可能在节点上停止，然后再新的节点上用一个新的 IP 启动一个新的 Pod，因此不能使用确定的 IP 和端口号提供服务。这对于业务来说，就不能根据 Pod 的 IP 作为业务调度。kubernetes 就引入了 Service 的概念，它为 Pod 提供一个入口，主要通过 Labels 标签来选择后端Pod，这时候不论后端 Pod 的 IP 地址如何变更，只要 Pod 的 Labels 标签没变，那么业务通过 Service 调度就不会存在问题。

同时 Service 对绑定的 Pod 提供了负载均衡的功能，我们业务直接使用 service 即可。

当声明 Service 的时候，会自动生成一个 Cluster IP，这个 IP 是虚拟 IP。我们就可以通过这个 IP 来访问后端的Pod，当然，如果集群配置了DNS服务，比如现在的 CoreDNS，那么也可以通过 Service 的名字来访问，它会通过 DNS 自动解析 Service 的 IP 地址。

2.8 Ingress

Ingress 为 Kubernetes 集群提供外部访问的能力，将 HTTP/HTTPS 请求转发到 Service 上，比如根据请求中不同的 Host 和 url 路径让请求落到不同的 Service 上。

Ingress Controller 就是一个反向代理程序，它负责解析 Ingress 的反向代理规则，如果 Ingress 有增删改的变动，所有的 Ingress Controller 都会及时更新自己相应的转发规则，当 Ingress Controller 收到请求后就会根据这些规则将请求转发到对应的 Service。

3、Kubernetes的整体架构

下图是一个完整可运行的 Kubernetes 集群的各种组件：

Kubernetes 由一个控制平面（Master 节点）和多个用于运行容器化应用的 Node（Worker 节点）组成。

Master 节点上运行着集群管理相关的一组进程（如 etcd、API Server、Controller Manager、Scheduler），这些进程实现了整个集群的资源管理、Pod 调度、弹性伸缩、安全控制、系统监控和纠错等管理功能，并且全都是自动完成。

Node 节点上运行 kubelet、kube-proxy、Container Runtime（例如 docker、containerd）等组件，负责对本节点上的 Pod 的生命周期进行管理以及实现服务代理的功能，用户应用运行在 Node 节点上。

用户通过 kubectl、dashboard 等工具与 Kubernetes 进行交互，向集群下达操作命令。

4、Kubernetes的核心概念和组件

4.1 控制平面组件

控制平面（Control Plane）负责控制和管理整个集群，作为整个 k8s 集群的大脑，部署在 Master 节点上。Master 节点可以部署一个或多个（提高可用性），包含一系列控制平面组件：

kube-apiserver：在整个集群的入口，暴露 Kubernetes API，接收集群所有的请求（如 kubectl 或 Dashboard 的请求）。

kube-controller-scheduler：集群资源调度，通过 watch 监视 pod 的创建，负责将 pod 调度到合适的 node 节点。

kube-controller-manager：运行多个控制器（Controller），确保集群状态符合预期。包含

Node Controller：监控节点状态（如节点不可用时驱逐 Pod）。
Replication Controller：确保副本数（如 Deployment 的 replicas）符合预期。
Endpoints Controller：维护 Service 与 Pod 的映射关系。
其他：如 Namespace、ServiceAccount 控制器等。

kube-scheduler：决定 Pod 应该运行在哪个节点上，调度策略基于资源需求（CPU/内存）、亲和性（Affinity）、污点（Taint）等。

etcd：分布式键值存储数据库，保存集群的所有配置数据和状态（如 Pod、Service、Namespace 等）。

cloud-controller-manager（可选）：用于公有云的接入实现，提供节点管理(node)、路由管理、服务管理(LoadBalancer和Ingress)、存储管理(Volume，如云盘，NAS接入)，需要由公有云厂商实现具体的细节。

4.2 Node组件

Node（Worker 节点）是实际的工作节点，负责集群负载的实际运行，即 Pod 运行的载体。每个 Node 都包含以下 Node 组件：

kubelet：运行在 Node 节点上的守护进程，它的主要职责是确保该节点上的 Pod 按照 API Server 指定的状态正确运行。kubelet 负责接收来自 API Server 的指令，创建、监控和管理 Pod 及其容器，还负责卷管理、健康检查、生命周期管理以及与容器运行时（比如 Docker）进行交互以执行具体容器操作。简而言之，kubelet 是 Kubernetes 集群在每个节点上的“管家”，确保集群的实际状态符合期望状态。

kube-proxy：Service 服务的抽象层，负责维护节点上的网络规则（如 iptables/IPVS），这些网络规则实现从集群内部或外部与 Pod 进行网络通信。

Container Runtime：容器运行时，负责管理容器的执行和生命周期，kubelet 通过 CRI（Container Runtime Interface）与容器运行时交互。容器运行时实现有 Docker、Containerd、CRI-O 以及 Kubernetes CRI 的其他任何实现。