pod进阶

一、Lifecycle

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

 通过前面的分享，关于pod是什么相信看过前面的文章的朋友已经很清楚了，有开发经验的朋友很清楚，对象的创建是具有生命周期的，对于Pod也一样，他也有它的生命周期，接下来就是分享pod的创建、销毁、以及他的状态是什么；简单的来说，就是分享pod的生命周期。

 

 

 

 下图是官网对Pod生命周期阶段的描述

 

 

 通过官网可以发现有一个Running状态，相信大家也非常喜欢Running状态，因为这玩意就表示创建成功正常运行，但有时候创建pod时也有不随人愿的时候，因为有时pod偏偏会有一些奇怪的状态，比哪下面几个状态

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

其实对这Pod五大状态了解后有问题时就可以很好解决了，因为知道状态后就可以通过kubectl describe pod pod-name -n namespace去查看pod日志了解为什么出现这状态了。

二、重启策略

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

 前面生命周期了解了后，下面了解下pod的重启策略，之所以要了解这，是因为我们有时候在创建Pod时会发现Pod会不断发生重启，官网对于重启策略也有说明，通过官网可以知道，关于重启我们可以在yaml文件中通过restartPolicy这个属性去进行一个配置，然后重启的策略有三个，分别如下：

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

 

三、静态Pod

静态Pod是由kubelet进行管理的，并且存在于特定的Node上，比喻像master。不能通过API Server进行管理，它是由kubelet进行管理的，无法与ReplicationController,Ddeployment或者DaemonSet进行关联，也无法进行健康检查。这个东西怎么理解呢?这样说吧，我们在查看kubectl get pods -n kube-system时会发现系统的这个命名空间之下，我们一装完网络插件之后会有很多Pod，按照之前我写的文章逻辑来想，这个pod至少要有一个yaml文件才能创建的，但是我们发现刚刚命令下的系统空间的pod我们并没有写他们的pod，那么它是怎么来的呢？其实这东西很简单，当我们用命令kubeadm-init命令时他会在我们的etc/kubernetes/目录之下会有一个manifests目录，这个manifests中会有很多系统需要的很多组件的pod.yaml文件；这些玩意都是系统给我们提供的，这些组件的pod是由kubelet统一管理的，这些pod我们会习惯叫他静态pod，之所以叫他静态Pod是因为他不会有一个独立的网络，可以通过查看pod详情命令kubectl get pods -n kube-system -o wide可以看到一个点，就是系统组件的pod用的是master节点的ip，并没有用到虚拟ip，所以也验证了他不是API Server进行管理的，是由kubelet进行统一管理的，所以也无法与ReplicationController,Ddeployment或者DaemonSet进行关联和通讯，也无法进行健康检查，所以我们习惯把他叫做静态pod。

四、健康检查

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

 经过前面几个步骤，pod有生命周期了，有重启策略了，也有固定ip了，接下来pod在进行创建的时候还需要进行健康检查才能够进行正常的创建，下面是官网对健康检查的说明

 

 

 健康检查是通过两个属性进行的：

• LivenessProbe探针：判断容器是否存活
• ReadinessProbe探针：判断容器是否启动完成

五、ConfifigMap

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

 

 

 官网的介绍说白了就是用来保存配置数据的键值对，也可以保存单个属性，也可以保存配置文件。所有的配置内容都存储在etcd中，创建的数据可以供Pod使用。下面来分享下三种创建的方式

5.1、命令行创建

创建一个名称为my-config的ConfigMap，key值时db.port，value值是3306

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

通过命令查看，会发现在系统的默认空间下创建了一个my-config

kubectl get configmap

查看yaml文件对应的格式

kubectl get configmap myconfig -o yaml

5.2、从配置文件中创建

创建一个文件，名称为app.properties，然后在创建的文件中加入下面两句话

name=ghy
age=2

然后根据文件去创建

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

通过命令查看，会发现在系统的默认空间下创建了一个app

kubectl get configmap

查看yaml文件对应的格式

kubectl get configmap app -o yaml

5.3、通过yaml文件创建

新建一个configmaps.yaml，并把文件放进去

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

启动yaml文件

kubectl apply -f configmaps.yaml

通过命令查看，会发现在系统的默认空间下创建了一个env-config和special-config两个

kubectl get configmap

创建CONFIGMAP的动作完成后接下来就是去使用他了。

5.4、ConfigMap的使用

使用方式：

• 通过环境变量的方式，直接传递给pod
  • 使用configmap中指定的key
  • 使用configmap中所有的key
• 通过在pod的命令行下运行的方式(启动命令中)
• 作为volume的方式挂载到pod内

注意

• ConfigMap必须在Pod使用它之前创建
• 使用envFrom时，将会自动忽略无效的键
• Pod只能使用同一个命名空间的ConfigMap

5.4.1、作为volume挂载使用

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

创建一个pod-configmap.yaml文件

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里面有一个busybox的containers，他会往虚拟机的/etc/config目录下把configMap的key和value以目录的形式挂载进去；

启动脚本

kubectl apply -f pod-myconfigmap.yml

可以用下面命令看是否创建成功

kubectl get pods

进入容器目录然后会找到上面说的东西

