一.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: /demos
2.创建查看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.. --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

· 创建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/manifests

2.静态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>

Logo

权威|前沿|技术|干货|国内首个API全生命周期开发者社区

更多推荐