Kubernetes系列-配置存储 ConfigMap & Secret

1 ConfigMap介绍

1.1 概述

在部署应用程序时,我们都会涉及到应用的配置,在容器中,如Docker容器中,如果将配置文件打入容器镜像,这种行为等同于写死配置,每次修改完配置,镜像就得重新构建。当然,我们也可以通过挂载包含该文件的卷进行配置管理和修改。而在k8s中,我们要讲一种更好的方式,即ConfigMap,这种资源对象的出现,更是极大的方便了应用程序的配置管理。
ConfigMap是一个或多个key/value的形式保存在k8s中,内部可以管理变量也可以管理完整的配置文件内容。

1.2 用法

  • 生成容器内的环境变量,在pod中可以通过spec.env或者spec.envFrom进行引用。
  • 设置容器启动命令的启动参数,前提是设置为环境变量。
  • 以卷volume的方式挂载到容器内部的文件或目录,通过spec.volumes引用。

注:在使用命令的时候注意单词: configmap等价于cm,cm算是简写,类似于deployment可以使用命令时写成deploy,service可以写成svc,namespace可以写成ns,pod可以写成po。

1.3 应用场景

configmap配置信息和镜像解耦,实现方式是把配置信息放到configmap对象中,然后在pod中作为volume挂载到pod中,从而实现导入配置的目的

适用场景:

  • 通过configmap给pod定义全局环境变量
  • 通过configmap给pod传递命令行参数,如mysql -u -p中的账户名密码都可以通过它传递
  • 通过configmap给pod中的容器服务提供配置文件,配置文件以挂载到容器的形式适用

注意事项:

  • configmap需要在pod使用它之前创建
  • pod和configmap必须在同一个namespace中才能使用
  • 主要用于非安全加密的配置场景
  • configmap通常用于小于1MB的配置,常用于配置文件
  • kubelet只支持可以被API Server管理的Pod使用ConfigMap。
  • kubelet在本Node上通过--manifest-url--config自动创建的静态 Pod 将无法引用 Conf1gMap。
  • 在 Pod 对 ConfigMap 进行挂载(volumeMount)操作时,容器内部只能挂载为“目录”, 无法挂载为“文件”。在挂载到容器内部后,目录中将包含 ConfigMap 定义的每个item,如果该目录下原来还有其他文件,则容器内的该目录将会被挂载的 ConfigMap 覆盖。 如果应用程序需要保留原来的其他文件,则需要进行额外的处理。可以将 ConfigMap 挂载到容器内部的临时目录,再通过启动脚本将配置文件复制或者链接到(cp或link命令)应用所用的实际配置目录下。

1.4 创建

1.4.1 yaml文件方式创建

示例:

apiVersion: v1
kind: ConfigMap
metadata:
  name: cm-test01
data:
  appconf01: value01
  appconf02: value02

命令:

[root@k8s-master k8s]# kubectl create -f cm-test01.yaml 
configmap/cm-test01 created

1.4.2 命令行方式创建

读取文件方式(也可以是目录)通过--from-file参数从文件中读取。可以指定key的名称,若不指定,则默认使用文件名为key。
案例:如当前目录有一个配置文件为test.properties

[root@k8s-master k8s]# cat test.properties 
key01:value01
key02:value02
conf01: value03

命令:

[root@k8s-master k8s]# kubectl create cm cm-test-file --from-file=test.properties
configmap/cm-test-file created

//指定参数方式,通过--from-literal指定keyxx=valuexx创建confimap中的data内配置属性。

[root@k8s-master k8s]#  kubectl create configmap cm-test-literal --from-literal=key01=value01 --from-literal=key02=value02
configmap/cm-test-literal created

1.5 查询

1.5.1 查询configmap列表

[root@k8s-master k8s]# kubectl get cm
NAME               DATA   AGE
cm-test-file       1      3m51s
cm-test-literal    2      3m30s
cm-test01          2      9m2s
kube-root-ca.crt   1      4d16h

1.5.2 查看configmap详细信息

[root@k8s-master k8s]# kubectl describe cm cm-test01
Name:         cm-test01
Namespace:    default
Labels:       <none>
Annotations:  <none>
 
