Kubernetes网络自学系列 | 容器基础设施的代言人：Kubernetes

Posted 2023-01-09 COCOgsta

素材来源：《Kubernetes网络权威指南》

一边学习一边整理内容，并与大家分享，侵权即删，谢谢支持！

附上汇总贴：Kubernetes网络自学系列 | 汇总_COCOgsta的博客-CSDN博客

---

3.1 容器基础设施的代言人：Kubernetes

云时代，企业将不再耗巨资投资自己的IT系统，而是直接使用无限制的按需付费的云服务，这无疑将显著降低IT基础设施的开销。作为程序员，笔者时常为自己有机会投身于这个波澜壮阔的技术变革事业感到莫名的激动。全面云化推进过程中最引人注目的便是“云原生”（Cloud Native）的概念。CNCF对云原生的最原始的定义是：

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。这些技术能够构建容错性好、易于管理、便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统做出频繁和可预测的重大变更。

简单地说，就是充分利用云计算的优势构建（build）和运行（run）软件，而一切技术都是围绕容器发展的。“Build once，run everywhere”，Docker公司提出的这个口号现在喊起来已经朗朗上口了。

有时我们会思考，当容器技术方兴未艾的时候，是什么促使了云原生技术如雨后春笋般在企业间萌发？诚然，“一次构建，到处运行”——容器良好的可移植性、敏捷性和Docker革新的镜像打包方式相较云计算最初的IaaS虚拟机形态，更容易成为公有云全新的基础设施和交付手段。但Docker毕竟只是一个运行时，当我们需要一个编排框架作为系统核心来串联开发、测试、发布、运行、升级等整个软件生命周期时，它就略显单薄。

3.1.1 Kubernetes简介

Kubernetes，简称k8s（k和s中间有8个英文字符），是谷歌照着鼎鼎大名的Borg系统开源的容器编排、调度和管理平台。如今的Kubernetes，既是GitHub上的明星项目，也获得了公有云厂商（包括AWS）的青睐。

关心容器生态圈的朋友，想必都已经接受了Kubernetes作为容器编排甚至是云原生标准的事实。

如图3-1所示，Kubernetes的logo是个船舵形象，寓意成为运输容器集装箱货轮的舵手。船舵的七个辐条来源于项目原先的名称，“Seven of Nine”。Borg是“星际迷航”电影中的一个宇宙种族，Seven of Nine则是该种族的一名女性角色。

图3-1 Kubernetes的logo

Kubernetes通过将容器分类组成Pod。Pod是Kubernetes中特有的一个概念，它是容器分组的一层抽象，也是Kubernetes最小的部署单元。Kubernetes基于Pod提供工作负载的概念及网络、存储等能力。

和其他技术一样，大量的专有名词有可能成为入门的障碍。下面解释一些通用的术语，希望能够帮助读者理解Kubernetes。

·Master（主节点）：控制Kubernetes工作节点的机器，运行着Kubernetes的管理面，也是创建Kubernetes工作负载的地方；

·Node（工作节点）：这些机器在Kubernetes主节点的控制下将工作负载以容器的方式运行起来；

·Pod：由一个或多个容器构成的集合，作为一个整体被部署到一个节点上。同一个Pod 中的容器共享网络协议栈、进程间通信（IPC）、主机名、存储其他资源。Kubernetes的Pod概念使得用户能够方便地对一组功能相似的容器的网络、存储、迁移和生命周期等进行管理。Pod运行一个或多个容器，节点运行零个或多个Pod；

·Replication Controller/Replication Set：控制Pod在集群上运行的副本数量；

·Service（服务）：将服务访问信息与具体的Pod解耦。Kubernetes服务代理负责自动将服务请求分发到正确的后端Pod处；

·Kubelet：守护进程，运行在每个工作节点上，保证该节点上容器的正常运行；

·kubectl：Kubernetes的命令行工具。

从底层实现技术的角度看，Pod内不同容器之间共享存储和一些namespace。具体来说，Pod中的容器可以共享的资源有：

·PID命名空间：Pod中的不同应用程序可以看到其他应用程序的进程ID；

·网络命名空间：Pod中的多个容器能够访问同一个IP和端口范围；

