pod高阶用法

Projected Volume">Projected Volume
- Secret">Secret
- Downward API
- ConfigMap
Pod Preset">Pod Preset
健康检查和恢复机制

Projected Volume

投射数据卷http://docs.kubernetes.org.cn/429.html#projected
为容器提供预先定义好的数据，从容器的角度来看，这些 Volume 里的信息是被 Kubernetes“投射进容器中的”
到目前为止，Kubernetes 支持的 Projected volume一共有4种
secret,configMap, downwardAPI, serviceAccountToken（特殊的secret）

Secret

https://kubernetes.io/zh/docs/concepts/configuration/secret/
Secret 对象要求这些数据必须是经过 Base64 转码，以免出现明文隐患

# echo -n 'admin' | base64
YWRtaW4=
# echo -n '123456' |base64
MTIzNDU2

创建secret对象

# cat user
YWRtaW4=
# cat pass
MTIzNDU2
# kubectl create secret generic user --from-file=./user
# kubectl create secret generic pass --from-file=./pass
# kubectl get secret |egrep "pass|user"
pass                  Opaque                                1      18h
user                  Opaque                                1      18h

YAML形式

# cat secret.yaml
apiVersion: v1
kind: Secret
metadata:
  name: robinsecert
type: Opaque
data:
  user: YWRtaW4=
  pass: MTIzNDU2
 # kubectl apply -f secret.yaml
 # kubectl get secret |grep secert
robinsecert           Opaque                                2      18h

创建pod对象声明挂载secret对象

apiVersion: v1
kind: Pod
metadata:
  name: test-projected-volume 
spec:
  containers:
  - name: test-secret-volume
    image: busybox
    args:
    - sleep
    - "86400"
    volumeMounts:
    - name: mysql-cred
      mountPath: "/projected-volume"
      readOnly: true
  volumes:
  - name: mysql-cred
    projected:
      sources:
      - secret:
          name: user
      - secret:
          name: pass

验证注入效果

# kubectl exec -it test-project-volume -- /bin/sh
/ # cat /projected-volume/user
YWRtaW4=
/ # cat /projected-volume/pass
MTIzNDU2

Downward API

https://kubernetes.io/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#the-downward-api
http://docs.kubernetes.org.cn/830.html#Downward_API
通过环境变量向容器暴露 Pod 信息，让 Pod 里的容器能够直接获取到这个 Pod API对象本身的信息
支持字段

1. 使用 fieldRef 可以声明使用:
spec.nodeName - 宿主机名字
status.hostIP - 宿主机 IP
metadata.name - Pod 的名字
metadata.namespace - Pod 的 Namespace
status.podIP - Pod 的 IP
spec.serviceAccountName - Pod 的 Service Account 的名字
metadata.uid - Pod 的 UID
metadata.labels['<KEY>'] - 指定 <KEY> 的 Label 值
metadata.annotations['<KEY>'] - 指定 <KEY> 的 Annotation 值
metadata.labels - Pod 的所有 Label
metadata.annotations - Pod 的所有 Annotation
2. 使用 resourceFieldRef 可以声明使用:
容器的 CPU limit
容器的 CPU request
容器的 memory limit
容器的 memory request

ConfigMap

https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/
https://www.kubernetes.org.cn/configmap
保存不需要加密的、应用所需的配置信息，用法和secret一致

Pod Preset

https://www.kubernetes.org.cn/podpreset
http://docs.kubernetes.org.cn/789.html
Pod Preset是一种API资源，用来在创建pod时向其注入运行时需要的额外信息，如环境变量、存储卷等，通过使用label selector确定为pod应用那些Presets。
Preset允许用户创建具有通用性的模板而无需显式提供pod运行时才需要的信息，
允许模板的创建者只需提供pod运行时需要的信息而无需关注pod的实现细节。
定义preset设置时区

# cat timezonePreset.yaml
apiVersion: settings.k8s.io/v1alpha1
kind: PodPreset
metadata:
  name: timezone-init
spec:
  selector:        #此段必选设置，可以为空表示应用所有pod
    matchLabels:
  env:
    - name: TZ
      value: Asia/Shanghai

报错 error: unable to recognize “timezonePreset.yaml”: no matches for kind “PodPreset” in version “settings.k8s.io/v1alpha1” 则需编辑/etc/kubernetes/manifests/kube-apiserver.yaml在spec/containers/command段添加以下两段配置，保存后kubelet会自动重启kube-apiserver组件

