Tejas Meshram

Hello. My name is Tejas Meshram. I have completed my computer engineering from VJTI College in Mumbai. And I started working at Wipro first as a software engineer. I worked there on multiple projects. One of those, which was an important one, was for the client Samsung, and I worked as a Java developer in that project. That is where I spent most of my career in Wipro. That was my first company. Then I changed to HSBC Bank in Pune. And there, I started off as a Java developer, but eventually got into DevOps and started creating and writing pipelines in Jenkins to automate the API deployments on the platform, which was our team. And after some time with that work, I started getting into cloud. I learned the technologies to set up the infrastructure, mostly the cloud infrastructure, on the job. So I created VMs, SQL instances, a Kubernetes cluster, and a Helm Chart as a part of setting up Kong API manager on GCP. After that, I worked at Priceline briefly in Mumbai, where I was responsible for managing Kubernetes clusters in production. And everything was configured via code there. So I heavily used Terraform in that project. And for Kubernetes workloads, I used FluxCD as a tool to manage the changes that needed to be pushed into the Kubernetes cluster. It worked as a GitOps approach, which means that if you have a change to make in a Kubernetes cluster or in a namespace, you just make that change in a Git repository. And that repository is configured with a Flux agent, which is deployed on the cluster. After a certain interval, which is configurable, Flux keeps on checking if there is any change in GitHub. And whenever it finds that change, it pulls that change into the cluster and deploys it. I also tried to write a pipeline for some of the AWS infrastructure in that project. After that, I am now working at Motorola. And here, I am mostly writing Helm charts. I am also managing Bitbucket pipelines. Our Kubernetes cluster is in AWS in EKS, and I heavily use bash scripting here to automate a lot of things. Thank you.

Horizontal path auto scaling in Kubernetes based on custom metrics can be configured as follows: How do you configure horizontal pod auto scaling in Kubernetes based on custom metrics? Horizontal pod auto scaling is a concept with the pitch. The Kubernetes cluster can spin up multiple pods if required based on the load that the port or the deployment is getting. And configuring horizontal pod auto scaling can be done by enabling the horizontal pod autoscaler first. And there should be a horizontal pod autoscaler field in some of the configuration in the manifest that we create for a deployment.

In Kubernetes, what is a namespace, and how does it help in cluster management? So, a namespace is a segregation of workloads, and that can be used for a variety of purposes. An example of which could be having a namespace for a different team where a department has a single cluster. This would allow those teams to work independently and not step on other teams' workloads unless they want to, for which they can use another Kubernetes concept like ingress and egress and network policy. And, we can also set resource limits on a namespace, which would help by allowing pods to only utilize the maximum amount of resources that we have configured in the namespace, and that would also help prevent killing other parts in some other namespace. So, this would help segregate the workloads in a namespace. This is how we can manage the resources of our cluster as well.

When setting up a CICD pipeline for a Kubernetes application, key components and stages would include: The first stage would be to clone the git repository. And since this is a Kubernetes application, I am assuming that there would be a Dockerfile in that application, which would contain the code for building the image of that application. So the second stage in the CICD pipeline would be building the image using the Dockerfile using the Docker build command. The next stage would be to push that image to a remote repository, depending on which remote repository services the organization uses. And the next stage would be to inject the Docker image along with its tag into the template that we have for a part, so that will contain the image specification with the Docker image that we just built in the previous stage. The next stage would be to perform the deployment of that part in the Kubernetes cluster, and that can be done through kubectl or through Helm commands depending on what type of templating is used in that application or in that organization. And once the application is deployed, the application can be verified to have appropriate checks to test if the application is up and running using liveness probes, etc. And once that is done, that could be the last stage of the pipeline.

Exposing a Kubernetes service to the Internet involves routing incoming traffic from the internet to the service through an ingress controller. We're currently within a Kubernetes cluster where an ingress controller is in place, which receives requests and directs them to the appropriate service. The ingress controller is one way to configure exposure to the internet, and a popular choice is the NGINX Ingress controller, which I've used. We can configure the NGINX Ingress controller to allow requests from the internet, and then we can set up appropriate ingresses based on the path of the request. These ingresses will point to the Kubernetes service, and based on the selectors and labels, they will be redirected to the correct parts of the cluster.

When creating a persistent volume claim in Kubernetes, we need to consider the storage class of that volume. We need to know what kind of access mode we want, which could be read-only, read-write, or exclusive. We also need to know the storage that this claim is going to need in terms of gigabytes or megabytes. These three configurations should be minimally known to create a persistent volume claim.

Can you explain the process of scaling our deployment in AKS, and what metrics would you consider during scaling? I am not particularly familiar with Azure Kubernetes service, but speaking roughly about, the general concept of scaling a deployment in any Kubernetes cluster. We could modify the configuration of a deployment by updating its replicas field to the desired number of replicas that we want for that deployment. Another way is to use kubectl to perform the same activity. And what metrics would you consider during scaling? The metrics that need to be considered would be the resources that are required for the deployment. And if there is any auto scaling already enabled, in which case, we may not need to do, to scale the deployment manually. Yep. I can think of these.

What considerations are important when configuring network policies in Kubernetes for microservice architectures? What considerations are important when configuring network policies in Kubernetes for microservice architectures? We have to consider if the SD parts in a particular namespace should be exposed to another namespace, or should the request be allowed to come into this particular namespace or whichever namespace is configured. And we can do that by specifying the ingress and egress configurations in the network policy, and we can configure them to either allow the traffic or to deny the traffic based on the namespaces and the labels among other options that can be used to filter the traffic.

How would you handle disaster recovery and backup strategies for stateful applications running on Kubernetes in Azure? How would you handle disaster recovery and backup strategies for stateful applications running on Kubernetes in Azure? The most basic thing that can be done to ensure no downtime or minimal downtime is to have multiple replicas of a stateful deployment, a stateful application. And we can configure that in its manifest. That would allow us to, and it would even help to deploy each of the replicas in a different node by setting the appropriate node selector or node affinity. If we have to absolutely ensure that we don't want any downtime, if that is the highest priority, then each of the replicas or at least some of the replicas could be deployed in nodes which are present in different zones or different regions in the Kubernetes cluster. The backup strategy. One of the backup strategies that I can think of is to keep taking backups of the etcd, which is the database for the entire Kubernetes cluster, and this can be done at a regular interval. This can be automated through some pipeline, and we can schedule a pipeline to perform this backup. Yeah.

I would use Fluentd as the logging architecture for a Kubernetes cluster, since it's a native service of GCP, and it goes very well with that. And the logging explorer or the logging service in GCP has great capability of directly fetching the logs from a Kubernetes part. So I would prefer the logging mechanism which is very well supported by that cloud's native services.

How do you approach performance test testing for deployments in Kubernetes, and how does it influence capacity planning? How do you approach performance testing for deployments in Kubernetes, and how does it influence capacity planning? There are some third party services that we can use for performance testing in a Kubernetes. The idea behind any testing would be to make a lot of requests to your application that is deployed in the Kubernetes cluster and test various aspects of the application and try to try to make as many requests as possible within a certain, period of time and see how the application behaves and see if the pod auto scales, if that is enabled, and how the application performs, when it is load tested or stress tested.