读书笔记 | Kubernetes in Action
- 2020 年 9 月 13 日
- 筆記
- k8s, Kubernetes
1 Kubernetes介绍
Kubernetes（以下简称K8s） 是一个部署和管理容器化应用的软件系统。它将底层基础设施抽象，简化了应用的开发、部署，以及对开发和运维团队的管理。
K8s由一个主节点和若干工作节点组成。开发者把应用描述提交到主节点，K8s会将描述中包含的容器镜像部署到集群的工作节点，开发者可以指定某些应用必须在一个工作节点一起运行（例如上图五边形和三角形应用），否则将被分散部署到集群中。
2 在K8s中运行应用
2.1 运行容器
pod
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
Job
一般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
CronJob是一种特殊的Job，用于在特定时间执行任务，或者在指定的时间间隔内重复运行。
CronJob的YAML描述文件类似如下：
下面是一些常用描述：
- restartPolicy——cron表达式；
- jobTemplate——创建任务资源；
- startingDeadlineSeconds——指定最迟必须在预定时间多少秒后开始运行，如未运行，任务将不会运行，并将显示为Failed;
2.2 保持容器运行
Probe
一旦程序运行起来，K8s定期对pod进行状态诊断，监控应用是否停止了工作，这种机制称为探针（Probe）。
有三种探针：
- livenessProbe——指示容器是否正在运行。如果失败则终止容器，容器将遵循其重新启动策略。需要使用
initialDelaySeconds属性设置初始延迟，保证容器已完成启动再探测; - readinessProbe——指示容器是否准备好响应请求。如果失败将删除该pod的IP地址;
- startupProb——指示容器中的应用程序是否启动。如果提供了启动探测，所有其他探测都将被禁用，直到它成功为止。如果失败则终止容器，容器将遵循其重新启动策略;
livenessProbe的YAML描述文件类似如下：
每种探针有三种探测机制：
- httpGet——对指定的端口和路径执行HTTP GET 请求，如果响应状态码不是2xx和3xx则探测失败；
- tcpSocket——与指定端口建立TCP连接，如果连接失败则探测失败；
- exec——在容器内执行任意命令，如果命令的退出状态码不是0则探测失败；
ReplicaSet
如果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
Deployment
当需要更新运行在pod的应用程序时，如何保证一组pod的实例正常运行？答案就是Deployment。
Deployment用于部署应用程序并以声明的方式升级应用。Deployment由ReplicaSet组成，并由它接管Deployment的pod。使用Deployment可以直接定义单个Deployment资源需要达到的状态，并让K8s处理中间的状态。
Deployment的YAML描述文件类似如下：
升级需要做的就是在pod模板中修改镜像的tag，K8s会收敛系统，匹配期望的状态。
下面是一些常用描述：
- maxSurge——期望的副本数之外，最多允许超出的pod实例数量；
- maxUnavailable——相对于期望副本数，能够允许有多少pod实例处于不可用状态；
- minReadySeconds——指定新创建的pod至少要运行多久之后，才能将其视为可用；
- progressDeadlineSeconds——判定滚动升级失败的超时时间；
2.3 迁移容器
Service
容器可能会重启，或者增加、停止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）。
HPA
指望靠人工干预来处理不可预测的流量增长不太现实，K8s可以检测CPU使用率或其他度量增长时自动对它扩容。
HorizontalpodAutoscaler (HPA)资源启用和配置Horizontal控制器，该控制器周期性检查pod度量， 计算满足HPA资源所配置的目标数值所需的副本数量， 进而调整目标资源的replicas字段。
HPA的YAML描述文件类似如下：
