什么是Pod

一个Pod(就像一群鲸鱼,或者一个豌豆夹)相当于一个共享context的配置组,在同一个context下,应用可能还会有独立的cgroup隔离机制,一个Pod是一个容器环境下的“逻辑主机”,它可能包含一个或者多个紧密相连的应用,这些应用可能是在同一个物理主机或虚拟机上。

Pod 的context可以理解成多个linux命名空间的联合

  • PID 命名空间(同一个Pod中应用可以看到其它进程)
  • 网络 命名空间(同一个Pod的中的应用对相同的IP地址和端口有权限)
  • IPC 命名空间(同一个Pod中的应用可以通过VPC或者POSIX进行通信)
  • UTS 命名空间(同一个Pod中的应用共享一个主机名称)

同一个Pod中的应用可以共享磁盘,磁盘是Pod级的,应用可以通过文件系统调用,额外的,一个Pod可能会定义顶级的cgroup隔离,这样的话绑定到任何一个应用(好吧,这句是在没怎么看懂,就是说Pod,应用,隔离)

由于docker的架构,一个Pod是由多个相关的并且共享磁盘的容器组成,Pid的命名空间共享还没有应用到Docker中

和相互独立的容器一样,Pod是一种相对短暂的存在,而不是持久存在的,正如我们在Pod的生命周期中提到的,Pod被安排到结点上,并且保持在这个节点上直到被终止(根据重启的设定)或者被删除,当一个节点死掉之后,上面的所有Pod均会被删除。特殊的Pod永远不会被转移到的其他的节点,作为替代,他们必须被replace.

Pod的发展

资源的共享及通信

Pod使Pod内的数据共享及通信变得容易

Pod的中的应用均使用相同的网络命名空间及端口,并且可以通过localhost发现并沟通其他应用,每个Pod都有一个扁平化的网络命名空间下IP地址,它是Pod可以和其他的物理机及其他的容器进行无障碍通信,(The hostname is set to the pod’s Name for the application containers within the pod)主机名被设置为Pod的名称(这个没翻译出来…)

除了定义了在Pod中运行的应用之外,Pod还定义了一系列的共享的磁盘,磁盘让这些数据在容器重启的时候不回丢失并且可以将这些数据在Pod中的应用进行共享

管理

Pod通过提供一个高层次抽象而不是底层的接口简化了应用的部署及管理,Pod 作为最小的部署及管理单位,位置管理,拷贝复制,资源共享,依赖关系都是自动处理的。(fate sharing估计就说什么时候该死了,什么时候该新增一个了…)

Pod的使用

Pod可以作为垂直应用整合的载体,但是它的主要特点是支持同地协作,同地管理程序,例如:

  • 内容管理系统,文件和数据加载,本地缓存等等
  • 日志和检查点备份,压缩,循环,快照等等
  • 数据交换监控,日志追踪,日志记录和监控适配器,以及事件发布等等
  • 代理,网桥,适配器
  • 控制,管理,配置,更新

总体来说,独立的Pod不会去加载多个相同的应用实例

考虑过的其他方案

为什么不直接在一个容器上运行所有的应用?

  1. 透明,Pod中的容器对基础设施可见使的基础设施可以给容器提供服务,例如线程管理和资源监控,这为用户提供很多便利
  2. 解耦软件依赖关系,独立的容器可以独立的进行重建和重新发布,Kubernetes 甚至会在将来支持独立容器的实时更新
  3. 易用,用户不需要运行自己的线程管理器,也不需要关心程序的信号以及异常结束码等
  4. 高效,因为基础设施承载了更多的责任,所以容器可以更加高效

为什么不支持容器的协同调度

容器的协同调度可以提供,但是它不具备Pod的大多数优点,比如资源共享,IPC,选择机制,简单管理等

Pod的持久性

Pod并不是被设计成一个持久化的资源,它不会在调度失败,节点崩溃,或者其他回收中(比如因为资源的缺乏,或者其他的维护中)幸存下来

