标签：kubectl 进阶 Kubernetes 创建 yaml pod Pod name
一、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
标签：kubectl,进阶,Kubernetes,创建,yaml,pod,Pod,name 来源： https://www.cnblogs.com/xing1/p/15841115.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。