Article

k8s（三）走进k8s

5/30/2022
- 云计算

普遍意义上实现了容器编排，解决了容器难使用的问题。

作者：lomtom

个人网站：lomtom.cn 🔗

个人公众号：博思奥园 🔗

你的支持就是我最大的动力。

k8s 系列：

本节主要是提及一些 k8s 的相关概念，当然也会涉及到 k8s 的一些相关命令，暂时无需自己去敲这些命令，安装 k8s 集群，会在下一节中讲解，那时候再去体验这些命令也不迟。

K8s 诞生

如果想要将 Docker 应用于具体的业务实现，是存在困难的——编排、管理和调度等各个方面，都不容易。于是，人们迫切需要一套管理系统，对 Docker 及容器进行更高级更灵活的管理。

就在这个时候，K8S 出现了。

K8S，就是基于容器的集群管理平台，它的全称，是 kubernetes。

至于他为什么叫 K8s，那是因为从 k 到 s 之间刚好有 8 个字母（~~就是这么随意~~）。

功能：为容器化的应用提供了资源调度、部署运行、服务发现、扩容及缩容等一整套功能

K8s 集群

对于应用系统的架构，一般可以分为：

有中心架构，通常为一个管理节点和多个工作节点（或者数据节点），例如 HDFS。
无中心架构，所有的节点皆为同等的伙伴关系，例如 Redis 集群。

而一个 K8S 系统，通常称为一个K8S 集群（Cluster），他是属于有中心架构模式。

一个 Master 节点（主节点）：Master 节点主要还是负责管理和控制
多个 Node 节点（工作节点）：Node 节点是工作负载节点，里面是具体的容器

使用kubectl get node 来查看节点情况。

[root@master-1 ~]# kubectl get node
NAME        STATUS   ROLES    AGE   VERSION
master-1    Ready    master   72d   v1.17.11
slave-1     Ready    <none>   72d   v1.17.11
slave-2     Ready    <none>   72d   v1.17.11

Master

Kubernetes 里的 Master 指的是集群控制节点，在每个 Kubernetes 集群里都需要有一个 Master 来负责整个集群的管理和控制，基本上 Kubernetes 的所有控制命令都发给它，它负责具体的执行过程，我们后面执行的所有命令基本都是在 Master 上运行的。

Master 通常会占据一个独立的服务器（高可用部署建议用 3 台服务器），主要原因是它太重要了，是整个集群的“首脑”，如果它宕机或者不可用，那么对集群内容器应用的管理都将失效。

Master 节点包括 API Server、Scheduler、Controller manager、etcd。

API Server 是整个系统的对外接口，供客户端和其它组件调用，相当于“营业厅”，即集群的入口及出口。
- 包括认证、授权、准入等功能；
- 还包括对 etcl 的数据缓存；
- 建立其他模块与 etcl 的通信枢纽。
Scheduler 负责对集群内部的资源进行调度，相当于“调度室”。调度过程：
- Predict：过滤掉不符合业务需求的节点。
- Priority：按照满足需求的情况下，选择最佳节点。
- Bind：将工作节点与 pod 绑定，完成调度
Controller manager 负责管理控制器，相当于“大总管”。
etcd：etcd 的官方将它定位成一个可信赖的分布式键值（key，value）存储服务，它能够为整个分布式集群存储一些关键数据，协助分布式集群的正常运转

[root@master ~]# kubectl get pod -A -o wide |grep  master
kube-system   coredns-6d8c4cb4d-2fbpp          1/1     Running   0               2d21h   10.244.0.3    master
kube-system   coredns-6d8c4cb4d-g8jzg          1/1     Running   0               2d21h   10.244.0.2    master
kube-system   etcd-master                      1/1     Running   1 (2d21h ago)   2d21h   8.16.0.67     master
kube-system   kube-apiserver-master            1/1     Running   1 (2d21h ago)   2d21h   8.16.0.67     master
kube-system   kube-controller-manager-master   1/1     Running   2 (29h ago)     2d21h   8.16.0.67     master
kube-system   kube-flannel-ds-7gm8n            1/1     Running   0               2d21h   8.16.0.67     master
kube-system   kube-proxy-tdz44                 1/1     Running   0               2d21h   8.16.0.67     master
kube-system   kube-scheduler-master            1/1     Running   2 (29h ago)     2d21h   8.16.0.67     master

Node

Node 节点包括 Docker、kubelet、kube-proxy、Fluentd、kube-dns（可选），还有就是Pod。

Pod 是 Kubernetes 最基本的操作单元。一个 Pod 代表着集群中运行的一个进程，它内部封装了一个或多个紧密相关的容器。除了 Pod 之外，K8S 还有一个 Service 的概念，一个 Service 可以看作一组提供相同服务的 Pod 的对外访问接口。

