Kubernetes资源对象之Pod

2017-01-15 阅读: Kubernetes

Pod基本概念

Pod是Kubernetes集群中最基本的资源对象。每个Pod由一个或多个业务容器和一个根容器(Pause容器)组成。

Kubernetes为每个Pod分配了唯一的IP,即Pod IP,Pod里的多个容器共享这个IP。

kubectl get pods -o wide --all-namespaces | grep dashboard
kube-system   kubernetes-dashboard-3109525988-5vnpv   1/1       Running   1          7h        10.244.0.8       cent0

实际上一个Pod内的多个容器共享相同的网络命名空间、IP、端口,也就是说这些容器之间能通过localhost来通信,此外这些容器还可以共享相同存储卷。

通过使用虚拟二层网络技术(如flannel),Kubernetes集群底层网络支持一个Pod内容器和另外一个Node上Pod内容器之间的TCP/IP通信。

关于Pod的yaml详细定义参考resources-reference Pod v1。 Pod创建成功后,就会被持久化到etcd中,Master节点会把Pod调度到某个具体的Node上,并由该Node上的kubelet进程启动相关的Docker容器。 如果Pod中的容器停止时,Kubernetes会重新启动这个Pod,Pod所在Node节点宕机,则这个Node上的所有Pod会被调度到其他Node上。

apiVersion: v1
kind: Pod
metadata:
  name: pod-example
spec:
  containers:
  - image: ubuntu:trusty
    command: ["echo"]
    args: ["Hello World"]

计算资源限额

可以为Pod内容器设置计算资源限额。 Kubernetes当前支持对CPU核的数量和内存大小两种资源设置限额。

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: db
    image: mysql
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
  - name: wp
    image: wordpress
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

spec.containers.resources.requests表示该资源的最小申请量,即Pod容器启动时必须满足的,spec.containers.resources.limits表示该资源最大允许的数量,当Pod内容器使用超过这个量时会被Kubernetes杀掉并重启。 上面的定义mysql容器申请0.25个CPU及64MB内存,运行过程中不超过0.5个CPU和128MB内存。

容器健康检查

Pod通过LivenessProbe和ReadinessProbe两种探针来检查容器的健康状态:

  • LivenessProbe 用于判断容器是否健康,如果LivenessProbe探测到容器不健康,kubelet将删除该容器并根据容器的重启策略做相应的处理。如果容器不包含LivenessProbe,则kubelet认为该容器的LivenessProbe探针永远返回success。
  • ReadinessProbe 用于判断容器是否启动完成且准备接收请求。如果该探针探测到失败,则Endpoint Controller将会从Service的Endpoint中删除包含该容器Pod的条目。

Kubelet定期调用容器中的LivenessProbe针来检查容器的健康状态。

关于探针的配置参考这里Configuring Liveness and Readiness Probes

如HttpGetAction探针:

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:

  - name: liveness

    args:
    - /server

    image: gcr.io/google_containers/liveness

    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
        httpHeaders:
          - name: X-Custom-Header
            value: Awesome
      initialDelaySeconds: 3
      periodSeconds: 3

静态Pod

静态Pod是一种特殊的Pod,由kubelet进程直接管理,仅存在于特定Node上。 静态Pod不会被存储到Kubernetes集群的持久化存储etcd中,而是被保存在某个具体Node上的某个目录中的文件内。

静态Pod的定义文件的存储位置可以在启动kubelet时通过–pod-manifest-path=参数指定。 Kubelet进程会定时扫描这个目录,根据该目录中的.yaml和.json文件进行创建。静态Pod无法通过kube-apiserver直接管理。 使用ps命令在Master节点上查看kubelet进程:

ps -ef | grep kubelet
root      2093     1  6 18:27 ?        00:08:31 /usr/bin/kubelet --kubeconfig=/etc/kubernetes/kubelet.conf --require-kubeconfig=true --pod-manifest-path=/etc/kubernetes/manifests --allow-privileged=true --network-plugin=cni --cni-conf-dir=/etc/cni/net.d --cni-bin-dir=/opt/cni/bin --cluster-dns=10.96.0.10 --cluster-domain=cluster.local

可以看到--pod-manifest-path=/etc/kubernetes/manifests

cd /etc/kubernetes/manifests
ls
etcd.json  kube-apiserver.json  kube-controller-manager.json  kube-scheduler.json

可以看到使用kubeadm init创建的Kubernetes集群,Master节点上的etcd, kube-apiserver, kube-controller-manager, kube-scheduler这些Pod都是静态Pod。

参考

标题:Kubernetes资源对象之Pod
本文链接:https://blog.frognew.com/2017/01/kubernetes-pods.html
转载请注明出处。

目录