K8S Secrete详解

k8s的secret基本概念及案例

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/

posted @ 2020-09-08 12:13 PanPan003 阅读(1598) 评论(0) 编辑收藏举报

刷新页面返回顶部

晴天彩虹

K8S Secrete详解

概览

內建的Secrets

创建自己的Secret

手动创建Secret

解析Secret中内容

限制

创建自定义的 overlay 网络

创建 MySQL service

创建 WordPress service

验证 WordPress

secret

概念

类型

Opaque

创建

文件

命令行

pod引用

imagePullSecrets

Service Account

概念

配置

1、configmap

1.1 认识configmap

1.2 创建configmap

1.2.1 通过命令行

1.2.2 通过文件

1.3 创建pod使用configmap

1.3.1 pod通过环境变量使用configmap

1.3.2 pod通过存储卷使用configmap

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

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

1.4.2 创建pod

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

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

2、secret

2.1 认识secret

2.2 创建一个secret

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

公告