总体来说,用户因该直接去创建Pod,并且一直使用controller(replication controller),即使是一个节点的情况,这是因为controller提供了集群范围内的自我修复,以及复制还有展示管理

集群API的使用是用户的主要使用方式,这是相对普遍的在如下云管理平台中( Borg, Marathon, Aurora, and Tupperware.)

Pod的直接暴露是如下操作变得更容器

  1. 调度和管理的易用性
  2. 在没有代理的情况下通过API可以对Pod进行操作
  3. Pod的生命周期与管理器的生命周期的分离
  4. 解偶控制器和服务,后段管理器仅仅监控Pod
  5. 划分清楚了Kubelet级别的功能与云平台级别的功能,kubelet 实际上是一个Pod管理器
  6. 高可用,当发生一些删除或者维护的过程时,Pod会自动的在他们被终止之前创建新的替代

目前对于宠物的最佳实践是,创建一个副本等于1和有对应service的一个replication控制器。如果你觉得这太麻烦,请在这里留下你的意见。

容器的终止

因为pod代表着一个集群中节点上运行的进程,让这些进程不再被需要,优雅的退出是很重要的(与粗暴的用一个KILL信号去结束,让应用没有机会进行清理操作)。用户应该能请求删除,并且在室进程终止的情况下能知道,而且也能保证删除最终完成。当一个用户请求删除pod,系统记录想要的优雅退出时间段,在这之前Pod不允许被强制的杀死,TERM信号会发送给容器主要的进程。一旦优雅退出的期限过了,KILL信号会送到这些进程,pod会从API服务器其中被删除。如果在等待进程结束的时候,Kubelet或者容器管理器重启了,结束的过程会带着完整的优雅退出时间段进行重试。

一个示例流程:

1. 用户发送一个命令来删除Pod,默认的优雅退出时间是30秒

2. API服务器中的Pod更新时间,超过该时间Pod被认为死亡

3. 在客户端命令的的里面,Pod显示为”Terminating(退出中)”的状态

4. (与第3同时)当Kubelet看到Pod标记为退出中的时候,因为第2步中时间已经设置了,它开始pod关闭的流程

i. 如果该Pod定义了一个停止前的钩子,其会在pod内部被调用。如果钩子在优雅退出时间段超时仍然在运行,第二步会意一个很小的优雅时间断被调用

ii. 进程被发送TERM的信号

5. (与第三步同时进行)Pod从service的列表中被删除,不在被认为是运行着的pod的一部分。缓慢关闭的pod可以继续对外服务,当负载均衡器将他们轮流移除。

6. 当优雅退出时间超时了,任何pod中正在运行的进程会被发送SIGKILL信号被杀死。

7. Kubelet会完成pod的删除,将优雅退出的时间设置为0(表示立即删除)。pod从API中删除,不在对客户端可见。

默认情况下,所有的删除操作的优雅退出时间都在30秒以内。kubectl delete命令支持–graceperiod=的选项,以运行用户来修改默认值。0表示删除立即执行,并且立即从API中删除pod这样一个新的pod会在同时被创建。在节点上,被设置了立即结束的的pod,仍然会给一个很短的优雅退出时间段,才会开始被强制杀死。

使用Volume

Volume可以为容器提供持久化存储,比如

  1. apiVersion: v1
  2. kind: Pod
  3. metadata:
  4. name: redis
  5. spec:
  6. containers:
  7. - name: redis
  8. image: redis
  9. volumeMounts:
  10. - name: redis-storage
  11. mountPath: /data/redis
  12. volumes:
  13. - name: redis-storage
  14. emptyDir: {}

私有镜像

在使用私有镜像时,需要创建一个docker registry secret,并在容器中引用。

创建docker registry secret:

  1. kubectl create secret docker-registry regsecret --docker-server=<your-registry-server> --docker-username=<your-name> --docker-password=<your-pword> --docker-email=<your-email>

容器中引用该secret:

  1. apiVersion: v1
  2. kind: Pod
  3. metadata:
  4. name: private-reg
  5. spec:
  6. containers:
  7. - name: private-reg-container
  8. image: <your-private-image>
  9. imagePullSecrets:
  10. - name: regsecret

