九、Kubernetes 进阶之控制器篇

2020-05-03 本文已影响0人 Suny____

上一章对Pod的一些配置进行了更深刻的了解，那对于管理Pod的Controller肯定也要进阶一下，

之前我们已经学习过的 Controller 有RC、RS和Deployment，除此之外官方还提供符合其他场景使用的控制器，如：DaemonSet、statefulSet、Job、cron-job这些。

1、DaemonSet

DaemonSet 确保全部（或者某些）节点上运行一个 Pod 的副本。当有节点加入集群时，也会为他们新增一个 Pod 。当有节点从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。

DaemonSet应用场景

运行集群存储 daemon，例如在每个节点上运行 glusterd、ceph。
在每个节点上运行日志收集 daemon，例如fluentd、logstash。
在每个节点上运行监控 daemon，例如 Prometheus Node Exporter、collectd、Datadog 代理、New Relic 代理，或 Ganglia gmond。

上面的说明应该很容易理解，简单来说就是，使用DaemonSet控制器创建资源，它会让每个Node节点都运行一份Pod，比如日志收集，因为Pod在不同节点运行，那每个节点肯定都要有一个Pod去收集这些日志，那就可以使用DaemonSet。

像K8S kube-system命名空间下的calico-node、kube-proxy组件，这些都是要在每个节点都要保证有一份Pod存在的，它们的资源类型肯定也是DaemonSet的！

image.png

2、StatefulSet

StatefulSet 是用来管理有状态应用的工作负载 API 对象。
StatefulSet 用来管理 Deployment 和扩展一组 Pod，并且能为这些 Pod 提供 序号和唯一性保证。
和 Deployment 相同的是，StatefulSet 管理了基于相同容器定义的一组 Pod。但和 Deployment 不同的是，StatefulSet 为它们的每个 Pod 维护了一个固定的 ID。这些 Pod 是基于相同的声明来创建的，但是不能相互替换：无论怎么调度，每个 Pod 都有一个永久不变的 ID。
StatefulSet 和其他控制器使用相同的工作模式。你在 StatefulSet 对象中定义你期望的状态，然后 StatefulSet 的 控制器 就会通过各种更新来达到那种你想要的状态。

2.1 StatefulSets 与其他控制器的区别：

之前接触的Pod的管理对象比如RC、Deployment、DaemonSet等都是面向无状态的服务，但是现实中有很多服务是有状态的，比如MySQL集群、MongoDB集群、ZK集群等，它们都有以下共同的特点：

每个节点都有固定的ID，通过该ID，集群中的成员可以互相发现并且通信
集群的规模是比较固定的，集群规模不能随意变动
集群里的每个节点都是有状态的，通常会持久化数据到永久存储中
如果磁盘损坏，则集群里的某个节点无法正常运行，集群功能受损

而之前的RC/Deployment没办法满足要求，所以从Kubernetes v1.4版本就引入了PetSet资源对象，在v1.5版本时更名为StatefulSet。从本质上说，StatefulSet可以看作是Deployment/RC对象的特殊变种

StatefulSet里的每个Pod都有稳定、唯一的网络标识，可以用来发现集群内其他的成员
Pod的启动顺序是受控的，操作第n个Pod时，前n-1个Pod已经是运行且准备好的状态
StatefulSet里的Pod采用稳定的持久化存储卷，通过PV/PVC来实现，删除Pod时默认不会删除与StatefulSet相关的存储卷
StatefulSet需要与Headless Service配合使用

2.2 使用StatefulSet

准备YAML文件

nginx-statefulset.yaml

# 定义Service
apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
# 定义StatefulSet
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  selector:
    matchLabels:
      app: nginx 
  serviceName: "nginx"  
  replicas: 3 
  template:
    metadata:
      labels:
        app: nginx 
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80
          name: web

创建资源

[root@master-kubeadm-k8s statefulset]# kubectl apply -f nginx-statefulset.yaml
service/nginx created
statefulset.apps/web created

查看资源

通过 kubectl get pods -w 监控Pod创建过程，观察Pod名称及创建顺序

image.png

通过观察Pod的创建过程可以发现，StatefulSet类型的资源名称是有序号的了，而且肯定是有序创建的，第一个Pod没创建完成不会创建第二个！

3、Job

