Introduction to Kubernetes (13): Dashboard, API, Access Configuration

目录

• Kubectl Command Overview
• Installing Kubernetes-Dashboard
• RESTful API
• Authentication
• Annotations
• Pod YAML Structure
• Configuration

Kubectl Command Overview

In the previous sections, we learned some Kubernetes knowledge. Now let's list all the kubectl commands and their abbreviations for reference.

The kubectl command format:

kubectl [command] [type] [name] [flag]  

| all | events (ev) | podsecuritypolicies (psp) |
| --------------------------------------------------- | -------------------------------------- | ----------------------------------- |
| certificatesigningrequests (csr) | horizontalpodautoscalers (hpa) | podtemplates |
| clusterrolebindings | ingresses (ing) | replicasets (rs) |
| clusterroles | jobs | replicationcontrollers (rc) |
| clusters (valid only for federation apiservers) | limitranges (limits) | resourcequotas (quota) |
| componentstatuses (cs) | namespaces (ns) | rolebindings |
| configmaps (cm) | networkpolicies (netpol) | roles |
| controllerrevisions | nodes (no) | secrets |
| cronjobs | persistentvolumeclaims (pvc) | serviceaccounts (sa) |
| customresourcedefinition (crd) | persistentvolumes (pv) | services (svc) |
| daemonsets (ds) | poddisruptionbudgets (pdb) | statefulsets |
| deployments (deploy) | podpreset | storageclasses |
| endpoints (ep) | pods (po) | |

Installing Kubernetes-Dashboard

Kubernetes-Dashboard is a web UI for managing Kubernetes clusters. Similar to kubectl, its backend is the API-Server. Deploy the Kubernetes-Dashboard using the online YAML file:

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

Once the dashboard is created, it will be in the kubernetes-dashboard namespace.

root@instance-1:~# kubectl get pods --namespace=kubernetes-dashboard  
NAME                                         READY   STATUS    RESTARTS   AGE  
dashboard-metrics-scraper-856586f554-4nd9v   1/1     Running   0          9d  
kubernetes-dashboard-78c79f97b4-288js        1/1     Running   0          9d  

root@instance-1:~# kubectl get services --namespace=kubernetes-dashboard  
NAME                            TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)         AGE  
dashboard-metrics-scraper       ClusterIP   10.98.50.123     <none>        8000/TCP        9d  
kubernetes-dashboard            NodePort    10.111.44.44     <none>        443/TCP   9d  

Since its network is default to NodePort and not configured for external access, we can modify its service for external accessibility:

kubectl edit service kubernetes-dashboard --namespace=kubernetes-dashboard  

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

Or change the type to LoadBalancer.

Internally, it can be accessed through port 443, and externally through port 30633, using HTTPS.

You can see that access methods include Token and configuration file (kubeconfig), which will be discussed later.

We can check the Token using 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 into the Web UI to enter the console.

RESTful API

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

The API can be authenticated using Token or certificates. We can use the token queried from the previous section to access the API:

curl https://k8smaster:6443/api/v1/pods -k --header "Authorization: bearer {填入你的token}"  

Note: Using -k ignores certificate issues; k8smaster is configured in the hosts file by the author, so adjust it to your master node IP.

Alternatively, you can access the API using a certificate 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  

Here, we won't elaborate on k8s' API, only introduce a few APIs useful for debugging.

GET /api/v1/namespaces/{namespace}/pods/{name}/exec  

GET /api/v1/namespaces/{namespace}/pods/{name}/log  

GET /api/v1/watch/namespaces/{namespace}/pods/{name}  

Authentication

Since the API-Server requires certain permissions to access, users also need permissions to execute commands while using kubectl.

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

To check if the current user has permission to access deployments, you can use:

kubectl auth can-i create deployments  

kubectl auth can-i {command}  

To check if another user has permission, you can use --as:

kubectl auth can-i create deployments --as ddddd  

kubectl auth can-i create deployments --as ddddd --namespace kube-system  

To simplify obtaining permissions, we can use the SelfSubjectAccessReview API to obtain permission information resources, which exposes the API server's authentication to external services. The API documentation is available at:

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

Additionally, there are three related APIs:

• SubjectAccessReview - Evaluates access for any user, not just the current user. This is useful when the authentication decision is delegated to the API server, for example, kubelet and extended API servers use it to determine user access to their own APIs.
• LocalSubjectAccessReview - Similar to SubjectAccessReview, but limited to a specific namespace.
• SelfSubjectRulesReview - Returns a review of the set of actions a user can perform within a namespace. Users can quickly summarize their access permissions or use it for hiding/showing actions in the UI.

These only need to be understood, no need for in-depth knowledge.

Annotations

We can use Kubernetes annotations to attach arbitrary non-identifying metadata to objects, with annotations identified by the annotations label. Client programs (such as tools and libraries) can retrieve this metadata.

We can view the related annotations of the dashboard:

kubectl describe services -n kubernetes-dashboard  

... ...  
Labels:                   k8s-app=kubernetes-dashboard  
Annotations:              <none>  
... ...  

Annotations consist of key/value pairs, similar to labels, but annotations support special characters and can be used for information such as building release images and logging.

kubectl annotate service kubernetes-dashboard -n kubernetes-dashboard description='my test'  

key=description  

value=my test  

When we recheck the describe command, we can see:

Annotations:              description: my test  

If you want to overwrite the value of a key, you need to add --overwrite.

To delete a key:

kubectl annotate service kubernetes-dashboard description-  

Pod YAML Structure

Here is a simple YAML file:

apiVersion: v1  
kind: Pod  
metadata:  
    name: firstpod  
spec:  
    containers:  
    - image: nginx  
      name: stan  

K8s YAML must contain four parts:

• apiVersion: API group version
• kind: Type of the object being created
• metadata: Metadata, the name field is required
• spec: How to create the object, if it is a pod, container is required.

Configuration

The Kubernetes configuration information is stored in the $HOME/.kube/config file, which can be directly opened to view, or you can use kubectl config view to view (displaying only partial information).

Earlier we accessed the API using a token; now we can use this config to create certificate files for access via certificates.

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

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

The key is stored in the client-key-data field:

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

The public key of the API-Server (auth) is stored in the certificate-authority-data field:

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

This means there are three important key data. For convenience, we use the variables client, key, and auth to store the queried 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 certificate files:

echo $client | base64 -d - > ./client.key  
echo $key | base64 -d - > ./client-key.pem  
echo $auth | base64 -d - > ./ca.pem  

Then you can securely access the API-Server using the certificates:

curl --cert ./client.pem --key ./client-key.pem --cacert ./ca.pem https://k8smaster:6443/api/v1/pod