您当前的位置： 首页 > 慢生活 > 程序人生 网站首页程序人生

38、存储 configmap（2）

发布时间：2022-12-31 18:25:54编辑：雪饮阅读（）

Step1

应用于环境变量的configmap

首先是创建configmap的模板

[root@k8s-master01 configmap]# mkdir env

[root@k8s-master01 configmap]# cd env

[root@k8s-master01 env]# vi env.yaml

[root@k8s-master01 env]# cat env.yaml

apiVersion: v1

kind: ConfigMap

metadata:

 name: env-config

 namespace: default

data:

 log_level: INFO

然后创建

[root@k8s-master01 env]# kubectl apply -f env.yaml

configmap/env-config created

就有了这个env-config

[root@k8s-master01 env]# kubectl get cm

NAME             DATA   AGE

env-config       1      2m23s

game-config      2      18h

game-config2     1      18h

special-config   2      18h

查看这个configmap

[root@k8s-master01 env]# kubectl describe cm env-config

Name:         env-config

Namespace:    default

Labels:       <none>

Annotations:  kubectl.kubernetes.io/last-applied-configuration:

                {"apiVersion":"v1","data":{"log_level":"INFO"},"kind":"ConfigMap","metadata":{"annotations":{},"name":"env-config","namespace":"default"}}

 

Data

====

log_level:

----

INFO

Events:  <none>

再查看昨天创建的这个special-config

[root@k8s-master01 env]# kubectl describe cm special-config

Name:         special-config

Namespace:    default

Labels:       <none>

Annotations:  <none>

 

Data

====

special.how:

----

very

special.type:

----

charm

Events:  <none>

然后我们先来清理一波之前的工作残留

[root@k8s-master01 env]# kubectl delete deployment --all

deployment.extensions "deployment1" deleted

deployment.extensions "deployment3" deleted

[root@k8s-master01 env]# kubectl delete ingress --all

ingress.extensions "https" deleted

ingress.extensions "ingress-with-auth" deleted

ingress.extensions "nginx-test" deleted

ingress.extensions "nginx-www1" deleted

[root@k8s-master01 env]# kubectl get svc

NAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE

kubernetes   ClusterIP   10.96.0.1        <none>        443/TCP        17d

nginx-dm     NodePort    10.97.54.233     <none>        80:32033/TCP   3d17h

svc-1        ClusterIP   10.99.93.214     <none>        80/TCP         41h

svc-3        ClusterIP   10.105.243.106   <none>        80/TCP         41h

[root@k8s-master01 env]# kubectl delete svc svc-1 svc-3 nginx-dm

service "svc-1" deleted

service "svc-3" deleted

service "nginx-dm" deleted

然后创建pod

[root@k8s-master01 env]# cat pod.yaml

apiVersion: v1

kind: Pod

metadata:

 name: dapi-test-pod

spec:

 containers:

  - name: test-container

    image: hub.atguigu.com/library/myapp:v1

    command: [ "/bin/sh", "-c", "env" ]

    env:

     - name: SPECIAL_LEVEL_KEY

       valueFrom:

        configMapKeyRef:

         name: special-config

         key: special.how

     - name: SPECIAL_TYPE_KEY

       valueFrom :

        configMapKeyRef:

         name: special-config

         key: special.type

    envFrom:

     - configMapRef:

        name: env-config

 restartPolicy: Never

[root@k8s-master01 env]# kubectl create -f pod.yaml

pod/dapi-test-pod created

可以看到pod创建了

[root@k8s-master01 env]# kubectl get pod

NAME            READY   STATUS      RESTARTS   AGE

dapi-test-pod   0/1     Completed   0          49s

查看pod日志

[root@k8s-master01 env]# kubectl log dapi-test-pod

log is DEPRECATED and will be removed in a future version. Use logs instead.

MYAPP_SVC_PORT_80_TCP_ADDR=10.98.57.156

KUBERNETES_PORT=tcp://10.96.0.1:443

KUBERNETES_SERVICE_PORT=443

MYAPP_SVC_PORT_80_TCP_PORT=80

HOSTNAME=dapi-test-pod

SHLVL=1

MYAPP_SVC_PORT_80_TCP_PROTO=tcp

