zoukankan html css js c++ java

K8S Secrete详解

secret相对于configMap，功能上是相似的
但是secret是以其他编码方式去记录配置信息的，但是也可以被解读，只不过有技术门槛，不是那么容易就被解读。
使用base64可以解码：echo ******** | base64 -d
********是kubectl describe secret secretName -o yaml中的值的编码

secret有三种类型：(查看：kubectl create secret --help)
docker-registry 一般保存docker-registry的认证信息
generic 通用的，一般保存一些密码数据
tls 一般保存私钥或证书

pod创建时若连接到私有仓库中需要认证，则要创建专用的secret （docker-registry）类型的
pod.spec.imagePullSecrets字段中需要指明secret的name

generic方式的secret，里面的键值虽说不是铭文，但是解码的技术手段要求不高。
对于密码类型的信息，最好用数据卷挂载方式来实现信息的注入，然后以文件形式挂载到挂载点，设置权限。

例：用数据卷方式，将mysql的密码注入到pod的容器中。
1.创建secret
kubectl create secret generic test --from-literal=MYSQL_ROOT_PASSWORD=smb@nds

2.创建pod

 1 vim myapp-demo.yaml
 2 apiVersion: apps/v1
 3 kind: Deployment
 4 metadata:
 5   name: myapp-demo
 6   namespace: default
 7 spec:
 8   replicas: 1
 9   selector:
10     matchLabels:
11       app: myapp
12   template:
13     metadata:
14       labels:
15         app: myapp
16     spec:
17       containers:
18       - name: myapp
19         image: ikubernetes/myapp:v1
20         imagePullPolicy: IfNotPresent
21         ports:
22         - name: http
23           containerPort: 80
24         volumeMounts:
25         - name: mysql
26           mountPath: /test/
27       volumes:
28       - name: mysql
29         secret:
30           secretName: test

3.启动pod，查看信息是否注入

1 kubectl apply -f myapp-demo.yaml
2 kubectl exec -it myapp-demo-75f8f9bf9f-8nbdv -- /bin/sh
3 / # cat test/MYSQL_ROOT_PASSWORD
4 smb@nds/ #

可以看到，信息注入后是明文的，可以设置查看访问权限解决。

k8s中secret解析

概览

Secret是用来保存小片敏感数据的k8s资源，例如密码，token，或者秘钥。这类数据当然也可以存放在Pod或者镜像中，但是放在Secret中是为了更方便的控制如何使用数据，并减少暴露的风险。

用户可以创建自己的secret，系统也会有自己的secret。

Pod需要先引用才能使用某个secret，Pod有2种方式来使用secret：作为volume的一个域被一个或多个容器挂载；在拉取镜像的时候被kubelet引用。

內建的Secrets

由ServiceAccount创建的API证书附加的秘钥

k8s自动生成的用来访问apiserver的Secret，所有Pod会默认使用这个Secret与apiserver通信

创建自己的Secret

使用kubectl create secret命令创建Secret

假如mougePod要访问数据库，需要用户名密码，分别存放在2个文件中：username.txt，password.txt

# Create files needed for rest of example.
$ echo -n 'admin' > ./username.txt
$ echo -n '1f2d1e2e67df' > ./password.txt

kubectl create secret指令将用户名密码写到secret中，并在apiserver创建Secret

$ kubectl create secret generic db-user-pass --from-file=./username.txt --from-file=./password.txt
secret "db-user-pass" created

查看创建结果：

$ kubectl get secrets
NAME                  TYPE                                  DATA      AGE
db-user-pass          Opaque                                2         51s

$ kubectl describe secrets/db-user-pass
Name:            db-user-pass
Namespace:       default
Labels:          <none>
Annotations:     <none>

Type:            Opaque

Data
====
password.txt:    12 bytes
username.txt:    5 bytes

get或describe指令都不会展示secret的实际内容，这是出于对数据的保护的考虑，如果想查看实际内容请继续往下看。

手动创建Secret

创建一个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

……

限制

需要被挂载到Pod中的secret需要提前创建，否则会导致Pod创建失败

secret是有命名空间属性的，只有在相同namespace的Pod才能引用它

单个Secret容量限制的1Mb，这么做是为了防止创建超大的Secret导致apiserver或kubelet的内存耗尽。但是创建过多的小容量secret同样也会耗尽内存，这个问题在将来可能会有方案解决

kubelet只支持由API server创建出来的Pod中引用secret，使用特殊方式创建出来的Pod是不支持引用secret的，比如通过kubelet的--manifest-url参数创建的pod，或者--config参数创建的，或者REST API创建的。

通过secretKeyRef引用一个不存在你secret key会导致pod创建失败

Kubernetes中的Secret配置

