ConfigMap资源,简称CM资源,它生成的键值对数据,存储在ETCD数据库中
应用场景:主要是对应用程序的配置
pod通过env变量引入ConfigMap,或者通过数据卷挂载volume的方式引入ConfigMap资源
官方解释:
configMap 卷提供了向 Pod 注入配置数据的方法。 ConfigMap 对象中存储的数据可以被 configMap 类型的卷引用,然后被 Pod 中运行的容器化应用使用。
引用 configMap 对象时,你可以在卷中通过它的名称来引用。 你可以自定义 ConfigMap 中特定条目所要使用的路径。 下面的配置显示了如何将名为 log-config 的 ConfigMap 挂载到名为 configmap-pod 的 Pod 中
[root@master demo]# kubectl api-resources
- [root@master demo]# mkdir configmap
- [root@master demo]# cd configmap
- [root@master a]# cat 01-cm.yaml
- apiVersion: v1
- kind: ConfigMap
- metadata:
- name: cm01
- #声明cm资源的数据
- data:
- #第一种写法【key:value】
- demo: demo-cm
- k8s: kubernets
- #第二种写法【key:| value value value...】
- test: |
- a=a
- b=b
- c=c
· 创建查看configMap资源
- [root@master a]# kubectl apply -f 01-cm.yaml
- configmap/cm01 created
- [root@master a]# kubectl get cm cm01
- NAME DATA AGE
- cm01 3 15s
- [root@master a]# kubectl create cm cm02 --from-literal=test=111 --from-literal=d=ddd
- configmap/cm02 created
- [root@master a]# kubectl get cm cm02
- NAME DATA AGE
- cm02 2 14s
- [root@master a]# cat > 1.txt <<EOF
- > aaaa
- > bbbb
- > cccc
- > dddd
- > 1111
- > 2222
- > 3333
- > 4444
- > EOF
- [root@master a]# kubectl create cm cm03 --from-file=1.txt=1.txt
- configmap/cm03 created
- [root@master a]# kubectl get cm cm03
- NAME DATA AGE
- cm03 1 8s
- [root@master a]# kubectl describe cm cm03
- Name: cm03
- Namespace: default
- Labels: <none>
- Annotations: <none>
-
- Data
- ====
- 1.txt:
- ----
- aaaa
- bbbb
- cccc
- dddd
- 1111
- 2222
- 3333
- 4444
-
-
- BinaryData
- ====
-
- Events: <none>
- [root@master a]# kubectl delete cm --all
- configmap "cm01" deleted
- configmap "cm02" deleted
- configmap "cm03" deleted
- configmap "kube-root-ca.crt" deleted
pod引入cm资源的方式,有两种,env变量引入和volume挂载卷引入
- [root@master a]# cat 01-cm.yaml
- apiVersion: v1
- kind: ConfigMap
- metadata:
- name: cm01
- #声明cm资源的数据
- data:
- #第一种写法【key:value】
- demo: demo-cm
- k8s: kubernets
- #第二种写法【key:| value value value。。。】
- test: |
- a=a
- b=b
- c=c
- [root@master a]# kubectl apply -f 01-cm.yaml
- configmap/cm01 created
- [root@master a]# cat pod-env.yaml
- apiVersion: v1
- kind: Pod
- metadata:
- name: demo111
- spec:
- containers:
- - name: demo-e
- image: nginx:1.20.1-alpine
- env:
- #引入一个变量
- - name: env-cm01
- #从其他位置引入变量
- valueFrom:
- #声明从ConfigMap中引入变量
- configMapKeyRef:
- #引入变量ConfigMap的名称
- name: cm01
- key: demo
- #引入第二个变量
- - name: env-cm02
- valueFrom:
- configMapKeyRef:
- name: cm01
- #引用ConfigMap中的哪个key
- key: test
- [root@master a]# kubectl apply -f pod-env.yaml
- pod/demo111 created
- [root@master a]# kubectl get pods
- NAME READY STATUS RESTARTS AGE
- demo 1/1 Running 1 (48m ago) 52m
- demo111 1/1 Running 0 9s
- [root@master a]# kubectl exec demo111 -it -- sh
- / # env
- [root@master a]# cat pod-env.yaml
- apiVersion: v1
- kind: Pod
- metadata:
- name: demo111
- spec:
- #声明pod存储卷
- volumes:
- - name: vol-cm
- #声明挂载cm资源
- configMap:
- #指定cm组员名称
- name: cm01
- #如果不写items,则引用cm资源中全部的key:value作为文件挂载
- items:
- #cm资源的key是什么
- - key: demo
- #key的value值挂载到容器中变成文件内容,文件名叫什么
- path: demo.txt
- - key: test
- path: test.txt
- containers:
- - name: demo-d
- image: nginx:1.20.1-alpine
- volumeMounts:
- - name: vol-cm
- mountPath: /demo
- [root@master a]# kubectl apply -f pod-env.yaml
- pod/demo111 created
- [root@master a]# kubectl get pods
- NAME READY STATUS RESTARTS AGE
- demo111 1/1 Running 0 35s
- [root@master a]# kubectl exec demo111 -it -- sh
- / # ls
- bin docker-entrypoint.sh media root sys
- demo etc mnt run tmp
- dev home opt sbin usr
- docker-entrypoint.d lib proc srv var
- / # cd demo
- /demo # ls
- demo.txt test.txt
- /demo # cat demo.txt
- demo-cm
- /demo # cat test.txt
- a=a
- b=b
- c=c
注:当pod挂载cm资源到容器的目录后,若容器的原目录中有文件,则会被清空,那么如何做到,及把cm资源挂载成为文件到容器的指定目录,又能保证容器原目录中的文件不清空呐?
subPath
- [root@master a]# cat pod-env.yaml
- apiVersion: v1
- kind: Pod
- metadata:
- name: demo111
- spec:
- volumes:
- - name: vol-cm
- configMap:
- name: cm01
- items:
- - key: demo
- path: demo.txt
- - key: test
- path: test.txt
- containers:
- - name: demo-d
- image: nginx:1.20.1-alpine
- volumeMounts:
- - name: vol-cm
- mountPath: /demo
- #如果subPath不指定任何值(默认),则默认容器挂载路径为空,表示清空挂载点;
- #如果subPath指定名称和cm的Path相同,表示仅仅挂载这个文件,不清空挂在的目录保留原本容器路径的文件;
- #也就是说volumes>>configMap>items>path只有与subPath的值相等时,才是挂载文件;否则就是挂载目录;会清空目录;
- subPath: test
- #resdOnly: true #只读设置;表示不允许容器内编辑或删除这个文件;
secrets资源,类似于configmap资源,只是secrets资源是用来传递重要的信息的;
secret資源就是將value的值使用base64编译后传输,当pod引用secret后,k8s会自动将其base64的编码,反编译回正常的字符串;
官方解释:
Secret 是一种包含少量敏感信息例如密码、令牌或密钥的对象。 这样的信息可能会被放在 Pod 规约中或者镜像中。 使用 Secret 意味着你不需要在应用程序代码中包含机密数据。
由于创建 Secret 可以独立于使用它们的 Pod, 因此在创建、查看和编辑 Pod 的工作流程中暴露 Secret(及其数据)的风险较小。 Kubernetes 和在集群中运行的应用程序也可以对 Secret 采取额外的预防措施, 例如避免将敏感数据写入非易失性存储。
- #正向编码
- [root@worker2 ~]# echo demotest | base64
- ZGVtb3Rlc3QK
- [root@worker2 ~]# echo kubernets | base64
- a3ViZXJuZXRzCg==
-
-
- #反向编码
- [root@worker2 ~]# echo ZGVtb3Rlc3QK | base64 -d
- demotest
- [root@master secrets]# cat 01-secret.yaml
- apiVersion: v1
- kind: Secret
- metadata:
- name: demo1
- #用户自定义的类型(Opaque为自定义类型)
- type: Opaque
- data:
- demotest: ZGVtb3Rlc3QK
- kubernets: a3ViZXJuZXRzCg==
- [root@master secrets]# kubectl apply -f .
- secret/demo1 created
- [root@master secrets]# kubectl get secrets
- NAME TYPE DATA AGE
- default-token-rnwqs kubernetes.io/service-account-token 3 9d
- demo1 Opaque 2 2m40s
[root@master secrets]# kubectl create secret generic demo2 --from-literal=testa=dGVzdGEK --from-literal=testb=dGVzdGIK
- [root@master secrets]# kubectl get secrets
- NAME TYPE DATA AGE
- default-token-rnwqs kubernetes.io/service-account-token 3 9d
- demo1 Opaque 2 2m40s
- demo2 Opaque 2 15s
Opaque为自定义类型
generic: 从本地file, directory或者literal value创建一个 secret(这是大多数情况使用的)
也就是资源清单中的type:Opaque是一个意思
docker-registry:创建一个给Docker registry容器镜像仓库使用的secret
tls: 创建一个TLS secret
原文链接:https://blog.csdn.net/flq18210105507/article/details/120749275
- [root@master secrets]# cat 01-pod.yaml
- apiVersion: v1
- kind: Pod
- metadata:
- name: demo323
- spec:
- containers:
- - name: nginx-d
- image: nginx:1.20.1-alpine
- env:
- - name: secret-env01
- valueFrom:
- #声明引用sercet
- secretKeyRef:
- #声明secret名称
- name: demo1
- #声明secret的key
- key: demotest
- - name: secret-env02
- valueFrom:
- secretKeyRef:
- name: demo1
- key: kubernets
- [root@master secrets]# kubectl apply -f 01-pod.yaml
- pod/demo323 created
- [root@master secrets]# kubectl get pods -o wide
- NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
- demo323 1/1 Running 0 13s 10.100.1.35 worker1 <none> <none>
- [root@master secrets]# kubectl exec demo323 -it -- sh
- / # env
- [root@master secrets]# cat 01-pod.yaml
- apiVersion: v1
- kind: Pod
- metadata:
- name: demo333
- spec:
- volumes:
- - name: vol-secret
- secret:
- secretName: demo1
- containers:
- - name: nginx-d
- image: nginx:1.20.1-alpine
- volumeMounts:
- - name: vol-secret
- mountPath: /demos
- [root@master secrets]# kubectl apply -f 01-pod.yaml
- pod/demo333 created
- [root@master secrets]# kubectl get pods -o wide
- NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
- demo333 1/1 Running 0 11s 10.100.1.36 worker1 <none> <none>
- [root@master secrets]# kubectl exec demo333 -it -- sh
- / # ls
- bin docker-entrypoint.sh media root sys
- demos etc mnt run tmp
- dev home opt sbin usr
- docker-entrypoint.d lib proc srv var
- / # cd demos
- /demos # ls
- demotest kubernets
- /demos # cat demotest
- demotest
- /demos # cat kubernets
- kubernets
创建Docker harbor的secret信息:
因为,k8s拉取镜像与Docker拉取镜像是不同的方式,所以k8s需要创建一个属于自己的拉取镜像的方式
generic: 从本地file, directory或者literal value创建一个 secret(这是大多数情况使用的)
也就是资源清单中的type:Opaque是一个意思
docker-registry:创建一个给Docker registry容器镜像仓库使用的secret
tls: 创建一个TLS secret
harbor创建私有仓库
- [root@worker2 ~]# docker login -uadmin -p111aaa.. harbor.test.com
-
- [root@worker2 ~]# docker tag nginx:1.20.1-alpine harbor.test.com/demo/nginx:1.20.1-alpine
- [root@worker2 ~]# docker push harbor.test.com/demo/nginx:1.20.1-alpine
- The push refers to repository [harbor.test.com/demo/nginx]
- 9d5b000ce7c7: Pushed
- b8dbe22b95f7: Pushed
- c39c1c35e3e8: Pushed
- 5f66747c8a72: Pushed
- 15d7cdc64789: Pushed
- 7fcb75871b21: Pushed
- 1.20.1-alpine: digest: sha256:34c4a6f3b4d5e5f886bfa6a32642ecf023282c82c03d37901bc1f30823abbd5d size: 1568
[root@master secrets]# kubectl create secret docker-registry demo-harbor --docker-username=admin --docker-password=111aaa.. --docker-email=123@qq.com --docker-server=harbor.test.com
- [root@master secrets]# kubectl get secret
- NAME TYPE DATA AGE
- default-token-rnwqs kubernetes.io/service-account-token 3 9d
- demo-harbor kubernetes.io/dockerconfigjson 1 11s
- [root@master secrets]# cat 01-pod.yaml
- apiVersion: v1
- kind: Pod
- metadata:
- name: demo-harbor00
- spec:
- imagePullSecrets:
- - name: demo-harbor
- containers:
- - name: harbortest
- image: harbor.test.com/demo/nginx:1.20.1-alpine
- [root@master secrets]# kubectl apply -f 01-pod.yaml
- pod/demo-harbor00 created
- [root@master secrets]# kubectl get pods -o wide
- NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
- demo-harbor00 1/1 Running 0 14s 10.100.1.37 worker1 <none> <none>
pod创建流程
用户通过 kubectl create 命令(或其他等效方式)向 Kubernetes API Server 发起一个创建 Pod 的请求。这个请求包含了 Pod 的定义,通常是一个 YAML 或 JSON 格式的文件。 API Server 接收请求并处理:
Kubernetes API Server 接收到创建 Pod 的请求后,会对请求进行验证和授权检查。 API Server 不会直接创建 Pod,而是将这个请求转化为一个内部表示(如一个含有 Pod 创建信息的 YAML 格式的对象)。 写入 Etcd 数据库:
API Server 将这个 Pod 对象的信息写入到 Etcd 数据库。Etcd 作为 Kubernetes 的数据存储,保存了集群的状态和配置。 Scheduler 进行调度:
Kubernetes Scheduler 持续监视 API Server,检查新的或未被调度的 Pod。 当 Scheduler 发现一个新的 Pod(pod.spec.Node == null 表示这个 Pod 还没有被调度到任何节点),它将根据资源需求、亲和性规则、污点和容忍度等因素选择一个合适的节点。 一旦选择了节点,Scheduler 将更新该 Pod 的信息,指定其运行在选择的节点上,并将这个更新写回到 Etcd。 Kubelet 监听并创建 Pod:
每个节点上的 Kubelet 进程持续监视 Etcd,查找分配给自己节点的新任务。 当 Kubelet 发现有新的 Pod 分配到它所在的节点,它会根据 Pod 定义开始创建和启动 Pod 中的容器。 Kubelet 调用容器运行时(如 Docker)来实际启动容器,并设置必要的网络和存储配置。 Pod 状态更新和汇报:
在 Pod 创建过程中,Kubelet 将 Pod 的状态更新回 API Server。这些状态信息包括 Pod 是否成功启动,运行中的容器等。 API Server 更新 Etcd 中的状态信息,确保集群状态的一致性。
原文链接:https://blog.csdn.net/weixin_48126010/article/details/136690275
- [root@master ~]# vim /var/lib/kubelet/config.yaml
-
- ......
- staticPodPath: /etc/kubernetes/manifests
这里面的名称都是我们的k8s集群中master节点的组成组件
- [root@master secrets]# ll /etc/kubernetes/manifests/
- 总用量 16
- -rw------- 1 root root 2274 7月 5 14:44 etcd.yaml
- -rw------- 1 root root 3403 7月 10 20:26 kube-apiserver.yaml
- -rw------- 1 root root 2880 7月 5 14:44 kube-controller-manager.yaml
- -rw------- 1 root root 1465 7月 5 14:44 kube-scheduler.yaml
静态pod就是kubelet自己监视的目录,如果这个目录有pod资源清单,则会在当前节点自动创建pod;不需要手动kubectl apply -f xxx.yaml
静态pod的创建,只在当前节点上创建,pod的名称会自动给你加一个当前节点名称后缀;
静态pod,只要有yaml文件在这个目录,就无法删除;
- [root@master pod]# mv 01-pod-nginx.yaml /etc/kubernetes/manifests/
- [root@master pod]# kubectl get pods -o wide
- NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
- m-nginx-master 0/1 ContainerCreating 0 9s <none> master <none> <none>