我家自动化

这个屌丝很懒，什么也没留下！

热门标签

Kubernetes的Pod管理_kubectl 管理pod

作者：我家自动化 | 2024-03-24 21:26:34

踩

kubectl 管理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中

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/我家自动化/article/detail/305004