Data
====
appconf01:
----
value01
appconf02:
----
value02
Events:  <none>
[root@k8s-master k8s]# kubectl describe cm cm-test-file
Name:         cm-test-file
Namespace:    default
Labels:       <none>
Annotations:  <none>
 
Data
====
test.properties:
----
key01:value01
key02:value02
conf01: value03
 
 
Events:  <none>
[root@k8s-master k8s]# kubectl describe cm cm-test-literal
Name:         cm-test-literal
Namespace:    default
Labels:       <none>
Annotations:  <none>
 
Data
====
key01:
----
value01
key02:
----
value02
Events:  <none>

1.5.3 查看yaml输出

[root@k8s-master k8s]# kubectl get cm cm-test01 -o yaml
apiVersion: v1
data:
  appconf01: value01
  appconf02: value02
kind: ConfigMap
metadata:
  creationTimestamp: "2022-08-07T00:18:47Z"
  name: cm-test01
  namespace: default
  resourceVersion: "44876"
  uid: 7492a928-b163-4b86-a3dd-54a7fbe59a10
[root@k8s-master k8s]# kubectl get configmap cm-test-file -o yaml
apiVersion: v1
data:
  test.properties: |+
    key01:value01
    key02:value02
    conf01: value03
 
kind: ConfigMap
metadata:
  creationTimestamp: "2022-08-07T00:23:58Z"
  name: cm-test-file
  namespace: default
  resourceVersion: "45341"
  uid: 818a39b4-cbaf-4643-9541-1119b4d61982
[root@k8s-master k8s]# kubectl get cm cm-test-literal -o yaml
apiVersion: v1
data:
  key01: value01
  key02: value02
kind: ConfigMap
metadata:
  creationTimestamp: "2022-08-07T00:24:19Z"
  name: cm-test-literal
  namespace: default
  resourceVersion: "45372"
  uid: 051849e0-bf0a-4926-a549-2405dc4963cc

1.6 更新

1.6.1 edit

[root@k8s-master k8s]# kubectl edit cm cm-test01
configmap/cm-test01 edited

通过kubectl describe cm cm-test01查看更新是否生效。

[root@k8s-master k8s]# kubectl describe cm cm-test01
Name:         cm-test01
Namespace:    default
Labels:       <none>
Annotations:  <none>
 
Data
====
appconf02:
----
value02
appconf01:
----
value001
Events:  <none>

1.6.2 apply

直接更新yaml文件里的值,通过 kubectl apply -f configmap-test01.yaml重新发布一遍进行更新。

1.7 删除

1.7.1 通过yaml文件方式删除

$ kubectl delete -f configmap-test01.yaml

1.7.2 直接删除资源

kubectl delet cm cm-test01

2 ConfigMap和Pod的使用

容器应用对ConfigMap的使用主要是两种:
1)通过环境变量获取ConfigMap的内容:spec.envspec.envFrom
2)通过卷volume挂载的方式将ConfigMap的内容挂载到容器内部的文件或目录:spec.volumes。

2.1 环境变量方式

2.1.1 sepc.env方式

2.1.1.1 创建pod
[root@k8s-master k8s]# vim pod-test01.yaml
 
apiVersion: v1
kind: Pod
metadata:
  name: cm-pod-test001
spec:
  containers:
  - name: cm-test
    image: tomcat:8
    command: [ "/bin/sh", "-c", "env | grep APP"]
    env:
    - name: APPCONF01 		# 定义环境变量的名称
      valueFrom:	  		# key “appconf01”的值获取
        configMapKeyRef:
          name: cm-test01	# 环境变量的值来自于configmap cm-test01
          key: appconf01	# configmap中的配置key为appconf01
    - name: APPCONF02		# 定义环境变量的名称
      valueFrom:			# key “appconf02”的值获取
        configMapKeyRef:
          name: cm-test01	# 环境变量的值来自于configmap cm-test01
          key: appconf02	# configmap中的配置key为appconf02
  restartPolicy: Never		# 重启策略:从不。

执行创建pod:

