读书笔记 Kubernetes in Action

Posted 2023-03-01

参考技术A Kubernetes（以下简称K8s） 是一个部署和管理容器化应用的软件系统。它将底层基础设施抽象，简化了应用的开发、部署，以及对开发和运维团队的管理。

K8s由一个主节点和若干工作节点组成。开发者把应用描述提交到主节点，K8s会将描述中包含的容器镜像部署到集群的工作节点，开发者可以指定某些应用必须在一个工作节点一起运行（例如上图五边形和三角形应用），否则将被分散部署到集群中。

K8s处理应用描述时，会指示容器运行时（例如Docker）拉取所需的镜像并运行容器。但是，K8s并不直接处理单个容器，它的基本构建模块称为pod。

一个pod是一组紧密相关的容器，总是一起运行在同一个工作节点上。使用这种方式，可以让每个应用进程运行与自己的容器中，不相关的应用互相隔离，而密切相关的进程又可以作为一个单元进行管理。

pod的YAML描述文件类似如下：

可以使用命令 kubectl create -f kubia-manual.yaml 创建一个pod。

下面是一些常用命令：

kubectl get po kubia-manual  –o  yaml#查看描述

kubectl get pods#列出pod

kubectl logs kubia-manual#查看日志

kubectl delete po kubia-manual#删除pod

一般pod都是持续运行的，即使容器内的进程执行结束，也会被调度重启，永远没有完成状态。而Job用于运行完成工作后就终止的情况。

Job会创建一种pod，该pod在内部进程成功结束时，不重启容器，pod将处于完成状态。由Job管理的pod，如果在节点上异常退出，会一直被重新安排，直到它完成任务。因此，需要保证任务是幂等的。

Job的YAML描述文件类似如下：

下面是一些常用描述：

restartPolicy——需要明确设置重启策略为OnFailure或Never（默认为Alwayse）；

completions——需要一个Job运行的次数；

parallelism——同一Job并行运行的pod数量；

activeDeadlineSeconds——限制pod运行时间，超过将尝试终止pod，并将pod标记为失败；

backoffLimit——标记为失败前可重试次数，默认为6；下面是一些常用命令：

kubectl get jobs#列出Job

CronJob是一种特殊的Job，用于在特定时间执行任务，或者在指定的时间间隔内重复运行。

CronJob的YAML描述文件类似如下：

下面是一些常用描述：

restartPolicy——cron表达式；

jobTemplate——创建任务资源；

startingDeadlineSeconds——指定最迟必须在预定时间多少秒后开始运行，如未运行，任务将不会运行，并将显示为Failed;

一旦程序运行起来，K8s定期对pod进行状态诊断，监控应用是否停止了工作，这种机制称为探针（Probe）。

有三种探针：

livenessProbe——指示容器是否正在运行。如果失败则终止容器，容器将遵循其重新启动策略。需要使用initialDelaySeconds属性设置初始延迟，保证容器已完成启动再探测;

readinessProbe——指示容器是否准备好响应请求。如果失败将删除该pod的IP地址;

startupProb——指示容器中的应用程序是否启动。如果提供了启动探测，所有其他探测都将被禁用，直到它成功为止。如果失败则终止容器，容器将遵循其重新启动策略;

livenessProbe的YAML描述文件类似如下：

每种探针有三种探测机制：

httpGet——对指定的端口和路径执行HTTP GET 请求，如果响应状态码不是2xx和3xx则探测失败；

tcpSocket——与指定端口建立TCP连接，如果连接失败则探测失败；

exec——在容器内执行任意命令，如果命令的退出状态码不是0则探测失败；

如果pod停止工作，K8s会重新启动它们，但是如果工作节点故障，那么节点上的pod将会丢失。

ReplicaSet通常用来保证给定数量的、完全相同的 pod 的可用性，K8s会持续监控由ReplicaSet创建的正在运行的pod列表，并保证相应类型的pod的数目与期望相符。

ReplicaSet的YAML描述文件类似如下：

下面是一些常用描述：

replicas——指定pod实例的目标数目；

selector.matchLabels——匹配pod的标签，还可以用matchExpressions属性重写选择器;

下面是一些常用命令：

kubectl get rs#列出ReplicaSet

kubectl describe rs#描述ReplicaSet

当需要更新运行在pod的应用程序时，如何保证一组pod的实例正常运行？答案就是Deployment。

Deployment用于部署应用程序并以声明的方式升级应用。Deployment由ReplicaSet组成，并由它接管Deployment的pod。使用Deployment可以直接定义单个Deployment资源需要达到的状态，并让K8s处理中间的状态。

Deployment的YAML描述文件类似如下：

升级需要做的就是在pod模板中修改镜像的tag，K8s会收敛系统，匹配期望的状态。

下面是一些常用描述：

maxSurge——期望的副本数之外，最多允许超出的pod实例数量；

maxUnavailable——相对于期望副本数，能够允许有多少pod实例处于不可用状态；

minReadySeconds——指定新创建的pod至少要运行多久之后，才能将其视为可用；

progressDeadlineSeconds——判定滚动升级失败的超时时间；

容器可能会重启，或者增加、停止pod副本，如果容器需要给集群中的其他容器或外部客户端提供使用，如何让客户端发现正确的pod并与之通信？

K8s服务是一种为一组功能相同的pod提供单一不变的接入点的资源。当服务存在时，它的IP地址和端口不会改变。

客户端不需要知道单独pod的地址，始终通过服务的IP地址和端口号建立连接。

Service的YAML描述文件类似如下：

下面是一些常用描述：

sessionAffinity——设置成ClientIP让特定客户端产生的请求每次都指向同一个pod；

K8s为客户端提供了多种服务发现方式：

环境变量——创建了kubia服务，环境变量中有KUBIA_SERVICE_HOST和 KUBIA_SERVICE_PORT ，分别代表了 kubia 服务的 IP 地址和端口号;

将服务类型设为NodePort——每个集群节点都会打开一个端口；

将服务类型设为LoadBalance——通过一个专用的负载均衡器访问；

创建Ingress资源——它运行在HTTP层，可以将不同的服务映射到相同主机的不同路径；

requests和limits

开发人员通常不关心应用程序运行在哪台服务器上，只要服务器能够为应用程序提供足够的系统资源。

可以指定容器对CPU和内存的资源请求量（requests）和资源限制量（limits），确保pod公平地使用K8s集群资源，同时也影响着整个集群pod的调度方式。

requests的YAML描述文件类似如下：

调度器只关注节点上部署的所有pod的资源requests之和，并不关注实际使用量。另外，CPU requests不仅仅在调度时起作用，也决定了未使用的CPU时间在容器之间会按照CPU requests比例分配。

limits的YAML描述文件类似如下：

所有limits的总和可以超过节点资源的总量的100%——即超卖。如果节点使用量超过100%，一些容器将被杀掉。

在一个超卖的系统，QoS等级决定了哪个容器第一个被杀掉（BestEffort->Burstable->Guaranteed）。

指望靠人工干预来处理不可预测的流量增长不太现实，K8s可以检测CPU使用率或其他度量增长时自动对它扩容。

HorizontalpodAutoscaler (HPA)资源启用和配置Horizontal控制器，该控制器周期性检查pod度量， 计算满足HPA资源所配置的目标数值所需的副本数量， 进而调整目标资源的replicas字段。

HPA的YAML描述文件类似如下：