🛡️
CTHFM: Kubernetes
  • Welcome
  • Kubernetes Fundamentals
    • Kubernetes Components
      • Kubernetes Master Node
      • Worker Nodes
      • Pods
      • Service
      • ConfigMaps and Secrets
      • Namespaces
      • Deployments
      • ReplicaSets
      • Jobs and CronJobs
      • Horizontal Pod Autoscaler (HPA)
      • Kubernetes Ports and Protocols
    • Kubectl
      • Installation and Setup
      • Basic Kubectl
      • Working With Pods
      • Deployments and ReplicaSets
      • Services and Networking
      • ConfigMaps and Secrets
      • YAML Manifest Management
      • Debugging and Troubleshooting
      • Kubectl Scripting: Security
      • Customizing Kubectl
      • Security Best Practices
      • Common Issues
      • Reading YAML Files
    • MiniKube
      • Intro
      • Prerequisites
      • Installation MiniKube
      • Starting MiniKube
      • Deploy a Sample Application
      • Managing Kubernetes Resources
      • Configuring MiniKube
      • Persistent Storage in Minikube
      • Using Minikube for Local Development
      • Common Pitfalls
      • Best Practices
  • Kubernetes Logging
    • Kubernetes Logging Overview
    • Audit Logs
    • Node Logs
    • Pod Logs
    • Application Logs
    • Importance of Logging
    • Types of Logs
    • Collecting and Aggregating Logs
    • Monitoring and Alerting
    • Log Parsing and Enrichment
    • Security Considerations in Logging
    • Best Practices
    • Kubernetes Logging Architecture
  • Threat Hunting
    • Threat Hunting Introduction
    • What Makes Kubernetes Threat Hunting Unique
    • Threat Hunting Process
      • Hypothesis Generation
      • Investigation
      • Identification
      • Resolution & Follow Up
    • Pyramid of Pain
    • Threat Frameworks
      • MITRE Containers Matrix
        • MITRE Att&ck Concepts
        • MITRE Att&ck Data Sources
        • MITRE ATT&CK Mitigations
        • MITRE Att&ck Containers Matrix
      • Microsoft Threat for Kubernetes
    • Kubernetes Behavioral Analysis and Anomaly Detection
    • Threat Hunting Ideas
    • Threat Hunting Labs
  • Security Tools
    • Falco
      • Falco Overview
      • Falco's Architecture
      • Runtime Security Explained
      • Installation and Setup
      • Falco Rules
      • Tuning Falco Rules
      • Integrating Falco with Kubernetes
      • Detecting Common Threats with Falco
      • Integrating Falco with Other Security Tools
      • Automating Incident Response with Falco
      • Managing Falco Performance and Scalability
      • Updating and Maintaining Falco
      • Real-World Case Studies and Lessons Learned
      • Labs
        • Deploying Falco on a Kubernetes Cluster
        • Writing and Testing Custom Falco Rules
        • Integrating Falco with a SIEM System
        • Automating Responses to Falco Alerts
    • Open Policy Agent (OPA)
      • Introduction to Open Policy Agent (OPA)
      • Getting Started with OPA
      • Rego
      • Advanced Rego Concepts
      • Integrating OPA with Kubernetes
      • OPA Gatekeeper
      • Policy Enforcement in Microservices
      • OPA API Gateways
      • Introduction to CI/CD Pipelines and Policy Enforcement
      • External Data in OPA
      • Introduction to Decision Logging
      • OPA Performance Monitoring
      • OPA Implementation Best Practices
      • OPA Case Studies
      • OPA Ecosystem
    • Kube-Bench
    • Kube-Hunter
    • Trivy
    • Security Best Practices and Documentation
      • RBAC Good Practices
      • Official CVE Feed
      • Kubernetes Security Checklist
      • Securing a Cluster
      • OWASP
  • Open Source Tools
    • Cloud Native Computing Foundation (CNCF)
      • Security Projects
  • Infrastructure as Code
    • Kubernetes and Terraform
      • Key Focus Areas for Threat Hunters
      • Infastructure As Code: Kubernetes
      • Infrastructure as Code (IaC) Basics
      • Infastructure As Code Essential Commands
      • Terraform for Container Orchestration
      • Network and Load Balancing
      • Secrets Management
      • State Management
      • CI/CD
      • Security Considerations
      • Monitoring and Logging
      • Scaling and High Availability
      • Backup and Disaster Recovery
    • Helm
      • What is Helm?
      • Helm Architecture
      • Write Helm Charts
      • Using Helm Charts
      • Customizing Helm Charts
      • Customizing Helm Charts
      • Building Your Own Helm Chart
      • Advanced Helm Chart Customization
      • Helm Repositories
      • Helm Best Practices
      • Helmfile and Continuous Integration
      • Managing Secrets with Helm and Helm Secrets
      • Troubleshooting and Debugging Helm
      • Production Deployments
      • Helm Case Studies
