This is the multi-page printable view of this section. Click here to print.Return to the regular view of this page.Access Applications in a ClusterConfigure load balancing, port forwarding, or setup firewall or DNS configurations to access applications in a cluster.1: Deploy and Access the Kubernetes Dashboard2: Accessing Clusters3: Configure Access to Multiple Clusters4: Use Port Forwarding to Access Applications in a Cluster5: Use a Service to Access an Application in a Cluster6: Connect a Frontend to a Backend Using Services7: Create an External Load Balancer8: List All Container Images Running in a Cluster9: Set up Ingress on Minikube with the NGINX Ingress Controller10: Communicate Between Containers in the Same Pod Using a Shared Volume11: Configure DNS for a Cluster12: Access Services Running on Clusters1 - Deploy and Access the Kubernetes DashboardDeploy the web UI (Kubernetes Dashboard) and access it.Dashboard is a web-based Kubernetes user interface. You can use Dashboard to deploy containerized applications to a Kubernetes cluster, troubleshoot your containerized application, and manage the cluster resources. You can use Dashboard to get an overview of applications running on your cluster, as well as for creating or modifying individual Kubernetes resources (such as Deployments, Jobs, DaemonSets, etc). For example, you can scale a Deployment, initiate a rolling update, restart a pod or deploy new applications using a deploy wizard.Dashboard also provides information on the state of Kubernetes resources in your cluster and on any errors that may have occurred.Deploying the Dashboard UINote:Kubernetes Dashboard supports only Helm-based installation currently as it is faster and gives us better control over all dependencies required by Dashboard to run.The Dashboard UI is not deployed by default. To deploy it, run the following command:# Add kubernetes-dashboard repository helm repo add kubernetes-dashboard https://kubernetes.github.io/dashboard/ # Deploy a Helm Release named "kubernetes-dashboard" using the kubernetes-dashboard chart helm upgrade --install kubernetes-dashboard kubernetes-dashboard/kubernetes-dashboard --create-namespace --namespace kubernetes-dashboard Accessing the Dashboard UITo protect your cluster data, Dashboard deploys with a minimal RBAC configuration by default. Currently, Dashboard only supports logging in with a Bearer Token. To create a token for this demo, you can follow our guide on creating a sample user.Warning:The sample user created in the tutorial will have administrative privileges and is for educational purposes only.Command line proxyYou can enable access to the Dashboard using the kubectl command-line tool, by running the following command:kubectl -n kubernetes-dashboard port-forward svc/kubernetes-dashboard-kong-proxy 8443:443 Kubectl will make Dashboard available at https://localhost:8443.The UI can only be accessed from the machine where the command is executed. See kubectl port-forward --help for more options.Note:The kubeconfig authentication method does not support external identity providers or X.509 certificate-based authentication.Welcome viewWhen you access Dashboard on an empty cluster, you'll see the welcome page. This page contains a link to this document as well as a button to deploy your first application. In addition, you can view which system applications are running by default in the kube-system namespace of your cluster, for example the Dashboard itself.Deploying containerized applicationsDashboard lets you create and deploy a containerized application as a Deployment and optional Service with a simple wizard. You can either manually specify application details, or upload a YAML or JSON manifest file containing application configuration.Click the CREATE button in the upper right corner of any page to begin.Specifying application detailsThe deploy wizard expects that you provide the following information:App name (mandatory): Name for your application. A label with the name will be added to the Deployment and Service, if any, that will be deployed.The application name must be unique within the selected Kubernetes namespace. It must start with a lowercase character, and end with a lowercase character or a number, and contain only lowercase letters, numbers and dashes (-). It is limited to 24 characters. Leading and trailing spaces are ignored.Container image (mandatory): The URL of a public Docker container image on any registry, or a private image (commonly hosted on the Google Container Registry or Docker Hub). The container image specification must end with a colon.Number of pods (mandatory): The target number of Pods you want your application to be deployed in. The value must be a positive integer.A Deployment will be created to maintain the desired number of Pods across your cluster.Service (optional): For some parts of your application (e.g. frontends) you may want to expose a Service onto an external, maybe public IP address outside of your cluster (external Service).Note:For external Services, you may need to open up one or more ports to do so.Other Services that are only visible from inside the cluster are called internal Services.Irrespective of the Service type, if you choose to create a Service and your container listens on a port (incoming), you need to specify two ports. The Service will be created mapping the port (incoming) to the target port seen by the container. This Service will route to your deployed Pods. Supported protocols are TCP and UDP. The internal DNS name for this Service will be the value you specified as application name above.If needed, you can expand the Advanced options section where you can specify more settings:Description: The text you enter here will be added as an annotation to the Deployment and displayed in the application's details.Labels: Default labels to be used for your application are application name and version. You can specify additional labels to be applied to the Deployment, Service (if any), and Pods, such as release, environment, tier, partition, and release track.Example:release=1.0 tier=frontend environment=pod track=stable Namespace: Kubernetes supports multiple virtual clusters backed by the same physical cluster. These virtual clusters are called namespaces. They let you partition resources into logically named groups.Dashboard offers all available namespaces in a dropdown list, and allows you to create a new namespace. The namespace name may contain a maximum of 63 alphanumeric characters and dashes (-) but can not contain capital letters. Namespace names should not consist of only numbers. If the name is set as a number, such as 10, the pod will be put in the default namespace.In case the creation of the namespace is successful, it is selected by default. If the creation fails, the first namespace is selected.Image Pull Secret: In case the specified Docker container image is private, it may require pull secret credentials.Dashboard offers all available secrets in a dropdown list, and allows you to create a new secret. The secret name must follow the DNS domain name syntax, for example new.image-pull.secret. The content of a secret must be base64-encoded and specified in a .dockercfg file. The secret name may consist of a maximum of 253 characters.In case the creation of the image pull secret is successful, it is selected by default. If the creation fails, no secret is applied.CPU requirement (cores) and Memory requirement (MiB): You can specify the minimum resource limits for the container. By default, Pods run with unbounded CPU and memory limits.Run command and Run command arguments: By default, your containers run the specified Docker image's default entrypoint command. You can use the command options and arguments to override the default.Run as privileged: This setting determines whether processes in privileged containers are equivalent to processes running as root on the host. Privileged containers can make use of capabilities like manipulating the network stack and accessing devices.Environment variables: Kubernetes exposes Services through environment variables. You can compose environment variable or pass arguments to your commands using the values of environment variables. They can be used in applications to find a Service. Values can reference other variables using the $(VAR_NAME) syntax.Uploading a YAML or JSON fileKubernetes supports declarative configuration. In this style, all configuration is stored in manifests (YAML or JSON configuration files). The manifests use Kubernetes API resource schemas.As an alternative to specifying application details in the deploy wizard, you can define your application in one or more manifests, and upload the files using Dashboard.Using DashboardFollowing sections describe views of the Kubernetes Dashboard UI; what they provide and how can they be used.NavigationWhen there are Kubernetes objects defined in the cluster, Dashboard shows them in the initial view. By default only objects from the default namespace are shown and this can be changed using the namespace selector located in the navigation menu.Dashboard shows most Kubernetes object kinds and groups them in a few menu categories.Admin overviewFor cluster and namespace administrators, Dashboard lists Nodes, Namespaces and PersistentVolumes and has detail views for them. Node list view contains CPU and memory usage metrics aggregated across all Nodes. The details view shows the metrics for a Node, its specification, status, allocated resources, events and pods running on the node.WorkloadsShows all applications running in the selected namespace. The view lists applications by workload kind (for example: Deployments, ReplicaSets, StatefulSets). Each workload kind can be viewed separately. The lists summarize actionable information about the workloads, such as the number of ready pods for a ReplicaSet or current memory usage for a Pod.Detail views for workloads show status and specification information and surface relationships between objects. For example, Pods that ReplicaSet is controlling or new ReplicaSets and HorizontalPodAutoscalers for Deployments.ServicesShows Kubernetes resources that allow for exposing services to external world and discovering them within a cluster. For that reason, Service and Ingress views show Pods targeted by them, internal endpoints for cluster connections and external endpoints for external users.StorageStorage view shows PersistentVolumeClaim resources which are used by applications for storing data.ConfigMaps and SecretsShows all Kubernetes resources that are used for live configuration of applications running in clusters. The view allows for editing and managing config objects and displays secrets hidden by default.Logs viewerPod lists and detail pages link to a logs viewer that is built into Dashboard. The viewer allows for drilling down logs from containers belonging to a single Pod.What's

