{"id":11611,"date":"2019-03-11T14:33:13","date_gmt":"2019-03-11T13:33:13","guid":{"rendered":"https:\/\/www.scaleuptech.com\/de\/?p=5597"},"modified":"2023-05-12T09:45:36","modified_gmt":"2023-05-12T07:45:36","slug":"kubernetes-architecture","status":"publish","type":"post","link":"https:\/\/www.scaleuptech.com\/en\/blog\/kubernetes-architecture\/","title":{"rendered":"The architecture of Kubernetes"},"content":{"rendered":"<p>Kubernetes is software that enables the orchestration and monitoring of microservice containers at the cluster, service, pod, and container levels. As shown in our <a href=\"https:\/\/www.scaleuptech.com\/de\/blog\/kubernetes-einfuehrung\/\">Introductory article<\/a> Kubernetes (abbreviated as \"K8s\") connects various servers to form a cluster and orchestrates resources and workloads via it. In this article, we will now take a closer look at the structure and components of a Kubernetes cluster. Our article is divided into the sections:<\/p>\n<ul>\n<li><a href=\"#master\"><strong>Master Nodes \/ Control Plane<\/strong><\/a><\/li>\n<li><a href=\"#worker\"><strong>Worker Nodes<\/strong><\/a><\/li>\n<li><a href=\"#addons\"><strong>Addons<\/strong><\/a><\/li>\n<li><a href=\"#deployment\"><strong>Kubernetes Cluster Deployment<\/strong><\/a><\/li>\n<li><a href=\"#fazit\"><strong>Conclusion<\/strong><\/a><\/li>\n<\/ul>\n<p>The main components of a K8s cluster are at least one <strong>Cluster Master (Control Plane)<\/strong> and several working machines, which are used as <strong>Nodes<\/strong> (engl. \"node\"). Nodes can be located on a physical or a virtual machine. Each node contains all the services needed to control pods.<\/p>\n<p>The brain of the cluster resides in the Control Plane, where all cluster orchestration tasks are managed.<\/p>\n<p><a href=\"https:\/\/www.scaleuptech.com\/de\/wp-content\/uploads\/2019\/03\/kubernetes_archiketktur_blog.jpg\"><img decoding=\"async\" class=\"aligncenter wp-image-5455\" src=\"https:\/\/www.scaleuptech.com\/de\/wp-content\/uploads\/2019\/03\/kubernetes_archiketktur_blog.jpg\" alt=\"Kubernetes Cluster Components\" width=\"5600\" height=\"auto\"><\/a><\/p>\n<p>The Control Plane in turn consists of several components, the Master Nodes:<\/p>\n<h2 id=\"master\">Master Nodes<\/h2>\n<p><strong>Kube API Server<\/strong><br \/>\nIs the central communication node of the cluster. As a front-end server, it provides REST endpoints for interactions with other cluster components.<\/p>\n<p>All interactions with the cluster are executed via Kubernetes API calls. Kubernetes API calls can be executed directly via HTTPs or indirectly via commands in the Kubernetes command line client (kubectl) as well as the Kuberndetes UI (Dashboard).<\/p>\n<p><strong>Etcd<\/strong><br \/>\nEtcd is the database backend and contains information about the cluster configuration, i.e. which nodes, resources are available within the cluster. The cluster state is also stored in Etcd.<\/p>\n<p><strong>Kube-Scheduler<\/strong><br \/>\nObserves newly created pods that do not have a node assigned and selects a node on which to run them. Factors to consider include individual and collective resource requirements, hardware \/ software \/ policy constraints, data location, and dependencies between workloads and deadlines.<\/p>\n<p><strong>Kube Controller Manager<\/strong><br \/>\nThe Kube Controller Manager implements the main control loops. It manages resources and deployments, monitors differences between the current and desired cluster states, and makes the necessary changes to achieve the desired state. Actually, each controller is a separate process. However, to reduce complexity, they are all combined into a single binary and executed in a single process.<\/p>\n<h3>Controllers include:<\/h3>\n<p><em>Node Controller:<\/em> Responsible for detecting and responding when nodes fail.<br \/>\n<em>Replication Controller:<\/em> Responsible for maintaining the correct number of pods for each replication controller object in the system.<br \/>\n<em>Endpoint Controller:<\/em> Populates the Endpoint object that connects Services &amp; Pods.<br \/>\n<em>Service Account and Token Controller:<\/em> Create default accounts and API access tokens for new namespaces<\/p>\n<p><strong>Cloud Controller Manager<\/strong><br \/>\nThe cloud controller manager is connected to the cloud provider (in cloud-based Kubernetes clusters) and checks whether unresponsive nodes have been deleted by the cloud provider (via node controller), organizes routing via so-called route controllers that manage resources such as load balancers (service controllers) and disk storage (volume controllers).<\/p>\n<h2 id=\"worker\">Worker Nodes<\/h2>\n<p>Worker node components are executed on each node. They \"maintain\" running pods, so to speak, and determine the Kubernetes runtime environment.<\/p>\n<p><strong>Kubelet<\/strong><br \/>\nAn agent that runs on each node in the cluster. A Kubelet launches the pods using the available container engine (Docker, rkt, etc.) and periodically checks \/ reports pod status based on specific PodSpecs.<\/p>\n<p><strong>Kube proxy<\/strong><br \/>\nKube proxy checks maintenance of network rules on the host and performs connection forwarding at service endpoints.<\/p>\n<p><strong>Container Runtime<\/strong><br \/>\nOperates the Contianer engine. Kubernetes supports multiple container engines: Docker, containerd, cri-o, rktlet, and any implementation of the Kubernetes CRI (Container Runtime Interface).<\/p>\n<p>Containers therefore do not need their own guest operating system, which makes them particularly efficient and time-saving. Instead, each container gets its own thin layer of operating system functions.<\/p>\n<h2 id=\"addons\">Addons<\/h2>\n<p>Kubernetes components are further extended by addons. Addons are pods and services that provide a respective cluster feature. Addons can be managed at different deployment levels. The Kubernetes addons listed here are only a selection made based on their relevance:<\/p>\n<p><strong>Core DNS<\/strong><br \/>\nCore DNS is an internal cluster DNS server. It automatically configures registers for Kubernetes namespaces, services, and pods. This makes it easier for pods to find other services in the cluster.<\/p>\n<p><strong>Web UI<\/strong><br \/>\nWeb UI (dashboard) is a common, web-based user interface for Kubernetes clusters. The Kubernetes dashboard provides functions for deploying, monitoring, and troubleshooting applications running in the cluster.<\/p>\n<p><strong>Monitoring tools for container resource management<br \/>\n<\/strong><br \/>\nContainer Resource Monitoring records generic time-series measurement data about containers in a central database and provides a user interface for browsing this data at the container, pod, service, and cluster levels. This data is important for reliable operation and automatic scaling of clusters.<\/p>\n<p>Several monitoring solutions are available in Kubernetes for application monitoring. By default, two separate pipelines are applicable for newly created clusters to collect monitoring statistics: The \"Resource Metrics Pipeline\" (Kubelet, cAdvisor) and \"Full Metrics Pipeline\" (captures significantly more metrics, e.g. Prometheus).<\/p>\n<p><strong>Cluster level logging<br \/>\n<\/strong>Stores container log files in a central log store and provides a search\/browse interface.<\/p>\n<p>It makes sense to store logs independently of containers and nodes at the cluster level, since this information would be lost if a container or node crashed or a pod was deleted.<\/p>\n<p>For the <strong>Cluster level logging<\/strong> a separate backend is required to store, analyze, and query logs. Kubernetes does not provide a native storage solution for log data. However, there are many existing logging solutions that can be integrated into the Kubernetes cluster. Possible solutions include:<\/p>\n<p><em>Node-Level Logging Agents<\/em>: Runs on every node,<\/p>\n<p><em>dedicated sidecar container for logging&nbsp;<\/em>to log in to an application pod or<\/p>\n<p><em>Automatic moving of application log files to the backend<\/em>.<\/p>\n<p>Further information on the logging topic can be found here: https:\/\/kubernetes.io\/docs\/concepts\/cluster-administration\/logging\/<\/p>\n<h2 id=\"deployment\">Kubernetes Cluster Deployment<\/h2>\n<p>A Kubernetes cluster deployment may require multiple master nodes and a separate etcd cluster to ensure high availability. Kubernetes also uses an overlay network to provide networking capabilities similar to a virtual machine-based environment. This software-defined network (SDN) enables communication between containers across the cluster and provides unique IP addresses for each container.<\/p>\n<h2 id=\"fazit\">Conclusion<\/h2>\n<p>In principle, Kubernetes consists of a set of independent control processes that can be put together again and again to form new workflows, just like in a Lego construction kit. The control processes continuously monitor and change the current state of the container landscape and convert it to the target state. Orchestration thus becomes practically independent and a central control instance is no longer necessary. Applications can be developed, operated and scaled faster and more easily thanks to automated processes.<\/p>\n<p><em>If your interest in this technology is piqued, you are welcome to contact us at Kubernetes <a href=\"https:\/\/www.scaleuptech.com\/de\/cloud-hosting\/managed-kubernetes\/#kostenlos-testen\">test<\/a>, a <a href=\"https:\/\/www.scaleuptech.com\/de\/cloud-hosting\/openstack-workshops\/\">of our workshops<\/a> visit or talk to us about your individual requirements.<\/em><\/p>\n<h6>Sources:<br \/>\nArundel, J., Domingus, J. (2019), <em>Cloud Native DevOps With Kubernetes<\/em>. Retrieved from https:\/\/www.nginx.com\/resources\/library\/cloud-native-devops-with-kubernetes\/<br \/>\nhttps:\/\/kubernetes.io\/docs\/concepts\/overview\/components\/<br \/>\nhttps:\/\/kubernetes.io\/docs\/tasks\/debug-application-cluster\/resource-usage-monitoring\/<\/h6>","protected":false},"excerpt":{"rendered":"<p>Kubernetes is software that enables the orchestration and monitoring of microservice containers at the cluster, service, pod, and container levels.<\/p>","protected":false},"author":2,"featured_media":5628,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1,18,10],"tags":[185,186,187,188,189,11,190,183],"class_list":["post-11611","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-alle-beitraege","category-cloud-computing","category-kubernetes","tag-addons","tag-architektur","tag-cluster","tag-control-plane","tag-einfuehrung","tag-kubernetes","tag-kubernetes-deployment","tag-orchestrierung"],"_links":{"self":[{"href":"https:\/\/www.scaleuptech.com\/en\/wp-json\/wp\/v2\/posts\/11611","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.scaleuptech.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.scaleuptech.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.scaleuptech.com\/en\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.scaleuptech.com\/en\/wp-json\/wp\/v2\/comments?post=11611"}],"version-history":[{"count":0,"href":"https:\/\/www.scaleuptech.com\/en\/wp-json\/wp\/v2\/posts\/11611\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.scaleuptech.com\/en\/wp-json\/"}],"wp:attachment":[{"href":"https:\/\/www.scaleuptech.com\/en\/wp-json\/wp\/v2\/media?parent=11611"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.scaleuptech.com\/en\/wp-json\/wp\/v2\/categories?post=11611"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.scaleuptech.com\/en\/wp-json\/wp\/v2\/tags?post=11611"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}