Kubernetes Pod概述

Pod简介

Pod是Kubernetes创建或部署的最小/最简单的基本单位，一个Pod代表集群上正在运行的一个进程。
一个Pod封装一个应用容器，Pod代表部署的一个单位。
Pods提供两种共享资源：网络和存储。
网络：每个Pod被分配一个独立的IP地址，Pod中的每个容器共享网络命名空间，包括IP地址和网络端口。
存储：Pod可以指定一组共享存储volumes。Pod中的所有容器都可以访问共享volumes，允许这些容器共享数据。
Pod不会自愈。如果Pod运行的Node故障，或者是调度器本身故障，这个Pod就会被删除。同样的，如果Pod所在Node缺少资源或者Pod处于维护状态，Pod也会被驱逐。Controller可以创建和管理多个Pod，提供副本管理、滚动升级和集群级别的自愈能力。例如，如果一个Node故障，Controller就能自动将该节点上的Pod调度到其他健康的Node上。

POD生命周期

Pod 的 status 定义在 PodStatus 对象中，其中有一个 phase 字段。

  • 挂起（Pending）：Pod 已被 Kubernetes 系统接受，但有一个或者多个容器镜像尚未创建。等待时间包括调度 Pod 的时间和通过网络下载镜像的时间，这可能需要花点时间。
  • 运行中（Running）：该 Pod 已经绑定到了一个节点上，Pod 中所有的容器都已被创建。至少有一个容器正在运行，或者正处于启动或重启状态。
  • 成功（Succeeded）：Pod 中的所有容器都被成功终止，并且不会再重启。
  • 失败（Failed）：Pod 中的所有容器都已终止了，并且至少有一个容器是因为失败终止。也就是说，容器以非0状态退出或者被系统终止。
  • 未知（Unknown）：因为某些原因无法取得 Pod 的状态，通常是因为与 Pod 所在主机通信失败。

容器存活探针

探针 是由 kubelet 对容器执行的定期诊断。要执行诊断，kubelet 调用由容器实现的 Handler。

  • ExecAction：在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。
  • TCPSocketAction：对指定端口上的容器的 IP 地址进行 TCP 检查。如果端口打开，则诊断被认为是成功的。
  • HTTPGetAction：对指定的端口和路径上的容器的 IP 地址执行 HTTP Get 请求。如果响应的状态码大于等于200 且小于 400，则诊断被认为是成功的。

livenessProbe：指示容器是否正在运行。
readinessProbe：指示容器是否准备好服务请求。
诊断结果状态：

  • 成功：容器通过了诊断。
  • 失败：容器未通过诊断。
  • 未知：诊断失败，因此不会采取任何行动。

重启策略

PodSpec 中有一个 restartPolicy 字段，可能的值为 Always、OnFailure 和 Never。默认为 Always，意味着容器在探测失败时被杀死并重新启动。

给容器和Pod分配内存资源

配置内存申请和限制

memory-request-limit.yaml

apiVersion: v1
kind: Pod
metadata:
  name: memory-demo
spec:
  containers:
  - name: memory-demo-ctr
    image: vish/stress
    resources:
      limits:
        memory: "200Mi"
      requests:
        memory: "100Mi"
    args:
    - -mem-total
    - 150Mi
    - -mem-alloc-size
    - 10Mi
    - -mem-alloc-sleep
    - 1s

创建一个容器的Pod，这个容器申请100M的内存，并且内存限制设置为200M,args代码段提供了容器所需的参数。-mem-total 150Mi告诉容器尝试申请150M 的内存。
在mem-example命名空间中创建pod：

# kubectl create -f memory-request-limit.yaml --namespace=mem-example

验证Pod的容器是否正常运行:

# kubectl get pod memory-demo --namespace=mem-example

查看Pod的详细信息:

# kubectl get pod memory-demo --output=yaml --namespace=mem-example
-----------------
...
resources:
  limits:
    memory: 200Mi
  requests:
    memory: 100Mi
...

POD实际使用内存约为150M。
删除Pod:

# kubectl delete pod memory-demo --namespace=mem-example

当创建POD时内存超出限制内存，则POD会被kill掉，reason: OOMKilled。
当创建POD时内存超出节点能力范围时，Pod的状态是Pending，因为Pod不会被调度到任何节点，它会一直保持在Pending状态下，因为节点上没有足够的内存。
如果没有内存限制，则容器使用内存资源没有上限，容器可以使用当前节点上所有可用的内存资源。

给容器和Pod分配CPU资源

给容器声明CPU限制

cpu-request-limit.yaml

apiVersion: v1
kind: Pod
metadata:
  name: cpu-demo
spec:
  containers:
  - name: cpu-demo-ctr
    image: vish/stress
    resources:
      limits:
        cpu: "1"
      requests:
        cpu: "0.5"
    args:
    - -cpus
    - "2"

