- ConfigMap
- ConfigMap概述
- ConfigMap用途
- ConfigMap场景
- ConfigMap限制
- ConfigMap *** 作
- 创建ConfigMap
- 1. 命令行创建Key-Value键值
- 2. 命令行从文件引入Key-Value键值
- 3. 命令行从目录引入Key-Value键值
- 4. YAML文件创建Key-Value键值
- 运用ConfigMap
- 1. 通过环境变量方式直接传递到Pod
- 2. 通过在Pod的命令行下运行传递键值
- 3. 通过Volume方式挂载到pod成为配置文件
- 经典ConfigMap
- 1. ConfigMap在Tomcat运用示例
- 2. 热更新ConfigMap
- Secret
- Secret概述
- Secret用途
- Secret类型
- Secret限制
- Secret *** 作
- 创建Secret
- 1. 命令行创建Key-Value键值
- 2. 命令行从文件引入Key-Value键值
- 3. 命令行从目录引入Key-Value键值
- 4. YAML文件创建Key-Value键值
- 查看/解密Secret信息
- 运用Secret
- 1. 通过Volume方式挂载
- 2. 通过环境变量方式挂载
- 经典Secret
- 1. 设置pod所需的镜像到secret卷里面自动拉取
- Secret与ConfigMap对比
应用部署的一个最佳实践是将应用所需的配置信息与程序进行分离，这样可以使应用程序被更好地复用，通过不同的配置也能实现更灵活的功能。将应用打包为容器镜像后，可以通过环境变量或者外挂文件的方式在创建容器时进行配置注入，但在大规模容器集群的环境中，对多个容器进行不同的配置将变得非常复杂。Kubernetes提供一种统一的应用配置管理方案 - Configmap。
ConfigMap用途它旨在让镜像和配置文件解耦，以便实现镜像的可移植性和可复用性。
- ConfigMap用于保存配置数据，以键值对形式存储。
- ConfigMap资源提供了向 Pod 注入配置数据的方法。
ConfigMap以一个或多个Key:Value的形式保存在Kubernetes系统中供应使用，既可以用于表示一个变量的值(例如apploglevel=info)，也可以用于表示一个完整配置文件的内容(例如my.cnf)。它大致有如下一些场景：
- 生成为容器内的环境变量。
- 设置容器启动命令的启动参数(需设置为环境变量)。
- 以Volume的形式挂载为容器内部的文件或目录。
- ConfigMap必须在Pod之前创建。
- ConfigMap受Namespace限制， 只有处于相同Namespace中的Pod才可以引用它。
- ConfigMap中的配额管理还未能实现。
- kubelet只支持可以被API Server管理的Pod使用ConfigMap。kubelet在本Node上通过–manifest- url或- config自动创建的静态Pod将无法引用ConfigMap。
- 在Pod对ConfigMap进行挂载(volumeMount) *** 作时，在容器内部只能挂载为“目录”，无法挂载为“文件”。在挂载到容器内部后，在目录下将包含ConfigMap定义的每个item，如果在该目录下原来还有其他文件，则容器内的该目录将被挂载的ConfigMap覆盖。
- ConfigMap单个配置最大的容量是1M。
kubectl create configmap my-config01 --from-literal=key1=config1 --from-literal=key2=config2
kubectl create configmap my-config02 --from-file=/prod/my.cnf
mkdir configmap
kubectl create configmap my-config03 --from-file=configmap
4. YAML文件创建Key-Value键值目录下的每一个文件名都会单独成为Key，而文件内容则是Value。
vi configmap04.yaml
---
apiVersion: v1
kind: ConfigMap
metadata:
name: my-config04
data:
db_host: "172.25.38.250"
db_port: "3306"
---
# YAML文件配置
vi pod-configmap01.yaml
---
# 手动定义键值
apiVersion: v1
kind: Pod
metadata:
name: pod-configmap01
spec:
containers:
- name: pod-configmap01
image: busybox
command: ["/bin/sh", "-c", "env"]
env:
- name: db_host #定义环境变量的名称
valueFrom: #key1对应的value
configMapKeyRef:
name: configmap04 #环境变量的值取自cm1-config，我们在上边创建的cm
key: db_host #key是cm1-config中的db_host
- name: db_port
valueFrom:
configMapKeyRef:
name: configmap04
key: db_port
restartPolicy: Never
# 批量导入键值
apiVersion: v1
kind: Pod
metadata:
name: pod-configmap01
spec:
containers:
- name: pod-configmap01
image: busybox
command: ["/bin/sh", "-c", "env"]
envFrom:
- name: db_host #定义环境变量的名称
valueFrom: #key1对应的value
configMapRef:
name: configmap04
restartPolicy: Never
---
# YAML文件应用
kubectl create -f pod-configmap01.yaml
# POD检查效果
kubectl logs pod-configmap01 | grep db_
kubectl describe cm my-config04
# YAML文件配置
vi pod-configmap02.yaml
---
apiVersion: v1
kind: Pod
metadata:
name: pod-configmap02
spec:
containers:
- name: pod-configmap02
image: busyboxplus
command: ["/bin/sh", "-c", "env"] #获取环境变量
envFrom: #用于在容器中填充环境变量的源列表
- configMapRef:
name: configmap04 #选择一个ConfigMap来填充环境具有的变量。cm1-config的键值对作为环境变量
restartPolicy: Never #重启策略：永不
---
# YAML文件应用
kubectl create -f pod-configmap02.yaml
# POD检查效果
kubectl logs pod-configmap02 | grep db_
kubectl describe cm my-config04
# YAML文件配置
vi pod-configmap03.yaml
---
apiVersion: v1
kind: Pod
metadata:
name: pod-configmap03
spec:
containers:
- name: pod-configmap03
image: busyboxplus
volumeMounts:
- name: config-volume #引用卷的名称
mountPath: /config #挂载到容器内的目录
volumes:
- name: config-volume #定义volume的名称
configMap:
name: my-config04 #使用我们前面创建的my-config04
restartPolicy: Never
---
# 创建ConfigMap
kubectl create configmap tomcat-config --from-file=/opt/tomcat-config
# 检查ConfigMap
kubectl get cm
# TOMCAT YAML文件
vi tomcat-configmap.yaml
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: tomcat
spec:
replicas: 1
selector:
matchLabels:
app: tomcat
minReadySeconds: 1
progressDeadlineSeconds: 60
revisionHistoryLimit: 5
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 1
template:
metadata:
name: tomcat
labels:
app: tomcat
spec:
containers:
- name: tomcat
image: tomcat:8
ports:
- containerPort: 8086
volumeMounts:
- name: tz-config
mountPath: /etc/localtime
- name: tomcat-t1
mountPath: /usr/local/tomcat/conf #configmap挂载到容器内部的目录
volumes:
- name: tz-config
hostPath:
path: /usr/share/zoneinfo/Asia/Shanghai
- name: tomcat-t1
configMap:
name: tomcat-config #定义configmap名称
---
apiVersion: v1
kind: Service
metadata:
name: tomcat
spec:
type: NodePort
ports:
- port: 8086
selector:
app: tomcat
---
# 应用Tomcat YAML文件
kubectl create -f tomcat-configmap.yaml
# 检查Tomcat YAML文件
kubectl get pod
kubectl get svc
# 测试Tomcat访问
curl
2. 热更新ConfigMap在一般情况下 configmap 挂载文件时，会先覆盖掉挂载目录，然后再将 congfigmap 中的内容作为文件挂载进行。如果想不对原来的文件夹下的文件造成覆盖，只是将 configmap 中的每个 key，按照文件的方式挂载到目录下，可以使用 subpath 参数。
实现修改配置文件可以动态更新到Pod环境，快速实现统一配置更新。如下以NGINX为例子：
# 创建nginx.conf配置文件
vi nginx.conf
---
server {
listen 8000; #该配置文件主要是设置端口
server_name _;
location / {
root /usr/share/nginx/html;
index index.html index.html;
}
}
---
# 创建ConfigMap配置文件
kubectl create configmap nginxconf --from-file=nginx.conf
# 创建Delployment的YAML配置文件
vi deploy-nginxconf.yaml
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: deploy-nginxconf
namespace: nginxconf
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
volumeMounts:
- name: config-volume
mountPath: /etc/nginx/conf.d #容器内挂载路径
- name: nginx-data
mountPath: /usr/share/nginx/html
volumes:
- name: config-volume
configMap:
name: nginxconf #使用nginxconf这个cm
- name: nginx-data
emptyDir: {}
---
# YAML配置应用
kubectl create -f deploy-nginxconf.yaml
# YAML配置验证
kubectl get all
kubectl get pod -o wide
# 访问Pod的Nginx
curl :8000
# 修改nginx.conf文件
vi nginx.conf
---
server {
listen 8080; #修改访问端口
server_name _;
location / {
root /usr/share/nginx/html;
index index.html index.html;
}
}
---
> 此时需要等待一定的时间，可能大概是几秒。
# 检查ConfigMap是否更新完毕
kubectl edit cm nginxconf
> 更新完毕，它并不会触发滚动更新到Pod, 而是需要手动触发。
# 触发更新
kubectl patch deployments.apps deploy-nginxconf --patch '{"spec": {"template": {"metadata": {"annotations": {"version/config": "20220417"}}}}}'
> version值一旦变动就会实现更新
Secret 是一个包含少量敏感数据（例如密码、令牌或密钥）的对象。否则，此类信息可能会被放入 荚规范或在 容器图像. 使用 Secret 意味着您不需要在应用程序代码中包含机密数据。
由于 Secret 可以独立于使用它们的 Pod 创建，因此在创建、查看和编辑 Pod 的工作流程中暴露 Secret（及其数据）的风险较小。Kubernetes 以及在集群中运行的应用程序还可以对 Secrets 采取额外的预防措施，例如避免将秘密数据写入非易失性存储。
Secret用途默认情况下，Kubernetes Secret 未加密地存储在 API 服务器的底层数据存储 (etcd) 中。任何拥有 API 访问权限的人都可以检索或修改 Secret，任何拥有 etcd 访问权限的人都可以。此外，任何有权在命名空间中创建 Pod 的人都可以使用该访问权限来读取该命名空间中的任何 Secret；这包括间接访问，例如创建部署的能力。
为了安全地使用 Secrets，请至少采取以下步骤：
- 为Secret启用静态加密；
- 启用或配置限制读取和写入 Secret 的RBAC 规则。请注意，任何有权创建 Pod 的人都可以隐式获取秘密。
- 在适当的情况下，还可以使用 RBAC 等机制来限制允许哪些主体创建新的 Secret 或替换现有的 Secret。
Pod 使用 Secret 的三种主要方式：
- 作为文件挂载到Pod容器；
- 作为容器环境变量；
- 作为参数被Pod拉取镜像；
| 内置类型 | 用法 |
|---|---|
Opaque | 用户定义的任意数据 |
kubernetes.io/service-account-token | 服务账号令牌 |
kubernetes.io/dockercfg | ~/.dockercfg 文件的序列化形式 |
kubernetes.io/dockerconfigjson | ~/.docker/config.json 文件的序列化形式 |
kubernetes.io/basic-auth | 用于基本身份认证的凭据 |
kubernetes.io/ssh-auth | 用于 SSH 身份认证的凭据 |
kubernetes.io/tls | 用于 TLS 客户端或者服务器端的数据 |
bootstrap.kubernetes.io/token | 启动引导令牌数据 |
如果某个容器已经在通过环境变量使用某 Secret，对该 Secret 的更新不会被 容器马上看见，除非容器被重启。有一些第三方的解决方案能够在 Secret 发生 变化时触发容器重启。
Secret *** 作 创建Secret 1. 命令行创建Key-Value键值# 创建Secret
kubectl create secret generic secret-test-1 --from-literal=username=ericzhong --from-literal=password=1qaz@WSX
# 检查Secret
kubectl get secret secret-test-1 -o wide
kubectl describe secret secret-test-1
# 创建Secret
kubectl create secret generic secret-test-2 --from-env-file=./secret-env.txt
# 检查Secret
kubectl get secret secret-test-2 -o yaml
kubectl describe secret secret-test-2
# 创建Secret
kubectl create secret generic ssh-key-secret --from-file=./
# 检查Secret
kubectl get secret ssh-key-secret -o yaml
kubectl describe secret ssh-key-secret
# 创建Secret
vi secret-test-3.yaml
---
apiVersion: v1
kind: Secret
metadata:
name: secret-basic-auth
type: kubernetes.io/basic-auth
stringData:
username: ericzhong
# 值必须为string类型，所以数值类型的密码必须加引号
password: "1qaz@WSX"
---
secret信息默认是使用base64加密的，所以可以通过base64解密来查看secret配置的auth信息
# 查看Secret
kubectl get -f secret-basic-auth.yaml -o yaml
# 解密Secret
echo | base64 -d
# 加密Secret
echo | base64
# 创建YAML运用全体Secret
vi pod-secret-basic-auth.yaml
---
apiVersion: v1
kind: Secret
metadata:
name: secret-basic-auth
type: Opaque
data:
password: MWYyZDFlMmU2N2Rm
username: YWRtaW4=
---
apiVersion: v1
kind: Pod
metadata:
name: pod-secret-basic-auth
spec:
containers:
- name: pod-secret-basic-auth
image: redis
volumeMounts:
- name: foo
mountPath: "/etc/foo"
readOnly: true
imagePullPolicy: IfNotPresent
volumes:
- name: foo
secret:
secretName: secret-basic-auth
---
# 创建YAML运用指定Secret
vi pod-secret-basic-auth-username.yaml
---
apiVersion: v1
kind: Secret
metadata:
name: secret-basic-auth
type: Opaque
data:
password: MWYyZDFlMmU2N2Rm
username: YWRtaW4=
---
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- name: mypod
image: redis
volumeMounts:
- name: foo
mountPath: "/etc/foo"
readOnly: true
imagePullPolicy: IfNotPresent
volumes:
- name: foo
secret:
secretName: secret-basic-auth
items:
- key: username
path: my-group/my-username
---
# 创建YAML
vi pod-secret-env.yaml
---
apiVersion: v1
kind: Pod
metadata:
name: secret-env-pod
spec:
containers:
- name: mycontainer
image: redis
env:
- name: SECRET_USERNAME
valueFrom:
secretKeyRef:
name: secret-basic-auth
key: username
- name: SECRET_PASSWORD
valueFrom:
secretKeyRef:
name: secret-basic-auth
key: password
imagePullPolicy: IfNotPresent
restartPolicy: Never
---
# 检查Secret
kubectl get -f pod-secret-env.yaml
kubectl exec -it pod-secret-env -- /bin/bash
echo $SECRET_USERNAME
echo $SECRET_PASSWORD
# 设置Docker registry
kubectl create secret docker-registry harbor-docker-registry \
--docker-server=registry.zhong.com \
[email protected] \
--docker-password=xxxxxx \
[email protected]
# 设置Pod
vi docker-registry.yaml
---
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- name: ingress-controller
image: registry.zhong.com/ericzhong/nginx:v1.1.2 指定镜像拉取路径
imagePullSecrets: 镜像在拉取时的secret
- name: myregistrykey secret名称
---
# 应用YAML
kubectl create -f docker-registry.yaml
# 检查POD
kubectl get pod mypod
kubectl describe pod mypod
相同点：
- key/value的形式
- 属于某个特定的namespace
- 可以导出到环境变量
- 可以通过目录/文件形式挂载(支持挂载所有key和部分key)
不同点：
- Secret可以被ServerAccount关联(使用)
- Secret可以存储register的鉴权信息，用在ImagePullSecret参数中，用于拉取私有仓库的镜像
- Secret支持Base64加密
- Secret分为kubernetes.io/Service Account，kubernetes.io/dockerconfigjson，Opaque三种类型,Configmap不区分类型
- Secret文件存储在tmpfs文件系统中，Pod删除后Secret文件也会对应的删除。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）