RestartPoliy

支持三种RestartPolicy

  • Always:只要退出就重启
  • OnFailure:失败退出(exit code不等于0)时重启
  • Never:只要退出就不再重启

注意,这里的重启是指在Pod所在Node上面本地重启,并不会调度到其他Node上去。

环境变量

环境变量为容器提供了一些重要的资源,包括容器和Pod的基本信息以及集群中服务的信息等:

(1) hostname

HOSTNAME环境变量保存了该Pod的hostname。

(2)容器和Pod的基本信息

Pod的名字、命名空间、IP以及容器的计算资源限制等可以以Downward API的方式获取并存储到环境变量中。

  1. apiVersion: v1
  2. kind: Pod
  3. metadata:
  4. name: test
  5. spec:
  6. containers:
  7. - name: test-container
  8. image: gcr.io/google_containers/busybox
  9. command: [ "sh", "-c"]
  10. args:
  11. - env
  12. resources:
  13. requests:
  14. memory: "32Mi"
  15. cpu: "125m"
  16. limits:
  17. memory: "64Mi"
  18. cpu: "250m"
  19. env:
  20. - name: MY_NODE_NAME
  21. valueFrom:
  22. fieldRef:
  23. fieldPath: spec.nodeName
  24. - name: MY_POD_NAME
  25. valueFrom:
  26. fieldRef:
  27. fieldPath: metadata.name
  28. - name: MY_POD_NAMESPACE
  29. valueFrom:
  30. fieldRef:
  31. fieldPath: metadata.namespace
  32. - name: MY_POD_IP
  33. valueFrom:
  34. fieldRef:
  35. fieldPath: status.podIP
  36. - name: MY_POD_SERVICE_ACCOUNT
  37. valueFrom:
  38. fieldRef:
  39. fieldPath: spec.serviceAccountName
  40. - name: MY_CPU_REQUEST
  41. valueFrom:
  42. resourceFieldRef:
  43. containerName: test-container
  44. resource: requests.cpu
  45. - name: MY_CPU_LIMIT
  46. valueFrom:
  47. resourceFieldRef:
  48. containerName: test-container
  49. resource: limits.cpu
  50. - name: MY_MEM_REQUEST
  51. valueFrom:
  52. resourceFieldRef:
  53. containerName: test-container
  54. resource: requests.memory
  55. - name: MY_MEM_LIMIT
  56. valueFrom:
  57. resourceFieldRef:
  58. containerName: test-container
  59. resource: limits.memory
  60. restartPolicy: Never

(3) 集群中服务的信息

容器的环境变量中还包括了容器运行前创建的所有服务的信息,比如默认的kubernetes服务对应了环境变量

  1. KUBERNETES_PORT_443_TCP_ADDR=10.0.0.1
  2. KUBERNETES_SERVICE_HOST=10.0.0.1
  3. KUBERNETES_SERVICE_PORT=443
  4. KUBERNETES_SERVICE_PORT_HTTPS=443
  5. KUBERNETES_PORT=tcp://10.0.0.1:443
  6. KUBERNETES_PORT_443_TCP=tcp://10.0.0.1:443
  7. KUBERNETES_PORT_443_TCP_PROTO=tcp
  8. KUBERNETES_PORT_443_TCP_PORT=443

由于环境变量存在创建顺序的局限性(环境变量中不包含后来创建的服务),推荐使用DNS来解析服务。

ImagePullPolicy

支持三种ImagePullPolicy

  • Always:不管镜像是否存在都会进行一次拉取。
  • Never:不管镜像是否存在都不会进行拉取
  • IfNotPresent:只有镜像不存在时,才会进行镜像拉取。

注意:

  • 默认为IfNotPresent,但:latest标签的镜像默认为Always
  • 拉取镜像时docker会进行校验,如果镜像中的MD5码没有变,则不会拉取镜像数据。
  • 生产环境中应该尽量避免使用:latest标签,而开发环境中可以借助:latest标签自动拉取最新的镜像。