会创建一个只有一个容器的Pod，这个容器申请0.5个CPU，并且CPU限制设置为1. cpus "2"代码告诉容器尝试使用2个CPU资源。
在cpu-example命名空间中创建pod:

# kubectl create -f cpu-request-limit.yaml --namespace=cpu-example

验证Pod的容器是否正常运行:

# kubectl get pod cpu-demo --namespace=cpu-example

查看Pod的详细信息:

# kubectl get pod cpu-demo --output=yaml --namespace=cpu-example
--------------
resources:
  limits:
    cpu: "1"
  requests:
    cpu: 500m

当创建的pod申请的CPU资源超过集群node所提供的资源，那么pod会一直处于Pending状态，那是因为这个Pod并不会被调度到任何节点上，所以它会一直保持这种状态。
如果你指定容器的CPU限额，则容器使用CPU资源没有上限，它可以使用它运行的Node上所有的CPU资源。

通过环境变量向容器暴露 Pod 信息

使用 Pod 字段作为环境变量的值

dapi-envars-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: dapi-envars-fieldref
spec:
  containers:
    - name: test-container
      image: k8s.gcr.io/busybox
      command: [ "sh", "-c"]
      args:
      - while true; do
          echo -en '\n';
          printenv MY_NODE_NAME MY_POD_NAME MY_POD_NAMESPACE;
          printenv MY_POD_IP MY_POD_SERVICE_ACCOUNT;
          sleep 10;
        done;
      env:
        - name: MY_NODE_NAME
          valueFrom:
            fieldRef:
              fieldPath: spec.nodeName
        - name: MY_POD_NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.name
        - name: MY_POD_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
        - name: MY_POD_IP
          valueFrom:
            fieldRef:
              fieldPath: status.podIP
        - name: MY_POD_SERVICE_ACCOUNT
          valueFrom:
            fieldRef:
              fieldPath: spec.serviceAccountName
  restartPolicy: Never

env 字段是 EnvVars 的数组。数组中的第一个元素指定 MY_NODE_NAME 环境变量从 Pod 的 spec.nodeName 字段中获取其值。字段是 Pod 的字段，不是 Pod 中的容器的字段。
创建pod：

# kubectl create -f dapi-envars-pod.yaml

查看容器日志：

# kubectl logs dapi-envars-fieldref
-------------
minikube
dapi-envars-fieldref
default
172.17.0.48
default

配置文件的 command 和 args 字段。当容器启动时，它将 5 个环境变量的值写到标准输出中。每十秒钟重复一次。
进入容器内查看环境变量：

MY_POD_SERVICE_ACCOUNT=default
...
MY_POD_NAMESPACE=default
MY_POD_IP=172.17.0.4
...
MY_NODE_NAME=minikube
...
MY_POD_NAME=dapi-envars-fieldref

使用容器字段作为环境变量的值

dapi-envars-container.yaml

apiVersion: v1
kind: Pod
metadata:
  name: dapi-envars-resourcefieldref
spec:
  containers:
    - name: test-container
      image: k8s.gcr.io/busybox:1.24
      command: [ "sh", "-c"]
      args:
      - while true; do
          echo -en '\n';
          printenv MY_CPU_REQUEST MY_CPU_LIMIT;
          printenv MY_MEM_REQUEST MY_MEM_LIMIT;
          sleep 10;
        done;
      resources:
        requests:
          memory: "32Mi"
          cpu: "125m"
        limits:
          memory: "64Mi"
          cpu: "250m"
      env:
        - name: MY_CPU_REQUEST
          valueFrom:
            resourceFieldRef:
              containerName: test-container
              resource: requests.cpu
        - name: MY_CPU_LIMIT
          valueFrom:
            resourceFieldRef:
              containerName: test-container
              resource: limits.cpu
        - name: MY_MEM_REQUEST
          valueFrom:
            resourceFieldRef:
              containerName: test-container
              resource: requests.memory
        - name: MY_MEM_LIMIT
          valueFrom:
            resourceFieldRef:
              containerName: test-container
              resource: limits.memory
  restartPolicy: Never

env 字段是 EnvVars 的数组。数组中的第一个元素指定 MY_CPU_REQUEST 环境变量从名为 test-container 的容器的 requests.cpu 字段中获取其值。类似地，其他环境变量从容器字段中获取它们的值。
创建pod，查看pod日志：

# kubectl create -f dapi-envars-container.yaml
# kubectl logs dapi-envars-resourcefieldref
--------------
1
1
33554432
67108864

原文地址：https://www.cnblogs.com/aresxin/p/Kubernetes-Pod.html

时间： 2024-11-01 01:35:50

Kubernetes Pod概述的相关文章

详解 Kubernetes Pod 的实现原理

