Kubernetes配置管理

Kubernetes配置管理

ConfigMap

对于应用的可变配置在 Kubernetes 中是通过一个 ConfigMap 资源对象来实现的,许多应用经常会有从配置文件、命令行参数或者环境变量中读取一些配置信息的需求,这些配置信息我们肯定不会直接写死到应用程序中,比如一个应用连接一个 redis 服务,下一次想更换一个,还得重新去修改代码,重新制作一个镜像,这肯定是不可取的,而ConfigMap 就给我们提供了向容器中注入配置信息的能力,不仅可以用来保存单个属性,还可以用来保存整个配置文件,比如我们可以用来配置一个 redis 服务的访问地址,也可以用来保存整个 redis 的配置文件。

创建

ConfigMap资源对象使用key-value形式的键值对来配置数据,这些数据可以在Pod里面使用,如下所示的资源清单:

apiVersion: v1 kind: ConfigMap metadata:   name: configMap data: # <map[string]string>   xxx 

详细的资源清单:

kind: ConfigMap apiVersion: v1 metadata:   name: cm-demo   namespace: default data:   data.1: hello   data.2: world   config: |     property.1=value-1     property.2=value-2     property.3=value-3 

其中配置数据在 data 属性下面进行配置,前两个被用来保存单个属性,后面一个被用来保存一个配置文件。

当然同样的我们可以使用kubectl create -f xx.yaml来创建上面的 ConfigMap 对象,但是如果我们不知道怎么创建 ConfigMap 的话,可以使用kubectl create configmap -h来查看关于创建 ConfigMap 的帮助信息:

Examples: # Create a new configmap named my-config based on folder bar kubectl create configmap my-config --from-file=path/to/bar  # Create a new configmap named my-config with specified keys instead of file basenames on disk kubectl create configmap my-config --from-file=key1=/path/to/bar/file1.txt --from-file=key2=/path/to/bar/file2.txt  # Create a new configmap named my-config with key1=config1 and key2=config2 kubectl create configmap my-config --from-literal=key1=config1 --from-literal=key2=config2 

可以看到可以从一个给定的目录来创建一个 ConfigMap 对象,比如我们有一个 testcm 的目录,该目录下面包含一些配置文件,redis 和 mysql 的连接信息,如下:

$ ls testcm/ mysql.conf  redis.conf  $ cat testcm/mysql.conf  host=127.0.0.1 port=3306  $ cat testcm/redis.conf  host=127.0.0.1 port=6379 

接着我们就可以使用 from-file 关键字来创建包含这个目录下面所以配置文件的 ConfigMap

$ kubectl create configmap cm-demo1 --from-file=testcm/ configmap/cm-demo1 created 

其中 from-file 参数指定在该目录下面的所有文件都会被用在 ConfigMap 里面创建一个键值对,键的名字就是文件名,值就是文件的内容。创建完成后,同样可以使用如下命令来查看 ConfigMap 列表:

$ kubectl get config NAME       DATA   AGE cm-demo1   2      10m 

可以看到已经创建了一个cm-demo1的ConfigMap对象,接着可以使用describe命令查看详细信息:

$ kubectl describe configmap cm-demo1 Name:         cm-demo1 Namespace:    default Labels:       <none> Annotations:  <none>  Data ==== mysql.conf: ---- host=127.0.0.1 port=3306  redis.conf: ---- host=127.0.0.1 port=6379  Events:  <none> 

可以看到两个 key 是 testcm 目录下面的文件名称,对应的 value 值就是文件内容,这里值得注意的是如果文件里面的配置信息很大的话,describe 的时候可能不会显示对应的值,要查看完整的键值,可以使用如下命令:

$ kubectl get cm cm-demo1 -o yaml apiVersion: v1 data:   mysql.conf: |     host=127.0.0.1     port=3306   redis.conf: |     host=127.0.0.1     port=6379 kind: ConfigMap metadata:   creationTimestamp: "2022-01-02T02:58:51Z"   managedFields:   - apiVersion: v1     fieldsType: FieldsV1     fieldsV1:       f:data:         .: {}         f:mysql.conf: {}         f:redis.conf: {}     manager: kubectl     operation: Update     time: "2022-01-02T02:58:51Z"   name: cm-demo1   namespace: default   resourceVersion: "4885"   selfLink: /api/v1/namespaces/default/configmaps/cm-demo1   uid: 1d4353cc-2bbb-44a0-9b25-b4ac4ca2cafe 

