- 1 day ago
CI/ CD Pipeline, Docker and Kubernetes lecture series
Category
📚
LearningTranscript
00:06Next, we are going to learn about ingress in Kubernetes.
00:09Now, as many applications we have given examples, when we expose them on the browser, we are
00:15using some sort of an external service.
00:17For example, we have taken an example of MongoDB, where we have exposed an external service
00:28and we have exposed this particular link, here we have an IP address and our port number
00:34and directly IP address and port number, we have access to our Mongo Express UI.
00:40Now, this is something which is good for testing, but this is not something that we use in our practical
00:46production
00:47level environments. Generally, when we access any application,
00:50we have access to any domain name through access. So, this domain name through access
00:57process, we use this Kubernetes component which is called ingress.
01:01So, ingress is very important when we talk about domain name.
01:05And how does everything work with ingress? Basically, when we use ingress,
01:09then we have another additional component in our cluster, which will be ingress.
01:15So, as many requests that will be our cluster, that will be ingress.
01:22And ingress will forward all the requests to service.
01:26And now, we don't need this external service.
01:29Now, we can use an internal service,
01:31which will forward forward our request to pod.
01:35Instead of having the external service as the entry point to the main application,
01:40we use ingress. And with ingress help, we can define
01:44that we want to set a domain for our request.
01:47For example, if my domain is app.com,
01:51then we will type in app.com in our browser
01:53and automatically this request will be ingress.
01:56And in this way, our request flow will be going.
01:59Now, the concept of external and internal service is something
02:02which we have already discussed before.
02:03When we have set up our Mongo and Mongo Express.
02:07So, we have used an internal service for MongoDB for MongoDB.
02:12It has an external service for MongoDB.
02:13For external services, we have a type that is load balancer.
02:17These things we have already discussed.
02:19In external service, we have to define an external port,
02:21node port,
02:23which has a specific range of 30,000 to 32,700.
02:26So, this type of setup, which we have already done,
02:29where we expose external service.
02:31Now, this setup we will talk about,
02:33that will be an ingress based setup.
02:36Now, ingress based setup,
02:37like we define our services for our configuration files.
02:40So, now, we can define our configuration files for ingress.
02:44How does it work?
02:46Let's take an example of the Mongo service.
02:49Now, in Mongo Express,
02:50we used our Mongo external service
02:53and the external service looked something like this.
02:56where we have defined type load balancer.
02:59We have a additional node port.
03:01If we have to add an ingress layer in MongoDB,
03:04if we have to add an ingress layer in MongoDB,
03:06we have to add an ingress layer in MongoDB.
03:07Now, this is an external service.
03:10But, if we want to add an ingress layer in MongoDB,
03:13we have to define an ingress in MongoDB.
03:16In which we have to define kind would become ingress.
03:18This will be our API version.
03:20We can give a name in meta data.
03:23And in specification,
03:24basically, we have to define rules in ingress.
03:27Which are routing rules.
03:28If we have a request for ingress,
03:32then it will be where to forward.
03:33So, whatever domain is,
03:35we define it in host.
03:36And this is the second attribute,
03:38which is HTTP.
03:39In HTTP, we define our request forwarding.
03:51So, what this entire setup basically means is,
04:08that we have not included anything in our browser.
04:11So, here we have to call our
04:19information on our Java fields,
04:25request will be directly to service port 8081 forward and what will be done in mongo
04:32express service will be directly to port 8081 forward and what will be done in mongo
04:37express service will be redirected to port 8081 forward. So this way our request
04:40forwarding will work. Now because we don't want to expose our IP address and port
04:43number directly, so now we don't need this external service, we can convert
04:48to an internal service. When we convert into internal service then
04:52we don't have type load balancer requirement here. Similarly we don't need to
04:57specify a node port here. So now our service is an internal service
05:01and we have added an ingress layer. So this is the general setup
05:08when we use ingress with internal services. Now inside our ingress configuration
05:12file we have HTTP. This is just the second step in the configuration file. This
05:18HTTP is not the HTTP protocol. So we don't confuse it. This is the second step.
05:23With that, whatever we define domain name, it should be a valid domain name
05:27which we have access to. So here are some basic things
05:30which we have to focus on.
05:31we have to focus on.
05:38Now when we use ingress, there is also one more important component
05:42which we have to use indirectly. In fact, directly we have to use
05:45which is called ingress controller. Ingress controller is basically an implementation of ingress.
05:53Implementation means that here, when we set up the ingress controller
05:57in the Kubernetes cluster, then here we have a pod create
06:02and this pod will basically be the ingress controller. So when we use ingress
06:07we don't use ingress. For example, let's talk about existing
06:10setup. So we have already a pod that exists. With that we have an internal service
06:16which exists and with that we have ingress set up. Now ingress set up
06:21means that we have to set up a pod
06:24in which we have the ingress controller. And all the requests
06:29actually come to this ingress controller. So when we imagine ingress
06:34we basically have to imagine it as a combined service
06:36where the entry point is not ingress but the entry point is the ingress controller pod
06:42where all our requests are coming. And ingress controller
06:45works to evaluate and process all the ingress rules.
06:49So whatever routing rules we define in ingress rules
06:52we all manage and process all the ingress controller
06:55along with managing all the redirections.
06:57That which request will redirect
06:59this work will also be our ingress controller
07:01which is now the entry point to the cluster.
07:05Now in Kubernetes there are different types of ingress controllers
07:08exist. Some third party ingress controllers
07:10which we can additionally set up
07:12but the default ingress controller
07:15that uses nginx
07:17nginx we already know
07:18nginx is our reverse proxy
07:20so we have the default kubernetes
07:22ingress controller exist
07:24that is the nginx ingress controller
07:27which we can use.
07:28We will set up a little bit. Now
07:30let's try to understand overall set up
07:32when we set up
07:33our request flow will work.
07:36So here we have to understand
07:37that ingress controller is an important component
07:40which is the entry point for all the requests.
07:44So we started with external service
07:45which we have now made internal service
07:48we have set up a layer of ingress
07:50and inside that layer
07:51there is an important pod
07:53which is the ingress controller.
07:55Now this is our normal set up
07:56which we will use nginx
07:57in nginx
07:59but generally when we use cloud providers
08:01like if we work with AWS
08:03which we will generally
08:05do in any organization
08:06we will do in any organization
08:07or we will do in any cloud provider
08:09whether it is AWS
08:10Azure
08:11or GCP
08:11or DigitalOcean
08:13if any cloud provider
08:14has got us
08:15then generally
08:15we don't expose directly
08:16ingress controller
08:19we expose what we do
08:20that is basically the load balancer
08:22every cloud provider
08:24has a load balancer
08:25like in AWS
08:26we have ALB
08:27application load balancer
08:28so this application load balancer
08:30has all the requests
08:32initially
08:32come to it
08:33and then
08:34its work to forward
08:35all the requests
08:36to the ingress controller
08:38now the ingress controller
08:39finally
08:40ingress controller
08:40finally
08:41our internal service
08:42and internal service
08:44in requests
08:45we have specified
08:47particular pod
08:48redirected
08:49so this way
08:50our flow of redirection
08:52of the request
08:54works along with the cloud provider
09:01now
09:01we are going to set up
09:02our own
09:03sample application
09:03with the help of ingress
09:05now
09:05we are going to set up
09:06this application
09:06we are going to take an example
09:08of a simple hello world application
09:09inside
09:10hello ingress
09:11configuration
09:12and we have the hello yaml
09:13configuration
09:14this is the deployment code
09:16which we have written
09:17basically
09:17our hello name
09:18image
09:19which we want to pull
09:19and set up
09:21and this image
09:22will be done
09:23once
09:23this pod
09:24created
09:24in this container
09:25simply
09:26hello from ingress
09:28will be printed
09:28in fact
09:30we are going to change it
09:30to hello from
09:31ingress
09:32we are going to change it
09:34to hello from
09:35our college
09:36let us suppose
09:37this text
09:37which we will print
09:38this text
09:39means
09:40our container
09:40and application
09:41all are working fine
09:42this is the deployment
09:43which we have created
09:44this is the name
09:45that we have given
09:46we want to create a single replica
09:47we have selected
09:48and labeled defined
09:50and this is the container port
09:52similarly
09:53we have defined an internal service
09:55here
09:55we have no type
09:56so this is an internal service
09:58within which
09:59we will accept the port
10:0080
10:00and they will forward
10:02into port
10:035678
10:05similarly
10:05we have defined an ingress
10:08the kind is ingress
10:09the api version is this
10:10we have given this
10:11in meta data
10:12we have given this
10:13ingress class
10:14we have given this
10:15we have given nginx
10:16our host
10:16that is hello.com
10:18meaning
10:18as we go to hello.com
10:19our request
10:21is service
10:22which is the
10:23hello world
10:24internal service
10:25redirect
10:26on port
10:2780
10:27this is the flow
10:28which we define
10:29in our configuration
10:30this flow
10:31if we summarize
10:32this is basically
10:33the same flow
10:34which we have created
10:35here
10:36our load balancer
10:38exists
10:38here
10:38directly
10:39our entry point
10:42here
10:43our requests
10:45they are coming
10:46on hello.com
10:48hello.com
10:50our request
10:50ingress
10:51and this
10:52requested
10:53is forwarded
10:53to port
10:5480
10:55of the internal service
10:57here
10:58our port
10:59that is 80
11:00request forwarded
11:01now internal service
11:02in request
11:02forwarded
11:03to port
11:045678
11:05here
11:05our request
11:09forwarded
11:09and this
11:10is the same container
11:11port
11:11which we have defined
11:12this is the basic
11:13setup
11:14we want to create
11:14this
11:16first
11:17we have to
11:18set up
11:18ingress
11:19controller
11:19we have to
11:22install the ingress
11:23controller on minicube
11:24so this is the
11:25nginx implementation
11:26which we will set up
11:27and the command
11:28is
11:28minicube
11:29add-ons
11:30enable
11:32ingress
11:32basically
11:33additional add-ons
11:35services
11:35which we can enable
11:36or disable
11:37enable
11:38here
11:38and this has started
11:41the process of
11:42enabling ingress
11:43so we have to install
11:44ingress
11:44in fact
11:45if we have to check
11:47all minicube
11:47add-ons
11:48then we can
11:49minicube
11:50add-ons
11:53list
11:53and we will have
11:54all the add-ons
11:55which are available
11:56to us
11:57here
11:57ingress add-on
11:59is enabled
11:59right now
12:00we can disable it
12:01and this way
12:02we have different
12:03add-ons
12:04like
12:04cube flow
12:05like
12:05registry
12:06so let's
12:07clear this
12:08like we have
12:09enabled
12:10kubernetes
12:10by default
12:11new namespace
12:13created
12:13if i do kubectl
12:15get namespaces
12:16so i have this new
12:17namespace which is
12:18ingress nginx
12:19this is basically
12:20for ingress
12:21we have already
12:22nginx used as the
12:24reverse proxy
12:24new namespace
12:26created
12:26where our
12:27ingress controller
12:28is set up
12:29if i want to
12:31check all the
12:32resources of this
12:32namespace
12:33i can do kubectl
12:34get all
12:37ingress
12:38nginx
12:41i can define
12:43my namespace
12:44here
12:44so this namespace
12:45all the resources
12:46have come with this
12:48namespace
12:48in this namespace
12:49if we talk about
12:49pods
12:49then we have
12:50three pods
12:51create
12:51in which
12:52nginx controller
12:53is this pod
12:54which is in
12:55running state
12:56this is actually
12:57our ingress controller
12:58which is created
12:59with us
12:59we have
13:00services
13:01we have
13:01deployment
13:02and we have
13:02a replica set
13:03let's clear this
13:04so i can simply
13:07do
13:07get all
13:08if we talk about
13:10pods
13:10this is the
13:12controller
13:12and if i talk about
13:14the services
13:14so if we look at
13:16the services
13:16these are the exact
13:18services
13:18which basically
13:19expose our ingress
13:21these two services
13:22are available
13:23are available
13:23and this ingress
13:25nginx controller
13:26is the service
13:27which basically
13:28will become
13:28entry point
13:29for our cluster
13:30where we have
13:31all the requests
13:32which will be
13:33host
13:33which will be
13:35all the requests
13:35that will be
13:38accepted
13:39and that will be
13:40redirected
13:41in fact
13:42let us also
13:43set up our other
13:43deployments
13:45if we do ls
13:45we have these two
13:46files
13:46we are going to set up
13:48our deployments
13:48kubectl
13:51apply-f
13:52hello.yaml
13:55and the second deployment
13:57which is for
13:57ingress
13:58in this way
13:59if i clear this
14:00and do kubectl
14:02get deployments
14:04the default
14:05deployments
14:05we are going to get
14:06this deployment
14:07which is of
14:08hello world
14:08now we will access
14:09this deployment
14:09in which way
14:10we will access
14:11the logical way
14:13is
14:13whatever service
14:15ingress
14:16through
14:16define
14:16there
14:17our requests
14:18like if i do
14:19kubectl
14:20get services
14:22hyphen n
14:23i want to get
14:23the services
14:24of ingress nginx
14:27so we have
14:28this service
14:29ingress nginx controller
14:30where actually
14:31our requests
14:32should come
14:33our HTTP requests
14:35by default
14:36they accept port
14:3680
14:37our HTTP requests
14:39by default
14:40they accept port
14:41443
14:42this is basically
14:44a service
14:45ingress
14:45ingress
14:46is an individual
14:47component
14:48but
14:48ingress
14:49components
14:50are set up
14:51inside our service
14:52actually
14:54all requests
14:55accept
14:55but there is a problem
14:57here
14:57the problem is
14:58that when we use
14:59minicube
15:00when we use
15:01production level
15:02kubectl
15:02our local
15:03setup
15:04automatically
15:05by default
15:07the ingress
15:08controller
15:08is created
15:09type
15:10node port
15:11the type
15:12ideally
15:12to be able
15:13to make it an entry point
15:15to the entire cluster
15:16the type should be load
15:17balancer
15:18external services
15:19we had created
15:21that service type
15:21is load balancer
15:22then
15:23we can access it
15:25by default
15:27type
15:27created
15:28which kubernetes
15:29created
15:30that is node
15:31port
15:31this is not load balancer
15:32so the first problem is
15:33that the type is node
15:34port
15:34and it should ideally be load
15:36balancer
15:36which is generally
15:37production level
15:37setup
15:38plus
15:39this service
15:39has no external IP
15:41if we don't have
15:42external IP
15:43then we can't expose it
15:44outside the browser
15:44with this
15:46another additional problem
15:47which exists with our local
15:48setup
15:49the problem basically
15:50is that
15:50we have this setup
15:52that exists
15:52now
15:53this whole setup
15:55this is inside
15:57our host machine
15:58host machine
15:59means that
16:00we have no computer
16:01we have Windows
16:02or Linux
16:03or Mac
16:04so we are working on
16:05any operating system
16:06that operating system
16:08is basically
16:09our host
16:09now
16:10this whole
16:11Kubernetes
16:11setup
16:12this is not
16:13directly on the
16:15host machine
16:15we have focused on
16:16that in the beginning
16:17when we started work with
16:18Minikube
16:19we have talked about
16:20that before
16:20we have to start our
16:22Docker desktop
16:24and if I look at my
16:25Docker desktop
16:27there is basically
16:28a container
16:29which is called
16:29minikube
16:30which is running
16:31actually
16:32which is our
16:33host machine
16:34if this is the
16:35host machine
16:36on this host
16:38we have
16:39Docker
16:39setup
16:40and in
16:40Docker
16:41this is a
16:42Docker container
16:44which is running
16:45and this
16:46Docker container
16:47is our
16:49minikube
16:50which works
16:51and this
16:52minikube
16:53we have
16:53ingress
16:54set up
16:55we have
16:56when we are
16:58exposed
16:58which means
16:59we are exposed
17:00to minikube
17:01what is
17:04ingress
17:04our
17:05entry point
17:06will be
17:06for our
17:07cluster
17:07so
17:08that means
17:08minikube
17:09cluster
17:09ingress
17:11will be
17:11the
17:11entry point
17:12for our
17:12application
17:13which is
17:14exposed
17:15for
17:15HTTP
17:16which is
17:17exposed
17:18now
17:29the problem is
17:31this
17:31port
17:32is
17:32Docker
17:33container
17:33not
17:34the
17:35host
17:35machine
17:35port
17:36so
17:36host
17:37machine
17:37and
17:38our
17:38minikube
17:38cluster
17:39actually
17:39different
17:40networks
17:40if
17:41Docker
17:42container
17:42not
17:43and
17:43directly
17:43our
17:44host
17:45machine
17:45and
17:57minikube
17:57are not
17:58on the
17:58same
17:58network
17:59docker
18:00container
18:00run
18:01so
18:02port
18:02this
18:03is not
18:04exactly
18:04on the
18:05same
18:05network
18:05with the
18:06host
18:06machine
18:07this
18:11is
18:11not
18:11on
18:12the
18:12host
18:12machine
18:12this
18:13is
18:13inside
18:14a
18:14Docker
18:14container
18:15so
18:15direct
18:16access
18:17is
18:18not
18:18possible
18:19if
18:19we
18:21hello.com
18:22then
18:22hello.com
18:23will not
18:24in our
18:24container
18:26so
18:27we have
18:27two
18:27problems
18:28exist
18:28first
18:29this
18:30type
18:31should
18:31be
18:31ideally
18:32load
18:32balancer
18:33but
18:33by default
18:33minikube
18:34node
18:34port
18:35create
18:35second
18:36problem
18:36is
18:36this
18:38is
18:38not
18:38directly
18:39on the
18:39host
18:39machine
18:40this
18:40is
18:40not
18:40inside
18:40a
18:41Docker
18:41container
18:41so
18:42we
18:42need
18:42to
18:44request
18:44request
18:45but
18:47that
18:47request
18:48direct
18:49to
18:52this
18:53minikube
18:53here
18:54we
18:54use
18:55port
18:56forwarding
18:56port
18:57forwarding
19:04in our
19:06name
19:06name
19:07space
19:07we
19:07are using
19:08ingress
19:08nginx
19:10and
19:11we
19:12basically
19:14this
19:14controller
19:15forward
19:16we
19:17whatever
19:18request
19:18we
19:25forward
19:26to
19:27port
19:2880
19:28of
19:28the
19:29internal
19:29service
19:29we
19:32redirect
19:33to
19:34port
19:3480
19:35of
19:35ingress
19:36controller
19:36port
19:3780
19:38will
19:38redirect
19:39to
19:40our
19:40host
19:41machine
19:41port
19:4280
19:43this
19:46is
19:47the
19:47basic
19:47setup
19:47that
19:48we
19:48want to
19:48create
19:48a
19:57new
20:02tab
20:03let's
20:04clear
20:04this
20:05command
20:07running
20:08we
20:08will
20:08test
20:11basically
20:11this
20:12line
20:12we
20:13say
20:16that
20:18host
20:18inside
20:19if
20:20there is
20:21a request
20:22which
20:23is
20:23port
20:2380
20:2380
20:24we
20:24want to
20:26this
20:27port
20:28we
20:32forward
20:36ingress
20:36and
20:37services
20:37handle
20:37so
20:38this
20:38setup
20:39we
20:39want to
20:42use
20:42curl
20:43we
20:43define
20:43the
20:47host
20:48is
20:48going
20:49to
20:49be
20:49app.com
20:51hello.com
20:53that
20:54is
20:55hello.com
20:56and
20:57as
20:57request
20:58we
21:00basically
21:01send
21:02to
21:02http
21:04localhost
21:058080
21:06so
21:06hello.com
21:08request
21:08basically
21:09port
21:0980
21:0980
21:10as
21:11port
21:1180
21:11as
21:11as
21:12as
21:27port
21:3080
21:3180
21:3280
21:33we
21:33can
21:34also
21:35test
21:35something
21:36on the
21:36browser
21:36as
21:36we
21:37copy
21:37it
21:38generally
21:39if
21:40we
21:41go to
21:41port
21:4180
21:4181
21:42so
21:42our
21:43system
21:43will
21:43say
21:44that
21:44localhost
21:45refuse to
21:45connect
21:45because
21:45port
21:4680
21:4680
21:46one
21:46service
21:47running
21:47but
21:48if
21:48we
21:48go to
21:49port
21:4980
21:4980
21:50this
21:51is
21:51page
21:51not
21:52found
21:52because
21:52there
21:52is
21:53no
21:53valid
21:53page
21:53this
21:55is
21:55a
21:55simple
21:56text
21:56which
21:56will
21:56print
21:57but
21:58here
21:59we
21:59will
22:00look
22:03at
22:03the
22:11flow
22:11of
22:12our
22:12application
22:13is
22:13going
22:13to
22:13look
22:14something
22:14like
22:14this
22:14but
22:15generally
22:15production
22:16level
22:16we
22:16use
22:16an
22:17application
22:17load
22:17balancer
22:18the
22:21next
22:30thing
22:31that
22:31we
22:31are
22:31going
22:31to
22:31learn
22:31about
22:32is
22:32the
22:33package
22:33manager
22:33for
22:34Kubernetes
22:34because
22:35there are
22:36different
22:36versions
22:37that
22:37exist
22:38and
22:41there are
22:42two
22:47terms
22:48that
22:48we are going
22:49to focus on
22:49a lot
22:50which
22:50is
22:50helm
22:52charts
22:55that
22:55will
22:55understand
22:57that
22:58this
22:59is
23:00a
23:00package
23:00manager
23:01what
23:01exactly does
23:01that mean?
23:02we
23:06must have
23:07learnt
23:08about
23:08YUM
23:08we
23:08used
23:10a lot
23:10of
23:11package
23:11managers
23:13package
23:14managers
23:15in
23:15kubernetes
23:16has
23:17special
23:18package
23:18manager
23:18which
23:19is
23:19called
23:19helm
23:19is
23:20very popular
23:21what
23:22exactly
23:22do we
23:23mean
23:23package
23:23manager
23:26for
23:27example
23:28this
23:28is
23:29our
23:29cluster
23:29and
23:30this
23:30cluster
23:31we
23:31have
23:31set up
23:33for
23:33this
23:34application
23:34we
23:35set up
23:42for
23:42this
23:42application
23:43we
23:43want
23:43to set up
23:45monitoring
23:45there
23:47are
23:48multiple
23:48applications
23:49additional
23:49tools
23:49additional
23:50resources
23:50that
23:51we
23:51want
23:54to
23:54set
24:03up
24:03an
24:03alert
24:04manager
24:04to
24:05send
24:06us
24:06alerts
24:08we
24:09have
24:12alert
24:13manager
24:14so
24:14we
24:15three
24:15additional
24:15services
24:16as part
24:17of
24:17monitoring
24:18setup
24:18of
24:19our
24:19application
24:19we
24:20need
24:23multiple
24:30deployments
24:31create
24:31multiple
24:32deployments
24:32and
24:32we
24:33have
24:33many
24:34several
24:34services
24:34that
24:35we
24:35need to
24:35use
24:36there
24:37might
24:38be
24:38a lot
24:38of
24:39config maps
24:39that
24:39we
24:40are going
24:40to use
24:40secrets
24:41that
24:41we
24:41are going
24:41to use
24:42to
24:42install
24:43and
24:44set up
24:45with
24:47multiple
24:48components
24:48and
24:49for
24:50every
24:50component
24:51we
24:51will
24:51end up
24:55using
24:55multiple
24:56configuration
24:57files
24:57that
24:57we
24:57need to
25:00create
25:02multiple
25:04configuration
25:05files
25:06set up
25:07and
25:07install
25:07and
25:08because
25:09it is
25:09error
25:09prone
25:10it is
25:10error
25:11and
25:11prone
25:11and
25:11it is
25:11error prone
25:12this
25:12whole
25:12set up
25:28bundle
25:29into
25:29a
25:30package
25:30and
25:31we
25:32need to
25:33set up
25:34only
25:35this
25:35package
25:36and
25:36our
25:38work will
25:39be
25:39easy
25:39install
25:41and
25:42set up
25:43into
25:43our
25:44system
25:44and
25:45yaml
25:46configurations
25:46run
25:47and
25:48apply
25:48so
25:49this
25:49is
25:50exactly
25:50what
25:51Helms
25:51does
25:51for
25:52us
25:52so
25:52this
25:53is
25:53exactly
25:53what
25:53Helms
25:53does
25:54us
25:54so
25:54is
25:55this
25:55helps
25:55which
25:57we have
25:58multiple
25:58yaml
26:00configuration
26:00files
26:01which
26:01we can
26:01set up
26:03and
26:03this
26:03bundle
26:04package
26:05which
26:06we can
26:06create
26:06and
26:13distribute
26:16across
26:17multiple
26:18teams
26:18and
26:19developers
26:19this
26:20entire
26:20process
26:25and
26:26we
26:26can
26:28publish
26:30onto
26:32Docker
26:33hub
26:33similarly
26:34when
26:35we
26:35talk about
26:35we can
26:37push
26:37onto
26:38github
26:39and
26:39we can
26:40publish
26:42onto
26:46platform
26:47called
26:48artifact
26:49hub
26:50this
26:51was
26:51previously
26:51called
26:52helm
26:52hub
26:52but
26:53now
26:53its
26:53name
26:53changed
26:53to
26:54artifact
26:54hub
26:55which
26:55we can
26:56the
26:56helm charts
26:56publish
26:57publish
26:57publish
26:57so
26:58when
26:58we create
27:00two
27:01particular
27:01use cases
27:02we can
27:05install
27:05and
27:06use
27:07it will make
27:08our entire development process very easy with kubernetes
27:11and
27:12second use case
27:12we can
27:13publish
27:14and publish
27:15where
27:16publish
27:16we have this public repository of all the helm charts
27:22which is called artifact hub where we can publish our helm charts
27:26and
27:27we have a lot of private repositories
27:29like
27:30some companies
27:31which may be using kubernetes
27:32but
27:33they don't want to expose their help charts
27:35publicly
27:36so
27:37in this case
27:37we have a lot of private repositories
27:39to create
27:40multiple platforms
27:41which exist
27:42one is
27:43chart museum
27:44another is
27:44harbor
27:45so
27:45we have multiple private options
27:47if we look at artifact hub
27:50this is the link for artifact hub.io
27:53and here
27:53we can search any cloud native package
27:56for example
27:57if i want to search for mysql
28:00i have
28:00these packages for mysql
28:02so i can go to
28:03this
28:04package
28:04and here
28:05i have all the information about how to install this particular package
28:09basically
28:10helm install is the particular command
28:12and after that we define our chart name
28:14so
28:14whatever helm chart
28:15will be installed
28:17so
28:17the first and primary use case
28:21for usage
28:22that is
28:23that is
28:23helm is a
28:25package manager
28:25for kubernetes
28:27but
28:28with this
28:28another use case
28:30which is
28:31that it is a
28:31templating engine
28:33templating engine
28:34means
28:35that
28:35let's suppose
28:36we have a single application
28:37in this single application
28:40we want to create multiple microservices
28:43so
28:44this might be my microservice
28:46one
28:46this might be my microservice
28:47two
28:48now microservices
28:49two applications
28:50are identical
28:50these are the applications
28:52almost identical
28:53within these
28:54there are just a few changes
28:55a few changes
28:56can be
28:57this is version v1
28:59and this might be version v2
29:00this can be different
29:01this can be different
29:03this can be different
29:03so
29:03in values
29:04there are some small changes
29:05but
29:06overall the configuration
29:07should be the same
29:08in this way
29:09when the situation
29:10happens
29:11so
29:12one way is
29:13we create a different
29:14yaml file
29:14we create a different
29:16yaml file
29:17and
29:18second way
29:19we create a common
29:20template
29:21we have created a yaml
29:23configuration file
29:24but
29:25this is basically
29:26a template file
29:27we can use
29:28dynamic values
29:29use
29:30this means
29:31here
29:32we will exist
29:34but
29:35in version
29:36we will give
29:36dynamic value
29:37in version
29:39we will pass
29:39v1
29:40and in version
29:41v2
29:42what does
29:43as a templating engine
29:45act
29:45and we help
29:46these templates
29:46create
29:47when we create
29:49static value
29:52we can use
29:54dynamic values
29:54and
29:55on the application
29:56basis
29:57different microservices
29:58here we have
29:58two services
29:59if we have
30:0020 microservices
30:02create
30:02then
30:02we can feed
30:04these values
30:04dynamically
30:06and
30:07this yaml template
30:08is called
30:08the template file
30:09this particular file
30:12here
30:13we have seen
30:13a normal yaml configuration
30:14here
30:15we have
30:16name
30:17application
30:18meaning
30:18those values
30:19dynamically
30:20change
30:21have not defined
30:22they are not static values
30:24but they are dynamic values
30:25which can change
30:25so this is the template file
30:27in which
30:27dynamically values
30:29.values
30:30.name
30:32.values
30:32.image
30:34.values
30:35.port
30:36.values
30:36and these values
30:38are feed
30:38in our template file
30:40values
30:41.yaml
30:41so this
30:43values.yaml
30:44file
30:45we define
30:46our values
30:46define
30:47like
30:48name
30:49which value
30:49will come
30:50here
30:50this name
30:50will come
30:51here
30:51and here
30:52use
30:54similarly
30:55this value
30:56will be used
30:57here
30:57this value
30:59will be used
31:00here
31:00now
31:00we have created
31:01values
31:01.yaml
31:02and we can create
31:03another value
31:04.yaml
31:05so
31:05values
31:06.yaml
31:06that is
31:08.values
31:08name
31:09and
31:09and
31:10this
31:11object
31:11different
31:11properties
31:12access
31:13our
31:14dynamic values
31:15feed
31:16with
31:18multiple
31:18configurations
31:20can
31:20use
31:20so
31:21this is something
31:22which is very helpful
31:23in
31:23CI
31:23cd
31:24that is
31:24continuous
31:24integration
31:25continuous
31:25deployment
31:26so
31:27this is something
31:28which is very helpful
31:36in CI
31:37CD
31:38that is
31:38continuous
31:39integration
31:49deployment
31:50values
31:50.yaml
31:51file
31:51a
31:52common
31:52template
31:53feed
31:53when we are implementing
31:55the CI
31:55CD pipeline
31:58now
31:59we can use existing
32:00helm charts
32:01we can create
32:04helm charts
32:05we have a common
32:06format
32:07which is called
32:08the helm chart
32:08structure
32:09we have to create
32:10a common
32:11folder
32:14this is
32:15the
32:16helm
32:16chart
32:18name
32:20that is
32:21our
32:22folder
32:22here
32:23we have
32:25multiple
32:27sub
32:28folders
32:28which
32:29we create
32:29first
32:30is called
32:31charts
32:32basically
32:33contains
32:33the
32:34dependencies
32:36for our
32:37particular
32:37helm chart
32:38which
32:39already
32:39set up
32:41for that
32:41chart
32:42to work
32:42all
32:42our
32:43charts
32:43folder
32:44this is
32:45basically
32:46similar
32:46to the
32:46node
32:47modules
32:47folder
32:48which
32:48is called
32:52templates
32:53our
32:54actual
32:55template
32:55file
32:55configuration
32:56files
32:57store
32:58next
32:58next
32:59file
32:59is
32:59chart.yaml
33:00chart.yaml
33:01contains
33:01the metadata
33:02about our particular chart
33:03metadata
33:04means
33:05what is our chart
33:05name
33:06version
33:07in fact
33:08different
33:09dependencies
33:09what is our
33:10basic information
33:11the metadata
33:12about data
33:13is stored
33:14in our chart.yaml
33:15plus
33:16we have
33:16values.yaml
33:17where
33:18our actual values
33:19will replace
33:20those values
33:22here
33:24store
33:25these are the
33:26values which are
33:27dynamic
33:27which we can change
33:28within
33:29my chart
33:29can exist
33:31like
33:32license
33:32file
33:32read
33:33so
33:33additional
33:34files
33:35can exist
33:35in our
33:35helm chart
33:36structure
33:37so
33:37when
33:38we create
33:38that
33:39structure
33:40is
33:41used
33:41this way
33:41we create
33:42and
33:43sometimes
33:43we want to use
33:44command
33:45which is
33:47helm
33:47install
33:47and
33:48our
33:48chart
33:48name
33:49by
33:51default
33:51for example
33:57mysql
33:58if we want to
33:58check the templates
34:00we can check the
34:01default values
34:02we can check the
34:03default values
34:03from here
34:04so
34:04this is
34:05values.yaml
34:06which is
34:06already stored
34:08now
34:08if we
34:09install
34:10but
34:11we don't want to use
34:12the default values
34:13we want to use
34:15default values
34:16we want to change
34:16in default values
34:17like
34:17here
34:18let's suppose
34:19if i want to change
34:20this image
34:21from mysql
34:22or if i want to change
34:23the image tag
34:24we want to use
34:24another image tag
34:26so
34:26for that
34:26we have a specific
34:28command line option
34:29which is called
34:30hyphen hyphen set
34:33we can change
34:35for example
34:36if i want to change
34:37the version
34:37i can change it to
34:39let's suppose
34:393.2
34:40so
34:40in this way
34:41we can set
34:41some particular value
34:42and some particular attribute
34:43we can set
34:44in this
34:45values.yaml
34:46we can use another file
34:48for another file
34:50we have another option
34:51which is hyphen
34:52hyphen values
34:53we can write hyphen
34:55hyphen values
34:56i can do
34:57my values
34:58dot yaml
34:59we can use
35:00in default values
35:01we can use
35:03so we can use these
35:04particular options
35:05to overwrite one value
35:06or all of the values
35:07generally
35:08when we talk about
35:09Helm as a package manager
35:10there is a common term
35:12which we get to hear
35:12every time
35:13every time
35:14when we use Stack Overflow
35:15or other resources
35:16in Helm
35:17and that term
35:18is called tiller
35:19tiller is something
35:20which is deprecated
35:21in Helm
35:22which we don't use
35:23but since this is a term
35:24which is used
35:25on multiple platforms
35:26so we can understand
35:26this one
35:28basically
35:28in Helm
35:29the latest version
35:30that is version 3
35:31before we have
35:32version 2
35:33in which
35:34tiller was something
35:35that was used
35:35now version 3
35:36which is latest version
35:37that is deprecated
35:39what exactly is tiller
35:41so version 2
35:42tiller was something
35:42which helps us
35:43in release management
35:45if we wanted to create
35:46new deployment
35:47version 2
35:48we are talking about
35:49so all the requests
35:50are in CLI
35:51now
35:52this has all the
35:53deployment configs
35:54this deployment configs
35:56was in CLI
35:56version 2
35:57forwarded to a
35:58back-end server
35:59which we called
35:59tiller
36:00this back-end server
36:02was in deployment
36:03configs
36:04now this back-end
36:05server
36:05was stored
36:07older
36:08as well as
36:09newer deployment
36:10configs
36:11so this tiller
36:12had the history
36:12of all of the
36:13chart executions
36:14that exist
36:15in fact
36:16if there is a newer
36:16version
36:17which basically
36:17fails
36:20tiller has
36:20capability
36:21to roll back
36:22to the older
36:23version
36:23which is working
36:24in a good way
36:24so tiller was an essential
36:26component of version 2
36:28of helm
36:28but tiller
36:29useful
36:29was also a security concern
36:31because tiller
36:32there was a lot of access
36:33of the entire cluster
36:34to be able to create
36:36update
36:36or delete things
36:37in the cluster
36:38which was a big
36:40security concern
36:41so helm
36:41latest version
36:42which is version 3
36:43this is something
36:44that has been deprecated
36:45so that's why
36:45we don't use it anymore
36:47so here
36:48we have done
36:49and studied
36:50a lot of things
36:51about kubernetes
36:52we have talked about
36:53clusters
36:54we have talked about
36:55different components
36:56services
36:57ingress
36:57config map
36:59secret
36:59practically
37:00deployments
37:01ports
37:01practically
37:02applications
37:02how do we use
37:03artifact hub
37:05how do we work
37:05in which way
37:06our helm charts
37:07work
37:07so in this way
37:08we have studied
37:09many things
37:09and these are all
37:13the essential
37:13core components
37:14of kubernetes
37:15which we should
37:16use kubernetes
37:17as a developer
37:19as a developer
37:19so i hope
37:20that kubernetes
37:21will have
37:22thoroughly enjoyed
37:23plus
37:24we have learned
37:26many useful things
37:26from them
37:27development
37:28or devops
37:29tools
37:29docker
37:29docker
37:30decompose
37:31kubernetes
37:31these things
37:32are evergreen
37:33and ever-evolving
37:34they have many new
37:36things
37:36that are coming
37:36with time
37:37and we can learn
37:38all these things
37:40because
37:40the core concepts
37:41are clear
37:42fundamentals
37:45we have cleared
37:46from our lecture
37:47so there are
37:48a lot of things
37:48that we can go
37:49and learn out there
37:50in our docker
37:51and kubernetes journey
37:51so i wish you all
37:52the best in your
37:53future development
37:53and devops journey
37:54to the next lecture
37:56till then
37:57keep learning
37:57and keep exploring
37:58so i think