Job会创建一个或多个Pod，并确保指定数量的Pod成功终止。job会跟踪 Pod 成功完成的情况。当达到指定的成功完成次数时，任务（即Job）就完成了。删除 Job 将清除其创建的Pod。
对于RS，RC之类的控制器，能够保持Pod按照预期数目持久地运行下去，它们针对的是持久性的任务，比如web服务。
而有些操作其实不需要持久，比如压缩文件，我们希望任务完成之后，Pod就结束运行，不需要保持在系统中，此时就需要用到Job。
所以可以这样理解，Job是对RS、RC等持久性控制器的补充，负责批量处理短暂的一次性任务，仅执行一次，并保证处理的一个或者多个Pod成功结束。

3.1 使用Job

准备YAML文件
- job.yaml
这个 Job 会打印 1 ~ 9 的数字到控制台，当打印完成后这个 Pod 的任务就完成
```
apiVersion: batch/v1
kind: Job
metadata:
  name: job-demo
spec:
  template:
    metadata:
      name: job-demo
    spec:
      restartPolicy: Never
      containers:
      - name: counter
        image: busybox
        command:
        - "bin/sh"
        - "-c"
        - "for i in 9 8 7 6 5 4 3 2 1; do echo $i; done"
```
注意Job的RestartPolicy 只支持Never和OnFailure两种，不支持Always，因为 Job 就相当于来执行一个批处理任务，执行完就结束了，如果支持Always的话就陷入死循环了!

查看日志

# 创建 Job
[root@master-kubeadm-k8s job]# kubectl apply -f job.yaml
job.batch/job-demo created

# 查看Job, 它的状态已经是 Completed 了,表示已经完成了
[root@master-kubeadm-k8s job]# kubectl get pods
NAME                   READY   STATUS      RESTARTS   AGE
job-demo-n7wxf         0/1     Completed   0          64s

# 也可以单独查看 Job 资源
[root@master-kubeadm-k8s job]# kubectl get job
NAME       COMPLETIONS   DURATION   AGE
job-demo   1/1           57s        17m

[root@master-kubeadm-k8s job]# kubectl get job -o wide
NAME       COMPLETIONS   DURATION   AGE   CONTAINERS   IMAGES    SELECTOR
job-demo   1/1           57s        17m   counter      busybox   controller-uid=866bed1d-8cff-11ea-827a-5254008afee6

# 查看日志,输出了 1 ~ 9 的数字
[root@master-kubeadm-k8s job]# kubectl logs job-demo-n7wxf
9
8
7
6
5
4
3
2
1

3.2 Job类型

非并行Job:
- 通常只运行一个Pod，Pod成功结束Job就退出。
固定完成次数的并行Job:
- 并发运行指定数量的Pod，直到指定数量的Pod成功，Job结束。
带有工作队列的并行Job:
- Pod必须在彼此之间或外部服务之间进行协调，以确定每个Pod应该如何处理。例如，一个Pod可以从工作队列中获取最多N批的批处理。
- 每个Pod都可以独立地确定其所有对等方是否都已完成，从而确定了整个Job。
- 用户可以指定并行的Pod数量，当任何Pod成功结束后，不会再创建新的Pod
- 一旦至少有一个Pod成功结束，并且所有的Pods都结束了，该Job就成功结束。
- 一旦有一个Pod成功结束，其他Pods都会准备退出。

4、Cron Job

Cron Job 创建基于时间调度的 Jobs。它是基于时间进行任务的定时管理。
一个 CronJob 对象就像 crontab (cron table) 文件中的一行。
它用 Cron 格式进行编写，周期性、或在给定的调度时间执行 Job。
反复在指定的时间点运行任务：比如定时进行数据库备份，定时发送电子邮件等等。

4.1 使用Cron Job

准备YAML文件

cronjob.yaml

这个 cron job 是会一分钟创建一个 Job去运行，每个 Job的任务是：

输出当前时间

打印 Hello Cron Job!!!

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox
            args:
            - /bin/sh
            - -c
            - date; echo Hello Cron Job!!!
          restartPolicy: OnFailure

创建资源

[root@master-kubeadm-k8s job]# kubectl apply -f cronjob.yaml
cronjob.batch/hello created

查看资源

# 查看cronjob资源, CronJob 还没有调度或执行任何任务。大约需要一分钟任务才能创建好。
[root@master-kubeadm-k8s job]# kubectl get cronjob
NAME    SCHEDULE      SUSPEND   ACTIVE   LAST SCHEDULE   AGE
hello   */1 * * * *   False     0        <none>          11s

# 通过监控Job状态来观察
[root@master-kubeadm-k8s job]# kubectl get jobs --watch
NAME               DESIRED   SUCCESSFUL   AGE
hello-4111706356   1         1              20s

