【kubernetes】Pod进阶

于 2023-08-09 19:21:01 发布
阅读量494 收藏
点赞数
文章标签： kubernetes 云原生 容器
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/2302_76824193/article/details/132194762
版权

目录

资源限制

官网示例：

Pod 和 容器 的资源请求和限制：

CPU 资源单位

内存 资源单位 

示例1：

示例2：

重启策略（restartPolicy）

1、Always

2、OnFailure

3、Never

示例

容器进入error状态不会进行重启

健康检查：又称为探针（Probe） 

探针的三种规则：

●livenessProbe 

●readinessProbe

●startupProbe（这个1.17版本增加的）

Probe支持三种检查方法：

●exec

●tcpSocket

●httpGet

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

官网示例：

示例1：exec方式

示例2：httpGet方式

示例3：tcpSocket方式

示例4：就绪检测

readiness探测失败，无法进入READY状态

示例5：就绪检测2

readiness探测失败，Pod 无法进入READY状态，且端点控制器将从 endpoints 中剔除删除该 Pod 的 IP 地址

启动、退出动作

在 node02 节点上查看

删除 pod 后，再在 node02 节点上查看

资源限制

当定义 Pod 时可以选择性地为每个容器设定所需要的资源数量。 最常见的可设定资源是 CPU 和内存大小，以及其他类型的资源。

当为 Pod 中的容器指定了 request 资源时，代表容器运行所需的最小资源量，调度器就使用该信息来决定将 Pod 调度到哪个节点上。当还为容器指定了 limit 资源时，kubelet 就会确保运行的容器不会使用超出所设的 limit 资源量。kubelet 还会为容器预留所设的 request 资源量， 供该容器使用。

如果 Pod 运行所在的节点具有足够的可用资源，容器可以使用超出所设置的 request 资源量。不过，容器不可以使用超出所设置的 limit 资源量。

如果给容器设置了内存的 limit 值，但未设置内存的 request 值，Kubernetes 会自动为其设置与内存 limit 相匹配的 request 值。 类似的，如果给容器设置了 CPU 的 limit 值但未设置 CPU 的 request 值，则 Kubernetes 自动为其设置 CPU 的 request 值 并使之与 CPU 的 limit 值匹配。

官网示例：

https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/

Pod 和 容器 的资源请求和限制：

spec.containers[].resources.requests.cpu            //定义创建容器时预分配的CPU资源
spec.containers[].resources.requests.memory         //定义创建容器时预分配的内存资源
spec.containers[].resources.limits.cpu              //定义 cpu 的资源上限 
spec.containers[].resources.limits.memory           //定义内存的资源上限

CPU 资源单位

CPU 资源的 request 和 limit 以 cpu 为单位。Kubernetes 中的一个 cpu 相当于1个 vCPU（1个超线程）。
Kubernetes 也支持带小数 CPU 的请求。spec.containers[].resources.requests.cpu 为 0.5 的容器能够获得一个 cpu 的一半 CPU 资源（类似于Cgroup对CPU资源的时间分片）。表达式 0.1 等价于表达式 100m（毫核），表示每 1000 毫秒内容器可以使用的 CPU 时间总量为 0.1*1000 毫秒。
Kubernetes 不允许设置精度小于 1m 的 CPU 资源。 

内存 资源单位 

内存的 request 和 limit 以字节为单位。可以以整数表示，或者以10为底数的指数的单位（E、P、T、G、M、K）来表示， 或者以2为底数的指数的单位（Ei、Pi、Ti、Gi、Mi、Ki）来表示。
如：1KB=10^3=1000，1MB=10^6=1000000=1000KB，1GB=10^9=1000000000=1000MB
1KiB=2^10=1024，1MiB=2^20=1048576=1024KiB

PS：在买硬盘的时候，操作系统报的数量要比产品标出或商家号称的小一些，主要原因是标出的是以 MB、GB为单位的，1GB 就是1,000,000,000Byte，而操作系统是以2进制为处理单位的，因此检查硬盘容量时是以MiB、GiB为单位，1GiB=2^30=1,073,741,824，相比较而言，1GiB要比1GB多出1,073,741,824-1,000,000,000=73,741,824Byte，所以检测实际结果要比标出的少一些。

示例1：

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: app
    image: images.my-company.example/app:v4
    env:
    - name: MYSQL_ROOT_PASSWORD
      value: "password"
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
  - name: log-aggregator
    image: images.my-company.example/log-aggregator:v6
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"


此例子中的 Pod 有两个容器。每个容器的 request 值为 0.25 cpu 和 64MiB 内存，每个容器的 limit 值为 0.5 cpu 和 128MiB 内存。那么可以认为该 Pod 的总的资源 request 为 0.5 cpu 和 128 MiB 内存，总的资源 limit 为 1 cpu 和 256MiB 内存。

示例2：

