Synopsis Set values in the kuberc configuration file. Use --section to specify whether to set defaults or aliases. For defaults: Sets default flag values for kubectl commands. The --command flag should specify only the command (e.g., "get", "create", "set env"), not resources. For aliases: Creates command aliases with optional default flag values and arguments. Use --prependarg and --appendarg to include resources or other arguments. kubectl alpha kuberc set --section (defaults|aliases) --command COMMAND Examples # Set default output format for 'get' command kubectl alpha kuberc set --section defaults --command get --option output=wide # Set default output format for a subcommand kubectl alpha kuberc set --section defaults --command "set env" --option output=yaml # Create an alias 'getn' for 'get' command with prepended 'nodes' resource kubectl alpha kuberc set --section aliases --name getn --command get --prependarg nodes --option output=wide # Create an alias 'runx' for 'run' command with appended arguments kubectl alpha kuberc set --section aliases --name runx --command run --option image=nginx --appendarg "--" --appendarg custom-arg1 # Overwrite an existing default kubectl alpha kuberc set --section defaults --command get --option output=json --overwrite Options --appendarg strings Argument to append to the command (can be specified multiple times, for aliases only)

Production-Grade Container Orchestration

Kubernetes runs your workload by placing containers into Pods to run on Nodes. A node may be a virtual or physical machine, depending on the cluster. Each node is managed by the control plane and contains the services necessary to run Pods. Typically you have several nodes in a cluster; in a learning or resource-limited environment, you might have only one node. The components on a node include the kubelet, a container runtime, and the kube-proxy.

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.

FEATURE STATE: Kubernetes v1.23 [stable] Your Kubernetes cluster includes dual-stack networking, which means that cluster networking lets you use either address family. In a cluster, the control plane can assign both an IPv4 address and an IPv6 address to a single Pod or a Service. Before you begin You need to have installed the kubeadm tool, following the steps from Installing kubeadm. For each server that you want to use as a node, make sure it allows IPv6 forwarding.

A cluster is a set of nodes (physical or virtual machines) running Kubernetes agents, managed by the control plane. Kubernetes v1.35 supports clusters with up to 5,000 nodes. More specifically, Kubernetes is designed to accommodate configurations that meet all of the following criteria: No more than 110 pods per node No more than 5,000 nodes No more than 150,000 total pods No more than 300,000 total containers You can scale your cluster by adding or removing nodes.

Security architecture information relating to the API server and other components

When several users or teams share a cluster with a fixed number of nodes, there is a concern that one team could use more than its fair share of resources. Resource quotas are a tool for administrators to address this concern. A resource quota, defined by a ResourceQuota object, provides constraints that limit aggregate resource consumption per namespace. A ResourceQuota can also limit the quantity of objects that can be created in a namespace by API kind, as well as the total amount of infrastructure resources that may be consumed by API objects found in that namespace.

A Secret is an object that contains a small amount of sensitive data such as a password, a token, or a key. Such information might otherwise be put in a Pod specification or in a container image. Using a Secret means that you don't need to include confidential data in your application code. Because Secrets can be created independently of the Pods that use them, there is less risk of the Secret (and its data) being exposed during the workflow of creating, viewing, and editing Pods.

Removed feature PodSecurityPolicy was deprecated in Kubernetes v1.21, and removed from Kubernetes in v1.25. Instead of using PodSecurityPolicy, you can enforce similar restrictions on Pods using either or both: Pod Security Admission a 3rd party admission plugin, that you deploy and configure yourself For a migration guide, see Migrate from PodSecurityPolicy to the Built-In PodSecurity Admission Controller. For more information on the removal of this API, see PodSecurityPolicy Deprecation: Past, Present, and Future.