前言

当用户熟练地掌握了容器技术，信心满满地要在服务器集群里大规模实施的时候，却会发现容器技术的创新只是解决了运维部署工作中一个很小的问题。现实生产环境的复杂程度实在是太高了，除了最基本的安装，还会有各式各样的需求，比如服务发现、负载均衡、状态监控、健康检查、扩容缩容、应用迁移、高可用等等……

什么是容器编排

什么是 Kubernetes

生产级别的容器编排系统

Kubernetes 也称为 K8s，是用于自动部署、扩缩和管理容器化应用程序的开源系统。 它将组成应用程序的容器组合成逻辑单元，以便于管理和服务发现。Kubernetes 源自Google 15 年生产环境的运维经验，同时凝聚了社区的最佳创意和实践。 星际尺度 Google 每周运行数十亿个容器，Kubernetes 基于与之相同的原则来设计，能够在不扩张运维团队的情况下进行规模扩展。 永不过时 无论是本地测试，还是跨国公司，Kubernetes 的灵活性都能让你在应对复杂系统时得心应手。 处处适用 Kubernetes 是开源系统，可以自由地部署在企业内部，私有云、混合云或公有云，让您轻松地做出合适的选择。 请访问下载部分下载 Kubernetes。 将 150+ 微服务迁移到 Kubernetes 上的挑战 Sarah Wells, 运营和可靠性技术总监, 金融时报 观看视频 参加 2024 年 3 月 19-22 日的欧洲 KubeCon + CloudNativeCon 参加 2024 年 11 月 12-15 日的北美 KubeCon + CloudNativeCon Kubernetes 特性 自动化上线和回滚 Kubernetes 会分步骤地将针对应用或其配置的更改上线，同时监视应用程序运行状况以确保你不会同时终止所有实例。如果出现问题，Kubernetes 会为你回滚所作更改。你应该充分利用不断成长的部署方案生态系统。 服务发现与负载均衡 你无需修改应用来使用陌生的服务发现机制。Kubernetes 为每个 Pod 提供了自己的 IP 地址并为一组 Pod 提供一个 DNS 名称，并且可以在它们之间实现负载均衡。 自我修复 重新启动失败的容器，在节点死亡时替换并重新调度容器， 杀死不响应用户定义的健康检查的容器， 并且在它们准备好服务之前不会将它们公布给客户端。 存储编排 自动挂载所选存储系统，包括本地存储、公有云提供商所提供的存储或者诸如 iSCSI 或 NFS 这类网络存储系统。 Secret 和配置管理 部署和更新 Secret 和应用程序的配置而不必重新构建容器镜像， 且不必将软件堆栈配置中的秘密信息暴露出来。 自动装箱 根据资源需求和其他限制自动放置容器，同时避免影响可用性。 将关键性的和尽力而为性质的工作负载进行混合放置，以提高资源利用率并节省更多资源。 批量执行 除了服务之外，Kubernetes 还可以管理你的批处理和 CI 工作负载，在期望时替换掉失效的容器。 IPv4/IPv6 双协议栈 为 Pod 和 Service 分配 IPv4 和 IPv6 地址 水平扩缩 使用一个简单的命令、一个 UI 或基于 CPU 使用情况自动对应用程序进行扩缩。 为扩展性设计 无需更改上游源码即可扩展你的 Kubernetes 集群。 案例分析 "

https://kubernetes.io/zh-cn/

Kubernetes 背后有 Borg 系统十多年生产环境经验的支持，技术底蕴深厚，理论水平也非常高，一经推出就引起了轰动。在 2015 年，Google 又联合 Linux 基金会成立了 CNCF（ Cloud Native Computing Foundation，云原生基金会），并把 Kubernetes 捐献出来作为种子项目。有了 Google 和 Linux 这两大家族的保驾护航，再加上宽容开放的社区，作为 CNCF 的“头把交椅”，Kubernetes 旗下很快就汇集了众多行业精英，仅用了两年的时间就打败了同期的竞争对手 Apache Mesos 和 Docker Swarm，成为了这个领域的唯一霸主。

云原生时代的操作系统

K8s 是一个生产级别的容器编排平台和集群管理系统，能够创建、调度容器，监控、管理服务器。

🤔

thinking…

容器是什么？

