instruction: Explain Communication between Nodes and the Control Plane
output: You are viewing documentation for Kubernetes version: v1.31
  Kubernetes v1.31 documentation is no longer actively maintained. The version you are currently viewing is a static snapshot. For up-to-date information, see the
  latest version.
  Communication between Nodes and the Control Plane
  This document catalogs the communication paths between the
  API server
  and the Kubernetes
  cluster
  The intent is to allow users to customize their installation to harden the network configuration
  such that the cluster can be run on an untrusted network (or on fully public IPs on a cloud
  provider).
  Node to Control Plane
  Kubernetes has a "hub-and-spoke" API pattern. All API usage from nodes (or the pods they run)
  terminates at the API server. None of the other control plane components are designed to expose
  remote services. The API server is configured to listen for remote connections on a secure HTTPS
  port (typically 443) with one or more forms of client
  authentication
  enabled.
  One or more forms of
  authorization
  should be
  enabled, especially if
  anonymous requests
  service account tokens
  are allowed.
  Nodes should be provisioned with the public root
  certificate
  for the cluster such that they can
  connect securely to the API server along with valid client credentials. A good approach is that the
  client credentials provided to the kubelet are in the form of a client certificate. See
  kubelet TLS bootstrapping
  for automated provisioning of kubelet client certificates.
  Pods
  that wish to connect to the API server can do so securely by leveraging a service account so
  that Kubernetes will automatically inject the public root certificate and a valid bearer token
  into the pod when it is instantiated.
  kubernetes
  service (in
  default
  namespace) is configured with a virtual IP address that is
  redirected (via
  kube-proxy
  ) to the HTTPS endpoint on the API server.
  The control plane components also communicate with the API server over the secure port.
  As a result, the default operating mode for connections from the nodes and pod running on the
  nodes to the control plane is secured by default and can run over untrusted and/or public
  networks.
  Control plane to node
  There are two primary communication paths from the control plane (the API server) to the nodes.
  The first is from the API server to the
  kubelet
  process which runs on each node in the cluster.
  The second is from the API server to any node, pod, or service through the API server's
  proxy
  functionality.
  API server to kubelet
  The connections from the API server to the kubelet are used for:
  Fetching logs for pods.
  Attaching (usually through
  kubectl
  ) to running pods.
  Providing the kubelet's port-forwarding functionality.
  These connections terminate at the kubelet's HTTPS endpoint. By default, the API server does not
  verify the kubelet's serving certificate, which makes the connection subject to man-in-the-middle
  attacks and
  unsafe
  to run over untrusted and/or public networks.
  To verify this connection, use the
  --kubelet-certificate-authority
  flag to provide the API
  server with a root certificate bundle to use to verify the kubelet's serving certificate.
  If that is not possible, use
  SSH tunneling
  between the API server and kubelet if
  required to avoid connecting over an
  untrusted or public network.
  Finally,
  Kubelet authentication and/or authorization
  should be enabled to secure the kubelet API.
  API server to nodes, pods, and services
  The connections from the API server to a node, pod, or service default to plain HTTP connections
  and are therefore neither authenticated nor encrypted. They can be run over a secure HTTPS
  connection by prefixing
  https:
  to the node, pod, or service name in the API URL, but they will
  not validate the certificate provided by the HTTPS endpoint nor provide client credentials. So
  while the connection will be encrypted, it will not provide any guarantees of integrity. These
  connections
  are not currently safe
  to run over untrusted or public networks.
  SSH tunnels
  Kubernetes supports
  SSH tunnels
  to protect the control plane to nodes communication paths. In this
  configuration, the API server initiates an SSH tunnel to each node in the cluster (connecting to
  the SSH server listening on port 22) and passes all traffic destined for a kubelet, node, pod, or
  service through the tunnel.
  This tunnel ensures that the traffic is not exposed outside of the network in which the nodes are
  running.
  Note:
  SSH tunnels are currently deprecated, so you shouldn't opt to use them unless you know what you
  are doing. The
  Konnectivity service
  is a replacement for this
  communication channel.
  Konnectivity service
  FEATURE STATE:
  Kubernetes v1.18 [beta]
  As a replacement to the SSH tunnels, the Konnectivity service provides TCP level proxy for the
  control plane to cluster communication. The Konnectivity service consists of two parts: the
  Konnectivity server in the control plane network and the Konnectivity agents in the nodes network.
  The Konnectivity agents initiate connections to the Konnectivity server and maintain the network
  connections.
  After enabling the Konnectivity service, all control plane to nodes traffic goes through these
  connections.
  Follow the
  Konnectivity service task
  to set
  up the Konnectivity service in your cluster.
  What's next
  Read about the
  Kubernetes control plane components
  Learn more about
  Hubs and Spoke model
  Learn how to
  Secure a Cluster
  Learn more about the
  Kubernetes API
  Set up Konnectivity service
  Use Port Forwarding to Access Applications in a Cluster
  Learn how to
  Fetch logs for Pods
  use kubectl port-forward
  Was this page helpful?
  Thanks for the feedback. If you have a specific, answerable question about how to use Kubernetes, ask it on
  Stack Overflow
  Open an issue in the
  GitHub Repository
  if you want to
  report a problem
  suggest an improvement
  Last modified September 01, 2024 at 1:54 AM PST:
  Fix broken links from "overview/components/#..." to "architecture/#..." (#47724) (7e64c2db82)