Learn Kubernetes

pre-requisites Includes configuring pre-requisites to install kubeadm step 01) Enable following ports and protcols step 02) sysctl params required by setup, params persist across reboots Apply sysctl params without reboot Verify that the brnetfilter, overlay modules are loaded Verify that the net.bridge.bridge-nf-call-iptables, net.bridge.bridge-nf-call-ip6tables, and net.ipv4.ipforward system variables are set to 1 in sysctl config We are selecting option 2 here using apt-get install via package manager : https://docs.docker.com/engine/install/ubuntu/ Remove old versions setup docker repository Add Docker's official GPG key: Add the repository to Apt sources: Install package we are only interested in containerd check and install cgroup driver for container runtime and kubelet to integrate with control groups for getting resources from the instance. ! both kubelet and containerd should use same cgroup driver find if the instances are systemd instances Configure cgroup driver copy following content to install cgroup drivers : Tip : delete all the content inside that file using command mode :%d and copy following content. save above config and run following Use Kubeadm to install a basic cluster " Install kubeadm, kubectl and kubelet on all nodes To see the new version labels in master node control plane NOTE if your using containerd install if your using docker if your using crio Manage a Highly-Available Kubernetes Cluster Kubernetes utilizes a microservices architecture, with all requests initially directed to a central API server microservice, supported by various other components. For high availability in a Kubernetes cluster, it's common to add more control plane nodes, each hosting additional instances of the API Server, Scheduler, and Controller Manager. If etcd is part of the control plane nodes, additional members will also be added to the etcd cluster. In a setup with multiple control plane nodes, several API Servers operate concurrently in a highly available configuration, all interfacing with the same etcd cluster. This setup ensures that client requests are processed consistently using the shared data. Communication with the API Servers is managed through a single endpoint, such as an external load balancer, which directs traffic to all API Server instances. Other control plane components like the Scheduler and Controller Manager function on a failover basis. Among the instances of these microservices, one is elected as the active leader to handle all critical tasks. The other instances remain passive and only become active if the current leader fails. High availability in the control plane is crucial but only part of achieving overall high availability in Kubernetes. For high availability of workloads, additional worker nodes might be necessary, and workloads should be configured to deploy multiple replicas that coordinate with each other. Kubeadm simplifies the process of expanding your Kubernetes cluster by adding more nodes. To join a new node to the cluster, you first need to generate a join command that includes the API server's address, a unique join token, and the SHA hash of the cluster’s certificate authority (CA) certificate. This command can be generated using the following command on an existing control plane node: master node restart containerd set containerd config worker node check master node Perform Version Upgrades on a Kubernetes Cluster using kubeadm" Perform Version Upgrades on a Kubernetes Cluster using kubeadm Upgrading a Kubernetes cluster involves updating its core components, which include the Kubernetes API Server, Scheduler, Controller Manager, etcd, and Kubelets. Kubeadm simplifies this process by managing the container versions of these control plane components. Additional tasks such as renewing certificates and updating kubelet configurations are also handled by Kubeadm, utilizing the kubeadm upgrade commands. When planning an upgrade, you must first decide on the target version. Updates to major APIs typically accompany minor version releases (e.g., from 1.25 to 1.26), while patch releases (e.g., 1.26.0 to 1.26.1) focus on fixes and security enhancements. It's important to note that Kubeadm supports upgrading only one minor version at a time. For instance, to upgrade from version 1.24 to 1.26, you must first upgrade to 1.25 and then proceed to 1.26. The version of the kubeadm tool itself dictates the highest Kubernetes version to which you can upgrade (e.g., kubeadm 1.25.0 cannot upgrade a cluster to Kubernetes 1.26.0). The upgrade process of the control-plane node involves several key steps: 1. Obtain the latest Kubernetes binaries. 2. Install the newer kubeadm version. 3. Use kubeadm upgrade plan to review and acquire the latest versions of the control plane components. 4. Execute the upgrade. 5. Update the kubelet and kubectl installations on the node. During the upgrade, it may be necessary to drain the node of reschedulable workloads using kubectl drain, ensuring to uncordon the node afterward with kubectl uncordon to allow workloads to return. Here's how to upgrade a Kubernetes control plane node from v1.25.0 to v1.26.0 on Ubuntu 20.04: Begin by updating the apt repository. check upgrade plan use upgrade command update to desire version etcd Backup and Restore etcd Backup and Restore Etcd maintains the active state of the cluster, with the API Servers interacting by writing to and retrieving data from it. Each transaction executed in etcd is logged in a Write-Ahead Log (WAL) file specific to each cluster member. These files, which are updated by transactions initiated by the cluster's "leader," are periodically condensed into snapshots to conserve space. This snapshotting process is an integral part of etcd's routine operations, and snapshots can also be manually triggered using the etcdctl tool with the snapshot save command. install etcd find server.crt take backup check snapshot Basics of Pod 0. What is POD learn via Kubectl Explain 1. Create a Pod from Nginx Image 2. Create a Pod and Expose a Port 3. Output the Manifest File alternative 4. Delete PODS List the Worker Node Create a new POD from Nginx Image List the PODS that are currently running. Connect inside the POD You can come out of the POD with CTRL+D Delete the POD pod-expose-port.yaml Finding a Pod’s Cluster IP Finding a Service’s IP We can find a Service IP using kubectl as well. In this case we will list all services in all namespaces: Labels and Selectors Labels - Maps (aka Dictionaries) Labels are attached to Kubernetes objects and are simple key: value pairs or maps(dictionary). Labels are used to store identifying information about a thing that you might need to query against. Labels are used for organization and selection of subsets of objects, and can be added to objects at creation time and/or modified at any time during cluster operations. You will see them on pods, replication controllers, replica sets, services, and so on. Selectors - Maps (aka Dictionaries) Labels are queryable — which makes them especially useful in organizing things A label selector is a string that identifies which labels you are trying to match You will see them on pods, replication controllers, replica sets, services, and so on. sh tier = frontend tier != frontend environment in (production, qa) Annotations Annotations are bits of useful information you might want to store about a pod (or cluster, node, etc.) that you will not have to query against. They are also key/value pairs and have the same rules as labels. Examples of things you might put there are the pager contact, the build date, or a pointer to more information someplace else—like a URL. Method-1: Assign labels while creating a new object Assign a new label to existing pod runtime as a patch will assign new label "tier: frontend" to our existing Pods from the deployment label-nginx-example Next patch the deployment with this YAML file Method-3: Assign a new label to existing deployments runtime using kubectl I have another deployment nginx-deploy on my cluster, so I will assign label tier: backend to this deployment: Using labels to list resource objects Using Selector to list resource objects I will create another deployment here with two labels and use one of the label as selector: Removing labels Create POD with Command and Arguments kubectl explain pods.spec.containers.command Create POD without any commands or arguments. args in Kubernetes overrides CMD in the original docker image. command in Kubernetes overrides ENTRYPOINT in the original docker image. commands.yaml Create POD with Command Modify the POD contents to the following one. Create POD with Command and Arguments Modify the YAML file contents to the following one. Create POD with Arguments Modify the YAML file contents to the following one. Use Cases for Multi-Container Pods Why does Kubernetes allow more than one container in a Pod Containers in a Pod runs on a "logical host": they use the same network namespace (same IP address and port space), they can use shared volumes using several containers for an application is simpler to use, more transparent, and allows decoupling software dependencies Use Cases for Multi-Container Pods The primary purpose of a multi-container Pod is to support co-located, co-managed helper processes for a main program Sidecar containers: "help" the main container. For example, log or data change watchers, monitoring adapters, and so on. A log watcher, for example, can be built once by a different team and reused across different applications Another example of a sidecar container is a file or data loader that generates data for the main container. Communication Between Containers in a Pod Shared volumes: you can use a shared Kubernetes Volume as a simple and efficient way to share data between containers in a Pod. Volumes enables data to survive container restarts. It has the same lifetime as a Pod. it is sufficient to use a directory on the host that is shared with all containers within a Pod A standard use case for a multi-container Pod with shared Volume is when one container writes to the shared directory (logs or other files), and the other container reads from the shared directory The second container uses Debian image and has the shared volume mounted to the directory /html. The second container every second adds current date and time and into index.html that is located in the shared volume. Nginx servers reads this file and transfers it to the user for each HTTP request to the web server. kubectl apply exec into mc1 pod 1st container exec into mc1 pod 3nd container Kubernetes has three Object Types you should know about: Pods - runs one or more closely related containers Services - sets up networking in a Kubernetes cluster Deployment - Maintains a set of identical pods, ensuring that they have the correct config and that the right number of them exist. Pods: Runs a single set of containers Good for one-off dev purposes Rarely used directly in production Deployment: Runs a set of identical pods Monitors the state of each pod, updating as necessary Good for dev Good for production Pod templates : Controllers for workload resources create Pods from a pod template and manage those Pods on your behalf. PodTemplates are specifications for creating Pods, and are included in workload resources such as Deployments, Jobs, and DaemonSets. Deployments and replication Kubectl explain Deployment Kubectl explain Replicaset Overview on Kubernetes Deployment Kubernetes also provides Deployment resource that sits on top of ReplicaSets and enables declarative application updates. When running Pods in datacenter, additional features may be needed such as scalability, updates and rollback etc which are offered by Deployments A Deployment is a higher-level resource meant for deploying applications and updating them declaratively, instead of doing it through a ReplicationController or a ReplicaSet, which are both considered lower-l