kubernetes ConfigMap和Secret：配置应用程序
7.1.配置容器化应用程序
7.2.向容器传递命令行参数
7.2.1.待Docker中定义命令与参数
1.了解ENTRYPOINT与CMDlinux
ENTRYPOINT定义容器启动时被调用的能够执行程序nginx
CMD指定传递给ENTRYP的参数web
dockerfile 内容以下redis
FROM daocloud.io/centos:latest ADD aaa /usr/local/aaa CMD ["-f","/var/log/aa.log"] ENTRYPOINT ["tail"]
当启动镜像时，容器启动时执行以下命令：tail -f /var/log/aa.logdocker
或者在docker run <images> <arguments> 中指定，arguments会覆盖CMD中内容centos
7.2.2.在kubernetes中覆盖命令行和参数
在k8s中定义容器时，镜像的ENTRYPOINT和CMD均可以被覆盖，仅需在容器定义中设置熟悉command和args的值api
对应参数以下：缓存
| Docker | kubernetes | 描述 |
| ENTRYPOINT | command | 容器中运行的可执行文件 |
| CMD | args | 传给可执行文件的参数 |
相关yml代码以下：ui
kind: pod
spec:
containers:
- image: some/image
command: ["/bin/command"]
args: ["args1","args2","args3"]
7.3.为容器设置环境变量
7.3.1.在容器定义中指定环境变量
与容器的命令和参数设置相同，环境变量列表没法在pod建立后被修改。编码
在pod的yml文件中设置容器环境变量代码以下：
kind: pod
spec:
containers:
- image: luksa/fortune:env
env:
- name: INTERVAL
value: "30"
name: value-test-yh
7.3.2.在环境变量值中引用其余环境变量
使用$( VAR )引用环境变量，
相关ym代码以下：
env: - name: FIRST_VAR value: "foo" - name: SECOND_VAR value: "$(FIRST_VAR)bar" //最终变量值为foobar
7.4.利用ConfigMap解耦配置
7.4.1.ConfigMap介绍
kubernetes容许将配置选项分离到独立的资源对象ConfigMap中，本质上就是一个键/值对映射，值能够是短字面变量，也能够是完整的配置文件。
应用无须直接读取ConfigMap，甚至根本不须要知道其是否存在。
映射的内容经过环境变量或者卷文件的形式传递给容器，而并不是直接传递给容器，命令行参数的定义中也是经过$(ENV_VAR)语法变量
7.4.2.建立ConfigMap
使用kubectl creat configmap建立ConfigMap中间不用加-f。
1.使用指令建立ConfigMap
#kubectl creat configmap configmap-yaohong --from-literal=foo=bar --from-literal=sleep-interval=25
2.从文件内容建立ConfigMap条目
#kubectl create configmap my-conf-yh --from-file=config-file.conf
使用以下命令，会将文件内容存储在自定义的条目下。与字面量使用相同
#kubectl create configmap my-conf-yh --from-file=customkey=config-file.conf
3.从文件夹建立ConfigMap
#kubectl create configmap my-conf-yh --from-file=/path/to/dir
4.合并不一样选项
#kubectl create configmap my-conf-yh --from-file=/path/to/dir/ --from-file=bar=foobar.conf --from-literal=some=thing
5.获取ConfigMap
#kubectl -n <namespace> get configmap
7.4.3.给容器传递ConfigMap条目做为环境变量
引用环境变量中的参数值给当前变量
apiVersion: v1
kind: pod
metadata:
name: fortune-env-from-configmap
spec:
containers:
- image: luksa/fortune:env
env:
- name: INTERVAL //设置环境变量
valueFrom:
configMapkeyRef:
name: fortune-configmap
key: sleep-interval //变量的值取自fortune-configmap的slee-interval对应的值
7.4.4.一次性传递ConfigMap的全部条目做为环境变量
apiVersion: v1
kind: pod
metadata:
name: fortune-env-from-configmap
spec:
containers:
- image: luksa/fortune:env
envFrom:
- prefix: CONFIG_
confgMapRef:
name: my-confg-map //引用my-config-map的ConfigMap并在变量前面都加上CONFIG_
7.4.5.使用ConfigMap卷将条目暴露为文件
apiVersion: v1
kind: pod
metadata:
name: configmap-volume-yh
spec:
containers:
- image: nginx:aplin
name: web-server
volumeMounts:
...
- name: config
defaultMode: "6600" //设置文件的权限为rw-rw
mountPath: /etc/nginx/con.conf
subPath: my.conf //subPath字段能够用于挂载卷中某个独立的文件或者文件夹，并且不覆盖该卷下其余文件
...
volume:
...
- name: config
configMap:
name: fortune-config //引用fortune-config configMap的卷，而后挂载在/etc/nginx/conf.d
能够使用以下命令查看到/etc/nginx/conf.d文件下面包含fortune-config
#kubectl exec config-volume-yh -c web-server ls /etc/nginx/conf.d
7.5.使用Secert给容器传递敏感数据
7.5.1.介绍Secert
Secret结构和ConfigMap相似，均是键/值对的映射。
使用方法也和ConfigMap同样，能够：
1.将Secret条目做为环境变量传递给容器，
2.将Secret条目暴露为卷中文件
ConfigMap存储非敏感的文本配置数据，采用Secret存储天生敏感的数据
7.5.2.默认令牌Secret
1.查看secret
# kubectl get secrets NAME TYPE DATA AGE default-token-x9cjb kubernetes.io/service-account-token 3 78d
2.描述secret
# kubectl describe secrets default-token-x9cjb
Name: default-token-x9cjb
Namespace: default
Labels: <none>
Annotations: kubernetes.io/service-account.name: default
kubernetes.io/service-account.uid: 64a41a09-98ce-11e9-9fa5-fa163e6fdb6b
Type: kubernetes.io/service-account-token
Data
====
token: eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5lduaW8vc2VydmljZTxCv6HdtP-ZW3ZC2IKKR5YBhaokFIl35mix79pU4Ia2pJ_fuPTBGNyrCHyNQYH4ex5DhND3_b2puQmn8RSErQ
ca.crt: 1298 bytes
namespace: 7 bytes
7.5.3.建立Secret
1.建立一个名为https-yh的generic secret
#kubectl create secret generic https-yh --from-file=https.key --from-file=https.cert --from-file=foo
2.建立一个secret.yaml文件，内容用base64编码
$ echo -n 'admin' | base64 YWRtaW4= $ echo -n '1f2d1e2e67df' | base64 MWYyZDFlMmU2N2Rm
yaml文件内容：
apiVersion: v1 kind: Secret metadata: name: mysecret type: Opaque data: username: YWRtaW4= password: MWYyZDFlMmU2N2Rm
建立：
$ kubectl create -f ./secret.yaml secret "mysecret" created
解析Secret中内容
$ kubectl get secret mysecret -o yaml apiVersion: v1 data: username: YWRtaW4= password: MWYyZDFlMmU2N2Rm kind: Secret metadata: creationTimestamp: 2016-01-22T18:41:56Z name: mysecret namespace: default resourceVersion: "164619" selfLink: /api/v1/namespaces/default/secrets/mysecret uid: cfee02d6-c137-11e5-8d73-42010af00002 type: Opaque
base64解码：
$ echo 'MWYyZDFlMmU2N2Rm' | base64 --decode 1f2d1e2e67df
7.5.4.对比ConfigMap与Secret
Secret的条目内容会进行Base64格式编码，而ConfigMap直接以纯文本展现。
1.为二进制数据建立Secret
Base64能够将二进制数据转换为纯文本，并以YAML或Json格式进行展现
但要注意Secret的大小限制是1MB
2.stringDate字段介绍
Secret能够经过StringDate字段设置条目的纯文本
kind: Secret apiVersion: v1 stringDate: foo: plain txt date: https.cert: HGIOPUPSDF63456BJ3BBJL34563456BLKJBK634563456BLBKJBLKJ63456BLK3456LK http.key: OHOPGPIU42342345OIVBGOI3456345OVB6O3456BIPO435B6IPU345UI
7.5.5.在pod中使用Secret
secret能够做为数据卷挂载或者做为环境变量暴露给Pod中的容器使用，也能够被系统中的其余资源使用。好比能够用secret导入与外部系统交互须要的证书文件等。
在Pod中以文件的形式使用secret
- 建立一个Secret，多个Pod能够引用同一个Secret
- 修改Pod的定义，在
spec.volumes[]加一个volume，给这个volume起个名字，spec.volumes[].secret.secretName记录的是要引用的Secret名字 - 在每一个须要使用Secret的容器中添加一项
spec.containers[].volumeMounts[]，指定spec.containers[].volumeMounts[].readOnly = true，spec.containers[].volumeMounts[].mountPath要指向一个未被使用的系统路径。 - 修改镜像或者命令行使系统能够找到上一步指定的路径。此时Secret中
data字段的每个key都是指定路径下面的一个文件名
下面是一个Pod中引用Secret的列子：
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- name: mypod
image: redis
volumeMounts:
- name: foo
mountPath: "/etc/foo"
readOnly: true
volumes:
- name: foo
secret:
secretName: mysecret
每个被引用的Secret都要在spec.volumes中定义
若是Pod中的多个容器都要引用这个Secret那么每个容器定义中都要指定本身的volumeMounts，可是Pod定义中声明一次spec.volumes就行了。
映射secret key到指定的路径
能够控制secret key被映射到容器内的路径，利用spec.volumes[].secret.items来修改被映射的具体路径
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- name: mypod
image: redis
volumeMounts:
- name: foo
mountPath: "/etc/foo"
readOnly: true
volumes:
- name: foo
secret:
secretName: mysecret
items:
- key: username
path: my-group/my-username
发生了什么呢？
- username被映射到了文件
/etc/foo/my-group/my-username而不是/etc/foo/username - password没有变
Secret文件权限
能够指定secret文件的权限，相似linux系统文件权限，若是不指定默认权限是0644，等同于linux文件的-rw-r--r--权限
设置默认权限位
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- name: mypod
image: redis
volumeMounts:
- name: foo
mountPath: "/etc/foo"
volumes:
- name: foo
secret:
secretName: mysecret
defaultMode: 256
上述文件表示将secret挂载到容器的/etc/foo路径，每个key衍生出的文件，权限位都将是0400
因为JSON不支持八进制数字，所以用十进制数256表示0400，若是用yaml格式的文件那么就很天然的使用八进制了
同理能够单独指定某个key的权限
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- name: mypod
image: redis
volumeMounts:
- name: foo
mountPath: "/etc/foo"
volumes:
- name: foo
secret:
secretName: mysecret
items:
- key: username
path: my-group/my-username
mode: 511
从volume中读取secret的值
值得注意的一点是，以文件的形式挂载到容器中的secret，他们的值已是通过base64解码的了，能够直接读出来使用。
$ ls /etc/foo/ username password $ cat /etc/foo/username admin $ cat /etc/foo/password 1f2d1e2e67df
被挂载的secret内容自动更新
也就是若是修改一个Secret的内容，那么挂载了该Secret的容器中也将会取到更新后的值，可是这个时间间隔是由kubelet的同步时间决定的。最长的时间将是一个同步周期加上缓存生命周期(period+ttl)
特例：以subPath形式挂载到容器中的secret将不会自动更新
以环境变量的形式使用Secret
- 建立一个Secret，多个Pod能够引用同一个Secret
- 修改pod的定义，定义环境变量并使用
env[].valueFrom.secretKeyRef指定secret和相应的key - 修改镜像或命令行，让它们能够读到环境变量
apiVersion: v1
kind: Pod
metadata:
name: secret-env-pod
spec:
containers:
- name: mycontainer
image: redis
env:
- name: SECRET_USERNAME
valueFrom:
secretKeyRef:
name: mysecret
key: username
- name: SECRET_PASSWORD
valueFrom:
secretKeyRef:
name: mysecret
key: password
restartPolicy: Never
容器中读取环境变量，已是base64解码后的值了：
$ echo $SECRET_USERNAME admin $ echo $SECRET_PASSWORD 1f2d1e2e67df
使用imagePullSecrets
建立一个专门用来访问镜像仓库的secret，当建立Pod的时候由kubelet访问镜像仓库并拉取镜像，具体描述文档在 这里
设置自动导入的imagePullSecrets
能够手动建立一个，而后在serviceAccount中引用它。全部通过这个serviceAccount建立的Pod都会默认使用关联的imagePullSecrets来拉取镜像，
- 1. (十)Kubernetes ConfigMap和Secret
- 2. Kubernetes学习笔记（六）：使用ConfigMap和Secret配置应用程序
- 3. Kubernetes ConfigMap vs Secret
- 4. Kubernetes笔记(8) - ConfigMap和Secret
- 5. kubernetes Configmap secret的使用
- 6. k8s之configmap和secret
- 7. Kubernetes进阶之secret及configmap配置管理
- 8. kubernetes存储—Configmap配置管理介绍、建立、如何使用configmap、configmap热更新、Secret配置管理的简介、类型、如何使用secret
- 9. k8s之configmap、secret
- 10. Kubernetes—配置管理ConfigMap
- 更多相关文章...
- • XML 应用程序 - XML 教程
- • ASP.NET MVC - Internet 应用程序 - ASP.NET 教程
- • IntelliJ IDEA 代码格式化配置和快捷键
- • IDEA下SpringBoot工程配置文件没有提示
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. (十)Kubernetes ConfigMap和Secret
- 2. Kubernetes学习笔记（六）：使用ConfigMap和Secret配置应用程序
- 3. Kubernetes ConfigMap vs Secret
- 4. Kubernetes笔记(8) - ConfigMap和Secret
- 5. kubernetes Configmap secret的使用
- 6. k8s之configmap和secret
- 7. Kubernetes进阶之secret及configmap配置管理
- 8. kubernetes存储—Configmap配置管理介绍、建立、如何使用configmap、configmap热更新、Secret配置管理的简介、类型、如何使用secret
- 9. k8s之configmap、secret
- 10. Kubernetes—配置管理ConfigMap