A load balancer provides a standard way to distribute network traffic among different backend services, thus maximizing scalability. Depending on the working environment, there can be two types of load balancer – Internal or External.
The Internal Load Balancer can automatically balance the load and allocate the required configuration to the pods. On the other hand, the External Load Balancer guides the external load traffic to the backend pods. In Kubernetes, the two load balancing methods operate through the kube-proxy feature.
A Cloud Controller Manager (CCM) is a daemon that allows for embedding cloud-specific control loops. It abstracts the cloud-specific vendor code from the core Kubernetes code. It also helps manage communication with underlying cloud services. Its design is based on the plugin mechanism, meaning that cloud vendors integrate their code with the CCM using plugins.
* Kubernetes master controls the nodes, and nodes have the containers in it.
* The individual containers are contained inside the pods and each pod can contain various numbers of containers based on the requirements & configuration.
* So when pods have to be deployed, they have to be deployed either using the interface or CLI (command line interface).
* These pods are scheduled on the nodes and on the basis of resource requirements, the pods are allocated to these nodes.
* Kube-apiserver (which is master node services) ensures that there is a communication between the Kubernetes node and master components.
The users need to understand the application's performance and resource utilization at all the different abstraction layers. Kubernetes create abstraction at different levels like containers, pods, services, and whole cluster to monitor them well. This process is called container resource monitoring.
Following is a list of some container resource monitoring tools:
Heapster: It is used to gather data and events from the containers and pods within the cluster.
InfluxDB: It is used along with heapster for visualizing data within the Kubernetes environment.
Grafana: It is a time-series database used to store the data captured by all heapster pods.
CAdvisor: It is a built-in tool in a kubelet that automatically discovers all the active containers and monitors them.
Prometheus: It specifies a project of CNCF, which provides powerful querying, alerting, and visualization capabilities.
The full form of PVC is Persistent Volume Claim. It is storage requested by Kubernetes for pods. In PVC, it doesn't require knowing the underlying provisioning. You can create the claim in the same namespace where the pod is created.
There are the following ways to provide API-Security on Kubernetes:
<> Using correct auth mode with API server authentication mode.
<> Making kubeless that protects its API via authorization-mode.
<> Ensuring the kube-dashboard uses a restrictive RBAC (Role-Based Access Control) policy.
K8s (K-eight characters-S) is a term used for Kubernetes. It is an open-source orchestration framework used for the containerized applications.
No, all the nodes don't occupy the same size in the cluster. The Kubernetes components, such as kubelet, take up resources on your nodes, and you still need more capacity for the node to do any task. In the larger cluster, it is always preferred to create a mix of different instance sizes. So, the Kubernetes can easily schedule the pods that require a lot of memory with intensive compute workloads on large nodes, and smaller nodes can handle smaller pods.
Many on-premises environments are remodeled to enable Kubernetes integration. Integrating storage, servers, and networking into a smoothly running environment requires top skills. For Kubernetes, deciding the right storage and networking equipment is crucial as it facilitates interaction with resources for storage, load balancers, etc. A critical part of Kubernetes’ value proposition is the ability to automate storage and the networking components.
See the differences between the Equity-Based Selectors and the Selector-Based Selectors:
<> Equity-Based Selectors: Equity-Based Selectors are the type of selector that allows filtering by label key and values. This selector will only look for the pods, which will have the same phrase as that of the label. For example, if your label key says app=nginx, then, with this selector, you can only look for those pods with label app equal to Nginx.
<> Selector-Based Selectors: The Selector-Based Selectors are used to allow filtering keys according to a set of values. You can say that these selectors look for pods whose label has been mentioned in the set. For example, if your label key says app in (Nginx, NPS, Apache). With this selector, if your app is equal to any of Nginx, NPS, or Apache, then the selector will take it as a true result.
We can use the Minikube tool to run Kubernetes locally. It runs a single-node cluster in a VM (virtual machine) on the computer. So, it is best for users who have just started learning Kubernetes.
Kubernetes Master assigns a new IP address.
We can set a static IP for Kubernetes load balancer by changing the DNS records whenever Kubernetes Master assigns a new IP address.
The primary data store of Kubernetes is etcd, which is responsible for storing all Kubernetes cluster data.
The process of load balancing will let us expose services. There are two types of load balancing when it comes to Kubernetes:
<> Internal load balancing: This is used for balancing the loads automatically and allocating the pods with the required configuration.
<> External load balancing: This directs the traffic from the external loads to the backend pods.
Following is the difference between a daemon set, a deployment, and a replication controller:
Daemon set: A daemon set is used to ensure that all nodes you have selected are running precisely one copy of a pod.
Deployment: A deployment is a resource object in Kubernetes. It is used to provide declarative updates to applications. It also manages the scheduling and lifecycle of pods. It offers many key features for managing pods, such as pod health checks, rolling updates of pods, the ability to roll back and quickly scale pods horizontally.
Replication Controller: The replication controller is used to specify how many exact copies of a pod should be running in a cluster. It differs from a deployment in that it does not offer pod health checks, and the rolling update process is not as robust.
Ingress network is a set of rules which allow permission for connections into the Kubernetes cluster.
The difference is mainly in the selectors used for pod replication. A replica set uses set-based selectors, and replication controllers use equity-based selectors.
The company can do well with something that offers scale-out capability, agility, and the DevOps practice to the cloud-based applications. Kubernetes, in this situation, can enable the customization of the scheduling architecture and support multiple container formats. This results in greater efficiency as well as provides support for various container networking solutions and container storage.
The node port service is a way to attain external traffic to your service. It is used to open a particular port on all nodes and forward the network traffic to this port.
The Google Container Engine is an open-source management platform tailor-made for Docker containers and clusters. It is used to provide support for the clusters that run in Google public cloud services.
A cluster of containers is nothing but a set of machine elements or nodes. Clusters specify specific routes so that the containers running on the nodes can communicate with each other. In Kubernetes, the container engine also provides hosting for the API server.
Sematext Docker agent is a log collection agent with events and metrics. It runs as a small container in each Docker host. These agents gather metrics, events, and logs for all cluster nodes and containers.
Secrets are sensitive information like login credentials of the user. They are objects in Kubernetes that stores sensitive information like username and password after performing encryption.
A persistent volume is a storage unit that is controlled by the administrator. It is used to manage an individual pod in a cluster.
Kube-apiserver is an API server of Kubernetes that is used to configure and validate API objects, which include services, controllers, etc. It provides the frontend to the cluster’s shared region using which components interact with each other.
A Replica set is used to keep replica pods stable. It enables us to specify the available number of identical pods. This can be considered a replacement for the replication .controller.
Daemon sets are used because:
* It enables to runs storage platforms like ceph and glusterd on each node.
* Daemon sets run the logs collection on every node such as filebeat or fluentd.
* It performs node monitoring on each and every node.
You can separate resources by using namespaces. These can be created either using kubectl or applying a YAML file. After you have created the namespace you can then place resources, or create new resources, within that namespace. Some people think of namespaces in Kubernetes like a virtual cluster in your actual Kubernetes cluster.
With a traditional server setup, application logs are written to a file and then viewed either on each server or collected by a logging agent and sent to a centralized location. In Kubernetes, however, writing logs to disk from a pod is discouraged since you would then have to manage log files for pods. The better way is to have your application output logs to stdout and stderr. The kubelet on each node collects stdout and stderr on the running pods and then combines them into a log file managed by Kubernetes. Then you can use different kubectl commands to view the logs.
A sidecar container is a utility container that is used to extend support for a main container in a Pod. Sidecar containers can be paired with one or more main containers, and they enhance the functionality of those main containers. An example would be using a sidecar container specifically to process system logs or for monitoring.
The company should move to a cloud environment and implement a microservice architecture for implementing Docker containers. Once the base framework is set up, Kubernetes can be used for the autonomous development of applications and the quick delivery of the same by the team.
Objects that are used in Kubernetes are: 1) Pods, 2) Replication sets and controllers, 3) Jobs and cron jobs, 4) Daemon sets, 5) Distinctive identities, 6) Deployments, 7) and Stateful sets.
The tools for container orchestration are 1) Docker swarm, 2) Apache Mesos, and 3) Kubernetes.
Docker is an open-source platform used to handle software development. It is mainly used to package the settings and dependencies that the software/application needs to run into a container, which allows for portability and several other advantages. On the other hand, Kubernetes is used to allow the manual linking and orchestration of several containers, running on multiple hosts that have been created using Docker.
Minikube is a software that helps the user to run Kubernetes. It runs on the single nodes that are inside VM on your computer. This tool is also used by programmers who are developing an application using Kubernetes.
Tools that are used for container monitoring are:
* Heapster
* cAdvisor
* Prometheus
* InfluxDB
* Grafana
Kubernetes can be run locally using the Minikube tool. It runs a single-node cluster in a VM (virtual machine) on the computer. Therefore, it offers the ideal way for users who have just started learning Kubernetes.
Multiple Kubernetes clusters can be managed as a single cluster with the help of federated clusters. So, you can create multiple Kubernetes clusters within a data center/cloud and use federation to control/manage them all at one place.
As for users, it is really important to understand the performance of the application and resource utilization at all the different abstraction layer, Kubernetes factored the management of the cluster by creating abstraction at different levels like container, pods, services and whole cluster. Now, each level can be monitored and this is nothing but Container resource monitoring.
By default, POD should be able to reach the external network but vice-versa we need to make some changes. Following options are available to connect with POD from the outer world.
Nodeport (it will expose one port on each node to communicate with it)
Load balancers (L4 layer of TCP/IP protocol)
Ingress (L7 layer of TCP/IP Protocol)
Another method is to use Kube-proxy which can expose a service with only cluster IP on the local system port.
$ kubectl proxy --port=8080 $ http://localhost:8080/api/v1/proxy/namespaces//services/:/
Various methods are available to achieve it.
<> nodeName: specify the name of a node in POD spec configuration, it will try to run the POD on a specific node.
<> nodeSelector: Assign a specific label to the node which has special resources and use the same label in POD spec so that POD will run only on that node.
<> nodeaffinities: required DuringSchedulingIgnoredDuringExecution, preferredDuringSchedulingIgnoredDuringExecution are hard and soft requirements for running the POD on specific nodes. This will be replacing nodeSelector in the future. It depends on the node labels.
Ingress network is a collection of rules that acts as an entry point to the Kubernetes cluster. This allows inbound connections, which can be configured to give services externally through reachable URLs, load balance traffic, or by offering name-based virtual hosting. So, Ingress is an API object that manages external access to the services in a cluster, usually by HTTP and is the most powerful way of exposing service.
A load balancer is one of the most common and standard ways of exposing service. There are two types of load balancer used based on the working environment i.e. either the Internal Load Balancer or the External Load Balancer. The Internal Load Balancer automatically balances load and allocates the pods with the required configuration whereas the External Load Balancer directs the traffic from the external load to the backend pods.
Etcd is written in Go programming language and is a distributed key-value store used for coordinating distributed work. So, Etcd stores the configuration data of the Kubernetes cluster, representing the state of the cluster at any given point in time.
In K8’s scheduler is responsible to spawn pods into nodes. There are many factors that can lead to unstartable POD. The most common one is running out of resources, use the commands like kubectl describe <POD> -n <Namespace> to see the reason why POD is not started. Also, keep an eye on kubectl to get events to see all events coming from the cluster.