2020-07-31 深入理解Pod对象

1. Pod基本概念

  • pod是kubernetes最基本的执行单元(最小、最简单的单元),pod表示在集群上运行的进程。
  • pod封装了应用程序容器(某些情况下多个容器),存储资源、唯一网络IP、以及控制器该如何运行的选项。
    • 运行单个容器的pod:一个pod运行一个容器是kubernetes最常见的。
    • 运行多个容器的pod:pod可能封装多个紧密耦合且需要共享资源的共处容器组成的应用程序。
  • 如果希望横向扩展应用程序,则应该使用多个pod,在kubernetes中,称为副本。
  • Pod是短暂的。
  • 每个pod分配一个唯一的IP地址,pod的每个容器共享网络命名空间。包括IP地址和端口。pod内的容器可以使用localhost相互通信。
  • 一个pod可以指定一组共享存储卷。pod中所有的容器都可以访问共享卷,允许这些容器共享数据。卷数据可以持久化。

2. Pod存在的意义

  • 解决一个docker容器只运行一个程序的限制;pod是多进程模型,可以运行多个应用程序,每个程序由容器来管理。
  • 某些亲密性应用场景是需要多个容器一起运行的;例如:频繁交互数据的两个应用,通过localhost相互访问可以提供性能,防止出现跨节点、跨网络的通信。

3. Pod实现机制

在同一个Pod中实现共享网络,使用数据卷volume实现共享存储。

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: write
    image: centos
    command: ["bash","-c","for i in {1..100};do echo $i >> /data/hello;sleep 1;done"]
    volumeMounts:
      - name: data
        mountPath: /data
  - name: read
    image: centos
    command: ["bash","-c","tail -f /data/hello"]
    volumeMounts:
      - name: data
        mountPath: /data

  volumes:    ---定义数据卷
  - name: data
    emptyDir: {}

4. 镜像拉取策略(imagePullPolicy)

  • IfNotPresent:默认值,镜像在宿主机上不存在时才拉取
  • Always:每次创建Pod 都会重新拉取一次镜像
  • Never:Pod 永远不会主动拉取这个镜像

默认规则

apiVersion: v1
kind: Pod
metadata:
  name: foo
  namespace: awesomeapps
spec:
  containers:
    - name: foo
      image: janedoe/awesomeapp:v1
      imagePullPolicy: IfNotPresent

根据凭据拉取镜像

apiVersion: v1
kind: Pod
metadata:
  name: foo
  namespace: awesomeapps
spec:
  containers:
    - name: foo
      image: janedoe/awesomeapp:v1
  imagePullSecrets:
    - name: registry-pull-secret

示例:使用Always方式拉取一个私有的镜像
官方链接 https://kubernetes.io/zh/docs/tasks/configure-pod-container/pull-image-private-registry/
生成secret有2种方式:
一、使用docker登录的凭证来生成

  • 1.先登录镜像仓库 docker login -u *** -p *** https://registry.cn-shanghai.aliyuncs.com ---仓库根据实际情况更改
  • 2.查看docker登录的凭证 cat .docker/config.json
  • 3.将凭证base64位编码 cat .docker/config.json |base64 -w 0
  • 4.生成token成功,将token保存到yaml模板即可。
# cat registry-pull-secret.yaml
apiVersion: v1
kind: Secret
metadata:
  name: registry-pull-secret
data:
  .dockerconfigjson: eyJjY3IuY2NzLnRlbmNlbnR5dW4uY29tL3RlbmNlbnR5dW4iOnsidXNlcm5hbWUiOiIzMzIxMzM3OTk0IiwicGFzc3dvcmQiOiIxMjM0NTYuY29tIiwiZW1haWwiOiIzMzIxMzM3OTk0QHFxLmNvbSIsImF1dGgiOiJNek15TVRNek56azVORG94TWpNME5UWXVZMjl0In19
type: kubernetes.io/dockerconfigjson
# kubectl create -f registry-pull-secret.yaml    ---创建
# kubectl get secret    ---查看是否创建成功

二、使用kubectl来生成(在集群中创建保存授权令牌的secret)

  • 1.创建 kubectl create secret docker-registry regcred --docker-server=<your-registry-server> --docker-username=<your-name> --docker-password=<your-pword> --docker-email=<your-email>
    1. 查看 kubectl get secret regcred --output=yaml

5. 资源限制

