Kubernetes的Pod管理

一、了解pod

Pod 管理
Pod 是可以创建和管理 Kubernetes 计算的最小可部署单元，一个 Pod 代表着集群
中运行的一个进程，每个 pod 都有一个唯一的 ip 。
．一个 pod 类似一个豌豆英，包含一个或多个容器（通常是 docker )，多个容器间
共享 IPC 、 Network 和 UTC namesnace 。

• container实际上是一个单进程模型

• pod可以类比为进程组概念

• pod在k8s中必须是原子调度单位

• Pod 要解决的问题核心就在于如何让一个 Pod 里的多个容器之间最高效的共享某些资源

和数据。

• 通过infra container的方式共享同一个network namespace

• 镜像k8s.gcr.io/pause由汇编语言编写、永远处于“暂停”状态，大小100~200KB

• 直接使用localhost通信

• pod内的所有容器共享一份网络资源，一个pod一份。

• 整个pod的生命周期跟infra容器一致，而与其它容器无关

• 所有同属于一个 Pod 的容器，他们共享所有的 volume。

 

 

• Pod 是 Kubernetes 项目里实现“容器设计模式”的核心机制

•

“容器设计模式”是 Google Borg 的大规模容器集群管理最佳实践之一，也是 Kubernetes 进行复杂应用编排的基础依赖之一；

• 所有“设计模式”的本质都是：解耦和重用。

• 容器设计模式

• initcontainer

• sidecar

• 应用与日志收集

• 代理容器

• 适配器容器

 

二.pod的管理和配置

创建  查看  并且删除一个自主式pod

 

创建一个控制器pod

 我们发现这个pod删不掉  他可以自愈 （控制器始终会维护我们的副本数，当副本数不够的时候他会自动创建）

 

根据业务需求可以对他进行快速的扩容缩容

 

 如何把这个控制器发布出去

 

我们访问他的vip发现有负载均衡

 

当你扩容我们发现 他立马多出三个地址（用来实现负载均衡）

 

默认情况下只能再集群内暴露  要是暴露集群以外就要编辑svc

 这样我们就可以再容器外部访问

 只有这样删除 才能让他彻底删除

 

三、资源清单

• 格式如下：

• apiVersion: group/version　　//指明api资源属于哪个群组和版本，同一个组

可以有多个版本

$ kubectl api-versions

//查询命令

• kind:

//标记创建的资源类型，k8s主要支持以下资源类别

Pod,ReplicaSet,Deployment,StatefulSet,DaemonSet,Job,Cronjob

 

• metadata:

//元数据

name：

//对像名称

namespace：

//对象属于哪个命名空间

labels：

//指定资源标签，标签是一种键值数据

annotations：

//用来描述资源的注解

ownerReference:// 用来描述多个资源之间相互关系

• spec:

//定义目标资源的期望状态

• status：

//用来描述观测到的状态

• $ kubectl explain pod

//查询帮助文档

 

 

 我们利用代码转化出 相关的yaml文件

 修改一下文件  然后熟悉运行删除操作

 

 把上述的yaml文件 根据自己的需求加以修改

 

 

上图看出  我们要运行两个name

 我们可以思考要是一个yaml文件 两个用一个镜像  会发生什么呢？

 

我们运行后发现 有一个error 

 kubectl logs demo -c web1  用下面这个代码进行查看

 

这个问题时什么情况导致呢

 

我们可以看出 80端口已经被占用  因为一个pod共享一个网络 第一个已经占有了80端口  所以第二个不能占有80端口  可以是其他端口

 

 

再次修改一下

 

我们发现这个节点再server2上

 

我们再server2上查看端口映射

 

再其他节点是看不到的

 再变化一次yaml文件

 

运行yaml文件 

 

我们查看实验是否成功

 

四、Pod的生命周期

• 探针 是由 kubelet 对容器执行的定期诊断:

• ExecAction：在容器内执行指定命令。如果命令退出时返回码为 0 则认为 诊断成功。

• TCPSocketAction：对指定端口上的容器的 IP 地址进行 TCP 检查。如果 端口打开，则诊断被认为是成功的。

• HTTPGetAction：对指定的端口和路径上的容器的 IP 地址执行 HTTP Get 请求。如果响应的状态码大于等于200 且小于 400，则诊断被认为是成功 的。

• 每次探测都将获得以下三种结果之一：

• 成功：容器通过了诊断。

• 失败：容器未通过诊断。

• 未知：诊断失败，因此不会采取任何行动。

 

 

 

 

 • 重启策略

• PodSpec 中有一个 restartPolicy 字段，可能的值为 Always、OnFailure 和 Never。默认Always。

• Pod 的生命

• 一般Pod 不会消失，直到人为销毁他们，这可能是一个人或控制器。

• 建议创建适当的控制器来创建 Pod，而不是直接自己创建 Pod。因为单独的 Pod 在机器故障的情况下没有办法自动复原，而控制器却可以。

• 三种可用的控制器：

• 使用 Job 运行预期会终止的 Pod，例如批量计算。Job 仅适用于重启策略为 OnFailure 或 Never 的 Pod。

• 对预期不会终止的 Pod 使用 ReplicationController、ReplicaSet 和 Deployment ，例如 Web 服务器。 ReplicationController 仅适用于具有 restartPolicy 为 Always 的 Pod。

• 提供特定于机器的系统服务，使用 DaemonSet 为每台机器运行一个 Pod 。

 

 

 

• Kubelet 可以选择是否执行在容器上运行的三种探针执行和做出反应：

• livenessProbe：指示容器是否正在运行。如果存活探测失败，则 kubelet 会 杀死容器，并且容器将受到其 重启策略 的影响。如果容器不提供存活探针， 则默认状态为 Success。

• readinessProbe：指示容器是否准备好服务请求。如果就绪探测失败，端点 控制器将从与 Pod 匹配的所有 Service 的端点中删除该 Pod 的 IP 地址。初 始延迟之前的就绪状态默认为 Failure。如果容器不提供就绪探针，则默认状 态为 Success。

• startupProbe: 指示容器中的应用是否已经启动。如果提供了启动探测 (startup probe)，则禁用所有其他探测，直到它成功为止。如果启动探测失 败，kubelet 将杀死容器，容器服从其重启策略进行重启。如果容器没有提 供启动探测，则默认状态为成功Success。

 

 

下面实验就是解释pod探针

 

 kubectl describe pod 查看一下日志

 

可以看出8080端口被拒绝了（因为nginx是80  但访问的是8080）

 

 

因为策略是Always 所以pod一直都在尝试重启

 我们把8080改成80 再试一下

 他虽然running 但是没有ready

 

我们发现test.html 始终没有就绪

 

当我们创建他时  立马就可以ready

 

那有test.html和没有他有什么区别

 

 

我们发现容器的地址已经出现再svc中