k8s_day05_03

​ 对于敏感信息，k8s 专门提供了一种资源secret来保存。对敏感信息转换以后再保存，base64编码而非加密，每一次注入到pod中的时候，会自动解码，完成信息的还原。 secret 仍然是以非加密的形式存于etcd 上的，因此对于etcd 的访问采用 双向证书加密认证

​ ConfigMap的配置信息基本没有类别之分，创建secret 和 configmap 并没有什么异同的地方。 --from-literal 从命令行指定信息， -from-file 从文件加载信息 。不同的地方 就是要指定类型

secret 类型

一、Secret根据其用户存在类型的概念；

​ docker-registry：专用于让kubelet启动Pod时从私有镜像仓库pull镜像时，首先认证到Registry时使用；

方式一 、认证信息全部命令指定

Docker Registry类型，也是独特类型：
kubectl create secret docker-registry my-secret --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL

注意：==–docker-server 一般不指定。==因为docker镜像名称已经隐含了server镜像地址，如果名称里没有就是默认的dockerhub

[root@node01 ~]# kubectl create secret docker-registry habor-tom --docker-username=tom --docker-password=magedu.com --docker-email=tom@magedu.com --docker-server=https://registry.magedu.com/v2/
secret/habor-tom created
[root@node01 ~]# 

[root@node01 ~]# kubectl get secret/habor-tom
NAME        TYPE                             DATA   AGE
habor-tom   kubernetes.io/dockerconfigjson   1      58s
[root@node01 ~]# 

查看dockerharbor 的用户身份信息

[root@node01 ~]# kubectl get secret/habor-tom -o yaml|grep '\.dockercon'|awk '{print $NF}'|base64 -d
{"auths":{"https://registry.magedu.com/v2/":{"username":"tom","password":"magedu.com","email":"tom@magedu.com","auth":"dG9tOm1hZ2VkdS5jb20="}}}[root@node01 ~]# 

方式二、从docker的认证文件中加载信息，这时使用–from-file选项；

docker 文件的位置 ： $HOME/.dockercfg 或者 ~/.docker/config.json

何时引用，以及如何引用

pod 拉取镜像时使用 ：pod.spec.imagePullSecrets

二、tls：专门用于保存tls/ssl用到证书和配对儿的私钥；

​ TLS类型是一种独特的类型，在创建secret的命令行中，除了类型标识的不同之外，它还需要使用专用的选项–cert和–key。
​ 无论证书和私钥文件名是什么，它们会统一为： tls.crt tls.key

eg:

创建自签名的证书

[root@node01 chapter6]# (umask 077 ; openssl genrsa -out nginx.key 2048)
[root@node01 chapter6]# openssl req -new -x509 -key nginx.key -out nginx.crt -subj /C=CN/ST=Beijing/L=DevOps/CN=www.magedu.com
[root@node01 chapter6]# 

创建 tls 类型的secret

–key 指定密钥的文件位置

–cert 指定证书文件的位置

[root@node01 chapter6]# kubectl create secret  tls nginx-ssl-secret --key=./nginx.key --cert=./nginx.crt
secret/nginx-ssl-secret created
[root@node01 chapter6]# kubectl get secret/nginx-ssl-secret
NAME               TYPE                DATA   AGE
nginx-ssl-secret   kubernetes.io/tls   2      18s

发现创建的tls类型的secret 。 数据项的键 就是 特定的tls.key tls.crt 而非自定义的文件名称

[root@node01 chapter6]# kubectl describe  secret/nginx-ssl-secret
Name:         nginx-ssl-secret
Namespace:    default
Labels:       <none>
Annotations:  <none>

Type:  kubernetes.io/tls

Data
====
tls.key:  1675 bytes
tls.crt:  1237 bytes
[root@node01 chapter6]# 

同理 ，get -o yaml后 base64 解码， 就可以得到之前的证书/密钥

三、generic：余下的通用类型； 可以存在子类型

1、Opaque

eg: 创建mysql 密码

[root@node01 ~]# kubectl create secret generic mysql-root-authn  --from-literal=username=root --from-literal=password=Magedu.c0m
secret/mysql-root-authn created

查看创建的secret Opaque 表示未界定的模糊的

[root@node01 ~]# kubectl get secret/mysql-root-authn
NAME               TYPE     DATA   AGE
mysql-root-authn   Opaque   2      97s

describe发现只显示 大小

kubectl describe  secret/mysql-root-authn

