This section of the Kubernetes documentation contains references. API Reference Glossary - a comprehensive, standardized list of Kubernetes terminology Kubernetes API Reference One-page API Reference for Kubernetes v1.31 Using The Kubernetes API - overview of the API for Kubernetes. API access control - details on how Kubernetes controls API access Well-Known Labels, Annotations and Taints Officially supported client libraries To call the Kubernetes API from a programming language, you can use client libraries.

Kubernetes certificate and trust bundle APIs enable automation of X.509 credential provisioning by providing a programmatic interface for clients of the Kubernetes API to request and obtain X.509 certificates from a Certificate Authority (CA). There is also experimental (alpha) support for distributing trust bundles. Certificate signing requests FEATURE STATE: Kubernetes v1.19 [stable] A CertificateSigningRequest (CSR) resource is used to request that a certificate be signed by a denoted signer, after which the request may be approved or denied before finally being signed.

This page serves as a reference for the audit annotations of the kubernetes.io namespace. These annotations apply to Event object from API group audit.k8s.io. Note:The following annotations are not used within the Kubernetes API. When you enable auditing in your cluster, audit event data is written using Event from API group audit.k8s.io. The annotations apply to audit events. Audit events are different from objects in the Event API (API group events.

The Kubernetes API server provides API endpoints to indicate the current status of the API server. This page describes these API endpoints and explains how you can use them. API endpoints for health The Kubernetes API server provides 3 API endpoints (healthz, livez and readyz) to indicate the current status of the API server. The healthz endpoint is deprecated (since Kubernetes v1.16), and you should use the more specific livez and readyz endpoints instead.

Instrumentation Kubernetes Component SLI Metrics CRI Pod & Container Metrics Collection of Pod & Container metrics vi...

This section provides reference information for the Kubernetes API. The REST API is the fundamental fabric of Kubernetes. All operations and communications between components, and external user commands are REST API calls that the API Server handles. Consequently, everything in the Kubernetes platform is treated as an API object and has a corresponding entry in the API. The Kubernetes API reference lists the API for Kubernetes version v1.31. For general background information, read The Kubernetes API.

kubeadm reset phase enables you to invoke atomic steps of the node reset process. Hence, you can let kubeadm do some of the work and you can fill in the gaps if you wish to apply customization. kubeadm reset phase is consistent with the kubeadm reset workflow, and behind the scene both use the same code. kubeadm reset phase phase Use this command to invoke single phase of the reset workflow

Synopsis Approve a certificate signing request. kubectl certificate approve allows a cluster admin to approve a certificate signing request (CSR). This action tells a certificate signing controller to issue a certificate to the requester with the attributes requested in the CSR. SECURITY NOTICE: Depending on the requested attributes, the issued certificate can potentially grant a requester access to cluster resources or to authenticate as a requested identity. Before approving a CSR, ensure you understand what the signed certificate can do.

Synopsis Inspect authorization. kubectl auth [flags] Options -h, --help help for auth --as string Username to impersonate for the operation. User could be a regular user or a service account in a namespace. --as-group strings Group to impersonate for the operation, this flag can be repeated to specify multiple groups. --as-uid string UID to impersonate for the operation. --cache-dir string     Default: "$HOME/.kube/cache" Default cache directory --certificate-authority string Path to a cert file for the certificate authority

This command initializes a new Kubernetes node and joins it to the existing cluster. Run this on any machine you wish to join an existing cluster Synopsis When joining a kubeadm initialized cluster, we need to establish bidirectional trust. This is split into discovery (having the Node trust the Kubernetes Control Plane) and TLS bootstrap (having the Kubernetes Control Plane trust the Node). There are 2 main schemes for discovery.