kubernets(k8s)使用-Pod篇

1. Pod定义2. Pod的基本用法3. 静态Pod4. Pod容器共享Volume5. 的配置管理6. 在容器中获取Pod信息7. Pod生命周期和重启策略8. Pod健康检查和服务可用性检查9. Pod调度10. 初始化容器(Init Container)11. Pod的升级和回滚12. Pod的扩缩容13. 使用StatefulSet搭建MongoDB集群(有状态的...

儒雅随和天启王

884人浏览 · 2020-01-29 21:12:56

儒雅随和天启王 · 2020-01-29 21:12:56 发布

文章目录

1. Pod定义
- 1.1 pod yaml格式
2. Pod的基本用法
- 2.1 启动一个容器组成的pod
- 2.2 启动由多个容器组成的pod
4. Pod hostPath Volume
- 4.1 创建pod
- 4.2 验证日志落盘是否成功
5. pod的配置管理(ConfigMap)
6. 在容器中获取Pod信息

1. Pod定义

1.1 pod yaml格式

apiVersion: v1		# 版本号
kind: Pod
metadata:			# 元数据
  name: string		# pod的名称
  namespace: string	# pod所属的命名空间，默认值为default
  labels:			# 自定义标签
    - name: string
  annotations:		# 自定义标签注释
    - name: string	
spec:				# pod中容器的详细定义
  containers:		# pod中的容器列表
  - name: string	# 容器的名称
    image: string	# 容器的镜像名称
    # Always: 表示每次都尝试重新拉取镜像
    # Never: 表示仅使用本地镜像
    # IfNotPresent: 如果本地有该镜像，则使用本地的镜像，本地不存在时拉取镜像
    imagePullPolicy: [Always | Never | IfNotPresent]
    command: [string]		# 容器的启动命令列表，如果不指定，则使用镜像打包时使用的启动命令
    args: [string]			# 容器的启动命令参数列表
    workingDir: string		# 容器的工作目录
    volumeMounts:			# 挂载到容器内部的存储卷配置
    - name: string			# 引用pod定义的共享存储卷的名称，需使用volumes[]部分定义的共享存储卷名称
      mountPath: string		# 存储卷在容器内mount的绝对路径(小于512字符)
      readonly: boolean		# 是否为只读模式，默认为读写模式
    ports:					# 容器需要暴露的端口号列表
    - name: string			# 端口的名称
      containerPort: int	# 容器需要监听的端口号
      hostPort: int			# 容器所在主机需要监听的端口号，默认与container port相同。设置hostPort时，同一宿主机将无法启动该容器的第二份副本
      protocol: string		# 端口协议，支持TCP和UDP，默认值为TCP
    env:					# 容器运行前需设置的环境变量列表 
    - name: string			# 环境变量名称
      value: string			# 环境变量的值
    resources:				# 资源限制和资源请求的设置
      limits:				# 资源限制的设置
        cpu: string			# CPU限制，单位为core数，将用于docker run --cpu-share 参数
        memory: string		# 内存限制，单位可以为MiB，GiB等，将用于docker run --memiry 参数
      requests:				# 资源请求的设置
        cpu: string			# CPU请求，单位为core数，容器启动的初始可用数量
        memory: string		# 内存请求，单位可以为MiB，GiB等，容器启动的初始可用数量
    livenessProbe:			# 对pod内各容器健康检查的设置，当探测无响应几次之后，系统将自动重启该容器。可以设置的方法包括exec、httpGet、tcpSocket。对一个容器仅需设置一种健康检查方法。
      exec:
        command: [string]	# exec方式需要指定命令或者脚本，返回值为0则表示容器正常
      httpGet:				# 对pod内个容器健康检查设置，需要指定path、port，任何大于200小于400的返回码都会认定是成功的返回码
        path: string		# 访问的HTTP server的path
        port: number		# 访问的容器的端口名字或者端口号
        host: string		# 连接的主机名，默认连接到pod的IP
        scheme: string		# 连接使用的schema，默认HTTP
        httpHeaders:		# 自定义请求的header
        - name: string	
          value: string
      tcpSocket:
        port: number
      initialDelaySeconds: 0	# 容器启动后第一次执行探测是需要等待多少秒
      timeoutSeconds: 0			# 对容器健康监测的探测等待响应的超时时间设置，默认为1s。若超过该设置，则认为容器不健康，会重启该容器
      periodSeconds: 0			# 对容器健康检查的定期探测时间设置。默认是10秒，最小1秒
      successThreshold: 0		# 探测失败后，最少连续探测成功多少次才被认定为成功。默认是1。对于liveness必须是1。最小值是1。
      failureThreshold: 0		# 探测成功后，最少连续探测失败多少次才被认定为失败。默认是3。最小值是1。
    securitycontext:
      privileged: false
  # pod重启策略
  # Always: pod一旦终止运行，无论容器时如何终止的，kubelet都将重启它
  # Never: pod终止后，kubelet将退出码报告给master，不会重启该pod
  # OnFailure: 只有pod以非零退出码终止时，kubelet才会重启该容器。如果容器正常结束，则kubelet将不会重启它。
  restartPolicy: [Always | Never | OnFailure]
  nodeSelector: object			# 设置node的label，以key:value格式指定，pod将被调度到具备有这些label的node上 
  imagePullSecrets:
  - name: string
  hostNetwork: false			# 是否使用主机网络模式，默认值为false。设置为ture表示容器使用宿主机网络，不再使用Docker网桥，该pod将无法再同一台宿主机上启动第2个副本
  volumes:						# 在该pod上定义的共享存储卷列表
  - name: string				# 共享存储卷的名称，在一个pod中每个存储卷定义一个名称。容器定义部分的containers[].volumeMounts[].name将引用共享存储卷的名称
    emptyDir: {}				# 类型为emptyDir的存储卷，表示与pod同生命周期的一个临时目录，其值为一个空对象
    hostPath:					# 类型为hostPath表示挂载pod所在宿主机的目录
      path: string				# pod所在主机的目录。将被用于容器中的mount目录containers[].volumeMounts[].mountPath
    secret:						# 类型为secret的存储卷，表示挂载集群预定义的secret对象到容器内部
      secretNarae: string
      items:
      - key: string
        path: string
    configMap:					# 类型为configMap的存储卷，表示挂载集群预定义的configMap对象到容器内部
      name: string
      items:
      - key: string
        path: string

2. Pod的基本用法

2.1 启动一个容器组成的pod

创建pod：kubectl create -f php-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: php-nginx
  namespace: pod-test
  labels:
    name: mysql
spec:                   
  containers:           
  - name: php-nginx        # 容器的名称
    image: docker.io/webdevops/php-nginx       # 容器的镜像名称
    imagePullPolicy: IfNotPresent
    ports:
    - containerPort: 80
      protocol: TCP

检查pod创建过程：kubectl describe pod -n pod-test php-nginx
查看pod创建过程
查看pod运行状态：kubectl get pod -n pod-test php-nginx
查看pod状态
删除pod：kubectl delete pod -n pod-test php-nginx

2.2 启动由多个容器组成的pod

创建pod：kubectl create -f php-redis-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: php-redis
  namespace: pod-test
  labels:
    name: php
spec:
  containers:
  - name: php-nginx        # 容器的名称
    image: docker.io/webdevops/php-nginx       # 容器的镜像名称
    imagePullPolicy: IfNotPresent
    ports:
    - containerPort: 80
      protocol: TCP
  - name: redis
    image: docker.io/redis
    imagePullPolicy: IfNotPresent
    ports:
    - containerPort: 6379
      protocol: TCP

检查pod创建过程：kubectl describe pod -n pod-test php-redis
查看pod创建过程

4. Pod hostPath Volume

这里只介绍hostPath模式，一般用于日志落盘操作。
hostpath模式会将pod所在宿主机的目录映射到pod内部，如下yaml就将宿主机的/logs目录映射到了php pod的/data/logs下

4.1 创建pod

创建pod：kubectl create -f volume-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: php
  namespace: pod-test
  labels:
    name: php
spec:                   
  containers:           
  - name: php-nginx        # 容器的名称
    image: docker.io/webdevops/php-nginx       # 容器的镜像名称
    imagePullPolicy: IfNotPresent
    ports:
    - containerPort: 80
      protocol: TCP
    volumeMounts:
    - name: php-logs
      mountPath: /data/logs
  volumes:              
    - name: php-logs       # 共享存储卷的名称，在一个pod中每个存储卷定义一个名称。容器定义部分的containers[].volumeMounts[].name将引用共享存储卷的名称
      hostPath:
        path: /logs

查看创建详情：kubectl describe pod -n pod-test php
查看pod创建过程

4.2 验证日志落盘是否成功

在pod内挂载目录写入文件
验证日志落盘
根据kubectl describe pod -n pod-test php查看到的信息可以得出，此pod在node2的宿主机上

5. pod的配置管理(ConfigMap)

5.1 ConfigMap概述

ConfigMap以一个或多个key:value的形式保存在Kubernetes系统中供应用使用，既可以用于表示一个变量的值，也可以用于表示一个完整配置文件的内容

ConfigMap供容器使用的典型用法如下：

生成为容器内的环境变量
设置容器启动命令的启动参数(需设置为环境变量)
以Volume的形式挂载为容器内部的文件或目录

5.2 创建ConfigMap资源对象

5.2.1 通过YAML配置文件方式创建

【例1】：将几个应用所需的变量定义为ConfigMap的用法
创建ConfigMap：kubectl create -f test-configmap.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: test-configmap
  namespace: pod-test
  labels:
    name: config
data:
  appname: tce
  appdir: /data/tce

查看ConfigMap的详细信息：kubectl get configmap test-configmap -n pod-test -o yaml

kubectl describe configmap -n pod-test 在这里插入图片描述
【例2】：将两个配置文件a.config和b.config定义为ConfigMap的用法，设置key为配置文件的别名，value则是配置文件的全部文本内容
创建ConfigMap：kubectl create -f file-configmap.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: file-configmap
  namespace: pod-test
  labels:
    name: config
data:
  a.config: |
    a=1
    b=2 
  b.config: |
    c=1
    d=2

查看ConfigMap的详细信息：kubectl get configmap file-configmap -n pod-test -o yaml
在这里插入图片描述

5.2.2 通过kubectl命令方式创建

可以使用参数--from-file或--from-literal指定内容，并且可以在一行命令中指定多个参数

5.2.2.1 通过--from-file参数从文件中进行创建

通过命令行创建ConfigMap：kubectl create configmap cli-file-configmap --from-file=a.txt -n pod-test
查看创建的ConfigMap：kubectl get configmap cli-file-configmap -o yaml -n pod-test

5.2.2.2 通过--from-file参数从目录中进行创建

该目录下的每个配置文件的名都被设置为key，文件的内容被设置为value
准备好配置文件存放的文件夹
在这里插入图片描述
根据配置文件夹创建ConfigMap：kubectl create configmap cli-files-configmap --from-file=configfile
查看ConfigMap详情：kubectl get configmap cli-files-configmap -o yaml

5.2.2.3 使用--from-literal参数创建k-v类型的ConfigMap内容

使用--from-literal创建：kubectl create configmap cli-k-v-configmap --from-literal=data=nihao --from-literal=logfile=/data/logs
查看ConfigMap信息：kubectl get configmap cli-k-v-configmap -o yaml
在这里插入图片描述

5.3 在pod中使用ConfigMap

5.3.1 通过环境变量方式使用ConfigMap

这里使用5.2.1中例1的ConfigMap进行挂载
创建pod：kubectl create -f conf-php-pod.yaml(1.6版本的k8s有更简单挂载方法envFrom，以后再说)

apiVersion: v1
kind: Pod
metadata:
  name: conf-php
  namespace: pod-test
  labels:
    name: configmap-test
spec:                   
  containers:           
  - name: php-nginx        # 容器的名称
    image: docker.io/webdevops/php-nginx       # 容器的镜像名称
    imagePullPolicy: IfNotPresent
    ports:
    - containerPort: 80
      protocol: TCP
    env:
    - name: app_name 			# 自定义环境变量名称
      valueFrom:
        configMapKeyRef:
          name: test-configmap  # 取自于哪一个ConfigMap
          key: appname 			# ConfigMap内的key
    - name: app_dir 			# 自定义环境变量名称
      valueFrom:
        configMapKeyRef:
          name: test-configmap  # 取自于哪一个ConfigMap
          key: appdir 			# ConfigMap内的key

查看pod创建过程：kubectl describe pod -n pod-test conf-php
在这里插入图片描述
检测环境变量是否传递成功

5.3.2 通过volumeMount使用ConfigMap

这里使用5.2.1中例2的ConfigMap进行挂载
创建pod：kubectl create -f c-v-php-pod.yaml
查看pod创建信息：kubectl describe pod c-v-php -n pod-test
在这里插入图片描述
检测是否挂载成功

5.4 使用ConfigMap的限制条件

ConfigMap必须在pod之前创建
ConfigMap受Namespace限制，只有处于相同Namespace中的pod才可以应用它
ConfigMap暂未实现配额管理

6. 在容器中获取Pod信息

6.1 环境变量方式

6.1.1 将pod信息注入为环境变量

【例】：将pod的ip、名称和所在Namespace注入容器的环境变量中

apiVersion: v1
kind: Pod
metadata:
  name: downward-api
  namespace: pod-test
  labels:
    name: downward-api
spec:
  containers:
  - name: redis
    image: docker.io/redis
    imagePullPolicy: IfNotPresent
    ports:
    - containerPort: 6379
      protocol: TCP
    env:
    - name: pod_name
      valueFrom:
        fieldRef:
          fieldPath: metadata.name
    - name: pod_namespace
      valueFrom:
        fieldRef:
          fieldPath: metadata.namespace
    - name: pod_ip
      valueFrom:
        fieldRef:
          fieldPath: status.podIP

可以使用kubectl get pod downward-api -n pod-test -o yaml去获取fieldPath的值，例如：status.hostIP
在这里插入图片描述
检测pod信息是否导入容器内

6.1.2 将容器资源信息注入为环境变量

apiVersion: v1
kind: Pod
metadata:
  name: container-downward-api 
  namespace: pod-test
  labels:
    name: downward-api
spec:                   
  containers:           
  - name: redis
    image: docker.io/redis 
    imagePullPolicy: IfNotPresent
    resources:
      requests:				
        memory: "64Mi"		# 容器内存请求值
        cpu: "0.5"			# 容器cpu请求值  0.5=500m
      limits:				
        memory: "128Mi"		# 容器内存限制值
        cpu: "1"			# 容器cpu限制值
    env:
    - name: container_requests_memory
      valueFrom:
        resourceFieldRef:
          containerName: redis
          resource: requests.memory
    - name: container_requests_cpu
      valueFrom:
        resourceFieldRef:
          containerName: redis
          resource: requests.cpu
    - name: container_limits_memory
      valueFrom:
        resourceFieldRef:
          containerName: redis
          resource: limits.cpu
    - name: container_limits_cpu
      valueFrom:
        resourceFieldRef:
          containerName: redis
          resource: limits.cpu

在这里插入图片描述

6.2 Volume挂载方式

通过挂载的方式将metadata.labels和metadata.annotations的信息挂载为容器内的一个文件
创建pod：kubectl create -f volume-downward-api.yaml

apiVersion: v1
kind: Pod
metadata:
  name: v-downward-api 
  namespace: pod-test
  labels:
    zone: home
    tag: more
  annotations:
    version: v6.6
spec:                   
  containers:           
  - name: redis
    image: docker.io/redis 
    imagePullPolicy: IfNotPresent
    ports:
    - containerPort: 6379
      protocol: TCP
    volumeMounts:
      - name: podinfo
        mountPath: /data
        readOnly: false

  volumes:
  - name: podinfo
    downwardAPI:
      items:
      - path: "labels"
        fieldRef:
          fieldPath: metadata.labels
      - path: "annotations"
        fieldRef:
          fieldPath: metadata.annotations

查看pod创建详细信息kubectl describe pod v-downward-api -n pod-test
在这里插入图片描述

验证挂载是否成功
在这里插入图片描述

K8S/Kubernetes

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐

【深度】阿里巴巴万级规模 K8s 集群全局高可用体系之美

作者 | 韩堂、柘远、沉醉来源 | 阿里巴巴云原生公众号前言台湾作家林清玄在接受记者采访的时候，如此评价自己 30 多年写作生涯：“第一个十年我才华横溢，‘贼光闪现’，令周边黯然失色；第二个十年，我终于‘宝光现形’，不再去抢风头，反而与身边的美丽相得益彰；进入第三个十年，繁华落尽见真醇，我进入了‘醇光初现’的阶段，真正体味到了境界之美”。长夜有穷，真水无香。领略过了 K8s“身在江

K8S/Kubernetes

如何基于 K8s 构建下一代 DevOps 平台？

作者 | 孙健波（天元）导读：当前云原生 DevOps 体系现状如何？面临哪些挑战？如何通过 OAM 解决云原生 DevOps 场景下的诸多问题？云原生开发应用模型 OAM(Open Application Model) 社区核心成员孙健波将为大家一一解答，并分享如何基于 OAM 和 Kubernetes 打造无限能力的下一代 DevOps 平台。什么是 DevOps？为什么基于 Kub