kubectl exec -it pod-configmap2 bash

 六、Secret

 官网：https://kubernetes.io/docs/concepts/configuration/secret/

这块内容是关于数据安全性东西，前面的ConfigMap的配置文件什么的大家也看了，但现在的文件配置都是明文的，如果有些东西不想明文展示，那怎么搞呢

 

 6.1、Secret类型

secret一共有三种类型：

• Opaque：使用base64编码存储信息，可以通过`base64 --decode`解码获得原始数据，因此安全性弱。
• kubernetes.io/dockerconfigjson：用于存储docker registry的认证信息。
• kubernetes.io/service-account-token：用于被 serviceaccount 引用。serviceaccout 创建时 Kubernetes 会默认创建对应的 secret。Pod 如果使用了 serviceaccount，对应的 secret 会自动挂载到 Pod 的 /run/secrets/kubernetes.io/serviceaccount 目录中。

6.2、Opaque Secret

 Opaque类型的Secret的value为base64位编码后的值

 6.2.1、 从文件中创建

echo -n "admin" > ./username.txt
echo -n "1f2d1e2e67df" > ./password.txt

kubectl create secret generic db-user-pass --from-file=./username.txt --from-file=./password.txt

kubectl get secret

6.2.2、 使用yaml文件创建

(1)对数据进行64位编码

echo -n 'admin' | base64
echo -n '1f2d1e2e67df' | base64

(2)定义mysecret.yaml文件

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  username: YWRtaW4=
  password: MWYyZDFlMmU2N2Rm

(3)根据yaml文件创建资源并查看

kubectl create -f ./secret.yaml

kubectl get secret

kubectl get secret mysecret -o yaml

6.3 Secret使用

通过6.2.2的方式就得到了一个secret文件，接下来就这个文件使用进行说明下。他的使用有两种方式

• 以Volume方式
• 以环境变量方式

6.3.1、 将Secret挂载到Volume中

（1）创建mypod.yaml文件

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mypod
    image: redis
    volumeMounts:
    - name: foo
      mountPath: "/etc/foo"
      readOnly: true
  volumes:
  - name: foo
    secret:
      secretName: mysecret

（2）用命令启动

kubectl apply -f mypod.yaml

（3）进入容器里面

kubectl exec -it mypod bash

(4)进入在配置文件定义的目录会发现目录是创建成功的

cd /etc/foo

（5）也可以用如下命令看创建的内容

cat /etc/foo/username

cat /etc/foo/password

6.3.2、 将Secret设置为环境变量

（1）配置文件如下，重要环境变量配置我标记出来了

apiVersion: v1
kind: Pod
metadata:
  name: secret-env-pod
spec:
  containers:
  - name: mycontainer
    image: redis
    env:
      - name: SECRET_USERNAME
        valueFrom:
          secretKeyRef:
            name: mysecret
            key: username
- name: SECRET_PASSWORD
        valueFrom:
          secretKeyRef:
            name: mysecret
            key: password
  restartPolicy: Never

6.4 、kubernetes.io/dockerconfigjson

kubernetes.io/dockerconfigjson用于存储docker registry的认证信息，可以直接使用`kubectl create secret`命令创建

6.5、 kubernetes.io/service-account-token

这个是用于被 serviceaccount 引用。serviceaccout 创建时 Kubernetes 会默认创建对应的 secret。Pod 如果使用了 serviceaccount，对应的 secret 会自动挂载到 Pod 的 /run/secrets/kubernetes.io/serviceaccount 目录中。

kubectl get secret   # 可以看到service-account-token
kubectl run nginx --image nginx
kubectl get pods
kubectl exec -it nginx-pod-name bash
ls /run/secrets/kubernetes.io/serviceaccount

kubectl get secret
kubectl get pods pod-name -o yaml   
#  找到volumes选项，定位到-name，secretName
#  找到volumeMounts选项，定位到mountPath: /var/run/secrets/kubernetes.io/serviceaccount

总结：

无论是ConfigMap，Secret，还是DownwardAPI，都是通过ProjectedVolume实现的，可以通过APIServer将信息放到Pod中进行使用。

七、指定Pod所运行的Node

(1)给node打上label

kubectl get nodes

kubectl label nodes worker02-kubeadm-k8s name=ghy

(2)查看node是否有上述label

kubectl describe node worker02-kubeadm-k8s

(3)部署一个mysql的pod

vi mysql-pod.yaml

apiVersion: v1
kind: ReplicationController
metadata:
  name: mysql-rc
  labels:
    name: mysql-rc
spec:
  replicas: 1
  selector:
    name: mysql-pod
  template:
    metadata:
      labels: 
        name: mysql-pod
    spec:
      nodeSelector: 
        name: ghy
      containers:
      - name: mysql
        image: mysql
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 3306
        env:
        - name: MYSQL_ROOT_PASSWORD
          value: "mysql"
      
---
apiVersion: v1
kind: Service
metadata:
  name: mysql-svc
  labels: 
    name: mysql-svc
spec:
  type: NodePort
  ports:
  - port: 3306
    protocol: TCP
    targetPort: 3306
    name: http
    nodePort: 32306
  selector:
    name: mysql-pod

(4)查看pod运行详情

kubectl apply -f mysql-pod.yaml

kubectl get pods -o wide