这是非云环境中Kubernetes的配置和运行系列的第四篇文章，本文将主要介绍Kubernetes的架构及主要组件，包括Pods、服务、卷、命名空间等。

想要先睹为快的读者，可直接克隆该项目的 GitHub 代码库。代码库中的文档正在持续改进中，并完全可用。代码库地址为： mvallim/kubernetes-under-the-hood

Kubernetes

“Kubernetes是一种用于管理容器化工作负载和服务的可移植、可扩展的开源平台，便于声明式配置和自动化。Kubernetes生态系统规模庞大，且增长快速，其服务，支持和工具已得到广泛使用。

“Google于2014年开源了Kubernetes项目。Kubernetes的建立基于Google十五年大规模生产工作负载的经验，并综合了来自社区的最佳思考和实践。

引用自： https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/

Kubernetes的优点包括：

敏捷应用开发和部署：与使用虚拟机镜像相比，Kubernetes改进了容器镜像创建的便捷性和效率。
容器开发、集成和部署：支持高频次、可靠的容器镜像构建和部署，并由于镜像的不可更改性，使得回滚更为快速和简单
有效隔离开发（Dev）和运维（Ops）：应用容器镜像创建是在构建/发布阶段，而非部署阶段，使应用得以从架构中解耦。
可观察性（Observability）：不仅涵盖操作系统层级的信息和度量，而且涉及应用健康等深层信息。
跨开发、测试和生产的环境一致性：无论对于云环境中，还是在个人笔记本上，都具有一致的运行环境。
云/操作系统发行版的可移植性：可运行在任何环境中，包括Debian、Ubuntu、CoreOS、本地部署、Google Kubernetes Engine、Amazon Elastic Container Service等。
以应用为中心的管理：将抽象层级从在虚拟硬件上运行操作系统，提升为使用逻辑资源在操作系统上运行应用。
松耦合、分布式、弹性、无约束的微服务：应用切分为可动态部署并管理的更小尺度独立部分，而非运行在专用机器上的单体应用。
资源隔离：支持应用性能可预测。
资源使用：更高效、更紧密。

引用自： https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/

为尽可能提供完备的功能，Kubernetes依赖并使用了其它一些开源工具。其中包括：

注册：例如 Docker Registry。
网络：例如 Flannel、 Calico、 MetalLB、 CoreDNS等。
遥测：例如 Prometheus、 Sysdig和 Istio。
安全：例如 LDAP、 SELinux、 RBAC和具有多层的 OAuth。
服务：对于过去常用应用模式创建的内容，支持以多种目录形式提供。

Kubernetes 架构

图 Kubernetes架构

Kubernetes管理的集群通常具有两个主要操作单元：主节点（Master）和工作节点（Worker）。

主节点（Master）：负责编排运行在工作节点上的所有容器相关活动。其中，主节点负责安排和部署集群应用，获取工作节点和Pod的相关信息。
工作节点（Worker）：是支持Kubernetes所管理容器得以有效运行的机器（节点）。工作节点可以是物理机，也可以是虚拟机。为了使工作节点可被Kubernetes管理，必须在其上安装Kubernetes的Kubelet代理。工作节点通过Kubelet代理完成与主机的所有通信，实现执行集群操作。

Kubernetes主节点从开发人员/运维人员（即DevOps）处接收指令，并传递给工作节点。这些指令由一组服务做处理，并重新传输。上述服务可自动确定最适合处理所请求任务的工作节点，然后将资源分配并指定给满足所请求指令的选定工作节点。

容器管理运行在更高层级上，其中已充分考虑工作细节。容器和工作节点的运作，无需手工主动干预。

主节点和工作节点的组件