# 看到了一个运行中的任务被 “hello” CronJob 调度。
# 可以停止监视这个任务，然后再次查看 CronJob 就能看到它调度任务：
# 能看到 “hello” CronJob 在 LAST-SCHEDULE 声明的时间点成功的调度了一次任务。
# ACTIVE 为 1 表示 Job 已经开始运行
[root@master-kubeadm-k8s job]# kubectl get cronjob
NAME    SCHEDULE      SUSPEND   ACTIVE   LAST SCHEDULE   AGE
hello   */1 * * * *   False     1        21s             2m

# 可以选择继续观察Job状态,它会周期性的去执行这个任务
[root@master-kubeadm-k8s job]# kubectl get jobs --watch
NAME               COMPLETIONS   DURATION   AGE
hello-1588485600   1/1           57s        3m45s
hello-1588485660   1/1           44s        2m45s
hello-1588485720   1/1           58s        105s
hello-1588485780   0/1           45s        45s

删除CronJob

删除 CronJob 会清除它创建的所有任务和 Pod，并阻止它创建额外的任务。
```
[root@master-kubeadm-k8s job]# kubectl delete cronjob hello
cronjob.batch "hello" deleted
```

5、Horizontal Pod Autoscaler

HPA（Horizontal Pod Autoscaler）特性，是可以基于CPU利用率自动伸缩 replication controller、deployment和 replica set 中的 pod 数量，（除了 CPU 利用率）也可以基于其他应程序提供的度量指标custom metrics。
pod 自动扩缩容不适用于无法扩缩容的对象，比如 DaemonSets。
Pod 水平自动伸缩特性由 Kubernetes API 资源和控制器实现。资源决定了控制器的行为。
控制器会周期性的获取平均 CPU 利用率，并与目标值相比较后来调整 replication controller 或 deployment 中的副本数量。

5.1 Horizontal Pod Autoscaler的使用

提前准备一个YAML

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

创建资源

[root@master-kubeadm-k8s hpa]# kubectl apply -f test-hpa.yaml
deployment.apps/nginx-deployment created

查看资源

# 3个副本数
[root@master-kubeadm-k8s hpa]# kubectl get deploy
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3/3     3            3           2m43s

手动扩容

[root@master-kubeadm-k8s hpa]# kubectl edit -f test-hpa.yaml
deployment.apps/nginx-deployment edited

image.png

修改副本数为 10

查看资源

# 这块就会动态的增加副本数为10
[root@master-kubeadm-k8s hpa]# kubectl get deploy
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   10/10    10           3           3m54s

使用HPA

创建HPA后，HPA会根据资源的使用情况，动态的调整Pod数量，但范围是由用户控制的

# 创建HPA, 使nginx pod的数量介于2和10之间，CPU使用率维持在50％
[root@master-kubeadm-k8s hpa]# kubectl autoscale deployment nginx-deployment --min=2 --max=10 --cpu-percent=50
horizontalpodautoscaler.autoscaling/nginx-deployment autoscaled

如果想要测试的话，可以用JMetter之类的工具去并发访问，我这里没有准备项目，就通过手动调整的方式来判断HPA是否生效

查看HPA

[root@master-kubeadm-k8s hpa]# kubectl get hpa
NAME               REFERENCE                     TARGETS         MINPODS   MAXPODS   REPLICAS   AGE
nginx-deployment   Deployment/nginx-deployment   <unknown>/50%   2         10        10         29s

调整副本数为15
image.png

查看资源

# 调整完成后发现还是10个, 因为HPA限制了它最大可以运行的副本数为 10
[root@master-kubeadm-k8s hpa]# kubectl get deploy
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   10/10   10           10          5m

5.2 HPA工作机制

HPA实际就是管理RC或Deployment，通过他们来进行动态的扩缩容。它可以根据CPU使用率或应用自定义metrics自动扩展Pod数量（支持replication controller、deployment和replica set）

控制管理器每隔15s查询metrics的资源使用情况
通过kubectl创建一个horizontalPodAutoscaler对象，并存储到etcd中
APIServer: 负责接受创建hpa对象，然后存入etcd

image.png

6、Resource

因为K8S的最小操作单元是Pod，所以这里主要讨论的是Pod的资源。
当使用Pod，可以指定每个容器需要多少资源，以及限制容器可以使用的资源。
最常见资源是CPU和内存（RAM）。

6.1 reques 与 limit

