The problem

The Kubernetes container service of Aliyun has created 3 master ha clusters by default according to the requirements of production. Apiserver, Controller, and Scheduler are deployed on each master node. For advanced users, especially in the development testing phase, who may need to adjust the logging level of these components to dubug their running behavior, manually adjust the logging level. Then we need to know how Aliyun kubernetes is configured to hack it.

Understand the deployment mode of Aliyun Kubernetes

The Docker deployment

Docker is deployed by Systemd, you can log in to a master, through

systemctl status dockerCopy the code

Check the status of the Docker Daemon to see where the docker configuration is/usr/lib/systemd/system/docker.service

Docker log configuration:

Then you can know the container of stdout logs will be in the container’s directory, file to the/var/lib/docker/containers / < container – id > / < > container – id – json. The log

Deployment of Kubelet

Kubelet is also deployed through Systemd, you can log in to a master, through

systemctl status kubeletCopy the code

Check the running status of Kubelet to know the configuration of Kubelet in/etc/systemd/system/kubelet.service.d/10-kubeadm.conf

Kubelet runs with the following configuration:



The red box is the path to the yaml file for configuring static Pod:/etc/kubernetes/manifests

The use and principle of the Static Pod can see: kubernetes. IO/docs/tasks /…

Scheduler’s log startup parameters

Into the/etc/kubernetes manifests directory, you can see there are three files, this is apiserver, scheduler, the operation of the controller pod yaml files

The podyAML file for the cloud scheduler is kube-scheduler.yaml, where the configuration is found. The scheduler Pod outputs directly to STdout, so its log file is in the container’s directory.

Log level configuration for Kubernetes Scheduler

Kubernetes uses scheduler –help to change the scheduler configuration.

It does not say what the optional value of the configuration is, and the official documentation does not say how to configure it. It does not even say the -v parameter. You have to go to Google and find the documentation:

Github.com/kubernetes/…

Hack Scheduler log level practices

Now that we know how scheduler works, and we know diary level configuration, hacks are a lot easier

  • Modify the/etc/kubernetes/manifests/kube-scheduler.yamlIncreased.-v=4The configuration of the

  • Wait for Kubelet to restart the corresponding POD, you can passdocker ps | grep schedulerCheck whether the corresponding POD has been restarted
  • docker ps | grep schedulerObtain the corresponding Container ID
  • View the corresponding/var/lib/docker/containers/<container-id>/<container-id>-json.logYou can get the corresponding log

conclusion

The same principle applies to other components if you need to hack them. However, this should only be used for development/testing purposes. In a production environment, it is important to keep the original configuration, after all, it is a production proven configuration.