[root@k8s-master k8s]# kubectl create -f pod-test01.yaml
pod/cm-test001 created
2.1.1.2 查看pod
[root@k8s-master k8s]# kubectl get pods
[root@k8s /cm/test]#  kubectl get pods
NAME             READY     STATUS      RESTARTS   AGE
cm-pod-test001   0/1       Completed   0          1h
2.1.1.3 查看pod日志
[root@k8s-master k8s]# kubectl logs cm-pod-test001
APPCONF01=value01
APPCONF02=value02

说明容器内部的环境变量使用ConfigMap中进行读取的

2.1.2 spec.envFrom方式

2.1.2.1 创建pod
[root@k8s-master k8s]# vim pod-test02.yaml
 
piVersion: v1
kind: Pod
metadata:
  name: cm-pod-test002
spec:
  containers:
  - name: cm-test2
    image: tomcat:8
    command: [ "/bin/sh", "-c", "env"]
    envFrom:
    - configMapRef:
      name: cm-test01  # 根据ConfigMap cm-test01资源自动生成环境变量
  restartPolicy: Never

执行创建pod:

[root@k8s-master k8s]# kubectl create -f pod-test02.yaml
2.1.2.2 查看pod
[root@k8s-master k8s]#  kubectl get po
NAME             READY     STATUS      RESTARTS   AGE
cm-pod-test001   0/1       Completed   0          2h
cm-pod-test002   0/1       Completed   0          1h
注意:
环境变量的名称受限制:[a-zA-Z][a-zA-Z0-9_]*,不能以数字或非法字符开头。

2.2 卷挂载方式

2.2.1 指定items

[root@k8s-master k8s]#  vim pod-test03.yaml
apiVersion: v1
kind: Pod
metadata:
  name: cm-pod-test003
spec:
  containers:
  - name: cm-test3
    image: tomcat:8
    volumeMounts:
    - name: vm-01-1
      mountPath: /conf
  volumes:
  - name: vm-01-1
    configMap:
      name: cm-test-file
      items:
      - key: key-testproperties
        path: test.properties
  restartPolicy: Never

2.2.2 不指定items

[root@k8s-master k8s]#  vim pod-test04.yaml
apiVersion: v1
kind: Pod
metadata:
  name: cm-pod-test004
spec:
  containers:
  - name: cm-test4
    image: tomcat:8
    volumeMounts:
    - name: vm-02-2
      mountPath: /conf
  volumes:
  - name: vm-02-2
    configMap:
      name: cm-test-file
  restartPolicy: Never

进入容器中查看

[root@k8s-master k8s]# kubectl exec -it cm-pod-test004 -c cm-test4 -- bash

进入容器后,ls /conf查看是否有test.properties文件。

[root@k8s-master k8s]#  kubectl exec -it cm-pod-test004 -c cm-test4  -- bash
root@cm-pod-test004:/usr/local/tomcat# ls /conf
test.properties

2.3 补充

关于--from-file的方式的创建指定key和不指定key的区别
1)不指定key名

创建:

[root@k8s-master k8s]# kubectl create cm cm-test-file --from-file=test.properties

输出:

[root@k8s-master k8s]# kubectl get cm cm-test-file -o yaml

2)指定key
创建:

[root@k8s-master k8s]# kubectl create cm cm-test-file02 --from-file=tp=test.properties

输出:

[root@k8s-master k8s]# kubectl get cm cm-test-file -o yaml

若指定key的名称,configmap中将会使用指定名称;若不指定,则默认使用文件名为key。

3 Secret

3.1 概述

Secret对象存储数据的方式是以键值方式存储数据,在Pod资源进行调用Secret的方式是通过环境变量或者存储卷的方式进行访问数据,解决了密码、token、密钥等敏感数据的配置问题,而不需要把这些敏感数据暴露到镜像或者Pod Spec中。

另外,Secret对象的数据存储和打印格式为Base64编码的字符串,因此用户在创建Secret对象时,也需要提供该类型的编码格式的数据。在容器中以环境变量或存储卷的方式访问时,会自动解码为明文格式。需要注意的是,如果是在Master节点上,Secret对象以非加密的格式存储在etcd中,所以需要对etcd的管理和权限进行严格控制。

