Kubernetes Book 2 - principles of operation - Revision history

Pchero: /* Connecting Pods to Services */

2020-01-08T22:31:25Z

Connecting Pods to Services

← Older revision		Revision as of 22:31, 8 January 2020
Line 174:		Line 174:
	==== Connecting Pods to Services ====		==== Connecting Pods to Services ====
	Services use labels and a label selector to know which set of Pods to load-balance traffic to. The Service has a label selector that is a list of all the labels a Pod must possess in order for it to receive traffic from the Service.		Services use labels and a label selector to know which set of Pods to load-balance traffic to. The Service has a label selector that is a list of all the labels a Pod must possess in order for it to receive traffic from the Service.

			== Summary ==
			The masters are where the control plane components run. Under-the-hood, there's a combination of several system-services, including the API Server that exposes the public REST interface. Masters make all of the deployment and scheduling decsisions, and multi-master HA is important for production-grade environments.

			Nodes are where user applications run. Each node runs a service called the kubelet that registers the node with the cluster and communicates with the control plane. This includes receiving new work tasks and maintaining areporting channel. Nodes also have a container runtime and the kube-proxy service. The container runtime, such as Docker or containerd, is responsible for all container-related operations. The kube-proxy is responsible for networking on the node.

	[[category:kubernetes]]		[[category:kubernetes]]

Pchero: /* Pods and containers */

2020-01-08T22:24:31Z

Pods and containers

@@ Line 127: / Line 127: @@
 * Web containers supported by a helper container that pulls the latest content.
 * Containers with a tightly coupled log scraper.
 [[category:kubernetes]]

Pchero: /* Declarative model and desired state */

2020-01-07T23:50:37Z

Declarative model and desired state

← Older revision		Revision as of 23:50, 7 January 2020
Line 118:		Line 118:

	But if things go wrong, things change. When the current state of the cluster no longer matches the desired state, as soon as this happens, Kubernetes kicks into action and attempts to bring the two back into harmony.		But if things go wrong, things change. When the current state of the cluster no longer matches the desired state, as soon as this happens, Kubernetes kicks into action and attempts to bring the two back into harmony.

			== Pods ==
			Containers must always run inside of Pods.

			=== Pods and containers ===
			The simplest model is to run a single container per Pod. However, there are advanced use-cases that run multiple containers inside a single Pod. For example:
			* Service meshes.
			* Web containers supported by a helper container that pulls the latest content.
			* Containers with a tightly coupled log scraper.

	[[category:kubernetes]]		[[category:kubernetes]]

Pchero: /* Declarative model and desired state */

2020-01-07T23:42:59Z

Declarative model and desired state

← Older revision		Revision as of 23:42, 7 January 2020
Line 95:		Line 95:
	* Deployed via declarative manifest file.		* Deployed via declarative manifest file.

	=== Declarative model and desired state ===		== Declarative model and desired state ==
	The declarative model and the concept of desired state are at the very heart of Kubernetes.		The declarative model and the concept of desired state are at the very heart of Kubernetes.

Line 104:		Line 104:
	* Kubernetes implements the desired state on the cluster.		* Kubernetes implements the desired state on the cluster.
	* Kubernetes implements watch loops to make sure the current state of the application doesn't vary from the desired state.		* Kubernetes implements watch loops to make sure the current state of the application doesn't vary from the desired state.

			Manifest files are written in simple YAML, and they tell Kubernetes how we want an application to look. We call this is the desired state. It includes things such as; which image to use, how many replicas to have, which network ports to listen on, and how to perform updates.

			Once we've created the manifest, we POST it to the API server. The most common way of doing this is with the kubectl command-line-utility. This POSTs the manifest as a request to the control plane, usually port 443.

			Once the request is authenticated and authorized, Kubernetes inspects the manifest, indentifies which controller to send it to (e.g. the Deployments controller), and records the config in the cluster store as part of the cluster's overall desired state. Once this is done, the work gets scheduled on the cluster. This includes the hard work of pulling images, starting containers, building networks, and starting the application's processes.

			Finally, Kubernetes utilizes background reconciliation loops that constantly monitor the state of the cluster. If the current state of the cluster varies from the desired state, Kubernetes will perform whatever takes are necessary to reconcile the issue.

			It's important to understand that what we've described is the opposite of the traditional imperative model. The imperative model is where we issue long lists of platform-specific commands to build things.

			Not only is the declarative model a lot simpler than long lists of imperative commands, it also enables self-healing, scaling, and lends itself to version control and self-documentation. It does this by telling the cluster how things should look. If they stop looking like this, the cluster notices the discrepancy and does all of the hard work to reconcile the situation.

			But if things go wrong, things change. When the current state of the cluster no longer matches the desired state, as soon as this happens, Kubernetes kicks into action and attempts to bring the two back into harmony.

	[[category:kubernetes]]		[[category:kubernetes]]

Pchero: /* Packaging apps */

2020-01-07T23:32:29Z

Packaging apps

