Pods are the smallest deployable units of computing that can be created and managed in Kubernetes.

What is a Pod?

pod (as in a pod of whales or pea pod) is a group of one or more containers (such as Docker containers), with shared storage/network, and a specification for how to run the containers. A pod’s contents are always co-located and co-scheduled, and run in a shared context. A pod models an application-specific “logical host” - it contains one or more application containers which are relatively tightly coupled — in a pre-container world, they would have executed on the same physical or virtual machine.

While Kubernetes supports more container runtimes than just Docker, Docker is the most commonly known runtime, and it helps to describe pods in Docker terms.

The shared context of a pod is a set of Linux namespaces, cgroups, and potentially other facets of isolation - the same things that isolate a Docker container. Within a pod’s context, the individual applications may have further sub-isolations applied.

Containers within a pod share an IP address and port space, and can find each other via localhost. They can also communicate with each other using standard inter-process communications like SystemV semaphores or POSIX shared memory. Containers in different pods have distinct IP addresses and can not communicate by IPC without special configuration. These containers usually communicate with each other via Pod IP addresses.

一个Pod中的容器共享IP地址和端口空间,可以使用localhost通信。还可以使用标准inter-process 通信,比如System V semaphores或POSIX共享内存。不同Pods上的容器的IP地址不同,不能直接用IPC通信,除非进行特殊设置。这些容器可以使用Pod IP地址通信。

Applications within a pod also have access to shared volumes, which are defined as part of a pod and are made available to be mounted into each application’s filesystem.

In terms of Docker constructs, a pod is modelled as a group of Docker containers with shared namespaces and shared volumes.

Like individual application containers, pods are considered to be relatively ephemeral (rather than durable) entities. As discussed in life of a pod, pods are created, assigned a unique ID (UID), and scheduled to nodes where they remain until termination (according to restart policy) or deletion. If a node dies, the pods scheduled to that node are scheduled for deletion, after a timeout period. A given pod (as defined by a UID) is not “rescheduled” to a new node; instead, it can be replaced by an identical pod, with even the same name if desired, but with a new UID (see replication controller for more details).

When something is said to have the same lifetime as a pod, such as a volume, that means that it exists as long as that pod (with that UID) exists. If that pod is deleted for any reason, even if an identical replacement is created, the related thing (e.g. volume) is also destroyed and created anew.

Pod内的所有应用都可以使用共享volumes,共享volumes是作为Pod的一部分,每个应用的文件系统上都被挂载了。

以Docker为例,pod作为docker容器的模型,共享了namespaces和shared volumes。

每个Pod在被创建时,都被赋值了一个unique ID(UID)

如果说某个东西的生命周期和pod相同,比如volume,意思是只要pod存在,这个东西就存在。如果pod被删除了,即使出现了相同的替代pod,这个东西也会被消耗重建。

A multi-container pod that contains a file puller and a web server that uses a persistent volume for shared storage between the containers.

闪图是一个多容器pod,包含一个file puller和一个web server,在容器之间使用persistent volume用来共享存储。

Motivation for pods

Management

Pods are a model of the pattern of multiple cooperating processes which form a cohesive unit of service. They simplify application deployment and management by providing a higher-level abstraction than the set of their constituent applications. Pods serve as unit of deployment, horizontal scaling, and replication. Colocation (co-scheduling), shared fate (e.g. termination), coordinated replication, resource sharing, and dependency management are handled automatically for containers in a pod.

Pod是一种将多个相互协作的进程组成聚合的服务单元的模型,通过提供对多个应用的多个抽象,简化了应用的部署和管理。Pod是作为部署、水平扩展、副本的管理单元。Pod中的多个容器相互写作、共享生命周期、副本一致、资源共享、依赖管理等功能都是自动由Pod管理的。

Resource sharing and communication

Pods enable data sharing and communication among their constituents.

The applications in a pod all use the same network namespace (same IP and port space), and can thus “find” each other and communicate using localhost. Because of this, applications in a pod must coordinate their usage of ports. Each pod has an IP address in a flat shared networking space that has full communication with other physical computers and pods across the network.

The hostname is set to the pod’s Name for the application containers within the pod. More details on networking.

