Shulou(Shulou.com)06/01 Report--

This article focuses on "how Dashboard manages Kubernetes clusters and API access configuration". Interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn how Dashboard manages Kubernetes clusters and API access configuration.

A complete Collection of Kubectl commands

All the commands for kubectl and their abbreviations are listed below for browsing.

Kubectl command format:

Kubectl [command] [type] [Name] [flag] allevents (ev) podsecuritypolicies (psp) certificatesigningrequests (csr) horizontalpodautoscalers (hpa) podtemplatesclusterrolebindingsingresses (ing) replicasets (rs) clusterrolesjobsreplicationcontrollers (rc) limitranges (limits) resourcequotas (quota) componentstatuses (cs) namespaces (ns) rolebindingsconfigmaps (cm) networkpolicies (netpol) rolescontrollerrevisionsnodes (no) secretscronjobspersistentvolumeclaims (secretscronjobspersistentvolumeclaims) secretscronjobspersistentvolumeclaims (secretscronjobspersistentvolumeclaims) secretscronjobspersistentvolumeclaims (pvc) pvc (pvc) serviceaccounts (serviceaccounts) serviceaccounts (serviceaccounts) serviceaccounts (sa) serviceaccounts () serviceaccounts () serviceaccounts (serviceaccounts)

Kubernetes-Dashboard is a Web UI that manages Kubernetes clusters. Like kubectl, the back end is API-Server, and Kubernetes-Dashboard is deployed using online YAML files:

Kubectl apply-f https://raw.githubusercontent.com/kubernetes/dashboard/v2.2.0/aio/deploy/recommended.yaml

After dashboard is created, it is in the kubernetes-dashboard namespace.

Root@instance-1:~# kubectl get pods-namespace=kubernetes-dashboardNAME READY STATUS RESTARTS AGEdashboard-metrics-scraper-856586f554-4nd9v 1 9dkubernetes-dashboard-78c79f97b4 1 Running 0 9dkubernetes-dashboard-78c79f97b4-288js 1 Running 0 9droot@instance-1:~# kubectl get services-namespace=kubernetes-dashboardNAME TYPE CLUSTER -IP EXTERNAL-IP PORT (S) AGEdashboard-metrics-scraper ClusterIP 10.98.50.123 8000/TCP 9dkubernetes-dashboard NodePort 10.111.44.44 443/TCP 9d

Since its network defaults to NodePort and is not configured to be opened by the outside world, you can modify its service in order to be accessed by the outside world:

Kubectl edit service kubernetes-dashboard-- namespace=kubernetes-dashboard ports:-nodePort: 30633 port: 443protocol: TCP targetPort: 8443 selector: k8s-app: kubernetes-dashboard sessionAffinity: None type: NodePort

Or change type to LoadBalancer.

It can be accessed through 443 in the private network of the cluster and 30633 in the external network, and the access method is https.

As you can see, the access methods are Token and kubeconfing, both of which will be discussed later.

We can view the Token with the following command:

Kubectl-n kube-system describe $(kubectl-n kube-system get secret-n kube-system-o name | grep namespace) | grep token

Copy it and fill it in the Web UI to enter the console.

RESTful API

We can access API-Server from any node in the cluster, and its port is 6443.

API can be authenticated using Token and certificate. We can use the token queried in the previous section to access API:

Curl https://k8smaster:6443/api/v1/pods-k-header "Authorization: bearer {fill in your token} here"

Note: use-k to ignore certificate issues; k8smaster is configured by the author hosts, specifically based on your master node ip.

You can also use a certificate to access API in the following format:

Curl-- cert / tmp/client.pem-- key / tmp/client-key.pem\-- cacert / tmp/ca.pem-v-XGET\ https://k8smaster:6443/api/v1/pods

There is not much introduction to the API of K8s here, only a few API that are useful for debugging.