通过案例学习 Secret - 每天5分钟玩转 Docker 容器技术（110）

在下面的例子中，我们会部署一个 WordPress 应用，WordPress 是流行的开源博客系统。

我们将创建一个 MySQL service，将密码保存到 secret 中。我们还会创建一个 WordPress service，它将使用 secret 连接 MySQL。这个例子将展示如何用 secret 避免在 image 中存放敏感信息，或者在命令行中直接传递敏感数据。

创建 secret 存放 MySQL 的管理员密码。

openssl rand -base64 20 | docker secret create mysql_root_password -

密码是由 openssl 生成的随机字符串。

注意 ag7injh6juonwl09lq8st36o8 是新创建的 service 的 ID，而非 service 的内容。

上面这种方式是从标准输入读取 secret 的内容，也可以指定从文件中读取，例如：

openssl rand -base64 20 > password.txt docker secret create my_password ./password.txt

一般情况下，应用不会直接用 root 密码访问 MySQL。我们会创建一个单独的用户 workpress，密码存放到 secret mysql_password中。

openssl rand -base64 20 | docker secret create mysql_password -

创建自定义的 overlay 网络

MySQL 通过 overlay 网络 mysql_private 与 WordPress 通信，不需要将 MySQL service 暴露给外部网络和其他容器。

docker network create -d overlay mysql_private

创建 MySQL service

命令如下：

docker service create 
     --name mysql 
     --network mysql_private 
     --secret source=mysql_root_password,target=mysql_root_password 
     --secret source=mysql_password,target=mysql_password 
     -e MYSQL_ROOT_PASSWORD_FILE="/run/secrets/mysql_root_password" 
     -e MYSQL_PASSWORD_FILE="/run/secrets/mysql_password" 
     -e MYSQL_USER="wordpress" 
     -e MYSQL_DATABASE="wordpress" 
     mysql:latest

MYSQL_DATABASE 指明创建数据库 wordpress。

MYSQL_USER 和 MYSQL_PASSWORD_FILE 指明创建数据库用户 workpress，密码从 secret mysql_password 中读取。

有关 mysql 镜像环境变量更详细的使用方法可参考 https://hub.docker.com/_/mysql/

创建 WordPress service

MySQL service 已就绪，现在创建 WordPress service。命令如下：

docker service create 
     --name wordpress 
     --network mysql_private 
     --publish 30000:80 
     --secret source=mysql_password,target=wp_db_password 
     -e WORDPRESS_DB_HOST="mysql:3306" 
     -e WORDPRESS_DB_NAME="wordpress" 
     -e WORDPRESS_DB_USER="wordpress" 
     -e WORDPRESS_DB_PASSWORD_FILE="/run/secrets/wp_db_password" 
     wordpress:latest

WORDPRESS_DB_HOST 指明 MySQL service 地址 mysql:3306，这里用到了 DNS。

WORDPRESS_DB_NAME 指明 WordPress 的数据库为 wordpress，与前面 MYSQL_DATABASE 一致。

WORDPRESS_DB_USER 指明连接 WordPress 数据库的用户为 wordpress，与前面 MYSQL_USER 一致。

WORDPRESS_DB_PASSWORD_FILE 指明数据库的用户 wordpress 的密码，从 secret mysql_password 中获取。

有关 wordpress 镜像环境变量更详细的使用方法可参考 https://hub.docker.com/_/wordpress/

验证 WordPress

访问 http://[swarm_master_ip]:30000/

能正常显示初始化界面，表明 WordPress 已经连接到 MySQL，部署成功。

Secret 就讨论到这里，下一节我们学习 Stack。

书籍：

1.《每天5分钟玩转Docker容器技术》
https://item.jd.com/16936307278.html

2.《每天5分钟玩转OpenStack》
https://item.jd.com/12086376.html

https://www.cnblogs.com/CloudMan6/tag/Docker/default.html?page=10

kubernetes资源类型--secret和Service Account

secret

概念

secret对象类型主要目的是保存和处理敏感信息/私密数据，比如密码，OAuth tokens，ssh keys等信息。将这些信息放在secret对象中比直接放在pod或docker image中更安全，也更方便使用。

一个已经创建好的secrets对象有两种方式被pod对象使用，其一，在container中的volume对象里以file的形式被使用，其二，在pull images时被kubelet使用。

类型

Opaque任意字符串，默认类型

kubernetes.io/service-account-token:作用于ServiceAccount

kubernetes.io/dockercfg:作用于Docker registry，用户下载docker镜像认证使用

Opaque

创建

文件

实现把需要加密的内容实现base64编码

echo -n lykops | base64

bHlrb3Bz

echo -n 1qaz2wsx | base64