In addition to defining the application containers that run in the pod, the pod specifies a set of shared storage volumes. Volumes enable data to survive container restarts and to be shared among the applications within the pod.

Pod中的多个应用共享数据和通信资源。

一个Pod中的所有应用使用相同的网络空间(IP和port域),可以使用localhost相互通信。因此一个pod中的应用必须协商ports的使用。每个pod都有一个IP地址,可以与网络中的其他物理机和pods相互通信。

pod的hostname就是pod的名称。

pod可以设置一些shared storage volumnes,允许容器重启后读取服务,容器间共享数据。

Uses of pods

Pods can be used to host vertically integrated application stacks (e.g. LAMP), but their primary motivation is to support co-located, co-managed helper programs, such as:

  • content management systems, file and data loaders, local cache managers, etc.
  • log and checkpoint backup, compression, rotation, snapshotting, etc.
  • data change watchers, log tailers, logging and monitoring adapters, event publishers, etc.
  • proxies, bridges, and adapters
  • controllers, managers, configurators, and updaters

Individual pods are not intended to run multiple instances of the same application, in general.

For a longer explanation, see The Distributed System ToolKit: Patterns for Composite Containers.

Alternatives considered

Why not just run multiple programs in a single (Docker) container?

  1. Transparency. Making the containers within the pod visible to the infrastructure enables the infrastructure to provide services to those containers, such as process management and resource monitoring. This facilitates a number of conveniences for users.
  2. Decoupling software dependencies. The individual containers may be versioned, rebuilt and redeployed independently. Kubernetes may even support live updates of individual containers someday.
  3. Ease of use. Users don’t need to run their own process managers, worry about signal and exit-code propagation, etc.
  4. Efficiency. Because the infrastructure takes on more responsibility, containers can be lighter weight.

Why not support affinity-based co-scheduling of containers?

That approach would provide co-location, but would not provide most of the benefits of pods, such as resource sharing, IPC, guaranteed fate sharing, and simplified management.

Durability of pods (or lack thereof)

Pods aren’t intended to be treated as durable entities. They won’t survive scheduling failures, node failures, or other evictions, such as due to lack of resources, or in the case of node maintenance.

In general, users shouldn’t need to create pods directly. They should almost always use controllers even for singletons, for example, Deployments). Controllers provide self-healing with a cluster scope, as well as replication and rollout management. Controllers like StatefulSet can also provide support to stateful pods.

The use of collective APIs as the primary user-facing primitive is relatively common among cluster scheduling systems, including BorgMarathonAurora, and Tupperware.

Pod is exposed as a primitive in order to facilitate:

  • scheduler and controller pluggability,可以插拔性地实现调度器和控制器
  • support for pod-level operations without the need to “proxy” them via controller APIs,支持pod-level的操作,不需要使用控制器的API。
  • decoupling of pod lifetime from controller lifetime, such as for bootstrapping,将pod的生命周期与controller的生命周期解耦,例如引导程序
  • decoupling of controllers and services — the endpoint controller just watches pods,结构控制器和service,endpoint controller只会监控pods。
  • clean composition of Kubelet-level functionality with cluster-level functionality — Kubelet is effectively the “pod controller”
  • high-availability applications, which will expect pods to be replaced in advance of their termination and certainly in advance of deletion, such as in the case of planned evictions or image prefetching.实现高可靠的应用,希望在终止和删除Pod之前,创建替代的pod,例如计划好的清除或镜像预读取。

Termination of Pods

Because pods represent running processes on nodes in the cluster, it is important to allow those processes to gracefully terminate when they are no longer needed (vs being violently killed with a KILL signal and having no chance to clean up). Users should be able to request deletion and know when processes terminate, but also be able to ensure that deletes eventually complete. When a user requests deletion of a pod the system records the intended grace period before the pod is allowed to be forcefully killed, and a TERM signal is sent to the main process in each container. Once the grace period has expired the KILL signal is sent to those processes and the pod is then deleted from the API server. If the Kubelet or the container manager is restarted while waiting for processes to terminate, the termination will be retried with the full grace period.

优雅地关闭pod,首先发送TERM信号,超过等待时间后发送KILL信号。