要使用 Secret,Pod 需要引用 Secret。 Pod 可以用三种方式之一来使用 Secret:

  • 作为挂载到一个或多个容器上的 卷 中的文件。
  • 作为容器的环境变量
  • 由 kubelet 在为 Pod 拉取镜像时使用

Secret 对象的名称必须是合法的 DNS 子域名。 在为创建 Secret 编写配置文件时,你可以设置 data 与/或 stringData 字段。 data 和 stringData 字段都是可选的。data 字段中所有键值都必须是 base64 编码的字符串。如果不希望执行这种 base64 字符串的转换操作,你可以选择设置 stringData 字段,其中可以使用任何字符串作为其取值。

3.2 Secret 的类型

在创建 Secret 对象时,你可以使用 Secret 资源的 type 字段,或者与其等价的 kubectl 命令行参数(如果有的话)为其设置类型。 Secret 的类型用来帮助编写程序处理 Secret 数据。

Kubernetes 提供若干种内置的类型,用于一些常见的使用场景。 针对这些类型,Kubernetes 所执行的合法性检查操作以及对其所实施的限制各不相同。

内置类型 用法
Opaque 用户定义的任意数据 base64编码格式的Secret,用来存储密码、密钥、信息、证书等,类型标识符为generic;
http://kubernetes.io/service-account-token 服务账号令牌 用来访问Kubernetes API,由Kubernetes自动创建,并且会自动挂载到Pod的/run/secrets/http://kubernetes.io/serviceaccount目录中;
http://kubernetes.io/dockercfg ~/.dockercfg 文件的序列化形式
http://kubernetes.io/dockerconfigjson ~/.docker/config.json 文件的序列化形式 用来存储私有docker registry的认证信息,类型标识为docker-registry
http://kubernetes.io/basic-auth 用于基本身份认证的凭据
http://kubernetes.io/ssh-auth 用于 SSH 身份认证的凭据
http://kubernetes.io/tls 用于 TLS 客户端或者服务器端的数据 用于为SSL通信模式存储证书和私钥文件,命令式创建类型标识为tls。
http://bootstrap.kubernetes.io/token 启动引导令牌数据

通过为 Secret 对象的 type 字段设置一个非空的字符串值,你也可以定义并使用自己 Secret 类型。如果 type 值为空字符串,则被视为 Opaque 类型。 Kubernetes 并不对类型的名称作任何限制。不过,如果你要使用内置类型之一, 则你必须满足为该类型所定义的所有要求。

3.3 Service Account

Kubernetes 在创建 Pod 时会自动创建一个服务账号 Secret 并自动修改你的 Pod 以使用该 Secret。该服务账号令牌 Secret 中包含了访问 Kubernetes API 所需要的凭据。

Service Account 用来访问kubernetes API,由Kubernetes自动创建,并且会自动挂载到Pod的/run/secrets/http://kubernetes.io/serviceaccount目录中。

Service Account 不需要我们自己去管理的,此证书是由kubernetes自己来进行维护管理的。

# 创建pod
kubectl run my-nginx --image=nginx:1.20.0

# 查看证书
kubctl exec -it podName -- bash

# 进入证书目录/run/secrets/kubernetes.io/serviceaccount查看即可
ca.crt
namespace
token

