八、Kubernetes 进阶之配置篇

作者: Suny____ | 来源:发表于2020-05-02 21:54 被阅读0次

学到现在，前面的七章其实已经足够开发使用，但如果想要对K8S有个进阶的认知，从现在开始才是真正的核心，很多第三方的yaml文件中还是有不少资源类型是我们不熟悉的，比如ConfigMap、ServiceAcount、DaemonSet等，以及Pod的生命周期、回收策略、重启策略的配置等。

本章节主要围绕Pod、ConfigMap、Secret进行展开！

1、Pod

对于Pod我们目前只知道它是K8S的一种资源类型，但对它还并不太了解，它还有些东西值得我们去学习。下面就开始学习Pod的生命周期、回收策略、重启策略。

1.1 Lifecycle

Pod的生命周期就是从创建Pod 到 Pod完成或失败的运行阶段的状态描述，是 Pod 在其生命周期中的宏观概述。

官方在对Pod的生命周期分为以下几个大阶段：

挂起（Pending）：Pod 已被 Kubernetes 系统接受，但有一个或者多个容器镜像尚未创建。等待时间包括调度 Pod 的时间和通过网络下载镜像的时间，这可能需要花点时间。
运行中（Running）：该 Pod 已经绑定到了一个节点上，Pod 中所有的容器都已被创建。至少有一个容器正在运行，或者正处于启动或重启状态。
成功（Succeeded）：Pod 中的所有容器都被成功终止，并且不会再重启。
失败（Failed）：Pod 中的所有容器都已终止了，并且至少有一个容器是因为失败终止。也就是说，容器以非0状态退出或者被系统终止。
未知（Unknown）：因为某些原因无法取得 Pod 的状态，通常是因为与 Pod 所在主机通信失败。

image.png

上图STATUS就是Pod的生命周期

实际Pod还会有一些状态，比如Completed、Terminating等，这些到后面再解释

1.2 健康检查

Kubelet 可以选择是否执行在容器上运行的三种监控检查执行和做出反应：

livenessProbe：指示容器是否正在运行。如果存活探测失败，则 kubelet 会杀死容器，并且容器将受到其重启策略的影响。如果容器不提供监控检查，则默认状态为 Success。
- 判断容器是否存活
readinessProbe：指示容器是否准备好服务请求。如果就绪探测失败，端点控制器将从与 Pod 匹配的所有 Service 的端点中删除该 Pod 的 IP 地址。初始延迟之前的就绪状态默认为 Failure。如果容器不提供就绪检查，则默认状态为 Success。
- 判断容器是否启动完成
startupProbe: 指示容器中的应用是否已经启动。如果提供了启动探测(startup probe)，则禁用所有其他探测，直到它成功为止。如果启动探测失败，kubelet 将杀死容器，容器服从其重启策略进行重启。如果容器没有提供启动探测，则默认状态为成功Success。
- 判断容器是否启动

image.png

上图是 nginx-ingress的YAML文件内容，这里就使用了健康检查

1.3 重启策略

PodSpec 中有一个 restartPolicy 字段，可能的值为 Always、OnFailure 和 Never。默认为 Always。

restartPolicy 适用于 Pod 中的所有容器。restartPolicy 仅指通过同一节点上的 kubelet 重新启动容器。失败的容器由 kubelet 以五分钟为上限的指数延迟（10秒，20秒，40秒…）重新启动，并在成功执行十分钟后重置。如 Pod 文档中所述，一旦绑定到一个节点，Pod 将永远不会重新绑定到另一个节点。

Always：容器失效时，自动重启
OnFailure：容器终止运行且退出码不为0时重启
Never：永远不重启

image.png

配置方式如上所示

1.4 静态Pod

静态Pod是由kubelet直接进行管理的，并且存在于特定的Node上。不能通过API Server进行管理，无法与Replication Controller、Deployment或者Daemon Set进行关联，也无法进行健康检查。

image.png

像kube-system命名空间下的Pod，就是由kubelet直接管理的，它们所使用的IP都是宿主机所在IP，而不是calico插件分配的。

2、ConfigMap

ConfigMap 允许将配置文件与镜像文件分离，以使容器化的应用程序具有可移植性。

简单来说就是用来保存配置数据的键值对，也可以保存单个属性，也可以保存配置文件。

所有的配置内容都存储在etcd中，创建的数据可以供Pod使用。

2.1 创建方式

2.1.1 命令行创建

创建ConfigMap