An example flow:

  1. User sends command to delete Pod, with default grace period (30s)
  2. The Pod in the API server is updated with the time beyond which the Pod is considered “dead” along with the grace period.
  3. Pod shows up as “Terminating” when listed in client commands
  4. (simultaneous with 3) When the Kubelet sees that a Pod has been marked as terminating because the time in 2 has been set, it begins the pod shutdown process.
    1. If the pod has defined a preStop hook, it is invoked inside of the pod. If the preStop hook is still running after the grace period expires, step 2 is then invoked with a small (2 second) extended grace period.
    2. The processes in the Pod are sent the TERM signal.
  5. (simultaneous with 3) Pod is removed from endpoints list for service, and are no longer considered part of the set of running pods for replication controllers. Pods that shutdown slowly can continue to serve traffic as load balancers (like the service proxy) remove them from their rotations.
  6. When the grace period expires, any processes still running in the Pod are killed with SIGKILL.
  7. The Kubelet will finish deleting the Pod on the API server by setting grace period 0 (immediate deletion). The Pod disappears from the API and is no longer visible from the client.

By default, all deletes are graceful within 30 seconds. The kubectl delete command supports the --grace-period=<seconds> option which allows a user to override the default and specify their own value. The value 0 force deletes the pod. In kubectl version >= 1.5, you must specify an additional flag --forcealong with --grace-period=0 in order to perform force deletions.

Force deletion of pods

Force deletion of a pod is defined as deletion of a pod from the cluster state and etcd immediately. When a force deletion is performed, the apiserver does not wait for confirmation from the kubelet that the pod has been terminated on the node it was running on. It removes the pod in the API immediately so a new pod can be created with the same name. On the node, pods that are set to terminate immediately will still be given a small grace period before being force killed.

Force deletions can be potentially dangerous for some pods and should be performed with caution. In case of StatefulSet pods, please refer to the task documentation for deleting Pods from a StatefulSet.

Privileged mode for pod containers

From Kubernetes v1.1, any container in a pod can enable privileged mode, using thprivileged flag on the SecurityContext of the container spec. This is useful for containers that want to use linux capabilities like manipulating the network stack and accessing devices. Processes within the container get almost the same privileges that are available to processes outside a container. With privileged mode, it should be easier to write network and volume plugins as separate pods that don’t need to be compiled into the kubelet.

可以操控网络堆栈、操作设备。容器中的进程几乎享有容器外进程的所有特权。单独的pod更容易地写入网络和卷

If the master is running Kubernetes v1.1 or higher, and the nodes are running a version lower than v1.1, then new privileged pods will be accepted by api-server, but will not be launched. They will be pending state. If user calls kubectl describe pod FooPodName, user can see the reason why the pod is in pending state. The events table in the describe command output will say: Error validating pod "FooPodName"."FooPodNamespace" from api, ignoring: spec.containers[0].securityContext.privileged: forbidden '<*>(0xc2089d3248)true'

如果master的版本高,但是node的版本低,使用特权模式的pods会处于pending状态。

If the master is running a version lower than v1.1, then privileged pods cannot be created. If user attempts to create a pod, that has a privileged container, the user will get the following error: The Pod "FooPodName" is invalid. spec.containers[0].securityContext.privileged: forbidden '<*>(0xc20b222db0)true'

如果master的版本低,特权pods创建时会报错。

API Object

Pod is a top-level resource in the Kubernetes REST API. More details about the API object can be found at: Pod API object.