Access Applications in a Cluster


This is the multi-page printable view of this section. Click here to print.Return to the regular view of this page.Kubernetes API1: Workload Resources1.1: Pod1.2: Binding1.3: PodTemplate1.4: ReplicationController1.5: ReplicaSet1.6: Deployment1.7: StatefulSet1.8: ControllerRevision1.9: DaemonSet1.10: Job1.11: CronJob1.12: HorizontalPodAutoscaler1.13: HorizontalPodAutoscaler1.14: PriorityClass1.15: DeviceTaintRule v1alpha31.16: ResourceClaim1.17: ResourceClaimTemplate1.18: ResourceSlice2: Service Resources2.1: Service2.2: Endpoints2.3: EndpointSlice2.4: Ingress2.5: IngressClass3: Config and Storage Resources3.1: ConfigMap3.2: Secret3.3: CSIDriver3.4: CSINode3.5: CSIStorageCapacity3.6: PersistentVolumeClaim3.7: PersistentVolume3.8: StorageClass3.9: StorageVersionMigration v1alpha13.10: Volume3.11: VolumeAttachment3.12: VolumeAttributesClass4: Authentication Resources4.1: ServiceAccount4.2: TokenRequest4.3: TokenReview4.4: CertificateSigningRequest4.5: ClusterTrustBundle v1beta14.6: SelfSubjectReview4.7: PodCertificateRequest v1alpha15: Authorization Resources5.1: LocalSubjectAccessReview5.2: SelfSubjectAccessReview5.3: SelfSubjectRulesReview5.4: SubjectAccessReview5.5: ClusterRole5.6: ClusterRoleBinding5.7: Role5.8: RoleBinding6: Policy Resources6.1: FlowSchema6.2: LimitRange6.3: ResourceQuota6.4: NetworkPolicy6.5: PodDisruptionBudget6.6: PriorityLevelConfiguration6.7: ValidatingAdmissionPolicy6.8: ValidatingAdmissionPolicyBinding6.9: MutatingAdmissionPolicy v1beta16.10: MutatingAdmissionPolicyBinding v1alpha17: Extend Resources7.1: CustomResourceDefinition7.2: DeviceClass7.3: MutatingWebhookConfiguration7.4: ValidatingWebhookConfiguration8: Cluster Resources8.1: APIService8.2: ComponentStatus8.3: Event8.4: IPAddress8.5: Lease8.6: LeaseCandidate v1beta18.7: Namespace8.8: Node8.9: RuntimeClass8.10: ServiceCIDR9: Common Definitions9.1: DeleteOptions9.2: LabelSelector9.3: ListMeta9.4: LocalObjectReference9.5: NodeSelectorRequirement9.6: ObjectFieldSelector9.7: ObjectMeta9.8: ObjectReference9.9: Patch9.10: Quantity9.11: ResourceFieldSelector9.12: Status9.13: TypedLocalObjectReference10: Other Resources10.1: MutatingAdmissionPolicyBindingList v1beta111: Common ParametersKubernetes' API is the application that serves Kubernetes functionality through a RESTful interface and stores the state of the cluster.Kubernetes resources and "records of intent" are all stored as API objects, and modified via RESTful calls to the API. The API allows configuration to be managed in a declarative way. Users can interact with the Kubernetes API directly, or via tools like kubectl. The core Kubernetes API is flexible and can also be extended to support custom resources.1 - Workload Resources1.1 - PodPod is a collection of containers that can run on a host.apiVersion: v1import "k8s.io/api/core/v1"PodPod is a collection of containers that can run on a host. This resource is created by clients and scheduled onto hosts.apiVersion: v1kind: Podmetadata (ObjectMeta)Standard object's metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadataspec (PodSpec)Specification of the desired behavior of the pod. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-statusstatus (PodStatus)Most recently observed status of the pod. This data may not be up to date. Populated by the system. Read-only. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-statusPodSpecPodSpec is a description of a pod.Containerscontainers ([]Container), requiredPatch strategy: merge on key nameMap: unique values on key name will be kept during a mergeList of containers belonging to the pod. Containers cannot currently be added or removed. There must be at least one container in a Pod. Cannot be updated.initContainers ([]Container)Patch strategy: merge on key nameMap: unique values on key name will be kept during a mergeList of initialization containers belonging to the pod. Init containers are executed in order prior to containers being started. If any init container fails, the pod is considered to have failed and is handled according to its restartPolicy. The name for an init container or normal container must be unique among all containers. Init containers may not have Lifecycle actions, Readiness probes, Liveness probes, or Startup probes. The resourceRequirements of an init container are taken into account during scheduling by finding the highest request/limit for each resource type, and then using the max of that value or the sum of the normal containers. Limits are applied to init containers in a similar fashion. Init containers cannot currently be added or removed. Cannot be updated. More info: https://kubernetes.io/docs/concepts/workloads/pods/init-containers/ephemeralContainers ([]EphemeralContainer)Patch strategy: merge on key nameMap: unique values on key name will be kept during a mergeList of ephemeral containers run in this pod. Ephemeral containers may be run in an existing pod to perform user-initiated actions such as debugging. This list cannot be specified when creating a pod, and it cannot be modified by updating the pod spec. In order to add an ephemeral container to an existing pod, use the pod's ephemeralcontainers subresource.imagePullSecrets ([]LocalObjectReference)Patch strategy: merge on key nameMap: unique values on key name will be kept during a mergeImagePullSecrets is an optional list of references to secrets in the same namespace to use for pulling any of the images used by this PodSpec. If specified, these secrets will be passed to individual puller implementations for them to use. More info: https://kubernetes.io/docs/concepts/containers/images#specifying-imagepullsecrets-on-a-podenableServiceLinks (boolean)EnableServiceLinks indicates whether information about services should be injected into pod's environment variables, matching the syntax of Docker links. Optional: Defaults to true.os (PodOS)Specifies the OS of the containers in the pod. Some pod and container fields are restricted if this is set.If the OS field is set to linux, the following fields must be unset: -securityContext.windowsOptionsIf the OS field is set to windows, following fields must be unset: - spec.hostPID - spec.hostIPC - spec.hostUsers - spec.resources - spec.securityContext.appArmorProfile - spec.securityContext.seLinuxOptions - spec.securityContext.seccompProfile - spec.securityContext.fsGroup - spec.securityContext.fsGroupChangePolicy - spec.securityContext.sysctls - spec.shareProcessNamespace - spec.securityContext.runAsUser - spec.securityContext.runAsGroup - spec.securityContext.supplementalGroups - spec.securityContext.supplementalGroupsPolicy - spec.containers[].securityContext.appArmorProfile - spec.containers[].securityContext.seLinuxOptions - spec.containers[].securityContext.seccompProfile - spec.containers[].securityContext.capabilities - spec.containers[].securityContext.readOnlyRootFilesystem - spec.containers[].securityContext.privileged - spec.containers[].securityContext.allowPrivilegeEscalation - spec.containers[].securityContext.procMount - spec.containers[].securityContext.runAsUser - spec.containers[].securityContext.runAsGroupPodOS defines the OS parameters of a pod.os.name (string), requiredName is the name of the operating system. The currently supported values are linux and windows. Additional value may be defined in future and can be one of: https://github.com/opencontainers/runtime-spec/blob/master/config.md#platform-specific-configuration Clients should expect to handle additional values and treat unrecognized values in this field as os: nullVolumesvolumes ([]Volume)Patch strategies: retainKeys, merge on key nameMap: unique values on key name will be kept during a mergeList of volumes that can be mounted by containers belonging to the pod. More info: https://kubernetes.io/docs/concepts/storage/volumesSchedulingnodeSelector (map[string]string)NodeSelector is a selector which must be true for the pod to fit on a node. Selector which must match a node's labels for the pod to be scheduled on that node. More info: https://kubernetes.io/docs/concepts/configuration/assign-pod-node/nodeName (string)NodeName indicates in which node this pod is scheduled. If empty, this pod is a candidate for scheduling by the scheduler defined in schedulerName. Once this field is set, the kubelet for this node becomes responsible for the lifecycle of this pod. This field should not be used to express a desire for the pod to be scheduled on a specific node. https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#nodenameaffinity (Affinity)If specified, the pod's scheduling constraintsAffinity is a group of affinity scheduling rules.affinity.nodeAffinity (NodeAffinity)Describes node affinity scheduling rules for the pod.affinity.podAffinity (PodAffinity)Describes pod affinity scheduling rules (e.g. co-locate this pod in the same node, zone, etc. as some other pod(s)).affinity.podAntiAffinity (PodAntiAffinity)Describes pod anti-affinity scheduling rules (e.g. avoid putting this pod in the same node, zone, etc. as some other pod(s)).tolerations ([]Toleration)Atomic: will be replaced during a mergeIf specified, the pod's tolerations.The pod this Toleration is attached to tolerates any taint that matches the triple <key,value,effect> using the matching operator .tolerations.key (string)Key is the taint key that the toleration applies to. Empty means match all taint keys. If the key is empty, operator must be Exists; this combination means to match all values and all keys.tolerations.operator (string)Operator represents a key's relationship to the value. Valid operators are Exists and Equal. Defaults to Equal. Exists is equivalent to wildcard for value, so that a pod can tolerate all taints of a particular category.tolerations.value (string)Value is the taint value the toleration matches to. If the operator is Exists, the value should be empty, otherwise just a regular string.tolerations.effect (string)Effect indicates the taint effect to match. Empty means match all taint effects. When specified, allowed values are NoSchedule, PreferNoSchedule and NoExecute.tolerations.tolerationSeconds (int64)TolerationSeconds represents the period of time the toleration (which must be of effect NoExecute, otherwise this field is ignored) tolerates the taint. By default, it is not set, which means tolerate the taint forever (do not evict). Zero and negative values will be treated as 0 (evict immediately) by the system.schedulerName (string)If specified, the pod will be dispatched by specified scheduler. If not specified, the pod will be dispatched by default scheduler.runtimeClassName (string)RuntimeClassName refers to a RuntimeClass object in the node.k8s.io group, which should be used to run this pod. If no RuntimeClass resource matches the named class, the pod will not be run. If unset or empty, the "legacy" RuntimeClass will be used, which is an implicit class with an empty definition that uses the default runtime handler. More info: https://git.k8s.io/enhancements/keps/sig-node/585-runtime-classpriorityClassName (string)If specified, indicates the pod's priority. "system-node-critical" and "system-cluster-critical" are two special keywords which indicate the highest priorities with the former being the highest priority. Any other name must be defined by creating a PriorityClass object with that name. If not specified, the pod priority will be default or zero if there is no default.priority (int32)The priority value. Various system components use this field to find the priority of the pod. When Priority Admission Controller is enabled, it prevents users from setting this field. The admission controller populates this field from PriorityClassName. The higher the value, the higher the priority.preemptionPolicy (string)PreemptionPolicy is the Policy for preempting pods with lower priority. One of Never, PreemptLowerPriority. Defaults to PreemptLowerPriority if unset.topologySpreadConstraints ([]TopologySpreadConstraint)Patch strategy: merge on key topologyKeyMap: unique values on keys topologyKey, whenUnsatisfiable will be kept during a mergeTopologySpreadConstraints describes how a group of pods ought to spread across topology domains. Scheduler will schedule pods in a way which abides by the constraints. All topologySpreadConstraints are ANDed.TopologySpreadConstraint specifies how to spread matching pods among the given topology.topologySpreadConstraints.maxSkew (int32), requiredMaxSkew describes the degree to which pods may be unevenly distributed. When whenUnsatisfiable=DoNotSchedule, it is the maximum permitted difference between the number of matching pods in the target topology and the global minimum. The global minimum is the minimum number of matching pods in an eligible domain or zero if the number of eligible domains is less than MinDomains. For example, in a 3-zone cluster, MaxSkew is set to 1, and pods with the same labelSelector spread as 2/2/1: In this case, the global minimum is 1. | zone1 | zone2 | zone3 | | P P | P P | P | - if MaxSkew is 1, incoming pod can only be scheduled to zone3 to become 2/2/2; scheduling it onto zone1(zone2) would make the ActualSkew(3-1) on zone1(zone2) violate MaxSkew(1). - if MaxSkew is 2, incoming pod can be scheduled onto any zone. When whenUnsatisfiable=ScheduleAnyway, it is used to give higher precedence to topologies that satisfy it. It's a required field. Default value is 1 and 0 is not allowed.topologySpreadConstraints.topologyKey (string), requiredTopologyKey is the key of node labels. Nodes that have a label with this key and identical values are considered to be in the same topology. We consider each <key, value> as a "bucket", and try to put balanced number of pods into each bucket. We define a domain as a particular instance of a topology. Also, we define an eligible domain as a domain whose nodes meet the requirements of nodeAffinityPolicy and nodeTaintsPolicy. e.g. If TopologyKey is "kubernetes.io/hostname", each Node is a domain of that topology. And, if TopologyKey is "topology.kubernetes.io/zone", each zone is a domain of that topology. It's a required field.topologySpreadConstraints.whenUnsatisfiable (string), requiredWhenUnsatisfiable indicates how to deal with a pod if it doesn't satisfy the spread constraint. - DoNotSchedule (default) tells the scheduler not to schedule it. - ScheduleAnyway tells the scheduler to schedule the pod in any location, but giving higher precedence to topologies that would help reduce the skew. A constraint is considered "Unsatisfiable" for an incoming pod if and only if every possible node assignment for that pod would violate "MaxSkew" on some topology. For example, in a 3-zone cluster, MaxSkew is set to 1, and pods with the same labelSelector spread as 3/1/1: | zone1 | zone2 | zone3 | | P P P | P | P | If WhenUnsatisfiable is set to DoNotSchedule, incoming pod can only be scheduled to zone2(zone3) to become 3/2/1(3/1/2) as ActualSkew(2-1) on zone2(zone3) satisfies MaxSkew(1). In other words, the cluster can still be imbalanced, but scheduler won't make it more imbalanced. It's a required field.topologySpreadConstraints.labelSelector (LabelSelector)LabelSelector is used to find matching pods. Pods that match this label selector are counted to determine the number of pods in their corresponding topology domain.topologySpreadConstraints.matchLabelKeys ([]string)Atomic: will be replaced during a mergeMatchLabelKeys is a set of pod label keys to select the pods over which spreading will be calculated. The keys are used to lookup values from the incoming pod labels, those key-value labels are ANDed with labelSelector to select the group of existing pods over which spreading will be calculated for the incoming pod. The same key is forbidden to exist in both MatchLabelKeys and LabelSelector. MatchLabelKeys cannot be set when LabelSelector isn't set. Keys that don't exist in the incoming pod labels will be ignored. A null or empty list means only match against labelSelector.This is a beta field and requires the MatchLabelKeysInPodTopologySpread feature gate to be enabled (enabled by default).topologySpreadConstraints.minDomains (int32)MinDomains indicates a minimum number of eligible domains. When the number of eligible domains with matching topology keys is less than minDomains, Pod Topology Spread treats "global minimum" as 0, and then the calculation of Skew is performed. And when the number of eligible domains with matching topology keys equals or greater than minDomains, this value has no effect on scheduling. As a result, when the number of eligible domains is less than minDomains, scheduler won't schedule more than maxSkew Pods to those domains. If value is nil, the constraint behaves as if MinDomains is equal to 1. Valid values are integers greater than 0. When value is not nil, WhenUnsatisfiable must be DoNotSchedule.For example, in a 3-zone cluster, MaxSkew is set to 2, MinDomains is set to 5 and pods with the same labelSelector spread as 2/2/2: | zone1 | zone2 | zone3 | | P P | P P | P P | The number of domains is less than 5(MinDomains), so "global minimum" is treated as 0. In this situation, new pod with the same labelSelector cannot be scheduled, because computed skew will be 3(3 - 0) if new Pod is scheduled to any of the three zones, it will violate MaxSkew.topologySpreadConstraints.nodeAffinityPolicy (string)NodeAffinityPolicy indicates how we will treat Pod's nodeAffinity/nodeSelector when calculating pod topology spread skew. Options are: - Honor: only nodes matching nodeAffinity/nodeSelector are included in the calculations. - Ignore: nodeAffinity/nodeSelector are ignored. All nodes are included in the calculations.If this value is nil, the behavior is equivalent to the Honor policy.topologySpreadConstraints.nodeTaintsPolicy (string)NodeTaintsPolicy indicates how we will treat node taints when calculating pod topology spread skew. Options are: - Honor: nodes without taints, along with tainted nodes for which the incoming pod has a toleration, are included. - Ignore: node taints are ignored. All nodes are included.If this value is nil, the behavior is equivalent to the Ignore policy.overhead (map[string]Quantity)Overhead represents the resource overhead associated with running a pod for a given RuntimeClass. This field will be autopopulated at admission time by the RuntimeClass admission controller. If the RuntimeClass admission controller is enabled, overhead must not be set in Pod create requests. The RuntimeClass admission controller will reject Pod create requests which have the overhead already set. If RuntimeClass is configured and selected in the PodSpec, Overhead will be set to the value defined in the corresponding RuntimeClass, otherwise it will remain unset and treated as zero. More info: https://git.k8s.io/enhancements/keps/sig-node/688-pod-overhead/README.mdLifecyclerestartPolicy (string)Restart policy for all containers within the pod. One of Always, OnFailure, Never. In some contexts, only a subset of those values may be permitted. Default to Always. More info: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#restart-policyterminationGracePeriodSeconds (int64)Optional duration in seconds the pod needs to terminate gracefully. May be decreased in delete request. Value must be non-negative integer. The value zero indicates stop immediately via the kill signal (no opportunity to shut down). If this value is nil, the default grace period will be used instead. The grace period is the duration in seconds after the processes running in the pod are sent a termination signal and the time when the processes are forcibly halted with a kill signal. Set this value longer than the expected cleanup time for your process. Defaults to 30 seconds.activeDeadlineSeconds (int64)Optional duration in seconds the pod may be active on the node relative to StartTime before the system will actively try to mark it failed and kill associated containers. Value must be a positive integer.readinessGates ([]PodReadinessGate)Atomic: will be replaced during a mergeIf specified, all readiness gates will be evaluated for pod readiness. A pod is ready when all its containers are ready AND all conditions specified in the readiness gates have status equal to "True" More info: https://git.k8s.io/enhancements/keps/sig-network/580-pod-readiness-gatesPodReadinessGate contains the reference to a pod conditionreadinessGates.conditionType (string), requiredConditionType refers to a condition in the pod's condition list with matching type.Hostname and Name resolutionhostname (string)Specifies the hostname of the Pod If not specified, the pod's hostname will be set to a system-defined value.hostnameOverride (string)HostnameOverride specifies an explicit override for the pod's hostname as perceived by the pod. This field only specifies the pod's hostname and does not affect its DNS records. When this field is set to a non-empty string: - It takes precedence over the values set in hostname and subdomain. - The Pod's hostname will be set to this value. - setHostnameAsFQDN must be nil or set to false. - hostNetwork must be set to false.This field must be a valid DNS subdomain as defined in RFC 1123 and contain at most 64 characters. Requires the HostnameOverride feature gate to be enabled.setHostnameAsFQDN (boolean)If true the pod's hostname will be configured as the pod's FQDN, rather than the leaf name (the default). In Linux containers, this means setting the FQDN in the hostname field of the kernel (the nodename field of struct utsname). In Windows containers, this means setting the registry value of hostname for the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters to FQDN. If a pod does not have FQDN, this has no effect. Default to false.subdomain (string)If specified, the fully qualified Pod hostname will be "<hostname>.<subdomain>.<pod namespace>.svc.<cluster domain>". If not specified, the pod will not have a domainname at all.hostAliases ([]HostAlias)Patch strategy: merge on key ipMap: unique values on key ip will be kept during a mergeHostAliases is an optional list of hosts and IPs that will be injected into the pod's hosts file if specified.HostAlias holds the mapping between IP and hostnames that will be injected as an entry in the pod's hosts file.hostAliases.ip (string), requiredIP address of the host file entry.hostAliases.hostnames ([]string)Atomic: will be replaced during a mergeHostnames for the above IP address.dnsConfig (PodDNSConfig)Specifies the DNS parameters of a pod. Parameters specified here will be merged to the generated DNS configuration based on DNSPolicy.PodDNSConfig defines the DNS parameters of a pod in addition to those generated from DNSPolicy.dnsConfig.nameservers ([]string)Atomic: will be replaced during a mergeA list of DNS name server IP addresses. This will be appended to the base nameservers generated from DNSPolicy. Duplicated nameservers will be removed.dnsConfig.options ([]PodDNSConfigOption)Atomic: will be replaced during a mergeA list of DNS resolver options. This will be merged with the base options generated from DNSPolicy. Duplicated entries will be removed. Resolution options given in Options will override those that appear in the base DNSPolicy.PodDNSConfigOption defines DNS resolver options of a pod.dnsConfig.options.name (string)Name is this DNS resolver option's name. Required.dnsConfig.options.value (string)Value is this DNS resolver option's value.dnsConfig.searches ([]string)Atomic: will be replaced during a mergeA list of DNS search domains for host-name lookup. This will be appended to the base search paths generated from DNSPolicy. Duplicated search paths will be removed.dnsPolicy (string)Set DNS policy for the pod. Defaults to "ClusterFirst". Valid values are 'ClusterFirstWithHostNet', 'ClusterFirst', 'Default' or 'None'. DNS parameters given in DNSConfig will be merged with the policy selected with DNSPolicy. To have DNS options set along with hostNetwork, you have to specify DNS policy explicitly to 'ClusterFirstWithHostNet'.Hosts namespaceshostNetwork (boolean)Host networking requested for this pod. Use the host's network namespace. When using HostNetwork you should specify ports so the scheduler is aware. When hostNetwork is true, specified hostPort fields in port definitions must match containerPort, and unspecified hostPort fields in port definitions are defaulted to match containerPort. Default to false.hostPID (boolean)Use the host's pid namespace. Optional: Default to false.hostIPC (boolean)Use the host's ipc namespace. Optional: Default to false.shareProcessNamespace (boolean)Share a single process namespace between all of the containers in a pod. When this is set containers will be able to view and signal processes from other containers in the same pod, and the first process in each container will not be assigned PID 1. HostPID and ShareProcessNamespace cannot both be set. Optional: Default to false.Service accountserviceAccountName (string)ServiceAccountName is the name of the ServiceAccount to use to run this pod. More info: https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/automountServiceAccountToken (boolean)AutomountServiceAccountToken indicates whether a service account token should be automatically mounted.Security contextsecurityContext (PodSecurityContext)SecurityContext holds pod-level security attributes and common container settings. Optional: Defaults to empty. See type description for default values of each field.PodSecurityContext holds pod-level security attributes and common container settings. Some fields are also present in container.securityContext. Field values of container.securityContext take precedence over field values of PodSecurityContext.securityContext.appArmorProfile (AppArmorProfile)appArmorProfile is the AppArmor options to use by the containers in this pod. Note that this field cannot be set when spec.os.name is windows.AppArmorProfile defines a pod or container's AppArmor settings.securityContext.appArmorProfile.type (string), requiredtype indicates which kind of AppArmor profile will be applied. Valid options are: Localhost - a profile pre-loaded on the node. RuntimeDefault - the container runtime's default profile. Unconfined - no AppArmor enforcement.securityContext.appArmorProfile.localhostProfile (string)localhostProfile indicates a profile loaded on the node that should be used. The profile must be preconfigured on the node to work. Must match the loaded name of the profile. Must be set if and only if type is "Localhost".securityContext.fsGroup (int64)A special supplemental group that applies to all containers in a pod. Some volume types allow the Kubelet to change the ownership of that volume to be owned by the pod:The owning GID will be the FSGroup 2. The setgid bit is set (new files created in the volume will be owned by FSGroup) 3. The permission bits are OR'd with rw-rw----If unset, the Kubelet will not modify the ownership and permissions of any volume. Note that this field cannot be set when spec.os.name is windows.securityContext.fsGroupChangePolicy (string)fsGroupChangePolicy defines behavior of changing ownership and permission of the volume before being exposed inside Pod. This field will only apply to volume types which support fsGroup based ownership(and permissions). It will have no effect on ephemeral volume types such as: secret, configmaps and emptydir. Valid values are "OnRootMismatch" and "Always". If not specified, "Always" is used. Note that this field cannot be set when spec.os.name is windows.securityContext.runAsUser (int64)The UID to run the entrypoint of the container process. Defaults to user specified in image metadata if unspecified. May also be set in SecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence for that container. Note that this field cannot be set when spec.os.name is windows.securityContext.runAsNonRoot (boolean)Indicates that the container must run as a non-root user. If true, the Kubelet will validate the image at runtime to ensure that it does not run as UID 0 (root) and fail to start the container if it does. If unset or false, no such validation will be performed. May also be set in SecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence.securityContext.runAsGroup (int64)The GID to run the entrypoint of the container process. Uses runtime default if unset. May also be set in SecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence for that container. Note that this field cannot be set when spec.os.name is windows.securityContext.seccompProfile (SeccompProfile)The seccomp options to use by the containers in this pod. Note that this field cannot be set when spec.os.name is windows.SeccompProfile defines a pod/container's seccomp profile settings. Only one profile source may be set.securityContext.seccompProfile.type (string), requiredtype indicates which kind of seccomp profile will be applied. Valid options are:Localhost - a profile defined in a file on the node should be used. RuntimeDefault - the container runtime default profile should be used. Unconfined - no profile should be applied.securityContext.seccompProfile.localhostProfile (string)localhostProfile indicates a profile defined in a file on the node should be used. The profile must be preconfigured on the node to work. Must be a descending path, relative to the kubelet's configured seccomp profile location. Must be set if type is "Localhost". Must NOT be set for any other type.securityContext.seLinuxChangePolicy (string)seLinuxChangePolicy defines how the container's SELinux label is applied to all volumes used by the Pod. It has no effect on nodes that do not support SELinux or to volumes does not support SELinux. Valid values are "MountOption" and "Recursive"."Recursive" means relabeling of all files on all Pod volumes by the container runtime. This may be slow for large volumes, but allows mixing privileged and unprivileged Pods sharing the same volume on the same node."MountOption" mounts all eligible Pod volumes with -o context mount option. This requires all Pods that share the same volume to use the same SELinux label. It is not possible to share the same volume among privileged and unprivileged Pods. Eligible volumes are in-tree FibreChannel and iSCSI volumes, and all CSI volumes whose CSI driver announces SELinux support by setting spec.seLinuxMount: true in their CSIDriver instance. Other volumes are always re-labelled recursively. "MountOption" value is allowed only when SELinuxMount feature gate is enabled.If not specified and SELinuxMount feature gate is enabled, "MountOption" is used. If not specified and SELinuxMount feature gate is disabled, "MountOption" is used for ReadWriteOncePod volumes and "Recursive" for all other volumes.This field affects only Pods that have SELinux label set, either in PodSecurityContext or in SecurityContext of all containers.All Pods that use the same volume should use the same seLinuxChangePolicy, otherwise some pods can get stuck in ContainerCreating state. Note that this field cannot be set when spec.os.name is windows.securityContext.seLinuxOptions (SELinuxOptions)The SELinux context to be applied to all containers. If unspecified, the container runtime will allocate a random SELinux context for each container. May also be set in SecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence for that container. Note that this field cannot be set when spec.os.name is windows.SELinuxOptions are the labels to be applied to the containersecurityContext.seLinuxOptions.level (string)Level is SELinux level label that applies to the container.securityContext.seLinuxOptions.role (string)Role is a SELinux role label that applies to the container.securityContext.seLinuxOptions.type (string)Type is a SELinux type label that applies to the container.securityContext.seLinuxOptions.user (string)User is a SELinux user label that applies to the container.securityContext.supplementalGroups ([]int64)Atomic: will be replaced during a mergeA list of groups applied to the first process run in each container, in addition to the container's primary GID and fsGroup (if specified). If the SupplementalGroupsPolicy feature is enabled, the supplementalGroupsPolicy field determines whether these are in addition to or instead of any group memberships defined in the container image. If unspecified, no additional groups are added, though group memberships defined in the container image may still be used, depending on the supplementalGroupsPolicy field. Note that this field cannot be set when spec.os.name is windows.securityContext.supplementalGroupsPolicy (string)Defines how supplemental groups of the first container processes are calculated. Valid values are "Merge" and "Strict". If not specified, "Merge" is used. (Alpha) Using the field requires the SupplementalGroupsPolicy feature gate to be enabled and the container runtime must implement support for this feature. Note that this field cannot be set when spec.os.name is windows.securityContext.sysctls ([]Sysctl)Atomic: will be replaced during a mergeSysctls hold a list of namespaced sysctls used for the pod. Pods with unsupported sysctls (by the container runtime) might fail to launch. Note that this field cannot be set when spec.os.name is windows.Sysctl defines a kernel parameter to be setsecurityContext.sysctls.name (string), requiredName of a property to setsecurityContext.sysctls.value (string), requiredValue of a property to setsecurityContext.windowsOptions (WindowsSecurityContextOptions)The Windows specific settings applied to all containers. If unspecified, the options within a container's SecurityContext will be used. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence. Note that this field cannot be set when spec.os.name is linux.WindowsSecurityContextOptions contain Windows-specific options and credentials.securityContext.windowsOptions.gmsaCredentialSpec (string)GMSACredentialSpec is where the GMSA admission webhook (https://github.com/kubernetes-sigs/windows-gmsa) inlines the contents of the GMSA credential spec named by the GMSACredentialSpecName field.securityContext.windowsOptions.gmsaCredentialSpecName (string)GMSACredentialSpecName is the name of the GMSA credential spec to use.securityContext.windowsOptions.hostProcess (boolean)HostProcess determines if a container should be run as a 'Host Process' container. All of a Pod's containers must have the same effective HostProcess value (it is not allowed to have a mix of HostProcess containers and non-HostProcess containers). In addition, if HostProcess is true then HostNetwork must also be set to true.securityContext.windowsOptions.runAsUserName (string)The UserName in Windows to run the entrypoint of the container process. Defaults to the user specified in image metadata if unspecified. May also be set in PodSecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence.Alpha levelhostUsers (boolean)Use the host's user namespace. Optional: Default to true. If set to true or not present, the pod will be run in the host user namespace, useful for when the pod needs a feature only available to the host user namespace, such as loading a kernel module with CAP_SYS_MODULE. When set to false, a new userns is created for the pod. Setting false is useful for mitigating container breakout vulnerabilities even allowing users to run their containers as root without actually having root privileges on the host. This field is alpha-level and is only honored by servers that enable the UserNamespacesSupport feature.resources (ResourceRequirements)Resources is the total amount of CPU and Memory resources required by all containers in the pod. It supports specifying Requests and Limits for "cpu", "memory" and "hugepages-" resource names only. ResourceClaims are not supported.This field enables fine-grained control over resource allocation for the entire pod, allowing resource sharing among containers in a pod.This is an alpha field and requires enabling the PodLevelResources feature gate.ResourceRequirements describes the compute resource requirements.resources.claims ([]ResourceClaim)Map: unique values on key name will be kept during a mergeClaims lists the names of resources, defined in spec.resourceClaims, that are used by this container.This field depends on the DynamicResourceAllocation feature gate.This field is immutable. It can only be set for containers.ResourceClaim references one entry in PodSpec.ResourceClaims.resources.claims.name (string), requiredName must match the name of one entry in pod.spec.resourceClaims of the Pod where this field is used. It makes that resource available inside a container.resources.claims.request (string)Request is the name chosen for a request in the referenced claim. If empty, everything from the claim is made available, otherwise only the result of this request.resources.limits (map[string]Quantity)Limits describes the maximum amount of compute resources allowed. More info: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/resources.requests (map[string]Quantity)Requests describes the minimum amount of compute resources required. If Requests is omitted for a container, it defaults to Limits if that is explicitly specified, otherwise to an implementation-defined value. Requests cannot exceed Limits. More info: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/resourceClaims ([]PodResourceClaim)Patch strategies: retainKeys, merge on key nameMap: unique values on key name will be kept during a mergeResourceClaims defines which ResourceClaims must be allocated and reserved before the Pod is allowed to start. The resources will be made available to those containers which consume them by name.This is an alpha field and requires enabling the DynamicResourceAllocation feature gate.This field is immutable.*PodResourceClaim references exactly one ResourceClaim, either directly or by naming a ResourceClaimTemplate which is then turned into a ResourceClaim for the pod.It adds a name to it that uniquely identifies the ResourceClaim inside the Pod. Containers that need access to the ResourceClaim reference it with this name.*resourceClaims.name (string), requiredName uniquely identifies this resource claim inside the pod. This must be a DNS_LABEL.resourceClaims.resourceClaimName (string)ResourceClaimName is the name of a ResourceClaim object in the same namespace as this pod.Exactly one of ResourceClaimName and ResourceClaimTemplateName must be set.resourceClaims.resourceClaimTemplateName (string)ResourceClaimTemplateName is the name of a ResourceClaimTemplate object in the same namespace as this pod.The template will be used to create a new ResourceClaim, which will be bound to this pod. When this pod is deleted, the ResourceClaim will also be deleted. The pod name and resource name, along with a generated component, will be used to form a unique name for the ResourceClaim, which will be recorded in pod.status.resourceClaimStatuses.This field is immutable and no changes will be made to the corresponding ResourceClaim by the control plane after creating the ResourceClaim.Exactly one of ResourceClaimName and ResourceClaimTemplateName must be set.schedulingGates ([]PodSchedulingGate)Patch strategy: merge on key nameMap: unique values on key name will be kept during a mergeSchedulingGates is an opaque list of values that if specified will block scheduling the pod. If schedulingGates is not empty, the pod will stay in the SchedulingGated state and the scheduler will not attempt to schedule the pod.SchedulingGates can only be set at pod creation time, and be removed only afterwards.PodSchedulingGate is associated to a Pod to guard its scheduling.schedulingGates.name (string), requiredName of the scheduling gate. Each scheduling gate must have a unique name field.DeprecatedserviceAccount (string)DeprecatedServiceAccount is a deprecated alias for ServiceAccountName. Deprecated: Use serviceAccountName instead.ContainerA single application container that you want to run within a pod.name (string), requiredName of the container specified as a DNS_LABEL. Each container in a pod must have a unique name (DNS_LABEL). Cannot be updated.Imageimage (string)Container image name. More info: https://kubernetes.io/docs/concepts/containers/images This field is optional to allow higher level config management to default or override container images in workload controllers like Deployments and StatefulSets.imagePullPolicy (string)Image pull policy. One of Always, Never, IfNotPresent. Defaults to Always if :latest tag is specified, or IfNotPresent otherwise. Cannot be updated. More info: https://kubernetes.io/docs/concepts/containers/images#updating-imagesEntrypointcommand ([]string)Atomic: will be replaced during a mergeEntrypoint array. Not executed within a shell. The container image's ENTRYPOINT is used if this is not provided. Variable references $(VAR_NAME) are expanded using the container's environment. If a variable cannot be resolved, the reference in the input string will be unchanged. Double $$ are reduced to a single $, which allows for escaping the $(VAR_NAME) syntax: i.e. "$$(VAR_NAME)" will produce the string literal "$(VAR_NAME)". Escaped references will never be expanded, regardless of whether the variable exists or not. Cannot be updated. More info: https://kubernetes.io/docs/tasks/inject-data-application/define-command-argument-container/#running-a-command-in-a-shellargs ([]string)Atomic: will be replaced during a mergeArguments to the entrypoint. The container image's CMD is used if this is not provided. Variable references $(VAR_NAME) are expanded using the container's environment. If a variable cannot be resolved, the reference in the input string will be unchanged. Double $$ are reduced to a single $, which allows for escaping the $(VAR_NAME) syntax: i.e. "$$(VAR_NAME)" will produce the string literal "$(VAR_NAME)". Escaped references will never be expanded, regardless of whether the variable exists or not. Cannot be updated. More info: https://kubernetes.io/docs/tasks/inject-data-application/define-command-argument-container/#running-a-command-in-a-shellworkingDir (string)Container's working directory. If not specified, the container runtime's default will be used, which might be configured in the container image. Cannot be updated.Portsports ([]ContainerPort)Patch strategy: merge on key containerPortMap: unique values on keys containerPort, protocol will be kept during a mergeList of ports to expose from the container. Not specifying a port here DOES NOT prevent that port from being exposed. Any port which is listening on the default "0.0.0.0" address inside a container will be accessible from the network. Modifying this array with strategic merge patch may corrupt the data. For more information See https://github.com/kubernetes/kubernetes/issues/108255. Cannot be updated.ContainerPort represents a network port in a single container.ports.containerPort (int32), requiredNumber of port to expose on the pod's IP address. This must be a valid port number, 0 < x < 65536.ports.hostIP (string)What host IP to bind the external port to.ports.hostPort (int32)Number of port to expose on the host. If specified, this must be a valid port number, 0 < x < 65536. If HostNetwork is specified, this must match ContainerPort. Most containers do not need this.ports.name (string)If specified, this must be an IANA_SVC_NAME and unique within the pod. Each named port in a pod must have a unique name. Name for the port that can be referred to by services.ports.protocol (string)Protocol for port. Must be UDP, TCP, or SCTP. Defaults to "TCP".Environment variablesenv ([]EnvVar)Patch strategy: merge on key nameMap: unique values on key name will be kept during a mergeList of environment variables to set in the container. Cannot be updated.EnvVar represents an environment variable present in a Container.env.name (string), requiredName of the environment variable. May consist of any printable ASCII characters except '='.env.value (string)Variable references $(VAR_NAME) are expanded using the previously defined environment variables in the container and any service environment variables. If a variable cannot be resolved, the reference in the input string will be unchanged. Double $$ are reduced to a single $, which allows for escaping the $(VAR_NAME) syntax: i.e. "$$(VAR_NAME)" will produce the string literal "$(VAR_NAME)". Escaped references will never be expanded, regardless of whether the variable exists or not. Defaults to "".env.valueFrom (EnvVarSource)Source for the environment variable's value. Cannot be used if value is not empty.EnvVarSource represents a source for the value of an EnvVar.env.valueFrom.configMapKeyRef (ConfigMapKeySelector)Selects a key of a ConfigMap.Selects a key from a ConfigMap.env.valueFrom.configMapKeyRef.key (string), requiredThe key to select.env.valueFrom.configMapKeyRef.name (string)Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#namesenv.valueFrom.configMapKeyRef.optional (boolean)Specify whether the ConfigMap or its key must be definedenv.valueFrom.fieldRef (ObjectFieldSelector)Selects a field of the pod: supports metadata.name, metadata.namespace, metadata.labels['\<KEY>'], metadata.annotations['\<KEY>'], spec.nodeName, spec.serviceAccountName, status.hostIP, status.podIP, status.podIPs.env.valueFrom.fileKeyRef (FileKeySelector)FileKeyRef selects a key of the env file. Requires the EnvFiles feature gate to be enabled.FileKeySelector selects a key of the env file.env.valueFrom.fileKeyRef.key (string), requiredThe key within the env file. An invalid key will prevent the pod from starting. The keys defined within a source may consist of any printable ASCII characters except '='. During Alpha stage of the EnvFiles feature gate, the key size is limited to 128 characters.env.valueFrom.fileKeyRef.path (string), requiredThe path within the volume from which to select the file. Must be relative and may not contain the '..' path or start with '..'.env.valueFrom.fileKeyRef.volumeName (string), requiredThe name of the volume mount containing the env file.env.valueFrom.fileKeyRef.optional (boolean)Specify whether the file or its key must be defined. If the file or key does not exist, then the env var is not published. If optional is set to true and the specified key does not exist, the environment variable will not be set in the Pod's containers.If optional is set to false and the specified key does not exist, an error will be returned during Pod creation.env.valueFrom.resourceFieldRef (ResourceFieldSelector)Selects a resource of the container: only resources limits and requests (limits.cpu, limits.memory, limits.ephemeral-storage, requests.cpu, requests.memory and requests.ephemeral-storage) are currently supported.env.valueFrom.secretKeyRef (SecretKeySelector)Selects a key of a secret in the pod's namespaceSecretKeySelector selects a key of a Secret.env.valueFrom.secretKeyRef.key (string), requiredThe key of the secret to select from. Must be a valid secret key.env.valueFrom.secretKeyRef.name (string)Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#namesenv.valueFrom.secretKeyRef.optional (boolean)Specify whether the Secret or its key must be definedenvFrom ([]EnvFromSource)Atomic: will be replaced during a mergeList of sources to populate environment variables in the container. The keys defined within a source may consist of any printable ASCII characters except '='. When a key exists in multiple sources, the value associated with the last source will take precedence. Values defined by an Env with a duplicate key will take precedence. Cannot be updated.EnvFromSource represents the source of a set of ConfigMaps or SecretsenvFrom.configMapRef (ConfigMapEnvSource)The ConfigMap to select from*ConfigMapEnvSource selects a ConfigMap to populate the environment variables with.The contents of the target ConfigMap's Data field will represent the key-value pairs as environment variables.*envFrom.configMapRef.name (string)Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#namesenvFrom.configMapRef.optional (boolean)Specify whether the ConfigMap must be definedenvFrom.prefix (string)Optional text to prepend to the name of each environment variable. May consist of any printable ASCII characters except '='.envFrom.secretRef (SecretEnvSource)The Secret to select from*SecretEnvSource selects a Secret to populate the environment variables with.The contents of the target Secret's Data field will represent the key-value pairs as environment variables.*envFrom.secretRef.name (string)Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#namesenvFrom.secretRef.optional (boolean)Specify whether the Secret must be definedVolumesvolumeMounts ([]VolumeMount)Patch strategy: merge on key mountPathMap: unique values on key mountPath will be kept during a mergePod volumes to mount into the container's filesystem. Cannot be updated.VolumeMount describes a mounting of a Volume within a container.volumeMounts.mountPath (string), requiredPath within the container at which the volume should be mounted. Must not contain ':'.volumeMounts.name (string), requiredThis must match the Name of a Volume.volumeMounts.mountPropagation (string)mountPropagation determines how mounts are propagated from the host to container and the other way around. When not set, MountPropagationNone is used. This field is beta in 1.10. When RecursiveReadOnly is set to IfPossible or to Enabled, MountPropagation must be None or unspecified (which defaults to None).volumeMounts.readOnly (boolean)Mounted read-only if true, read-write otherwise (false or unspecified). Defaults to false.volumeMounts.recursiveReadOnly (string)RecursiveReadOnly specifies whether read-only mounts should be handled recursively.If ReadOnly is false, this field has no meaning and must be unspecified.If ReadOnly is true, and this field is set to Disabled, the mount is not made recursively read-only. If this field is set to IfPossible, the mount is made recursively read-only, if it is supported by the container runtime. If this field is set to Enabled, the mount is made recursively read-only if it is supported by the container runtime, otherwise the pod will not be started and an error will be generated to indicate the reason.If this field is set to IfPossible or Enabled, MountPropagation must be set to None (or be unspecified, which defaults to None).If this field is not specified, it is treated as an equivalent of Disabled.volumeMounts.subPath (string)Path within the volume from which the container's volume should be mounted. Defaults to "" (volume's root).volumeMounts.subPathExpr (string)Expanded path within the volume from which the container's volume should be mounted. Behaves similarly to SubPath but environment variable references $(VAR_NAME) are expanded using the container's environment. Defaults to "" (volume's root). SubPathExpr and SubPath are mutually exclusive.volumeDevices ([]VolumeDevice)Patch strategy: merge on key devicePathMap: unique values on key devicePath will be kept during a mergevolumeDevices is the list of block devices to be used by the container.volumeDevice describes a mapping of a raw block device within a container.volumeDevices.devicePath (string), requireddevicePath is the path inside of the container that the device will be mapped to.volumeDevices.name (string), requiredname must match the name of a persistentVolumeClaim in the podResourcesresources (ResourceRequirements)Compute Resources required by this container. Cannot be updated. More info: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ResourceRequirements describes the compute resource requirements.resources.claims ([]ResourceClaim)Map: unique values on key name will be kept during a mergeClaims lists the names of resources, defined in spec.resourceClaims, that are used by this container.This field depends on the DynamicResourceAllocation feature gate.This field is immutable. It can only be set for containers.ResourceClaim references one entry in PodSpec.ResourceClaims.resources.claims.name (string), requiredName must match the name of one entry in pod.spec.resourceClaims of the Pod where this field is used. It makes that resource available inside a container.resources.claims.request (string)Request is the name chosen for a request in the referenced claim. If empty, everything from the claim is made available, otherwise only the result of this request.resources.limits (map[string]Quantity)Limits describes the maximum amount of compute resources allowed. More info: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/resources.requests (map[string]Quantity)Requests describes the minimum amount of compute resources required. If Requests is omitted for a container, it defaults to Limits if that is explicitly specified, otherwise to an implementation-defined value. Requests cannot exceed Limits. More info: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/resizePolicy ([]ContainerResizePolicy)Atomic: will be replaced during a mergeResources resize policy for the container.ContainerResizePolicy represents resource resize policy for the container.resizePolicy.resourceName (string), requiredName of the resource to which this resource resize policy applies. Supported values: cpu, memory.resizePolicy.restartPolicy (string), requiredRestart policy to apply when specified resource is resized. If not specified, it defaults to NotRequired.Lifecyclelifecycle (Lifecycle)Actions that the management system should take in response to container lifecycle events. Cannot be updated.Lifecycle describes actions that the management system should take in response to container lifecycle events. For the PostStart and PreStop lifecycle handlers, management of the container blocks until the action is complete, unless the container process fails, in which case the handler is aborted.lifecycle.postStart (LifecycleHandler)PostStart is called immediately after a container is created. If the handler fails, the container is terminated and restarted according to its restart policy. Other management of the container blocks until the hook completes. More info: https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hookslifecycle.preStop (LifecycleHandler)PreStop is called immediately before a container is terminated due to an API request or management event such as liveness/startup probe failure, preemption, resource contention, etc. The handler is not called if the container crashes or exits. The Pod's termination grace period countdown begins before the PreStop hook is executed. Regardless of the outcome of the handler, the container will eventually terminate within the Pod's termination grace period (unless delayed by finalizers). Other management of the container blocks until the hook completes or until the termination grace period is reached. More info: https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hookslifecycle.stopSignal (string)StopSignal defines which signal will be sent to a container when it is being stopped. If not specified, the default is defined by the container runtime in use. StopSignal can only be set for Pods with a non-empty .spec.os.nameterminationMessagePath (string)Optional: Path at which the file to which the container's termination message will be written is mounted into the container's filesystem. Message written is intended to be brief final status, such as an assertion failure message. Will be truncated by the node if greater than 4096 bytes. The total message length across all containers will be limited to 12kb. Defaults to /dev/termination-log. Cannot be updated.terminationMessagePolicy (string)Indicate how the termination message should be populated. File will use the contents of terminationMessagePath to populate the container status message on both success and failure. FallbackToLogsOnError will use the last chunk of container log output if the termination message file is empty and the container exited with an error. The log output is limited to 2048 bytes or 80 lines, whichever is smaller. Defaults to File. Cannot be updated.livenessProbe (Probe)Periodic probe of container liveness. Container will be restarted if the probe fails. Cannot be updated. More info: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probesreadinessProbe (Probe)Periodic probe of container service readiness. Container will be removed from service endpoints if the probe fails. Cannot be updated. More info: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probesstartupProbe (Probe)StartupProbe indicates that the Pod has successfully initialized. If specified, no other probes are executed until this completes successfully. If this probe fails, the Pod will be restarted, just as if the livenessProbe failed. This can be used to provide different probe parameters at the beginning of a Pod's lifecycle, when it might take a long time to load data or warm a cache, than during steady-state operation. This cannot be updated. More info: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probesrestartPolicy (string)RestartPolicy defines the restart behavior of individual containers in a pod. This overrides the pod-level restart policy. When this field is not specified, the restart behavior is defined by the Pod's restart policy and the container type. Additionally, setting the RestartPolicy as "Always" for the init container will have the following effect: this init container will be continually restarted on exit until all regular containers have terminated. Once all regular containers have completed, all init containers with restartPolicy "Always" will be shut down. This lifecycle differs from normal init containers and is often referred to as a "sidecar" container. Although this init container still starts in the init container sequence, it does not wait for the container to complete before proceeding to the

