YT YouTube2Text

YouTube2Text → Transcripts → Kubernetes Crash Course for Absolute Beginners [NEW]

Kubernetes Crash Course for Absolute Beginners [NEW] — Transcript

by TechWorld with Nana · 10,204 words · 1,713 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:00hello and welcome to the kubernetes
0:03crash course where i will teach you
0:05everything you need to know to get
0:07started with kubernetes in one hour
0:10i am nana and i have taught hundreds of
0:13thousands of people how to advance their
0:15devops skills through my youtube channel
0:18online courses and the devops
0:20educational program
0:21if you're new here be sure to subscribe
0:24because i upload new videos all the time
0:27now let's look at an overview of what
0:29you will learn
0:30first of all we'll see what is
0:32kubernetes and why do we need it and why
0:34did it become so popular
0:37second we will go through the kubernetes
0:38architecture and you will see how
0:40kubernetes actually works in the
0:42background
0:43after that we will cover main kubernetes
0:46components that you need to learn to
0:48work efficiently with kubernetes and
0:51finally we will do a hands-on demo
0:53project to get your first practical
0:56experience with kubernetes now
0:58kubernetes is a very popular but also a
1:01very complex technology so this crash
1:04course will help you get your first
1:06experience to get started with
1:08kubernetes but if by the end of the
1:10video you decide to deepen your
1:12knowledge in kubernetes and are thinking
1:15about a career as a kubernetes
1:17administrator my new complete kubernetes
1:20administrator course will be a great
1:22resource for you where you will learn
1:24how to build configure and manage
1:26kubernetes clusters from scratch
1:29the course is also dedicated to help you
1:32pass the cka exam from linux foundation
1:35to become a certified kubernetes
1:37administrator now we have a lot to cover
1:40in this video so let's jump right into
1:43it
1:44so let's jump in right into the
1:45definition what is kubernetes
1:48so kubernetes is an open source
1:49container orchestration framework which
1:52was originally developed by google so on
1:54the foundation it manages containers be
1:57docker containers or from some other
1:59technology which basically means that
2:02kubernetes helps you manage applications
2:05that are made up of hundreds or maybe
2:08thousands of containers and it helps you
2:11manage them in different environments
2:13like physical machines virtual machines
2:16or cloud environments or even hybrid
2:19deployment environments
2:23so what problems does kubernetes solve
2:26and what are the tasks of a container
2:29orchestration tool actually so to go
2:32through this chronologically
2:34the rise of microservices caused
2:36increased usage of container
2:38technologies because the containers
2:40actually offer the perfect host for
2:43small
2:44independent applications like
2:46microservices
2:48and the rise of containers and the micro
2:50service technology actually resulted in
2:53applications they're now comprised of
2:55hundreds or sometimes maybe even
2:57thousands of containers managing those
3:00loads of containers across multiple
3:02environments using scripts and self-made
3:06tools can be really complex
3:08and sometimes even impossible so that
3:11specific scenario actually caused the
3:14need for
3:15having container orchestration
3:17technologies
3:21so what those orchestration tools like
3:23kubernetes do is
3:25actually guarantee following features
3:28one is high availability in simple words
3:32high availability means that the
3:34application has no downtime so it's
3:36always accessible by the users a second
3:40one is scalability which means you can
3:43scale your applications fast when you
3:46have more load on it and more users are
3:49trying to access it and the same way you
3:51can easily scale it down when the load
3:53goes down
3:55so it makes your application more
3:56flexible to adjust to the increasing or
3:59decreasing load and the third one is
4:03disaster recovery which basically means
4:05that if an infrastructure has some
4:06problems like data is lost or the
4:09servers explode or something bad happens
4:11with the service center the
4:12infrastructure has to have some kind of
4:14mechanism to back up the data and to
4:16restore it to the latest state so that
4:19application doesn't actually lose any
4:21data and the containerized application
4:23can run from the latest state after the
4:26recovery
4:27and all of these are functionalities
4:29that
4:30container orchestration technologies
4:32like kubernetes offer so how does the
4:34kubernetes basic architecture actually
4:36look like
4:37the kubernetes cluster is made up with
4:40at least one master node
4:43and then connected to it you have
4:45a couple of worker nodes where each node
4:49has a cubelet process running on it and
4:52cubelet is actually a kubernetes process
4:55that makes it possible for the cluster
4:58to talk to each other to communicate to
5:00each other and actually execute some
5:03tasks on those nodes like running
5:05application processes
5:07each worker node has containers of
5:10different applications deployed on it so
5:12depending on how the workload is
5:15distributed you would have different
5:17number of docker containers running on
5:20worker nodes and worker nodes are where
5:23the actual work is happening so here is
5:25where your applications are running so
5:28the question is what is running on
5:30masternode
5:31masternode actually runs several
5:34kubernetes processes that are absolutely
5:37necessary
5:38to run and manage the cluster properly
5:41one of such processes is an api server
5:44which also is a container an api server
5:47is actually the entry point to the
5:49kubernetes cluster so this is the
5:51process
5:52which the different kubernetes clients
5:54will talk to like ui if you're using
5:56kubernetes dashboard an api if you're
5:59using some scripts and automating
6:02technologies and a command line tool so
6:05all of these will talk to the api server
6:07another process that is running on
6:09master node is a controller manager
6:12which basically keeps an overview of
6:14what's happening in the cluster whether
6:16something needs to be repaired or maybe
6:19if a container died and it needs to be
6:21restarted etc
6:23and another one is
6:25scheduler which is basically responsible
6:27for scheduling
6:29containers on different nodes based on
6:31the workload and the available server
6:34resources on each node so it's an
6:37intelligent
6:38process that decides on which worker
6:41node the next container should be
6:44scheduled on based on the available
6:46resources on those worker nodes and the
6:48load that that container needs and
6:51another very important component of the
6:53whole cluster is actually an etcd key
6:56value storage which basically holds at
6:59any time the current state of the
7:02kubernetes cluster so it has all the
7:04configuration data inside
7:06and all the status data of each node and
7:09each container inside of that node and
7:12the backup and restore that we mentioned
7:14previously is actually made from these
7:16etcd snapshots because you can recover
7:20the whole cluster state using that etcd
7:24snapshot and last but not least also a
7:26very important component of kubernetes
7:29which enables those nodes worker nodes
7:32masternodes talk to each other is the
7:34virtual network that spans all the nodes
7:37that are part of the cluster and in
7:39simple words virtual network actually
7:42turns
7:43all the nodes inside of a cluster into
7:46one powerful machine that has the sum of
7:50all the resources of individual nodes
7:53one thing to be noted here is that
7:55worker knows because they actually have
7:58most load because they are running the
8:01applications on inside of it usually are
8:04much bigger and have more resources
8:07because they will be running hundreds of
8:08containers inside of them whereas master
8:11node will be running just a handful of
8:14master processes like we see in this
8:16diagram so it doesn't need that many
8:18resources however as you can imagine
8:20masternode is much more important than
8:23the individual worker nodes because if
8:25for example you lose a masternode access
8:29you will not be able to access the
8:31cluster anymore and that means that you
8:34absolutely have to have a backup of your
8:36master at any time so in production
8:39environments usually you would have at
8:41least two masters inside of your
8:44kubernetes cluster but in more cases of
8:46course you're going to have multiple
8:48musters where if one muster node
8:51is down the cluster continues to
8:54function smoothly because you have other
8:56masters available
8:59in this video we're going to learn about
9:01the main kubernetes components that we
9:04as kubernetes administrators or users
9:07will be working with most of the time to
9:10make it easier to understand all these
9:12components i'm gonna build a simple use
9:14case of a web application with a simple
9:17database and i'm gonna show you step by
9:20step how each component in kubernetes
9:23helps you deploy such an application
9:25setup and what is the role of each of
9:27these components
9:31so let's start with the basic setup of a
9:34worker node or in kubernetes terms a
9:37node
9:38which is a simple server a physical or
9:41virtual machine and the basic component
9:43or the smallest unit of kubernetes is a
9:47pod so what pod is is basically an
9:50abstraction over a container so if
9:52you're familiar with docker containers
9:55or container images so basically what
9:57pod does is it creates this running
10:00environment or a layer on top of the
10:03container
10:04and the reason is because kubernetes
10:06wants to abstract away the container
10:09runtime or container technologies so
10:11that you can replace them if you want to
10:14and also because you don't have to
10:16directly work with docker or whatever
10:19container technology you use in a
10:21kubernetes so you only interact with the
10:23kubernetes layer so we have an
10:25application pod which is our own
10:27application and that will maybe use a
10:30database pod with its own container and
10:32this is also an important concept here
10:35pod is usually meant to run one
10:38application container inside of it you
10:41can run multiple containers inside one
10:43pod but usually it's only the case if
10:45you have one main application container
10:48and the helper container or some side
10:51service that has to run inside of that
10:54pod
10:55and as you see this is nothing special
10:57you just have one server and two
10:58containers running on it with a
11:00abstraction layer on top of it so now
11:02let's see how they communicate with each
11:04other in kubernetes world so kubernetes
11:07offers out of the box a virtual network
11:09which means that each
11:10pod gets its own ip address not the
11:14container the pod gets the ip address
11:16and each pod
11:18can communicate with each other using
11:20that ip address which is an internal ip
11:22address obviously it's not the public
11:24one so my application container can
11:27communicate with database using the ip
11:30address however pod components in
11:33kubernetes also an important concept are
11:36ephemeral which means that they can die
11:39very easily
11:40and when that happens for example if i
11:42lose a database container because the
11:45container crashed because the
11:47application crashed inside or because
11:50the nodes the server that i'm running
11:53them on
11:54ran out resources the pod will die
11:57and a new one will get created in its
11:59place and when that happens it will get
12:02assigned a new ip address which
12:04obviously is inconvenient if you are
12:07communicating with the database using
12:08the ip address because now you have to
12:10adjust it every time pod restarts and
12:13because of that another component of
12:16kubernetes called service is used
12:21so service is basically a static ip
12:24address or permanent ip address that can
12:27be attached so to say to each pod so my
12:31app will have its own service and
12:32database pod will have its own service
12:35and the good thing here is that the life
12:38cycles of service and the pod are not
12:41connected so even if the pod dies
12:44the service and its ip address will stay
12:48so you don't have to change that
12:51endpoint anymore
12:52so now obviously you would want your
12:55application to be accessible through a
12:57browser right and for this you would
12:59have to create an external service so
13:01external services a service that opens
13:04the communication from external sources
13:07but obviously you wouldn't want your
13:09database to be open to the public
13:12requests and for that you would create
13:14something called an internal service so
13:17this is a type of a service that you
13:20specify when creating one however if you
13:23notice the url of
13:26the external service is not very
13:29practical so basically what you have is
13:32an http protocol with a node ip address
13:36so of the node not the service and the
13:39port number of the service which is
13:42good for test purposes if you want to
13:44test something very fast but not for the
13:46end product so usually you would want
13:48your url to look like this if you want
13:50to talk to your application with a
13:53secure protocol and a domain name and
13:56for that
13:57there is another component of kubernetes
14:00called ingress so instead of service the
14:03request goes first to ingress and it
14:05does the forwarding then to the service
14:08so now we saw some of the very basic
14:10components of kubernetes and as you see
14:12this is a very simple setup we just have
14:14a one server and a couple of containers
14:17running and some services nothing really
14:21special where kubernetes advantages or
14:24the actual cool features really come
14:26forward but we're gonna get there step
14:28by step so let's continue
14:34so as we said pods communicate with each
14:36other using a service so my application
14:39will have a database endpoint let's say
14:42called mongodb service that it uses to
14:45communicate with the database but
14:48whether you configure usually this
14:50database url or endpoint usually you
14:53would do it in application properties
14:55file or as some kind of external
14:58environmental variable but usually it's
15:00inside of the built image of the
15:03application so for example if the
15:06endpoint of the service or service name
15:08in this case changed to mongodb you
15:11would have to adjust that url in the
15:13application so usually you'd have to
15:16rebuild the application with a new
15:18version and you have to push it to the
15:20repository and now you'll have to
15:23pull that new image in your pod and
15:26restart the whole thing so a little bit
15:28tedious for a small change like database
15:32url so for that purpose kubernetes has a
15:35component called config map so what it
15:38does is it's basically your external
15:40configuration to your application so
15:43config map would usually contain
15:45configuration data like urls of a
15:48database or some other services that you
15:50use and in kubernetes you just connect
15:53it to the pod so that pod actually gets
15:56the data that config map contains
15:59and now if you change the name of the
16:01service the endpoint of the service you
16:03just adjust the config map and that's it
16:06you don't have to build a new image and
16:08have to go through this whole cycle now
16:11part of the external configuration can
16:13also be database username and password
16:16right which may also change in the
16:19application deployment process but
16:21putting a password or other credentials
16:24in a config map in a plain text format
16:27would be insecure even though it's an
16:29external configuration so for this
16:31purpose kubernetes has another component
16:34called secret
16:36so secret is just like config map but
16:39the difference is that it's used to
16:41store secret data credentials for
16:44example and it's stored not in a plain
16:46text format but in base 64 in encoded
16:50format but of course basics before
16:52encoding a secret doesn't make it
16:53automatically secure
16:55the secret components are meant to be
16:58encrypted
16:59using third-party tools in kubernetes
17:02because kubernetes doesn't encrypt them
17:04out of the box
17:05and there are tools for that from cloud
17:07providers or separate third-party tools
17:10that you can
17:11deploy on kubernetes to encrypt your
17:13secrets and that will make secrets
17:16secure
17:17so secret would contain things like
17:20credentials and of course i mean
17:22database user you could also put in
17:23config map but what's important is the
17:26passwords certificates things that you
17:29don't want other people to have access
17:31to would go in the secret and just like
17:34config map you just connect it to your
17:36pod so that pod can actually see those
17:38data and read from the secret you can
17:41actually use the data from configmap or
17:44secret inside of your application pod
17:47using for example environmental
17:49variables or even as a properties file
17:52so now let's see another very important
17:54concept generally which is data storage
17:58and how it works in kubernetes
18:00so we have this database pod that our
18:02application uses and it has some data or
18:04it generates some data with this setup
18:06that you see now if the database
18:09container or the pod gets restarted
18:12the data would be gone and that's
18:15problematic and inconvenient obviously
18:18because you want your database data or
18:20log data to be persisted reliably long
18:24term
18:25and the way you can do it in kubernetes
18:27is using another component of kubernetes
18:30called volumes
18:32and how it works is that it basically
18:34attaches a physical storage on a hard
18:37drive to your pod and that storage could
18:40be either on a local machine meaning on
18:42the same server node where the pod is
18:45running or it could be on a remote
18:47storage meaning outside of the
18:49kubernetes cluster it could be a cloud
18:52storage or it could be your own premise
18:54storage which is not part of the
18:56kubernetes cluster so you just have an
18:59external reference on it so now when the
19:01database pod or container gets restarted
19:04all the data will be there persisted
19:07it's important to understand the
19:08distinction between the kubernetes
19:10cluster and all of its components and
19:13the storage
19:14regardless of whether it's a local or
19:17remote storage think of a storage as an
19:20external hard drive plugged in into the
19:23kubernetes cluster because the point is
19:26kubernetes cluster explicitly doesn't
19:28manage any data persistence which means
19:31that you as a kubernetes user or an
19:33administrator are responsible for
19:36backing up the data replicating and
19:38managing it and making sure that it's
19:40kept on a proper hardware etc because
19:43it's not taking care of kubernetes
19:50so now let's see everything is running
19:51perfectly and a user can access our
19:53application through a browser
19:56now with this setup what happens if my
19:59application pod dies right crashes or i
20:02have to restart the pod because i built
20:06a new container image
20:08basically i would have a downtime where
20:11a user can reach my application which is
20:14obviously a very bad thing
20:16if it happens in production and this is
20:19exactly the advantage of distributed
20:21systems and containers
20:23so instead of relying on just one
20:25application part and one database part
20:28etc
20:29we are replicating everything
20:32on multiple servers
20:34so we would have another node where a
20:37replica or clone of our application
20:40would run which will also be connected
20:43to the service so remember previously we
20:45said the service is like a persistent
20:48static ip address with a dns name so
20:51that you don't have to
20:53constantly adjust the end point when a
20:56pod dies
20:57but service is also a load balancer
20:59which means that the service will
21:01actually catch the request and forward
21:03it to whichever part is least busy so it
21:05has both of these functionalities
21:08but in order to create the the second
21:10replica of the my application pod you
21:13wouldn't create a second part but
21:15instead you will define a blueprint for
21:18a my application pod and specify how
21:20many replicas of that pod you would like
21:23to run and that component or that
21:25blueprint is called deployment which is
21:28another component of kubernetes and in
21:31practice you would not be working with
21:33pods or you would not be creating pods
21:36you would be creating deployments
21:38because there you can specify how many
21:40replicas and you can also scale up or
21:43scale down the number of replicas of
21:46pots that you need so with pot we said
21:48that pot is a layer of abstraction on
21:51top of containers
21:53and deployment is another abstraction on
21:56top of pots which makes it more
21:58convenient to interact with the pods
22:00replicate them and do some other
22:02configuration
22:04so in practice you would mostly work
22:06with deployments and not with pods so
22:09now if one of the replicas of your
22:11application pod would die the service
22:13will forward the requests to another one
22:17so your application would still be
22:18accessible for the user so now you're
22:20probably wondering what about the
22:22database pod because if the database
22:25part died your application also wouldn't
22:27be accessible so we need a
22:30database replica as well however we
22:32can't replicate database using a
22:35deployment and the reason for that is
22:37because database has a state which is
22:41its data
22:42meaning that if we have clones or
22:44replicas of the database they would all
22:47need to access the same
22:50shared
22:50data storage and there you would need
22:53some kind of mechanism that manages
22:56which parts are currently writing to
22:58that storage or which pods are reading
23:01from the storage in order to avoid data
23:04inconsistencies and that mechanism
23:08in addition to replicating feature is
23:11offered by another kubernetes component
23:14called statefulset so this component is
23:17meant specifically for applications like
23:20databases so mysql mongodb
23:24elasticsearch or any other stateful
23:27applications or databases
23:30should be created using stateful sets
23:32and not deployments
23:34it's a very important distinction
23:36and stateful said just like deployment
23:39would take care of
23:40replicating the pots and scaling them up
23:44or scaling them down but making sure the
23:46database reads and writes are
23:48synchronized so that no database
23:51inconsistencies are offered however i
23:54must mention here that deploying
23:56database applications using stateful
23:59sets
24:00in kubernetes cluster can be somewhat
24:03tedious so it's definitely more
24:05difficult than working with deployments
24:08where you don't have all these
24:09challenges that's why it's also a common
24:12practice to host database
24:14applications outside of the kubernetes
24:17cluster and just have the deployments or
24:20stateless applications
24:22that replicate and scale with no problem
24:24inside of the kubernetes cluster and
24:27communicate with the external database
24:29so now that we have two replicas of my
24:31application pod and two replicas of the
24:34database and they're both load balanced
24:36our setup is more robust which means
24:39that now even if node one the whole node
24:42server was actually rebooted or crashed
24:46and nothing could run on it we would
24:48still have a second node with
24:50application and database pods running on
24:53it and the application would still be
24:55accessible by the user until these two
24:58replicas get recreated so you can avoid
25:01downtime
25:04so to summarize we have looked at
25:07the most used kubernetes components we
25:10start with the pods and the services in
25:12order to communicate between the parts
25:14and the ingress component which is
25:16used to route traffic into the cluster
25:19we've also looked at external
25:21configuration using config maps and
25:23secrets and data persistence using
25:26volumes and finally we've looked at pod
25:30blueprints with replicating mechanisms
25:33like deployments and stateful sets where
25:36stateful set is used specifically for
25:38stateful applications like databases
25:41just using these core components you can
25:44actually build pretty powerful
25:46kubernetes clusters
25:48before moving on i want to give a shout
25:50out to castin who made this video
25:52possible
25:54kessen's k10 is the data management
25:57platform for kubernetes
25:59k10 basically takes off most of the load
26:02of doing backup and restore in
26:04kubernetes from the cluster
26:06administrators it has a very simple ui
26:09so it's super easy to work with and has
26:12an intelligent logic which does all the
26:14heavy lifting for you and with my link
26:17you can download k10 for free and get 10
26:20nodes free forever to do your kubernetes
26:23backups so make sure to check out the
26:25link in the video description and now
26:27let's continue
26:28so now that we have seen the basic
26:30concepts of kubernetes how do we
26:32actually create those components like
26:34pods and services to configure the
26:37kubernetes cluster
26:41all the configuration in kubernetes
26:43cluster actually goes through a master
26:46node with the process called api server
26:48which we mentioned briefly earlier so
26:51kubernetes clients which could be a ui a
26:54kubernetes dashboard for example or an
26:56api which could be a script or a curl
26:59command
27:00or a command line tool like cubectl they
27:03all talk to the api server and they send
27:05their configuration requests to the api
27:08server which is the main entry point or
27:10the only entry point into the cluster
27:12and these requests have to be either in
27:15yaml format or json format and this is
27:18how example configuration in yaml format
27:21actually looks like so with this we are
27:23sending a request to kubernetes to
27:26configure a component called deployment
27:29which is basically a template or a
27:31blueprint for creating pods and in this
27:33specific configuration example we tell
27:36kubernetes to create two replica pods
27:39for us called my app with each pod
27:43replica having a container based on my
27:46image running inside in addition to that
27:49we
27:50configure what the environment variables
27:52and the port configuration of this
27:54container inside of the pod should be
27:57and as you see
27:58the
27:59configuration requests in kubernetes are
28:02declarative form so we declare what is
28:04our desired outcome from kubernetes
28:07and kubernetes tries to meet those
28:10requirements meaning for example since
28:12we declare we want two replica parts of
28:15my app deployment to be running in the
28:18cluster and one of those parts dies the
28:21controller manager will see that the
28:23ease and shoot states now are different
28:26the actual state is one part our desired
28:29state is 2 so it goes to work to make
28:32sure that this desired state is
28:35recovered automatically restarting the
28:38second replica of that pod
28:42so here i have examples of a deployment
28:45and service configuration files side by
28:48side so the first thing is that every
28:51configuration file in kubernetes has
28:54three parts the first part is where the
28:57metadata of that component that you're
29:00creating resides and one of the metadata
29:03is obviously name of the component
29:05itself the second part in the
29:08configuration file is specification so
29:11each component's configuration file will
29:14have a specification where you basically
29:16put every kind of configuration that you
29:19want to apply for that
29:21component the first two lines here as
29:24you see is just
29:25declaring what you want to create here
29:28we are creating deployment and here
29:30we're creating a service
29:32and this is basically you have to look
29:34up for each component there's a
29:36different api version
29:37so now inside of the specification part
29:40obviously the attributes will be
29:44specific to the kind of a component that
29:47you're creating so deployment will have
29:50its own attributes
29:52that only apply for deployment and the
29:54service will have its own stuff but i
29:57said there are three parts of a
29:58configuration file and
30:01we just see metadata and the
30:03specification so where's the third part
30:06so the third part will be a status but
30:09it's going to be automatically generated
30:12and edit by kubernetes so the way it
30:15works is that kubernetes will always
30:17compare what is the desired state and
30:20what is the actual state or the status
30:22of that component and if the status and
30:24desired state do not match then
30:27kubernetes knows there's something to be
30:29fixed there so it's gonna try to fix it
30:32and this is the basis of the
30:35self-healing feature that kubernetes
30:37provides for example here you specify
30:40you want two replicas of nginx
30:43deployment so when you apply this when
30:46you actually create the deployment using
30:48this configuration file that's what
30:50apply means kubernetes will add here the
30:52status of your deployment and it will
30:56update that state continuously so for
30:59example if a status at some point will
31:01say just one replica is running then
31:04kubernetes will compare that status with
31:07the specification and we'll know there
31:09is a problem there another replica needs
31:12to be created sap now another
31:14interesting question here is
31:16where does kubernetes actually get the
31:18status data to automatically add here or
31:22update continuously that information
31:24comes from the icd remember the cluster
31:27brain one of the master processes that
31:30actually stores the cluster data so it
31:33cd holds at any time the current status
31:37of any kubernetes component and that's
31:40where the status information comes from
31:46so as you see the format of the
31:48configuration files is yemel
31:51that's why the extension here and
31:54generally it's pretty straightforward to
31:56understand it's a very simple format but
31:58yaml is very strict about the
32:00indentations so for example if you have
32:04something wrongly indented here your
32:06file will be invalid but other than that
32:09it's pretty simple another thing is
32:11where do you actually store those
32:13configuration files a usual practice is
32:16to store them with your code because
32:19since the deployment and service is
32:22going to be applied to your application
32:24it's a good practice to store these
32:26configuration files in your application
32:28code so usually it will be part of the
32:31whole infrastructure as a code concept
32:34or you can also have its own git
32:37repository just for the configuration
32:39files
32:41so in this video i'm going to show you
32:43what mini cube and cube ctl are and how
32:46to set them up
32:47so first of all let's see what is mini
32:49cube usually in kubernetes world when
32:52you are setting up a production cluster
32:55it will look something like this so you
32:57would have multiple masters at least two
32:59in a production setting and you would
33:01have multiple worker nodes
33:03and master nodes and the worker nodes
33:06have their own separate responsibility
33:09so as you see on the diagram you would
33:10have actual separate virtual or physical
33:13machines that each represent a note
33:17now if you want to test something on
33:19your local environment or if you want to
33:22try something out very quickly for
33:23example deploying new application or new
33:27components and you want to test it on
33:29your local machine obviously setting up
33:31a cluster like this will be pretty
33:33difficult or maybe even impossible if
33:35you don't have enough resources like
33:37memory and cpu etc and exactly for the
33:41use case
33:42there's this open source tool that is
33:44called a mini cube so what a mini cube
33:46is is basically one node cluster where
33:50the master processes and the worker
33:52processes both run on one node and this
33:56node will have a docker container
33:58runtime pre-installed so you will be
34:01able to run the containers or the pods
34:03with containers on this node
34:07so now that you have this virtual node
34:10on your local machine that represents
34:12mini cube you need some way to interact
34:15with that cluster so you need a way to
34:17create pods
34:18and other kubernetes components on the
34:20node and the way to do it is using
34:23cubectl which is a command line tool for
34:26kubernetes cluster so let's see how it
34:28actually works remember we said that
34:30minicube runs both master and work
34:32processes so one of the master processes
34:35called api server is actually the main
34:38entry point into the kubernetes cluster
34:40so if you want to do anything in the
34:42kubernetes if you want to configure
34:44anything create any component you first
34:46have to talk to the api server and the
34:48way to talk to the api server is through
34:50different clients so you can have a ui
34:52like a dashboard you can talk to it
34:54using kubernetes api
34:56or a command line tool which is cubectl
35:00and cubectl is actually the most
35:02powerful of all the three clients
35:04because with cube cdl you can basically
35:06do
35:07anything in the kubernetes that you want
35:09and throughout this video tutorials
35:11we're going to be using cube ctl mostly
35:14so once the cube ctl submits commands to
35:16the api server to create components
35:18delete components etc the work processes
35:22on minicube node will actually make it
35:25happen so they will be actually
35:27executing the commands to create the
35:29parts to destroy the parts to create
35:31services etc so this is the mini cube
35:34setup and this is how cubectl is used to
35:37interact with the cluster an important
35:39thing to note here is that kipctl isn't
35:42just for minikube cluster if you have a
35:44cloud cluster or a hybrid cluster
35:47whatever cube ctl is the tool to use to
35:51interact with any type of kubernetes
35:53cluster setup so that's important to
35:55note here so now that we know what mini
35:57cube and cube ctl are let's actually
35:59install them to see them in practice
36:04now let's see how to install and run
36:07mini cube there are many different ways
36:10depending on your operating system and
36:12its architecture so the best way is to
36:15reference the official documentation and
36:17here as you see minicube can run either
36:20as a container or a virtual machine and
36:24these are the resource requirements to
36:26run minicube on your machine so make
36:29sure you have enough resources for
36:31installation you just select the correct
36:34data for your machine in my case it's
36:36going to be mac os with a home homebrew
36:39installation
36:41and with one simple brew installed mini
36:43cube command i can basically install
36:46mini cube
36:48like this and as you see the latest mini
36:51cube version has been installed once
36:53minicube is installed we want to
36:55actually start or create a mini cube
36:58cluster
36:58which is also super easy as you see
37:01we simply execute a mini cube start
37:04command
37:05however as i mentioned
37:07minicube must start either as a
37:09container or a virtual machine so we
37:12need either a container or a virtual
37:14machine tool installed on our laptop to
37:17run mini cube and this is going to be
37:19the driver for mini cube and opening the
37:22drivers page
37:23you see the list of supported drivers
37:27for linux mac os and windows and you see
37:31that docker is actually the preferred
37:34driver for running mini cube on all
37:36operating systems now this may be a
37:38little bit confusing because as you know
37:41inside the kubernetes cluster we run
37:44docker containers and it's important to
37:46note here that mini cube insulation
37:49actually comes with docker already
37:51installed to run those containers but
37:54docker as a driver from minicube means
37:58that we are hosting minicube on our
38:01local machine as a docker container
38:03itself so we have two layers of docker
38:06mini cube running is a docker container
38:08and inside mini cube we have docker
38:12packaged in minikube to run our
38:14application containers and for hosting
38:17minicube on our machine we can use
38:19docker so if you have docker already
38:21installed on your machine you're all set
38:24up to start a mini cube cluster
38:26if not also not a problem you can easily
38:29install it from here
38:31so clicking on install docker link this
38:34will take me to docker hub where i have
38:37docker desktop installation for windows
38:40and mac
38:42so i'm simply going to click in
38:44in my case docker desktop for mac and
38:47i'm gonna download and install docker
38:50and once downloaded just install it
38:55drag and drop into the applications
38:57folder
38:59and now we can start the docker daemon
39:01from the applications
39:04and as you see docker is starting up so
39:07the download and installation may take
39:09some time but once docker is installed
39:12and running we can switch back to the
39:14terminal and start the mini cube cluster
39:17using mini cube
39:19start command passing docker as a driver
39:23option
39:23using the driver flag with docker value
39:27and let's execute
39:29and this may also take a while when
39:32you're running it first time because it
39:34needs to actually create the cluster and
39:36download all the necessary images and
39:38components so the next time you do mini
39:40cube start it should actually go faster
39:43and as you see this command created a
39:45local kubernetes cluster on our machine
39:49with the latest kubernetes version
39:511.22 and now we can check the status of
39:54the cluster using minicube
39:57status command
39:58and we see that all the components
40:00inside are running and everything is
40:02configured and now start to actually
40:06interact with our cluster using
40:09command line tool and cubectl actually
40:12gets installed as a dependency when we
40:15install minicube
40:18which you see right here installing
40:20dependencies for minicube and kubernetes
40:23cli is actually cube ctl
40:26and that means we already have that
40:28available we don't have to install it so
40:31now i can do cube ctl get node
40:35and this will display all the nodes in
40:37the cluster in our case we just have one
40:39node which is control plane and the
40:41worker node at the same time
40:43and we see information for each node
40:46like the status the kubernetes version
40:49that it's running as well as when it was
40:51added to the cluster so with this we now
40:54have an actual kubernetes cluster
40:56running locally on our machine and we
40:59can start deploying applications in it
41:01so from this point on we are going to be
41:03interacting with the mini cube cluster
41:05using cubectl command line tool so
41:08minicube is basically just for the
41:10startup and for deleting the cluster but
41:13everything else configuring we're going
41:15to be doing through cubectl now we have
41:18enough knowledge to deploy a very simple
41:20but realistic application setup in a
41:23kubernetes cluster we will deploy a
41:25mongodb database and a web application
41:29which will connect to the mongodb
41:32database using external configuration
41:35data from config map and the secret and
41:38finally we will make our web application
41:42accessible externally from the browser
41:45so let's get right in so i have two
41:47resources here we're going to reference
41:49the kubernetes documentation to create
41:51our components which is a realistic way
41:53of working with kubernetes and also a
41:56docker hub where i have
41:58the web application image that i created
42:00which is publicly accessible so you can
42:02also pull it directly from the docker
42:05hub in your kubernetes cluster so first
42:08let's go ahead and create
42:10all the kubernetes configuration files
42:13that we need for deploying our
42:16application setup and for that i'm going
42:18to go to visual studio code where i have
42:21a kubernetes demo folder open and in
42:24this folder we're going to create four
42:26kubernetes configuration files that we
42:28need we're going to create a config map
42:31with mongodb
42:32database endpoint we're going to create
42:35a secret with username and password for
42:38mongodb and then we're going to create a
42:41configuration file for deploying a
42:42mongodb application
42:44and its service and then we're going to
42:46create kubernetes configuration file for
42:49deploying our simple demo app
42:52application with its service
42:57so the first file will be called
43:00config.yml
43:03and creating a config map in kubernetes
43:05is super simple for the syntax we can
43:08reference kubernetes documentation
43:13so i'm going to copy the first part here
43:16paste it in
43:17and that's basically the main syntax
43:19we're starting from
43:21let's call our config map
43:24config
43:28so we have the metadata and then we have
43:30the actual
43:31contents of this config map within the
43:34data attribute we have all the key value
43:37pairs that we define as external
43:40configuration within this config map in
43:42our case we just have one which we're
43:44going to call
43:46url as a key and of course we need a
43:49value for the mongodb url and the value
43:53will be the service that we're going to
43:56create for mongodb application and we're
43:59going to call that service
44:01service
44:02and in a couple of minutes you're going
44:04to see how to create this service
44:07and that will be basically all the
44:09configuration we need for creating
44:11config map
44:15so that one is done let's now go ahead
44:17and create secret
44:20dot
44:21yaml which will hold the username and
44:24password for mongodb application again
44:28to reference
44:29documentation
44:33i'm going to take this one and let's
44:35actually copy the whole thing
44:37so we have the secret kind instead of
44:40config map let's call this secret
44:44we have type opaque which is the generic
44:47type for defining secret data basically
44:51and we have the same data attribute here
44:54and let's actually create our own values
44:56let's call this
44:58[Music]
44:59user
45:00and
45:03password
45:06and as you already learned the values in
45:09secret are base64 encoded so we can just
45:12set the values plain text we have to
45:15encode them first and encoding values is
45:18super easy we're just gonna do echo
45:21and let's call it user
45:24and
45:25base 64. encode it
45:28and the same way let's do
45:31password
45:36and
45:38paste those values
45:44and this will be our secret
45:46configuration and now when we create
45:49deployments for our applications we can
45:51reference
45:52any of the values defined in the secret
45:55or config map so let's see how that
45:57works
46:01again let's create a new file and let's
46:03call this dot yaml this is going
46:07to be a configuration file where
46:09we're going to create deployment and
46:12service for mongodb you can have
46:15separate files for them but it's a very
46:17common thing to put them together
46:19because all the deployments need
46:21services so you have them grouped in one
46:24yaml file
46:25and again
46:26let's reference the documentation for
46:31the deployment example syntax
46:34and we can then adjust the values as we
46:36need
46:37and as you see deployment configuration
46:39file looks a little bit more complex
46:42than configmap or a secret so let's go
46:45through the configuration and understand
46:47all these attributes so we have the
46:49metadata section
46:51and the specification and these are
46:53basically deployment specific
46:56configuration that we have in the
46:58specification section and let's start
47:01with the main part of the deployment
47:02which defines the blueprint for the pots
47:06and that blueprint is defined as a
47:08template so template
47:11basically is a configuration of the part
47:15within the configuration of deployment
47:18and you see that template section has
47:20its own metadata and own spec or
47:24specification just like deployment has
47:26its metadata and specification right so
47:29this part actually configures the pod
47:33within a deployment and in the
47:35specification of the pod we have the
47:37definition of containers so this is a
47:40list of containers as you learned you
47:42can have multiple containers in a pot
47:45but mostly one main application per pot
47:49and this is where we define which image
47:52will be used to create this pod in our
47:55case this is going to be a mongodb image
47:58and if we
48:00search for
48:01in docker hub
48:04that's basically the image name and you
48:07can find all the text
48:09in the text section and we're going to
48:11use the tag 5.0
48:14so one go
48:175.0 that's where we define the image
48:20of the container within the pot we can
48:22name this
48:23mongodb this is just the name of the
48:26container and we also have the port
48:28where the container will listen and
48:30let's check our image and as you see
48:33mongodb starts at this port so we can
48:35just copy it and paste it in here so
48:38this basically
48:40just configures our deployment to create
48:43pods with a mongodb image version
48:465.0 so that's the core of a deployment
48:50now let's see what is all this other
48:51stuff here first of all we have this
48:54labels attribute in the metadata section
48:58and then we also have match labels
49:00attribute so what is this about in
49:03kubernetes you can give any component
49:06a key value pair labels so you can label
49:10anything from pod to deployment to
49:12configmap etc and labels basically are
49:16additional identifiers of the components
49:18in addition to the name for example
49:21so you can
49:22identify and address specific components
49:26using their labels
49:27now why do we need them first of all
49:30when we have multiple replicas of the
49:32same part
49:34each part will get a unique
49:36name however
49:38they can share the same label so we can
49:41identify all the part replicas of the
49:43same application using a specific label
49:47that all of them share and that's why in
49:49the metadata of the pod we always have
49:52this label so for pods labels is a
49:55required field for other components like
49:58deployment configmap etc labels is
50:01optional but it is a good practice to
50:04set them
50:05now
50:06when we create pod replicas how does
50:08deployment know which parts actually
50:11belong to it or how does kubernetes know
50:13which pods belong to which deployments
50:16and that is defined using
50:19this part right here so
50:21selector match labels is in the
50:23specification of the deployment as you
50:25see and this defines
50:27that all the parts that match
50:30this label belong to
50:33this deployment so that's why we have
50:36match labels here
50:38so this
50:39selector will match the pods created
50:42with this configuration
50:44because they have label app engine x now
50:47are these labels
50:48given or can you select any key value
50:51pairs well these are totally up to you
50:53you can call it whatever you want
50:55you can call it my key
50:58my value it doesn't really matter
51:00however the standard and a common
51:02practice in kubernetes is to use app
51:06key in the labels when labeling your
51:08applications and the value will
51:10obviously be whatever application you
51:12have so let's actually change and set
51:15the values
51:17to instead of nginx
51:19because that's our application and of
51:21course we want to match label app
51:25and let's also change
51:27this one right here
51:29to deployment and finally last
51:32attribute we have here is replicas which
51:35is super simple and straightforward this
51:38just defines how many pods you want to
51:40create using this blueprint in our case
51:43let's do just one replica because it's a
51:46database and as you learned if you want
51:48to scale databases in kubernetes you
51:50should use stateful set and not a
51:52deployment to keep everything simple
51:54we're going to stick to one replica and
51:57that basically configures our mongodb
52:00deployment
52:01and the pod blueprint now let's add a
52:04service configuration because every
52:06application needs a service in
52:07kubernetes and
52:10that's going to be a separate
52:12yaml
52:13unit or yaml section and we're going to
52:15separate it using
52:17three dashes which is basic yaml syntax
52:20nothing specific to kubernetes and again
52:23let's
52:25grab a service example
52:34and adjust it as we need now service
52:36configuration is much easier than the
52:38deployment as you see first let's change
52:41the name let's call it service and
52:44remember this is the end point
52:47which
52:48we will use to access and that's
52:50what we defined right here so this is
52:53the name of the service
52:57and in the specification we have
53:00service specific attributes first of all
53:03we have the selector attribute which you
53:06already know from here now why do we
53:08need a selector in service because as
53:11you know service needs to forward the
53:14request that it gets to
53:17its endpoint pods how does service know
53:20which pods belong to it and which ones
53:23it should forward the requests to well
53:25using the same label selector as we saw
53:29on deployment so this should match
53:32the label
53:33of the pods that will belong to the
53:36service which is
53:37and that's how service and pods
53:41will find each other and then we have
53:43the ports configuration which is also
53:46super simple service is accessible
53:48within the cluster using its own ip
53:52address and the port and we define its
53:55port right here
53:56and this can be any port that we decide
53:58on this could be 80 8080 doesn't really
54:01matter
54:02and we have the target port which is the
54:06port of the pods that belong to the
54:09service and logically enough the target
54:12port should always be the same as the
54:15container port because that's where the
54:17application in the pod is accessible
54:20that's where the service should forward
54:23the request to so again very important
54:26port attribute sets the port of the
54:29service and target port tells service
54:33to which port it should forward the
54:36request to the pods and this should be
54:39same as the container port port and
54:41target port values can be different or
54:44again it's a common standard
54:46to
54:47select the same port for the service as
54:49well just to keep things simple so let's
54:52save this and that's our configuration
54:55for mongodb deployment and service
55:00now i'm going to copy this whole thing
55:03and
55:04create
55:05a deployment in service for web
55:08application for our kubernetes demo
55:11application and let's call this webapp
55:14dot yaml
55:16paste
55:17everything in
55:19and we can just adjust all these
55:22values
55:30in the service
55:31and deployment
55:33all the labels and label selectors of
55:35course
55:36and right here we of course need the
55:39correct image of our web application
55:42going back to our docker hub
55:44this is
55:45the name of my image and again this is
55:48publicly accessible so you can use it as
55:51well
55:52and
55:53the tag is v
55:551.0
55:57and there you go so this is a very
55:59simple node.js application which starts
56:02on port 3000 so that's why we need to
56:05define container port on 3000 and
56:08container port is same as target port
56:11on the service and we can set the
56:13service port to the same value and this
56:16will configure
56:17deployment
56:19and
56:20service for our web application
56:23so this is
56:24the basic configuration for deployment
56:27and service for any application in
56:30kubernetes cluster
56:34but we have one more thing to configure
56:37in our deployment components for both
56:40and web app which is we need to
56:43pass the data defined in the config and
56:47secret components
56:48first of all when starting a mongodb
56:51application we need to set user name and
56:54password so when mongodb application
56:56starts it will automatically generate
56:58username and password for mongodb and we
57:00can then use that to access it in our
57:03cluster
57:04now how do we know
57:06how username and password can be
57:08configured in a mongodb on startup well
57:11we go to the image documentation and
57:14right here we see the environment
57:16variable names
57:18for username and password and these are
57:21actually required fields in most of the
57:23databases we have to set them otherwise
57:26we won't be able to access them so the
57:28next question is how do we configure
57:30environment variables in a container
57:33configuration so how do we pass
57:35environment variables to this
57:37application running inside the container
57:40well that's also very easy we have n
57:44attribute for that
57:46which is a list of environment variables
57:49with names
57:50and
57:52values that's it
57:54so
57:55very simple so name is the environment
57:58variable name and value is
58:00the environment variable value so let's
58:03copy the name
58:05so this is the environment variable name
58:07that mongodb expects and we have to set
58:10a value whatever we want the username to
58:13be now we can directly set
58:16the username right here like this
58:19or in our case we're going to reference
58:21them from secret and config
58:24components
58:26how do we do that also pretty simple we
58:28do value from
58:31and we want to reference it
58:32from the secret so we do secret
58:36key
58:38ref
58:40and under that we have the name of the
58:42secret
58:43which we called secret
58:46and the key
58:50which is user
58:53so kubernetes will basically find a
58:55secret with this name
58:57and get the value set for this key and
58:59substitute it as a value for this
59:02environment variable and the same way
59:04we're gonna
59:06configure
59:08a password
59:09so let's take the password that's the
59:12name of the environment variable
59:14same secrets
59:16component
59:19this time with a different key
59:22and that's it
59:23so our mongodb configuration file is
59:26complete
59:28and when it starts a user with these
59:30credentials will be created
59:35when our web application starts it will
59:38need to connect to the database so we
59:40need to give this web application
59:43information about the database endpoint
59:46where can it access the database
59:49and which username and password to use
59:52to authenticate with the database and i
59:54have already configured this application
59:57inside to expect all these values as
1:00:00environment variables with specific
1:00:03names so we're going to pass
1:00:05these three pieces of data as
1:00:07environment variables
1:00:09to the web app application so let's do
1:00:13that
1:00:16again
1:00:17the name of the environment variable the
1:00:18first one i actually called username
1:00:22and we can actually copy
1:00:25the same configuration and paste it here
1:00:28and you already see an advantage of
1:00:30using
1:00:31configuration from secret or config
1:00:34because if you need the same information
1:00:37in 10 different applications you create
1:00:39it once and reference it 10 times
1:00:43the second
1:00:44environment variable is for password
1:00:49and i called this one user pwd
1:00:53and finally our application needs
1:00:56the database endpoint which
1:01:01will be db url
1:01:04and this value is not in the secret
1:01:07but in configmap and how do we access
1:01:10value from config map very similar as
1:01:14the secret so we have the same value
1:01:16from
1:01:19and instead of secret key ref we have
1:01:21config
1:01:23map
1:01:24kirev
1:01:25or key reference
1:01:27and then we have
1:01:28name which we called config
1:01:33and key
1:01:36which is the name of the key
1:01:39and that's it so we don't have any of
1:01:41the configuration values hard coded in
1:01:44our
1:01:45kubernetes configuration files we only
1:01:48have references which makes our
1:01:50configuration way cleaner so if
1:01:52something changes or the values change
1:01:54here we don't have to adjust anything in
1:01:57our deployments
1:02:01so connectivity with the database is
1:02:03configured and there is one last thing
1:02:06missing in our web application
1:02:08configuration before we deploy all this
1:02:10which is making it accessible from the
1:02:13browser we want to be able to type in
1:02:16some url and access our web application
1:02:19from the browser right and as you
1:02:22learned we have external services for
1:02:24that so we will need to adjust
1:02:27the service configuration a little bit
1:02:29right now
1:02:30these service configurations both of
1:02:32them are internal services
1:02:35so to make it external
1:02:37all we need to do is
1:02:40set a type which is by default cluster
1:02:43ip
1:02:45so that's the default type if we don't
1:02:47specify the type but we're going to set
1:02:49it to
1:02:50node port
1:02:52so node port is an external service type
1:02:55and it requires a third port which is
1:02:58called
1:02:59a node port
1:03:03so what is a node port port
1:03:05this is a port which will open on the
1:03:08kubernetes nodes on which the
1:03:11application will be accessible so on the
1:03:14node ip address in node port combination
1:03:17we will be able to access
1:03:20this service which will then access
1:03:24the pods behind it and node port range
1:03:27is actually defined in kubernetes so we
1:03:29can't just type anything we want here
1:03:34like this it has to be within the range
1:03:36of thirty thousand and thirty two
1:03:38thousand seven hundred sixty seven so
1:03:42anything within this range is fine as a
1:03:44value so we can do 30 000 or 30
1:03:48100 doesn't really matter
1:03:51so let's set this as a value and this
1:03:54completes the web app configuration file
1:03:59now we have a very simple but also
1:04:02pretty realistic
1:04:04configuration
1:04:05for deploying an application with its
1:04:07database
1:04:09with external configuration in the
1:04:11cluster so as a final step we're just
1:04:14gonna create all these components one by
1:04:16one in kubernetes so i'm gonna open a
1:04:19terminal and we already have a mini cube
1:04:22cluster running
1:04:27but there are no components inside so
1:04:30first we need to create the external
1:04:32configurations because
1:04:34they need to be there when we create
1:04:36mongodb and web application deployments
1:04:40because they reference those
1:04:41configurations so let's create
1:04:44config and secret first to do that
1:04:47we have cube ctl apply command with
1:04:50minus f which stands for file which
1:04:53takes a kubernetes configuration file as
1:04:55an input
1:04:57like this
1:04:58and creates whatever is defined inside
1:05:01and as you see config was created
1:05:04now let's create longer secret
1:05:08next we're gonna create a database
1:05:10because our web application depends on
1:05:12it
1:05:14so it should start first
1:05:16and again let's do cube ctl apply
1:05:19with mongo.yaml as an input and as you
1:05:23see deployment
1:05:24and service were created and finally
1:05:28let's deploy our web application and
1:05:30there you go so everything seems fine
1:05:33but of course we want to check all the
1:05:35parts and all the components
1:05:37that were created in the cluster
1:05:42so for that i'm going to actually switch
1:05:44to command line so that we can see it
1:05:46better
1:05:47and first we're going to do cube ctl get
1:05:51all
1:05:52which gives you all the components
1:05:54created in the cluster which includes
1:05:56deployments
1:05:58the pods
1:05:59behind the deployment and all the
1:06:01services and as you see we have
1:06:04deployment and web app deployment parts
1:06:07each one with one replica running and we
1:06:10have the services for
1:06:13mongodb and web app
1:06:15and web app service is of node port type
1:06:18which means we can access it externally
1:06:20however we don't see configmap and
1:06:22secret here we can get them using
1:06:25kubectl get config map
1:06:28and cubectl get
1:06:30secret commands so as you see displaying
1:06:33any component is pretty easy using cube
1:06:35ctl you just do kubectl get and the name
1:06:38of the component like pod and you get
1:06:42a list of those components
1:06:44with some additional data
1:06:46and cubesatl is actually a very powerful
1:06:49tool and it has a bunch of sub-commands
1:06:52so as a natural documentation for
1:06:54cubectl to basically have an overview
1:06:57and see what you can do with it you can
1:07:00always use cubectl
1:07:03help as a documentation which lists all
1:07:06the sub-commands you can use with it one
1:07:09of them which we already used
1:07:11get and for each sub-command
1:07:14like cube ctl get you can also get some
1:07:17help
1:07:18and basically see all the examples
1:07:20plus all the available options so you
1:07:23can navigate all the options you have
1:07:25here so cube ctl get is obviously the
1:07:28most common command you're going to use
1:07:30to list all the components
1:07:33if you want to see more details about a
1:07:35certain component
1:07:37you can use cube ctl describe command
1:07:40for it a name of the component like a
1:07:42service for example
1:07:44and the actual instance of that
1:07:47component like web app service and this
1:07:50will give you more detailed output about
1:07:52that specific component same way you can
1:07:55also do cube ctl describe pod and then
1:07:59name of the pod
1:08:02like this one
1:08:05and this will give you details about
1:08:08your pot including the status of how the
1:08:11pod was scheduled
1:08:13the container configuration
1:08:16labels etc
1:08:18and finally
1:08:22of course when you have applications
1:08:24running in your cluster you want to
1:08:26check the logs to troubleshoot debug or
1:08:29just make sure that everything is fine
1:08:31within the pod and you can do that very
1:08:34easily using kubectl locks command
1:08:37and just specifying name of the pot like
1:08:42this
1:08:42this gives you
1:08:44logs of the container inside
1:08:46and you can even stream the logs using
1:08:49minus f option
1:08:54so the final step we want to validate
1:08:56that our application is also accessible
1:08:58from the browser and for that we
1:09:01actually configured the service and we
1:09:03can actually get the service using
1:09:05service or svc
1:09:08comment so how do we access this service
1:09:11from the browser because this is the
1:09:13port we're going to use to access it but
1:09:15which ip address is it accessible at
1:09:18well the node port service is always
1:09:20accessible at the ip address of the
1:09:23cluster node so all the work nodes that
1:09:26the cluster has in our case we just have
1:09:28one which is the mini cube so we need
1:09:30the ip address of the mini cube to get
1:09:33that
1:09:34we just do mini cube ip
1:09:37or using kubernetes we can also get
1:09:40get node which gives you mini cube
1:09:44and
1:09:45a white output
1:09:47or a longer output than what you see
1:09:49here
1:09:50which will give you
1:09:51the ip address
1:09:54of the node which is the same as this
1:09:57one right here and by the way you can
1:09:59use the all white option for any other
1:10:02get command for services pods etc to get
1:10:06some additional information like this
1:10:09so let's grab the mini cube ip address
1:10:12and access the application at this port
1:10:18which is 30
1:10:20100
1:10:22and there you go this is our web
1:10:24application which is connected to
1:10:27mongodb and we can also validate that by
1:10:30editing something
1:10:36and saving because this request goes to
1:10:39database
1:10:40and if we refresh
1:10:42the changes should still be there
1:10:45awesome so we deployed an application
1:10:47with its database in kubernetes which is
1:10:50a blueprint configuration for most
1:10:53common application
1:10:54setups you're gonna have plus you also
1:10:56learn a couple of cubesitl commands as
1:10:59well as how to reference the kubernetes
1:11:01official documentation to help you
1:11:04configure and create all the components
1:11:07i hope i helped you learn a lot about
1:11:09kubernetes with this crash course and
1:11:11you feel much more confident with
1:11:13kubernetes now if you're serious about
1:11:16learning kubernetes in depth i actually
1:11:18have two more resources for you
1:11:20as i mentioned at the beginning if you
1:11:22want to really become an expert in
1:11:24kubernetes and learn how to build and
1:11:27administer a cluster from scratch then
1:11:30my complete kubernetes administrator
1:11:32course will be a perfect resource for
1:11:34you but if your goal is rather to become
1:11:37a devops engineer then our complete
1:11:39devops educational program will be the
1:11:42best fit for you where during a
1:11:44six-month program you learn all the
1:11:47necessary concepts and technologies
1:11:49including kubernetes which you need to
1:11:52get started in devops or cloud
1:11:54engineering
1:11:55if you're interested you can find the
1:11:57links in the video description below and
1:11:59with that
1:12:00thank you for watching and see you in
1:12:02the next video

About this transcript

This page contains the full transcript of Kubernetes Crash Course for Absolute Beginners [NEW] by TechWorld with Nana, generated from the public captions YouTube serves with the video. The transcript has 10,204 words across 1,713 segments, with the original timestamps preserved so you can click any line to jump to that moment in the embedded player.

What you can do with it

Use the transcript to take notes, quote the speaker, build a study guide, generate a summary with ChatGPT or Claude via the YouTube Summary tool, or export it as a timed subtitle file with YouTube to SRT. You can also re-open it in the transcriber to translate the transcript into 100+ languages.

Free YouTube transcript tool

YouTube2Text is a free YouTube transcript generator — no signup, no daily limit. Paste any YouTube link and get the full transcript instantly, with timestamps, click-to-jump, translation to 100+ languages, AI prompts for ChatGPT, Claude, and Gemini, and exports to TXT, SRT, VTT, or Markdown.