Highly available Kubernetes cluster-13. Deploy kubernetes-dashboard

Reference documentation:

1. Github introduction:https://github.com/kubernetes/dashboard
2. Github yaml file:

   https://github.com/kubernetes/dashboard/blob/master/src/deploy/recommended/kubernetes-dashboard.yaml

   Or (each service module is saved independently): https://github.com/kubernetes/kubernetes/tree/master/cluster/addons/dashboard

3. Access the dashboard :https://github.com/kubernetes/dashboard/wiki/Accessing-Dashboard---1.7.X-and-above
4. Issues accessing dashboard (based on 1.6.x version): https://github.com/opsnull/follow-me-install-kubernetes-cluster/issues/5

 

Kubernetes-dashboard is a ui web page management tool for kubernetes , which provides common cluster functions such as deploying applications, resource object management, container log query, and system monitoring.

1. environment

1. basic environment

components	Version	Remark
governor	v1.9.2
kubernetes-dashboard	v1.8.3

1. Deploy Kubernetes-dashboard

1. prepare images

When kubernetes deploys services, in order to avoid the problem of time-out of pull images during deployment, it is recommended to pull related images to all related nodes (experimental) in advance, or build a local image system.

1. The basic environment has been accelerated by mirroring, please refer to: http://www.cnblogs.com/netonline/p/7420188.html
2. The image that needs to be pulled from gcr.io has used the "Create Auto-Build GitHub" function of Docker Hub (Docker Hub uses the Dockerfile file on GitHub to build the image). The build is successful in the personal Docker Hub and can be directly pulled to the local use.

 

# kubernetes-dashboard

[root@kubenode1 ~]# docker pull netonline/kubernetes-dashboard-amd64:v1.8.3

1. Download kubernetes-dashboard related yaml template

# https://github.com/kubernetes/kubernetes/tree/master/cluster/addons/dashboard

# You can also put multiple service resources in one yaml file

[root@kubenode1 ~]# mkdir -p /usr/local/src/yaml/dashboard

[root@kubenode1 ~]# cd /usr/local/src/yaml/dashboard

 

# ConfigMap

[root@kubenode1 dashboard]# wget https://raw.githubusercontent.com/kubernetes/kubernetes/master/cluster/addons/dashboard/dashboard-configmap.yaml

 

# Secret

[root@kubenode1 dashboard]# wget https://raw.githubusercontent.com/kubernetes/kubernetes/master/cluster/addons/dashboard/dashboard-secret.yaml

 

# RBAC

[root@kubenode1 dashboard]# wget https://raw.githubusercontent.com/kubernetes/kubernetes/master/cluster/addons/dashboard/dashboard-rbac.yaml

 

# dashboard-controller

[root@kubenode1 dashboard]# wget https://raw.githubusercontent.com/kubernetes/kubernetes/master/cluster/addons/dashboard/dashboard-controller.yaml

 

# Service

[root@kubenode1 dashboard]# wget https://raw.githubusercontent.com/kubernetes/kubernetes/master/cluster/addons/dashboard/dashboard-service.yaml

 

This experiment uses the yaml file (modified version): https://github.com/Netonline2016/kubernetes/tree/master/addons/dashboard

1. dashboard-configmap.yaml

It will not be modified for the time being. For this verification, dashboard-controller does not use configmap.

1. dashboard-rbac.yaml

Because the api-server has performed two-way digital certificate authentication, and the display and operation of the dashboard are realized by calling the interface of the api-server, it is necessary to authorize the dashboard and use the rbac authorization mode.

 

# By default dashboard-rbac.yaml defines a Role named "kubernetes-dashboard-minimal"; and made a RoleBinding named "kubernetes-dashboard-minimal" to authorize the ServiceAccount named "kubernetes-dashboard";

# But the Role permissions defined by the default dashboard-rbac.yaml are too small, which is not convenient for verification;

# To redefine rbac, you only need to define a new ClusterRoleBinding: kubernetes-dashboard, and assign kubernetes' own ClusterRole: cluster-admin with full permissions to ClusterRoleBinding; this authorization method should be used with caution in the production environment;

# Note the red bold font

[root@kubenode1 ~]# cd /usr/local/src/yaml/dashboard/

[root@kubenode1 dashboard]# vim dashboard-rbac.yaml

apiVersion: rbac.authorization.k8s.io/v1

kind: ClusterRoleBinding

metadata:

name: kubernetes-dashboard

namespace: kube-system

labels:

k8s-app: kubernetes-dashboard

addonmanager.kubernetes.io/mode: Reconcile

roleRef:

apiGroup: rbac.authorization.k8s.io

kind: ClusterRole

name: cluster-admin

subjects:

- kind: ServiceAccount

name: kubernetes-dashboard

namespace: kube-system

1. dashboard-secret.yaml