HOME=/root

SPECIAL_TYPE_KEY=charm

MYAPP_SVC_PORT_80_TCP=tcp://10.98.57.156:80

NGINX_VERSION=1.12.2

KUBERNETES_PORT_443_TCP_ADDR=10.96.0.1

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

KUBERNETES_PORT_443_TCP_PORT=443

KUBERNETES_PORT_443_TCP_PROTO=tcp

MYAPP_SVC_SERVICE_HOST=10.98.57.156

SPECIAL_LEVEL_KEY=very

log_level=INFO

KUBERNETES_SERVICE_PORT_HTTPS=443

KUBERNETES_PORT_443_TCP=tcp://10.96.0.1:443

PWD=/

KUBERNETES_SERVICE_HOST=10.96.0.1

MYAPP_SVC_SERVICE_PORT=80

MYAPP_SVC_PORT=tcp://10.98.57.156:80

这个日志中这3个标红的就是我们configmap注入进来的环境变量咯

log_level=INFO来自于pod模板中envFrom来自于env-config这个configmap

SPECIAL_LEVEL_KEY=very来自于昨天创建的special_config的configmap的key为special.how的值

SPECIAL_TYPE_KEY=charm来自于昨天创建的special_config的configmap的key为special.type的值

Step2

command，pod命令行中使用configmap

创建第二个pod

[root@k8s-master01 env]# cat pod1.yaml

apiVersion: v1

kind: Pod

metadata:

 name: dapi-test-pod66

spec:

 containers:

  - name: test-container

    image: hub.atguigu.com/library/myapp:v1

    command: [ "/bin/sh", "-c", "echo $(SPECIAL_LEVEL_KEY) $(SPECIAL_TYPE_KEY)" ]

    env:

     - name: SPECIAL_LEVEL_KEY

       valueFrom:

        configMapKeyRef:

         name: special-config

         key: special.how

     - name: SPECIAL_TYPE_KEY

       valueFrom:

        configMapKeyRef:

         name: special-config

         key: special.type

 restartPolicy: Never

[root@k8s-master01 env]# kubectl create -f pod1.yaml

pod/dapi-test-pod66 created

[root@k8s-master01 env]# kubectl get pod

NAME              READY   STATUS      RESTARTS   AGE

dapi-test-pod     0/1     Completed   0          36m

dapi-test-pod66   0/1     Completed   0          5s

由于command中的输出是标准输出（一般的），而pod的log一般的就是标准输出的日志，所以上面的环境变量的configmap的配置就可以被在日志中记录，我们可以查看日志

[root@k8s-master01 env]# kubectl log dapi-test-pod66

log is DEPRECATED and will be removed in a future version. Use logs instead.

very charm

可见pod命令行中也是可以用configmap的配置的引用的。

Step3

创建第三个pod，实验下configmap挂载到pod的卷上

[root@k8s-master01 env]# cat pod2.yaml

apiVersion: v1

kind: Pod

metadata:

 name: dapi-test-pod11

spec:

 containers:

  - name: test-container

    image: hub.atguigu.com/library/myapp:v1

    command: [ "/bin/sh", "-c","sleep 3600s" ]

    volumeMounts:

    - name: config-volume

      mountPath: /etc/config

 volumes:

  - name: config-volume

    configMap:

     name: special-config

 restartPolicy: Never

这里挂载的卷自定义为config-volume，其指定的configmap，所指定的configmap来自于special-config这个configmap，那么这个自定义的config-volume卷挂载于pod的/etc/config路径

[root@k8s-master01 env]# kubectl create -f pod2.yaml

pod/dapi-test-pod11 created

[root@k8s-master01 env]# kubectl get pod

NAME              READY   STATUS      RESTARTS   AGE

dapi-test-pod     0/1     Completed   0          47m

dapi-test-pod11   1/1     Running     0          13s

dapi-test-pod66   0/1     Completed   0          11m

然后可以看下这次configmap挂载到pod的卷中

[root@k8s-master01 env]# kubectl exec dapi-test-pod11 -it -- /bin/sh

/ # ls /etc/config

special.how   special.type

/ # cat /etc/config/special.how

