Posts

K8s - ETCD

Image
  etcd is a "strongly consistent , distributed key-value store". Why etcd? 1. Consistency : Since the API server is the central coordination point of the entire cluster; strong consistency is essential. It would be a disaster if, say, two nodes tried to attach the same persistent volume over iSCSI because the API server told them both that it was available. 2. Availability: API downtime means that the entire Kubernetes control plane comes to a halt, which is undesirable for production clusters. The  CAP theorem  says that 100% availability is impossible with strong consistency, but minimizing downtime is still a critical goal. 3. Consistent Performance: The API server for a busy Kubernetes cluster receives a fair amount of read and write traffic. The secret behind etcd's balance of strong consistency and high availability is the  Raft algorithm . Raft solves a particular problem: how can multiple independent processes decide on a single value for somethin...

K8s - Creating a User and Group

Image
  In the previous blog we saw about role and role binding. In this post, we will see how to create a user and group. Technically, there is no concept called "User" and "Group" in K8s.   But, K8s provides ways to authenticate an external user/group with K8s. In this blog, we will see how to use certificate based authentication. Below are steps to onboard a user: 1) Create a private key. 2) Create a certificate signing request (CSR) using the above private key. 3) Generate a CSR request. 4) Approve the CSR request. 5) Extract the approved CRT file from the approved CSR request. 6) Build the config file. When we create a CSR, we mention the USERNAME and GROUPNAME . Let's see practically. Generating a private key. I am going to create a user called " demouser ". Now, we have the private key. Using that we are going to create a CSR. Note the highlighted portion, which is the subject where CN(Common Name) refers to username and O(Organization) refers to grou...

K8s - User and Groups

Image
  In this post, we will see how user and group works. Technically, there is no concept of user and group management in K8s.  But, K8s has something called "Service Account" . When K8s is installed from scratch, every namespace has "default" service account and it has admin access to perform actions. It is not practically possible to use " default " service account for every actions. From security point of view, we need to give fine grained and required access.  K8s has 2 important things in the space of "Access Management". Role and RoleBinding [Namespace Scoped] Role : Create a role with actions allowed actions on the resources. Let's say I want to create a readonly role. Using the role users can only view the resource and cannot perform actions like create, modify, delete. Rolebinding : Attaching the role to a user, group and service account is called "Role Binding". apiVersion : rbac.authorization.k8s.io/v1 kind : Role metadata :...

K8s - Finalizer

Image
  Finalizers  are conditions that must be satisfied before a resource can be deleted. When a delete is ordered on a finalized resource, the resource is locked in changes until the conditions are met. Finalizers are used to signal to the control plane, or to custom controllers like Operators, to clean up for a resource before completely and finally removing it. Some common finalizers you’ve likely encountered are: kubernetes.io/pv-protection kubernetes.io/pvc-protection kubernetes.io/pv-protection, ensures that PVs are not removed while still bound to PVCs. Similarly, the kubernetes.io/pvc-protection finalizer on PVCs blocks the deletion of a PVC that is still in use by a pod. Let's try to implement finalizer on a pod.  Below is my pod YAML: Verifying the finalizer tag on my pod. Let's trigger a delete call on the pod. We can see the pod is in " Terminating " state. What the pod log shows? We see the kubelet has stopped the container, but the pod is in " T...

K8s - Deployment and HPA replicas

Image
  We all know that replica is a critical part of a K8s deployment. Default replica is 1. Setting replicas as 3 will ensure 3 pods of that deployment is running at any given time.  Replica are internally managed by replica set which is in turn controlled by the K8s  ReplicationController   . When a pod is bad or deleted as part of replicaset, replication controller will ensure a new pod is created. Now, coming to HPA (Horizontal Pod Autoscaler) which is a dynamic scaler which works at the pod level based on the metrics configured.  When we configure we must mention min and max values. They should be greater than 1. Let's image I create a HPA with min as 5 and max as 10 under the condition of CPU utilization more than 50%. Initial deployment is set with the replica as 1. On top the deployment, I am attaching a HPA with the mentioned configuration. Under HPA, we are forcing the min replicas to 5. Hence, it autoscales the pod to 5 even though the CPU utilization is ...

K8s - Affinitiy and Anti-Affinity

Image
  Affinity refers to "Establishing a relationship based on similar characteristics". Anti-Affinity refers to "Breaking a relationship based on a similar characteristics". This affinity can be set at node level and pod level. Both node and pod affinity has two parameters: required DuringScheduling IgnoredDuringExecution : Means the scheduler should look for the node matching the  nodeAffinity condition mentioned in the pod configuration file. preferred DuringScheduling IgnoredDuringExecution:  Means the scheduler tries look for the node matching the  nodeAffinity  condition mentioned in the pod configuration file. If no node is available then the scheduler creates pod on any available nodes. What is a node affinity? Node affinity says scheduler to place a pod on a node when one or more condition matches. Node affinity is very similar to "Node Selector", but under node affinity we can mention one or more conditions. I have a node labelled as  datacenter=Chen...

AWS - Route53 Failover Policy

Image
  "Route 53 failover" refers to  a feature within Amazon Route 53, a DNS service, that allows automatic redirection of traffic to a backup server or region if the primary server or region becomes unavailable , essentially ensuring continuous website access even during outages by utilizing health checks to monitor the status of your resources and route users to the healthy endpoint. For this post, I have 2 webservers running web application on port 80. First, I am going to create Route53 Private Hosted Zone.  The zone name is " labexample.com ". I am making this zone as private, so that it can be accessed with AWS VPC. Once we have the zone, we need to create Route53 health check, this is a critical piece to monitor the primary server and enabled route53 to failover if the primary server fails. IP address to monitor is the IP address of the primary server. Here, we are mentioning how often to monitor and failure threshold. Next, we will create DNS record under the p...