API Server:-
The API Server is responsible for serving the Kubernetes API
and is the front-end for the Kubernetes control plane.
It handles operations such as CRUD (Create, Read, Update,
Delete) for Kubernetes objects.
Controller Manager:-
The Controller Manager is a component that embeds the core
control loops that regulate the state of the system.
It includes various controllers responsible for maintaining
the desired state of different types of resources in the cluster. Examples
include the Replication Controller, ReplicaSet Controller, and others.
Controller Manager's Role:
o Manages
and runs various controller processes.
o Continuously
monitors the cluster's state for discrepancies.
o Takes
corrective actions to align the current state with the desired state.
Examples of controllers it runs:
o Node
Controller: Manages node lifecycle (adding, removing, updating).
o Replication
Controller: Ensures desired number of pod replicas are running.
o Deployment
Controller: Manages deployments and updates pods gracefully.
o DaemonSet
Controller: Ensures specific pods run on all or selected nodes.
o Job
Controller: Manages job lifecycles and pod completion.
Key Distinction:
o
API Server is primarily for communication and
data management.
o
Controller Manager is responsible for
actively maintaining the cluster's desired state by running controllers.
Scheduler:
The Scheduler is responsible for placing pods onto nodes in
the cluster based on resource requirements, constraints, and other policies.
It ensures that the workload is distributed across the
cluster effectively.
Analogy:
Think of the API Server as the "front desk" of a
hotel, handling requests and managing information.
The Controller Manager is like the "housekeeping
staff," continuously working behind the scenes to ensure everything is in
its proper place and functioning correctly.
The core concept of declarative configuration is:
Writing configuration documents that describe the system you
want Kubernetes to deploy.
Explanation:
Declarative configuration is a fundamental principle in
Kubernetes. It involves specifying the desired state of the system in
configuration files (YAML manifests) rather than providing a sequence of
imperative commands. In a declarative approach, you describe what you want the
system to look like, and the Kubernetes control plane works to make the current
state of the system match the desired state.
In the context of Kubernetes:
Writing configuration documents: This involves creating YAML
manifests that define the desired state of Kubernetes resources such as pods,
services, deployments, etc.
Describing the system you want Kubernetes to deploy: The
configuration documents specify the desired state of the system, and Kubernetes
takes care of managing the deployment and maintaining the desired state.
This approach is in contrast to imperative configuration,
where you would provide step-by-step commands to achieve a specific state.
Declarative configuration is preferred in Kubernetes for its clarity,
repeatability, and the ability to easily manage and version control
configuration as code.
If a Pod controller by a Job has its execution interrupted
by a Node failure, how will the Job Controller react? job controller Reschedule
the Pod
its explanation: -
·
A Job in Kubernetes is intended to create one or
more Pods and ensures that a specified number of them successfully terminate.
·
If a Pod controlled by a Job is interrupted due
to a Node failure or any other reason, the Job Controller will detect the
failure and take corrective actions to meet the desired state.
·
The Job Controller will attempt to reschedule
the failed Pod to another available Node in the cluster to ensure that the
specified number of successful completions is achieved.
In summary, the Job Controller is
designed to handle failures and disruptions in a way that aligns with the
desired state specified by the Job. Rescheduling the Pod is a mechanism to
ensure that the Job's requirements are met despite interruptions.
Here are 10 possible multiple choice questions
based on the passage, along with the correct answers and explanations:
1. What is the
main responsibility of the API Server in Kubernetes?
a) Serving the
Kubernetes API and acting as the front-end for the control plane.
b) Placing pods onto nodes in the cluster
based on resource requirements and constraints.
c) Embedding the core control loops that
regulate the state of the system.
d) Managing the
lifecycle of containers and pods in the cluster.
Answer: a) Serving the Kubernetes API and acting as
the front-end for the control plane.
Explanation: The API Server is the component that
exposes the Kubernetes API and handles operations such as CRUD (Create, Read,
Update, Delete) for Kubernetes objects. It is the entry point for communication
and data management in the control plane.
2. What is the
main responsibility of the Controller Manager in Kubernetes?
a) Serving the
Kubernetes API and acting as the front-end for the control plane.
b) Placing pods onto
nodes in the cluster based on resource requirements and constraints.
c) Embedding the core control loops that
regulate the state of the system.
d) Managing the
lifecycle of containers and pods in the cluster.
Answer: c) Embedding the core control loops that
regulate the state of the system.
Explanation: The Controller Manager is the
component that runs various controllers responsible for maintaining the desired
state of different types of resources in the cluster. It continuously monitors
the cluster's state for discrepancies and takes corrective actions to align the
current state with the desired state.
3. What is the
main responsibility of the Scheduler in Kubernetes?
a) Serving the
Kubernetes API and acting as the front-end for the control plane.
b) Placing pods onto nodes in the cluster
based on resource requirements and constraints.
c) Embedding the core control loops that
regulate the state of the system.
d) Managing the
lifecycle of containers and pods in the cluster.
Answer: b) Placing pods onto nodes in the cluster
based on resource requirements and constraints.
Explanation: The Scheduler is the component that
assigns pods to nodes in the cluster based on various factors, such as resource
availability, affinity and anti-affinity rules, taints and tolerations, and
other policies. It ensures that the workload is distributed across the cluster
effectively.
4. Which of
the following is an example of a controller that the Controller Manager runs?
a) Node Controller
b) Deployment Controller
c) DaemonSet Controller
d) All of the above
Answer: d) All of the above
Explanation: The Controller Manager runs various controllers
that are responsible for different types of resources in the cluster. Some
examples are:
● Node
Controller: Manages node lifecycle (adding, removing, updating).
● Deployment
Controller: Manages deployments and updates pods gracefully.
● DaemonSet
Controller: Ensures specific pods run on all or selected nodes.
5. Which of
the following is a key distinction between the API Server and the Controller
Manager?
a) The API Server is primarily for
communication and data management, while the Controller Manager is responsible
for actively maintaining the cluster's desired state by running controllers.
b) The API Server is responsible for actively
maintaining the cluster's desired state by running controllers, while the
Controller Manager is primarily for communication and data management.
c) The API Server and
the Controller Manager have the same responsibilities and functions in the
control plane.
d) None of the above.
Answer: a) The API Server is primarily for
communication and data management, while the Controller Manager is responsible
for actively maintaining the cluster's desired state by running controllers.
Explanation: The API Server and the Controller
Manager have different roles and functions in the control plane. The API Server
is the entry point for communication and data management, while the Controller
Manager is the component that runs various controllers to regulate the state of
the system.
6. What is the
core concept of declarative configuration in Kubernetes?
a) Writing configuration documents that
describe the system you want Kubernetes to deploy.
b) Writing configuration
documents that describe the system you have deployed with Kubernetes.
c) Writing configuration
documents that describe the commands you want Kubernetes to execute.
d) Writing configuration
documents that describe the commands you have executed with Kubernetes.
Answer: a) Writing configuration documents that
describe the system you want Kubernetes to deploy.
Explanation: Declarative configuration is a
principle in Kubernetes that involves specifying the desired state of the
system in configuration files (YAML manifests) rather than providing a sequence
of imperative commands. In a declarative approach, you describe what you want
the system to look like, and the Kubernetes control plane works to make the
current state of the system match the desired state.
7. What is the
difference between declarative and imperative configuration in Kubernetes?
a) Declarative
configuration describes what you want the system to look like, while imperative
configuration describes how you want the system to behave.
b) Declarative configuration describes how you
want the system to behave, while imperative configuration describes what you
want the system to look like.
c) Declarative
configuration describes what you want the system to look like, while imperative
configuration describes the steps to achieve a specific state.
d) Declarative configuration describes the
steps to achieve a specific state, while imperative configuration describes
what you want the system to look like.
Answer: c) Declarative configuration describes what
you want the system to look like, while imperative configuration describes the
steps to achieve a specific state.
Explanation: Declarative configuration is a
principle in Kubernetes that involves specifying the desired state of the
system in configuration files (YAML manifests) rather than providing a sequence
of imperative commands. In a declarative approach, you describe what you want
the system to look like, and the Kubernetes control plane works to make the
current state of the system match the desired state. Imperative configuration
is the opposite approach, where you provide step-by-step commands to achieve a
specific state. Declarative configuration is preferred in Kubernetes for its
clarity, repeatability, and the ability to easily manage and version control
configuration as code.
8. What is the
purpose of a Persistent Volume (PV) in Kubernetes?
a) To store data that persists beyond the
lifecycle of a Pod.
b) To store data that is
deleted when a Pod is deleted.
c) To store data that is
shared between multiple Pods.
d) To store data that is
encrypted and secured.
Answer: a) To store data that persists beyond the
lifecycle of a Pod.
Explanation: A Persistent Volume (PV) is a
Kubernetes API object that represents a piece of storage in the cluster. It
allows you to store data that persists beyond the lifecycle of a Pod. By
default, the data within a container is ephemeral and is deleted when the Pod
is deleted. A PV allows you to decouple the data from the Pod and retain it
even after the Pod is deleted.
9. What is the
purpose of a Persistent Volume Claim (PVC) in Kubernetes? a) To request and
consume a Persistent Volume (PV) in the cluster.
b) To create and
provision a Persistent Volume (PV) in the cluster.
c) To release and delete
a Persistent Volume (PV) in the cluster.
d) To encrypt and secure
a Persistent Volume (PV) in the cluster.
Answer: a) To request and consume a Persistent
Volume (PV) in the cluster.
Explanation: A Persistent Volume Claim (PVC) is a
Kubernetes API object that allows a user to request and consume a Persistent
Volume (PV) in the cluster. A PVC specifies the size, access mode, and storage
class of the desired PV.
The Kubernetes control plane then binds the PVC to
an available PV that matches the criteria. A PVC can be mounted by a Pod to
access the data on the PV.
10.
What happens to the data on a Persistent Volume (PV)
when it is released?
a) The data is retained,
recycled, or deleted depending on the reclaim policy of the PV.
b) The data is always
retained and can be reclaimed by the administrator manually.
c) The data is always
recycled and made available for reuse by other PVCs.
d) The data is always
deleted and the storage resource is freed.
Answer: a) The data is retained, recycled, or
deleted depending on the reclaim policy of the PV.
Explanation: The reclaim policy of a Persistent
Volume (PV) determines what happens to the data on the storage resource when
the PV is released. The reclaim policy is specified in the PV's configuration.
Common reclaim policies include:
● Retain:
Keeps the data intact, and the administrator is responsible for manually
reclaiming or deleting the data.
● Recycle:
Deletes the data on the storage resource, making it available for reuse by
other PVCs.
● Delete:
Similar to Recycle, deletes the data on the storage resource, but the reclaim
process might be handled by an external system or dynamic provisioning.
