In this section, you will go through the basic concepts needed to understand how Kubernetes works. Think of it as a beginner’s guide to Kubernetes and an absolute necessity if this CKA course is your first brush with Kubernetes. If you have taken up any other Kubernetes course, feel free to gloss over the contents of this section, going over the practice tests to affirm your knowledge.
This section introduces you to a high-level abstraction of how Kubernetes orchestrates applications hosted on machines, whether virtual or on-premises.
Kubernetes helps automate the management, deployment, and scaling of applications hosted in containers. These containers run on clusters of hosts called nodes. Clusters are composed of several nodes so you can deploy and manage as many instances of the application as your workload requires. In Kubernetes clusters, there are two kinds of nodes: worker nodes and master nodes.
The Master nodes host the Kubernetes control plane elements that make all scheduling and allocation decisions for a Kubernetes cluster. These elements are:
- ETCD: This is the distributed database that stores all cluster data in key-value pairs. In a highly distributed application with multiple instances of the control plane, the leader is chosen through a raft algorithm, and this becomes the single source of truth for the entire cluster.
- Schedulers: The
kube-scheduleris the control plane component that assigns nodes to newly created Kubernetes PODs. The scheduling decisions are made based on a number of factors, including: deadlines, interference, and resource requirements among others.
- Controllers: These elements monitor the cluster state and make adjustments in a bid to get them to the desired state. Some controllers you’ll encounter with your clusters include:
- Node Controller- Notices and responds to changes in node availability.
- Replication controller- Maintains the correct number of PODs for all Kubernetes cluster objects.
- Endpoints Controller- Connects PODs with services.
- The Kube-API Server: This serves as the front end for all control plane elements by exposing them to the Kubernetes Application Programming Interface.
Worker nodes run the application workloads. These are the machines that host application containers and are managed by control plane elements on master nodes. The components of a worker node include:
- The Kubelet: This is the agent that runs on each machine of a cluster, ensuring that every container has been given a POD. The kubelet doesn’t manage containers which were not created by Kubernetes, instead, it uses various Pod Specifications (PodSpecs) to make sure containers run healthy.
- The Kube-Proxy: This component runs on each node in your cluster and enforces network rules on all nodes, ensuring PODs can communicate with other PODs within and outside the cluster.
- The Container Runtime: The operating software that hosts and runs containers. Kubernetes supports most container runtimes, including Docker, CRI-O, containerd, and any custom solution that implements Kubernetes Container Runtime Interface (CRI).
Beginner’s Guide to ETCD
ETCD is a simple, secure, fast, and reliable distributed key storage used to store small bits of data that need fast read/write times. To read, write and store cluster information, ETCD uses key-value declarations. The format for key-value declarations is:
Command [Key1] [Value1]
There are various methods of installing
etcd on your machine. One way is to use a simple Chocolatey installation to bring all the packages to the local machine by running the command:
$ choco install etcd
Additionally, a simple
curl command extracts the binary packages on a local machine by running the command:
$ curl -L https://storage.googleapis.com/etcd/v3.4.15/etcd-v3.4.15-linux-amd64.tar.gz -o etcd-v3.4.15-linux-amd64.tar.gz % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 9 100 9 0 0 8 0 0:00:01 0:00:01 --:--:-- 8
To extract the etcd service use the following the archive using the command:
tar xzvf etcd-v3.4.15-linux-amd64.tar.gz
The etcd service is launched by initializing the executable file:
This will bring up etcd listening on port 2379 for client communication and on port 2380 for server-to-server communication.
./etcdctl to display a list of commands that can be used with etcd, along with making sure that the service is running.
NAME: etcdctl - A simple command line client for etcd3. USAGE: etcdctl [flags] VERSION: 3.4.14 API VERSION: 3.4 COMMANDS: alarm disarm Disarms all alarms alarm list Lists all alarms auth disable Disables authentication auth enable Enables authentication check datascale Check the memory usage of holding data for different workloads on a given server endpoint.
We input a simple key-value pair to check that the service is running. To enter a key-value pair into the database we use the
put command as shown:
./etcdctl put name darwin
To access the values we use the
./etcdctl get name
The results are as shown:
./etcdctl put name darwin OK ./etcdctl get name name darwin
ETCD for Kubernetes
In Kubernetes, the ETCD server stores all information regarding the cluster, including the states of PODs, Nodes, Configs, roles, bindings, accounts, and secrets. With the
kubectl get command, you get information that is always extracted from the ETCD storage. All changes made to the cluster are updated on the ETCD server. Changes can only become valid when the server approves them as complete. When creating your clusters from scratch, you will have to configure ETCD as a service in your master node. On the other hand, if you use
kubeadm, the ETCD server is set up as a static POD in the
To access all keys stored in the server, run the command:
$ ./etcdctl get / --prefix --keys-only
ETCD stores cluster data in a very specific structure. The root directory is the registry, which is then subdivided into functional Kubernetes objects such as minions, PODs, ReplicaSets, Roles, Secrets, Deployments, and many more.
If you are building a High Availability application, you will have a number of ETCD clusters spread across various master nodes. These instances are specified during the initial creation of your Kubernetes cluster.
Kube API Server
The API Server is the primary management component in a Kubernetes cluster. It is the only control plane element that communicates directly with the ETCD server. The API Server is also responsible for returning requests made by the
kubectl utility. Upon receiving an incoming request, the API Server authenticates then validates the request. After validating, the API Server then fetches data from the ETCD server and comes back with a response.
It is also possible to interact directly with the API server using a POST request:
$ curl -X POST /api/v1/namespaces/default/pods
The Cluster Scheduler is always constantly monitoring the API Server on the look for new unassigned PODs. It then finds the most appropriate node to host the new POD, then updates the API Server, which in turn updates the ETCD database on the new configuration. The ETCD then passes this information to a Kubelet on the worker node, which instructs the container runtime to update the application in the image. Once the changes are effected, the Kubelet service communicates the changes to the API Server which updates the information on ETCD storage.
If you installed your cluster using
kubeadm, the API server is installed as a static POD in the
kube-system namespace. Therefore, you can view your server’s options by running the command:
$ kubectl get pods -n kube-system
If you deployed your cluster the hard way, you can access API-Server configurations by inspecting the service file, ie:
$ cat /etc/systemd/system/kube-apiserver.service
Kube Controller Manager
The kube-controller-manager helps to administer the functions of controllers- processes designed to watch the state of your cluster and adjust it until it reaches desired state. There are several types of controllers under the manager:
Node Controller- periodically checks the status of running nodes. If it stops receiving a signature from a node, the node is marked as unavailable. The node is marked unavailable but is kept running for a period of time known as the Grace Period, after which it is evicted from the cluster. The controller will then provision PODs on this node to a healthier one if the PODs are within the active ReplicaSet.
Replication Controller- Ensures that the desired number of PODs is available within a ReplicaSet at all times.
Depending on your application, you can have many more types of controllers monitoring and controlling different Kubernetes objects. The Kubernetes Controller Manager is the single package that encapsulates all controller processes, allowing you to view and manage them seamlessly. When you install the Kube control manager, all the controller processes are installed too.
When running a cluster using
kubeadm, the manager comes pre-configured as a static POD in the
- To view your kube-controller-manager server options, run the command:
$ kubectl get pods -n kube-system
- PODs can be inspected using the command:
$ cat /etc/kubernetes/manifests/kube-controller-manager.yaml
- In a cluster that has been set up from scratch, the settings can be viewed by inspecting the file:
$ cat /etc/systemd/system/kube-controller-manager.service
- It is possible to list the controller manager process to view its properties using the command:
$ ps -aux | grep kube-controller-manager
This is the control plane process responsible for assigning PODs to Nodes. In reality, the scheduler identifies the most suitable node that can host a POD based on resource requirements, application dependencies, and the POD destination. When a Scheduler sees a new POD, it will assign a Node in two steps:
Filtering- here, all the Nodes that do not meet the PODs resource requirements are eliminated, leaving only viable Nodes.
Ranking- viable Nodes are ranked according to how much they satisfy the various POD requirements. The scheduler uses a priority function to assign a score for each requirement on a 1-10 scale, and the highest-ranking node gets assigned the POD. Schedulers can be customized or composed to execute specific rankings for different applications.
Installing the Kubernetes scheduler is a 2-step process:
1. Downloading the binaries from the Kubernetes release page:
2. Extracting, then running the scheduler as a service:
If the cluster was set up using
kubeadm, kube-server options can be viewed by checking the
kube-scheduler.yaml folder in the Kubernetes manifest sub-folder:
Listing and searching for
kube-scheduler on the master node also shows the running process and specifications:
ps -aux | grep kube-scheduler
In the worker nodes, the Kubelet is the process responsible for registering the nodes within the cluster. It uses a template known as PodSpec (Pod Specification) to register the node to the Kube-API Server using logs, hostnames or flags.
It receives instructions from the kube-scheduler through the API Server to load a container. It then requests the container runtime on the worker node to run an instance of the application by pulling the required image. It then continuously monitors the POD and containers, periodically reporting to the API server.
Kubelet is not installed automatically when running
kubeadm, so it must be manually installed for every node. It is first downloaded using the command:
$ sudo apt-get install -y kubelet
To list and search for
kubelet on the master node, use the following command that shows the running processes and effective options:
$ ps -aux | grep kubelet
This is a daemonset that runs on every node, and is responsible for creating rules that balance workloads and forward traffic to POD service backends. The proxy reflects these services as they are deployed on every node and can forward traffic using simple or round-robin TCP and UDP streams. These network rules allow network communication to your Pods from network sessions inside or outside of your cluster.
kubeadm tool deploys
kube-proxy as a POD/DaemonSet on all nodes in the cluster. These can be accessed by listing all PODs within the cluster:
$ kubectl get pods -n kube-system
kube-proxy is deployed as a daemonset on every node, it can also be accessed by:
$ kubectl get daemonset -n kube-system
A POD is the smallest object you can create in Kubernetes. It is the basic object that encapsulates containers as they are deployed on a node. A POD, therefore, represents one instance of an application, and they typically share a 1:1 relationship with containers. When scaling an application, PODs are added or removed to meet the workload by deploying new instances of the application.
Creating a Kubernetes POD depends on the following prerequisites:
- A working Kubernetes cluster
- An application developed and built within a docker image and available through the docker repository
- All cluster services should be running
While containers typically share a 1:1 relationship with PODs, a POD can have more than one container, provided they are of different types. A single POD could, for instance, house an application container and a helper container that runs services. These are called multi-container PODs. Containers in the same POD can refer to each other as
localhost since they share network and storage space.
PODs help create applications that respond to scale and architectural changes seamlessly since Kubernetes creates multiple instances of the same containers to meet workload needs. While it is possible to run simple applications on Docker directly using containers, it is a requirement to run Kubernetes applications on PODs, which simplify scaling and load balancing.
PODs are created using the
$ kubectl run pod-name --image image-name
$ kubectl run nginx --image nginx
Once the POD is created, you get the following message:
When creating a POD using this process, the application image (Nginx) is downloaded from the Docker hub repository, and is then run within the cluster.
get command can be used to access information on running PODs:
$ kubectl get pods
With the output being:
NAME READY STATUS RESTARTS AGE nginx 1/1 Running 0 10s
Kubernetes uses Replication to ensure high-availability, and deploys as many instances of the application as desired. Replication Controllers are intelligent agents that help run multiple instances of the same POD in the cluster ensuring high availability. Even in applications running on single PODs, the replication controllers help by bringing up new PODs when the existing ones fail. Replication also helps to create multiple PODs for effective scaling and load balancing. Since the replication controller spans across multiple nodes, load balancing can be achieved by extending workloads to PODs on other nodes within the same cluster a ReplicaSet is a newer technology that involves the use of labels and Selectors.
To create a ReplicaSet/Replication Controller, we define its specifications in a YAML file. The header contents of this file should describe the ReplicaSet/Replication Controller, and the specification should include the specifications of the POD to be replicated. The specifications for a Replication Controller named
myapp-replicaset running 3 replicas of the
myapp-pod POD are shown below:
apiVersion: apps/v1 kind: ReplicaSet metadata: name: frontend labels: tier: frontend spec: replicas: 3 selector: matchLabels: tier: frontend template: metadata: labels: tier: frontend spec: containers: - name: nginx image: nginx
This replica controller can then be deployed using the
kubectl create command:
$ kubectl create -f replicaset-definition.yml
To display the working ReplicaSet, run the command:
$ kubectl get replicaset
To check the PODs deployed by the ReplicaSet, run the command:
$ kubectl get pods -l tier=frontend
ReplicaSets monitor existing PODs in the cluster. They use Selectors and Labels to identify PODs they can monitor and replicate. These labels are provided in the POD definition files, and act as a filter for the ReplicaSet, which is why we use the
matchLabels filter in the replicaset definition file.
When we need to scale the application using the ReplicaSet, we can update the number of replicas in the definition file, then use the
kubectl replace command to replace the existing set.
Alternatively, we can scale directly by specifying the number of Replicas alongside the
$ kubectl scale --replicas=6 replicaset-definition.yml
This can also be represented in the type-name format as shown:
$ kubectl scale --replicas=6 replicaset frontend
Deployment is a Kubernetes object that allows for the hosting of applications in production environments. This is because Deployments allow for the provisioning of enough replicas, rolling updates, rollbacks, pausing and resuming updates. The Deployment is a level of abstraction above a ReplicaSet, and automatically creates one when launched.
Deployments are created by first defining their specifications in a YAML definition file. The file specifications for a deployment named
--- apiVersion: apps/v1 kind: Deployment metadata: name: myapp-deployment labels: app: web spec: replicas: 2 selector: matchLabels: app: web template: metadata: labels: app: web spec: containers: - name: front-end image: nginx ports: - containerPort: 80 - name: rss-reader image: nickchase/rss-php-nginx:v1 ports: - containerPort: 88
The deployment is then launched by running the command:
$ kubectl create -f deployment-definition.yml
- To display running deployments:
$ kubectl get deployments
- To update a deployment, make changes to the deployment file by using the
$ kubectl apply -f deployment-definition.yml
- To check the status of the rollout:
$ kubectl rollout status deployment/myapp-deployment
- To display the history of rollouts:
$ kubectl rollout history deployment/myapp-deployment
- To change the image name of the container front-end
$ kubectl set image deploy myapp-deployment front-end=nginx:1.19
- To roll back changes:
$ kubectl rollout undo deployment/myapp-deployment
In Kubernetes clusters, Namespaces offer a way to group objects into sub-clusters that are logically separated yet they can still communicate with each other. Services within the same namespace can communicate directly using a simple call. For instance, to communicate to
db-service within the same namespace:
To connect to a different namespace, we’ll need to specify the cluster and service domains along with the service name:
In the above command,
cluster.local is the cluster’s domain,
svc is the service path while
dev refers to the namespace.
Namespaces are created by specifying the configurations in a YAML file with Kind. Below are the specifications for a namespace called
dev in a specification file named
apiVersion: v1 kind: Namespace metadata: name: dev
- The namespace can then be created by running the command:
$ kubectl create -f namespace-dev.yml
- Another way of creating a namespace is by running the command:
$ kubectl create namespace dev
- To list the PODs in another namespace, it is specified on the command line, ie:
$ kubectl get pod --namespace=dev
- Likewise, this command line specification can be used to create a POD in another namespace:
$ kubectl create -f pod-definition.yml --namespace=dev
To ensure that a POD is created in the namespace by default without having to specify on the command line, the namespace can be included as a child specification of
metadata in the POD’s YAML definition file.
apiVersion: V1 kind: pod Metadata: namespace: dev name: myapp
To switch to a different namespace, the
kubectl config command is invoked:
$ kubectl config set-context $(kubectl config current-context) --namespace=dev
A successful switch is acknowledged with the message:
Context "kubernetes-admin@kubernetes" modified.
Namespaces can also be used to assign resource quotas and limits to instances of an application. This is first done by creating a YAML definition file for the resource quota with specifications as shown:
apiVersion: v1 kind: ResourceQuota metadata: name: compute-quota namespace: dev spec: hard: pods: "10" requests.cpu: "4" requests.memory: 5Gi limits.cpu: "10" limits.memory: 10Gi
This quota can then be enforced on the cluster by running the command:
$ kubectl create -f compute-quota.yaml
To get the current resource quota in the dev namespace:
$ kubectl get resourcequotas -n dev
In Kubernetes, Services are processes that allow communication between different services in a cluster, different nodes, and connect the application to external data sources. Kubernetes applications follow a Microservices architecture, where different functionalities of the application are hosted in different containers on various nodes within the cluster. This calls for a structured networking solution between different components of the Kubernetes ecosystem. Some of the most important Services within a cluster include: NodePort, ClusterIP and the LoadBalancer Service.
The NodePort service helps users access cluster resources by mapping a port on a POD to a port on a node. NodePort, therefore, creates a connection using three ports:
- TargetPort: this is the port on the POD receiving requests from the service.
- Port: the port in the service establishing communication between the POD and the node.
- NodePort: the port on the node through which we can access the cluster externally.
The service itself has an IP address called ClusterIP.
The NodePort service can be created by declaring its specifications in a definition file:
apiVersion: v1 kind: Service metadata: name: my-service spec: type: NodePort selector: app: myapp ports: - port: 80 targetPort: 80 nodePort: 30008 selector: app: myapp
- This service can then be launched using the run command:
$ kubectl create -f service-definition.yml
- To list the services running in a cluster:
$ kubectl get service
- The application can then be accessed via SSH using the command:
$ curl http://192.168.1:30008
- Alternatively, if the web application has a GUI, it can be accessed by typing
http://192.168.1:30008 into a browser
If there are 3 PODs with the same application instance, all of them qualify as an endpoint for the request made with the address above. NodePort will use a random algorithm to determine which POD will return the request. If the PODs are situated in different nodes, Kubernetes will create a NodePort service spanning across all nodes and map a targetPort to the same nodePort on all nodes. Now the application can easily be accessed by combining the IP address of a node with the nodePort for high availability.
A full-stack application is typically composed of a number of PODs running different layers of services in a cluster. Some PODs could run the front-end, others run the back-end while others host the SQL database and key-value storage. These layers need to communicate with each other. While all PODs have an IP address assigned, the PODs are periodically added and subtracted so these addresses aren’t static.
The ClusterIP service is responsible for grouping PODs with the same functionality into a single interface, and assigning it an IP address so that other PODs can access its services.
The ClusterIP address is created by first composing a YAML definition file:
apiVersion: v1 kind: Service metadata: name: my-service spec: type: ClusterIP selector: app: myapp ports: - port: 80 targetPort: 80
The service is then launched by running the command:
$ kubectl create -f service-definition.yml
To inspect the services running in a cluster:
$ kubectl get services
To expose your app directly using the kubectl
$ kubectl create deployment nginx --image=nginx
$ kubectl expose deployment nginx --type=ClusterIP --name=my-service --port=80
To test it
$ kubectl run curl --image=radial/busyboxplus:curl -i --tty
$ curl http://my-service:80
While the NodePort service makes an application’s services accessible to external users, it does not specify which POD services a user’s request. The LoadBalancer service takes care of this by managing the services’ IP addresses. Major cloud platforms offer support for native load balancing, allowing for the autonomous distribution of workloads among hosted containers.
The LoadBalancer is created by declaring its properties in a YAML definition file:
apiVersion: v1 kind: Service metadata: name: my-service spec: selector: app: myapp ports: - protocol: TCP port: 80 targetPort: 80 type: LoadBalancer
The service is then activated using the command:
$ kubectl create -f service-definition.yml
Imperative vs. Declarative
In Kubernetes, we can create objects either using definition files or Kubernetes commands. The two approaches to managing objects in Kubernetes as Imperative and Declarative.
With Imperative commands, the developer tells Kubernetes what to do, and enlists the steps required to achieve the result. With declarative programming, the developers will specify the object requirements, and the software figures out how to achieve them.
Both methods have inherent merits depending on the use-case.
Imperative commands require the definition of object specification through flags that increase command length. Imperative commands are best suited for quick, simple applications that do not require extensive configuration.
In this method, the developers use –
exposecommands to create objects, and,
setcommands to update objects.
Imperative commands also offer no logs so it is difficult to keep track of changes made to cluster objects. When using the
edit command, changes are not made to the local manifest file, but to a version of the file in Kubernetes memory. The changes made to an object are difficult to track since updates are lost once new ones are made.
When making changes using the
replace command, a non-existent file returns an error. Similarly, when trying to create a file that already exists, an error is returned.
Manifest files help to describe the behavior of Kubernetes objects using YAML definitions. It is best to make changes to the configuration files then enforcing these updates using the
kubectl apply command. If the file doesn’t exist, Kubernetes will automatically create one. If a file already exists, it is updated to the latest version. This reduces the tedium involved in the administration of Kubernetes applications.
It is also possible to create multiple objects by pointing the
kubectl apply command to a file folder with manifest files:
$ kubectl apply -f /path/to/config-files
Kubectl Apply Command
This command is used to manage Kubernetes objects declaratively. It takes into consideration the local configuration file and the last applied configuration before deciding what changes to make. It creates a live configuration file within Kubernetes memory that includes the configuration data and status of the object.
When the command is run, it converts the definition file into JSON format, and stores this as the last applied configuration. Moving forward, it will compare the local manifest file, the live object on Kubernetes, and the JSON file to decide on the changes. It compares the local file with the running version to see which fields are missing/have been added, then writes these onto the last known configuration file.
Research Questions & Conclusion
This concludes the Core Concepts of the CKA certification exam. To test your knowledge, it is strongly recommended that you access research questions of all core concepts covered in the coursework and a test to prepare you for the exam. You can also send your feedback to the course developers, whether you have feedback or would like something changed within the course.
Here is a quick quiz to help you assess your knowledge. Leave your answers in the comments below and tag us back.
Quick Tip – Questions below may include a mix of DOMC and MCQ types.
1. Which command can be used to get the
replicasets in the namespace default?
kubectl get replicasets
kubectl get replicasets -n default
kubectl get pods
kubectl get rc
2. Which command can be used to get the number of PODs in the namespace dev?
kubectl get pods
kubectl get pods -n dev
kubectl get pods --namespace dev
kubectl get pods -n default
3. Which command can be used to get the image used to create the pods in the frontend deployment?
kubectl get deployments
kubectl describe deployments frontend
kubectl inspect deployments frontend
kubectl describe pod frontend-56d8ff5458-6d7jt
4. Inspect the below pod-definition file and answer the following questions.
apiVersion: apps/v1 kind: Deployment metadata: name: deployment-1 spec: selector: matchLabels: name: busybox-pod template: metadata: labels: name: busybox spec: containers: - name: busybox-container image: busybox888 command: - sh - "-c" - echo Hello Kubernetes! && sleep 3600
- This yaml is valid.
- By default, if we didn’t specify the replicas, the replica count will be 2
5. Which command can be used to create a pod called nginx and it’s image nginx?
kubectl run nginx --image=nginx
kubectl create nginx --image=nginx
kubectl apply nginx --image=nginx
kubectl create nginx --image=nginx
6. What does the READY column in the output of the
kubectl get pods command indicate?
[A] Running Containers in POD/Total containers in POD
[B] Running Pods / Total Pods
[C] Total Pods / Running Pods
[D] Total Containers in Pod / Running containers in POD
7. In the current(default) namespace, what is the command to check how many Services exist on the system?
kubectl get svc
kubectl get svc -n default
kubectl get services
kubectl get services -n default
8. What is the type of the default kubernetes service?
9. Which command can be used to create a service
redis-service to expose the Redis application within the cluster on port 6379? The service should only be accessible from the cluster and not exposed externally.
kubectl create service nodeport redis-service --tcp=6379:6379
kubectl create service loadbalancer redis-service --tcp=6379:6379
kubectl create service clusterip redis-service --tcp=6379:6379
kubectl create service externalname redis-service --tcp=6379:6379
10. Select the right command to create a namespace called
kubectl apply namespace staging
kubectl create namespace staging
kubectl replace namespace staging
kubectl get namespace staging
11. Which command can be used to create a deployment webserver with image httpd and namespace production?
kubectl create deployment webserver --image=httpd -n default
kubectl create deployment webserver --image=httpd
kubectl create deployment webserver --image=httpd -n production
kubectl apply deployment webserver --image=httpd -n production
12. Which is the best description of TargetPort?
[A] Exposes the Kubernetes service on the specified port within the cluster.
[B] Is the port on which the service will send requests to, that your pod will be listening on.
[C] Exposes a service externally to the cluster by means of the target nodes IP address and the NodePort.
[D] None of the above.
13. Which is the command to get all the namespaces inside your cluster?
kubectl get ns
kubectl get namespaces
kubectl list ns
kubectl list namespaces
14. What is the FQDN of service nginx in the default namespace?
15. … is a consistent and highly-available key value store used as Kubernetes’ backing store for all cluster data.
[A] kube API
[B] kube scheduler
[C] kube manager
The core concepts section is a helpful introduction to all aspects candidates need to know about running production-grade Kubernetes clusters. The section is divided carefully into chapters explored using animations, illustrations, and analogy to provide even the basic beginner a high-level understanding of the components in a Kubernetes cluster. Even for those with an experience in Kubernetes, this section is a great crash course and reference guide when working on real-world projects. Once the concepts of this section are well understood, the incoming chapters are a breeze since they build on the knowledge introduced in this chapter. The Core Concepts section is, therefore, a must-have guide for any practicing and prospective Kubernetes administrator.
On KodeKloud, you also get a learning path with recommendations, sample questions, and tips for clearing the CKA exam.