Pod.Service.Volume 和 Namespace 是 Kubernetes 集群中四大基本对象,它们能够表示系统中部署的应用.工作负载.网络和磁盘资源,共同定义了集群的状态.Kubernetes 中很多其他的资源其实只对这些基本的对象进行了组合. Pod 是 Kubernetes 集群中能够被创建和管理的最小部署单元,想要彻底和完整的了解 Kubernetes 的实现原理,我们必须要清楚 Pod 的实现原理以及最佳实践. 在这里,我们将分两个部分对 Pod 进行解析,第一部分主要会从

Kubernetes Pod故障归类与排查方法

Pod概念 Pod是kubernetes集群中最小的部署和管理的基本单元,协同寻址,协同调度. Pod是一个或多个容器的集合,是一个或一组服务(进程)的抽象集合. Pod中可以共享网络和存储(可以简单理解为一个逻辑上的虚拟机,但并不是虚拟机). Pod被创建后用一个UID来唯一标识,当Pod生命周期结束,被一个等价Pod替代时UID将重新生成. Kubernetes Pod中最常用Docker容器运行,当然Pod也能支持其他的容器运行,比如rkt.podman等. Kubernetes集群中的P

Kubernetes Pod 控制器

在机器人技术和自动化中,控制环是一个控制系统状态的不终止的循环 这是一个控制环的例子:"房间里的温度自动调节器"当你设置了温度,告诉了温度自动调节器你的"期望状态",房间的实际温度是"当前状态".通过对设备的开关控制,温度自动调节器让其当前状态无限接近于期望状态.控制器通过 k8s的apiserver 去监控集群的公共状态,并致力于将当前状态转变为所期望的状态. 中文参考官方:怎么描述Kubernetes架构控制器的 kubernetes 之Po

Python Django撸个WebSSH操作Kubernetes Pod（下）- 终端窗口自适应Resize

追求完美不服输的我,一直在与各种问题斗争的路上痛并快乐着 上一篇文章Django实现WebSSH操作Kubernetes Pod最后留了个问题没有解决,那就是terminal内容窗口的大小没有办法调整,这会导致的一个问题就是浏览器上可显示内容的区域太小,当查看/编辑文件时非常不便,就像下边这样,红色可视区域并没有被用到 RESIZE_CHANNEL 前文说到kubectl exec有两个参数COLUMNS和LINES可以调整tty内容窗口的大小,命令如下: kubectl exec -i -t

kubernetes Pod 资源调度

1 概述 1 总述 API server 接受客户端提交的POD对象创建请求操作过程中,需要kube-scheduler 从当前集群中选择一个可用的最佳节点接受并运行,通常是默认调度器复制此类任务,对于每个待创建的POD来说,需要经过三个步骤.1 预选(predicate)节点预选: 基于一系列预选规则(podfitsresources 和 matchnode-selector等)对每个节点进行检查,将那些不符合条件的节点过滤.如果需要某些特殊服务,则需要通过组合节点标签,以及POD标签或标签选

[Kubernetes]Pod基本概念

Pod是Kubernetes项目的原子调度单位 为什么需要Pod? 容器是未来云计算系统中的进程,容器镜像就是这个系统里的".exe"安装包,那Kubernetes就是操作系统. 在一个真正的操作系统里,进程不是独自运行的,而是以进程组的方式组织在一起.对操作系统来说,进程组更方便管理,比如Linux只要将信号SIGKILL信号发送给一个进程组,那么该进程组中的所有进程都会收到这个信号而终止运行. 可以通过下面这个命令查看进程组,进程后面括号里的数字就是它的进程组ID(process

Kubernetes Pod应用的滚动更新(八)

一.环境准备 我们紧接上一节的环境,进行下面的操作,如果不清楚的,可以先查看上一篇博文. 滚动更新是一次只更新一小部分副本,成功后,再更新更多的副本,最终完成所有副本的更新.滚动更新的最大的好处是零停机,整个更新过程始终有副本在运行,从而保证了业务的连续性. 二.更新 我们查看一下上一节的配置文件mytest-deploy.yaml. apiVersion: extensions/v1beta1 kind: Deployment metadata: name: mytest spec: repl

Devoos核心要点及kubernetes架构概述

Ansible就是一个编排工具.docker :我们应用程序被容器化了,面向容器化的应用程序. docker compose 是一个docker编排工具,面向单台主机编排, docker swarm 是面向集群化的编排工具, docker machine mesos,marathon(容器遍排框架) AWS的. kubernetes DevOps(应用模式的开发),MicroServices,Blockchain CI: 持续集成 CD: 持续交付 Dlivery CD: 持续部署 Deploy

Kubernetes系列之Kubernetes Pod控制器

#一.常见Pod控制器及含义 ###1. ReplicaSets ReplicaSet是下一代复本控制器.ReplicaSet和 Replication Controller之间的唯一区别是现在的选择器支持.Replication Controller只支持基于等式的selector(env=dev或environment!=qa),但ReplicaSet还支持新的,基于集合的selector(version in (v1.0, v2.0)或env notin (dev, qa)).大多数kub