资源限制

Kubernetes通过cgroups限制容器的CPU和内存等计算资源,包括requests(请求,调度器保证调度到资源充足的Node上)和limits(上限)等:

  • spec.containers[].resources.limits.cpu:CPU上限,可以短暂超过,容器也不会被停止
  • spec.containers[].resources.limits.memory:内存上限,不可以超过;如果超过,容器可能会被停止或调度到其他资源充足的机器上
  • spec.containers[].resources.requests.cpu:CPU请求,可以超过
  • spec.containers[].resources.requests.memory:内存请求,可以超过;但如果超过,容器可能会在Node内存不足时清理

比如nginx容器请求30%的CPU和56MB的内存,但限制最多只用50%的CPU和128MB的内存:

  1. apiVersion: v1
  2. kind: Pod
  3. metadata:
  4. labels:
  5. app: nginx
  6. name: nginx
  7. spec:
  8. containers:
  9. - image: nginx
  10. name: nginx
  11. resources:
  12. requests:
  13. cpu: "300m"
  14. memory: "56Mi"
  15. limits:
  16. cpu: "500m"
  17. memory: "128Mi"

注意,CPU的单位是milicpu,500mcpu=0.5cpu;而内存的单位则包括E, P, T, G, M, K, Ei, Pi, Ti, Gi, Mi, Ki等。

健康检查

为了确保容器在部署后确实处在正常运行状态,Kubernetes提供了两种探针(Probe,支持exec、tcp和httpGet方式)来探测容器的状态:

  • LivenessProbe:探测应用是否处于健康状态,如果不健康则删除重建改容器
  • ReadinessProbe:探测应用是否启动完成并且处于正常服务状态,如果不正常则更新容器的状态
  1. apiVersion: v1
  2. kind: Pod
  3. metadata:
  4. labels:
  5. app: nginx
  6. name: nginx
  7. spec:
  8. containers:
  9. - image: nginx
  10. imagePullPolicy: Always
  11. name: http
  12. livenessProbe:
  13. httpGet:
  14. path: /
  15. port: 80
  16. initialDelaySeconds: 15
  17. timeoutSeconds: 1
  18. readinessProbe:
  19. httpGet:
  20. path: /ping
  21. port: 80
  22. initialDelaySeconds: 5
  23. timeoutSeconds: 1

Init Container

Init Container在所有容器运行之前执行(run-to-completion),常用来初始化配置。

  1. apiVersion: v1
  2. kind: Pod
  3. metadata:
  4. name: init-demo
  5. spec:
  6. containers:
  7. - name: nginx
  8. image: nginx
  9. ports:
  10. - containerPort: 80
  11. volumeMounts:
  12. - name: workdir
  13. mountPath: /usr/share/nginx/html
  14. # These containers are run during pod initialization
  15. initContainers:
  16. - name: install
  17. image: busybox
  18. command:
  19. - wget
  20. - "-O"
  21. - "/work-dir/index.html"
  22. - http://kubernetes.io
  23. volumeMounts:
  24. - name: workdir
  25. mountPath: "/work-dir"
  26. dnsPolicy: Default
  27. volumes:
  28. - name: workdir
  29. emptyDir: {}

容器生命周期钩子

容器生命周期钩子(Container Lifecycle Hooks)监听容器生命周期的特定事件,并在事件发生时执行已注册的回调函数。支持两种钩子:

  • postStart: 容器启动后执行,注意由于是异步执行,它无法保证一定在ENTRYPOINT之后运行。如果失败,容器会被杀死,并根据RestartPolicy决定是否重启
  • preStop:容器停止前执行,常用于资源清理。如果失败,容器同样也会被杀死

而钩子的回调函数支持两种方式:

  • exec:在容器内执行命令
  • httpGet:向指定URL发起GET请求