vim pod2.yaml
apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: web
    image: nginx
    env:
    - name: WEB_ROOT_PASSWORD
      value: "password"
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
  - name: db
    image: mysql
    env:
    - name: MYSQL_ROOT_PASSWORD
      value: "abc123"
    resources:
      requests:
        memory: "512Mi"
        cpu: "0.5"
      limits:
        memory: "1Gi"
        cpu: "1"
kubectl apply -f pod2.yaml
kubectl describe pod frontend
kubectl get pods -o wide
NAME       READY   STATUS    RESTARTS   AGE   IP           NODE     NOMINATED NODE   READINESS GATES
frontend   2/2     Running   5          15m   10.244.2.4   node02   <none>           <none>
kubectl describe nodes node02                #由于当前虚拟机有2个CPU，所以Pod的CPU Limits一共占用了50%
Namespace                  Name                           CPU Requests  CPU Limits  Memory Requests  Memory Limits  AGE
  ---------                  ----                           ------------  ----------  ---------------  -------------  ---
  default                    frontend                       500m (25%)    1 (50%)     128Mi (3%)       256Mi (6%)     16m
  kube-system                kube-flannel-ds-amd64-f4pbp    100m (5%)     100m (5%)   50Mi (1%)        50Mi (1%)      19h
  kube-system                kube-proxy-pj4wp               0 (0%)        0 (0%)      0 (0%)           0 (0%)         19h
Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  Resource           Requests    Limits
  --------           --------    ------
  cpu                600m (30%)  1100m (55%)
  memory             178Mi (4%)  306Mi (7%)
  ephemeral-storage  0 (0%)      0 (0%)

重启策略（restartPolicy）

当 Pod 中的容器退出时通过节点上的 kubelet 重启容器。适用于 Pod 中的所有容器。

1、Always

当容器终止退出后，总是重启容器，默认策略

2、OnFailure

当容器异常退出（退出状态码非0）时，重启容器；正常退出则不重启容器

3、Never

当容器终止退出，从不重启容器。
注意：K8S 中不支持重启 Pod 资源，只有删除重建。
      在用 yaml 方式创建 Deployment 和 StatefulSet 类型时，restartPolicy 只能是 Always，kubectl run 创建 Pod 可以选择 Always,OnFailure,Never 三种策略

