{"id":22672,"date":"2025-07-02T11:48:29","date_gmt":"2025-07-02T11:48:29","guid":{"rendered":"https:\/\/www.devopsschool.com\/blog\/?p=22672"},"modified":"2025-07-02T11:48:59","modified_gmt":"2025-07-02T11:48:59","slug":"details-kubernetes-components-in-master-worker","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/blog\/details-kubernetes-components-in-master-worker\/","title":{"rendered":"Kubernetes Components in Master & Worker"},"content":{"rendered":"\n

Here is a very comprehensive, detailed tutorial\/guide<\/strong> explaining each Kubernetes cluster architecture component you\u2019ve listed. This guide is suitable for learning, interviews, or team documentation, and each component is clearly explained with details on how it works, its purpose, and practical usage.<\/p>\n\n\n\n

\n\n\n\n

Kubernetes Cluster Architecture: Complete Guide<\/h1>\n\n\n\n
\n\n\n\n

1. Overview of Kubernetes Cluster Architecture<\/strong><\/h2>\n\n\n\n

A Kubernetes (K8s) cluster consists of several components working together to manage, orchestrate, and scale containerized applications. The architecture is designed to be modular, highly available, and scalable. The main building blocks are:<\/p>\n\n\n

Workstation \u2192 Master Node(s) \u2192 Worker Node(s)\n<\/code><\/span><\/pre>\n\n\n
\n\n\n\n
2. Workstation<\/strong><\/h2>\n\n\n\n
This is the user’s machine or environment<\/strong> used to manage and interact with the Kubernetes cluster. Most operational tasks, cluster management, and resource definitions start here.<\/p>\n\n\n\n
Key Tools on Workstation<\/strong><\/h3>\n\n\n\n
a. kubectl<\/strong><\/h4>\n\n\n\n
    \n
  • Description:<\/strong>
    kubectl<\/code> is the command-line tool for interacting with the Kubernetes API server. It allows you to deploy applications, inspect and manage cluster resources, and view logs.<\/li>\n\n\n\n
  • Common Commands:<\/strong>\n
      \n
    • kubectl get pods<\/code><\/li>\n\n\n\n
    • kubectl apply -f deployment.yaml<\/code><\/li>\n\n\n\n
    • kubectl logs <pod-name><\/code><\/li>\n<\/ul>\n<\/li>\n\n\n\n
    • How it works:<\/strong>
      Communicates with the Kubernetes API server over HTTPS, using kubeconfig for authentication and cluster context.<\/li>\n\n\n\n
    • Practical Example:<\/strong> kubectl get nodes kubectl describe service my-service<\/code><\/li>\n<\/ul>\n\n\n\n
      b. YAML<\/strong><\/h4>\n\n\n\n
        \n
      • Description:<\/strong>
        YAML files are used to define the desired state<\/strong> of Kubernetes resources (Pods, Deployments, Services, etc.) in a declarative way.<\/li>\n\n\n\n
      • How it works:<\/strong>
        You write a resource definition in a .yaml<\/code> file and use kubectl apply -f file.yaml<\/code> to create or update resources.<\/li>\n\n\n\n
      • Example YAML:<\/strong> <\/li>\n\n\n\n
      • apiVersion: v1 kind: Pod metadata: name: nginx-pod spec: containers: - name: nginx image: nginx:latest<\/code><\/li>\n<\/ul>\n\n\n\n
        \n\n\n\n
        3. Master Node<\/strong><\/h2>\n\n\n\n
        The Master Node<\/strong> is the brain of the Kubernetes cluster. It manages the cluster state, schedules workloads, and handles API requests. In production, you typically have more than one master for high availability.<\/p>\n\n\n\n
        Core Components on Master Node<\/strong><\/h3>\n\n\n\n
        a. API Server<\/strong><\/h4>\n\n\n\n
          \n
        • What it is:<\/strong>
          The API Server is the central management point<\/strong> for the Kubernetes cluster. It exposes the Kubernetes API, which is a RESTful interface used by all other components and by kubectl<\/code>.<\/li>\n\n\n\n
        • How it works:<\/strong>\n
            \n
          • Receives requests (create, update, delete, get) from users and other components.<\/li>\n\n\n\n
          • Validates and processes API calls.<\/li>\n\n\n\n
          • Stores the resulting state in etcd.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
          • Deployed as:<\/strong>
            Runs as a Pod<\/strong> on the master node (using an image from the Google Registry).<\/li>\n\n\n\n
          • Practical Notes:<\/strong>\n
              \n
            • All communication in the cluster passes through the API Server.<\/li>\n\n\n\n
            • Secures communication via SSL\/TLS and authenticates users.<\/li>\n\n\n\n
            • Example command to access: kubectl get nodes<\/code> (This command communicates with the API server.)<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
              b. etcd<\/strong><\/h4>\n\n\n\n
                \n
              • What it is:<\/strong>
                A distributed key-value store<\/strong> that holds the entire configuration and state of the cluster.<\/li>\n\n\n\n
              • How it works:<\/strong>\n
                  \n
                • The “single source of truth” for the cluster\u2019s desired and actual state.<\/li>\n\n\n\n
                • Stores objects like pods, deployments, configmaps, secrets, etc.<\/li>\n\n\n\n
                • Highly available in production with a cluster of etcd nodes.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                • Deployed as:<\/strong>
                  Runs as a Pod<\/strong> on the master node (using an image from the Google Registry).<\/li>\n\n\n\n
                • Backup:<\/strong>
                  Essential to regularly back up etcd for disaster recovery.<\/li>\n<\/ul>\n\n\n\n
                  c. Controller Manager<\/strong><\/h4>\n\n\n\n
                    \n
                  • What it is:<\/strong>
                    The brains behind state management<\/strong> in Kubernetes. Runs controllers that ensure the cluster is always at the desired state.<\/li>\n\n\n\n
                  • How it works:<\/strong>\n
                      \n
                    • Watches etcd and the API Server for changes.<\/li>\n\n\n\n
                    • Runs controllers such as:\n
                        \n
                      • Replication Controller (ensures correct number of pods)<\/li>\n\n\n\n
                      • Node Controller (tracks node health)<\/li>\n\n\n\n
                      • Endpoint Controller (populates endpoints for services)<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                      • Takes action if the current state diverges from the desired state (e.g., creates new pods if one crashes).<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                      • Deployed as:<\/strong>
                        Runs as a Pod<\/strong> on the master node.<\/li>\n<\/ul>\n\n\n\n
                        d. Scheduler<\/strong><\/h4>\n\n\n\n
                          \n
                        • What it is:<\/strong>
                          Decides which worker node will run a new pod<\/strong> based on resource requirements and policies.<\/li>\n\n\n\n
                        • How it works:<\/strong>\n
                            \n
                          • Watches for newly created pods that don\u2019t have a node assigned.<\/li>\n\n\n\n
                          • Selects an appropriate node based on available CPU\/memory, taints\/tolerations, affinity\/anti-affinity, etc.<\/li>\n\n\n\n
                          • Updates the pod spec to bind it to the selected node.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                          • Deployed as:<\/strong>
                            Runs as a Pod<\/strong> on the master node.<\/li>\n<\/ul>\n\n\n\n
                            e. kube-proxy<\/strong><\/h4>\n\n\n\n
                              \n
                            • What it is:<\/strong>
                              Handles network proxying and load balancing<\/strong> for services in Kubernetes.<\/li>\n\n\n\n
                            • How it works:<\/strong>\n
                                \n
                              • Runs on every node (both master and worker nodes).<\/li>\n\n\n\n
                              • Maintains network rules and manages traffic routing to pods.<\/li>\n\n\n\n
                              • Enables access to Kubernetes services via ClusterIP, NodePort, or LoadBalancer.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                              • Deployed as:<\/strong>
                                Runs as a Pod<\/strong> on both master and worker nodes.<\/li>\n<\/ul>\n\n\n\n
                                \n\n\n\n
                                Supporting Tools on Master Node<\/strong><\/h3>\n\n\n\n
                                  \n
                                • kubelet:<\/strong>
                                  Node agent that ensures containers are running as specified in PodSpecs. (More on this in Worker Node section.)<\/li>\n\n\n\n
                                • Docker\/ContainerD:<\/strong>
                                  Container runtimes that pull container images and run containers. Kubernetes supports both; ContainerD is becoming the standard.<\/li>\n\n\n\n
                                • kubectl:<\/strong>
                                  Used on master for troubleshooting and cluster management.<\/li>\n\n\n\n
                                • kubeadm:<\/strong>
                                  Tool for bootstrapping and managing Kubernetes clusters.\n
                                    \n
                                  • kubeadm init<\/code> is used to initialize a new master node.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
                                    \n\n\n\n
                                    Master Node Setup Example<\/strong><\/h3>\n\n\n
                                    sudo kubeadm init --pod-network-cidr=10.244<\/span>.0<\/span>.0<\/span>\/16<\/span>\n# Follow the output instructions to set up kubectl config and join worker nodes.<\/span>\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                                    \n\n\n\n
                                    4. Worker Node<\/strong><\/h2>\n\n\n\n
                                    The Worker Node<\/strong> is where application workloads run. These nodes are registered with the cluster and managed by the control plane (masters).<\/p>\n\n\n\n
                                    Key Components on Worker Node<\/strong><\/h3>\n\n\n\n
                                    a. kubelet<\/strong><\/h4>\n\n\n\n
                                      \n
                                    • What it is:<\/strong>
                                      The node agent<\/strong>. Ensures that the containers described in PodSpecs are running and healthy.<\/li>\n\n\n\n
                                    • How it works:<\/strong>\n
                                        \n
                                      • Communicates with the API Server to receive pod specs.<\/li>\n\n\n\n
                                      • Starts\/stops containers as needed.<\/li>\n\n\n\n
                                      • Reports node and pod status back to the master.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
                                        b. kube-proxy<\/strong><\/h4>\n\n\n\n
                                          \n
                                        • What it is:<\/strong>
                                          As described above, enables network communication and load balancing for services on each node.<\/li>\n<\/ul>\n\n\n\n
                                          c. Container Runtime (Docker\/ContainerD)<\/strong><\/h4>\n\n\n\n
                                            \n
                                          • What it is:<\/strong>
                                            The engine responsible for running containers.<\/li>\n\n\n\n
                                          • How it works:<\/strong>\n
                                              \n
                                            • Pulls images from container registries (e.g., Google Registry, Docker Hub).<\/li>\n\n\n\n
                                            • Starts, stops, and manages the lifecycle of containers.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
                                              d. kubectl<\/strong><\/h4>\n\n\n\n
                                                \n
                                              • Optional on worker:<\/strong>
                                                Can be used for troubleshooting but not required for basic node function.<\/li>\n<\/ul>\n\n\n\n
                                                e. kubeadm<\/strong><\/h4>\n\n\n\n
                                                  \n
                                                • How it’s used:<\/strong>\n
                                                    \n
                                                  • Used to join the worker node to the cluster: sudo kubeadm join <master-ip>:<port> --token <token> --discovery-token-ca-cert-hash sha256:<hash><\/code><\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
                                                    \n\n\n\n
                                                    Worker Node Setup Example<\/strong><\/h3>\n\n\n
                                                    # Install kubeadm, kubelet, containerd\/docker\n# Join cluster (command given by kubeadm init on master)\nsudo kubeadm join <MASTER_IP<\/span>><\/span>:6443 --token <TOKEN<\/span>><\/span> --discovery-token-ca-cert-hash sha256:<HASH<\/span>><\/span>\n<\/code><\/span>Code language:<\/span> HTML, XML<\/span> (<\/span>xml<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                    \n\n\n\n
                                                    5. Summary Table: Components and Their Functions<\/strong><\/h2>\n\n\n\n
                                                    Component<\/th>Runs On<\/th>Description \/ Purpose<\/th><\/tr><\/thead>
                                                    kubectl<\/td>Workstation<\/td>CLI tool to manage cluster and resources<\/td><\/tr>
                                                    YAML<\/td>Workstation<\/td>Declarative configuration files<\/td><\/tr>
                                                    API Server<\/td>Master Node<\/td>Cluster gateway, exposes Kubernetes API<\/td><\/tr>
                                                    etcd<\/td>Master Node<\/td>Distributed key-value store for cluster state<\/td><\/tr>
                                                    Controller Manager<\/td>Master Node<\/td>Maintains desired state via controllers<\/td><\/tr>
                                                    Scheduler<\/td>Master Node<\/td>Assigns pods to worker nodes<\/td><\/tr>
                                                    kube-proxy<\/td>Both<\/td>Manages networking, service load balancing<\/td><\/tr>
                                                    kubelet<\/td>Both<\/td>Ensures container health and execution<\/td><\/tr>
                                                    Docker\/ContainerD<\/td>Both<\/td>Container runtime to run pods<\/td><\/tr>
                                                    kubeadm<\/td>Both<\/td>Bootstrap and manage cluster<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                    \n\n\n\n
                                                    6. How Everything Works Together: Flow Example<\/strong><\/h2>\n\n\n\n
                                                      \n
                                                    1. User writes a YAML manifest<\/strong> on the workstation.<\/li>\n\n\n\n
                                                    2. User applies manifest<\/strong> with kubectl apply -f file.yaml<\/code>.<\/li>\n\n\n\n
                                                    3. kubectl<\/strong> sends the request to the API Server<\/strong>.<\/li>\n\n\n\n
                                                    4. API Server<\/strong> stores configuration\/state in etcd<\/strong>.<\/li>\n\n\n\n
                                                    5. Controller Manager<\/strong> notices a new deployment is needed.<\/li>\n\n\n\n
                                                    6. Scheduler<\/strong> assigns pods to available worker nodes<\/strong>.<\/li>\n\n\n\n
                                                    7. kubelet<\/strong> on worker nodes creates and manages containers via Docker\/ContainerD.<\/li>\n\n\n\n
                                                    8. kube-proxy<\/strong> sets up networking rules so services are reachable.<\/li>\n<\/ol>\n\n\n\n
                                                      \n\n\n\n
                                                      7. Conclusion & Best Practices<\/strong><\/h2>\n\n\n\n
                                                        \n
                                                      • Separate control plane and worker responsibilities<\/strong> for security and reliability.<\/li>\n\n\n\n
                                                      • Always secure etcd and take regular backups.<\/strong><\/li>\n\n\n\n
                                                      • Use declarative YAML for consistent, version-controlled cluster management.<\/strong><\/li>\n\n\n\n
                                                      • Leverage kubeadm for standard, reliable cluster bootstrapping.<\/strong><\/li>\n\n\n\n
                                                      • Use kubectl with RBAC (Role-Based Access Control) to restrict access.<\/strong><\/li>\n\n\n\n
                                                      • Regularly update cluster components for security and features.<\/strong><\/li>\n<\/ul>\n\n\n\n
                                                        \n\n\n\n
                                                        <\/p>\n","protected":false},"excerpt":{"rendered":"
                                                        Here is a very comprehensive, detailed tutorial\/guide explaining each Kubernetes cluster architecture component you\u2019ve listed. This guide is suitable for learning, interviews, or team documentation, and each component is clearly… <\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_joinchat":[],"footnotes":""},"categories":[4859],"tags":[],"class_list":["post-22672","post","type-post","status-publish","format-standard","hentry","category-kubernetes"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/22672","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/comments?post=22672"}],"version-history":[{"count":7,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/22672\/revisions"}],"predecessor-version":[{"id":49919,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/22672\/revisions\/49919"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/media?parent=22672"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/categories?post=22672"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/tags?post=22672"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}