Production-Grade Container Orchestration

Synopsis Create a secret based on a file, directory, or specified literal value. A single secret may package one or more key/value pairs. When creating a secret based on a file, the key will default to the basename of the file, and the value will default to the file content. If the basename is an invalid key or you wish to chose your own, you may specify an alternate key.

This page shows how to use kubectl exec to get a shell to a running container. Before you begin You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. It is recommended to run this tutorial on a cluster with at least two nodes that are not acting as control plane hosts. If you do not already have a cluster, you can create one by using minikube or you can use one of these Kubernetes playgrounds:

Kubernetes keeps many aspects of how pods execute on nodes abstracted from the user. This is by design. However, some workloads require stronger guarantees in terms of latency and/or performance in order to operate acceptably. The kubelet provides methods to enable more complex workload placement policies while keeping the abstraction free from explicit placement directives. You can manage topology within nodes. This means helping the kubelet to configure the host operating system so that Pods and containers are placed on the correct side of inner boundaries, such as NUMA domains.

This task shows how to create a frontend and a backend microservice. The backend microservice is a hello greeter. The frontend exposes the backend using nginx and a Kubernetes Service object. Objectives Create and run a sample hello backend microservice using a Deployment object. Use a Service object to send traffic to the backend microservice's multiple replicas. Create and run a nginx frontend microservice, also using a Deployment object. Configure the frontend microservice to send traffic to the backend microservice.

This page shows how to run automated tasks using Kubernetes CronJob object. Before you begin You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. It is recommended to run this tutorial on a cluster with at least two nodes that are not acting as control plane hosts. If you do not already have a cluster, you can create one by using minikube or you can use one of these Kubernetes playgrounds:

When running Kubernetes in an environment with strict network boundaries, such as on-premises datacenter with physical network firewalls or Virtual Networks in Public Cloud, it is useful to be aware of the ports and protocols used by Kubernetes components. Control plane Protocol Direction Port Range Purpose Used By TCP Inbound 6443 Kubernetes API server All TCP Inbound 2379-2380 etcd server client API kube-apiserver, etcd TCP Inbound 10250 Kubelet API Self, Control plane TCP Inbound 10259 kube-scheduler Self TCP Inbound 10257 kube-controller-manager Self Although etcd ports are included in control plane section, you can also host your own etcd cluster externally or on custom ports.

Production-Grade Container Orchestration

The kubelet is mostly a stateless process running on a Kubernetes node. This document outlines files that kubelet reads and writes. Note:This document is for informational purpose and not describing any guaranteed behaviors or APIs. It lists resources used by the kubelet, which is an implementation detail and a subject to change at any release. The kubelet typically uses the control plane as the source of truth on what needs to run on the Node, and the container runtime to retrieve the current state of containers.

FEATURE STATE: Kubernetes v1.30 [beta](enabled by default) Checkpointing a container is the functionality to create a stateful copy of a running container. Once you have a stateful copy of a container, you could move it to a different computer for debugging or similar purposes. If you move the checkpointed container data to a computer that's able to restore it, that restored container continues to run at exactly the same point it was checkpointed.