kubernetes concepts -- Termination Of Pod的更多相关文章

  1. kubernetes concepts -- Pod Overview

    This page provides an overview of Pod, the smallest deployable object in the Kubernetes object model ...

  2. Kubernetes concepts 系列

    kubernetes concepts overview Pod overview Replication Controller Pod Liftcycle Termination Of Pod Re ...

  3. kubernetes进阶之三:Pod

    一:Pod 是什么 Pod是Kubernetes的最重要最基本的概念.它是能够被创建,调度和管理的最小部署单元.一个Pod代表集群中一个运行的进程. 二:Pod的组成 一个Pod由一个特殊的根容器Pa ...

  4. Kubernetes — 为什么我们需要Pod?

    不过,我相信你在学习和使用 Kubernetes 项目的过程中,已经不止一次地想要问这样一个问题:为什么我们会需要 Pod? 是啊,我们在前面已经花了很多精力去解读 Linux 容器的原理.分析了 D ...

  5. 三、Kubernetes之深入了解Pod

      1.yaml格式的Pod配置文件内容及注解 深入Pod之前,首先我们来了解下Pod的yaml整体文件内容及功能注解. 如下: # yaml格式的pod定义文件完整内容: apiVersion: v ...

  6. kubernetes之多容器pod以及通信

    系列目录 容器经常是为了解决单一的,窄范围的问题,比如说微服务.然而现实中,一些复杂问题的完成往往需要多个容器.这里我们讨论一下如何把多个容器放在同一个pod里以及容器间的通信 什么是pod pod是 ...

  7. Kubernetes 服务质量 Qos 解析 - Pod 资源 requests 和 limits 如何配置?

    QoS是 Quality of Service 的缩写,即服务质量.为了实现资源被有效调度和分配的同时提高资源利用率,kubernetes针对不同服务质量的预期,通过 QoS(Quality of S ...

  8. Kubernetes中强制删除Pod、namespace

    Kubernetes中强制删除Pod.namespace 解决方法 可使用kubectl中的强制删除命令 # 删除POD kubectl delete pod PODNAME --force --gr ...

  9. 基于Kubernetes的hpa实现pod实例数量的自动伸缩

    Pod 是在 Kubernetes 体系中,承载用户业务负载的一种资源.Pod 们运行的好坏,是用户们最为关心的事情.在业务流量高峰时,手动快速扩展 Pod 的实例数量,算是玩转 Kubernetes ...

随机推荐

  1. Anagram——[枚举全排列]

    预备知识: 1.求0—n个数全排列的算法: void print_permutation(int n,int *A,int cur){ if(cur==n){ ;i<cur;i++) cout& ...

  2. P1003 电影票价

    题目描述 已知一位小朋友的电影票价是10元,请问 \(n\) 位小朋友的总票价是多少? 输入格式 输入一个整数 \(n(1 \le n \le 1000)\) , 用于表示小朋友的数量. 输出格式 输 ...

  3. H3C IPv6地址构成

  4. 在小程序内点击按钮分享H5网页给好友或者朋友圈

    在小程序内点击按钮分享H5网页给好友或者朋友圈 首先需要建立h5容器文件夹 页面.wxml <navigator url="/pages/report-await/fouryearh5 ...

  5. java打包上传服务器的一些命令

    Maven下package打包成jar包和war包,都在target目录下 其中War包扔在tomcat的webapps目录下.随tomcat启动自行启动 运行jar包命令. nohup java - ...

  6. dotnet 获取程序所在路径的方法

    在 dotnet 有很多方法可以获取当前程序所在的路径,但是这些方法获取到的路径有一点不相同,特别是在工作路径不是当前的程序所在的路径的时候 通过下面几个方法都可以拿到程序所在的文件夹或程序文件 Ap ...

  7. 云栖大会压轴好戏 阿里云发布视频云V5计划与系列新产品

    9月25 - 27日,2019云栖大会如期召开.在大会最后一天下午,阿里云智能视频云分论坛为今年的云栖大会献上了一场精彩的压轴好戏. 视频云V5计划发布 使能生态合作伙伴 会上,阿里云智能研究员金戈进 ...

  8. boostrap-非常好用但是容易让人忽略的地方【6】:role属性

    普通样式,鼠标hover没有任何效果 <span>content</span> 加上role属性的样式,鼠标hover会有cursor:pointer的效果 <span ...

  9. Qt串行化的输入和输出(使用QDataStream读写QByteArray,对QIODevice直接起作用)

    参考https://lug.ustc.edu.cn/sites/qtguide/ 今天看了一个介绍Qt串行化的介绍,感觉很受益,就记录了下来. 串行化(Serialization)是计算机科学中的一个 ...

  10. lnmp一键安装,安装php时失败

    查看安装日志 直接cd进入根目录报错内容:configure: error: mcrypt.h not found. Please reinstall libmcrypt 解决办法如下#使用wget可 ...