Kubernetes进阶之基础组件

前面讲了如何使用k8s以及对应的k8s的集群如何搭建，对相应的组件的使用也是慢慢了解了，例如pod，deployment等。但是只是使用还不够，本文主要是针对k8s常用的组件进行进阶介绍。

1、Pod进阶

1.1、生命周期(Lifecycle)

官网：https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/

Pod的生命周期分为五种状态：挂起、运行中、成功、失败、未知状态，平时运行apply命令创建pod以后通过kubectl get pods -o wide可以看到创建的pod到哪个生命周期了。

挂起（Pending）： Pod已经被Kubernetes系统接受，但有一个或者多个镜像尚未创建。可能会等待的时间分为两个部分，一个是调度Pod的时间，另一个是通过网络下载镜像的时间，可提前下载好需要的镜像减少等待的时间；
运行中（Running）： 该Pod已经绑定到了一个节点上，Pod中所有的容器都已经被创建，至少有一个容器正在运行，或者正在处于启动或重启状态；
成功（Succeeded）： Pod中所有的容器都被成功终止，并且不会再重启；
失败（Failed）： Pod中的所有容器都已经终止，并且最少有一个容器因为失败终止，也就是说容器以非0的状态退出或者被系统终止；
未知（Unknown）： 因为某些原因无法取得Pod的状态，通常是因为与Pod所在主机通信失败。

1.2、重启策略

官网：https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy

Pod的重启策略有三种，但是重启策略只适用于同一节点的容器。

Always： 容器失效时立即重启；
OnFailure： 容器终止运行且退出码不为0时重启；
Never： 永远不重启。

1.3、静态Pod

静态Pod是由kubelet进行管理的，并且存在于特定的Node上。
不能通过API Server进行管理，无法与ReplicationController、Deployment、DaemonSet进行关联，也无法进行健康检查。

1.4、健康检查

官网：https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes

通过官网我们可以看到健康检查的方式有三种，检查的结果也是三种，检查结果分为通过检查，检查失败和未知情况（不做任何处理）。

livenessProbe： 判断容器是否存活；如果检查结果失败，则kubelet会杀死所有容器，容器是否重启依赖于其重启策略。如果容器没有提供该探针，则默认为通过检查。
readinessProbe： 判断容器是否能够响应请求；如果检查结果为失败，则将Pod从所有与之匹配的节点中删除。第一次延迟响应之前的检查结果默认为失败，如果容器没有提供该探针，则默认为通过检查。
startupProbe： 判断容器是否启动；如果容器提供了该探针，那么其他探针失败直到该探针的检查结果通过才能继续使用。如果检查结果失败，则kubelet会杀死所有容器，容器是否重启依赖于其重启策略。如果容器没有提供该探针，则默认为通过检查。

1.5、ConfigMap

官网 ：https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/

ConfigMap说白了就是用来保存配置数据的键值对，也可以保存单个属性，也可以保存配置文件。所有的配置内容都存储在etcd中，创建的数据可以供Pod使用。

1.5.1、如何创建ConfigMap

1.5.1.1、命令行创建

创建一个名称为my-config的configMap，key值是port，value值是’3306’，可以直接使用以下命令：

kubectl create configmap my-config --from-literal=port='3306'

查看该ConfigMap：kubectl get configmap
获取该ConfigMap的yml文件详细信息：kubectl get configmap myconfig -o yaml

1.5.1.2、从配置文件中创建

创建一个文件，名称为my-config.propertie，然后在里面加上port=3306 name = mysql
然后再运行以下命令将该配置文件变成ConfigMap:

kubectl create configmap app --from-file=./my-config.properties

查看命令跟上面一样

1.5.1.3、从目录中创建

创建一层层文件夹，然后再运行命令创建：

mkdir config 
cd config 
mkdir a 
mkdir b 
cd .. 

kubectl create configmap config --from-file=config/

1.5.1.4、通过yml文件创建

创建一个ConfigMaps.yml文件，可以在里面创建多个ConfigMap，不同的ConfigMap存储的数据不一样，下面yml中data就是每个ConfigMap存储的数据键值对。

apiVersion: v1 
kind: ConfigMap 
metadata: 
  name: special-config 
  namespace: default 
data: 
  special.how: very 
--- 
apiVersion: v1 
kind: ConfigMap 
metadata: 
  name: env-config 
  namespace: default 
data: 
  log_level: INFO

kubectl apply -f ConfigMaps.yml

1.5.2、Pod中ConfigMap的使用

注意： （1）ConfigMap必须在Pod使用它之前创建；（2）Pod只能使用同一个命名空间下的ConfigMap；

1.5.2.1、通过环境变量使用

apiVersion: v1 
kind: Pod 
metadata: 
  name: dapi-test-pod 
spec: 
  containers: 
    - name: test-container 
      image: busybox 
      command: [ "/bin/sh", "-c", "env" ] 
      env:# Define the environment variable 
        - name: SPECIAL_LEVEL_KEY 
          valueFrom: 
            configMapKeyRef: 
              name: special-config #匹配ConfigMap的name
              key: special.how   #匹配ConfigMap的data中的key
restartPolicy: Never

可以运行kubectl logs pod-name命令查看打印出来的数据

1.5.2.2、用作命令行参数

在命令行下引用时，需要先设置为环境变量，之后可以用过$(VAR_NAME)设置容器启动命令的启动参数

apiVersion: v1 
kind: Pod 
metadata: 
  name: dapi-test-pod2 
spec: 
  containers: 
    - name: test-container 
      image: busybox 
      command: [ "/bin/sh", "-c", "echo $(SPECIAL_LEVEL_KEY)" ] 
      env:
        - name: SPECIAL_LEVEL_KEY 
          valueFrom:
            configMapKeyRef: 
              name: special-config   #匹配ConfigMap的name
              key: special.how  #匹配ConfigMap的data中的key
restartPolicy: Never

运行kubectl logs pod-name命令查看打印出来的数据

1.5.2.3、作为volume挂载使用

将创建的ConfigMap直接挂载到Pod的/etc/config目录下，其中每一个key-value键值对都会生成一个文件，key为文件名，value为内容。

apiVersion: v1 
kind: Pod 
metadata: 
  name: pod-configmap2 
spec: 
  containers: 
    - name: test-container 
      image: busybox 
      command: [ "/bin/sh", "-c", "ls /etc/config/" ] 
      volumeMounts: 
        - name: config-volume 
          mountPath: /etc/config 
          volumes: 
            - name: config-volume 
              configMap: 
                name: special-config 
restartPolicy: Never

创建pod：kubectl apply -f pod-myconfigmap-v2.yml
进入Pod：kubectl exec -it pod-name bash
查看运行日志：kubectl logs pod-name

1.5.3、ConfigMap在IngressController中的使用

前面将的IngressController还记得吧（Kubernetes的核心详解），我使用了Ingress Nginx Controller，从官网下载了Ingress Nginx Controller创建需要的yml文件，文件中有很多configMap。如下：

然后我们继续看，能看到Ingress Nginx Controller的Deployment使用名字为ingress-nginx-controller的configMap来作为配置文件，也就是上图我们截图的那个ConfigMap。

其实通过Ingress Nginx Controller的讲解，我们知道Ingress Nginx Controller其实核心就是一个nginx，其肯定也有对应的配置文件/etc/nginx/nginx.conf。如果我们要修改配置文件，之前的方法是直接改配置文件，但是现在既然用了Co