- --enable-admission-plugins=NodeRestriction,PodPreset
- --runtime-config=settings.k8s.io/v1alpha1=true

再次查看api-version并创建即可成功

# kubectl api-versions | grep settings.k8s.io
settings.k8s.io/v1alpha1
# kubectl apply -f timezonePreset.yaml
podpreset.settings.k8s.io/timezone-init created
# kubectl get podpresets
NAME             CREATED AT
timezone-init    2019-09-11T12:10:01Z

定义pod的yaml文件

# cat busybox.yaml
apiVersion: v1
kind: Pod
metadata:
  name: timezone-test
spec:
  containers:
    - name: minial
      image: busybox
应用后查看一下这个 Pod 的 API 对象多了新添加的时区设置
# kubectl apply -f busybox.yaml
pod/timezone-test created
# kubectl get pod timezone-test -o yaml
apiVersion: v1
kind: Pod
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","kind":"Pod","metadata":{"annotations":{},"name":"timezone-test","namespace":"default"},"spec":{"containers":[{"image":"busybox","name":"minial"}]}}
    podpreset.admission.kubernetes.io/podpreset-timezone-init: "6946675"
  creationTimestamp: "2019-09-11T12:19:17Z"
  name: timezone-test
  namespace: default
  resourceVersion: "6948419"
  selfLink: /api/v1/namespaces/default/pods/timezone-test
  uid: 86679227-6bf6-4d76-a2e3-c926593819d4
spec:
  containers:
  - env:
    - name: TZ
      value: Asia/Shanghai
    image: busybox
    imagePullPolicy: Always
    name: minial

Kubernetes为Preset提供了一个允许控制器(admission controller)，当创建创建pod的请求到达时，通过这个允入控制器将label selector选中的Preset应用到pod中，具体流程如下：

检索系统中所有可用的Presets。
检查所有Preset的label selector是否与当前pod的标签匹配。
尝试将匹配Preset中的各种资源合并进正在创建的pod。
如果发生错误，为pod抛出合并Preset失败的异常事件，然后在不合并Preset所提供资源的情况下创建pod（合并失败并没有阻挡pod的创建）。
如果合并成功，向合并后的结果spec加入到pod的注解中，表示pod被Preset修改了，注册格式如下：
podpreset.admission.kubernetes.io/podpreset-: “”
每个pod可以被0到多个Preset匹配，每个Preset可以应用到0到多个pod。当Preset被应用到pod时，kubernetes会修改pod的spec。当注入Env、EnvFrom、VolumeMounts时，kubernetes会修改pod中除init container以外的其它所有container的spec，当注入volume时，修改pod的spec。
健康检查和恢复机制
可以为Pod里的容器定义一个健康检查的探针（Probe），kubelet会根据这个Probe的返回值判断容器的状态，而不是以docker是否在运行来做判断依据—生产环境检查健康存活的手段
demo—exec
```
apiVersion: v1
kind: Pod
metadata:
labels:
 test: liveness
name: test-liveness-exec
spec:
containers:
- name: liveness
 image: busybox
 args:
 - /bin/sh
 - -c
 - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
 livenessProbe:   (健康检查)
   exec:
     command:
     - cat
     - /tmp/healthy
   initialDelaySeconds: 5      （容器启动后5S执行） 
   periodSeconds: 5            （每5S执行一次）
```
demo—http
```
...
livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
    httpHeaders:
    - name: X-Custom-Header
      value: Awesome
    initialDelaySeconds: 3
    periodSeconds: 3
```
demo—tcp
```
 ...
 livenessProbe:
   tcpSocket:
     port: 8080
   initialDelaySeconds: 15
   periodSeconds: 20
```
Pod恢复机制，也叫restartPolicy，pod spec部分的标准字段，默认为Always，Pod 的恢复过程，永远都是发生在当前节点上，除非pod.spec.node发生了变化，否则就算主机宕机也不会主动迁移到其他节点上去。
Kubernetes 中并没有 Docker 的 Stop 语义。所以虽然是 Restart（重启），但实际却是重新创建容器—create
pod.spec.restartPolicy

Always：在任何情况下，只要容器不在运行状态，就自动重启
OnFailure: 只在容器异常时才自动重启容器；
Never: 从来不重启容器

Projected Volume

Secret

Downward API

ConfigMap

Pod Preset

健康检查和恢复机制