[root@master-kubeadm-k8s k8s-springboot-demo]# kubectl create configmap my-config --from-literal=db.port='3306'
configmap/my-config created

查看ConfigMap

# 查看创建的ConfigMap
[root@master-kubeadm-k8s k8s-springboot-demo]# kubectl get cm
NAME        DATA   AGE
my-config   1      5s

# 以YAML方式查看ConfigMap详情信息
[root@master-kubeadm-k8s k8s-springboot-demo]# kubectl get configmap my-config -o yaml
apiVersion: v1
kind: ConfigMap
metadata:
  creationTimestamp: "2020-05-02T06:12:45Z"
  name: my-config
  namespace: default
  resourceVersion: "318695"
  selfLink: /api/v1/namespaces/default/configmaps/my-config
  uid: f0849fda-8c3b-11ea-9dfb-5254008afee6
data:
  db.port: "3306"

2.1.2 从配置文件中创建

创建配置文件

[root@master-kubeadm-k8s k8s-springboot-demo]# vi cm.properties
name=sunny
age=25

创建ConfigMap

[root@master-kubeadm-k8s k8s-springboot-demo]# kubectl create configmap app --from-file=./cm.properties
configmap/app created

查看ConfigMap

[root@master-kubeadm-k8s k8s-springboot-demo]# kubectl get configmap app -o yaml
apiVersion: v1
kind: ConfigMap
metadata:
  creationTimestamp: "2020-05-02T06:17:23Z"
  name: app
  namespace: default
  resourceVersion: "319070"
  selfLink: /api/v1/namespaces/default/configmaps/app
  uid: 968946cf-8c3c-11ea-9dfb-5254008afee6
data:
  cm.properties: |
    name=sunny
    age=25

2.1.3 通过YAML文件创建

创建YAML文件

configmaps.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config
  namespace: default
data:
  name: snny
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: env-config
  namespace: default
data:
  log_level: INFO

创建ConfigMap

[root@master-kubeadm-k8s k8s-springboot-demo]# kubectl apply -f configmaps.yaml
configmap/special-config created
configmap/env-config created

查看ConfigMap

[root@master-kubeadm-k8s k8s-springboot-demo]# kubectl get cm
NAME             DATA   AGE
app              1      3m56s
env-config       1      45s
my-config        1      9m32s
special-config   1      45s

2.2 ConfigMap的使用

2.2.1 通过环境变量的方式，直接传递给pod

创建YAML文件
- pod_nginx.yaml

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80
    env:
      - name: ENV_LEVEL_KEY
        valueFrom:              # 值来源
          configMapKeyRef:      # 表示使用ConfigMap
            name: env-config    # ConfigMap名称
            key: log_level      # ConfigMap中的具体的key名称

创建资源

[root@master-kubeadm-k8s ~]# kubectl apply -f pod_nginx.yaml

进入容器查看环境变量

[root@master-kubeadm-k8s ~]# kubectl get pods
NAME                     READY   STATUS    RESTARTS   AGE
nginx-77945f44db-sllmh   1/1     Running   2          39h
nginx-pod                1/1     Running   0          21m

# 进入容器
[root@master-kubeadm-k8s ~]# kubectl exec -it nginx-pod bash

# 输出环境变量
root@nginx-pod:/# echo $ENV_LEVEL_KEY
INFO

2.2.2 通过在pod的命令行下运行的方式(启动命令中)

创建YAML文件

command-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: command-configmap
spec:
  containers:
    - name: test-container
      image: busybox
      command: [ "/bin/sh", "-c", "echo $(SPECIAL_LEVEL_KEY)" ] # 引用环境变量中的ConfigMap值
      env:
        - name: SPECIAL_LEVEL_KEY
          valueFrom:
            configMapKeyRef:
              name: special-config
              key: name
  restartPolicy: Never

创建资源

[root@master-kubeadm-k8s ~]# kubectl apply -f command-pod.yaml
pod/command-configmap created

查看容器日志

这里看到了 Pod 的另一种生命周期状态：Completed

这表示Pod的任务已经完成了，因为我们的Pod功能就只是输出一段命令

[root@master-kubeadm-k8s ~]# kubectl get pods
NAME                     READY   STATUS      RESTARTS   AGE
command-configmap        0/1     Completed   0          46s
nginx-77945f44db-sllmh   1/1     Running     2          39h
nginx-pod                1/1     Running     0          32m

# 查看日志,正常输出ConfigMap定义的值了
[root@master-kubeadm-k8s ~]# kubectl logs command-configmap
sunny

