8. K8s 资源部署

Posted 2023-03-09

参考技术A

很少在 Kubernetes 中直接创建一个Pod，甚至是单实例（Singleton）的 Pod。 这是因为 Pod 被设计成了相对临时性的、用后即抛的一次性实体， 不支持高可用 。一般使用工作负载资源来创建和管理多个 Pod。 资源的控制器能够处理副本的管理、上线，并在 Pod 失效时提供自愈能力。
能够管理一个或者多个 Pod 的工作负载资源有：

Pod 类似于共享namesapce、cgroup、文件系统卷的一组 Docker 容器。创建Pod时，除了会创建1个或多个工作容器外， 还会额外在Pod中创建Pod容器，Pod容器用于实现k8s的各种功能 。

查询基础信息

查询详细信息

查询Pod的标签

ReplicationController 确保在任何时候都有特定数量的 Pod 副本处于运行状态。 换句话说，ReplicationController 确保一个 Pod 或一组同类的 Pod 总是可用的。
RC会根据 spec.selector 将当前已经运行的Pod加入RC，当 Pod 数量过多时，ReplicationController 会终止多余的 Pod。当 Pod 数量太少时，ReplicationController 将会启动新的 Pod。

查询基础信息

查询详细信息

问题：
Pod创建完成后，如何访问Pod呢？直接访问Pod会有如下几个问题：

解决方法：
Kubernetes中的Service对象就是用来解决上述Pod访问问题的。Service有一个固定IP地址 Cluster IP ，Service将访问它的流量转发给Pod，具体转发给哪些Pod通过Label来选择，而且Service可以给这些Pod做负载均衡。

Node物理节点的IP地址

Service的IP地址，此为虚拟IP地址。外部网络无法ping通，只有kubernetes集群内部访问使用。

每个Pod的IP地址

Cluster地址和pod地址在不同网段，Cluster地址为虚拟地址，不配在pod上或主机上，外部访问时，先到Node节点网络（所有Node开放同一个端口号），再转到service网络，最后代理给pod网络。

Service的类型决定了如何向外暴露Service

通过集群的内部 IP 暴露服务，选择该值时服务只能够在集群内部访问。 这也是默认的 ServiceType。

通过每个节点上的 IP 和静态端口（NodePort）暴露服务。 NodePort 服务会路由到自动创建的 ClusterIP 服务。 通过请求 <Node节点 IP>:<节点端口>，你可以从集群的外部访问一个 NodePort 服务。

NodePort类型的Service例子：

Service默认的负载均衡模式是RR轮询模式，可以通过修改 spec.sessionAffinity 为 ClientIP 来实现源地址会话保持。可以设置会话保持的超时时间（默认时间是10800s），设置 spec.sessionAffinityConfig.clientIP.timeoutSeconds 的值。

Deployment 管理 ReplicaSet，并向 Pod 提供声明式的更新以及许多其他有用的功能，

首先根据文件创建deployment，加入 --record 参数来记录历史，方便在回滚时查看针对每个 Deployment 修订版本所执行过的命令。

Deployment会创建ReplicaSet，ReplicaSet负责启动Pods。ReplicaSet 的名称始终被格式化为 [Deployment名称]-[随机字符串] 。 其中的随机字符串是使用 pod-template-hash 作为种子随机生成的。

Deployment 控制器每次注意到新的 Deployment 时，都会创建一个 ReplicaSet 以启动所需的 Pods。 如果更新了 Deployment，则控制标签匹配 .spec.selector 但模板不匹配 .spec.template 的 Pods 的现有 ReplicaSet 被缩容。最终，新的 ReplicaSet 缩放为 .spec.replicas 个副本， 所有旧 ReplicaSets 缩放为 0 个副本。

当 Deployment 正在上线时被更新，Deployment 会针对更新创建一个新的 ReplicaSet 并开始对其扩容，之前正在被扩容的 ReplicaSet 会被翻转，添加到旧 ReplicaSets 列表 并开始缩容。

例如，假定你在创建一个 Deployment 以生成 nginx:1.14.2 的 5 个副本，但接下来 更新 Deployment 以创建 5 个 nginx:1.16.1 的副本，而此时只有 3 个nginx:1.14.2 副本已创建。在这种情况下，Deployment 会立即开始杀死 3 个 nginx:1.14.2 Pods， 并开始创建 nginx:1.16.1 Pods。它不会等待 nginx:1.14.2 的 5 个副本都创建完成 后才开始执行变更动作。

升级操作，两种方式：

Deployment之所以能如此容易的做到回滚，是因为Deployment是通过ReplicaSet控制Pod的，升级后之前ReplicaSet都一直存在，Deployment回滚做的就是使用之前的ReplicaSet再次把Pod创建出来。Deployment中保存ReplicaSet的数量可以使用 revisionHistoryLimit 参数限制，默认值为10。

查看Deployment 修订历史

输出

查看第n次的修订历史

输出

回滚到之前的修订版本

回滚后，Deployment 修订历史发生变化，revision 1变为revision 3

可以在触发一个或多个更新之前暂停 Deployment，然后再恢复其执行。 这样做使得你能够在暂停和恢复执行之间应用多个修补程序，而不会触发不必要的上线操作。

暂停

恢复

通过检测容器响应是否正常来决定是否重启Pod，Kubernetes支持如下三种探测机制：

Liveness Probe在 containers 字段中定义

为Deployment中的Pod配置Liveness Probe，Probe往容器的80端口发送HTTP GET请求，如果请求不成功，Kubernetes会重启容器。

在容器中执行 cat /tmp/healthy 命令，如果成功执行并返回 0 ，则说明容器是健康的。