·IPC命名空间：Pod中的多个容器能够使用SystemV IPC或POSIX消息队列进行通信；

·UTS命名空间：Pod中的多个容器共享一个主机名；

·Volumes（共享存储卷）：Pod中的各个容器可以访问在Pod级别定义的存储卷。

需要注意的是，在Kubernetes 1.8版本之前默认支持Pod PID namespace共享，在之后的版本中默认关闭了PID namespace共享，具体原因我们会在介绍Kubernetes的pause容器时详细解释。

本书重点讨论Kubernetes网络，因此不花大量篇幅介绍Kubernetes的基本概念，感兴趣的读者可以自行查阅其他相关资料。

关于Kubernetes为什么要发明Pod概念，在后面的章节中会专门解释。

3.1.2 Kubernetes能做什么

真实的生产环境应用会包含多个容器，而这些容器很可能会跨越多个服务器部署。Kubernetes提供了容器大规模部署、编排与管理的能力。Kubernetes提供的工作负载抽象能够让用户非常方便地构建多容器的应用服务，并且支持弹性伸缩、滚动升级和健康检查等功能。

一个初步的Linux容器应用程序把容器视作高效、快速的虚拟机。一旦把它部署到生产环境或者扩展为多个应用，随着这些容器的累积，运行环境中容器的数量就会急剧增加，复杂度也随之增大。因此，Kubernetes通常需要与镜像仓库、网络、存储、安全、监控告警等其他服务集成才能提供综合性的容器基础设施，如图3-2所示。

图3-2 Kubernetes及其周边服务

有了Kubernetes，用户可以：

·跨主机编排容器；

·更充分地利用硬件资源最大化地满足企业应用的需求；

·控制与自动化应用的部署与升级；

·为有状态的应用程序挂载和添加存储器；

·线上扩展或裁剪容器化应用程序与它们的资源；

·声明式的容器管理，保证所部署的应用按照我们部署的方式运作；

·通过自动布局、自动重启、自动复制、自动伸缩实现应用的状态检查与自我修复。

然而，Kubernetes依赖其他项目提供完整的编排服务，要正确实施的Kubernetes可以集成云原生领域的其他开源项目，让用户可以管理自己的容器基础设施。一些参考的项目如下所示：

·仓库：Harbor、Docker Registry等；

·网络：OpenvSwitch、CNI、Calico等；

·监控：Prometheus、Kibana、watchdog、Elastic等；

·安全：LDAP、SELinux、OAUTH、Spiffe等；

·存储：Rook、Torus等。

3.1.3 如何用Kubernetes

我们将Kubernetes视为云计算时代的操作系统，它管理着集群中的节点和在之上运行的容器。Kubernetes的Master节点从管理员处接收命令，再把指令转交给其管理的工作节点，然后在该节点上分配资源并指派Pod来完成任务请求。

所以从基础设施的角度看，管理容器的方式发生了一点小小的变化。对容器的控制在更高的层次进行，提供了更佳的控制方式，无须用户微观管理每个单独的容器或者节点。必要的工作则集中在如何指派Kubernetes主节点、定义节点、Pod和更高层次的工作负载（Workload）等问题上，如图3-3所示。

图3-3 Kubernetes工作原理

3.1.4 Docker在Kubernetes中的角色

最后，介绍Docker在Kubernetes中扮演的角色。通常情况下，Docker依然执行它原本的任务，即管理容器和镜像。当Kubernetes把Pod调度到节点上，节点上的Kubelet会指示Docker启动特定的容器。接着，Kubelet会通过cgroup持续地收集容器的信息，然后提交到Kubernetes的管理面。Docker如往常一样拉取容器镜像、启动或停止容器。

值得一提的是，随着CRI标准的提出和成熟，Kubernetes正在逐渐弱化Docker的作用。诚然，Docker对容器技术的迅速普及做出了非常重要的贡献，随着Docker中集成越来越多容器网络和编排层的功能，Docker不再是一个纯粹的容器引擎，而且稳定性也受到一定影响。Kubernetes作为编排层完全可以替用户屏蔽底层容器实现技术，提供一个更简单和通用的容器接口层，让containerd、cri-o、katacontainer等更轻量或更安全的容器技术实现CRI接口并集成Kubernetes。