Data
====
password:  10 bytes
username:  4 bytes

以yaml 格式输出是可以看到的

[root@node01 ~]# kubectl get secret/mysql-root-authn  -o yaml
apiVersion: v1
data:
  password: TWFnZWR1LmMwbQ==
  username: cm9vdA==

base64 解码

[root@node01 ~]# echo 'TWFnZWR1LmMwbQ=='|base64 -d
Magedu.c0m[root@node01 ~]# 

2、kubernetes.io/basic-auth

用于http服务认证 ， 如 nginx httpd

[root@node01 ~]# kubectl get secret/web-basic-authn
NAME              TYPE                       DATA   AGE
web-basic-authn   kubernetes.io/basic-auth   2      16s
[root@node01 ~]# 

3、kubernetes.io/rbd

ceph 使用的认证

4、kubernetes.io/ssh-auth

​ ssh 认证

5、bootstrap.kubernetes.io/token

由kubeadm 命令引入，用于 集群认证时生成的token 信息 。也在ns/kube-system 当中.

[root@node01 ~]# kubectl get secret/bootstrap-token-hn5rn0  -n kube-system
NAME                     TYPE                            DATA   AGE
bootstrap-token-hn5rn0   bootstrap.kubernetes.io/token   6      62s

因为tocken 会过期 ，相应的secret 也会被删除

kubeadm token create --print-join-command 会重新生成

[root@node01 ~]# kubectl get secret/bootstrap-token-hn5rn0  -n kube-system  -oyaml
apiVersion: v1
data:
auth-extra-groups: c3lzdGVtOmJvb3RzdHJhcHBlcnM6a3ViZWFkbTpkZWZhdWx0LW5vZGUtdG9rZW4=
expiration: MjAyMS0xMi0xNlQxMjo0NTo0OSswODowMA==

可以查看它的过期时间 等等

[root@node01 ~]# echo 'MjAyMS0xMi0xNlQxMjo0NTo0OSswODowMA==' |base64 -d
2021-12-16T12:45:49+08:00[root@node01 ~]# 

资源注解

​ 在kube-system 的名称空间下 有大量的secret存在 ，比如某些controller. 保存有专用于ServiceAccount 的相关的token信息的Secret资源会使用资源注解来保存其使用场景。 和label 一样 ，都是附加在metadata 上

[root@node01 ~]# kubectl get secret/node-controller-token-tb4dg    -n kube-system  -o yaml

metadata:
  annotations:
    kubernetes.io/service-account.name: node-controller
    kubernetes.io/service-account.uid: 369f11e7-2791-4d25-907e-d8d5e04fe3cc

资源的元数据：除了name, namespace之外，常用的还有labels, annotations；

1. annotation的名称遵循类似于labels的名称命名格式，但其数据长度不受限制；

2. 它不能用于被标签选择器作为筛选条件；但常用于为那些仍处于Beta阶段的应用程序提供临时的配置接口；

3. 管理命令：
   添加注解： kubectl annotate TYPE/NAME KEY=VALUE

   删除注解 ：kubectl annotate TYPE/NAME KEY-

   还有一种由kubeadm的bootstrap所使用的token专用的类型，它通常保存于kube-system名称空间，以bootstrap-token-为前缀。

    --type=""
   

如何引用secret

和configmap 一样 ，一种同变量，一种通过存储卷

Secret资源，使用环境变量 

containers:
- name: …
  image: …
  env:
  - name: <string>       # 变量名，其值来自于某Secret对象上的指定键的值；
    valueFrom:            # 键值引用； 
      secretKeyRef:       #configmap 用的是configMapKeyRef
        name: <string>    # 引用的Secret对象的名称，需要与该Pod位于同一名称空间；
        key: <string>     # 引用的Secret对象上的键，其值将传递给环境变量；
        optional: <boolean> # 是否为可选引用；
  envFrom:                 # 整体引用指定的Secret对象的全部键名和键值；
  - prefix: <string>     # 将所有键名引用为环境变量时统一添加的前缀；
secretRef:        
  name: <string>     # 引用的Secret对象名称；
  optional: <boolean> # 是否为可选引用；

eg1: 变量方式引用

为mariadb 注入 用户名密码

[root@node01 chapter6]# cat secrets-env-demo.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: secrets-env-demo
  namespace: default
spec:
  containers:
  - name: mariadb
    image: mariadb
    imagePullPolicy: IfNotPresent
    env:
    - name: MYSQL_ROOT_PASSWORD
      valueFrom:
        secretKeyRef:
          name: mysql-root-authn
          key: password