GET / api/v1/namespaces/ {namespace} / pods/ {name} / execGET / api/v1/namespaces/ {namespace} / pods/ {name} / logGET / api/v1/watch/namespaces/ {namespace} / pods/ {name} authentication

Because API-Server requires certain permissions to access, users actually need permissions to execute commands when they use the kubectl tool.

The kubectl auth can-i command is used to determine whether a user can access API.

To determine whether the current user has access to deployments, you can use:

Kubectl auth can-i create deploymentskubectl auth can-i {Command}

To check whether other users have permissions, you can use-- as:

Kubectl auth can-i create deployments-as dddddkubectl auth can-i create deployments-as ddddd-namespace kube-system

In order to obtain permissions more easily, we can use SelfSubjectAccessReview as an API to obtain permission information resources. It exposes API server authentication to external services, and its API specifies the document address:

Https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.21/#selfsubjectaccessreview-v1-authorization-k8s-io

There are also three related API:

SubjectAccessReview-evaluate the access of any user, not just the current user. This is useful when authentication decisions are delegated to the API server. For example, kubelet and extended API servers use it to determine users' access to their own API.

LocalSubjectAccessReview-similar to SubjectAccessReview, but limited to specific namespaces.

SelfSubjectRulesReview-returns a review of the set of actions that the user can perform in the namespace. Users can quickly summarize their access rights or use them for hide / show actions in UI.

We only need to know here, not in depth.

Notes

We can use Kubernetes annotations to attach arbitrary unidentified metadata to objects, and annotations are marked with annotations. Client programs, such as tools and libraries, can obtain this metadata information.

Let's take a look at the relevant annotations of dashboard:

Kubectl describe services-n kubernetes-dashboard... ... Labels: k8s-app=kubernetes-dashboardAnnotations:......

Annotations consists of key/value, similar to label, but annotations supports some special characters that can be used as information, logging, and so on when building and publishing images.

Kubectl annotate service kubernetes-dashboard-n kubernetes-dashboard description='my test'key=descriptionvalue=my test

If you re-look at describe, you can see:

Annotations: description: my test

To override the value of key, you need to add-- overwrite.

To delete a key:

Kubectl annotate service kubernetes-dashboard description-Pod YAML structure

This is a simple YAML file:

ApiVersion: v1kind: Podmetadata: name: firstpodspec: containers:-image: nginx name: stan

The YAML of k8s must contain four parts:

Version of the apiVersion:API group

Kind: the type of object created

Metadata: metadata. Name field is required.

Spec: how to create an object. If it is pod, container is required.

Configuration

The configuration information for Kubernetes is stored in the $HOME/.kube/config file, which can be viewed directly or via kubectl config view (showing only part of the information).

When we visited API earlier, we used token, and now we can use this config to create a certificate file and access it through a certificate.

The client key is stored in the client-certificate-data field of the config file.

Grep client-cert $HOME/.kube/config | cut-d ""-f 6

Key, which stores in the client-key-data field:

Grep client-key-data $HOME/.kube/config | cut-d ""-f 6

API-Server 's public key (auth), which is stored in the certificate-authority-data field:

Grep certificate-authority-data $HOME/.kube/config | cut-d ""-f 6

It means three important key data. for convenience, three variables client, key and auth are used to store the query data.

Export client= (grep client-cert $HOME/.kube/config | cut-d ""-f 6) export key= (grep client-key-data $HOME/.kube/config | cut-d ""-f 6) export auth= (grep certificate-authority-data $HOME/.kube/config | cut-d ""-f 6)

Create a certificate file:

Echo $client | base64-d->. / client.pemsecho $key | base64-d->. / client-key.pemecho $auth | base64-d->. / ca.pem

Then you can securely access the API-Server through the certificate when you access it:

Curl-- cert. / client.pem-- key. / client-key.pem-- cacert. / ca.pem https://k8smaster:6443/api/v1/pod here, I believe you have a better understanding of "how Dashboard manages Kubernetes clusters and API access configuration". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.