2.2.3 作为volume的方式挂载到pod内

作为volume挂载使用

将创建的ConfigMap直接挂载至Pod的某个目录下，其中每一个key-value键值对都会生成一个文件，key为文件名，value为内容

创建YAML文件

pod-configmap-volume.yaml

apiVersion: v1
kind: Pod
metadata:
  name: pod-configmap-volume
spec:
  containers:
    - name: test-container
      image: busybox
      command: [ "/bin/sh", "-c", "ls /etc/config/" ]   # 执行 ls /etc/config/ 命令
      volumeMounts:
      - name: config-volume
        mountPath: /etc/config
  volumes:
    - name: config-volume
      configMap:                    # 挂载方式采用ConfigMap
        name: special-config        # ConfigMap名称
  restartPolicy: Never

创建资源

[root@master-kubeadm-k8s ~]# kubectl apply -f pod-configmap-volume.yaml

查看容器日志

# name 是我们之前在ConfigMap中定义的 Key 名称,这里已经作为文件存在了
[root@master-kubeadm-k8s ~]# kubectl logs pod-configmap-volume
name

2.2.4 ConfigMap在Ingress Controller中的应用

查看nginx-ingress配置文件

apiVersion: v1
kind: Namespace
metadata:
  name: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
---
# nginx-ingress在初期就定义好了几个ConfigMap,但是没有设置数据
kind: ConfigMap
apiVersion: v1
metadata:
  name: nginx-configuration
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
---
kind: ConfigMap
apiVersion: v1
metadata:
  name: tcp-services
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
---
kind: ConfigMap
apiVersion: v1
metadata:
  name: udp-services
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx

# ... 省略 ...

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-ingress-controller
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: ingress-nginx
      app.kubernetes.io/part-of: ingress-nginx
  template:
    metadata:
      labels:
        app.kubernetes.io/name: ingress-nginx
        app.kubernetes.io/part-of: ingress-nginx
      annotations:
        prometheus.io/port: "10254"
        prometheus.io/scrape: "true"
    spec:
      # wait up to five minutes for the drain of connections
      terminationGracePeriodSeconds: 300
      serviceAccountName: nginx-ingress-serviceaccount
      hostNetwork: true
      nodeSelector:
        name: ingress
        kubernetes.io/os: linux
      containers:
        - name: nginx-ingress-controller
          image: quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.30.0
          args:
            - /nginx-ingress-controller
            
            # 这里将上面定义的ConfigMap传递到了容器中,这可以很方便的调整Nginx的参数
            - --configmap=$(POD_NAMESPACE)/nginx-configuration
            - --tcp-services-configmap=$(POD_NAMESPACE)/tcp-services
            - --udp-services-configmap=$(POD_NAMESPACE)/udp-services
            - --publish-service=$(POD_NAMESPACE)/ingress-nginx
            - --annotations-prefix=nginx.ingress.kubernetes.io
            
# ... 省略 ...

可以看到上面的mandatory.yaml文件中使用了ConfigMap，发现有nginx-configuration、tcp-services等名称的ConfigMap，而且也发现最后在容器的参数中使用了这些ConfigMap。

但它为什么ConfigMap中没有设置数据呢？这不就是一个空的ConfigMap资源吗？

其实他提供的ConfigMap是为了用户考虑的，我们如果想要修改nginx.conf的参数，就可以通过ConfigMap的方式去修改！

证明Ingress Controller中ConfigMap的使用

查看Ingress Controller所在节点

[root@master-kubeadm-k8s ~]# kubectl get pods -n ingress-nginx -o wide
NAME                                        READY   STATUS    RESTARTS   AGE   IP               NODE                   NOMINATED NODE   READINESS GATES
nginx-ingress-controller-5588956455-j6589   1/1     Running   0          13d   192.168.50.112   worker01-kubeadm-k8s   <none>           <none>

进入容器

[root@master-kubeadm-k8s ~]# kubectl exec -it nginx-ingress-controller-5588956455-j6589 bash

# 可以看到它其实就是一个nginx容器,这里会有nginx.conf文件
root@nginx-ingress-controller:/etc/nginx# ls
conf.d  fastcgi_params  koi-utf  koi-win  mime.types  modules  nginx.conf  scgi_params  uwsgi_params  win-utf

我们配置的ingress访问规则其实就是动态的在nginx.cong文件中增加一个location，nginx帮我们实现了转发，所以我们才可以通过域名访问到Service

查看nginx.conf，选择一个要修改的配置

  # Custom headers to proxied server