MXFhejJ3c3g=

然后写入lykops-secret.yaml

apiVersion: v1
kind: Secret
metadata:
  name: test-secret
  namespace: default
type: Opaque
data:
  password: MXFhejJ3c3g=
  username: bHlrb3Bz

导入kubectl create -f lykops-secret.yaml

命令行

kubectl createsecret generic lykops --secret --from-literal=username=lykops--from-literal=password=1qaz2wsx

pod引用

cat << EOF > lykops-secret.yaml
apiVersion: v1
kind: Pod
metadata:
 name: lykops-secret-pod
 labels:
   software: apache
   project: lykops
   app: lykops-secret-pod
   version: v1
spec:
 containers:
    -name: lykops-secret-pod
     image: web:apache
     command: ['sh' , '/etc/run.sh']
     env:
       - name: SECRET_USERNAME
         valueFrom:
           secretKeyRef:
             name: lykops-secret
             key: username
       - name: SECRET_PASSWORD
         valueFrom:
           secretKeyRef:
             name: lykops-secret
             key: password

EOF

kubectl create -f lykops-secret-pod.yaml

然后进入pod

kubectl exec -it lykops-secret-pod /bin/bash

执行env | grep -i '^SECRET_'

SECRET_USERNAME=lykops

SECRET_PASSWORD=1qaz2wsx

imagePullSecrets

当在需要安全验证的环境中拉取镜像时，需要通过用户名和密码。

apiVersion: v1
kind: Secret
metadata:
 name: myregistrykey
 namespace: awesomeapps
data:
 .dockerconfigjson:UmVhbGx5IHJlYWxseSByZWVlZWVlZWVlZWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGx5eXl5eXl5eXl5eXl5eXl5eXl5eSBsbGxsbGxsbGxsbGxsbG9vb29vb29vb29vb29vb29vb29vb29vb29vb25ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubmdnZ2dnZ2dnZ2dnZ2dnZ2dnZ2cgYXV0aCBrZXlzCg==
type: kubernetes.io/dockerconfigjson

·或者直接通过命令创建

kubectl create secret docker-registrymyregistrykey --docker-server=DOCKER_REGISTRY_SERVER--docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD--docker-email=DOCKER_EMAIL

·接下来拉取镜像的时候，就可以使用了

apiVersion: v1
kind: Pod
metadata:
 name: foo
 namespace: awesomeapps
spec:
 containers:
    -name: foo
     image: janedoe/awesomeapp:v1
 imagePullSecrets:
    -name: myregistrykey

·其实本质上还是kubelet把这个认证放到了docker的目录下面，如下：

Service Account

概念

Service Account（以下简称SA）的使用场景：运行在pod里的进程需要调用K8S API以及非K8S API的其它服务。SA

cat ~/.docker/config.json
{
   "auths": {
       "10.39.0.118": {
           "auth": "Y2hlbm1vOmNtMTM4MTE2NjY3ODY="
       },
       "10.39.0.12:5000": {
           "auth": "dXNlcjAxOjEyMzQ1YQ=="
       },
       "http://10.39.0.12:5000": {
           "auth": "dXNlcjAxOjEyMzQ1YQ=="
       }
    }
}

并不是给K8S集群的用户使用的，而是给pod里面的进程使用的，它为pod提供必要的身份认证。

如果K8S开启了SA（位于/etc/kubernetes/controller-manager的KUBE_ADMISSION_CONTROL="--admission-control=NamespaceLifecycle,NamespaceExists,LimitRanger,SecurityContextDeny,ServiceAccount,ResourceQuota"），那么会在每个namespace下面都会创建一个默认的default的SA。

配置

当用户在namespace下创建pod时会默认使用sa。

……
 volumes:
  -name: default-token-rsf8r
   secret:
     defaultMode: 420
      secretName:default-token-rsf8r

具体看一下secret

