- 综合排序
- 最热优先
- 最新优先
- 来自专栏积跬Coder
Pod
Pod是资源对象模型中由用户创建或部署的最小资源对象模型，也是K8s上运行容器应用的资源对象， 其他的资源对象都是用来支撑或扩展Pod对象的功能 比如 控制器对象是用来管控Pod对象 service或ingress 资源对象是用来暴露Pod引用对象 PersistentVolume资源对象是为Pod提供存储的 k8s 不会直接处理容器，而是Pod。 Pod由一个或多个container组成 Pod是K8s的最重要的概念，每一个Pod都有一个特殊的被称之为根容器的Pause容器。Pause容器对应的镜像属于K8s的一部分。 除了Pause容器，每个Pod还包含一个或多个紧密相关的用户业务容器 基本概念 最小部署单位 包含多个容器(一组容器的集合) 同一个Pod容器共享网络命名空间(同一个Pod，共享网络) Pod短暂存在 一个容器有进程，一个容器运行一个应用程序 Pod是“多进程”设计，运行多个应用程序 Pod的存在，为了亲密性 两个应用需要进行交互 网络外部隔离，内部互通 Pod共享实现机制 共享网络 容器本身之间相互隔离
84111发布于 2020-12-18 - 来自专栏开源部署
Pod 介绍
一、什么是 Pod Pod 是 kubernetes 集群中最小的部署和管理的基本单元，协同寻址，协同调度。 Pod 是一个或多个容器的集合，是一个或一组服务（进程）的抽象集合。 同一个 Pod 里的容器之间仅需通过 localhost 就能互相通信。 二、Pod 的网络 每个Pod被分配了唯一的IP地址，该Pod内的所有容器共享一个网络空间，包括IP和端口。 同个Pod不同容器之间通过localhost通信，Pod内端口不能冲突。 不同Pod之间的通信则通过IP+端口的形式来访问到Pod内的具体服务（容器）。 Pod中，同个Pod中的多个容器之间互相访问可以通过localhost来通信。 kebectl describe pod Pod名称 -n 空间名称，如果不指定则默认显示default空间内的 pod 删除 kubectl delete pod Pod名称 / kubectl delete
6.7K14编辑于 2022-09-15 - 来自专栏全栈程序员必看
evicted Pod
apiVersion: v1 kind: Pod metadata: annotations: checksum/config: 8476fd6406a3cc87e5471154d85fd7c50e6a629acda16989a09a5d90937bb5b0 app.kubernetes.io/instance: test-myapi-ingress app.kubernetes.io/name: myapi-ingress-controller pod-template-hash myapi-ingress-controller - ingress - --config-path - /ingress-myapi/conf/config.yaml env: - name: POD_NAMESPACE valueFrom: fieldRef: apiVersion: v1 fieldPath: metadata.namespace - name: POD_NAME
48230编辑于 2022-08-27 - 来自专栏木二天空
021.掌握Pod-Pod调度策略
一 Pod生命周期管理 1.1 Pod生命周期 Pod在整个生命周期过程中被系统定义了如下各种状态。 1.2 Pod重启策略 Pod重启策略（RestartPolicy）应用于Pod内的所有容器，并且仅在Pod所处的Node上由kubelet进行判断和重启操作。 Kubernetes将Job氛围以下三类： Non-parallel Jobs 通常一个Job只启动一个Pod，除非Pod异常，才会重启该Pod，一旦此Pod正常结束，Job将结束。 都能独立判断和决定是否还有任务项需要处理； 如果某个Pod正常结束，则Job不会再启动新的Pod； 如果一个Pod成功结束，则此时应该不存在其他Pod还在工作的情况。 Pod的infrastructure容器更新时， Pod将会重启。 若Pod中的所有应用容器都终止了， 并且RestartPolicy=Always， 则Pod会重启。
1.8K31发布于 2019-11-22 - 来自专栏linux技术
kubernetes | pod
Pod是短暂的 存在意义# Pod为亲密性应用而存在。 # 静态Pod特点： Pod由特定节点上的kubelet管理 不能使用控制器 Pod名称标识当前节点名称 在kubelet配置文件启用静态Pod： vi /var/lib/kubelet 将部署的pod yaml放到该目录会由kubelet自动创建 重启策略# Always：当容器终止退出后，总是重启容器，默认策略。 健康检查# 健康检查有以下两种类型： livenessProbe（存活检查）：如果检查失败，将杀死容器，根据Pod的restartPolicy来操作。 readinessProbe（就绪检查）：如果检查失败，Kubernetes会把Pod从service endpoints中剔除。
84620编辑于 2022-10-25 - 来自专栏木二天空
020.掌握Pod-Pod基础使用
redis-php #查看详细信息 5 三 静态Pod 3.1 静态Pod概述 静态pod是由kubelet进行管理的仅存在于特定Node的Pod上，他们不能通过API Server进行管理，无法与 删除该pod只能在其运行的node上，将定义POD的yaml删除。 四 Pod容器共享Volume 4.1 共享Volume 在同一个Pod中的多个容器能够共享Pod级别的存储就Volume。 六 Pod获取自身信息 6.1 Downward API pod拥有唯一的名字、IP地址，并且处于某个Namespace中。pod的容器内获取pod的信息科通过Downward API实现。 logs dapi-test-pod | grep MY_POD 3 MY_POD_NAMESPACE=default 4 MY_POD_IP=172.30.240.4 5 MY_POD_NAME
87620发布于 2019-11-21 - 来自专栏院长运维开发
创建一个Pod---liveness-exec-pod
vim liveness-exec.yaml apiVersion: v1 kind: Pod metadata: name: liveness-exec-pod namespace: default initialDelaySeconds: 1 periodSeconds: 3 执行创建 [root@master01 ~]#kubectl apply -f liveness-exec.yaml pod /liveness-exec-pod created 获取pods [root@master01 ~]#kubectl get pods NAME READY STATUS RESTARTS AGE liveness-exec-pod 0/1 ContainerCreating 0 8s web 0 3d15h 查看pods描述信息，发现活性探测失败 [root@master01 ~]#kubectl describe pods liveness-exec-pod
66320发布于 2020-07-14 POD的创建流程及POD的删除流程
一、POD的创建流程1、用户通过kubectl或其他API客户端提交pod对象给APIserver.2、APIserver尝试将pod对象的相关信息存入etcd中，写入操作完成后APIserver返回确认信息至客户端 6、Kube-schduler为pod对象挑选一个工作节点并将结果更新至APIserver。7、调度结果由APIserver更新至etcd，而且APIserver也开始翻新此Pod对象的调度结果。 二、POD的删除流程1、请求删除pod。2、APIserver将Pod标记为Terminating状态。 3、（与第2步同时进行）Kubelet在监控到pod对象转为Terminating状态的同时启动pod关闭过程。4、（与第2步同时进行）Service将Endpoint摘除。 5、如果当前pod对象定义了preStophook，则在其标记为Terminating后会以同步的方式执行，宽限期开始计划。6、pod中的容器进程收到TERM信号。
9910编辑于 2026-02-11- 来自专栏CSDN搜“看，未来”
Pod 定义详解
文章目录 Yaml 格式的 Pod 定义文件的完整内容如下 对 Pod 定义文件模板中各属性的详细说明 如果记不住 Yaml 格式的 Pod 定义文件的完整内容如下 apiVersion: v1 kind : Pod metadate: name: string namespace: string labels: - name: string annotations: - spec object Required pod 中容器的详细定义 s.containers list Required pod 中的容器列表 s.c.name string Required 方式需要制定的命令或脚本 s.l.httpGet object 对 Pod 内各容器健康检查的设置，httpGet 方式 s.l.tcpSocket object 对 Pod 内各容器健康检查的设置 KIND: Pod VERSION: v1 FIELDS: apiVersion <string> kind <string> metadata <Object
73610编辑于 2022-09-27 - 来自专栏首富手记
Pod依赖启动
你可以在 Pod 的规约中与用来描述应用容器的 containers数组平行的位置指定 Init 容器。 Pod 也可以有一个或多个先于应用容器启动的 Init 容器。 如果 Pod 的 Init 容器失败，kubelet 会不断地重启该 Init 容器直到该容器成功为止。 然而，如果 Pod 对应的 restartPolicy值为 "Never"，并且 Pod 的 Init 容器失败， 则 Kubernetes 会将整个 Pod 状态设置为失败。 我们可以在POD B内添加一个init containers容器.这个容器的作用就是去探测pod A是否正常启动，这个探测可以是http 也可以是TCP的。
96920编辑于 2022-04-15 - 来自专栏痴者工良
容器与 Pod
Pod 最简单的说法就是将多个容器打包起来一起运行，这个整体就是 Pod。 Pod 中的所有容器共享相同的资源和本地网络，从而简化了 Pod 中应用程序之间的通讯。在 Pod 中，所有容器中的进程共享网络，可以通过 127.0.0.1、localhost 相互进行访问。 随着 Pod 负载的增加，Kubernetes 可以自动复制 Pod 以达到预期的可拓展性(部署更多的 Pod 提供相同的服务，负载均衡)。 Pod 为容器提供了一种抽象，可以将一个或多个应用程序包装到一个 Pod 中，而 Pod 是 Kubernetes 集群中最小的执行单元。 例如 Pod 可以包含初始化容器，这些容器为其它应用提供了准备环境，然后在应用程序开始执行前终结。Pod 是集群中复制的最小单位，Pod 中的容器作为整体被扩展或缩小。
1.3K10发布于 2021-11-24 - 来自专栏玖叁叁
Pod平滑退出
一、概述在Kubernetes中，Pod的平滑退出是指容器在终止之前可以处理完所有正在进行的请求和任务，保证数据的完整性和一致性。在本文中，我们将介绍如何实现Pod的平滑退出，并给出相应的示例。 二、实现Pod的平滑退出在Kubernetes中，Pod的平滑退出可以通过以下两种方式来实现：通过在Pod的容器中运行一个脚本或应用程序来处理信号，然后在接收到终止信号时进行清理操作。 通过在Pod的控制器中设置terminationGracePeriodSeconds字段来定义容器的终止时长，在这段时间内，Kubernetes会等待容器完成正在进行的任务，并尝试优雅地终止容器。 通过运行脚本或应用程序处理信号在Pod中的容器中，可以编写一个脚本或应用程序来处理信号。 通过设置terminationGracePeriodSeconds字段另一种实现Pod平滑退出的方式是通过在Pod的控制器中设置terminationGracePeriodSeconds字段。
2.7K20编辑于 2023-04-29 - 来自专栏kubernetes中文社区
Kubernetes Pod基础
Pod对象功能的，比如控制器对象是用来管控Pod对象的，Service或者Ingress资源对象是用来暴露Pod引用对象的，PersistentVolume资源对象是用来为Pod提供存储等等，k8s不会直接处理容器 ，而是Pod，Pod是由一个或者多个container组成的。 节点，Pod，容器之前的关系 二：Pod 特性： 2.1 资源共享 一个Pod里的多个容器可以共享存储和网络，可以看作一个逻辑的主机。 一个Pod里的多个容器可以共享存储卷，这个存储卷会被定义为Pod的一部分，并且可以挂载到该Pod里的所有容器的文件系统上。 2.2 生命周期短暂 Pod属于生命周期比较短暂的组件，比如，当Pod所在节点发生故障，那么该节点上的Pod会被调度到其他节点，但需要注意的是，被重新调度的Pod是一个全新的Pod,跟之前的Pod没有半毛钱关系
97730发布于 2019-06-24 - 来自专栏玖叁叁
Pod的示例
下面是一个完整的Pod示例，该Pod包含两个容器：一个运行Nginx的容器和一个运行PHP-FPM的容器。 mountPath: /var/www/html volumes: - name: app hostPath: path: /data/app该清单文件定义了一个名为nginx-php的Pod 此外，Pod定义了一个名为app的卷，并将宿主机上的/data/app目录挂载到该卷中。
42051编辑于 2023-04-28 - 来自专栏小手冰凉
pod 资源对象
DaemonSet: 用于确保每一个节点都运行了某个Pod的一个副本，新增的 节点一样会被添加此类Pod,在节点移除时，此类Pod会被回收。 #编写例子yaml文件 [root@docker-k8s01 pod]# cat test-pod.yaml kind: pod apiVersion: v1 metadata: name: test-pod spec: containers: - name: test-pod image: httpd Pod中镜像获取策略 //将上述Pod资源的镜像下载策略改为IfNotPresent [root@docker-k8s01 pod]# cat test-pod.yaml kind: pod apiVersion: v1 metadata: name: test-pod spec 容器重启策略 //将上述Pod资源添加重启策略为OnFailure [root@docker-k8s01 pod]# cat test-pod.yaml kind: pod apiVersion: v1
82040发布于 2020-09-09 - 来自专栏有点技术
critical pod浅谈
请注意，将pod标记为关键并不意味着完全防止驱逐。它只能防止pod永久不可用。对于静态pod，这意味着无法将其逐出，但对于非静态pod，这仅意味着它们将始终被重新调度。 设置critical pod 在v1.11之前，关键Pod必须在kube-system命名空间中运行，在v1.11之后，此限制已被删除，并且可以通过以下两种方式将任何命名空间中的pod配置为关键Pod： ,被抢占pod非关键pod,则抢占成功 如果都设置的有Priority，则抢占者大于被抢占pod的优先级时，抢占成功 这里可以看到，同为优先级为2000001000以上的关键pod,优先级的依旧可以被抢占 关键pod判定 func IsCriticalPod(pod *v1.Pod) bool { if IsStaticPod(pod) { return true } if 如果为静态pod则为关键pod 如果为mirrorpod则为关键pod 即带有 kubernetes.io/config.mirror注释的pod,实际上只要是static pod,都会加上这个注释，和上面的有重复
92820发布于 2020-07-14 - 来自专栏玖叁叁
Pod重启策略
一、概述在Kubernetes中，Pod是最小的可部署对象，可以由一个或多个容器组成。在实际使用中，Pod可能会由于各种原因停止工作，此时可以通过Pod的重启策略来决定如何处理这种情况。 在本文中，我们将介绍Pod的重启策略以及如何设置重启策略。二、Pod的重启策略Pod的重启策略定义了在容器失败或退出时，Kubernetes将如何处理该Pod。 Never在容器失败或退出时，Kubernetes将不会自动重启容器，也不会重建Pod。 - name: my-container image: my-image restartPolicy: Always在上述示例中，Pod将始终自动重新启动容器。 image: my-image restartPolicy: Never在上述示例中，Pod在容器失败或退出时不会自动重启容器，也不会重建Pod。
1.9K41编辑于 2023-04-29 - 来自专栏devops_k8s
优雅停止Pod
Pod 摘掉，同时给 Pod 发 SIGTERM 信号让 Pod 中的各个容器优雅退出就行了。 因此，K8s 的 Pod 终止流程中还有一个“最多可以容忍的时间”，即 grace period（在 Pod 的 .spec.terminationGracePeriodSeconds 字段中定义），这个值默认是 最后我们串起来再整个表述一下 Pod 退出的流程（官方文档里更严谨哦）： 1 . 用户删除 Pod。 2 2.1. Pod 进入 Terminating 状态。 2.2. 与此同时，K8s 会将 Pod 从对应的 service 上摘除。 2.3. 假如类似的事情发生了，为了业务稳定和数据安全，我们就不能强制关闭 Pod，而应该停止操作过程，通知工程师介入。 这时，上面所说的 Pod 退出流程就不再适用了。
2.4K71发布于 2021-09-08 - 来自专栏木二天空
022.掌握Pod-Pod升级和回滚
注意：在整个升级的过程中，系统会保证至少有两个Pod可用，并且最多同时运行4个Pod，这是Deployment通过复杂的算法完成的。 Recreate：设置spec.strategy.type=Recreate，表示Deployment在更新Pod时，会先杀掉所有正在运行的Pod，然后创建新的Pod。 一旦新的Pod创建并准备好，旧的ReplicaSet会进一步缩容，新的ReplicaSet又继续扩容。整个过程中系统在任意时刻都可以确保可用状态的Pod总数至少占Pod期望副本总数的70%。 spec.strategy.rollingUpdate.maxSurge：用于指定在Deployment更新Pod的过程中Pod总数超过Pod期望副本数部分的最大值。 该命令创建了一个新的RC，然后自动控制旧的RC中的Pod副本数量逐渐减少到0，同时新的RC中的Pod副本数量从0逐步增加到目标值，来完成Pod的升级。
77610发布于 2019-11-27 - 来自专栏木二天空
023.掌握Pod-Pod扩容和缩容
一 Pod的扩容和缩容 Kubernetes对Pod的扩缩容操作提供了手动和自动两种模式，手动模式通过执行kubectl scale命令或通过RESTful API对一个Deployment/RC进行Pod Pod的资源性能指标，并与HPA资源对象中的扩缩容条件进行对比，在满足条件时对Pod副本数量进行调整。 Pod自定义指标：Pod级别的性能指标，通常是一个数值，例如接收的请求数量。 此外，存在几种Pod异常的如下情况： Pod正在被删除（设置了删除时间戳）：将不会计入目标Pod副本数量。 Pod的当前指标值无法获得：本次探测不会将这个Pod纳入目标Pod副本数量，后续的探测会被重新纳入计算范围。
1.5K30发布于 2019-11-27
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号