最低0.47元/天 解锁文章
一条会呼吸的鱼
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
K8S集群中Pod资源处于Error状态排查思路
江晓龙的博客
06-30 4148
Error状态是CrashLoopBackOff状态之前的一个错误状态，Pod资源处于Error状态的原因可能有以下几种：1）排查Pod的状态 2）查看Pod运行的详细日志从中获取线索 3）排查容器运行的日志获取关键信息 4）排查Kubelet日志以及Node节点系统日志从中获取关键信息......
06-Kubernetes Pod控制器应用进阶.mp4
07-26
06-Kubernetes Pod控制器应用进阶.mp4
k8s pod异常与故障排查及问题思路
砚墨
06-09 6599
通常情况下pod发生问题时首先收集一下错误 kubectl get pod <pod-name> -o yaml 查看 Pod 的配置是否正确 kubectl describe pod <pod-name> 查看 Pod 的事件 kubectl logs <pod-name> [-c <container-name>] 查看容器日志 Pod Pending 状态 如果一个 Pod 处于 Pending 状态，表示 Pod 没有被调度到节点上。通常这是因为某种
kubernetes命令学习
qq_33816292的博客
12-08 614
kubernetes命令学习
k8s运维之pod排错
qq_52804302的博客
11-01 715
k8s运维之pod排错 K8S是一个开源的，用于管理云平台中多个主机上的容器化应用，Kubernetes的目标是让部署容器化变得简单并且高效 K8S的核心优势： 1，基于yaml文件实现容器的自动创建、删除 2，更快速实现业务的弹性横向扩容 3，动态发现新扩容的容器并自动对用户提供访问 4，更简单、更快速的实现业务代码升级和回滚 一般来说pod处于异常状态，都可以执行以下命令查看pod状态 kubectl get pod <pod-name> -o yaml #查看pod配置 ku
Kubectl基础命令
stone_tomcate的博客
02-15 434
Kubectl简述 在学习如何更有效地使用kubectl之前，您应该基本了解它是什么以及它是如何工作的。 从用户角度来说： kubectl是控制Kubernetes的驾驶舱。它允许您执行所有可能的Kubernetes操作。 从技术角度来说： kubectl是Kubernetes API的客户端，通过该客户端我们可以完全控制Kubernetes，这意味着每个Kubernetes操作都...
Pod 常见错误及其故障排查思路
潇潇雨歇
04-27 3375
文章目录一、pod的几种状态：1.1常用的排障命令：二、常见故障归类Pod状态 一直处于 Pending2.1故障原因分析：2.1.1Pod --Pending状态2.1.2 Pod --Waiting 或 ContainerCreating状态2.1.3Pod – ImagePullBackOff状态2.1.4Pod – CrashLoopBackOff状态2.1.5Pod --Error 状态2.1.6Pod --Terminating 或 Unknown 状态2.1.7 Pod – Evicted状态
【K8S系列】Pod重启策略及重启可能原因
热门推荐
颜淡慕潇
01-30 1万+
1 重启策略 1.1Always Pod中的容器，不管因为什么原因停止，都会自动重启。 该为默认策略， 没有定义重启策略时，默认的就是always 1.2OnFailure Pod中的容器，非正常停止/异常退出时，会自动重启容器，如果是正常停止，则不会 1.3Nerver Pod中容器不管以什么原因退出，都不会自动重启容器 自动重启的可能原因： 1.Xms超出了k8s分配 2.docker容器的内存限制 3.出现OOMKilled事件
【Kubernetes实战】K8S集群Pod异常状态排查
Friendsofthewind的博客
03-12 1266
docker images本地可以查看到镜像，则需要将其执行：docker push ip:port/soft:v1.0将其推送到私有远程仓库，如果用pod控制器创建的可以删除pod，自动创建方式实现重建pod。因场景而异，有的时候是承载docker的节点物理内存不足，导致进程被杀死，或没被杀死，不能提供正常运行及处理任务所需内存。在事件列信息里确认是哪里出现问题，如果显示和docker有关，则证明还是“docker进程异常”，但是状态并没有死掉。第一步：执行上面两个查看服务状态命令，返回信息显示无异常；
K8S常见Pod 异常状态的处理
qq_45477065的博客
01-29 2275
https://blog.csdn.net/wuli_smbug/article/details/103767136 一般来说，无论 Pod 处于什么异常状态，都可以执行以下命令来查看 Pod 的状态 kubectl get pod -o yaml 查看 Pod 的配置是否正确 kubectl describe pod 查看 Pod 的事件 kubectl logs [-c ] 查看容器日志 Pod --Pending状态 Pending 说明 Pod 还没有调度到某个 Node 上面。可以通.
017 Kubernetes Pod控制器应用进阶.mp4
05-07
017 Kubernetes Pod控制器应用进阶.mp4
016 Kubernetes Pod控制器应用进阶.mp4
05-07
016 Kubernetes Pod控制器应用进阶.mp4
Pod进阶、Controller进阶、Resource和Dashboard
06-04
Pod进阶、Controller进阶、Resource和Dashboard 安装并使用好一个dashboard，操作及效果见博客：https://blog.csdn.net/qq_36963950/article/details/125115389
Docker到Kubernetes进阶视频.rar
10-23
│ kubernetes-learning.pdf,网盘文件永久链接 ├ 一、课程介绍 │ └ 11.课程介绍.mp4 ├ 七、深入理解Pod │ │ 18.YAML 文件.mp4 │ │ 19.静态 Pod.mp4 │ │ 20.Pod Hook.mp4 │ │ 21.Pod 的健康检查.mp4 │ ...
Error!!在k8s中查看pod日志报错
繁星若渺的博客
03-24 1918
目录1、报错现象2、解决思路3、解决方法 1、报错现象 2、解决思路 查看pod日志发现报错原因是权限问题 3、解决方法 [root@master01 ~]# kubectl create clusterrolebinding cluster-system-anonymous --clusterrole=cluster-admin --user=system:anonymous #指定集群中的匿名用户有管理员权限 [root@master01 ~]# kubectl logs nginx-dbddb
Kubernetes Pod 故障归类与排查方法
qq_24794401的博客
01-03 2339
Pod 概念 Pod是kubernetes集群中最小的部署和管理的基本单元，协同寻址，协同调度。 Pod是一个或多个容器的集合，是一个或一组服务（进程）的抽象集合。 Pod中可以共享网络和存储（可以简单理解为一个逻辑上的虚拟机，但并不是虚拟机）。 Pod被创建后用一个UID来唯一标识，当Pod生命周期结束，被一个等价Pod替代，UID将重新生成。 Docker 是 Kubernetes P...
pod重启策略和状态解释
yan_0916的博客
02-28 4119
一、Pod一直处于Pending状态二、Pod一直处于Waiting 或 ContainerCreating状态三、Pod 一直处于CrashLoopBackOff状态四、Pod处于Error状态五、Pod 处于Terminating或 Unknown状态 一、Pod一直处于Pending状态 Pending状态意味着Pod的YAML文件已经提交给Kubernetes，API对象已经被创建并保存在Etcd当中。但是，这个Pod里有些容器因为某种原因而不能被顺利创建。比如，调度不成功(可以通过kubectl.
k8s-生产实例 常见pod 状态代码 以及错误问题原因
m0_66705547的博客
01-18 1029
云原生-k8s-pod状态
异常处理-k8s-Pod 异常
惰立的博客
05-06 423
异常处理-k8s-Pod 异常
kubernetes pod 网络不通
最新发布
11-01
Kubernetes Pod 网络不通可能有多种原因。 首先，可能是 Pod 所属的 Node 网络故障。这可能是由于 Node 上的网络问题，例如网卡故障、网络配置错误或网络连接中断导致的。解决这个问题的方法可以是检查 Node 上的...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值