proxy_connect_timeout                   5s;
proxy_send_timeout                      60s;

# 比如我们选择修改 proxy_read_timeout
proxy_read_timeout                      60s;

proxy_buffering                         off;
proxy_buffer_size                       4k;
proxy_buffers                           4 4k;
proxy_max_temp_file_size                1024m;

编写一个ConfigMap动态修改nginx配置
- ingress-configmap.yaml
ingress-nginx那里定义的ConfigMap实际只是为用户开放一个门，先把ConfigMap定义好，我们如果要想动态修改配置，可以自己写一个ConfigMap资源文件，只要资源的名称一致，ingress-nginx-controller就可以动态的加载配置！

nginx-configuration
```
kind: ConfigMap
apiVersion: v1
metadata:
  name: nginx-configuration # 与ingress-nginx配置的ConfigMap名称一致
  namespace: ingress-nginx
  labels:
    app: ingress-nginx
data:
  proxy-read-timeout: "210" # 修改nginx.conf文件中的配置
```

创建资源

[root@master-kubeadm-k8s configmap]# kubectl apply -f ingress-configmap.yaml
configmap/nginx-configuration configured

再次查看ingress-nginx容器中的nginx.conf文件

image.png

ConfigMap定义规则都在nginx ingress controller的官网中

https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/

image.png

2.2.5 注意事项

ConfigMap必须在Pod使用它之前创建
使用envFrom时，将会自动忽略无效的键
Pod只能使用同一个命名空间的ConfigMap

3、Secret

Secret 对象类型是用来保存敏感信息的，例如密码、OAuth 令牌和 ssh key。

将这些信息放在 secret 中比直接放在 Pod 的定义或者容器镜像中来说会更加安全和灵活。

3.1 Secret 概览

这样的信息可能会被放在 Pod spec 中或者镜像中；将其放在一个 secret 对象中可以更好地控制它的用途，并降低意外暴露的风险。

用户可以创建 secret，同时系统也创建了一些 secret。

要使用 secret，pod 需要引用 secret。Pod 可以用两种方式使用 secret：作为 volume 中的文件被挂载到 pod 中的一个或者多个容器里，或者当 kubelet 为 pod 拉取镜像时使用。

内置secret

Kubernetes 会自动创建包含访问 API 凭据的 secret，并自动修改 pod 以使用此类型的 secret。

如果需要，可以禁用或覆盖自动创建和使用 API 凭据。

3.2 secret类型

Opaque：使用base64编码存储信息，可以通过base64 --decode解码获得原始数据，因此安全性弱。
kubernetes.io/dockerconfigjson：用于存储docker registry的认证信息。
kubernetes.io/service-account-token：用于被 serviceAccount 引用。serviceAccout 创建时 Kubernetes 会默认创建对应的 secret。

3.3 创建secret

Opaque Secret

Opaque类型的Secret的value为base64位编码后的值

从文件中创建

# 对密码进行base64编码
[root@master-kubeadm-k8s docker]# echo 'admin' | base64
YWRtaW4K

# 写用户名
[root@master-kubeadm-k8s secret]# echo -n "admin" > ./username.txt
# 写密码
[root@master-kubeadm-k8s secret]# echo -n "YWRtaW4K" > ./password.txt
[root@master-kubeadm-k8s secret]# ll
total 8
-rw-r--r--. 1 root root 8 May  2 10:52 password.txt
-rw-r--r--. 1 root root 5 May  2 10:51 username.txt

# 创建secret
[root@master-kubeadm-k8s secret]# kubectl create secret generic db-user-pass --from-file=./username.txt --from-file=./password.txt
secret/db-user-pass created

# 查看secret, 也可以看到默认会有一个kubernetes.io/service-account-token类型的secret
[root@master-kubeadm-k8s secret]# kubectl get secret
NAME                  TYPE                                  DATA   AGE
db-user-pass          Opaque                                2      29s
default-token-xggf5   kubernetes.io/service-account-token   3      38d

使用yaml文件创建

先拿到base64编码后的账号密码

[root@master-kubeadm-k8s docker]# echo 'admin' | base64
YWRtaW4K
[root@master-kubeadm-k8s secret]# echo 'admin123' | base64
YWRtaW4xMjMK

mysecret.yaml

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  username: YWRtaW4K
  password: YWRtaW4xMjMK

创建secret

[root@master-kubeadm-k8s secret]# kubectl apply -f mysecret.yaml
secret/mysecret created

