I noticed that none of the Kubernetes services are writing logs to /var/log/ on the master nodes. I built my lab with kubeadm and a reasonably basic configuration file, just the settings needed to make it work. The configuration file contained just enough information to build the lab and make it work. The Kubernetes services apiServer, ControlManager and Scheduler have several configuration flags for logging. In this post, I am going to go through my experience, enabling logging with kubeadm.
Static pods are like regular pods, except they are managed by the kubelet service on a node and not the API server. The kubelet creates a mirror pod on the API server, which is a read-only copy that allows the pod to be seen on the API server but not controlled. The kubelet service is responsible for managing the state of the pod and controlling restarts, for example. The kubelet process watches the location specified with the configuration parameter --manifest-url or --pod-manifest-path.
A DaemonSet is an object which ensures that there is a copy of a pod running on each node. This type of object is commonly used to deploy pods which provide a management service, such as log collection daemons or monitoring daemons to provide data to a solution such as Prometheus. The scheduler places a copy of the pod specified in a DaemonSet on all eligible nodes within the cluster.
Labels are a key/value formatted peice of metadata attached to an object within Kubernetes. Labels provide additional information about the object with relevance to the consumer or object. For example, a label can specify hardware characteristics of a node or if a workload is for testing of production. Labels implicitly group like objects together while providing a lookup mechanism for users, controllers and external systems. For this example, I have a deployment for a web service which runs on internal infrastructure and one which runs on DMZ infrastructure.
I’ve recently started learning Kubernetes, working through the CKA curriculum and performing various administrative tasks. During my study so far, I have found that there are a lot of manual steps involved when looking at an end to end process. Often the process required to achieve an outcome requires the same data to be entered in multiple places, for example, labels and selectors. A process which I have found to be overly manual and prone to misconfiguration is user management.
Build Performance Requirements into the Logical Design
vROPS 7.0 launched with a feature called Business Intent which controls workload placement based on vSphere tags Announcement. This feature tackles several use cases one being controlling the host placement of workloads which have physical licencing requirements. Business Intent settings are configured at the data centre (or custom datacenter) level within vROPS 7.0 and can be configured at the per cluster or per host level. For the scope of this post, I am going to cover a customer use case to combine clusters, increaseing availability for some workloads while maintaining licencing compliance for others.
Build Manageability Requirements into the Logical Design