除了通过文件目录进行创建,我们也可以使用指定的文件进行创建 ConfigMap,同样的,以上面的配置文件为例,我们创建一个 redis 的配置的一个单独 ConfigMap 对象:

$ kubectl create configmap cm-demo2 --from-file=testcm/mysql.conf  configmap/cm-demo2 created 

可以看到一个关联mysql.conf 文件配置信息的 ConfigMap 对象创建成功了,另外值得注意的是 --from-file 这个参数可以使用多次,比如我们这里使用两次分别指定 redis.conf 和 mysql.conf 文件,就和直接指定整个目录是一样的效果了。

另外,通过帮助文档我们可以看到我们还可以直接使用字符串进行创建,通过 --from-literal 参数传递配置信息,同样的,这个参数可以使用多次,格式如下:

$ kubectl create configmap cm-demo3 --from-literal=db.host=localhost --from-literal=db.port=6379 configmap/cm-demo3 created  $ kubectl get cm cm-demo3 -o yaml apiVersion: v1 data:   db.host: localhost   db.port: "6379" kind: ConfigMap metadata:   creationTimestamp: "2022-01-02T03:19:39Z"   managedFields:   - apiVersion: v1     fieldsType: FieldsV1     fieldsV1:       f:data:         .: {}         f:db.host: {}         f:db.port: {}     manager: kubectl     operation: Update     time: "2022-01-02T03:19:39Z"   name: cm-demo3   namespace: default   resourceVersion: "7882"   selfLink: /api/v1/namespaces/default/configmaps/cm-demo3   uid: ac114686-f7cd-4da9-86a9-1c6fff3ad8ee 

使用

ConfigMap创建成功了,我们应该怎么在Pod中使用呢?ConfigMap这些配置数据可以通过以下方式在Pod的使用:

  • 设置环境变量的值
  • 在容器中设置命令行参数
  • 在数据卷里挂载配置文件

首先使用ConfigMap来填充我们的环境变量,如下所示Pod资源对象:

apiVersion: v1 kind: Pod metadata:   name: testcm1-pod spec:   containers:     - name: testcm1       image: busybox       command: ["/bin/sh", "-c", "env"]       env:         - name: DB_HOST           valueFrom:             configMapKeyRef:               name: cm-demo3               key: db.host         - name: DB_PORT           valueFrom:             configMapKeyRef:               name: cm-demo3               key: db.port       envFrom:         - configMapRef:             name: cm-demo1 

查看Pod输出日志:

$ kubectl logs testcm1-pod ...... DB_PORT=6379 mysql.conf=host=127.0.0.1 port=3306 redis.conf=host=127.0.0.1 port=6379 DB_HOST=localhost ...... 

发现与我们的预期一致,DB_HOST和DB_PORT都已经正常输出了,另外的环境变量是因为我们直接把cm-demo1给注入进来了。

另外我们也可以使用ConfigMap来设置命令行参数:

apiVersion: v1 kind: Pod metadata:   name: testcm2-pod spec:   containers:     - name: testcm1       image: busybox:1.30       command: ["/bin/sh", "-c", "echo $(DB_HOST) $(DB_PORT)"]       env:         - name: DB_HOST           valueFrom:             configMapKeyRef:               name: cm-demo3               key: db.host         - name: DB_PORT           valueFrom:             configMapKeyRef:               name: cm-demo3               key: db.port 

同样我们查看Pod的输出:

$ kubectl logs testcm2-pod localhost 6379 

另外也可以在数据卷中使用ConfigMap,如下资源对象所示:

apiVersion: v1 kind: Pod metadata:   name: testcm3-pod spec:   volumes:     - name: config-volume       configMap:         name: cm-demo2   containers:     - name: testcm3       image: busybox:1.30       command: ["/bin/sh", "-c", "cat /etc/config/mysql.conf"]       volumeMounts:         - name: config-volume           mountPath: /etc/config 

运行这个Pod,查看日志:

$ kubectl logs testcm3-pod host=127.0.0.1 port=3306 

当然,我们也可以在ConfigMap值被映射的数据卷里去控制路径,如下Pod所示:

apiVersion: v1 kind: Pod metadata:   name: testcm4-pod spec:   volumes:     - name: config-volume       configMap:         name: cm-demo1         items:           - key: redis.conf             path: path/redis.conf   # 定义容器里的挂载路径   containers:     - name: testcm3       image: busybox:1.30       command: ["/bin/sh", "-c", "cat /etc/config/path/redis.conf"]       volumeMounts:         - name: config-volume           mountPath: /etc/config 

运行这个Pod,查看输出日志:

$ kubectl logs testcm4-pod host=127.0.0.1 port=6379 

另外需要注意的是,当 ConfigMap 以数据卷的形式挂载进 Pod 的时,这时更新 ConfigMap(或删掉重建ConfigMap),Pod 内挂载的配置信息会热更新。这时可以增加一些监测配置文件变更的脚本,然后重加载对应服务就可以实现应用的热更新。

下面我们创建一个ConfigMap,以数据卷的形式挂载进Pod,动态更新配置信息。

apiVersion: v1 kind: ConfigMap metadata:   name: cm1 data:   info:     username:admin     password:123456 

将上面的ConfigMap挂载进Pod

apiVersion: v1 kind: Pod metadata:   name: cm-pod spec:   containers:     - name: nginx       image: nginx:1.17.1       volumeMounts:         - name: config           mountPath: /configMap/config   volumes:     - name: config       configMap:         name: cm1 

进入容器查看配置:

$ kubectl exec -it cm-pod /bin/bash kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl kubectl exec [POD] -- [COMMAND] instead.  root@cm-pod:~# cat /configMap/config/info  username:admin password:123456 

接下来我们进行动态修改ConfigMap:

$ kubectl edit cm cm1 # 这里我将原来的password:123456改成了admin 

修改完成后,再次进入容器查看配置:

$ kubectl exec -it cm-pod /bin/bash kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl kubectl exec [POD] -- [COMMAND] instead. root@cm-pod:/# cat /configMap/config/info  username:admin password:admin 

另外,只有通过 Kubernetes API 创建的 Pod 才能使用 ConfigMap,其他方式创建的(比如静态 Pod)不能使用;ConfigMap 文件大小限制为 1MB(ETCD 的要求)。

Secret

一般情况下 ConfigMap 是用来存储一些非安全的配置信息,如果涉及到一些安全相关的数据的话用 ConfigMap 就非常不妥了,因为ConfigMap 是明文存储的,这个时候我们就需要用到另外一个和ConfigMap非常相似的资源对象了:SecretSecret用来保存敏感信息,例如密码、OAuth 令牌和 ssh key 等等,将这些信息放在 Secret 中比放在 Pod 的定义中或者 Docker 镜像中要更加安全和灵活。

Secret主要使用有以下三种类型:

  • Opaque:base64 编码格式的 Secret,用来存储密码、密钥等;但数据也可以通过base64 –decode解码得到原始数据,所有加密性很弱。
  • kubernetes.io/dockerconfigjson:用来存储私有docker registry的认证信息。
  • kubernetes.io/service-account-token:用于被 ServiceAccount ServiceAccount 创建时 Kubernetes 会默认创建一个对应的 Secret 对象。Pod 如果使用了 ServiceAccount,对应的 Secret 会自动挂载到 Pod 目录 /run/secrets/kubernetes.io/serviceaccount 中。

Opaque Secret

Opaque 类型的数据是一个 map 类型,要求 value 必须是 base64 编码格式,比如我们来创建一个用户名为 admin,密码为 admin321 的 Secret 对象,首先我们需要先把用户名和密码做 base64 编码:

$ echo -n "admin" | base64 YWRtaW4= $ echo -n "admin123" | base64 YWRtaW4xMjM= 

接着们使用以上编码后的数据编写一个YAML文件:

apiVersion: v1 kind: Secret metadata:   name: s1 type:   Opaque data:   username: YWRtaW4=   password: YWRtaW4xMjM= 

创建后使用kubectl get secret命令进行查看:

$ kubectl get secret NAME                  TYPE                                  DATA   AGE default-token-lqrpd   kubernetes.io/service-account-token   3      171m s1                    Opaque                                2      8s 

其中 default-token-lqrpd 为创建集群时默认创建的 Secret,被 serviceacount/default 引用。

我们可以使用 describe 命令查看s1的详情:

kubectl describe secret s1 Name:         s1 Namespace:    default Labels:       <none> Annotations:   Type:         Opaque  Data ==== password:  8 bytes username:  5 bytes 