# 查看secret
[root@master-kubeadm-k8s secret]# kubectl get secret
NAME                  TYPE                                  DATA   AGE
db-user-pass          Opaque                                2      5m37s
default-token-xggf5   kubernetes.io/service-account-token   3      38d
mysecret              Opaque                                2      11s

Secret使用

以Volume方式

将Secret挂载到Volume中

mypod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: volume-secret
spec:
  containers:
  - name: mypod
    image: nginx
    volumeMounts:
    - name: foo
      mountPath: "/etc/foo"
      readOnly: true
  volumes:
  - name: foo
    secret:
      secretName: mysecret

创建资源

[root@master-kubeadm-k8s opaque]# kubectl apply -f volume-secret.yaml
pod/volume-secret created

查看挂载文件

# 进入容器
[root@master-kubeadm-k8s opaque]# kubectl exec -it volume-secret bash
root@volume-secret:/# cd /etc/foo/

root@volume-secret:/etc/foo# ls
password  username

# 查看内容,这与ConfigMap一样,挂载进来都是以文件的方式存在
root@volume-secret:/etc/foo# cat username
admin
root@volume-secret:/etc/foo# cat password
admin12

以环境变量方式

env-secret.yaml

apiVersion: v1
kind: Pod
metadata:
  name: env-secret
spec:
  containers:
  - name: mycontainer
    image: nginx
    env:
      - name: SECRET_USERNAME
        valueFrom:
          secretKeyRef:
            name: mysecret
            key: username
      - name: SECRET_PASSWORD
        valueFrom:
          secretKeyRef:
            name: mysecret
            key: password
  restartPolicy: Never

创建资源

[root@master-kubeadm-k8s opaque]# kubectl apply -f env-secret.yaml
pod/env-secret created

查看环境变量

[root@master-kubeadm-k8s opaque]# kubectl exec -it env-secret bash

# 查看环境变量
root@env-secret:/# echo $SECRET_USERNAME
admin
root@env-secret:/# echo $SECRET_PASSWORD
admin123

kubernetes.io/dockerconfigjson

kubernetes.io/dockerconfigjson用于存储docker registry的认证信息，可以直接使用kubectl create secret命令创建

一般是在拉取私有镜像仓库中的image时使用，在前面的实战章节中我们也演示过

创建secret

 # 创建保存授权令牌的 Secret
[root@master-kubeadm-k8s k8s-springboot-demo]# kubectl create secret docker-registry registry-aliyun --docker-server=registry.cn-hangzhou.aliyuncs.com --docker-username=[用户名] --docker-password=[密码] --docker-email=[邮箱]
secret/registry-aliyun created
      
# 检查 Secret
[root@master-kubeadm-k8s k8s-springboot-demo]# kubectl get secret registry-aliyun --output=yaml
apiVersion: v1
kind: Secret
metadata:
  creationTimestamp: "2020-05-02T19:18:24Z"
  name: registry-aliyun
  namespace: default
  resourceVersion: "109789"
  selfLink: /api/v1/namespaces/default/secrets/registry-aliyun
  uid: 368a54cd-22ggb-11ea-28ty-5254008afee6
type: kubernetes.io/dockerconfigjson
data:
  .dockerconfigjson: eyJhdXRocyI6eyJyZWdpc3RyeS5jbi1oYW5nemhvdS5hbGl5dW5jcy5jb20iOnsidXNlcm5hbWUiOiJ5enlfemhhb3lhbmdAMTYzLmNvbSIsInBdkjhasjdhksabdkajaksddasdaWwiOiJ5enlfemhhb3lhbmdAMTYzLmNvbSIsImF1dGgiOiJlWHAkcjnhkcnhamoewr3242309jdsjaldj092qeGIxbEJUa2MxTmpJMU5ERTQifX19

# 可以使用base64解码查看secret
[root@master-kubeadm-k8s opaque]# kubectl get secret registry-aliyun --output="jsonpath={.data.\.dockerconfigjson}" | base64 --decode

# secret内容
{"auths":{"registry.cn-hangzhou.aliyuncs.com":{"username":"用户名","password":"密码","email":"邮箱","auth":"eXpgh5YW95YW5nQDE2das45hhb1lrege231NjI1NDE4"}}}

使用 dockerconfigjson secret

如果镜像仓库是私有的，必须是要有secret才能拉取到

apiVersion: apps/v1
kind: Deployment
metadata: 
  name: springboot-demo