postStart和preStop钩子示例:

  1. apiVersion: v1
  2. kind: Pod
  3. metadata:
  4. name: lifecycle-demo
  5. spec:
  6. containers:
  7. - name: lifecycle-demo-container
  8. image: nginx
  9. lifecycle:
  10. postStart:
  11. exec:
  12. command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"]
  13. preStop:
  14. exec:
  15. command: ["/usr/sbin/nginx","-s","quit"]

指定Node

通过nodeSelector,一个Pod可以指定它所想要运行的Node节点。

首先给Node加上标签:

  1. kubectl label nodes <your-node-name> disktype=ssd

接着,指定该Pod只想运行在带有disktype=ssd标签的Node上:

  1. apiVersion: v1
  2. kind: Pod
  3. metadata:
  4. name: nginx
  5. labels:
  6. env: test
  7. spec:
  8. containers:
  9. - name: nginx
  10. image: nginx
  11. imagePullPolicy: IfNotPresent
  12. nodeSelector:
  13. disktype: ssd

使用Capabilities

默认情况下,容器都是以非特权容器的方式运行。比如,不能在容器中创建虚拟网卡、配置虚拟网络。

Kubernetes提供了修改Capabilities的机制,可以按需要给给容器增加或删除。比如下面的配置给容器增加了CAP_NET_ADMIN并删除了CAP_KILL

  1. apiVersion: v1
  2. kind: Pod
  3. metadata:
  4. name: hello-world
  5. spec:
  6. containers:
  7. - name: friendly-container
  8. image: "alpine:3.4"
  9. command: ["/bin/echo", "hello", "world"]
  10. securityContext:
  11. capabilities:
  12. add:
  13. - NET_ADMIN
  14. drop:
  15. - KILL

限制网络带宽

可以通过给Pod增加kubernetes.io/ingress-bandwidthkubernetes.io/egress-bandwidth这两个annotation来限制Pod的网络带宽

  1. apiVersion: v1
  2. kind: Pod
  3. metadata:
  4. name: qos
  5. annotations:
  6. kubernetes.io/ingress-bandwidth: 3M
  7. kubernetes.io/egress-bandwidth: 4M
  8. spec:
  9. containers:
  10. - name: iperf3
  11. image: networkstatic/iperf3
  12. command:
  13. - iperf3
  14. - -s

仅kubenet支持限制带宽

目前只有kubenet网络插件支持限制网络带宽,其他CNI网络插件暂不支持这个功能。

kubenet的网络带宽限制其实是通过tc来实现的

  1. # setup qdisc (only once)
  2. tc qdisc add dev cbr0 root handle 1: htb default 30
  3. # download rate
  4. tc class add dev cbr0 parent 1: classid 1:2 htb rate 3Mbit
  5. tc filter add dev cbr0 protocol ip parent 1:0 prio 1 u32 match ip dst 10.1.0.3/32 flowid 1:2
  6. # upload rate
  7. tc class add dev cbr0 parent 1: classid 1:3 htb rate 4Mbit
  8. tc filter add dev cbr0 protocol ip parent 1:0 prio 1 u32 match ip src 10.1.0.3/32 flowid 1:3

调度到指定的Node上

可以通过nodeSelector、nodeAffinity、podAffinity以及Taints和tolerations等来将Pod调度到需要的Node上。