kubectl get secret default-token-rsf8r -oyaml
apiVersion: v1
data:
 ca.crt:LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUR2akNDQXFhZ0F3SUJBZ0lVZlpvZDJtSzNsa3JiMzR3NDhhUmtOc0pVVDJjd0RRWUpLb1pJaHZjTkFRRUwKQlFBd1pURUxNQWtHQTFVRUJoTUNRMDR4RURBT0JnTlZCQWdUQjBKbGFVcHBibWN4RURBT0JnTlZCQWNUQjBKbAphVXBwYm1jeEREQUtCZ05WQkFvVEEyczRjekVQTUEwR0ExVUVDeE1HVTNsemRHVnRNUk13RVFZRFZRUURFd3ByCmRXSmxjbTVsZEdWek1CNFhEVEUzTURVd01qQTNNekF3TUZvWERUSXlNRFV3TVRBM016QXdNRm93WlRFTE1Ba0cKQTFVRUJoTUNRMDR4RURBT0JnTlZCQWdUQjBKbGFVcHBibWN4RURBT0JnTlZCQWNUQjBKbGFVcHBibWN4RERBSwpCZ05WQkFvVEEyczRjekVQTUEwR0ExVUVDeE1HVTNsemRHVnRNUk13RVFZRFZRUURFd3ByZFdKbGNtNWxkR1Z6Ck1JSUJJakFOQmdrcWhraUc5dzBCQVFFRkFBT0NBUThBTUlJQkNnS0NBUUVBc2E5Zk1HVGd2MGl0YnlZcHoycXkKOThKWktXdWdFL0VPbXRYS2ExT0Y3ekUxSFh1cDFOVG8rNkhvUEFuR3hhVzg4Q0s0TENrbWhNSGFLdUxnT3IvVApOMGphdnc5YWlPeVdYR1hXUUxVN3U0aVhoaDV6a2N4bmZxRW9JOW9JV2dMTzVEL3hBL0tnZzRQZDRMeFdqMkFQCk4rcVdxQ2crU3BrdkpIQUZWL3IyTk1BbEIzNHBrK0t5djVQMDJSQmd6Y2xTeSs5OUxDWnlIQ1VocGl0TFFabHoKdUNmeGtBeUNoWFcxMWNKdVFtaDM4aFVKa0dhUW9OVDVSNmtoRTArenJDVjVkWnNVMVZuR0FydWxaWXpJY3kregpkeUZpYWYyaitITyt5blg4RUNySzR1TUF3Nk4zN1pnNjRHZVRtbk5EWmVDTTlPelk5czBOVzc1dHU5bHJPZTVqCnZRSURBUUFCbzJZd1pEQU9CZ05WSFE4QkFmOEVCQU1DQVFZd0VnWURWUjBUQVFIL0JBZ3dCZ0VCL3dJQkFqQWQKQmdOVkhRNEVGZ1FVK2RqMThRUkZyMWhKMVhGb1VyYUVVRnpEeVRBd0h3WURWUjBqQkJnd0ZvQVUrZGoxOFFSRgpyMWhKMVhGb1VyYUVVRnpEeVRBd0RRWUpLb1pJaHZjTkFRRUxCUUFEZ2dFQkFBazQ4ODZBa0Fpa3VBVWRiOWU1CitldkVXVVFFaTIyTmc4REhmVTVSbXppU2ZhVllFQ1FuTlBUREprMmYvTm1Kb3RUVWxRZS9Ec3BkNEk1TFova1IKMGI2b1VoZkdmTkVOOXVObkkvZEgzOFBjUTNDaWtVeHhaeFRYTytaaldxcGNHZTRLNzZtaWd2ZWhQR2Z1VUNzQwp0UmZkZDM2YkhnRjN4MzRCWnc5MStDQ2VKQzBSWmNjVENqcHFHUEZFQlM3akJUVUlRVjNodnZycWJMV0hNeTJuCnFIck94UFI1eFkrRU5SQ0xzVWNSdk9icUhBK1g0c1BTdzBwMWpROXNtK1lWNG1ybW9Gd1RyS09kK2FqTVhzVXkKL3ZRYkRzNld4RWkxZ2ZvR3BxZFN6U1k0MS9IWHovMjZWNlFWazJBajdQd0FYZmszYk1wWHdDamRXRG4xODhNbQpXSHM9Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K
 namespace: ZGVmYXVsdA==
 token:ZXlKaGJHY2lPaUpTVXpJMU5pSXNJblI1Y0NJNklrcFhWQ0o5LmV5SnBjM01pT2lKcmRXSmxjbTVsZEdWekwzTmxjblpwWTJWaFkyTnZkVzUwSWl3aWEzVmlaWEp1WlhSbGN5NXBieTl6WlhKMmFXTmxZV05qYjNWdWRDOXVZVzFsYzNCaFkyVWlPaUprWldaaGRXeDBJaXdpYTNWaVpYSnVaWFJsY3k1cGJ5OXpaWEoyYVdObFlXTmpiM1Z1ZEM5elpXTnlaWFF1Ym1GdFpTSTZJbVJsWm1GMWJIUXRkRzlyWlc0dGNuTm1PSElpTENKcmRXSmxjbTVsZEdWekxtbHZMM05sY25acFkyVmhZMk52ZFc1MEwzTmxjblpwWTJVdFlXTmpiM1Z1ZEM1dVlXMWxJam9pWkdWbVlYVnNkQ0lzSW10MVltVnlibVYwWlhNdWFXOHZjMlZ5ZG1salpXRmpZMjkxYm5RdmMyVnlkbWxqWlMxaFkyTnZkVzUwTG5WcFpDSTZJakJrWlRJek5UYzFMVEptTURJdE1URmxOeTA1T0dRd0xUVXlOVFJqTkRZeU9HRmtPU0lzSW5OMVlpSTZJbk41YzNSbGJUcHpaWEoyYVdObFlXTmpiM1Z1ZERwa1pXWmhkV3gwT21SbFptRjFiSFFpZlEuSmxuamM0Y0xNYkZrRlJVQjIyWGtFN2t4bTJ1dS1aQm9sUTh4VEdDNmdLOTdSZTVOMzBuY2V0SWJsanVOVWFlaDhtMDk2R19nMHE3cmRvWm5XMTV2OFBVXzNyM1hWWlBNc1lxbGRpZlNJbWtReXFqeEphVlBka3Izam5GWVBkVWNaTmk3MFF3cWtEdm5sMXB4SFRNZTZkTVNPTlExbUVoMHZSbHBhRTdjVWtTVlg5blRzaFVJVTVXWE9wRUxwdTVjVjBHV3ZGeDRDSzR6Umt3clNMdlV5X2d5UGZwLWdYVFZQWU80NkJKSWZtaVhlZGhVaW9nempPN285eGxDbUxQVkhyNkFIZGViNExiTVA1dkJ2MlBSZ2RrMW9keTR0VEdxLVRGU3M2VkNoMTZ4dk5IdTRtRVN5TjZmcXVObzJwYUFOelY4b251aTJuaU4yNTU1TzN4SFdR
