Kubernetes (also known as k8s or “kube”) is a very popular container orchestration platform that automates many of the manual processes involved in deploying, managing, and scaling containerized applications.
You can cluster together groups of hosts running Linux containers, and Kubernetes helps you easily and efficiently manage those clusters. The cluster can be located locally, for testing or dev purposes or in the Cloud for Production setup.
There is a big variety of containers available, from Kubernetes official repo or other unofficial sources. For example, there are containers for web applications such as, Nginx, Apache, or Databases (MySQL), or applications for specific purposes such as VoD/Live transcoding and streaming.
Kubernetes Architecture
It is very important to understand the architecture because it will help to solve issues and identify where the problem is within your Cluster.
Figure 1:
Figure 1, is showing the High-Level Architecture and the main Kubernetes components which will explain below:
Master Node
The Kubernetes master is responsible for maintaining the desired state for the cluster. When the administrator interacts with Kubernetes, such as by using the kubectl command-line interface, will need to communicate with the cluster’s Kubernetes master.
- API Server: The Kubernetes API server validates and configures data for the API objects which include pods, services, replication controllers, and others.
- Controller Manager: In Kubernetes, a controller is a control loop that watches the shared state of the cluster through the apiserver and makes changes attempting to move the current state towards the desired state.
- Scheduler: Kubernetes Schedulerselects an optimal node to runnewly created pods or other unscheduled pods.
- Etcd: etcd is a consistent and highly-available key-value store used as Kubernetes’ backing store for all cluster data.
Worker Node
The nodes in a cluster are the machines (VMs, physical servers, etc) that run the applications and cloud workflows. The Kubernetes master controls each node and will rarely need to interact with nodes directly.
- Kubelet: The kubelet is the primary “node agent” that runs on each node. It can register the node with the apiserver.
- Kube-Proxy: Kube-proxy is a network proxy that runs on each node in the cluster and maintains network rules on nodes.
- Pods: Pods are the smallest deployable units of computing that can be created and managed in Kubernetes.
- Containers: Containers are a technology for packaging the (compiled) code for an application along with the dependencies it needs at run time.
You can have a cluster locally, for development purposes, or in the Cloud. I will provide the tools which can be used for both cases, as well as tools for monitoring, logs and alerts.
Local Cluster
To install a cluster locally will need to use a very popular tool, which is Minikube. Minikube runs a single-node Kubernetes cluster inside a Virtual Machine (VM) on your laptop for users looking to try out Kubernetes or develop with it day-to-day.
The installation guide can be found here but is very important to install Kubectl first (can be found in the same homepage) to be able to interact with the cluster via CLI:
https://kubernetes.io/docs/tasks/tools/install-minikube/
Also, the repo for Minikube can be found here:
https://github.com/kubernetes/minikube
Cloud Cluster
kops helps you create, destroy, upgrade, and maintain production-grade, highly available, Kubernetes clusters from the command line. AWS (Amazon Web Services) is currently officially supported, with GCE and OpenStack in beta support, and VMware vSphere in alpha.
The installation guide for Kops can be found here:
https://kubernetes.io/docs/setup/production-environment/tools/kops/
However, if you want to use GCE (and can’t wait for the official Kops release), you can use the GCE Kubernetes tools (available in the GCE dashboard). Before you start deploying in GCE, is better to watch this video from Richard Chesterwood:
After you have the cluster (locally or in the cloud) ready, you can use some pre-configured yaml files to test your cluster:
https://kubernetes.io/docs/tasks/run-application/
Open-Source Tools
There are many tools that can use with the Kubernetes cluster but I will provide the most important ones.
Helm
Helm is a tool that streamlines installing and managing Kubernetes applications. Think of it like Apt/Yum/Homebrew for K8S.
Helm uses a packaging format called charts. A chart is a collection of files that describe a related set of Kubernetes resources. A single chart might be used to deploy something simple, like a Memcached pod, or something complex, like a full web app stack with HTTP servers, databases, caches, and so on.
Logging a Cluster – ELK stack (Fluentd)
“ELK” is the acronym for three open source projects: Elasticsearch, Logstash, and Kibana. Elasticsearch is a search and analytics engine. Logstash is a server‑side data processing pipeline that ingests data from multiple sources simultaneously, transforms it, and then sends it to a “stash” like Elasticsearch. Kibana lets users visualize data with charts and graphs in Elasticsearch.
However, Fluentd is the opensource version, Fluentd is an open-source data collector, which lets you unify the data collection and consumption for better use and understanding of data.
https://www.fluentd.org/architecture
Monitoring a Cluster – Prometheus & Grafana
Monitors the Kubernetes cluster using Prometheus. Shows overall cluster CPU / Memory / Filesystem usage as well as an individual pod, containers, systemd services statistics. Uses cAdvisor metrics only.
https://grafana.com/grafana/dashboards/315
https://github.com/helm/charts/tree/master/stable/prometheus-operator
Alert Manager (part of Prometheus Operator)
The Alertmanager handles alerts sent by client applications such as the Prometheus server. It takes care of deduplicating, grouping, and routing them to the correct receiver integration such as email, PagerDuty, or OpsGenie. It also takes care of silencing and inhibition of alerts.
https://prometheus.io/docs/alerting/latest/alertmanager/
https://prometheus.io/docs/alerting/latest/configuration/
Alertmanager config can be very long and complicated, however a simple config file looks like this (includes Slack channel config):
global:
slack_api_url: '<add here the Slack Webhook URL>'
route:
group_by: ['alertname']
group_wait: 5s
group_interval: 1m
repeat_interval: 10m
receiver: 'slack'
receivers:
- name: 'slack'
slack_configs:
- channel: '<add here the slack channel>'
icon_emoji: ':bell:'
send_resolved: true
text: "<!channel> \nsummary: {{ .CommonAnnotations.summary }}\ndescription: {{ .CommonAnnotations.description }}"
