对于应用的可变配置在 Kubernetes 中是通过一个 ConfigMap 资源对象来实现的，许多应用经常会有从配置文件、命令行参数或者环境变量中读取一些配置信息的需求，这些配置信息我们肯定不会直接写死到应用程序中，比如一个应用连接一个 redis 服务，下一次想更换一个，还得重新去修改代码，重新制作一个镜像，这肯定是不可取的，而ConfigMap 就给我们提供了向容器中注入配置信息的能力，不仅可以用来保存单个属性，还可以用来保存整个配置文件，比如我们可以用来配置一个 redis 服务的访问地址，也可以用来保存整个 redis 的配置文件。
ConfigMap资源对象使用key-value形式的键值对来配置数据，这些数据可以在Pod里面使用，如下所示的资源清单：
apiVersion: v1
kind: ConfigMap
metadata:
name: configMap
data: #
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:
Annotations:
Data
====
mysql.conf:
----
host=127.0.0.1
port=3306
redis.conf:
----
host=127.0.0.1
port=6379
Events:
可以看到两个 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 的要求）。
一般情况下 ConfigMap 是用来存储一些非安全的配置信息，如果涉及到一些安全相关的数据的话用 ConfigMap 就非常不妥了，因为ConfigMap 是明文存储的，这个时候我们就需要用到另外一个和ConfigMap非常相似的资源对象了：Secret，Secret用来保存敏感信息，例如密码、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 类型的数据是一个 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:
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
......
同样使用一个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 指定 key 和 path。
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
除了上面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
我们可以通过指定文件的方式来创建镜像仓库认证任信息，需要主要对应的KEY和TYPE。
首先我们登录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对应的TYPE是kubernetes.io/dockerconfigjson,同样可以使用describe命令来查看详细信息：
$ kubectl describe secret myregistry
Name: myregistry
Namespace: default
Labels:
Annotations:
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
ImagePullSecrets与Secrets不同，因为Secrets可以挂载到 Pod 中，但是ImagePullSecrets只能由 Kubelet 访问。
我们需要拉取私有仓库镜像 192.168.1.100:5000/test:v1，我们就需要针对该私有仓库来创建一个如上的 Secret，然后在 Pod 中指定 imagePullSecrets。
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 主要是用于解决 Pod 在集群中的身份认证问题的。认证使用的授权信息其实就是利用前面所说的 kubernetes.io/service-account-token 进行管理的。
ServiceAccount 是命名空间级别的，每一个命名空间创建的时候就会自动创建一个名为 default 的 ServiceAccount 对象:
$ 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 集群的一个典型的方式如下图所示：
代码中我们指定了 ServiceAccount 背后的 Secret 挂载到 Pod 里面的两个文件：token 和 ca.crt，然后通过环境变量获取到 APIServer 的访问地址（前面我们提到过会把 Service 信息通过环境变量的方式注入到 Pod 中），然后通过 ca.cart 校验服务端是否可信，最后服务端会根据我们提供的 token 文件对 Pod 进行认证。
Pod 身份被认证合法过后，具体具有哪些资源的访问权限，就需要通过后面的 RBAC 来进行声明了。
京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有