K8S中Pods的更多相关文章

  1. k8s中yaml文常见语法

    在k8s中,所有的配置都是 json格式的.但为了读写方便,通常将这些配置写成yaml 格式,其运行的时候,还是会靠yaml引擎将其转化为json,apiserver 也仅接受json的数据类型. y ...

  2. 新版的K8S中的flannel.yaml文件中要注意的细节

    部署flannel作为k8s中的网络插件,yaml文件都大小同异. 但在要注意以下细节. 以前,只需要前面master判断. 现在也需要有not-ready状态了. tolerations: - ke ...

  3. 转 docker创建私有仓库和k8s中使用私有镜像

    docker私有仓库建立 环境说明我们选取192.168.5.2做私有仓库地址yum install docker -y1.启动docker仓库端口服务 docker run -d -p 5000:5 ...

  4. 在k8s中搭建可解析hostname的DNS服务

    2016-01-25更新 上篇文章总结k8s中搭建hbase时,遇到Pod中hostname的DNS解析问题,本篇将通过修改kube2sky源码来解决这个问题. 1 前言 kube2sky在Githu ...

  5. 在k8s中的基本概念

    在k8s中的基本概念 一.Pod1. podk8s下最重要也最基本的概念,由一个根容器Pause和许多用户业务容器组成,是容器的载体. 2. pod的yaml定义格式及字段 apiVersion: v ...

  6. 查看k8s中etcd数据

    #查看etcd pod kubectl get pod -n kube-system | grep etcd #进入etcd pod kubectl exec -it -n kube-system e ...

  7. Prometheus K8S中部署Alertmanager

    Prometheus K8S中部署Alertmanager 设置告警和通知的主要步骤如下:一.部署Alertmanager二.配置Prometheus与Alertmanager通信三.配置告警 1. ...

  8. K8s中的网络

    Kubernetes的网络通信问题: 1. 容器间通信: 即同一个Pod内多个容器间通信,通常使用loopback来实现. 2. Pod间通信: K8s要求,Pod和Pod之间通信必须使用Pod-IP ...

  9. Kubernetes之在k8s中部署Java应用

    部署好了k8s以后 部署参考https://www.cnblogs.com/minseo/p/12055731.html 怎么在k8s部署应用 项目迁移到k8s平台是怎样的流程 1,制作镜像 2,控制 ...

随机推荐

  1. 自动化测试之if __name__ == '__main__'未运行

    自动化测试之if __name__ == '__main__'未运行 添加Count类 calculator.py: class Count: def __init__(self,a,b): self ...

  2. (十一)Activitivi5之流程控制网关:连线

    一.案例 1.1 需求 我们希望如果是重要情况才需要班主任审批,否则班长审批就行. 1.2 案例 当流程走到“班长审批”任务节点的时候,如果是一般情况,则如下: /** * 完成任务 */ @Test ...

  3. Q-Dir

    Q-dir,可以分界面,分文件夹,快捷选择等优势,非常好用的工具,可以替代微软的File Explorer. 官网:https://www.softwareok.com/?seite=Freeware ...

  4. 使用zrender.js绘制体温单(1)

    之前公司请外包做了一个体温单使用的zrender.js 但是代码比较复杂维护性比较低再加上自己技术也不行 最近闲下来的时候看了一下zrender的官网慢慢的摸索并读了下之前的代码,感觉实际并不难,就自 ...

  5. 安装theano踩过的坑(gpu)

    参考 http://deeplearning.net/software/theano/install.html TensorFlow出了点问题 python3.7的环境 pip安装 keras已经安装 ...

  6. 同一个url对应多个视图函数,取第一个视图函数有效

    # -*- coding: utf-8 -*- from flask import Flask app = Flask(__name__) @app.route('/') def index(): r ...

  7. [Vue warn]: Duplicate keys detected: '0'. This may cause an update error.

    1.[Vue warn]: Duplicate keys detected: '0'. This may cause an update error. 第一眼看到这个错误一脸懵逼,项目使用很久了,代码 ...

  8. linux命令详解——eval

    shell中的eval 功能说明:重新运算求出参数的内容. 语 法:eval [参数] 补充说明:eval可读取一连串的参数,然后再依参数本身的特性来执行. 参 数:参数不限数目,彼此之间用分号分开. ...

  9. 异常-Exception in thread "main" net.sf.jsqlparser.parser.TokenMgrError: Lexical error at line 1, column 596. Encountered: <EOF> after :

    1 详细异常 Exception in thread "main" net.sf.jsqlparser.parser.TokenMgrError: Lexical error at ...

  10. (转载)小白的linux设备驱动归纳总结(一):内核的相关基础概念---学习总结

    1. 学习总结 小白的博客讲的linux内核驱动这一块的东西比较基础,因此想通过学习他的博客,搭配着看书的方式来学习linux内核和驱动.我会依次更新在学习小白的博客的过程的感悟和体会. 2.1 内核 ...