验证结果

[root@node01 chapter6]# kubectl exec -it  secrets-env-demo    -- /bin/sh
# mysql -uroot -pMagedu.c0m

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> Bye
# 

注意， 对于mysql 来讲，启动镜像为日期时，变量只在在初始化容器的过程中调用一次，如果在运行过程这改了是无效的，除非重启mariadb

如果使用环境变量传的配置，只是在容器初始化时有效，所有的配置都一样，不光是密码，半道改了是无法同步到容器内部的，环境变量仅仅在被传值或被调用时赋值一次，无论是configmap 还是secret 不会在运行中修改是不会再次传值的

存储卷的方式是可以避免的

eg2: 存储卷的方式引用

为nginx 注入证书

1. 为容器注入配置文件

   [root@node01 chapter6]# kubectl create configmap nginx-sslvhosts-confs --from-file=./nginx-ssl-conf.d/
   configmap/nginx-sslhosts-confs created
   

2. 为容器注入证书

   [root@node01 chapter6]# cat  secrets-volume-demo.yaml 
   # Maintainer: MageEdu <mage@magedu.com>
   # URL: http://www.magedu.com
   ---
   apiVersion: v1
   kind: Pod
   metadata:
     name: secrets-volume-demo
     namespace: default
   spec:
     containers:
     - image: nginx:alpine
       name: ngxserver
       volumeMounts:
       - name: nginxcerts
         mountPath: /etc/nginx/certs/
         readOnly: true
       - name: nginxconfs
         mountPath: /etc/nginx/conf.d/
         readOnly: true
     volumes:
     - name: nginxcerts
       secret:
         secretName: nginx-ssl-secret
     - name: nginxconfs
       configMap:
         name: nginx-sslvhosts-confs
         optional: false
   

   验证结果

   [root@node01 chapter6]# kubectl exec -it secrets-volume-demo -- /bin/sh
   
   / # curl -H 'www.magedu.com' https://127.0.0.1:443/  -k -I
   HTTP/1.1 200 OK
   Server: nginx/1.21.4
   Date: Wed, 15 Dec 2021 06:42:55 GMT
   Content-Type: text/html
   Content-Length: 615
   Last-Modified: Tue, 02 Nov 2021 15:07:50 GMT
   Connection: keep-alive
   ETag: "61815446-267"
   Accept-Ranges: bytes
   
   / # 
   
   

downwardAPI

​ 为运行在pod中的应用 ，提供了一种反向引用 容器所属pod 自身的属性信息， 比如pod自己名称、pod ip , pod 设置的自身限制等等（pod 内看到的物理资源信息都是节点的，而不是被限制过的）。 为什么叫downwardAPI ? 因为 使用 downwardAPI 会自动向下引用底层的环境，就是查询apiserver

downwardAPI存储卷类型，从严格意义上来说，downwardAPI不是存储卷，它自身就存在，原因在于，它引用的是Pod自身的运行环境信息，这些信息在Pod启动手就存在。

​ downwardAPI 不用事先定义 ，因为他就是pod 自身的属性，但是我们把它理解为一种存储卷类型，是因为他也可以使用存储卷的方式注入的， 这些所引用的信息来自apiserver的查询。

downwardAPI的类型：

1、pod running 之前就存在的信息

​ 类似于ConfigMap或Secret资源，容器能够在环境变量中在valueFrom字段中嵌套fieldRef或resourceFieldRef字段来引用其所属Pod对象的元数据信息。不过，通常只有常量类型的属性才能够通过环境变量注入到容器中，毕竟，在进程启动完成后无法再向其告知变量值的变动，于是，环境变量也就不支持中途的更新操作。容器规范中可在环境变量配置中的valueFrom通过内嵌字段fieldRef引用的信息包括如下这些：

metadata.name：Pod对象的名称； 
metadata.namespace：Pod对象隶属的名称空间； 
metadata.uid：Pod对象的UID； 
metadata.labels['<KEY>']：Pod对象标签中的指定键的值，例如metadata.labels['mylabel']，仅Kubernetes 1.9及之后的版本才支持；
metadata.annotations['<KEY>']：Pod对象注解信息中的指定键的值，仅Kubernetes 1.9及之后的版本才支持。

2、pod 运行之后才存在的信息

如果一个pod处于pending 状态是 是不存在以下信息的

