0:07 hi kaushik so uh
0:09 yeah let's start the mock interview and
0:11 uh so i'll firstly try to understand
0:14 your profile and then
0:15 you know you can give me a brief
0:17 introduction and uh we can go forward
0:20 with the questions right so
0:22 can you uh just brief me about your past
0:25 experience and uh what is your uh you
0:27 know comfort zone in devops and what are
0:29 you doing day to day
0:31 can you just give me a movie
0:33 yeah definitely so
0:35 so for the past i've been working on uh
0:38 devops and cloud technologies uh so what
0:40 i've been working is like working on
0:42 cloud technologies like aws and azure
0:46 and also on our devops as well so for
0:48 git uh i've been using for uh
0:53 uh jenkins for ci cd and uh airbus uh
0:55 code pipelines and as well as azure repos
0:57 repos
0:59 and also uh azure devops
1:02 for uh ci cd management and uh coming to
1:04 containerization and orchestration i've
1:07 been using uh docker and kubernetes uh
1:10 okay so like this is my overview like
1:12 this is uh like what i've been working
1:14 on and also like for uh configuration
1:17 management i've been using uh ansible
1:18 and as well as
1:22 uh terraform for uh like uh deploying
1:25 the infrastructure so yeah awesome so
1:27 i'll i'll try to keep this uh interview
1:29 questions as simple as possible to
1:31 understand your experience the goal is
1:33 not to confuse but to you know
1:35 understand what is your work experience
1:38 and how familiar of you with these tools
1:40 right so yeah okay as you told uh i
1:42 would firstly like to understand uh can
1:45 you tell me what is git
1:47 so git is basically for source code
1:49 management say like uh you have some
1:50 developers and uh
1:52 like we need to develop an application
1:54 uh so what we do with kit is like you
1:57 basically uh check in the code and you
1:59 have all the source code and we need a
2:01 distributed centralized uh version
2:03 control system where we can actually
2:06 track the code so so for that reason uh
2:09 we use git law so for git we have like
2:11 several hosting platforms like say like
2:13 a bit packet we have some something like
2:16 azure repos or code comment or git lab
2:18 or github so so we use them as a
2:20 platform uh to actually commit the code
2:22 and like for a centralized
2:25 system to track the changes so that is
2:27 when you use git so
2:28 so
2:31 do you know if git is a centralized or a
2:33 distributed version controlling system
2:35 git is a distributed version control system
2:36 system
2:39 awesome so uh because you have vast
2:41 experience like you have experience with
2:43 azure and you also have experience with
2:45 uh like you told that you know that
2:47 there are other hosting platforms like
2:49 github right so
2:51 i would like to understand from you what
2:53 is the difference between github and
2:56 the azure repositories have you tried to
2:58 understand the difference anytime
3:00 yeah i mean like uh it's like it's just
3:03 like a hosting platform uh it's just
3:05 that the user interface would vary and
3:07 there are like couple of features which
3:10 would uh vary from github to like say
3:12 azure repos so uh
3:14 like i mean like uh it's almost the same
3:16 it's just that the platform is different
3:17 and you have much more better
3:20 integrations with the azure repos where
3:22 you can easily integrate
3:24 it with azure devops so it has that flexibility
3:25 flexibility
3:28 so yeah so that is the main difference i
3:29 can say
3:31 okay so can you integrate uh azure
3:34 devops with a github repository
3:36 yeah definitely so so we have a concept
3:38 called service connections where you
3:41 actually provide the provider and you
3:43 you specify a service account and its
3:45 details you pass it in the service
3:46 connections and
3:49 then you can have your github integrated
3:52 to azure devops so in that case uh what
3:54 do you see is the difference between
3:56 github and azure repositories because i
3:59 can create a github repository for free
4:01 right i don't have anything
4:03 yeah exactly so so yeah i mean like you
4:05 have like you can create public
4:07 repositories or like private uh
4:10 repositories uh for sure but uh for
4:11 azure repos you need to have a
4:13 subscription and you you need to have
4:15 your own organization set up so
4:18 it's like based on like you need to you
4:20 need to make a payment for it so azure
4:22 for like github you don't need to
4:25 necessarily so in your organization are
4:28 you using repos on github or azure so we
4:30 have used like multiple projects like uh
4:32 so for one project uh for the project
4:35 that i'm currently in uh using uh i'm
4:37 currently uh using azure repos for
4:39 source management yeah
4:41 okay got it
4:43 yeah so uh
4:44 do you use git for your day-to-day
4:46 activities or
4:49 yeah i do use uh get on like for a
4:51 day-to-day activities like not like
4:53 really complicated comments but like
4:56 what what exactly is required for
4:58 for the code management so do you
5:00 understand the difference between git
5:02 pool and git fetch
5:05 yeah git pull basically pulls all the
5:08 contents of a
5:09 repository whereas git fetch only
5:12 fetches what what exactly has been
5:14 changed and uh that will be the new the
5:16 new files and the new changes right yeah
5:18 exactly awesome
5:20 yeah so uh like i would like to
5:24 understand uh a complete ci flow of your
5:28 organization have you are doing uh cacd
5:30 yeah definitely i can go ahead so so i
5:32 can have like several use cases like let
5:35 me take one example uh i would taking
5:36 taking
5:38 azure into consideration for now uh say
5:41 like we use azure devops for ci cd so
5:43 what we what i have done in the past is
5:46 like i have created uh release pipelines
5:48 in azure devops where i have integrated
5:51 uh azure repos uh
5:53 inside the pipeline and for this we're
5:55 using uh docker and kubernetes uh where
5:58 for uh micro service management so so we
6:00 we containerize the application and like
6:02 uh this is part of the release process
6:04 uh so like
6:06 we create images and we push these
6:09 images to azure container registry and
6:11 once we have the images pushed to azure
6:13 container registry uh we fetch the
6:16 images uh as a part of cacd process and
6:18 then we
6:20 use this kubernetes concept to uh
6:23 create a release pipeline and we create
6:26 a deployment uh manifest and uh uh
6:28 basically fetch the image from the
6:30 registry and uh
6:32 so how do you do that uh deployment part
6:34 like how do you fetch this
6:37 from the registry and how do you deploy
6:39 so this is through kubernetes manifest
6:42 file so we specify in the container
6:43 image and also
6:46 we specify the required parameters we
6:48 pass them inside the kubernetes manifest and
6:49 and
6:51 as a part of this process uh we include
6:53 this in the release pipeline and
6:56 so that is how the pipeline looks like
6:59 so uh do you prepare this kubernetes
7:01 manifest on the fly or do you store it
7:03 somewhere or how is it
7:05 so this is like version control so as i
7:08 mentioned earlier we use azure repos for
7:10 source code management so uh we have all
7:13 these files com checked into uh azure
7:15 repos so from there we fetch this uh
7:18 deployment file okay so using some shell
7:20 script or something do you modify the
7:23 container image or the port if required
7:25 for the deployment yaml file before so i
7:28 use visual studio code to basically uh
7:30 update the images and uh so that is when
7:33 i have integrated uh azure with uh uh
7:35 uh
7:37 for this visual studio code and that is
7:39 how i check in the code to azure repos and
7:40 and
7:43 uh and i create a release based on the
7:45 requirement or based on what we have scheduled
7:47 scheduled so
7:48 so
7:50 awesome yeah that's that's very good to
7:52 know and
7:56 so coming to this uh kubernetes right so
7:57 how do you
7:59 ensure that there is no downtime during
8:02 your uh application deployment
8:05 yeah definitely so so so i do perform
8:07 like a rolling update what exactly it
8:09 means is making sure that we have at
8:13 least two replicas running on our uh
8:16 on on our kubernetes uh so this this
8:18 ensures that when you create a release
8:20 so then one one part goes down and
8:23 meantime the other part uh still stays uh
8:24 uh
8:26 updated with the new changes so so that
8:29 is how uh we do we do like a rolling
8:32 update which which will ensure that the
8:33 application is up and running all the time
8:34 time
8:37 awesome awesome so uh what is the
8:38 difference between a
8:41 deployment and a replica
8:44 so uh the replica set
8:47 is deployment is where you specify the
8:50 number of replicas and replica set is
8:52 kind of a different concept also so
8:55 replica that i'm i don't have on top of
8:56 my mind but uh
8:58 yeah yeah that's okay
9:01 yeah and uh so you are performing this
9:03 uh as a rolling updates right the deployment
9:09 so uh like do you understand the concept
9:12 of services in kubernetes
9:15 yeah i mean like i do i do uh work on
9:17 different services like so we have like
9:19 a load balancer service we can say and
9:22 also like uh notepod and uh also like
9:24 cluster ib so these are like the circles
9:27 that we uh use like based on what
9:29 exactly is required so yeah awesome
9:31 awesome so
9:33 about the different kinds of services yeah
9:34 yeah
9:38 so uh let us let us slightly uh deep
9:42 dive into this kubernetes topics and um so
9:43 so
9:45 what are the kubernetes uh
9:46 i mean you understand the kubernetes
9:49 control plane right so right and it is
9:51 uh which kubernetes control plane
9:54 services uh would deploy on the worker nodes
9:55 nodes
9:58 so so basically considering to master we
10:01 say like we have like a cube scheduler
10:03 controller queue control manager and as
10:05 well as api server which are like and
10:09 also like the xcd which are part of uh
10:11 the kubernetes control plane uh like uh
10:14 the core components and like for
10:16 kubernetes nodes i can say like we we
10:20 have this cube q proxy and as well as uh
10:22 cube ctl uh so basically these are like
10:24 uh uh
10:26 which we have on each node so this is to
10:30 perform uh uh pod operations and uh uh
10:32 like manage the cluster operations on
10:33 the node
10:35 yeah so basically uh you forgot about cubelet
10:36 cubelet
10:39 oh yeah yeah yeah right yeah cubelet and
10:41 theta is for uh
10:43 command interface right yeah
10:44 yeah
10:46 so uh can you
10:48 it's okay if you don't uh completely
10:50 understand but uh do you know how
10:52 cubelet actually works uh can you tell
10:54 like if i'm creating a pod let's assume
10:57 that uh i gave a request through command
11:01 line something like ctl apply for dml
11:04 okay so can you unders can you tell me
11:06 on in a brief like what actually happens
11:08 how is this request uh
11:11 processed from your cube ctl from your
11:13 command line to the deployment of the
11:14 actual part
11:17 okay so so basically here uh the cube
11:19 scheduler and cube controller comes into
11:21 picture so what cube scheduler does is
11:23 like when we when we pass the
11:26 requirements uh it makes sure that it
11:29 will have that required
11:31 resources allocated onto a particular
11:34 part which which make sure uh that
11:35 it it deploys the right number of
11:38 replicas onto that particular part and
11:41 inside the cluster which is so and like
11:43 cube controller uh what it does is like
11:46 it make sure that uh it has the right
11:48 number of uh so so we have this concept
11:51 called like desired state and uh yeah uh
11:54 the current state so it make sure that
11:56 if if for some reason the part goes down
11:59 uh maybe some uh issues like uh we can
12:02 say like crash crash flow back off state
12:04 and the part goes down and what it does
12:05 is like
12:06 it creates a new part that is when a
12:08 desired state
12:10 it looks for that state and that is how
12:11 uh the cube controller comes into
12:15 picture and cubelet uh cube uh cubectl
12:18 is how we we write in the commands uh so
12:19 just that uh
12:22 to fetch the logs if it fetches the logs
12:24 through this master node
12:27 so what it does is like uh
12:29 we use cube ctl which which queries uh
12:32 the cube api server so that is how the
12:35 connection looks like uh so yeah so yeah
12:37 so from cube ctl it would actually go to
12:40 the cube api server cube api server then
12:42 it goes to your api server yeah
12:43 yeah yeah
12:44 yeah
12:46 so from the api server it would go to
12:48 the scheduler and from scheduler it goes
12:49 to the cubelet right
12:52 and from there it also goes to lcd as well
12:52 well
12:54 yeah and
12:56 yeah probably uh sometimes uh to some of
12:58 the interviewers you might have to
13:00 explain that you know uh when when we
13:02 are looking for more about cubelet so
13:04 probably you can say that uh cubelet
13:06 would talk to the container network
13:08 interface right correct yeah we have the
13:11 cni and the cre right container yeah
13:12 runtime environment container runtime
13:14 environment yeah so you need to say that
13:16 it goes to the container runtime and
13:18 depending on the container runtime there
13:19 is a container runtime interface and
13:21 from there it would get deployed yeah
13:24 but you are good i mean yeah i mean like
13:26 i just wanted to give an overview yeah
13:28 okay so like if we go in depth it's like
13:29 we have like container and an environment
13:31 environment
13:34 which basically manages this yeah yeah
13:37 good so uh do you understand the concept
13:40 of ingress in kubernetes
13:43 yeah i do understand the concept of
13:46 ingress uh can you tell me why
13:48 is so
13:50 it is like similar to like uh
13:53 service type it is a service type where
13:55 we you directly need to like uh so we
13:58 use like application gateway so it
13:59 doesn't need to actually communicate with
14:00 with
14:02 intermediate interfaces like we have we
14:04 can establish a direct connectivity uh
14:06 with your parts and uh like for the
14:09 external uh applications like which is
14:11 outside of your cluster
14:14 awesome awesome yeah so
14:16 i think you are doing really well uh on
14:18 this specific things i would like to
14:20 like you know slightly jump on to uh
14:23 some advanced questions that i have and
14:24 uh yeah
14:26 yeah you can uh you know you can ask me
14:28 if there is any questions uh regarding
14:30 these things or not so yeah
14:33 because you already work on docker
14:35 right so do you know what is a uh
14:39 distro-less docker image
14:42 ah destroy stalker image
14:46 yeah that's okay and uh
14:48 one more thing is uh have you ever
14:50 worked on uh multi-stage docker deployments
14:52 deployments
14:54 yeah uh i did work on multi-stage docker
14:56 deployment where in like kubernetes we
14:59 have like uh the pod concept where uh in
15:01 each part like there are like multiple
15:02 containers which is called like a
15:05 sidecar container okay i have worked on that
15:06 that
15:10 yeah okay uh no problem and
15:13 so with respect to kubernetes um
15:15 do you know what is a custom resource definition
15:16 definition
15:18 yeah uh the crd right so custom resource
15:21 definition is like which you so for one
15:23 use case which i can say is like for
15:25 help there is one thing
15:27 so we have this uh radish which we need
15:30 to deploy so what we use like for we use
15:33 like custom resource definition to
15:36 basically uh pass inside the
15:38 kubernetes file uh for the help
15:40 deployment that which which basically
15:43 packages and makes it it acts like a
15:47 proxy uh so so where you can
15:49 actually manage the resources so that is
15:52 what the crd is actually
15:53 okay okay
15:55 yeah so uh
15:59 yeah one last question that i have uh is
16:02 like uh do you know uh what is an
16:05 admission controller in kubernetes
16:08 uh admission controller uh i knew but i
16:11 don't i want to that's okay i mean yeah
16:14 it does also yeah because we don't work anymore
16:15 anymore
16:18 yeah sure so basically you know uh it's
16:20 they're like similar to web hooks where
16:23 uh you know probably you want to modify
16:25 the behavior are you aware of uh service mesh
16:26 mesh
16:28 yeah yeah
16:30 so if you take example of service mesh
16:32 what happens when you deploy
16:34 you know when you deploy service mesh so
16:36 it creates a side cut container for your
16:39 uh actual container right inside it is
16:42 when you use sidecar containers yeah so
16:44 you know how this works uh behind is
16:47 that uh kubernetes has a concept called
16:49 mutating webhook so you know okay uh so
16:50 whenever you create a request for the
16:53 pod so
16:56 the webhook gets triggered and
16:58 it modifies the behavior of your port
17:00 and it creates two containers instead of
17:01 your actual container that you're
17:03 deploying so this is the concept of
17:06 admission controllers yeah that's okay
17:09 yeah no you know it so yeah that's fine
17:12 yeah yeah so yeah i think uh you have
17:15 answered pretty well and uh that's all i
17:18 have uh it was very nice talking to you
17:20 and yeah it was nice talking to you as well
17:20 well
17:23 yeah good to know about like couple of
17:25 concepts like the admission controller
17:27 yeah uh and also the republic assets as
