一.ConfigMap
1.概述
ConfigMap资源，简称CM资源，它生成的键值对数据，存储在ETCD数据库中
应用场景：主要是对应用程序的配置
pod通过env变量引入ConfigMap，或者通过数据卷挂载volume的方式引入ConfigMap资源
官方解释：
configMap 卷提供了向 Pod 注入配置数据的方法。 ConfigMap 对象中存储的数据可以被 configMap 类型的卷引用，然后被 Pod 中运行的容器化应用使用。
引用 configMap 对象时，你可以在卷中通过它的名称来引用。 你可以自定义 ConfigMap 中特定条目所要使用的路径。 下面的配置显示了如何将名为 log-config 的 ConfigMap 挂载到名为 configmap-pod 的 Pod 中
2.查看k8s集群系统中都有哪些资源类型
[root@master demo]# kubectl api-resources 
3.ConfigMap资源管理
· 创建工作目录
[root@master demo]# mkdir configmap
[root@master demo]# cd configmap· 创建ConfigMap资源
1.声明式创建ConfigMap资源
· 编辑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
2.响应式创建ConfigMap资源
· 命令行创建ConfigMap资源
[root@master a]# kubectl create cm cm02 --from-literal=test=111 --from-literal=d=ddd
configmap/cm02 created
· 查看cm资源
[root@master a]# kubectl get cm cm02
NAME DATA AGE
cm02 2 14s
3.指定文件方式创建cm资源
· 编辑一个文件
[root@master a]# cat > 1.txt <<EOF
> aaaa
> bbbb
> cccc
> dddd
> 1111
> 2222
> 3333
> 4444
> EOF
·创建查看ConfigMap资源
[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
4.查看cm资源的详细信息
[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>
5.删除cm资源
[root@master a]# kubectl delete cm --all
configmap "cm01" deleted
configmap "cm02" deleted
configmap "cm03" deleted
configmap "kube-root-ca.crt" deleted
4.pod引入CM资源
pod引入cm资源的方式，有两种，env变量引入和volume挂载卷引入
·env变量引入
1.编辑并创建cm资源
[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
2.创建pod资源，env变量引入cm
[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
3.进入容器查看变量是否引入成功
[root@master a]# kubectl exec demo111 -it -- sh
/ # env
· volume挂载卷引入cm
1.编辑pod资源清单
[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
2.创建查看资源
[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
3. 进入pod容器查看是否挂载成功，变成文件
[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
secrets资源，类似于configmap资源，只是secrets资源是用来传递重要的信息的；
secret資源就是將value的值使用base64编译后传输，当pod引用secret后，k8s会自动将其base64的编码，反编译回正常的字符串；
官方解释：
Secret 是一种包含少量敏感信息例如密码、令牌或密钥的对象。 这样的信息可能会被放在 Pod 规约中或者镜像中。 使用 Secret 意味着你不需要在应用程序代码中包含机密数据。
由于创建 Secret 可以独立于使用它们的 Pod， 因此在创建、查看和编辑 Pod 的工作流程中暴露 Secret（及其数据）的风险较小。 Kubernetes 和在集群中运行的应用程序也可以对 Secret 采取额外的预防措施， 例如避免将敏感数据写入非易失性存储。
1.创建secrets资源
·准备将“想要的数据”使用base64进行编码
#正向编码
[root@worker2 ~]# echo demotest | base64
ZGVtb3Rlc3QK
[root@worker2 ~]# echo kubernets | base64
a3ViZXJuZXRzCg==
#反向编码
[root@worker2 ~]# echo ZGVtb3Rlc3QK | base64 -d
demotest
·声明式创建secrets资源
1.编辑secrets资源清单
[root@master secrets]# cat 01-secret.yaml
apiVersion: v1
kind: Secret
metadata:
name: demo1
#用户自定义的类型（Opaque为自定义类型）
type: Opaque
data:
demotest: ZGVtb3Rlc3QK
kubernets: a3ViZXJuZXRzCg==
2.创建查看secret资源
[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
·响应式创建secret
[root@master secrets]# kubectl create secret generic demo2 --from-literal=testa=dGVzdGEK --from-literal=testb=dGVzdGIK
查看secrets资源
[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
2.pod引用secret资源
· pod资源env环境变量引用secret资源
1.编辑pod资源
[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
2.创建查看pod
[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>
3.登录pod资源查看env变量
[root@master secrets]# kubectl exec demo323 -it -- sh
/ # env
· pod资源volume存储卷引用secret资源
1.编辑pod资源
[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: /demos2.创建查看pod
[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>
3.进入容器内查看是否挂在为文件
[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
3.secret类型之-私有镜像仓库使用
创建Docker harbor的secret信息：
因为，k8s拉取镜像与Docker拉取镜像是不同的方式，所以k8s需要创建一个属于自己的拉取镜像的方式
generic： 从本地file, directory或者literal value创建一个 secret（这是大多数情况使用的）
也就是资源清单中的type：Opaque是一个意思
docker-registry：创建一个给Docker registry容器镜像仓库使用的secret
tls： 创建一个TLS secret
·harbor创建私有仓库
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
· 创建拉取镜像的secret资源
1.响应式创建secret资源
[root@master secrets]# kubectl create secret docker-registry demo-harbor --docker-username=admin --docker-password=111aaa.. [email protected] --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
· 创建pod引用拉取镜像的secret资源
[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
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
1.查看静态pod的路径
[root@master ~]# vim /var/lib/kubelet/config.yaml
......
staticPodPath: /etc/kubernetes/manifests2.静态pod的查看与含义
这里面的名称都是我们的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>