如果运行Pod的节点有足够的可用资源，则容器有可能（允许）使用比该request资源指定的资源更多的资源。但是，容器不能使用超出其资源的范围limit。
- 例如，如果为一个容器设置了256 MiB 的memory的请求，并且该容器位于已分配到具有8GiB内存且没有其他Pod的节点的Pod中，则该容器可以尝试使用更多的RAM。
如果为该容器设置了4GiB的memory限制，则kubelet（以及容器运行时）会强制执行该限制。运行时可防止容器使用超出配置的资源限制的容器。
- 例如：当容器中的进程尝试消耗的内存量超过允许的数量时，系统内核将终止尝试分配的进程，并出现内存不足（OOM）错误。
可以以反应方式实施限制（一旦发现违规，系统就会进行干预），也可以强制实施（系统防止容器超过限制）。不同的运行时可以采用不同的方式来实现相同的限制。

6.2 资源的配置项

Pod的每个容器可以指定以下一项或多项：

spec.containers[].resources.limits.cpu
spec.containers[].resources.limits.memory
spec.containers[].resources.limits.hugepages-
spec.containers[].resources.requests.cpu
spec.containers[].resources.requests.memory
spec.containers[].resources.requests.hugepages-

需求：requests 定义容器运行时至少需要资源
限制：limits 定义容器运行时最多能分配的资源

尽管只能在单个容器上指定请求和限制，但是Pod资源请求和限制很方便。Pod中每个Container的该类型资源请求/限制的会进行加总求和。

6.3 资源单位

CPU
- CPU资源的限制和请求以cpu为单位进行度量。
- Kubernetes中的 1 cpu 相当于1个vCPU / Core（对于云提供商）和1个超线程（在裸机Intel处理器上）。
  
  spec.containers[].resources.requests.cpu: 0.5
  
  表示使用 0.5核 CPU的使用率
- 表达式0.1等同于表达式100m，可以将其理解为“一百毫厘”。有人说“一百亿”，这被理解为是同一回事。
  
  100m ≈ 100mi ≈ 0.1
- 若表达式是纯数字格式，例如0.1，K8S会将具有小数点的请求转换为100m，但精度超出了100m 的允许范围。所以更推荐100m的写法。
- 尽量使用绝对数量的利用率，而不是相对数量。
内存
- 限制和请求都是以内存 字节 为单位。
- 可以使用以下后缀之一将内存表示为纯整数或定点整数：E，P，T，G，M，K。
- 还可以使用两个幂的等效项：Ei，Pi，Ti ，Gi，Mi，Ki。
  - 例如，以下内容表示大致相同的值：
    
    128974848, 129e6, 129M, 123Mi

6.4 资源的使用

准备YAML文件

以下Pod具有两个容器。

每个容器都有一个0.25核cpu和64MiB的内存请求。

每个容器的限制为0.5核cpu和128MiB的内存。

总和为:

当前Pod的请求为0.5核cpu和128 MiB的内存，限制为1核cpu和256MiB的内存。

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: db
    image: mysql
    env:
    - name: MYSQL_ROOT_PASSWORD
      value: "password"
    resources:
      requests:
        memory: "64Mi"            # 表示需要64Mi内存
        cpu: "250m"               # 表示需要0.25核的CPU
      limits:
        memory: "128Mi"           # 表示限制最大内存为128Mi
        cpu: "500m"               # 表示限制最大CPU使用率为0.5核
  - name: wp
    image: wordpress
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

查看资源

[root@master-kubeadm-k8s resource]# kubectl describe node worker02-kubeadm-k8s

image.png

7、Web UI (Dashboard)

Dashboard 是基于网页的 Kubernetes 用户界面。
可以使用 Dashboard 将容器应用部署到 Kubernetes 集群中，也可以对容器应用排错，还能管理集群资源。
可以使用 Dashboard 获取运行在集群中的应用的概览信息，也可以创建或者修改 Kubernetes 资源（如 Deployment，Job，DaemonSet 等等）。
- 例如，可以对 Deployment 实现弹性伸缩、发起滚动升级、重启 Pod 或者使用向导创建新的应用。
Dashboard 同时展示了 Kubernetes 集群中的资源状态信息和所有报错信息。

image.png

7.1 部署Dashboard

默认情况下，K8S不会安装Dashboard，可以手动下载yaml文件进行安装

yaml文件

有两处需要修改

镜像地址更好为国内镜像

默认Dashboard只能集群内访问，所以使用NodePort方式开放端口供外部访问