kind: Secret
metadata:
 annotations:
   kubernetes.io/service-account.name: default
   kubernetes.io/service-account.uid: 0de23575-2f02-11e7-98d0-5254c4628ad9
 name: default-token-rsf8r
 namespace: default
 resourceVersion: "12551"
 selfLink: /api/v1/namespaces/default/secrets/default-token-rsf8r
  uid:75c0a236-2f02-11e7-98d0-5254c4628ad9
type: kubernetes.io/service-account-token

上面的内容是经过base64加密过后的，直接进入容器内：

ls -l /var/run/secrets/kubernetes.io/serviceaccount/
total 0
lrwxrwxrwx   1 root     root            13 May  4 23:57 ca.crt -> ..data/ca.crt
lrwxrwxrwx   1 root     root            16 May  4 23:57 namespace -> ..data/namespace
lrwxrwxrwx   1 root     root            12 May  4 23:57 token -> ..data/token

可以看到已将ca.crt 、namespace和token放到容器内了，那么这个容器就可以通过https的请求访问apiserver了。

Kubernetes里的secret最基本的用法

Secret解决了密码、token、密钥等敏感数据的配置问题，使用Secret可以避免把这些敏感数据以明文的形式暴露到镜像或者Pod Spec中。

Secret可以以Volume或者环境变量的方式使用。

使用如下命令行创建一个secret：

kubectl create secret generic admin-access --from-file=./username.txt --from-file=./password.txt

输入文件username.txt和password.txt需要手动创建，里面分别维护用于测试的用户名和密码。

创建成功后，发现secret的类型为Opaque：

实际上，Kubernetes的secret有三种类型：

1. Service Account：用来访问Kubernetes API，由Kubernetes自动创建，并且会自动挂载到Pod的 /run/secrets/kubernetes.io/serviceaccount 目录中；

2. Opaque：base64编码格式的Secret，用来存储密码、密钥等；

3. kubernetes.io/dockerconfigjson ：用来存储私有docker registry的认证信息。

而我们刚刚创建的secret的类型为Opaque，因此在kubectl get secrets的返回结果里，能看到password和username的值均为base64编码：

要在pod里消费这个secret也很容易，看一个例子：

apiVersion: v1

kind: Pod

metadata:

name: secret-pod

spec:

restartPolicy: Never

volumes:

- name: credentials

secret:

secretName: admin-access

defaultMode: 0440

containers:

- name: secret-container

image: alpine:3.8

command: [ "/bin/sh", "-c", "cat /etc/foo/username.txt /etc/foo/password.txt" ]

volumeMounts:

- name: credentials

mountPath: "/etc/foo"

readOnly: true

创建pod，自动执行，通过log命令查看pod的日志：

发现/bin/sh命令被执行了，pod mount的目录/etc/foo下的username.txt和password.txt通过cat命令显示了输出：

kubernetes系列12—二个特色的存储卷configmap和secret

1、configmap

1.1 认识configmap

　　ConfigMap用于保存配置数据的键值对，可以用来保存单个属性，也可以用来保存配置文件。ConfigMap跟secret很类似，但它可以更方便地处理不包含敏感信息的字符串。