Kubernetes API


Container RuntimesNote: Dockershim has been removed from the Kubernetes project as of release 1.24. Read the Dockershim Removal FAQ for further details.You need to install a container runtime into each node in the cluster so that Pods can run there. This page outlines what is involved and describes related tasks for setting up nodes.Kubernetes 1.34 requires that you use a runtime that conforms with the Container Runtime Interface (CRI).See CRI version support for more information.This page provides an outline of how to use several common container runtimes with Kubernetes.containerdCRI-ODocker EngineMirantis Container RuntimeNote:Kubernetes releases before v1.24 included a direct integration with Docker Engine, using a component named dockershim. That special direct integration is no longer part of Kubernetes (this removal was announced as part of the v1.20 release). You can read Check whether Dockershim removal affects you to understand how this removal might affect you. To learn about migrating from using dockershim, see Migrating from dockershim.If you are running a version of Kubernetes other than v1.34, check the documentation for that version.Install and configure prerequisitesNetwork configurationBy default, the Linux kernel does not allow IPv4 packets to be routed between interfaces. Most Kubernetes cluster networking implementations will change this setting (if needed), but some might expect the administrator to do it for them. (Some might also expect other sysctl parameters to be set, kernel modules to be loaded, etc; consult the documentation for your specific network implementation.)Enable IPv4 packet forwardingTo manually enable IPv4 packet forwarding:# sysctl params required by setup, params persist across reboots cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf net.ipv4.ip_forward = 1 EOF # Apply sysctl params without reboot sudo sysctl --system Verify that net.ipv4.ip_forward is set to 1 with:sysctl net.ipv4.ip_forward cgroup driversOn Linux, control groups are used to constrain resources that are allocated to processes.Both the kubelet and the underlying container runtime need to interface with control groups to enforce resource management for pods and containers and set resources such as cpu/memory requests and limits. To interface with control groups, the kubelet and the container runtime need to use a cgroup driver. It's critical that the kubelet and the container runtime use the same cgroup driver and are configured the same.There are two cgroup drivers available:cgroupfssystemdcgroupfs driverThe cgroupfs driver is the default cgroup driver in the kubelet. When the cgroupfs driver is used, the kubelet and the container runtime directly interface with the cgroup filesystem to configure cgroups.The cgroupfs driver is not recommended when systemd is the init system because systemd expects a single cgroup manager on the system. Additionally, if you use cgroup v2, use the systemd cgroup driver instead of cgroupfs.systemd cgroup driverWhen systemd is chosen as the init system for a Linux distribution, the init process generates and consumes a root control group (cgroup) and acts as a cgroup manager.systemd has a tight integration with cgroups and allocates a cgroup per systemd unit. As a result, if you use systemd as the init system with the cgroupfs driver, the system gets two different cgroup managers.Two cgroup managers result in two views of the available and in-use resources in the system. In some cases, nodes that are configured to use cgroupfs for the kubelet and container runtime, but use systemd for the rest of the processes become unstable under resource pressure.The approach to mitigate this instability is to use systemd as the cgroup driver for the kubelet and the container runtime when systemd is the selected init system.To set systemd as the cgroup driver, edit the KubeletConfiguration option of cgroupDriver and set it to systemd. For example:apiVersion: kubelet.config.k8s.io/v1beta1 kind: KubeletConfiguration ... cgroupDriver: systemd Note:Starting with v1.22 and later, when creating a cluster with kubeadm, if the user does not set the cgroupDriver field under KubeletConfiguration, kubeadm defaults it to systemd.If you configure systemd as the cgroup driver for the kubelet, you must also configure systemd as the cgroup driver for the container runtime. Refer to the documentation for your container runtime for instructions. For example:containerdCRI-OIn Kubernetes 1.34, with the KubeletCgroupDriverFromCRI feature gate enabled and a container runtime that supports the RuntimeConfig CRI RPC, the kubelet automatically detects the appropriate cgroup driver from the runtime, and ignores the cgroupDriver setting within the kubelet configuration.However, older versions of container runtimes (specifically, containerd 1.y and below) do not support the RuntimeConfig CRI RPC, and may not respond correctly to this query, and thus the Kubelet falls back to using the value in its own --cgroup-driver flag.In Kubernetes 1.36, this fallback behavior will be dropped, and older versions of containerd will fail with newer kubelets.Caution:Changing the cgroup driver of a Node that has joined a cluster is a sensitive operation. If the kubelet has created Pods using the semantics of one cgroup driver, changing the container runtime to another cgroup driver can cause errors when trying to re-create the Pod sandbox for such existing Pods. Restarting the kubelet may not solve such errors.If you have automation that makes it feasible, replace the node with another using the updated configuration, or reinstall it using automation.Migrating to the systemd driver in kubeadm managed clustersIf you wish to migrate to the systemd cgroup driver in existing kubeadm managed clusters, follow configuring a cgroup driver.CRI version supportYour container runtime must support at least v1alpha2 of the container runtime interface.Kubernetes starting v1.26 only works with v1 of the CRI API. Earlier versions default to v1 version, however if a container runtime does not support the v1 API, the kubelet falls back to using the (deprecated) v1alpha2 API instead.Container runtimesNote: This section links to third party projects that provide functionality required by Kubernetes. The Kubernetes project authors aren't responsible for these projects, which are listed alphabetically. To add a project to this list, read the content guide before submitting a change. More information.containerdThis section outlines the necessary steps to use containerd as CRI runtime.To install containerd on your system, follow the instructions on getting started with containerd. Return to this step once you've created a valid config.toml configuration file.You can find this file under the path /etc/containerd/config.toml.You can find this file under the path C:\Program Files\containerd\config.toml.On Linux the default CRI socket for containerd is /run/containerd/containerd.sock. On Windows the default CRI endpoint is npipe://./pipe/containerd-containerd.Configuring the systemd cgroup driverTo use the systemd cgroup driver in /etc/containerd/config.toml with runc, set the following config based on your Containerd versionContainerd versions 1.x:[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc] ... [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options] SystemdCgroup = true Containerd versions 2.x:[plugins.'io.containerd.cri.v1.runtime'.containerd.runtimes.runc] ... [plugins.'io.containerd.cri.v1.runtime'.containerd.runtimes.runc.options] SystemdCgroup = true The systemd cgroup driver is recommended if you use cgroup v2.Note:If you installed containerd from a package (for example, RPM or .deb), you may find that the CRI integration plugin is disabled by default.You need CRI support enabled to use containerd with Kubernetes. Make sure that cri is not included in thedisabled_plugins list within /etc/containerd/config.toml; if you made changes to that file, also restart containerd.If you experience container crash loops after the initial cluster installation or after installing a CNI, the containerd configuration provided with the package might contain incompatible configuration parameters. Consider resetting the containerd configuration with containerd config default > /etc/containerd/config.toml as specified in getting-started.md and then set the configuration parameters specified above accordingly.If you apply this change, make sure to restart containerd:sudo systemctl restart containerd When using kubeadm, manually configure the cgroup driver for kubelet.In Kubernetes v1.28, you can enable automatic detection of the cgroup driver as an alpha feature. See systemd cgroup driver for more details.Overriding the sandbox (pause) imageIn your containerd config you can overwrite the sandbox image by setting the following config:[plugins."io.containerd.grpc.v1.cri"] sandbox_image = "registry.k8s.io/pause:3.10" You might need to restart containerd as well once you've updated the config file: systemctl restart containerd.CRI-OThis section contains the necessary steps to install CRI-O as a container runtime.To install CRI-O, follow CRI-O Install Instructions.cgroup driverCRI-O uses the systemd cgroup driver per default, which is likely to work fine for you. To switch to the cgroupfs cgroup driver, either edit /etc/crio/crio.conf or place a drop-in configuration in /etc/crio/crio.conf.d/02-cgroup-manager.conf, for example:[crio.runtime] conmon_cgroup = "pod" cgroup_manager = "cgroupfs" You should also note the changed conmon_cgroup, which has to be set to the value pod when using CRI-O with cgroupfs. It is generally necessary to keep the cgroup driver configuration of the kubelet (usually done via kubeadm) and CRI-O in sync.In Kubernetes v1.28, you can enable automatic detection of the cgroup driver as an alpha feature. See systemd cgroup driver for more details.For CRI-O, the CRI socket is /var/run/crio/crio.sock by default.Overriding the sandbox (pause) imageIn your CRI-O config you can set the following config value:[crio.image] pause_image="registry.k8s.io/pause:3.10" This config option supports live configuration reload to apply this change: systemctl reload crio or by sending SIGHUP to the crio process.Docker EngineNote:These instructions assume that you are using the cri-dockerd adapter to integrate Docker Engine with Kubernetes.On each of your nodes, install Docker for your Linux distribution as per Install Docker Engine.Install cri-dockerd, following the directions in the install section of the documentation.For cri-dockerd, the CRI socket is /run/cri-dockerd.sock by default.Mirantis Container RuntimeMirantis Container Runtime (MCR) is a commercially available container runtime that was formerly known as Docker Enterprise Edition.You can use Mirantis Container Runtime with Kubernetes using the open source cri-dockerd component, included with MCR.To learn more about how to install Mirantis Container Runtime, visit MCR Deployment Guide.Check the systemd unit named cri-docker.socket to find out the path to the CRI socket.Overriding the sandbox (pause) imageThe cri-dockerd adapter accepts a command line argument for specifying which container image to use as the Pod infrastructure container (“pause image”). The command line argument to use is --pod-infra-container-image.What's nextAs well as a container runtime, your cluster will need a working network plugin.Items on this page refer to third party products or projects that provide functionality required by Kubernetes. The Kubernetes project authors aren't responsible for those third-party products or projects. See the CNCF website guidelines for more details.You should read the content guide before proposing a change that adds an extra third-party link.

Container Runtimes