Docker，Docker 引擎，负责本机的容器创建和管理工作。
Kubelet，主要负责监视指派到它所在 Node 上的 Pod，包括创建、修改、监控、删除等。
Kube-proxy，主要负责为 Pod 对象提供代理。
Fluentd，主要负责日志收集、存储与查询。

Namespace

Namespace（命名空间）是资源隔离的基本单位，K8s 将集群内部的资源分配到不同的 Namespace 下。

Kubernetes 集群在启动后会创建一个名为 default 的 Namespace，通过 kubectl 可以查看:kubectl get namespaces

[root@master ~]# kubectl get ns
NAME                 STATUS   AGE
default              Active   39d
kube-node-lease      Active   39d
kube-public          Active   39d
kube-system          Active   39d

在使用kubectl命令查看 k8s 资源时都需要带上-n参数来指定命名空间，不指定时将是默认的命名空间。

Pod

Kubernetes 官网 🔗

Pod 是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元。

Pod 是一组（一个或多个）容器 🔗；这些容器共享存储、网络、以及怎样运行这些容器的声明。 Pod 中的内容总是并置（colocated）的并且一同调度，在共享的上下文中运行。 Pod 所建模的是特定于应用的“逻辑主机”，其中包含一个或多个应用容器，这些容器是相对紧密的耦合在一起的。在非云环境中，在相同的物理机或虚拟机上运行的应用类似于在同一逻辑主机上运行的云应用。

Kubernetes 为每个 Pod 都分配了唯一的 IP 地址，称之为 Pod IP，一个 Pod 里的多个容器共享 Pod IP 地址。

根据 Pod 在集群中的存储位置可以分为两种类型:

普通的 Pod
静态 Pod(Static Pod)。

后者比较特殊，它并没被存放在 Kubernetes 的 etcd 存储里，而是被存放在某个具体的 Node 上的一个具体文件中，并且只在此 Node 上启动、运行。

而普通的 Pod 一旦被创建，就会被放入 etcd 中存储，随后会被 Kubernetes Master 调度到某个具体的 Node 上并进行绑定(Binding)，随后该 Pod 被对应的 Node 上的 kubelet 进程实例化成一组相关的 Docker 容器并启动。在默认情况下，当 Pod 里的某个容器停止时，Kubernetes 会自动检测到这个问题并且重新启动这个 Pod(重启 Pod 里的所有容器)，如果 Pod 所在的 Node 宕机，就会将这个 Node 上的所有 Pod 重新调度到其他节点上。

同样，根据 pod 的数据是否是持久化可以分为有状态的和无状态的。

有状态：会持久化数据到永久存储中，可以存储在集群的存储中，也可以外挂硬盘来进行存储，例如 Mysql 服务器。
无状态：无状态服务不会在本地存储持久化数据，比如 web 应用。

1)deployment 认为所有的 pod 都是一样的 2)不用考虑顺序的要求 3)不用考虑在哪个 node 节点上运行 4)可以随意扩容和缩容

那么在 k8s 中怎么获取 pod 的信息呢？

使用kubectl get pod 即可获取 pod 的状态信息。

[root@master-1 ~]# kubectl get pod
NAME          READY   STATUS             RESTARTS   AGE
pod1          0/1     Completed          0          3d
pod2          1/1     Running            0          2d
pod3          0/1     CrashLoopBackOff   5000       2d

工作负载

Kubernetes 官网 🔗

工作负载是在 Kubernetes 上运行的应用程序（相当于数据库、后端等所有组在一起能够提供完整功能的应用）。

无论你的负载是单一组件还是由多个一同工作的组件构成，在 Kubernetes 中你可以在一组 Pods 🔗 中运行它。在 Kubernetes 中，Pod 代表的是集群上处于运行状态的一组容器 🔗。

Kubernetes Pods 有确定的生命周期 🔗。例如，当某 Pod 在你的集群中运行时，Pod 运行所在的节点 🔗 出现致命错误时，所有该节点上的 Pods 都会失败。Kubernetes 将这类失败视为最终状态：即使该节点后来恢复正常运行，你也需要创建新的 Pod 来恢复应用。

不过，为了让用户的日子略微好过一些，你并不需要直接管理每个 Pod。相反，你可以使用 负载资源 来替你管理一组 Pods。这些资源配置控制器 🔗 来确保合适类型的、处于运行状态的 Pod 个数是正确的，与你所指定的状态相一致。

容器、pods、工作负载关系

为什么 Kubernetes 会设计出一个全新的 Pod 的概念并且 Pod 有这样特殊的组成结构？

原因之一：在一组容器作为一个单元的情况下，我们难以简单地对“整体”进行判断及有效地行动。比如，一个容器死亡了，此时算是整体死亡么？是 N/M 的死亡率么？引入业务无关并且不易死亡的 Pause 容器作为 Pod 的根容器，以它的状态代表整个容器组的状态，就简单、巧妙地解决了这个难题。
原因之二：Pod 里的多个业务容器共享 Pause 容器的 IP，共享 Pause 容器挂接的 Volume，这样既简化了密切关联的业务容器之间的通信问题，也很好地解决了它们之间的文件共享问题。

