一、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