RSInfoMinds

  A security context allows you to set access control for Pods, as well as containers and volumes in Pods, when applicable.  Examples of access controls that can be set with security contexts include: The user ID and group IDs of the first process running in a container The group ID of volumes If a container's root file system is read-only Security-Enhanced Linux (SELinux) options The privileged status of containers, which allows the container to do almost everything root can do on the host if enabled Whether or not privilege escalation, where child processes can have more privileges than their parent, is allowed Creating a pod with no security context: We are listing the logical device files under the container /dev folder. But it does not list the entire /dev files which are visible under host. Let's create another pod with privileged security as TRUE. Now you can see the /dev files which are available under the host from the...

  In this post, we will see how to upgrade K8s master and worker node. kubeadm   supports upgrading Kubernetes clusters.  We will be upgrading Kubernetes from version 1.28.1 to version 1.28.2.  You should always backup important data before upgrading, and test upgrades before deploying them to production. The upgrade process follows the general procedure of: Upgrading the Kubernetes control plane with kubeadm (Kubernetes components and add-ons excluding the CNI) Manually upgrading the CNI network plugin, if applicable Upgrading the Kubernetes packages ( kubelet ,  kubeadm ,  kubectl ) on the control plane and worker nodes Upgrading the kubelet config on worker nodes with kubeadm. Login to the control plane node. To begin the upgrade,  first kubeadm  needs to be updated to  1.28.2  : sudo apt-get update sudo apt-get install -y --allow-change-held-packages kubeadm=1...

  In this post, we will discuss some of the deployment attributes.  RollingUpdate: New pods are added gradually, and old pods are terminated gradually. Recreate: All old pods are terminated before any new pods are added. In most cases, RollingUpdate is the preferable update strategy for Deployments - No Downtime. If the deployment as 10 replicas and with maxSurge as 2 and maxUnavailable as 2. Then during the deployment. At most,  12 pods ( 10 + 2 maxSurge pods ) will be ready during the update. At least 8 pods ( 10 - 2 maxUnavailable pods ) will be ready during the update. maxSurge is the maximum number of new pods that will be created at a time. maxUnavailable is the maximum number of old pods that will be deleted at a time. minReadySeconds is the bootup time of your application, Kubernetes waits specific time tili the next pod creation. This is my current deployment. Updating the deployment. 12 pods created as a result of maxSurge . As a result of minReadySeconds the di...