1.2 创建configmap

1.2.1 通过命令行

创建一个名为nginx-config的configmap，指定端口和server name

[root@master ~]# kubectl create configmap nginx-config --from-literal=nginx_port=80 --from-literal=server_name=myapp.along.com
configmap/nginx-config created
[root@master ~]# kubectl get cm
NAME           DATA      AGE
nginx-config   2         11s
[root@master ~]# kubectl describe cm nginx-config
Name:         nginx-config
Namespace:    default
Labels:       <none>
Annotations:  <none>
 
Data
====
nginx_port:
----
80
server_name:
----
myapp.along.com
Events:  <none>

1.2.2 通过文件

（1）准备文件

[root@master ~]# mkdir configmap
[root@master ~]# cd configmap
[root@master configmap]# vim www.conf
server {
        server_name myapp.along.com;
        listen 80;
        root /data/web/html/;
}

（2）创建查询认证

[root@master configmap]# kubectl create configmap nginx-www --from-file=./www.conf
configmap/nginx-www created
[root@master configmap]# kubectl get cm
NAME           DATA      AGE
nginx-config   2         3m
nginx-www      1         5s
[root@master configmap]# kubectl describe cm nginx-www
Name:         nginx-www
Namespace:    default
Labels:       <none>
Annotations:  <none>
 
Data
====
www.conf:
----
server {
  server_name myapp.along.com;
  listen 80;
  root /data/web/html/;
}
 
Events:  <none>

1.3 创建pod使用configmap

1.3.1 pod通过环境变量使用configmap

通过使用环境变量传入pod的configmap，不能实时更新

（1）编写configmap的yaml文件

[root@master configmap]# vim pod-configmap.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-cm-1
  namespace: default
  labels:
    app: myapp
    tier: frontend
  annotations:
    along.com/created-by: "cluster admin"
spec:
  containers:
  - name: myapp
    image: ikubernetes/myapp:v1
    ports:
    - name: http
      containerPort: 80
    env:
    - name: NGINX_SERVER_PORT
      valueFrom:
        configMapKeyRef:
          name: nginx-config
          key: nginx_port
    - name: NGINX_SERVER_NAME
      valueFrom:
        configMapKeyRef:
          name: nginx-config
          key: server_name

（2）创建pod，查询认证

[root@master configmap]# kubectl apply -f pod-configmap.yaml
pod/pod-cm-1 created
[root@master configmap]# kubectl get pods
NAME                            READY     STATUS    RESTARTS   AGE
pod-cm-1                        1/1       Running   0          41s
---查询pod内部变量
[root@master configmap]# kubectl exec -it pod-cm-1 -- printenv |grep NGINX_SERVER
NGINX_SERVER_PORT=80
NGINX_SERVER_NAME=myapp.along.com

（3）通过环境变量导入configmap，修改configmap后，pod中内容不会更改

① 使用edit修改configmap，把nginx_port 80改为8080

[root@master configmap]# kubectl edit cm nginx-config
... ...
  nginx_port: "8080"     #把80改为8080
... ...
configmap/nginx-config edited

② 查询，configmap被修改，但是pod中变量并未修改

因为configmap只是在容器启动时加载生效；现在pod已经创建，再修改，不会生效

------cm已经修改------
[root@master configmap]# kubectl describe cm nginx-config  
Data
====
nginx_port:
----
8080
server_name:
----
myapp.along.com
Events:  <none>
------但是pod实际没有改变------
[root@master configmap]# kubectl exec -it pod-cm-1 -- printenv |grep NGINX_SERVER  
NGINX_SERVER_PORT=80
NGINX_SERVER_NAME=myapp.along.com

1.3.2 pod通过存储卷使用configmap

通过使用存储卷传入pod的configmap，可以实时更新

（1）编写configmap的yaml文件，并创建configmap

创建一个volume，使用上边创建好的名为nginx-config的configmap

[root@master configmap]# vim pod-configmap-2.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-cm-2
  namespace: default
  labels:
    app: myapp
    tier: frontend
  annotations:
    along.com/created-by: "cluster admin"
spec:
  volumes:
  - name: nginxconf
    configMap:
      name: nginx-config
  containers:
  - name: myapp
    image: ikubernetes/myapp:v1
    ports:
    - name: http
      containerPort: 80
    volumeMounts:
    - name: nginxconf
      mountPath: /etc/nginx/config.d/
      readOnly: true
[root@master configmap]# kubectl apply -f pod-configmap-2.yaml
pod/pod-cm-2 created

（2）登入pod中，查询验证

