Cluster Architecture, Installation & Configuration

The kubelet is a critical node-level agent that runs on every node in a Kubernetes cluster. Its primary responsibility is to ensure that containers are running in pods as expected. The kubelet receives PodSpecs from the API server and guarantees that the containers described in those PodSpecs are running and healthy.

The kubelet communicates with the container runtime (such as containerd or CRI-O) to start, stop, and manage containers. It also reports node and pod status back to the control plane, performs health checks (liveness and readiness probes), and mounts volumes for pods.

The other answers describe different Kubernetes components:

• Managing cluster-wide scheduling decisions is the responsibility of the kube-scheduler, which runs on the control plane and determines which node should run newly created pods based on resource requirements, constraints, and policies.

• Handling external traffic routing and load balancing for services is the role of kube-proxy, which runs on each node and maintains network rules that allow network communication to pods from inside or outside of the cluster.

• Storing configuration data and coordinating communication between components describes etcd, the distributed key-value store that serves as Kubernetes' backing store for all cluster data, including configuration, state, and metadata.

The correct answer is to use a Role in the staging namespace with verbs create and delete on deployments resource.

In Kubernetes RBAC (Role-Based Access Control), when you need to grant permissions that are limited to a specific namespace, you should use a Role resource. A Role defines permissions within a particular namespace and can specify:
- Which resources can be accessed (in this case, deployments)
- Which verbs/actions are allowed (in this case, create and delete)

Since the requirement is to allow the user to create and delete Deployments ONLY in the 'staging' namespace, a Role is the appropriate choice because it is namespace-scoped by design.

Why the other options are incorrect:

• Using a ClusterRole would define cluster-wide permissions. While a ClusterRole CAN be bound to a specific namespace using a RoleBinding, the question asks which resource would define the permissions, not bind them. A Role is the more appropriate and straightforward choice for namespace-specific permissions.

• A Role with verbs 'get' and 'list' would only allow reading/viewing Deployments, not creating or deleting them. This doesn't match the requirement of allowing create and delete operations.

• A RoleBinding is used to bind a Role (or ClusterRole) to a user, group, or service account. It does not define permissions itself - it connects users to the permissions defined in a Role or ClusterRole. The verbs and resources are defined in the Role, not in the RoleBinding.

The correct answer is that controlPlaneEndpoint in the ClusterConfiguration section specifies the load balancer address for API server access.

When setting up a highly-available Kubernetes control plane with kubeadm, the controlPlaneEndpoint field is crucial. This field defines a stable endpoint (typically a load balancer DNS name or IP address) that all nodes in the cluster use to communicate with the API server. This endpoint remains constant even as individual control plane nodes may come and go, ensuring continuous cluster availability.

In the kubeadm configuration file, it appears in the ClusterConfiguration section like this:

apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
controlPlaneEndpoint: "loadbalancer.example.com:6443"

This is essential for HA setups because:
- Worker nodes need a consistent endpoint to reach the API server
- Additional control plane nodes joining the cluster need to know where to connect
- The endpoint typically points to a load balancer that distributes traffic across all healthy control plane nodes

The other options are incorrect:

• apiServerEndpoint in InitConfiguration does not exist as a configuration field for this purpose. The InitConfiguration section handles settings for the initial node joining the cluster, not the shared API endpoint.

• clusterEndpoint in KubeadmConfig is not a valid kubeadm configuration field. There is no KubeadmConfig section in the kubeadm configuration schema, and etcd endpoint configuration is handled separately.

• masterEndpoint in ClusterConfiguration does not exist. This is a fabricated field name that is not part of the kubeadm API specification.