# 查看证书
# root@my-nginx:/run/secrets/kubernetes.io/serviceaccount# cat ca.crt 
-----BEGIN CERTIFICATE-----
MIIC5zCCAc+gAwIBAgIBADANBgkqhkiG9w0BAQsFADAVMRMwEQYDVQQDEwprdWJl
cm5ldGVzMB4XDTIxMDUxNzA3MTgyMloXDTMxMDUxNTA3MTgyMlowFTETMBEGA1UE
AxMKa3ViZXJuZXRlczCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALIB
eVgGvrAomjLyj4fgasSoJQoZnhpZj75wKDOg7gYFKmGb9oLX5qIj33jqmrK4bUI5
symIPTJTrNZ7FsVmeC66JiE50niMpxuD01pDJARTfc0cMgkFWDq7JsVptA7MNILT
81keKB7eOZY0Cx7c/O+9w6f6UrvpHTMgNvE6wG3StFw2YJFPhDC6ZqwduISzBIsK
wbTrwp6jBHPTxsQEmEuHuoe0Hz+sjov5wXFpw7QB5V+P980tVvgK1GGX9wPxMytJ
ofv3vwbvHD/DrotA6HNwdYELIEgFULXPGuO/HL4z7C2MJxqVW7UdirCdnBDtI6HB
m55toVZJtmHj7kCpkzMCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgKkMA8GA1UdEwEB
/wQFMAMBAf8wHQYDVR0OBBYEFIaXFp8Y2aneT8Wk59gysMNJxmOhMA0GCSqGSIb3
DQEBCwUAA4IBAQCuPXfqD25NJagNOoEPjXyTfWGCHHBJSqSknnz3B/KaJu7hzIwD
G5c5zLQwDc/chHNjaRRZWcvOpfQfmqdhRg0EdDIa/B4cVmGa9eUs7f2XwlZuu6aw
5VOoTRZ6h/a9L4RQLxSSWTl2/AR4YeiBiU1tjfrc+gmZTObptmNLyuDfU7A4BG7U
1N8AddG4dojH2a7xbAnIKbTjTXRtLsI5aC0BPWHazwwG5NOreCauD+yVnQlw/dcw
C74QaamuFeWr/K2W0pq0qcjH471xuKhOUnY02HkN7P1zOL2uIZQ613yBYNksmPZB
9AQJ9VZlD6szo0XoniWcSD0Z2J90pbFCJCUd
-----END CERTIFICATE-----

# 查看命名空间
root@my-nginx:/run/secrets/kubernetes.io/serviceaccount# cat namespace 
default

# 查看token
# root@my-nginx:/run/secrets/kubernetes.io/serviceaccount# cat token 
eyJhbGciOiJSUzI1NiIsImtpZCI6ImIyMVg2OTBtZm1jUVNWM2ZGMUI0QkQ2MzJVS0EyOER2N3NuZFpha3pRMDgifQ.eyJhdWQiOlsiaHR0cHM6Ly9rdWJlcm5ldGVzLmRlZmF1bHQuc3ZjLmNsdXN0ZXIubG9jYWwiXSwiZXhwIjoxNjU0MzM0NzE4LCJpYXQiOjE2MjI3OTg3MTgsImlzcyI6Imh0dHBzOi8va3ViZXJuZXRlcy5kZWZhdWx0LnN2Yy5jbHVzdGVyLmxvY2FsIiwia3ViZXJuZXRlcy5pbyI6eyJuYW1lc3BhY2UiOiJkZWZhdWx0IiwicG9kIjp7Im5hbWUiOiJteS1uZ2lueCIsInVpZCI6IjEyNzI5NWFjLWIzN2EtNDc5Zi1hMzYwLWEzNDg4ODA0NDgxZCJ9LCJzZXJ2aWNlYWNjb3VudCI6eyJuYW1lIjoiZGVmYXVsdCIsInVpZCI6IjE5Y2ZkZmM2LThlZGMtNDNjYy05YjUxLTJlNDUzZjMwNTRhZSJ9LCJ3YXJuYWZ0ZXIiOjE2MjI4MDIzMjV9LCJuYmYiOjE2MjI3OTg3MTgsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDpkZWZhdWx0OmRlZmF1bHQifQ.i-VcnUBSBGm6FlukqjgcWe50nBQNGgERoKjWhkPod5rTAIswJ9EGyUcADt-vYewT4CYb8R4SVRY53kfk2mPnaH54_b9BbHD5jixA99YxYcDc7N99UE_ySyJj13zHlPNRFgoagBKmwr2b2nXNtw5PEAKqI_lHbDI2oQfUHY_yTqUM9si6HMqGJJ7W2non44OzGnB33RAV--ZzJkr6oZBkgMesPYAwsJa4FMoCOIB8OtczQ3Yvtr7IxvMGoeSRbjcjN5A_v4p8-GpjlkbbXfMME9B04iFeZmhERQpkf6CwtnXgEtNwktYJATQ9jOE9lXLwYd4WpBr7zspmU67yuVtuqQ

3.4 Opaque Secret