[root@master configmap]# kubectl get pods
NAME       READY     STATUS    RESTARTS   AGE
pod-cm-2   1/1       Running   0          7s
[root@master ~]# kubectl exec -it pod-cm-2 -- /bin/sh
/ # cd /etc/nginx/config.d/
/etc/nginx/config.d # ls
nginx_port   server_name
/etc/nginx/config.d # cat nginx_port
80
/etc/nginx/config.d # cat server_name
myapp.along.com

（3）通过环境变量导入configmap，修改configmap后，pod中内容会更改

① 使用edit修改configmap，把nginx_port 80改为8080

[root@master ~]# kubectl edit cm nginx-config
apiVersion: v1
data:
  nginx_port: "8080"
  server_name: myapp.along.com
... ...
configmap/nginx-config edited

② 再登入pod查看，发现已经改变

[root@master ~]# kubectl exec -it pod-cm-2 -- /bin/sh
/ # cat /etc/nginx/config.d/nginx_port
8080/

1.4 一个完整的configmap的应用实例

1.4.1 编写创建pod的yaml文件，使用nginx-www的configmap

[root@master configmap]# vim pod-configmap-3.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-cm-3
  namespace: default
  labels:
    app: myapp
    tier: frontend
  annotations:
    along.com/created-by: "cluster admin"
spec:
  volumes:
  - name: nginxconf
    configMap:
      name: nginx-www
  containers:
  - name: myapp
    image: ikubernetes/myapp:v1
    ports:
    - name: http
      containerPort: 80
    volumeMounts:
    - name: nginxconf
      mountPath: /etc/nginx/conf.d/
      readOnly: true

1.4.2 创建pod

[root@master configmap]# kubectl apply -f pod-configmap-3.yaml
pod/pod-cm-3 created
[root@master configmap]# kubectl get pods
NAME       READY     STATUS    RESTARTS   AGE
pod-cm-3   1/1       Running   0          24s

1.4.3 登入pod，查询配置是否成功

[root@master configmap]# kubectl exec -it pod-cm-3 -- /bin/sh
/ # cat /etc/nginx/conf.d/www.conf
server {
        server_name myapp.along.com;
        listen 80;
        root /data/web/html/;
}
/ # nginx -T |tail -7      #-T查询nginx的配置信息
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
# configuration file /etc/nginx/conf.d/www.conf:
server {
    server_name myapp.along.com;
    listen 80;
    root /data/web/html/;
}
---生成nginx的主页内容
/ # mkdir -p /data/web/html
/ # vi /data/web/html/index.html
<h1>Nginx Server configured by CM</h1>

1.4.4 在其他节点访问，验证是否成功

（1）在master上新开一个窗口，查询pod对应的IP

[root@master ~]# kubectl get pods -o wide
NAME                            READY     STATUS    RESTARTS   AGE       IP            NODE
pod-cm-3                        1/1       Running   0          7m        10.244.1.124  node2

（2）在任意节点上配置host，使其能连通此pod

[root@node1 ~]# vim /etc/hosts
10.244.1.124 myapp.along.com

（3）访问pod，成功

[root@node1 ~]# curl myapp.along.com   
<h1>Nginx Server configured by CM</h1> 

2、secret

2.1 认识secret

Secret 对象类型用来保存敏感信息，例如密码、OAuth 令牌和 ssh key。将这些信息放在 secret 中比放在 pod 的定义或者 docker 镜像中来说更加安全和灵活。
Secret 是一种包含少量敏感信息例如密码、token 或 key 的对象。这样的信息可能会被放在 Pod spec 中或者镜像中；将其放在一个 secret 对象中可以更好地控制它的用途，并降低意外暴露的风险。
用户可以创建 secret，同时系统也创建了一些 secret。
要使用 secret，pod 需要引用 secret。Pod 可以用两种方式使用 secret：作为 volume 中的文件被挂载到 pod 中的一个或者多个容器里，或者当 kubelet 为 pod 拉取镜像时使用。
Secret有三种类型：
- Service Account：用来访问Kubernetes API，由Kubernetes自动创建，并且会自动挂载到Pod的/run/secrets/kubernetes.io/serviceaccount目录中；
- Opaque：base64编码格式的Secret，用来存储密码、密钥等；
- kubernetes.io/dockerconfigjson：用来存储私有docker registry的认证信息。

2.2 创建一个secret

---创建secret
[root@master ~]# kubectl create secret generic mysql-root-passwd --from-literal=password=MyP@ss123
secret/mysql-root-passwd created
---查询secret信息
[root@master ~]# kubectl get secret
NAME                  TYPE                                  DATA      AGE
default-token-wjbzf   kubernetes.io/service-account-token   3         35d
mysql-root-passwd     Opaque                                1         11s
---查询详细信息
[root@master ~]# kubectl describe secret mysql-root-passwd
Name:         mysql-root-passwd
Namespace:    default
Labels:       <none>
Annotations:  <none>
 