Service

在 Kubernetes 中，Service 是分布式集群架构的核心，一个 Service 对象拥有如下关键特征。

◎ 拥有唯一指定的名称（比如 mysql-server）。

◎ 拥有一个虚拟 IP（Cluster IP、Service IP 或 VIP）和端口号。

◎ 能够提供某种远程服务能力。

◎ 被映射到提供这种服务能力的一组容器应用上。

我们运行的应用（Pod）通常通过 Service 来进行对外暴露的。

K8S 控制器

在 K8s 中，我们通常很少的去使用pod的定义文件去生成，而是使用更高级的控制器来管理这些pod。通常有以下控制器。

Replication Controller
- 机制
  
  定义了一个 RC 并将其提交到 Kubernetes 集群中后，Master 上的 Controller Manager 组件就得到通知，定期巡检系统中当前存活的目标 Pod，并确保目标 Pod 实例的数量刚好等于此 RC 的期望值，如果有过多的 Pod 副本在运行，系统就会停掉一些 Pod，否则系统会再自动创建一些 Pod。
- 好处
  
  可以说，通过 RC，Kubernetes 实现了用户应用集群的高可用性，并且大大减少了系统管理员在传统 IT 环境中需要完成的许多手工运维工作（如主机监控脚本、应用监控脚本、故障恢复脚本等）。
Replica Set

在 Kubernetes 1.2 后引入，Replica Set 与 RC 当前的唯一区别是，Replica Sets 支持基于集合的 Label selector（Set-based selector），而 RC 只支持基于等式的 Label Selector（equality-based selector），这使得 Replica Set 的功能更强。

当前很少单独使用 Replica Set，它主要被 Deployment 这个更高层的资源对象所使用，从而形成一整套 Pod 创建、删除、更新的编排机制。
Deployment

在 Kubernetes 1.2 后引入，用于更好地解决 Pod 的编排问题。

Deployment 相对于 RC 的一个最大升级是我们可以随时知道当前 Pod“部署”的进度。实际上由于一个 Pod 的创建、调度、绑定节点及在目标 Node 上启动对应的容器这一完整过程需要一定的时间，所以我们期待系统启动 N 个 Pod 副本的目标状态，实际上是一个连续变化的“部署过程”导致的最终状态。

Deployment 的典型使用场景有以下几个。

◎ 创建一个 Deployment 对象来生成对应的 Replica Set 并完成 Pod 副本的创建。

◎ 检查 Deployment 的状态来看部署动作是否完成（Pod 副本数量是否达到预期的值）。

◎ 更新 Deployment 以创建新的 Pod（比如镜像升级）。

◎ 如果当前 Deployment 不稳定，则回滚到一个早先的 Deployment 版本。

◎ 暂停 Deployment 以便于一次性修改多个 PodTemplateSpec 的配置项，之后再恢复 Deployment，进行新的发布。

◎ 扩展 Deployment 以应对高负载。

◎ 查看 Deployment 的状态，以此作为发布是否成功的指标。

◎ 清理不再需要的旧版本 ReplicaSets。
StatefulSet

为了解决：Pod 的管理对象 RC、Deployment、DaemonSet 和 Job 都面向无状态的服务，所以引入 StatefulSet

Kubernetes 从 1.4 版本开始引入了 PetSet 这个新的资源对象，并且在 1.5 版本时更名为 StatefulSet，StatefulSet 从本质上来说，可以看作 Deployment/RC 的一个特殊变种。

特性：

◎ StatefulSet 里的每个 Pod 都有稳定、唯一的网络标识，可以用来发现集群内的其他成员。假设 StatefulSet 的名称为 kafka，那么第 1 个 Pod 叫 kafka-0，第 2 个叫 kafka-1，以此类推。

◎ StatefulSet 控制的 Pod 副本的启停顺序是受控的，操作第 n 个 Pod 时，前 n-1 个 Pod 已经是运行且准备好的状态。

◎ StatefulSet 里的 Pod 采用稳定的持久化存储卷，通过 PV 或 PVC 来实现，删除 Pod 时默认不会删除与 StatefulSet 相关的存储卷（为了保证数据的安全）。
DaemonSet

守护进程集
Job

批处理任务
CronJob

k8s 的强大之处远比我们想象的还要强大的多

本文为原创内容，欢迎分享与引用，请保留作者与原文链接。

文章标题

k8s（三）走进k8s

作者

lomtom

发布方式

原创发布

原文链接 https://lomtom.cn/2ef4a819 ↗

k8s（三）走进k8s

K8s 诞生

K8s 集群

Master

Node

Namespace

Pod

工作负载

Service

K8S 控制器

K8s 基于 IB RDMA 网络加速大模型分布式训练的实践指南

CKA（一）注意

CKA（二）题库一