apiVersion: v1
kind: ConfigMap
metadata:
  labels:
    k8s-app: kubernetes-dashboard
    # Allows editing resource and makes sure it is created first.
    addonmanager.kubernetes.io/mode: EnsureExists
  name: kubernetes-dashboard-settings
  namespace: kube-system
---
apiVersion: v1
kind: ServiceAccount
metadata:
  labels:
    k8s-app: kubernetes-dashboard
    addonmanager.kubernetes.io/mode: Reconcile
  name: kubernetes-dashboard
  namespace: kube-system
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: kubernetes-dashboard
  namespace: kube-system
  labels:
    k8s-app: kubernetes-dashboard
    kubernetes.io/cluster-service: "true"
    addonmanager.kubernetes.io/mode: Reconcile
spec:
  selector:
    matchLabels:
      k8s-app: kubernetes-dashboard
  template:
    metadata:
      labels:
        k8s-app: kubernetes-dashboard
      annotations:
        scheduler.alpha.kubernetes.io/critical-pod: ''
        seccomp.security.alpha.kubernetes.io/pod: 'docker/default'
    spec:
      priorityClassName: system-cluster-critical
      containers:
      - name: kubernetes-dashboard
        image: registry.cn-hangzhou.aliyuncs.com/kubernete/kubernetes-dashboard-amd64:v1.8.3
        resources:
          limits:
            cpu: 100m
            memory: 300Mi
          requests:
            cpu: 50m
            memory: 100Mi
        ports:
        - containerPort: 8443
          protocol: TCP
        args:
          # PLATFORM-SPECIFIC ARGS HERE
          - --auto-generate-certificates
        volumeMounts:
        - name: kubernetes-dashboard-certs
          mountPath: /certs
        - name: tmp-volume
          mountPath: /tmp
        livenessProbe:
          httpGet:
            scheme: HTTPS
            path: /
            port: 8443
          initialDelaySeconds: 30
          timeoutSeconds: 30
      volumes:
      - name: kubernetes-dashboard-certs
        secret:
          secretName: kubernetes-dashboard-certs
      - name: tmp-volume
        emptyDir: {}
      serviceAccountName: kubernetes-dashboard
      tolerations:
      - key: "CriticalAddonsOnly"
        operator: "Exists"
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  labels:
    k8s-app: kubernetes-dashboard
    addonmanager.kubernetes.io/mode: Reconcile
  name: kubernetes-dashboard-minimal
  namespace: kube-system
rules:
  # Allow Dashboard to get, update and delete Dashboard exclusive secrets.
- apiGroups: [""]
  resources: ["secrets"]
  resourceNames: ["kubernetes-dashboard-key-holder", "kubernetes-dashboard-certs"]
  verbs: ["get", "update", "delete"]
  # Allow Dashboard to get and update 'kubernetes-dashboard-settings' config map.
- apiGroups: [""]
  resources: ["configmaps"]
  resourceNames: ["kubernetes-dashboard-settings"]
  verbs: ["get", "update"]
  # Allow Dashboard to get metrics from heapster.
- apiGroups: [""]
  resources: ["services"]
  resourceNames: ["heapster"]
  verbs: ["proxy"]