容器上的计算资源需求和资源限制相关的信息，以及临时存储资源需求和资源限制相关的信息可通过容器规范中的resourceFieldRef字段引用，相关字段包括requests.cpu、limits.cpu、requests.memory和limits.memory等。另外，可通过环境变量引用的信息有如下几个：

status.podIP：Pod对象的IP地址
spec.serviceAccountName：Pod对象使用的ServiceAccount资源名称
spec.nodeName：节点名称
status.hostIP：节点IP地址

3、另外，还可以通过resourceFieldRef字段引用当前容器的资源请求及资源限额的定义。

​ 因此它们包括requests.cpu、requests.memory、requests.ephemeral-storage、limits.cpu、limits.memory和limits.ephemeral-storage这6项。

eg1 : 变量方式引用

[root@node01 chapter6]# cat downwardapi-env-demo.yaml 
# Maintainer: MageEdu <mage@magedu.com>
# URL: http://www.magedu.com
---
apiVersion: v1
kind: Pod
metadata:
  name: downwardapi-env-demo
  labels:
    app: demoapp
spec:
  containers:
    - name: demoapp
      image: ikubernetes/demoapp:v1.0
#      command: [ "/bin/sh", "-c", "env" ]
      resources:
        requests:
          memory: "32Mi"
          cpu: "250m"
        limits:
          memory: "64Mi"
          cpu: "500m"
      env:
        - name: THIS_POD_NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.name
        - name: THIS_POD_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
        - name: THIS_APP_LABEL
          valueFrom:
            fieldRef:
              fieldPath: metadata.labels['app']
        - name: THIS_CPU_LIMIT
          valueFrom:
            resourceFieldRef:
              resource: limits.cpu
        - name: THIS_MEM_REQUEST
          valueFrom:
            resourceFieldRef:
              resource: requests.memory
              divisor: 1Mi
#  restartPolicy: Never

验证结果

[root@node01 chapter6]# kubectl exec -it downwardapi-env-demo -- /bin/sh
[root@downwardapi-env-demo /]# env|grep THIS
THIS_CPU_LIMIT=1
THIS_APP_LABEL=demoapp
THIS_MEM_REQUEST=32
THIS_POD_NAME=downwardapi-env-demo
THIS_POD_NAMESPACE=default
[root@downwardapi-env-demo /]# 

eg2： 存储卷方式引用

[root@node01 chapter6]# kubectl explain po.spec.volumes.downwardAPI.items

[root@node01 chapter6]# cat  downwardapi-volume-demo.yaml 
kind: Pod
apiVersion: v1
metadata:
  name: downwardapi-volume-demo
  labels:
    zone: zone1
    rack: rack100
    app: demoapp
  annotations:
    region: ease-cn
spec:
  containers:
    - name: demoapp
      image: ikubernetes/demoapp:v1.0
      resources:
        requests:
          memory: "32Mi"
          cpu: "250m"
        limits:
          memory: "64Mi"
          cpu: "500m"
      volumeMounts:
      - name: podinfo
        mountPath: /etc/podinfo
        readOnly: false
  volumes:
  - name: podinfo
    downwardAPI:
      defaultMode: 420
      items:
      - fieldRef:
          fieldPath: metadata.namespace
        path: pod_namespace
      - fieldRef:
          fieldPath: metadata.labels
        path: pod_labels
      - fieldRef:
          fieldPath: metadata.annotations
        path: pod_annotations
      - resourceFieldRef:
          containerName: demoapp
          resource: limits.cpu
        path: "cpu_limit"
      - resourceFieldRef:
          containerName: demoapp
          resource: requests.memory
          divisor: "1Mi"
        path: "mem_request"
[root@node01 chapter6]# 

path： 指的是在挂载点生成对应的数据项文件， 键 就是文件名称，也就是 path value。 文件内容的信息 就是键值

验证结果

进入挂载点 查看 path 对应的文件

[root@downwardapi-volume-demo /]# cd /etc/podinfo
[root@downwardapi-volume-demo /etc/podinfo]# ls
cpu_limit        mem_request      pod_annotations  pod_labels       pod_namespace
[root@downwardapi-volume-demo /etc/podinfo]# cat cpu_limit 
1[root@downwardapi-volume-demo /etc/podinfo]# 

[root@downwardapi-volume-demo /etc/podinfo]# cat pod_labels 
app="demoapp"
rack="rack100"
zone="zone1"[root@downwardapi-volume-demo /etc/podinfo]#