我们发现Data的数据没有直接显示出来,那么我们可以输出成yaml文件查看:

$ kubectl get secret s1 -o yaml apiVersion: v1 data:   password: YWRtaW4xMjM=   username: YWRtaW4= kind: Secret metadata:   annotations:     kubectl.kubernetes.io/last-applied-configuration: |       {"apiVersion":"v1","data":{"password":"YWRtaW4xMjM=","username":"YWRtaW4="},"kind":"Secret","metadata":{"annotations":{},"name":"s1","namespace":"default"},"type":"Opaque"}   creationTimestamp: "2022-01-02T05:20:21Z"   ...... 省略部分内容   name: s1   namespace: default   resourceVersion: "25976"   selfLink: /api/v1/namespaces/default/secrets/s1   uid: 1ca8d5b8-27c5-4044-8c02-e5ac8331584b type: Opaque 

创建好Secret对象后,有两种方式使用:以环境变量的形式和以Volume挂载形式

环境变量

环境变量和上面ConfigMap中的configMapKeyRef类似,在Secret中使用secertKeyRef

apiVersion: v1 kind: Pod metadata:   name: s1-pod spec:   containers:     - name: secret1       image: busybox:1.30       command: ["/bin/sh", "-c", "env"]       env:         - name: USERNAME           valueFrom:             secretKeyRef:               name: s1               key: username         - name: PASSWORD           valueFrom:             secretKeyRef:               name: s1               key: password 

同样查看Pod输出日志:

$ kubectl logs s1-pod ...... USERNAME=admin PASSWORD=admin123 ...... 

Volume挂载

同样使用一个Pod验证Volume挂载:

apiVersion: v1 kind: Pod metadata:   name: s1-pod1 spec:   containers:     - name: secret1       image: busybox:1.30       command: ["/bin/sh", "-c", "ls /etc/secrets"]       volumeMounts:         - name: secrets           mountPath: /etc/secrets   volumes:     - name: secrets       secret:         secretName: s1 

查看Pod的输出日志:

$ kubectl logs s1-pod1 password username 

可以看到 Secret 把两个 key 挂载成了两个对应的文件。当然如果想要挂载到指定的文件上面,是不是也可以使用上一节的方法:在 secretName 下面添加 items 指定 keypath

apiVersion: v1 kind: Pod metadata:   name: s1-pod2 spec:   volumes:     - name: secrets       secret:         secretName: s1         items:           - key: password             path: secrets/password   containers:     - name: s1       image: busybox:1.30       command: ["/bin/sh", "-c", "cat /etc/config/secrets/password"]       volumeMounts:         - name: secrets           mountPath: /etc/config 

同样查看pod的输出日志:

$ kubectl logs s1-pod2 admin123 

kubernetes.io/dockerconfigjson

除了上面Opaque这种类型外,还可以创建用户docker registry认证的Secret,直接使用kubectl create命令创建即可:

$ kubectl create secret docker-registry myregistry  	--docker-server=DOCKER_SERVER  	--docker-username=DOCKER_USER  	--docker-password=DOCKER_PASSWORD  	--docker-email=DOCKER_EMAIL 

我们可以通过指定文件的方式来创建镜像仓库认证任信息,需要主要对应的KEYTYPE

首先我们登录docker:

$ docker login Login with your Docker ID to push and pull images from Docker Hub. If you don't have a Docker ID, head over to https://hub.docker.com to create one. Username: huiyichanmian Password:  WARNING! Your password will be stored unencrypted in /root/.docker/config.json. Configure a credential helper to remove this warning. See https://docs.docker.com/engine/reference/commandline/login/#credentials-store  Login Succeeded 