Powered by GitBook
On this page
  • Kubernetes Master Node Overview
  • 1. API Server (kube-apiserver)
  • 2. etcd
  • 3. Controller Manager (kube-controller-manager)
  • 4. Scheduler (kube-scheduler)
  • 5. Cloud Controller Manager
  • 6. Cluster State Store (etcd)
  • How the Master Node Components Work Together
  1. Kubernetes Fundamentals
  2. Kubernetes Components

Kubernetes Master Node

Kubernetes Master Node Overview

The Kubernetes master node, also known as the control plane, is the central control unit that manages the entire Kubernetes cluster. It is responsible for making global decisions about the cluster, such as scheduling, and for detecting and responding to cluster events (e.g., starting up new pods when a deployment's replicas field is unsatisfied). Below are the key components of the Kubernetes master node:

1. API Server (kube-apiserver)

  • Role:

    • The API server is the front end of the Kubernetes control plane. It exposes the Kubernetes API, which is the central interface for all interactions with the cluster. All the administrative tasks, such as scaling applications, deploying new applications, and managing cluster resources, are done via API calls to the API server.

  • Functions:

    • Handles RESTful calls to the API.

    • Authenticates and validates API requests.

    • Serves as the gateway for communication between different components of the control plane and the cluster.

    • Stores the state of the cluster in etcd.

2. etcd

  • Role:

    • etcd is a distributed key-value store that Kubernetes uses to store all its configuration data, state data, and metadata. It is the primary database for Kubernetes and serves as the single source of truth for the entire cluster.

  • Functions:

    • Stores the entire cluster state, including the configuration and status of the nodes, pods, deployments, and other resources.

    • Provides reliable data storage and retrieval, ensuring the consistency of data across the cluster.

    • Supports cluster leader election and other distributed consensus tasks.

3. Controller Manager (kube-controller-manager)

  • Role:

    • The controller manager is a daemon that runs the core control loops, which are known as controllers. Each controller tries to bring the current state of the cluster closer to the desired state by constantly monitoring the cluster and making adjustments as needed.

  • Functions:

    • Node Controller: Responsible for noticing and responding when nodes go down.

    • Replication Controller: Ensures that the correct number of pod replicas are running in the cluster.

    • Endpoints Controller: Manages the endpoints in the cluster, associating them with services for proper routing of traffic.

    • Service Account and Token Controllers: Create default accounts and API access tokens for new namespaces.

4. Scheduler (kube-scheduler)

  • Role:

    • The scheduler is responsible for assigning pods to nodes in the cluster. It takes into account the resource requirements of the pods, as well as any constraints (e.g., affinity rules, node taints) and available resources on the nodes.

  • Functions:

    • Watches for unassigned pods and assigns them to appropriate nodes.

    • Considers factors such as CPU, memory, network, and storage availability on nodes.

    • Evaluates the scheduling policies, such as taints, tolerations, and affinities, to ensure that pods are placed on nodes that meet their requirements.

5. Cloud Controller Manager

  • Role:

    • The cloud controller manager is responsible for managing cloud-specific controller logic, allowing Kubernetes to interact with the underlying cloud infrastructure. This component is especially useful in environments where Kubernetes is running on a cloud platform like AWS, Azure, or GCP.

  • Functions:

    • Node Controller: Checks the cloud provider to determine if a node has been deleted after it stops responding.

    • Route Controller: Responsible for configuring routes in the cloud provider’s network when using the Kubernetes cluster on a cloud platform.

    • Service Controller: Manages load balancers in the cloud to expose services externally.

6. Cluster State Store (etcd)

  • While etcd is a key component of the control plane, it deserves special mention because of its critical role in storing the state of the cluster. The health of the etcd store is vital for the operation of the Kubernetes cluster.

How the Master Node Components Work Together

  • Control Loop: The controllers managed by the controller manager are constantly monitoring the state of the cluster. For example, if a node fails, the node controller in the controller manager will detect this and attempt to bring the system back to the desired state, often by creating replacement pods on other nodes.

  • API Server as the Hub: The API server is the central hub of the control plane, interacting with etcd to retrieve the cluster state, interacting with the scheduler to place pods on nodes, and interacting with the controller manager to ensure the cluster is running as expected.

  • Scheduler Decisions: The scheduler is key in deciding where pods will run based on the resource availability and constraints defined by the user, ensuring efficient utilization of the cluster’s resources.

The master node controls the overall operation of the cluster, ensuring that the desired state (as defined by the user) is maintained across the worker nodes, regardless of failures or changes in the cluster environment. Without the master node, Kubernetes would not be able to manage the cluster autonomously.

PreviousKubernetes ComponentsNextWorker Nodes

Last updated 7 months ago