KB:Kubernetes Endpoints

In Kubernetes, an endpoint refers to the set of network addresses (IP addresses and ports) that are associated with a Kubernetes service. Endpoints are used to keep track of the Pods that are dynamically assigned to a service. Here's a more detailed breakdown of what endpoints are and how they work:

Key Concepts:

  1. Services:

    • A Kubernetes Service is an abstraction that defines a logical set of Pods and a policy by which to access them. Services enable network access to a group of Pods in a Kubernetes cluster.
    • Services can be exposed internally within the cluster (ClusterIP), externally to the internet (LoadBalancer or NodePort), or can be headless (without a stable IP address).

  2. Pods:

    • Pods are the smallest and simplest Kubernetes objects. A Pod represents a single instance of a running process in your cluster.
    • Pods are ephemeral, meaning they can be created and destroyed dynamically.

  3. Endpoints:

    • Endpoints in Kubernetes are the objects that associate a service with the actual Pod IP addresses and ports.
    • When a service is created, an endpoint object is also created and updated dynamically as Pods are created, destroyed, or moved.

How Endpoints Work:

  • When a service is defined, Kubernetes automatically creates an associated endpoint object.
  • The endpoint object lists all the IP addresses and ports of the Pods that are part of the service.
  • Whenever a Pod is added or removed from the service, the endpoint object is updated accordingly.
  • This allows the service to dynamically keep track of the current set of Pods it should route traffic to.

Types of Endpoints:

  1. Regular Endpoints:

    • These are the standard endpoints created for each service, mapping the service to the IP addresses and ports of the associated Pods.

  2. Headless Services:

    • When a service is created without a cluster IP (by setting the clusterIP field to "None"), it is known as a headless service.
    • For headless services, Kubernetes does not create a standard endpoint object. Instead, DNS entries are created for each Pod, allowing direct access to the Pods.


Endpoints in Kubernetes are not directly exposed externally. Instead, they are used internally within the Kubernetes cluster to keep track of the IP addresses and ports of the Pods that are associated with a service. Here's a deeper look at how endpoints interact with external exposure:

Internal vs. External Exposure

  • Internal Exposure:

    • Endpoints are primarily used for internal service discovery. Kubernetes services use these endpoints to route traffic to the appropriate Pods within the cluster.
    • The endpoints object itself is not accessible from outside the cluster; it is managed by the Kubernetes control plane to maintain the mapping between services and Pods.

  • External Exposure:

    • To expose services externally, Kubernetes provides different types of services:
      • NodePort: Exposes the service on each Node’s IP at a static port. This makes the service accessible externally through <NodeIP>:<NodePort>.
      • LoadBalancer: Creates an external load balancer (if supported by the underlying infrastructure) and assigns a public IP to the service.
      • Ingress: Manages external access to services, typically HTTP and HTTPS, providing features like load balancing, SSL termination, and name-based virtual hosting.
Summary:
  • Endpoints in Kubernetes are not directly exposed externally.
  • They are used internally to manage the mapping between services and Pods.
  • To expose services externally, Kubernetes provides mechanisms like NodePort, LoadBalancer, and Ingress, which handle the external routing while relying on the internal endpoint objects to distribute traffic to the Pods.
  • Endpoints are updated whenever the set of Pods associated with a service changes, not specifically when the service is exposed.
  • The service’s exposure method (ClusterIP, NodePort, LoadBalancer, Ingress) determines how the traffic reaches the service but does not directly trigger endpoint updates.
  • Endpoint updates are driven by changes in the Pods (creation, deletion, rescheduling) that match the service's selector.

Comments

Post a Comment

Popular posts from this blog

KB: Azure ACA Container fails to start (no User Assigned or Delegated Managed Identity found for specified ClientId)

Image
When deploying secure workloads using Azure Container Apps (ACA) , teams often face confusion between User Assigned Managed Identities (UAMI) and App Registrations . While both entities are visible in Azure Active Directory and have similar identifiers (Application ID, Object ID), they serve very different purposes . This confusion can lead to authentication failures when accessing services like Azure App Configuration or Key Vault . A common issue occurs when a container app is configured with a managed identity, but the environment variables or role assignments mistakenly reference an App Registration instead, causing errors like: "No User Assigned or Delegated Managed Identity found for specified ClientId" This article breaks down the difference between UAMI and App Registrations, explains why this issue happens, and outlines the correct approach to resolve it. Symptoms Azure Container App fails to authenticate to Azure App Configuration or other services. Logs...
Read more

Electron Process Execution Failure with FSLogix

  Technical Note: Electron Process Execution Failure with FSLogix 1. Overview When running Electron-based applications in environments using FSLogix Profile or Office Containers , users may encounter issues where the Electron process fails to launch or execute properly . This behavior has been observed in Azure Virtual Desktop (AVD) , Windows Virtual Desktop (WVD) , and other environments where FSLogix filter drivers are active. 2. Symptoms Electron-based applications (e.g., desktop apps built on Electron, CLI wrappers) do not start , remain unresponsive, or terminate silently. No visible logs or error messages are generated by the application. Standard executables run correctly when placed outside of the FSLogix-controlled profile path (e.g., copying to C:\Temp allows execution). The issue is reproducible across all Electron apps in the FSLogix-managed profile. 3. Root Cause The issue is linked to FSLogix filter drivers ( frxdrv , frxdrvvt , frxccd ) interfe...
Read more

KB:RMM VS DEX (Remote Monitoring Management vs Digital Employee Experience)

Digital Employee Experience (DEX) and Remote Monitoring and Management (RMM) tools serve different purposes and cater to distinct aspects of IT and employee management. Digital Employee Experience (DEX) Focus: Enhancing the overall experience of employees with their digital workplace tools and environment. Key Features: User Experience Monitoring: Tracks how employees interact with software and hardware, identifying issues impacting productivity. Performance Analytics: Provides insights into the performance of applications from the end-user's perspective. Feedback Mechanisms: Allows employees to report issues and give feedback on their digital tools and environment. Employee Well-being: Monitors factors that affect employee satisfaction and well-being, such as system performance and usability. Proactive Support: Identifies potential issues before they become significant problems, enabling proactive IT support. Goals: Improve employee satisfaction and productivity. Ensure a sm...
Read more