TOC
ConfigMap
Kubernetes是一个容器编排平台，虽然它又额外加了一层外层Pod，并以容器的方式来运行应用程序的特定，在Docker时代所面临的配置容器化应用的问题，在Kubernetes时代依然存在，如果想配置应用程序，我们想用到的途径和方式无非是两种；
第一如果程序的镜像是云原生的，或者借助于entrypoint脚本能够通过传递环境变量接受参数，完成配置这是一种比较轻量化的配置方式，在启动容器时传递几个环境变量，分别代表着几个重要的配置参数，从而完成应用程序配置；
第二以Nginx为例，启动Nginx需要加载我们自定义的配置文件模块，我们还可以使用存储卷的方式进行配置文件的传递，将外部的配置文件加载到容器内部
这两种配置方式有缺陷，如果使用环境变量配置的话，环境变量是在容器启动时被装入的，然后进行替换，一旦替换就没法更改了，如果想修改某一个参数的值，只能重新启动容器，如果使用存储卷的方式去做，存储卷中的内容也是在进程启动时被装入的，后面就算修改了存储卷的配置，也还是需要手动触发进程reload加载新的配置；
如果说我们在一个Pod控制器下，控制有五个Pod，这个五个Pod配置信息应该都是一样的，意味着这五个Pod他们会共享同一个存储卷，如果修改了存储卷的当中的内容，很显然，这个五个Pod都能加载到新的内容，但是这五个Pod都得进程重载，这就很麻烦了，尤其在以后使用Hpa控制器的时候，它会根据用户的访问量来自定伸缩Pod副本，那这个时候就完全不知道该重载哪些Pod，所以在这种情况之下，一样会面临复杂的配置问题，这个时候最好能够提供一种机制，让我们可以改完配置信息以后能自动被相关的Pod重载，而且能够一对多，只需要改一遍，所有加载这个配置文件的Pod都能够被自动进行重载；
在kubernetes之上用于实现配置自动重载的功能的组件，他们分别是ConfigMap、Secret，他们都是用于把配置文件配置为Kubernetes资源，其中ConfigMap用于提供非敏感配置，而Secret用户配置敏感配置信息(密码、密钥等)进行编码存放，他们内部存储的都是键值对，而这种键值，键可以是我们的配置参数，值可以做得很复杂，比如我们可以把一个配置文件的文件名当作键，整个文件的配置当作值；
这样子也就意味着我们常见的配置文件，都可以直接被实例化为ConfigMap中的键值对象，所以一个ConfigMap就是一个键值存储系统，我们一旦定义好ConfigMap需要在我们的Kubernetes中的Pod调用有两种方式；
第一，我们可以在Kubernetes容器中，把每一个Key的Value映射为这个容器内部环境变量的值，比如我们在一个Pod中有一个环境变量名是MYSQL_USER它的值可以来自于一个ConfigMap的键的值，我们向MYSQL_USER值不是直接赋值而是给它赋值一个ConfigMap中的键，从而他能够实现键的替换，然后也就能够被我们的应用程序引用到；
Kubernetes的ConfigMap和Pod都是标准的Kubernetes资源，因此在这种情况下有一个名称空间，我们做了有一个ConfigMap，在这个ConfigMap种我们定义了两个数据项第一叫redis_host值为172.16.1.1，第二叫redis_port值为6379，随后我们配置一个Pod，这个Pod是一个filebeat，这个Pod能够通过一个环境变量来引用redis主机和端口的配置，对应环境变量名是的host和prot，那么我们就可以这样定义Pod，“host：redis-cfg.redis_host，port：redis_port”，以后我们想要修改配置只需要配置ConfigMap即可，但是这种引用有一个缺陷，就是只要你把Pod启动起来就不会再重新获取值了，也就意味着后面我们修改了ConfigMap里面的数据也不会被Pod加载到，这个时候 还是需要重建来进行加载新配置，这是环境变量的缺陷；
还有一种方式，ConfigMap资源可以直接被Pod当作容器使用，比如配置一个Nginx，Nginx是可以在/etc/nginx/conf.d目录中去装载我们Nginx配置文件的，因此我们仍然定义一个ConfigMap资源，这个ConfigMap叫做nginx-cfg，它有一个键叫做server1.conf他里面还有一个键值比如server_name值为172.16.1.1，随后我们在定义Pod时候先定义一个存储卷，这个存储卷的类型是ConfigMap，它是ConfigMap中的存储卷，而这个卷也不是某个存储设备的存储空间，而就是引用了ConfigMap中的资源，我们可以通过存储卷的方式引用一个ConfigMap资源，而后在Nginx容器当中就可以把这个存储卷挂在到/etc/nginx/conf.d目录下，一旦我们挂在完成之后，它能够自动把这个server1.conf键映射成文件名，并且把server1.conf键的值映射为文件的内容，所以直接变成容器内部的/etc/nginx/conf.d下面的server.conf文件，更方便的是，这种引用方式，如果我们修改了ConfigMap里面的配置，过一个随机时长，可能几秒内，会自动同步到所有引用这个ConfigMap存储卷的Pod，而且一旦只要容器应用支持还重载，那么 同步完成之后它会自动重载容器应用，使得新配置生效，但是如果通过重载应用无法生效， 那就得需要重建Pod使配置生效，Secret也是一样，只不过数据做了一层base64加密；
环境变量方式配置
使用ConfigMap的方式配置，我们后面可以通过entrypoint脚本来进行配置替换，但是这种方式有一种缺陷，就是热修改配置的时候，Pod里面的应用不会重新加载配置；
# 创建一个名称空间
[root@node1 ~]# kubectl create ns config
# 创建一个configmap
[root@node1 ~]# kubectl create configmap -n config filebeat-cfg --from-literal=redis_host="redis.default.svc.cluster.local" --from-literal=redis_port="6379"
# 查看创建的configmap
[root@node1 ~]# kubectl get configmaps -n config filebeat-cfg -o yaml apiVersion: v1
data:
redis_host: redis.default.svc.cluster.local # 配置都存储在data对象下面
redis_port: "6379"
kind: ConfigMap
metadata:
creationTimestamp: "2019-11-29T07:20:47Z"
name: filebeat-cfg
namespace: config
resourceVersion: "34819"
selfLink: /api/v1/namespaces/config/configmaps/filebeat-cfg
uid: 592a60fc-9188-4782-b9af-dceac9766418
# 编写Pod配置
[root@node1 ~]# cat test.yaml
apiVersion: v1
kind: Pod
metadata:
name: config-test
namespace: config
spec:
restartPolicy: Always
containers:
- name: vol-pod
image: busybox:latest
command:
- /bin/httpd
- -f
env:
- name: REDIS_HOST
valueFrom:
configMapKeyRef:
name: filebeat-cfg
key: redis_host
- name: REDIS_PORT
valueFrom:
configMapKeyRef:
name: filebeat-cfg
key: redis_port
# 查看环境变量是否加载成功
[root@node1 config]# kubectl exec -it -n config config-test printenv
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=config-test
TERM=xterm
REDIS_HOST=redis.default.svc.cluster.local
REDIS_PORT=6379 # 可以看到环境变量已经加载进来了
KUBERNETES_PORT_443_TCP_ADDR=10.96.0.1
KUBERNETES_SERVICE_HOST=10.96.0.1
KUBERNETES_SERVICE_PORT=443
KUBERNETES_SERVICE_PORT_HTTPS=443
KUBERNETES_PORT=tcp://10.96.0.1:443
KUBERNETES_PORT_443_TCP=tcp://10.96.0.1:443
KUBERNETES_PORT_443_TCP_PROTO=tcp
KUBERNETES_PORT_443_TCP_PORT=443
HOME=/root
# 测试修改configmap里面的值
[root@node1 config]# kubectl edit configmaps -n config filebeat-cfg
# 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:
redis_host: redis.default.svc.cluster.local
redis_port: "6380" # 修改为6380
kind: ConfigMap
metadata:
creationTimestamp: "2019-11-29T07:59:00Z"
name: filebeat-cfg
namespace: config
resourceVersion: "38149"
selfLink: /api/v1/namespaces/config/configmaps/filebeat-cfg
uid: aa81b1c9-a29a-4c73-b480-8146273d3c17
# 重新查看容器会发现环境变量没有重新加载
[root@node1 config]# kubectl exec -it -n config config-test printenv
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=config-test
TERM=xterm
REDIS_HOST=redis.default.svc.cluster.local
REDIS_PORT=6379 # 没有变动
KUBERNETES_PORT_443_TCP_ADDR=10.96.0.1
KUBERNETES_SERVICE_HOST=10.96.0.1
KUBERNETES_SERVICE_PORT=443
KUBERNETES_SERVICE_PORT_HTTPS=443
KUBERNETES_PORT=tcp://10.96.0.1:443
KUBERNETES_PORT_443_TCP=tcp://10.96.0.1:443
KUBERNETES_PORT_443_TCP_PROTO=tcp
KUBERNETES_PORT_443_TCP_PORT=443
HOME=/root
# 手动删除Pod并重建查看是否是新的环境变量
[root@node1 config]# kubectl delete -f test.yaml
pod "config-test" deleted
[root@node1 config]# kubectl apply -f test.yaml
pod/config-test created
[root@node1 config]# kubectl exec -it -n config config-test printenv
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=config-test
TERM=xterm
REDIS_HOST=redis.default.svc.cluster.local
REDIS_PORT=6380 # 配置已经变动
KUBERNETES_SERVICE_PORT_HTTPS=443
KUBERNETES_PORT=tcp://10.96.0.1:443
KUBERNETES_PORT_443_TCP=tcp://10.96.0.1:443
KUBERNETES_PORT_443_TCP_PROTO=tcp
KUBERNETES_PORT_443_TCP_PORT=443
KUBERNETES_PORT_443_TCP_ADDR=10.96.0.1
KUBERNETES_SERVICE_HOST=10.96.0.1
KUBERNETES_SERVICE_PORT=443
HOME=/root
volume方式配置
volume方式配置就是直接通过挂载configmap的方式将配置写入到Pod容器指定的路径下面，这种方式会自动加载新配置，但是有的程序是不支持reload的，以Nginx为例；
# 创建Nginx配置
[root@node1 nginx]# cat server1.conf server2.conf
server {
server_name 0.0.0.0;
listen 80;
location / {
root /data/wwwroot/server1;
}
}
server {
server_name 0.0.0.0;
listen 8080;
location / {
root /data/wwwroot/server2;
}
}
# 将nginx配置创建为ConfigMap资源
[root@node1 nginx]# kubectl create ns config-volume
[root@node1 nginx]# kubectl create configmap nginx-conf --from-file=server1=server1.conf --from-file=server2=server2.conf -n config-volume
configmap/nginx-conf created
[root@node1 nginx]# kubectl get configmaps -n config-volume -o yaml
apiVersion: v1
items:
- apiVersion: v1
data:
server1: "server {\n\tserver_name 0.0.0.0;\n\tlisten\t\t80;\n\tlocation / {\n\t\troot
/data/wwwroot/server1;\n\t}\n}\n"
server2: "server {\n\tserver_name 0.0.0.0;\n\tlisten\t\t8080;\n\tlocation / {\n\t\troot
/data/wwwroot/server2;\n\t}\n}\n"
kind: ConfigMap
metadata:
creationTimestamp: "2019-11-29T13:52:41Z"
name: nginx-conf
namespace: config-volume
resourceVersion: "6558"
selfLink: /api/v1/namespaces/config-volume/configmaps/nginx-conf
uid: 9e0ff284-70ae-4911-a975-7990b91a7373
kind: List
metadata:
resourceVersion: ""
selfLink: ""
# 配置Pod
[root@node1 nginx]# cat pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: config-volume-pod
namespace: config-volume
spec:
containers:
- name: nginx
image: nginx:1.14-alpine
volumeMounts:
- name: conf # 要挂载volumes的名字
mountPath: /etc/nginx/conf.d # 挂载的目的目录
volumes:
- name: conf # 该volumes的名字
configMap:
name: nginx-conf # 要使用configMap的名字
items:
- key: server1 # 要使用指定configMap里面的键名
path: s1.conf # 挂载之后的文件名
- key: server2 # 要使用指定configMap里面的键名
path: s2.conf # 挂载之后的文件名
# 查看配置是否生效
[root@node1 nginx]# kubectl exec -it -n config-volume config-volume-pod /bin/sh
/ # ls /etc/nginx/conf.d/ # 两个配置文件已经加入进来
s1.conf s2.conf
/ # cat /etc/nginx/conf.d/* # 配置和我们定义的一致
server {
server_name 0.0.0.0;
listen 80;
location / {
root /data/wwwroot/server1;
}
}
server {
server_name 0.0.0.0;
listen 8080;
location / {
root /data/wwwroot/server2;
}
}
/ # netstat -ntlp # 端口也启动起来了
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 1/nginx: master pro
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 1/nginx: master pro
/ #
# 测试修改配置
[root@node2 ~]# kubectl edit -n config-volume configmaps nginx-conf
configmap/nginx-conf edited
# 80变更为81，8080变更为8081
[root@node2 ~]# kubectl edit -n config-volume configmaps nginx-conf
# 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:
server1: "server {\n\tserver_name 0.0.0.0;\n\tlisten\t\t81;\n\tlocation / {\n\t\troot
/data/wwwroot/server1;\n\t}\n}\n"
server2: "server {\n\tserver_name 0.0.0.0;\n\tlisten\t\t8081;\n\tlocation / {\n\t\troot
/data/wwwroot/server2;\n\t}\n}\n"
kind: ConfigMap
metadata:
creationTimestamp: "2019-11-29T13:52:41Z"
name: nginx-conf
namespace: config-volume
resourceVersion: "8765"
selfLink: /api/v1/namespaces/config-volume/configmaps/nginx-conf
uid: 9e0ff284-70ae-4911-a975-7990b91a7373
# 数秒后会发现Nginx配置文件已变更，但是nginx未重载，可以借助其他插件实现
[root@node1 nginx]# kubectl exec -it -n config-volume config-volume-pod cat /etc/nginx/conf.d/s1.conf
server {
server_name 0.0.0.0;
listen 81;
location / {
root /data/wwwroot/server1;
}
}
配置中心概念
Kubernetes用来配置分布式或者负载均衡集群化的配置中心，比如如果在nginx后面维护有20个tomcat，需要改修tomcat配置文件的一些配置信息，比如在修改tomcat连接redis的账号密码，那如何让20个tomcat都应用到新配置，此前的做法就是使用ansible，然后分批推，推的时候还需要以灰度的方式进行，如果一下全部推送那在某一时刻服务都无法访问了，所以即使借助了ansible来编排，也得一个一个来，但这种才20个，但是如果有30个或者更多这就比较麻烦了，所以很多规模非常大的网站都不会通过这种方式来配置应用程序，而是让应用程序所有配置都不通过本地配置文件加载，而是通过联系一个配置中心的服务去加载配置，所以称之为配置中心；
启动多个应用程序时，抛弃了传统从本地文件加载配置的方法，而是通过一个中心服务器来加载配置，这个服务叫做配置中心，随后我们在这个配置中心修改了配置以后，会通知给每一个进程，让进程自动进行重载，就能完成所有的进程进行重载，还可以以灰度的方式通知，那么他们就可以以灰度的方式去更新自己的配置信息；
国内有两个项目，为非容器化应用程序提供配置中心，协程的Apollo、百度的Distconf，所以在非容器化模式中，也可以使用配置中心，要使用配置中心还需要我们的程序支持从配置中心加载配置才行；
