Explore topic-wise InterviewSolutions in .

This architecture depends upon the APPLICATION and many other factors. Following are the common logging patterns

• Node level logging agent.
• Streaming sidecar container.
• Sidecar container with the logging agent.
• Export LOGS directly from the application.

In the SETUP, journalbeat and filebeat are running as daemonset. Logs collected by these are dumped to the kafka topic which is EVENTUALLY dumped to the ELK stack.

The same can be achieved using EFK stack and fluentd-bit.

Prometheus is USED for Kubernetes monitoring. The Prometheus ecosystem CONSISTS of multiple components.

• Mainly Prometheus server which scrapes and STORES time-series data.
• Client libraries for instrumenting application code.
• Push gateway for supporting short-lived jobs.
• Special-purpose exporters for services like StatsD, HAPROXY, Graphite, etc.
• An ALERT manager to handle alerts on various support tools.

By DEFAULT, POD can COMMUNICATE with any other POD, we can SET up network policies to limit this COMMUNICATION between the PODs.

• RBAC (Role-based access control) to narrow down the permissions.
• Use namespaces to ESTABLISH security boundaries.
• Set the admission control policies to avoid running the privileged containers.
• Turn on audit logging.

Load BALANCING is a way to distribute the incoming traffic into multiple backend SERVERS, which is useful to ensure the application available to the users.

In Kubernetes, as shown in the above figure all the incoming traffic lands to a single IP address on the load balancer which is a way to expose your service to outside the internet which routes the incoming traffic to a particular pod (via service) using an algorithm known as round-robin. Even if any pod GOES down load balances are notified so that the traffic is not routed to that particular unavailable node. THUS load balancers in Kubernetes are responsible for distributing a SET of tasks (incoming traffic) to the pods

 init CONTAINERS will set a stage for you before running the actual POD.

Wait for some time before STARTING the APP Container with a command like sleep 60.

Clone a GIT repository into a volume.

A Kubernetes administrator can create a deployment of a kind: PodDisruptionBudget for high availability of the application, it makes sure that the minimum NUMBER is running pods are respected as mentioned by the ATTRIBUTE minAvailable SPEC file. This is useful while performing a drain where the drain will halt until the PDB is respected to ensure the High Availability(HA) of the application. The following spec file also shows minAvailable as 2 which implies the minimum number of an AVAILABLE pod (even after the election).

Example: YAML Config using minAvailable => 

Mainly K8 cluster consists of two types of nodes, executor and master.

Executor node: (This runs on master node)

• Kube-proxy: This service is responsible for the communication of pods within the cluster and to the OUTSIDE network, which runs on every node. This service is responsible to MAINTAIN network protocols when your pod establishes a network communication.
• kubelet: Each node has a running kubelet service that updates the running node accordingly with the configuration(YAML or JSON) file. NOTE: kubelet service is only for containers created by Kubernetes.

Master services:

• Kube-apiserver: Master API service which acts as an entry point to K8 cluster.
• Kube-scheduler: Schedule PODs according to available resources on executor nodes.
• Kube-controller-manager:  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 stable state

With the use of limit and REQUEST resource usage of a POD can be controlled.

Request: The number of resources being requested for a container. If a container exceeds its request for resources, it can be throttled back down to its request.

Limit: An upper cap on the resources a single container can use. If it tries to exceed this predefined limit it can be terminated if K8's decides that ANOTHER container needs these resources. If you are sensitive TOWARDS pod restarts, it makes sense to have the sum of all container resource limits equal to or less than the total resource capacity for your cluster.

Example:

Whenever there are security patches available the Kubernetes administrator has to perform the maintenance task to apply the security PATCH to the running container in order to prevent it from vulnerability, which is often an unavoidable part of the ADMINISTRATION. The following two commands are useful to SAFELY drain the K8s node.

• kubectl cordon
• kubectl drain –ignore-daemon set

The first command moves the node to maintenance mode or makes the node unavailable, FOLLOWED by kubectl drain which will finally discard the pod from the node. After the drain command is a success you can perform maintenance.

Note: If you wish to perform maintenance on a single pod following two commands can be issued in order:

• kubectl get NODES: to list all the nodes
• kubectl drain <node name>: drain a particular node