概述
了解 Kubernetes 及其构件的高层次概要。
Kubernetes 是什么?
Kubernetes 是一个可移植的,可扩展的开源平台,用于管理容器化的工作负载和服务,方便了声明式配置和自动化。它拥有一个庞大且快速增长的生态系统。Kubernetes 的服务,支持和工具广泛可用。Kubernetes 组件
Kubernetes 集群由代表控制平面的组件和一组称为节点的机器组成。Kubernetes API
Kubernetes API 使你可以查询和操纵 Kubernetes 中对象的状态。 Kubernetes 控制平面的核心是 API 服务器和它暴露的 HTTP API。 用户、集群的不同部分以及外部组件都通过 API 服务器相互通信。使用 Kubernetes 对象
Kubernetes 对象是 Kubernetes 系统中的持久性实体。Kubernetes 使用这些实体表示你的集群状态。 了解 Kubernetes 对象模型以及如何使用这些对象。
Kubernetes 架构
Kubernetes 背后的架构概念。
¶节点
Kubernetes 通过将容器放入在节点(Node)上运行的 Pod 中来执行你的工作负载。 节点可以是一个虚拟机或者物理机器,取决于所在的集群配置。 每个节点包含运行 Pods 所需的服务; 这些节点由 控制面 负责管理。
通常集群中会有若干个节点;而在一个学习用或者资源受限的环境中,你的集群中也可能 只有一个节点。
节点上的组件包括 kubelet、 容器运行时以及 kube-proxy。
¶控制面到节点通信
本文列举控制面节点(确切说是 API 服务器)和 Kubernetes 集群之间的通信路径。 目的是为了让用户能够自定义他们的安装,以实现对网络配置的加固,使得集群能够在不可信的网络上 (或者在一个云服务商完全公开的 IP 上)运行。
¶控制器
在机器人技术和自动化领域,控制回路(Control Loop)是一个非终止回路,用于调节系统状态。
这是一个控制环的例子:房间里的温度自动调节器。
当你设置了温度,告诉了温度自动调节器你的期望状态(Desired State)。 房间的实际温度是当前状态(Current State)。 通过对设备的开关控制,温度自动调节器让其当前状态接近期望状态。
在 Kubernetes 中,控制器通过监控集群 的公共状态,并致力于将当前状态转变为期望的状态。
¶云控制器管理器
¶垃圾收集
垃圾收集是 Kubernetes 用于清理集群资源的各种机制的统称。
¶容器运行时接口(CRI)
容器
每个运行的容器都是可重复的; 包含依赖环境在内的标准,意味着无论您在哪里运行它,您都会得到相同的行为。
容器将应用程序从底层的主机设施中解耦。 这使得在不同的云或 OS 环境中部署更加容易。
工作负载
工作负载是在 Kubernetes 上运行的应用程序。
无论你的负载是单一组件还是由多个一同工作的组件构成,在 Kubernetes 中你可以在一组 Pods 中运行它。 在 Kubernetes 中,Pod 代表的是集群上处于运行状态的一组 容器。
不过,为了让用户的日子略微好过一些,你并不需要直接管理每个 Pod。 相反,你可以使用 负载资源 来替你管理一组 Pods。 这些资源配置 控制器 来确保合适类型的、处于运行状态的 Pod 个数是正确的,与你所指定的状态相一致。
Kubernetes 提供若干种内置的工作负载资源:
Deployment 和 ReplicaSet (替换原来的资源 ReplicationController)。
Deployment
很适合用来管理你的集群上的无状态应用,Deployment
中的所有Pod
都是相互等价的,并且在需要的时候被换掉。StatefulSet 让你能够运行一个或者多个以某种方式跟踪应用状态的 Pods。 例如,如果你的负载会将数据作持久存储,你可以运行一个
StatefulSet
,将每个Pod
与某个PersistentVolume
对应起来。你在StatefulSet
中各个Pod
内运行的代码可以将数据复制到同一StatefulSet
中的其它Pod
中以提高整体的服务可靠性。DaemonSet 定义提供节点本地支撑设施的
Pods
。这些 Pods 可能对于你的集群的运维是 非常重要的,例如作为网络链接的辅助工具或者作为网络 插件 的一部分等等。每次你向集群中添加一个新节点时,如果该节点与某DaemonSet
的规约匹配,则控制面会为该DaemonSet
调度一个Pod
到该新节点上运行。Job 和 CronJob。 定义一些一直运行到结束并停止的任务。
Job
用来表达的是一次性的任务,而CronJob
会根据其时间规划反复运行。
在庞大的 Kubernetes 生态系统中,你还可以找到一些提供额外操作的第三方 工作负载资源。通过使用 定制资源定义(CRD), 你可以添加第三方工作负载资源,以完成原本不是 Kubernetes 核心功能的工作。 例如,如果你希望运行一组 Pods
,但要求所有 Pods 都可用时才执行操作 (比如针对某种高吞吐量的分布式任务),你可以实现一个能够满足这一需求 的扩展,并将其安装到集群中运行。
¶Pods
¶工作负载资源
服务、负载均衡和联网
Kubernetes 网络背后的概念和资源。
¶Kubernetes 网络模型
每一个 Pod
都有它自己的IP地址, 这就意味着你不需要显式地在 Pod
之间创建链接, 你几乎不需要处理容器端口到主机端口之间的映射。 这将形成一个干净的、向后兼容的模型;在这个模型里,从端口分配、命名、服务发现、 负载均衡、应用配置和迁移的角度来看, Pod
可以被视作虚拟机或者物理主机。
Kubernetes 强制要求所有网络设施都满足以下基本要求(从而排除了有意隔离网络的策略):
- 节点上的 Pod 可以不通过 NAT 和其他任何节点上的 Pod 通信
- 节点上的代理(比如:系统守护进程、kubelet)可以和节点上的所有 Pod 通信
备注:对于支持在主机网络中运行 Pod
的平台(比如:Linux):
- 运行在节点主机网络里的 Pod 可以不通过 NAT 和所有节点上的 Pod 通信
这个模型不仅不复杂,而且还和 Kubernetes 的实现从虚拟机向容器平滑迁移的初衷相符, 如果你的任务开始是在虚拟机中运行的,你的虚拟机有一个 IP, 可以和项目中其他虚拟机通信。这里的模型是基本相同的。
Kubernetes 的 IP 地址存在于 Pod
范围内 - 容器共享它们的网络命名空间 - 包括它们的 IP 地址和 MAC 地址。 这就意味着 Pod
内的容器都可以通过 localhost
到达对方端口。 这也意味着 Pod
内的容器需要相互协调端口的使用,但是这和虚拟机中的进程似乎没有什么不同, 这也被称为“一个 Pod 一个 IP”模型。
如何实现以上需求是所使用的特定容器运行时的细节。
也可以在 Node
本身请求端口,并用这类端口转发到你的 Pod
(称之为主机端口), 但这是一个很特殊的操作。转发方式如何实现也是容器运行时的细节。 Pod
自己并不知道这些主机端口的存在。
Kubernetes 网络解决四方面的问题:
- 一个 Pod 中的容器之间通过本地回路(loopback)通信。
- 集群网络在不同 pod 之间提供通信。
- Service 资源允许你 对外暴露 Pods 中运行的应用程序, 以支持来自于集群外部的访问。
- 可以使用 Services 来发布仅供集群内部使用的服务。
- 使用拓扑键实现拓扑感知的流量路由
- 服务
- Pod 与 Service 的 DNS
- 使用 Service 连接到应用
- Ingress
- Ingress 控制器
- 拓扑感知提示
- 服务内部流量策略
- 端点切片(Endpoint Slices)
- 网络策略
- IPv4/IPv6 双协议栈
存储
为集群中的 Pods 提供长期和临时存储的方法。
配置
Kubernetes 为配置 Pods 提供的资源。
安全
确保云原生工作负载安全的一组概念。
-
在云原生安全的背景下思考 Kubernetes 安全模型。
-
对 Pod 安全性准入控制器的概述,Pod 安全性准入控制器可以实施 Pod 安全性标准。
策略
调度,抢占和驱逐
在Kubernetes中,调度 (scheduling) 指的是确保 Pods 匹配到合适的节点, 以便 kubelet 能够运行它们。抢占 (Preemption) 指的是终止低优先级的 Pods 以便高优先级的 Pods 可以 调度运行的过程。驱逐 (Eviction) 是在资源匮乏的节点上,主动让一个或多个 Pods 失效的过程。
¶调度
¶Pod 干扰
集群管理
关于创建和管理 Kubernetes 集群的底层细节。
集群管理概述面向任何创建和管理 Kubernetes 集群的读者人群。 我们假设你大概了解一些核心的 Kubernetes 概念。
扩展 Kubernetes
改变你的 Kubernetes 集群的行为的若干方法。