very/ # cat /etc/config/special.type

charm/ #

确实是没有问题的

可见挂载卷的方式卷路径相当于这个configmap的某种意义上来说是目录名，然后卷中的每个文件名映射挂载的这个configmap的每个key，卷中的每个文件名对应里面的文件内容则映射挂载的这个configmap的每个key对应的key的值。

Step4

然后我们再次清理下pod和cm

[root@k8s-master01 env]# kubectl delete pod --all

pod "dapi-test-pod" deleted

pod "dapi-test-pod11" deleted

pod "dapi-test-pod66" deleted

[root@k8s-master01 env]# kubectl delete cm --all

configmap "env-config" deleted

configmap "game-config" deleted

configmap "game-config2" deleted

configmap "special-config" deleted

[root@k8s-master01 env]# kubectl get cm

No resources found.

然后接下来我们玩玩所谓的热更新

然后创建configmap与用改configmap的pod于一起

[root@k8s-master01 configmap]# cat 111.yaml

apiVersion: v1

kind: ConfigMap

metadata:

 name: log-config

 namespace: default

data:

 log_level: INFO

---

apiVersion: extensions/v1beta1

kind: Deployment

metadata:

 name: my-nginx

spec:

 replicas: 1

 template:

  metadata:

   labels:

    run: my-nginx

  spec:

   containers:

   - name: my-nginx

     image: hub.atguigu.com/library/myapp:v1

     ports:

     - containerPort: 80

     volumeMounts:

     - name: config-volume

       mountPath: /etc/config

   volumes :

    - name: config-volume

      configMap:

       name: log-config

然后创建

[root@k8s-master01 configmap]# kubectl apply -f 111.yaml

configmap/log-config created

pod没有问题

[root@k8s-master01 configmap]# kubectl get pod

NAME                        READY   STATUS    RESTARTS   AGE

my-nginx-7b55868ff4-ld9v8   1/1     Running   0          61s

由于我们这次所用的configmap中只有一个log_level这个key并且我们和上面step3一样实验挂载卷的方式，所以我们可以直接看到该pod中这个log_level的值

[root@k8s-master01 configmap]# kubectl exec my-nginx-7b55868ff4-ld9v8 -it -- cat /etc/config/log_level

INFO

这次为什么没有sleep 3600s了？

因为这次没有实验command就不会覆盖掉默认的pod的脚本吧，而nginx的pod的默认执行命令肯定就是让nginx运行起来，然后常驻内存呗。

那么如何热更新configmap？由于这次使用的configmap是log-config，所以我们

[root@k8s-master01 configmap]# kubectl edit configmap log-config

进入一个vi编辑器里面，内容如：

# Please edit the object below. Lines beginning with a '#' will be ignored,

# and an empty file will abort the edit. If an error occurs while saving this file will be

# reopened with the relevant failures.

#

apiVersion: v1

data:

  log_level: INFO

kind: ConfigMap

metadata:

  annotations:

    kubectl.kubernetes.io/last-applied-configuration: |

      {"apiVersion":"v1","data":{"log_level":"INFO"},"kind":"ConfigMap","metadata":{"annotations":{},"name":"log-config","namespace":"default"}}

  creationTimestamp: "2022-12-31T10:13:19Z"

  name: log-config

  namespace: default

  resourceVersion: "184219"

  selfLink: /api/v1/namespaces/default/configmaps/log-config

  uid: e4663b75-396d-4a76-a6fe-e6c17df43867

我们就将这两个INFO修改为DEBUG吧

一般的保存后就能看到效果了

[root@k8s-master01 configmap]# kubectl edit configmap log-config

configmap/log-config edited

[root@k8s-master01 configmap]# kubectl exec my-nginx-7b55868ff4-ld9v8 -it -- cat /etc/config/log_level

DEBUG[root@k8s-master01 configmap]#

有说是保存后稍待片刻才行，可能我这里稍微耽误了一下，所以当我再次查看的时候已经是变更了之后的了。

这样如果用在nginx就实现了nginx配置文件的热更新，不过nginx的机制是配置文件更新后还要重新reload，所以可以让pod重启下即可

当然，也有比较“优雅”的解决方案



这里就不实验了。