Pod和Container的资源请求和限制:

  • spec.containers[].resources.limits.cpu

  • spec.containers[].resources.limits.memory

  • spec.containers[].resources.requests.cpu

  • spec.containers[].resources.requests.memory

  • cpu的含义:
    0.1cpu=100m;0.1的cpu在双核,多核机器中的意义是一样的。

  • 内存的含义:
    内存的限制和请求以字节为单位。常见单位 Ei,Pi,Ti,Gi,Mi,Ki。

  • 具有资源请求的pod如何调度:
    当你创建一个pod时,kubernetes调度程序将为pod选择一个节点。每个节点具有每种资源类型的最大容量,调度程序确保对每种资源类型,调度的容器的资源请求综合人小于节点的容量。

  • 具有资源限制的pod如何运行:
    当kubectl启动一个容器时,它会将cpu和内存限制传递到容器运行时 。
    spec.containers[].resource.request.cpu 作用于docker run 命令中的--cpu-shares
    spec.containers[].resource.limits.cpu 作用于docker run 命令中的--cpu-quota
    spec.containers[].resource.limits.memory 作用于 docker run 命令中的--memory

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: db
    image: mysql
    env:
    - name: MYSQL_ROOT_PASSWORD
      value: "password"
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"    ---也可以写成0.25
      limits:
        memory: "128Mi"
        cpu: "500m"    ---也可以写成0.5
  - name: wp
    image: wordpress
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

6. Pod重启策略(restartPolicy)

  • Always:当容器终止退出后,总是重启容器,默认策略。
  • OnFailure:当容器异常退出(退出状态码非0)时,才重启容器。
  • Never:当容器终止退出,从不重启容器。
apiVersion: v1
kind: Pod
metadata:
name: foo
namespace: awesomeapps
spec:
containers:
-name: foo
image: janedoe/awesomeapp:v1
restartPolicy: Always

7. Pod健康检查(Probe)

Probe有以下两种类型:

  • livenessProbe(存活检查)
    如果检查失败,将杀死容器,根据Pod的restartPolicy来操作。
  • readinessProbe(就绪检查)
    如果检查失败,Kubernetes会把Pod从service endpoints中剔除。

Probe支持以下三种检查方法:

  • httpGet
    发送HTTP请求,返回200-400范围状态码为成功。
  • exec
    执行Shell命令返回状态码是0为成功。
  • tcpSocket
    发起TCP Socket建立成功。

探测器配置:

  • initialDelaySeconds:容器启动后要等待多少秒后存活和就绪探测器才被初始化,默认0秒;
  • periodSeconds:执行探测器的时间间隔,默认是10秒;
  • timeoutSeconds:探测的超时后等待多少秒。默认值是1,最小值是1;
  • sucsessThreshold:探测器失败后,被视为成功的最小连续成功数。默认值1.存活探测器必须是1.最小值是1;
  • failureThreshold:当pod启动了并探测到失败,kubernetes重试次数,默认值3,最小值1;

http探测器可以在httpGet上配置额外的字段:

  • host:链接使用的主机名,默认是pod的IP
  • scheme:链接方式,http\https
  • path:访问http的路径
  • httpHeaders:请求证自定义的http头
  • port:访问容器的端口号和端口名,必须在1-65535之间
vi pod-check.yaml
apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
  - name: liveness
    image: busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 60
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5    ---容器初始化之后多长时间做第一次健康检查
      periodSeconds: 5    ---之后多长时间做一个周期性的健康检查
    readinessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5
kubectl create -f pod-check.yaml

一般两种方法都一起配。

8. Pod调度约束

图片.png
  • nodeName用于将Pod调度到指定的Node名称上
apiVersion: v1
kind: Pod
metadata:
  name: pod-example
  labels:
    app: nginx
spec:
  nodeName: 192.168.31.65
  containers:
  - name: nginx
    image: nginx:1.15
  • nodeSelector用于将Pod调度到匹配Label的Node上
apiVersion: v1
kind: Pod
metadata:
  name: pod-example
spec:
  nodeSelector:
    env_role: dev
  containers:
  - name: nginx
    image: nginx:1.15

使用nodeSelector需要先设置label标签:

kubectl label nodes 192.168.9.65 env_role=dev
kubectl label nodes 192.168.9.66 env_role=sit
kubectl get nodes --show-labels

9. 故障排查

Pod状态

常用查看异常命令:

  • kubectl logs type/name #查看容器日志
  • kuberctl describe type/name #查看容器详细描述
  • kubectl exec -it name bash #进入容器内部查看
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 204,732评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 87,496评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 151,264评论 0 338
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,807评论 1 277
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,806评论 5 368
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,675评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,029评论 3 399
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,683评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 41,704评论 1 299
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,666评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,773评论 1 332
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,413评论 4 321
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,016评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,978评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,204评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,083评论 2 350
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,503评论 2 343