- apiGroups: [""]
  resources: ["services/proxy"]
  resourceNames: ["heapster", "http:heapster:", "https:heapster:"]
  verbs: ["get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: kubernetes-dashboard-minimal
  namespace: kube-system
  labels:
    k8s-app: kubernetes-dashboard
    addonmanager.kubernetes.io/mode: Reconcile
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: kubernetes-dashboard-minimal
subjects:
- kind: ServiceAccount
  name: kubernetes-dashboard
  namespace: kube-system
---
apiVersion: v1
kind: Secret
metadata:
  labels:
    k8s-app: kubernetes-dashboard
    # Allows editing resource and makes sure it is created first.
    addonmanager.kubernetes.io/mode: EnsureExists
  name: kubernetes-dashboard-certs
  namespace: kube-system
type: Opaque
---
apiVersion: v1
kind: Secret
metadata:
  labels:
    k8s-app: kubernetes-dashboard
    # Allows editing resource and makes sure it is created first.
    addonmanager.kubernetes.io/mode: EnsureExists
  name: kubernetes-dashboard-key-holder
  namespace: kube-system
type: Opaque
---
apiVersion: v1
kind: Service
metadata:
  name: kubernetes-dashboard
  namespace: kube-system
  labels:
    k8s-app: kubernetes-dashboard
    kubernetes.io/cluster-service: "true"
    addonmanager.kubernetes.io/mode: Reconcile
spec:
  selector:
    k8s-app: kubernetes-dashboard
  ports:
  - port: 443
    targetPort: 8443
    nodePort: 30018
  type: NodePort

创建资源

[root@master-kubeadm-k8s dashboard]# kubectl apply -f dashboard.yaml
configmap/kubernetes-dashboard-settings unchanged
serviceaccount/kubernetes-dashboard unchanged
deployment.apps/kubernetes-dashboard created
role.rbac.authorization.k8s.io/kubernetes-dashboard-minimal created
rolebinding.rbac.authorization.k8s.io/kubernetes-dashboard-minimal created
secret/kubernetes-dashboard-certs created
secret/kubernetes-dashboard-key-holder created
service/kubernetes-dashboard created

查看资源
image.png

访问Web UI

https://192.168.50.113:30018/

谷歌浏览器无法直接访问，K8S内部的一些证书它不支持，要想用谷歌浏览器打开dashboard，得手动配置一些证书才行，具体怎么配，网上一堆，这里不演示
image.png

我这里通过搜狗浏览器打开

发现需要认证，有两种方式，我们选择Token令牌的方式登录

image.png

生成Token

# 创建service account
[root@master-kubeadm-k8s dashboard]# kubectl create sa dashboard-admin -n kube-system
serviceaccount/dashboard-admin created

# # 创建角色绑定关系
[root@master-kubeadm-k8s dashboard]# kubectl create clusterrolebinding dashboard-admin --clusterrole=cluster-admin --serviceaccount=kube-system:dashboard-admin
clusterrolebinding.rbac.authorization.k8s.io/dashboard-admin created

# 查看dashboard-admin的secret名字
[root@master-kubeadm-k8s dashboard]# ADMIN_SECRET=$(kubectl get secrets -n kube-system | grep dashboard-admin | awk '{print $1}')
[root@master-kubeadm-k8s dashboard]# echo ADMIN_SECRET
ADMIN_SECRET

# 打印secret的token
[root@master-kubeadm-k8s dashboard]# kubectl describe secret -n kube-system ${ADMIN_SECRET} | grep -E '^token' | awk '{print $2}'
eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJrdWJlLXN5c3RlbSIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VjcmV0Lm5hbWUiOiJkYXNoYm9hcmQtYWRtaW4tdG9rZW4temtsNWoiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoiZGFzaGJvYXJkLWFkbWluIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQudWlkIjoiMGVlZjI5ZDEtOGQzYi0xMWVhLTgyN2EtNTI1NDAwOGFmZWU2Iiwic3ViIjoic3lzdGVtOnNlcnZpY2VhY2NvdW50Omt1YmUtc3lzdGVtOmRhc2hib2FyZC1hZG1pbiJ9.iFaoyxLbiAxuHT5DXZCt1xUjU2n17I0a7ip2zEY6wEKy6ULhG3I9jByeImETAINzqRsPdiRUwi6Rn-oqoq7_36x-XP4EE7C1EgefJqMWPCvVbC4W3UAG6cfjmAUe-9nc5IwxCIxMX-ZeYcNJ8-QiWNVmCxVgqaN53iqKJAwBvHuNQwyrMDI7tBf5SnjLD5_8_HPtzavRH23QlUjT3X_3DHxzYx03oUoVsijs46u-6n52ZNIfemhMzd751Um57RWzvXtYFsXZsRi_KDppw0AuftX6oajXxJvuquP1HWKxKwo0w93FyjKc0GpGCaMooQOim5957j2PJeYOgLX9q8N_qA

登录Dashboard

复制生成的Token登录
image.png

Dashboard功能很全面，有了Dashboard我们很多简单操作无需再到宿主机中去敲命令，直接通过界面操作即可。

具体的使用这里不错介绍了，功能很简单，多点点多看看就知道怎么玩了。

九、Kubernetes 进阶之控制器篇

1、DaemonSet

2、StatefulSet

2.1 StatefulSets 与其他控制器的区别：

2.2 使用StatefulSet

3、Job

3.1 使用Job

3.2 Job类型

4、Cron Job

4.1 使用Cron Job

5、Horizontal Pod Autoscaler

5.1 Horizontal Pod Autoscaler的使用

5.2 HPA工作机制

6、Resource

6.1 reques 与 limit

6.2 资源的配置项

6.3 资源单位

6.4 资源的使用

7、Web UI (Dashboard)

7.1 部署Dashboard

猜你喜欢

热点阅读