← Older revision		Revision as of 23:32, 7 January 2020
Line 95:		Line 95:
	* Deployed via declarative manifest file.		* Deployed via declarative manifest file.

			=== Declarative model and desired state ===
			The declarative model and the concept of desired state are at the very heart of Kubernetes.

			In Kubernetes, the declarative model works like this:
			* Declare the desired state of the application(microservice) in a manifest file.
			* POST it to the Kubernetes API server.
			* Kubernetes stores this in the cluster store as the application's desired state.
			* Kubernetes implements the desired state on the cluster.
			* Kubernetes implements watch loops to make sure the current state of the application doesn't vary from the desired state.

	[[category:kubernetes]]		[[category:kubernetes]]

Pchero: /* Kubernetes DNS */

2020-01-07T22:38:23Z

Kubernetes DNS

← Older revision		Revision as of 22:38, 7 January 2020
Line 83:		Line 83:

	=== Kubernetes DNS ===		=== Kubernetes DNS ===
			As well as the various control plane and node components, every Kubernetes cluster has an internal DNS service that is vital to operations.

			The cluster's DNS service has a static IP address that is hard-coded into every Pod on the cluster, meaning all containers and Pods know how to find it. Every new service is automatically registered with the cluster's DNS so that all components in the cluster can find every Service by name. Some other components that are registered with the cluster DNS are StatfulSets and the individual Pods that a StatefulSet manages.

			Cluster DNS is based on CoreDNS(https://coredns.io/).

			== Packaging apps ==
			For an application to run on a Kubernetes cluster it needs few things.
			* Packaged as a container.
			* Wrapped in a Pod.
			* Deployed via declarative manifest file.


	[[category:kubernetes]]		[[category:kubernetes]]

Pchero: /* Nodes */

2020-01-07T22:31:59Z

Nodes

@@ Line 60: / Line 60: @@
 * Execute new work assignments.
 * Report back to the control plane.
 [[category:kubernetes]]

Pchero: /* Control plane */

2020-01-07T20:52:10Z

Control plane

← Older revision		Revision as of 20:52, 7 January 2020
Line 51:		Line 51:

	==== Control plane ====		==== Control plane ====
			Kubernetes masters run all of the cluster's control plane services. Think of it as brains of the cluster where all the control and scheduling decisions are made. Behind the scenes, a master is made up of lots of small specialized control loops and services. These include the API server, the cluster store, the controller manager, and the scheduler.

			The API Server is the front-end into the control plane and the only component in the control plane that we interact with directly. By default, it exposes a RESTful endpoint on port 443.

			=== Nodes ===
			Nodes are the workers of a Kubernetes cluster. At a high0level they do three things:
			* Watch the API Server for new work assignments.
			* Execute new work assignments.
			* Report back to the control plane.

	[[category:kubernetes]]		[[category:kubernetes]]

Pchero: /* Scheduler */

2020-01-07T20:47:19Z

Scheduler

← Older revision		Revision as of 20:47, 7 January 2020
Line 47:		Line 47:
	It's not the job of the scheduler to perform the mechanics of running Pods, it just picks the nodes they will be scheduled on.		It's not the job of the scheduler to perform the mechanics of running Pods, it just picks the nodes they will be scheduled on.

			==== cloud controller manager ====
			If the cluster on a supported public cloud platform, cush as AWS, Azure, or GCP, the control plane will be running a cloud controller manager. Its job is to manage integrations with underlying cloud technologies and services such as instances, load-balancers and storage.

			==== Control plane ====

	[[category:kubernetes]]		[[category:kubernetes]]

Pchero: /* Scheduler */

2020-01-07T00:03:15Z

Scheduler

← Older revision		Revision as of 00:03, 7 January 2020
Line 40:		Line 40:
	==== Scheduler ====		==== Scheduler ====
	At a high level, the scheduler watches for new work tasks and assigns them to appropriate healthy nodes. Behind the scenes, it implements complex logic that filters out nodes incapable of running the Pod and then ranks the nodes that are capable. The ranking system itself is complex, but the node with the highest ranking point is eventually selected to run the Pod.		At a high level, the scheduler watches for new work tasks and assigns them to appropriate healthy nodes. Behind the scenes, it implements complex logic that filters out nodes incapable of running the Pod and then ranks the nodes that are capable. The ranking system itself is complex, but the node with the highest ranking point is eventually selected to run the Pod.

			When identifying nodes that are capable of running the Pod, the scheduler performs various predicate checks. These include; is the node tainted, are there any affinity or anti-affinity rules, is the Pod's network port available on the node, does the node have sufficient free resources etc. Any node incapable of running the Pod is ignored, and the remaining Pods are ranked according to things such as; does the node already have the required image, how much free resource does the node have, how many Pods is the node already running. Each criteria is worth points, and the node with the most points is selected to run the Pod.

			If the scheduler cannot find a suitable node, the Pod cannot be scheduled and goes into pending.

			It's not the job of the scheduler to perform the mechanics of running Pods, it just picks the nodes they will be scheduled on.


	[[category:kubernetes]]		[[category:kubernetes]]