In kubernetes 1.8.x and 1.9.x versions, the dashboard service enables the https port by default instead of the default http 9090 port in the 1.6.x version, which requires the secret resource to call the relevant certificate.

dashboard-secret.yaml is not modified.

1. dashboard-controller.yaml

# dashboard-controller.yaml defines the ServiceAccount resource (authorization) and Deployment (service Pod);

# Modify the dashboard image used by default on line 33

dashboard-controller.yaml

[root@kubenode1 dashboard]# sed -i 's|k8s.gcr.io/kubernetes-dashboard-amd64:v1.8.3|netonline/kubernetes-dashboard-amd64:v1.8.3|g' dashboard-controller.yaml

1. dashboard-service.yaml

# dashboard-service.yaml defines the service, the red bold font is the modified or new part;

# Define the "NodePort" type, to verify the direct access to the dashboard through the control node (not recommended in the production environment), "nodePort: 18443" defines a specific port, if not set, it will be randomly generated in the service port range

[root@kubenode1 dashboard]# vim dashboard-service.yaml

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

type: NodePort

ports:

- port: 443

targetPort: 8443

nodePort: 18443

1. Verify Kubernetes-dashboard

1. start the dashboard

# Start the services defined by the rbac, secret, controller, and service 4 yaml files;

# or kubectl create -f .

[root@kubenode1 ~]# cd /usr/local/src/yaml/dashboard/

[root@kubenode1 dashboard]# kubectl create -f dashboard-rbac.yaml

[root@kubenode1 dashboard]# kubectl create -f dashboard-secret.yaml

[root@kubenode1 dashboard]# kubectl create -f dashboard-controller.yaml

[root@kubenode1 dashboard]# kubectl create -f dashboard-service.yaml

1. View related services

# View service, nodePort has been done according to the defined port

[root@kubenode1 dashboard]# kubectl get svc -n kube-system

 

# View deployment and pod services

[root@kubenode1 dashboard]# kubectl get deployment -n kube-system

[root@kubenode1 dashboard]# kubectl get pod -n kube-system

1. Access dashboard through kube-apiserver

There are 3 ways to access the dashboard:

1. Access dashboard through kube-apiserver,;
2. Access dashboard through kubectl proxy;
3. Access the dashboard through nodePort, it is recommended to use it in an experimental environment.

Reference: https://github.com/kubernetes/dashboard/wiki/Accessing-Dashboard---1.7.X-and-above

Generate an access certificate for kube-apiserver

# Because the kube-apiserver enables two-way authentication, and the local browser uses an anonymous certificate when accessing the kube-apiserver (when the relevant certificate is not imported), the authorization fails and cannot be accessed;

# The certificate for the client tool kubectl to access kube-apiserver has been generated before, and here it is only necessary to convert the certificate that can be recognized by the browser client;

# The password can be left blank when converting, otherwise you need to enter the password when importing

[root @ kubenode1 ~] # cd / etc / kubernetes / admin /

[root@kubenode1 admin]# openssl pkcs12 -export -in admin.pem -out admin-dashboard.p12 -inkey admin-key.pem

Import the access certificate of kube-apiserver

Take the firefox browser as an example to import the certificate, enter the password used for conversion, and leave it blank here.

Access dashboard through kube-apiserver

# Get the kube-apiserver access address of the dashboard

[root@kubenode1 ~]# kubectl cluster-info

 

Browser security access https://<kube-apiserver>:<port>: https://172.30.200.10:6443/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy

 

1. To access using "Kubeconfig", you need to import the kubeconfig file. Here, the kubeconfig file required for the client tool kubectl access is generated: /etc/kubernetes/admin/admin.conf;
2. To use token access, you need to enter the token, here you can get the token name through "kubectl get secret -n kube-system | grep kubernetes-dashboard-token", and then pass "kubectl describe secret kubernetes-dashboard-token-wl2wq -n" kube-system" to get the token ("kubernetes-dashboard-token-wl2wq" is the token name);
3. Or simply "skip".

 

After entering the kubernetes homepage, it is in the default namespace by default.

1. Access dashboard through kube-proxy

# kubectl proxy can enable the proxy, the proxy is not necessarily enabled on the node where the pod is located.

[root@kubenode1 dashboard]# kubectl get pod -n kube-system -o wide

[root@kubenode1 ~]# kubectl proxy --address='172.30.200.21' --port=18001 --accept-hosts='^*$'

 

Browser insecure access to http://<proxy node>:<port>: http://172.30.200.21:18001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy

1. Access dashboard via NodePort

When defining dashboard-service.yaml, the NodePort" type has been defined and "nodePort: 18443" is specified. This method is not recommended in the production environment.

Securely access https://<node>:<port > through a browser (different from the proxy method, the node must be the node where the pod is located): https://172.30.200.23:18443