Type:  Opaque
 
Data
====
password:  9 bytes    #已经进行64位加密
---以yaml文件显示信息
[root@master ~]# kubectl get secret mysql-root-passwd -o yaml
apiVersion: v1
data:
  password: TXlQQHNzMTIz
kind: Secret
metadata:
  creationTimestamp: 2018-10-10T03:14:04Z
  name: mysql-root-passwd
  namespace: default
  resourceVersion: "436965"
  selfLink: /api/v1/namespaces/default/secrets/mysql-root-passwd
  uid: 8adbf6ae-cc3a-11e8-bb48-005056277243
type: Opaque
---解密
[root@master ~]# echo TXlQQHNzMTIz |base64 -d
MyP@ss123

2.3 通过secret向pod注入环境变量

（1）编写yaml文件，创建pod

[root@master configmap]# vim pod-secret-1.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-secret-1
  namespace: default
  labels:
    app: myapp
    tier: frontend
  annotations:
    along.com/created-by: "cluster admin"
spec:
  containers:
  - name: myapp
    image: ikubernetes/myapp:v1
    ports:
    - name: http
      containerPort: 80
    env:
    - name: MYSQL_ROOT_PASSWD
      valueFrom:
        secretKeyRef:
          name: mysql-root-passwd
          key: password
[root@master configmap]# kubectl apply -f pod-secret-1.yaml
pod/pod-secret-1 created

（2）查询并认证

[root@master configmap]# kubectl get pods
NAME                            READY     STATUS    RESTARTS   AGE
pod-secret-1                    1/1       Running   0          14s
---验证，查询pod中的环境变量，筛选出MYSQL_ROOT_PASSWD
[root@master configmap]# kubectl exec pod-secret-1 -- printenv |grep MYSQL
MYSQL_ROOT_PASSWD=MyP@ss123

　　通过使用存储卷传入pod的configmap，可以实时更新

（1）编写configmap的yaml文件，并创建configmap

创建一个volume，使用上边创建好的名为nginx-config的configmap

[root@master configmap]# vim pod-configmap-2.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-cm-2
  namespace: default
  labels:
    app: myapp
    tier: frontend
  annotations:
    along.com/created-by: "cluster admin"
spec:
  volumes:
  - name: nginxconf
    configMap:
      name: nginx-config
  containers:
  - name: myapp
    image: ikubernetes/myapp:v1
    ports:
    - name: http
      containerPort: 80
    volumeMounts:
    - name: nginxconf
      mountPath: /etc/nginx/config.d/
      readOnly: true
[root@master configmap]# kubectl apply -f pod-configmap-2.yaml
pod/pod-cm-2 created

（2）登入pod中，查询验证

[root@master configmap]# kubectl get pods
NAME       READY     STATUS    RESTARTS   AGE
pod-cm-2   1/1       Running   0          7s
[root@master ~]# kubectl exec -it pod-cm-2 -- /bin/sh
/ # cd /etc/nginx/config.d/
/etc/nginx/config.d # ls
nginx_port   server_name
/etc/nginx/config.d # cat nginx_port
80
/etc/nginx/config.d # cat server_name
myapp.along.com

（3）通过环境变量导入configmap，修改configmap后，pod中内容会更改

① 使用edit修改configmap，把nginx_port 80改为8080

[root@master ~]# kubectl edit cm nginx-config
apiVersion: v1
data:
  nginx_port: "8080"
  server_name: myapp.along.com
... ...
configmap/nginx-config edited

② 再登入pod查看，发现已经改变

[root@master ~]# kubectl exec -it pod-cm-2 -- /bin/sh
/ # cat /etc/nginx/config.d/nginx_port
8080/

查看全文

相关阅读:
腾讯优测优分享 | Android适配中的一些特殊情况小结
 腾讯优测优分享 | 你是否体验过Android手机插入耳机后仍外放的尴尬？
腾讯优测优分享 | 让你头疼的手机应用自动遍历可以这样实现
 腾讯优测优分享 | 适配路上，避免掉入“扫码调用相机”的坑
 腾讯优测优分享 | 游戏的UI自动化测试可以这样开展
 腾讯优测优分享 | 这样做测试用例评审更高效
 腾讯优测优分享 | Android性能测试工具化实现
 腾讯优测优分享 | 分布式系统测试的应用方法——场景注入测试
 腾讯优测优分享 | Android碎片化问题小结——关于闪光灯的那些事儿
 腾讯优测优分享 | 谈谈移动端屏幕适配的几种方法

原文地址：https://www.cnblogs.com/panpanwelcome/p/13631760.html