Kubernetes and Cloud Native Associate CheatSheet PDF

Kubernetes and Cloud Native Associate Cheat Sheets These cheat sheets are provided for non-commercial purpose for personal study. Please do not redistribute or upload these cheat sheets elsewhere. Good luck on your exam! Kubernetes and Cloud Native A...

Kubernetes and Cloud Native Associate Cheat Sheets These cheat sheets are provided for non-commercial purpose for personal study. Please do not redistribute or upload these cheat sheets elsewhere. Good luck on your exam! Kubernetes and Cloud Native Associate CheatSheet Cloud-native describes an architectural approach that emphasizes application workloads that are *portable, modular and isolate, between different cloud deployment models and Cloud Service Providers (CSP) Some describe Cloud-Native being 4 key principles: 1. Microservices 2. Containerization 3. Continuous Delivery 4. DevOps A Cloud Service Provider (CSP): A collection of cloud services Strong application integration and synergies between services Utilizing metered billing Under a single unified API Cloud-Native is a workload, application or system, that is designed to run on cloud services, and “takes advantage of cloud offerings” Virtual Machines (VMs) do not make the best use of space. Apps are not isolated which could cause config conflicts, security problems or resource hogging. Containers allow you to run multiple apps which are virtually isolated from each other. Monolithic Architecture: One app which is responsible for everything, Functionality is tightly coupled Microservices Architecture Multiple apps which are each responsible for one thing Functionality is isolate and stateless Kubernetes is an open-source container orchestration system for automating deployment, scaling and management of containers. **The advantage of Kubernetes over Docker is the ability to run “container apps” distributed across multiple VMs A pod is a group of one more containers with shared storage, network resources and other shared settings. Cluster A logical grouping of all components within a cluster. Kubernetes and Cloud Native Associate CheatSheet Namespace A named logical grouping of Kubernetes components within a cluster. Used to Isolate different workloads on the same cluster Node A virtual machine or underlying server. There are two types of nodes: Control Plane and Worker nodes. Worker nodes is where your application or workloads run. Control Plane nodes manage worker nodes. Pod The smallest unit in K8s. It is an abstraction over a container. Generally, defines an application workload Service A static IP address and DNS name for a set of pods (persists an address even if a pod dies) and a load balancer Ingress Translates HTTP/S rules to point to services API Server The API Server allows users to interact with K8s components using the KubeCTL or by sending HTTP requests. Kubelet Kubelet is an agent installed on all nodes. Kublelet allows users to interact with node via the API Server and KubeCTL KubeCTL A command line interface (CLI) that allows users to interact with the cluster and components via the API Server Cloud Controller Manager Allows you to link a Cloud Service Provider (CSP) eg. AWS, Azure GCP to leverage cloud services. Controller Manager A control loop that watches the state of the cluster and will change the current state back to desired state. Scheduler Determines where to place pods on nodes. Places them in a scheduling a queue Kubernetes and Cloud Native Associate CheatSheet Kube Proxy An application on worker nodes that provides routing and filtering rules for ingress (incoming) traffic to pods. Network Policy Acts as a virtual firewall as the namespace-level or pod-level ConfigMap allows you to decouple environment-specific configuration from your container images, so that your applications are easily portable. Used to store non- confidential data in key-value pair Secret small amount of sensitive data such as a password, a token, or a key Volumes mounting storage eg. locally on the node, or remote to cloud storage StatefulSet provides guarantees about the ordering and uniqueness of these Pods Think of databases where you have to determine read and write order or limit the amount of containers StatefulSets are hard, when you can host your db externally from K8s cluster ReplicaSets Maintain a stable set of replica pods running at a given time. Can provide a guarantee of availability. Deployment Is a blueprint for a pod (think Launch Template) A Manifest file is a generalized name for any Kubernetes Configuration File that define the configuration of various K8s components. These are all Manifest files with specific purposes: Deployment File PodSpec File Network Policy File Kubernetes and Cloud Native Associate CheatSheet Manifest Files can be written in either: YAML JSON A manifest can contain multiple K8s component definitions/configurations. In YAML you can see the three hyphens --- is used to defined multiple components. kubectl apply command is generally used to deploy manifest files Resource Configuration file is sometimes used to describe multiple resources in a manifest. Control Plane Node (Formally known as Master Node) Manages processes like scheduling, restarting nodes… API Server – the backbone of communication Scheduler – determines where to start a pod on worker node Controller Manager – detect state changes (if pod crashes, restart it) etcd – A Key/Value Store that stores the state of the cluster Kubelet – Allows user to interact with the node via KubeCTL Worker Node Does the work, running your app in pods and containers… The worker node runs: Kubelet Kube Proxy Container Runtime Pods and Containers Pods are the smallest unit in Kubernetes. Pods abstract away the container layer so you can directly interact with the Kubernetes Layer. A Pod is intended to run one application in multiple containers Database Pod, Job Pod, Frontend App Pod, Backend App Pod You can run multiple apps in a pod but those containers will tightly dependent. Kubernetes and Cloud Native Associate CheatSheet Each Pod gets it own private IP address Containers will run on different ports Containers can talk to each other via localhost Each Pod can have a shared storage volume attached. All containers will share the same volume When the last remaining container dies (maybe crashes) in a pod so does the pod When a replacement pod is created, the pod will have an IP address will be assigned. IP addresses are Ephemeral, (temporary) for pods, they don’t by default persist. The API server exposes an HTTP API that lets end users, different parts of your cluster, and external components communicate with one another. The Kubernetes API lets you query and manipulate the state of API objects in Kubernetes (for example: Pods, Namespaces, ConfigMaps, and Events). The main implementation of a Kubernetes API server is kube-apiserver. kube-apiserver is designed to scale horizontally—that is, it scales by deploying more instances. Everything has to go through the API Server. You can interact with the API Server in three ways: UI* API CLI KubeCTL A Deployment provides declarative updates for Pods and ReplicaSets. A Deployment define the desired state of ReplicaSets and Pods. A Deployment Controller changes the actual state to the desired state at a controlled rate. The default Deployment Controller can be swapped out for other deployments tools eg: Argo CD, Flux, Jenkin X….. A deployment will create and manage a ReplicaSet. A ReplicaSet will manage replicas of pod. ReplicaSet is a way to maintain a desired amount of redundant pods (replicas) to provide a guarantee of availability. Kubernetes and Cloud Native Associate CheatSheet Stateless - ReplicaSets Every request does not care (forgets) about previous or current state Stateful - StatefulSets Every request relies on state data (remembers). All databases are stateful Stateful Sets are used when you need traffic to be sent to a specific pods. Stateful Set will always have: a unique and predictable name and address ordinal index number assigned each pod a persistent volume attached, with a persistent link from pod to the storage If a pod is rescheduled the original Persistent Volume (PV) will be mounted to ensure data integrity and consistency. Stateful Set pods will always start in the same order, and terminate in reverse order DNS Hostname for Writes Writes will be directed to the Main pod by its DNS Hostname which is identified by a Headless Service ClusterIP for Reads For read traffic it can be distributed to all reading pods using a ClusterIP Service Headless Service The headless service is a Service with ClusterIP set to none. PVC and PV Each pod has its own volume. A Persistent Volume Claim can dynamically reference a Persistent Volume. A Namespace is a way to logically isolate resources within a Kubernetes Cluster. Namespaces can be organized based on project, department or any user-defined grouping. To view all namespaces: kubectl get namespace You can create your own namespaces: kubectl create namespace production Kubernetes and Cloud Native Associate CheatSheet Kubernetes starts 4 initial namespaces: 1. default The default namespace where all our pods and services run unless a namespace is specified. 2. kube-public For resources that are publicly visible and readable. 3. kube-system The system namespace that stores objects created by the Kubernetes System. Engineers deploying applications are not supposed to touch this namespace. 4. kube-node-lease Holds lease objects associated with each node. Used to detect node failures by sending heartbeats Names of resources need to be unique within a namespace, but not across namespaces. Namespace-based scoping is applicable only for namespaced objects eg. Deployments, Services But not for cluster-wide objects eg. StorageClass, Nodes, PersistentVolumes Single-Namespace Objects ConfigMaps and Secrets can’t be shared across namespaces Multi-Namespace Objects A Service and Pods can belong to multiple namespaces Cluster-Wide Objects Volumes and Nodes cannot be bound to namespace since they are global In-Tree: Plugins, components or functionality that are provided by default and/or reside in the main repository. Think of In-Tree as Internal plugins Out-of-Tree: Plugins, components or functionality that must be installed manually, and extends or replaces the default behaviour. Think of Out-of-Tree as External plugins Endpoints track the IP Addresses of the pods assigned to a Kubernetes Service. When a service selector matches a pod label, The pod IP Address is added to the pool of endpoints Pods expose themselves to services via endpoints. To see a list of endpoints: kubectl get endpoints Kubernetes and Cloud Native Associate CheatSheet A background job is a one-off task that is used to run a piece of code. A Job creates one or more Pods and will continue to retry execution of the Pods until a specified number of them successfully terminate. A CronJob is a job that execute based on a repeating schedule. Kubernetes Dashboard is an open-source application you can deploy to your cluster to provide a UI to view K8s components Selectors are a way of selecting one or more Kubernetes Objects. In Kubernetes there are 3 types of selectors: 1. Label Selector Select K8s objects based on the applied label 2. Field Selector Select K8s objects based on object data eg. Metadata, Status 3. Node Selector Select nodes for very specific pod placement Label Selectors define labels as a key value pair under metadata in a Manifest file Kubectl get pods –show-labels