登录成功后,docker会把登录信息存放在``~/.docker/config.json`这个文件里。

接下来我们创建镜像仓库认证信息:

$ kubectl create secret generic myregistry  	--from-file=.dockerconfigjson=/root/.docker/config.json  	--type=kubernetes.io/dockerconfigjson 

查看Secret列表:

$ kubectl get secrets NAME                  TYPE                                  DATA   AGE default-token-lqrpd   kubernetes.io/service-account-token   3      6h9m myregistry            kubernetes.io/dockerconfigjson        1      22s myregistry1           kubernetes.io/dockerconfigjson        1      42s 

myregistry对应的TYPEkubernetes.io/dockerconfigjson,同样可以使用describe命令来查看详细信息:

$ kubectl describe secret myregistry Name:         myregistry Namespace:    default Labels:       <none> Annotations:  <none>  Type:  kubernetes.io/dockerconfigjson  Data ==== .dockerconfigjson:  152 bytes 

Data区域的数据没有直接展示,我们使用-o yaml来输出:

$ kubectl get secret myregistry -o yaml apiVersion: v1 data:   .dockerconfigjson: ewoJImF1dGhzIjogewoJCSJodHRwczovL2luZGV4LmRvY2tlci5pby92MS8iOiB7CgkJCSJhdXRoIjogImFIVnBlV2xqYUdGdWJXbGhianBqYUhKcGMzUnBZVzQ0TWpVPSIKCQl9Cgl9LAoJIkh0dHBIZWFkZXJzIjogewoJCSJVc2VyLUFnZW50IjogIkRvY2tlci1DbGllbnQvMTguMDYuMy1jZSAobGludXgpIgoJfQp9 kind: Secret metadata:   creationTimestamp: "2022-01-02T08:38:01Z"   .....   uid: 37b13407-b5d2-4513-a8cf-6dee65acc2bf type: kubernetes.io/dockerconfigjson 

我们把上面data.dockerconfigjson的数据做一个base64解码:

$ echo eyJhdXRocyI6eyJET0NLRVJfU0VSVkVSIjp7InVzZXJuYW1lIjoiRE9DS0VSX1VTRVIiLCJwYXNzd29yZCI6IkRPQ0tFUl9QQVNTV09SRCIsImVtYWlsIjoiRE9DS0VSX0VNQUlMIiwiYXV0aCI6IlJFOURTMFZTWDFWVFJWSTZSRTlEUzBWU1gxQkJVMU5YVDFKRSJ9fX0= | base64 -d {"auths":{"DOCKER_SERVER":{"username":"DOCKER_USER","password":"DOCKER_PASSWORD","email":"DOCKER_EMAIL","auth":"RE9DS0VSX1VTRVI6RE9DS0VSX1BBU1NXT1JE"}}} 

如果我们需要拉去私有仓库中的Docker镜像,就需要使用上面的myregistry这个Secret:

apiVersion: v1 kind: Pod metadata:   name: foo spec:   containers:   - name: foo     image: 192.168.1.100:5000/test:v1   imagePullSecrets:   - name: myregistry 
  • ImagePullSecrets

    ImagePullSecretsSecrets 不同,因为 Secrets 可以挂载到 Pod 中,但是 ImagePullSecrets 只能由 Kubelet 访问。

我们需要拉取私有仓库镜像 192.168.1.100:5000/test:v1,我们就需要针对该私有仓库来创建一个如上的 Secret,然后在 Pod 中指定 imagePullSecrets

kubernetes.io/service-account-token

kubernetes.io/service-account-token用于被 ServiceAccount 引用。ServiceAccout 创建时 Kubernetes 会默认创建对应的 Secret。Pod 如果使用了 ServiceAccount,对应的 Secret 会自动挂载到 Pod 的 /var/run/secrets/kubernetes.io/serviceaccount/ 目录中。如下所示我们随意创建一个 Pod:

$ kubectl run secret-pod --image nginx:1.17.1 

查看这个pod的详细信息:

...... spec:   containers:   - image: nginx:1.17.1     imagePullPolicy: IfNotPresent     name: secret-pod    ......     volumeMounts:     - mountPath: /var/run/secrets/kubernetes.io/serviceaccount       name: default-token-lqrpd       readOnly: true ......   serviceAccount: default   serviceAccountName: default   volumes:   - name: default-token-lqrpd     secret:       defaultMode: 420       secretName: default-token-lqrpd 

可以看到默认把名为 default(自动创建的)的 ServiceAccount 对应的 Secret 对象通过 Volume 挂载到了容器的 /var/run/secrets/kubernetes.io/serviceaccount 的目录中。

同样 Secret 文件大小限制为 1MB(ETCD 的要求);Secret 虽然采用 Base64 编码,但是我们还是可以很方便解码获取到原始信息,所以对于非常重要的数据还是需要慎重考虑。

ServiceAccount

ServiceAccount 主要是用于解决 Pod 在集群中的身份认证问题的。认证使用的授权信息其实就是利用前面所说的 kubernetes.io/service-account-token 进行管理的。

介绍

ServiceAccount 是命名空间级别的,每一个命名空间创建的时候就会自动创建一个名为 defaultServiceAccount 对象:

$ kubectl create namespace dev namespace/dev created  $ kubectl get serviceaccount -n dev NAME      SECRETS   AGE default   1         22s  $  kubectl get secret -n dev NAME                  TYPE                                  DATA   AGE default-token-qxvm4   kubernetes.io/service-account-token   3      70s 

这个ServiceAccount会自动关联到一个Secret对象上:

$ kubectl get sa default -n dev -o yaml apiVersion: v1 kind: ServiceAccount metadata:   creationTimestamp: "2022-01-02T09:21:03Z"   name: default   namespace: dev   resourceVersion: "61354"   selfLink: /api/v1/namespaces/dev/serviceaccounts/default   uid: 0cfe3ea8-0255-434a-84ec-82f9c9e60fee secrets: - name: default-token-qxvm4 

这个 Secret 对象是 ServiceAccount 控制器自动创建的,我们可以查看这个关联的 Secret 对象信息:

# kubectl get secret default-token-qxvm4 -n dev -o yaml apiVersion: v1 data:   ca.crt: LS0...   namespace: ZGV2   token: ZXlKaGJ... kind: Secret metadata:   annotations:     kubernetes.io/service-account.name: default     kubernetes.io/service-account.uid: 0cfe3ea8-0255-434a-84ec-82f9c9e60fee   creationTimestamp: "2022-01-02T09:21:03Z"   ......   name: default-token-qxvm4   namespace: dev   resourceVersion: "61353"   selfLink: /api/v1/namespaces/dev/secrets/default-token-qxvm4   uid: 0277b6f3-5e22-405d-a4fa-e64b7bbd4bc5 type: kubernetes.io/service-account-token 

data区域,我们可以看到三个信息:

  • ca.crt:用于校验服务端的证书信息
  • namespace:表示当前管理的命名空间
  • token:用于 Pod 身份认证的 Token

默认情况下当前 namespace 下面的 Pod 会默认使用 default 这个 ServiceAccount,对应的 Secret 会自动挂载到 Pod 的 /var/run/secrets/kubernetes.io/serviceaccount/ 目录中,这样我们就可以在 Pod 里面获取到用于身份认证的信息了。

实现原理

实际上这个自动挂载过程是在 Pod 创建的时候通过 Admisson Controller(准入控制器) 来实现的。

  • Admisson Controller

    Admission Controller(准入控制)是 Kubernetes API Server 用于拦截请求的一种手段。Admission 可以做到对请求的资源对象进行校验,修改,Pod 创建时 Admission Controller 会根据指定的的 ServiceAccount(默认的 default)把对应的 Secret 挂载到容器中的固定目录下 /var/run/secrets/kubernetes.io/serviceaccount/

当我们在 Pod 里面访问集群的时候,就可以默认利用挂载到 Pod 内部的 token 文件来认证 Pod 的身份,ca.crt 则用来校验服务端。在 Pod 中访问 Kubernetes 集群的一个典型的方式如下图所示:

image

代码中我们指定了 ServiceAccount 背后的 Secret 挂载到 Pod 里面的两个文件:tokenca.crt,然后通过环境变量获取到 APIServer 的访问地址(前面我们提到过会把 Service 信息通过环境变量的方式注入到 Pod 中),然后通过 ca.cart 校验服务端是否可信,最后服务端会根据我们提供的 token 文件对 Pod 进行认证。

Pod 身份被认证合法过后,具体具有哪些资源的访问权限,就需要通过后面的 RBAC 来进行声明了。

推荐这些技术文章:

Kubernetes 配置管理

ConfigMap(可变配置管理)
对于应用的可变配置在 Kubernetes 中是通过一个 ConfigMap 资源对象来实现的,我们知道许多应用经常会有从配置文件、命令行参数或者环境变量中读取一些配置信息的需求,这些配置信息我们肯定不会直接写死到应用程序中去的,比如你一个应用连接一个 redis 服务,下一次想更换一个了的,还得重新去修改代码,重新制作一个镜像,这肯定是不可取的,而Confi...

13.Configmap配置管理

1.Configmap 是什么
Configmap 是 k8s 中的资源对象,用于保存非机密性的配置的,数据可以用 key/value 键值对的形式保存,也可通过文件的形式保存。
2.Configmap 能解决哪些问题
我们在部署服务的时候,每个服务都有自己的配置文件,如果一台服务器上部署多个服务:nginx、tomcat、apache 等,那么这些配置都存在这个节点上,假如一台服务器不能满足线...

12.Kubernetes配置管理

1.Secret
Secret的主要作用就是加密数据,然后存在etcd里面,让Pod容器以挂载Volume方式进行访问
场景:用户名 和 密码进行加密
一般场景的是对某个字符串进行base64编码 进行加密
echo -n 'admin' | base64

变量形式挂载到Pod

创建secret加密数据的yaml文件 secret.yaml

然后使用下面命令创建一个pod
kubect...

14.Secret配置管理

1.Secret 是什么?
Configmap 一般是用来存放明文数据的,如配置文件,对于一些敏感数据,如密码、私钥等数据时,要用 secret 类型。
Secret 解决了密码、token、秘钥等敏感数据的配置问题,而不需要把这些敏感数据暴露到镜像或者 Pod Spec 中。Secret 可以以 Volume 或者环境变量的方式使用。要使用 secret,pod 需要引用 secret。Pod...

|NO.Z.00181|——————————|CloudNative|——|KuberNetes&配置管理.V12|——|secret.v04|ImagePullSecret|

一、ImagePullSecret:

### --- ImagePullSecret:

~~~ Pod拉取私有镜像仓库时使用的账号密码,里面的账号信息会传递给kubelet,
~~~ 然后kubelet就可以拉取有密码的仓库里面的镜像。

### --- 创建一个docker registry的secrets
~~~ 手动创建docker regis...

|NO.Z.00175|——————————|CloudNative|——|KuberNetes&配置管理.V06|——|configmap.v06|使用configmap定义容器|

一、使用configmap数据定义容器

### --- 使用congfigmap数据定义容器环境变量
~~~ 使用来自单个configmap的数据定义容器环境变量

[root@k8s-master01 configmap]# vim pod-single-configmap-env-variable.yaml
apiVersion: v1
kind: Pod
meta...

|NO.Z.00171|——————————|CloudNative|——|KuberNetes&配置管理.V02|——|configmap.v02|从文件创建configmap|

一、从文件创建configmap

### --- 可以用来kubectl create configmap从单个文件或多个文件创建ConfigMap。
~~~ 也可以定义它的名字,在前面加入命名方式,若是不加的话默认是按照它的文件名来命名的:
~~~ 这种方式在生产环境中是最常用的。

[root@k8s-master01 ~]# kubectl create ...

|NO.Z.00184|——————————|CloudNative|——|KuberNetes&配置管理.V15|——|configmap.secret热更新.v01|解决configmap不被更新感知的问题|

一、ConfigMap和Secret的热更新概述

### --- ConfigMap和Secret的热更新概述

~~~ ConfigMap和Secret如果是以subPath 的形式挂载的,
~~~ 那么Pod是不会感知到ConfigMap和Secret的更新的。
~~~ 如果Pod的变量来自于ConfigMap和Secret中定义的内容,那么Co...

|NO.Z.00185|——————————|CloudNative|——|KuberNetes&配置管理.V16|——|configmap.secret热更新.v02|configmap编辑方式|

一、configmap编辑方式

### --- 编辑configmap的形式:

~~~ 方式一: edit:显示文件内容会很杂乱,不是很标准的显示内容,造成视觉的难理解。若是文件特别小的话,它会把文件内容显示在configmap的文件中,若是文件特别长的话,它是不会把文件内容显示在configmap文件中,只会显示文件的大小。
~~~ 方式一: 可...

|NO.Z.00172|——————————|CloudNative|——|KuberNetes&配置管理.V03|——|configmap.v03|从文件值创建configmap|

一、从文件值创建configmap

### --- 根据文件值创建configmap
~~~ 可以将kubectl create configmap其与--from-literal参数一起使用,
~~~ 以从命令行定义文字值

[root@k8s-master01 configmap]# kubectl create configmap special-conf...

文章标题:Kubernetes配置管理
文章链接:https://www.dianjilingqu.com/1833.html
本文章来源于网络,版权归原作者所有,如果本站文章侵犯了您的权益,请联系我们删除,联系邮箱:saisai#email.cn,感谢支持理解。
THE END
< <上一篇
下一篇>>