spec: 
  selector: 
    matchLabels: 
      app: springboot-demo
  replicas: 1
  template: 
    metadata:
      labels: 
        app: springboot-demo
    spec: 
      containers: 
      - name: springboot-demo
        # 这里的镜像是私有的镜像仓库地址
        image: registry.cn-hangzhou.aliyuncs.com/sunny95/springboot-demo-image:v1.0
        ports: 
        - containerPort: 8080
        #=========增加 Secret===========
      imagePullSecrets:
      - name: registry-aliyun   # 注意名称要与创建时指定的名称一致
        #=========增加 Secret===========

kubernetes.io/service-account-token

前提说明
- Service Account是为了方便Pod里面的进程调用Kubernetes API或其他外部服务而设计的
- 每个namespace都会自动创建一个default service account
- Token controller会检测service account的创建，并为它们创建secret
- 开启ServiceAccount Admission Controller
  - 每个Pod在创建后都会自动设置spec.serviceAccount为default（除非指定了其他ServiceAccout）
  - 验证Pod引用的service account已经存在，不存在会拒绝创建
  - 如果Pod没有指定ImagePullSecrets，则把service account的ImagePullSecrets加到Pod中
  - 每个container启动后都会挂载该service account的token和ca.crt到/var/run/secrets/kubernetes.io/serviceaccount/

系统默认的serviceAcount

准备yaml文件

apiVersion: v1
kind: Pod
metadata:
  name: service-acount-pod
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
     - containerPort: 80

创建Pod

[root@master-kubeadm-k8s opaque]# kubectl apply -f service-acount-pod.yaml
pod/service-acount-pod created

查看Pod详情

[root@master-kubeadm-k8s opaque]# kubectl get  pod service-acount-pod -o yaml

apiVersion: v1
kind: Pod
# ... 省略 ...

    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    # 默认会自动挂载
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: default-token-xggf5
      readOnly: true

# ... 省略 ...

查看挂载目录

# 进入容器
[root@master-kubeadm-k8s opaque]# kubectl exec -it service-acount-pod bash

# 进入挂载目录
root@service-acount-pod:/# cd /var/run/secrets/kubernetes.io/serviceaccount

# 查看目录结构
root@service-acount-pod:/var/run/secrets/kubernetes.io/serviceaccount# ls
ca.crt  namespace  token

创建自定义的serviceAcount

yaml文件方式创建serviceAcount

apiVersion: v1
kind: ServiceAccount
metadata:
  name: nginx-ingress-serviceaccount
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx

命令行方式创建serviceAcount

# 创建secret
[root@master-kubeadm-k8s ~]# kubectl create  serviceaccount sunny
serviceaccount/sunny created

# 查看serviceAcount
[root@master-kubeadm-k8s ~]# kubectl get sa
NAME      SECRETS   AGE
default   1         38d
sunny     1         21s

# 查看serviceAcount详情,默认还会帮助创建一个名为 sunny-token-cjvhs 的secret
# 用于当前serviceaccount连接至当前API Server时使用的认证信息
[root@master-kubeadm-k8s ~]# kubectl describe sa sunny
Name:                sunny
Namespace:           default
Labels:              <none>
Annotations:         <none>
Image pull secrets:  <none>
Mountable secrets:   sunny-token-cjvhs
Tokens:              sunny-token-cjvhs
Events:              <none>

# 查看secret
[root@master-kubeadm-k8s ~]# kubectl get secret
NAME                  TYPE                                  DATA   AGE
db-user-pass          Opaque                                2      58m
default-token-xggf5   kubernetes.io/service-account-token   3      38d
registry-aliyun       kubernetes.io/dockerconfigjson        1      50m
sunny-token-cjvhs     kubernetes.io/service-account-token   3      110s

具体的应用我们后面的章节会讲到，这里还没学到~~~

八、Kubernetes 进阶之配置篇

1、Pod

1.1 Lifecycle

1.2 健康检查

1.3 重启策略

1.4 静态Pod

2、ConfigMap

2.1 创建方式

2.1.1 命令行创建

2.1.2 从配置文件中创建

2.1.3 通过YAML文件创建

2.2 ConfigMap的使用

2.2.1 通过环境变量的方式，直接传递给pod

2.2.2 通过在pod的命令行下运行的方式(启动命令中)

2.2.3 作为volume的方式挂载到pod内

2.2.4 ConfigMap在Ingress Controller中的应用

2.2.5 注意事项

3、Secret

3.1 Secret 概览

内置secret

3.2 secret类型

3.3 创建secret

相关文章

网友评论

延伸阅读

深度阅读

栏目导航

热点阅读

Kubernetes