容器网络接口（CNI，Container network interface）：该网络插件遵循appc/CNI规范。规范支持运行在不同节点上的Pod间的连接，并支持灵活集成overlays、纯第三层网络（pure L3）等多种网络解决方案。
- Kubernetes和CNI相关信息，可参见官方文档“ Network plugins”。
etcd：支持高可用和一致性的键值存储，用于Kubernetes中所有集群数据的存储。如果Kubernetes集群的后台存储使用etcd，需确保具有针对集群数据的备份计划。
api-server: 用于提供Kubernetes API的主节点组件。API服务是Kubernetes控制平台（Control Plane）的前端，设计上考虑了水平扩展，即随部署实例数量而扩展的能力。
控制平台：容器编排层，提供用于定义、部署和管理容器生命周期的API和接口。
调度程序（Scheduler）：主节点上的组件，用于监视新创建且未分配给工作节点的Pod，并调度一个工作节点运行该Pod。调度策略中考虑的因素包括：个体和全部资源需求、硬件/软件/策略约束，亲和性和反亲和性（affinity and anti-affinity）规范、数据的本地性、工作负载间的干扰和最后期限等。
Controller manager：主节点上运行控制器的组件。每个控制器在逻辑上是独立的进程，但是为了降低复杂性，它们被编译为一个二进制文件，以单个进程运行。
kubelet：运行在工作节点上的服务。kubelet读取Pod清单（manifests），确保清单中定义的容器已启动并处于运行状态。
containerd：容器运行时，注重于容器的简单性、鲁棒性和可移植性。在Linux或Windows上，containerd是以守护程序形式运行的容器运行时，负责获取和存储容器映像、执行容器、提供网络访问等。在我们的解决方案中，我们使用Docker实现上述功能。
Kube Proxy：运行在群集中每个工作节点上的网络代理。Kube-proxy负责请求转发，通过一组后端功能支持TCP/UDP流转发和轮询转发。

参考资料： https://kubernetes.io/docs/reference/glossary/?fundamental=true

Kubectl

图片来源： RisingStack

kubectl命令行工具提供与Kubernetes API服务的交互。用户可使用kubectl创建、更新和删除Kubernetes对象。

Docker简述

Docker功能可直接使用。不同之处在于，Kubernetes在配置Pod时，将指令发送给选定工作节点的kubelet，其中指定Docker去启动或停止容器。进而，kubelet继续从Docker及其容器中收集信息，并将所有这些信息汇总给主节点。其中的主要差异之处在于，所有这些操作都是自动进行的，无需管理员必须手动完成配置和信息收集。

Kubernetes的关键对象

下面简要介绍Kubernetes所管理的每个关键对象。细节将在Kubernetes之旅系列的下一篇文章中推出。

Pod：最小、最简的Kubernetes对象。Pod表示了一组集群中正在运行的容器。Pod的运行模式通常设置为单个主容器，也可选择添加对日志支持等辅助功能的挎斗模式（sidecar）容器。Pod通常由Deployment管理。

Deployment：管理复制（replicated）应用的API对象。每个副本表示为一个分布在集群工作节点间的Pod。

Service：描述Pods等应用访问方式的API对象，支持对端口和负载平衡器的描述。访问接入点可位于群集的内部或外部。

卷（Volume）：是包含数据并对Pod容器可访问的目录。Kubernetes卷的生命周期与包含它的Pod一致。因此，卷的寿命超过Pod中运行的所有容器，并且在容器重启后保留数据。
- 文件系统：在Kubernetes中，每个容器都可以在其自身的文件系统中执行读写操作。但是，容器重启或删除后，写入该文件系统的数据将被破坏。
- 卷：Kubernetes具有卷。只要Pod存在，Pod中的卷就将存在。卷可在同一Pod容器间共享。Pod重启或移除后，卷将被破坏。
- 持久卷：Kubernetes具有持久卷。持久卷提供Kubernetes集群中的长期存储。持久卷寿命超出容器、Pods和工作节点。只要Kubernetes集群存在，持久卷就存在。Pod可声明使用持久卷读取、写入和读写。

命名空间（Namespace）：一种Kubernetes用于支持在同一物理集群上的多个虚拟集群的抽象。命名空间用于组织集群中的对象，并提供了一种集群资源的划分方法。资源名称在同一命名空间中必须唯一，但在多个命名空间之间则不必唯一。

参考资料： https://kubernetes.io/docs/reference/glossary/?fundamental=true

原文链接：

Kubernetes Journey — Up and running out of the cloud — Kubernetes Overview

创作场景

非云环境中 Kubernetes 的配置和运行： Kubernetes 架构