容器是软件，是应用，是进程。

服务器是什么？

服务器是硬件，是 CPU、内存、硬盘、网卡。

那么，既可以管理软件，也可以管理硬件，这样的东西应该是什么？

这就是一个操作系统（Operating System）！

可以把 Kubernetes 与 Linux 对比学习

从某种角度来看，Kubernetes 可以说是一个集群级别的操作系统，主要功能就是资源管理和作业调度。但 Kubernetes 不是运行在单机上管理单台计算资源和进程，而是运行在多台服务器上管理几百几千台的计算资源，以及在这些资源上运行的上万上百万的进程，规模要大得多。

Kubernetes 的基本架构

• 控制面 Control Plane
控制面的节点在 K8s 中叫做 Master Node，常简称为 Master，是整个集群里最重要的部分。

可以说是 Kubernetes 的大脑和心脏。

• 数据面 Data Plane
数据面的节点在 K8s 中叫做 Worker Node，常简称为 Worker 或 Node。

相当于 Kubernetes 的手和脚，在 Master 的指挥下干活。

Node 的数量非常多，构成了一个资源池，Kubernetes 就在这个池里分配资源，调度应用。因资源被“池化”，所以管理也就变得比较简单，可在集群中任意添加或者删除节点。

Client ——> kubectl

kubectl 是 Kubernetes 的客户端工具，用来操作 K8s，其位于集群之外，不属于集群。

节点内部的结构

Master 组件

• kube-apiserver

是 Master 节点 甚至整个 Kubernetes 系统的唯一入口，是 Kubernetes 里的”联络员“。

对外公开了一系列 RESTful API，并增加验证、授权等功能。所有组件都只能和它直接通信。

• etcd

Kubernetes 里的配置管理员

是一个高可用的分布式 Key-Value 数据库，用来持久化存储系统里的各种资源对象和状态。

etcd 只与 apiserver 有直接联系，任何其他组件想读写数据都必须经过 apiserver :
scheduler 必须通过 apiserver 才能获得节点状态和 Pod 信息；
controller-manager 也必须通过 apiserver 获得信息，才能实现对资源的各种操作。

• kube-scheduler

相当于部署人员

负责容器的编排工作，检查节点的资源状态，把 Pod 调度到最适合的节点上运行。

• kube-controller-manager

相当于监控运维人员

负责维护容器和节点等资源的状态，实现故障检测、服务迁移、应用伸缩等功能。

上述 4 个组件均被容器化，运行在集群的 Pod 里，可用 kubectl 来查看它们的状态：

命令行里要用 -n kube-system 参数，表示检查“kube-system”名字空间里的 Pod。

Node 组件

• kubelet

相当于是 Node 上的“小管家”

是 Node 的代理，负责管理 Node 相关的绝大部分操作。Node 上只有它能够与 kube-apiserver 通信，实现状态报告、命令下发、启停容器等功能。

• kube-proxy

相当于是专职的“小邮差”

是 Node 的网络代理，负责管理容器的网络通信。简单来说就是为 Pod 转发 TCP/UDP 数据包。

• container-runtime

是真正干活的“苦力”


因 Kubernetes 定位是容器编排平台，故其并未限定 container runtime 必须是 Docker。完全可以替换成任何符合标准的其他容器运行时，例如 containerd、 CRI-O 等。
是容器和镜像的实际使用者，在 kubelet 的指挥下创建容器，管理 Pod 的生命周期。

这 3 个组件中只有 kube-proxy 被容器化了，因 kubelet 必须要管理整个节点，容器化会限制其能力，所以必须在 container-runtime 之外运行。

插件

Addons

Kubernetes 工作流程

1. 每个 Node 上的 kubelet 均定期向 kube-apiserver 上报节点状态，kube-apiserver 存入 etcd 中；

2. 每个 Node 上的 kube-proxy 实现了 TCP/UDP 反向代理，让容器对外提供稳定的服务；

3. kube-scheduler 通过 kube-apiserver 得到当前的节点状态后，调度 Pod。然后 kube-apiserver 下发命令给某个 Node 上的 kubelet 。此 kubelet 调用 container-runtime 启动容器；

4. controller-manager 通过 kube-apiserver 得到实时的节点状态，监控可能的异常情况，再使用相应的手段去调节恢复。