3.4.1 创建示例

当 Secret 配置文件中未作显式设定时,默认的 Secret 类型是 Opaque。 当你使用 kubectl 来创建一个 Secret 时,你会使用 generic 子命令来标明 要创建的是一个 Opaque 类型 Secret。

Opaque类型的数据一个map类型,要求value是base64编码格式

# base64对用户名,密码加密效果演示
# [root@k8s-master configmap]# echo "superadmin" | base64
c3VwZXJhZG1pbgo=

# [root@k8s-master configmap]# echo "passpppp" | base64
cGFzc3BwcHAK
多次加密结果都是一样的,破解很容易
# secre-test.yaml配置文件方式
apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
 username: c3VwZXJhZG1pbgo=   # 上面演示用户名加密结果
 password: cGFzc3BwcHAK       # 密码加密结果
# [root@k8s-master configmap]# kubectl apply -f secret-test.yaml
secret/mysecret created

# [root@k8s-master configmap]# kubectl get secret
NAME                  TYPE                                  DATA   AGE
default-token-cgxwv   kubernetes.io/service-account-token   3      18d
mysecret              Opaque                                2      13s  # 自定义的secret类型为Opaque
tls-secret            kubernetes.io/tls                     2      8d

3.4.2 使用方式

3.4.2.1 作为挂载到一个或多个容器上的 卷 中的文件 
# 将secret挂载到volume中
# secret-in-volume.yaml
apiVersion: v1
kind: Pod
metadata:
 name: secret-test
 labels:
   name: secret-test
spec:
  containers:
  - name: nginx-secret-volume
    image: nginx:1.20.0
    imagePullPolicy: IfNotPresent
    volumeMounts:
    - name: myvolsecrets
      mountPath: "/etc/secrets" # 容器挂载数据卷,挂载到/etc/secrets目录下
      readOnly: true
  volumes: # 引入一个数据卷
  - name: myvolsecrets
    secret: # 挂载指定的secret
      secretName: mysecret
# [root@k8s-master configmap]# kubectl apply -f secret-in-volume.yaml
pod/secret-test created

# [root@k8s-master configmap]# kubectl get pods 
NAME          READY   STATUS    RESTARTS   AGE
secret-test   1/1     Running   0          3m1s

# 进入容器
[root@k8s-master configmap]# kubectl exec -it secret-test -n default -- bash

# 切换路径
# root@secret-test:/# cd /etc/secrets/

# 查看挂载文件
# root@secret-test:/etc/secrets# ls
password  username

# 查看文件内容--文件内容已自动解析为明文
# root@secret-test:/etc/secrets# cat password username
passpppp
superadmin

清理环境 kubectl delete -f secret-in-volume.yaml 

 3.4.2.2 作为容器的环境变量
# 将secret导出到环境变量中
# vim secret-to-env.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
 name: secret-to-envdeployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: pod-secret-to-env
  template:
    metadata:
      labels:
        app: pod-secret-to-env
    spec:
      containers:
      - name: secret-to-envdeployment
        image: nginx:1.20.0
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
        env: # 设置环境变量
        - name: TEST_USER
          valueFrom:
            secretKeyRef: # 核心在这里 secretKeyRef
              name: mysecret   # secret名称
              key: username    # key的名称
        - name: TEST_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysecret
              key: password
# [root@k8s-master configmap]# kubectl apply -f secret-to-env.yaml
deployment.apps/secret-to-envdeployment created

# [root@k8s-master configmap]# kubectl get pods 
NAME                                       READY   STATUS    RESTARTS   AGE
secret-to-envdeployment-67b9584f69-tmlzf   1/1     Running   0          9s

# 进入容器
# [root@k8s-master configmap]# kubectl exec -it  pod/secret-to-envdeployment-67b9584f69-tmlzf -n default -- bash

# 打印环境变量
# root@secret-to-envdeployment-67b9584f69-tmlzf:/# echo ${TEST_USER}
superadmin
# root@secret-to-envdeployment-67b9584f69-tmlzf:/# echo ${TEST_PASSWORD}
passpppp

猜你喜欢

转载自blog.csdn.net/ygq13572549874/article/details/132072844