Easy to use kubernetes documentation

Available resources for kubernetes version 1.28

Your browsers url supports all resources in the kubernetes openAPI spec, even if a resource is not listed here.

APIGroup 🔗

APIGroup contains the name, the supported versions, and the preferred version of a group.

APIService 🔗

APIService represents a server for a particular GroupVersion. Name must be "".

APIVersions 🔗

APIVersions lists the versions that are available, to allow clients to discover the API at /api, which is the root path of the legacy v1 API.

Binding 🔗

Binding ties one object to another; for example, a pod is bound to a node by a scheduler. Deprecated in 1.7, please use the bindings subresource of pods instead.

CSIDriver 🔗

CSIDriver captures information about a Container Storage Interface (CSI) volume driver deployed on the cluster. Kubernetes attach detach controller uses this object to determine whether attach is required. Kubelet uses this object to determine whether pod information needs to be passed on mount. CSIDriver objects are non-namespaced.

CSINode 🔗

CSINode holds information about all CSI drivers installed on a node. CSI drivers do not need to create the CSINode object directly. As long as they use the node-driver-registrar sidecar container, the kubelet will automatically populate the CSINode object for the CSI driver as part of kubelet plugin registration. CSINode has the same name as a node. If the object is missing, it means either there are no CSI Drivers available on the node, or the Kubelet version is low enough that it doesn't create this object. CSINode has an OwnerReference that points to the corresponding node object.

CSIStorageCapacity 🔗

CSIStorageCapacity stores the result of one CSI GetCapacity call. For a given StorageClass, this describes the available capacity in a particular topology segment. This can be used when considering where to instantiate new PersistentVolumes. For example this can express things like: - StorageClass "standard" has "1234 GiB" available in "" - StorageClass "localssd" has "10 GiB" available in "" The following three cases all imply that no capacity is available for a certain combination: - no object exists with suitable topology and storage class name - such an object exists, but the capacity is unset - such an object exists, but the capacity is zero The producer of these objects can decide which approach is more suitable. They are consumed by the kube-scheduler when a CSI driver opts into capacity-aware scheduling with CSIDriverSpec.StorageCapacity. The scheduler compares the MaximumVolumeSize against the requested size of pending volumes to filter out unsuitable nodes. If MaximumVolumeSize is unset, it falls back to a comparison against the less precise Capacity. If that is also unset, the scheduler assumes that capacity is insufficient and tries some other node.

CertificateSigningRequest 🔗

CertificateSigningRequest objects provide a mechanism to obtain x509 certificates by submitting a certificate signing request, and having it asynchronously approved and issued. Kubelets use this API to obtain: 1. client certificates to authenticate to kube-apiserver (with the "" signerName). 2. serving certificates for TLS endpoints kube-apiserver can connect to securely (with the "" signerName). This API can be used to request client certificates to authenticate to kube-apiserver (with the "" signerName), or to obtain certificates from custom non-Kubernetes signers.

ClusterCIDR 🔗

ClusterCIDR represents a single configuration for per-Node Pod CIDR allocations when the MultiCIDRRangeAllocator is enabled (see the config for kube-controller-manager). A cluster may have any number of ClusterCIDR resources, all of which will be considered when allocating a CIDR for a Node. A ClusterCIDR is eligible to be used for a given Node when the node selector matches the node in question and has free CIDRs to allocate. In case of multiple matching ClusterCIDR resources, the allocator will attempt to break ties using internal heuristics, but any ClusterCIDR whose node selector matches the Node may be used.

ClusterRole 🔗

ClusterRole is a cluster level, logical grouping of PolicyRules that can be referenced as a unit by a RoleBinding or ClusterRoleBinding.

ClusterRoleBinding 🔗

ClusterRoleBinding references a ClusterRole, but not contain it. It can reference a ClusterRole in the global namespace, and adds who information via Subject.

ClusterTrustBundle 🔗

ClusterTrustBundle is a cluster-scoped container for X.509 trust anchors (root certificates). ClusterTrustBundle objects are considered to be readable by any authenticated user in the cluster, because they can be mounted by pods using the `clusterTrustBundle` projection. All service accounts have read access to ClusterTrustBundles by default. Users who only have namespace-level access to a cluster can read ClusterTrustBundles by impersonating a serviceaccount that they have access to. It can be optionally associated with a particular assigner, in which case it contains one valid set of trust anchors for that signer. Signers may have multiple associated ClusterTrustBundles; each is an independent set of trust anchors for that signer. Admission control is used to enforce that only users with permissions on the signer can create or modify the corresponding bundle.

ComponentStatus 🔗

ComponentStatus (and ComponentStatusList) holds the cluster validation info. Deprecated: This API is deprecated in v1.19+

ConfigMap 🔗

ConfigMap holds configuration data for pods to consume.

ControllerRevision 🔗

ControllerRevision implements an immutable snapshot of state data. Clients are responsible for serializing and deserializing the objects that contain their internal state. Once a ControllerRevision has been successfully created, it can not be updated. The API Server will fail validation of all requests that attempt to mutate the Data field. ControllerRevisions may, however, be deleted. Note that, due to its use by both the DaemonSet and StatefulSet controllers for update and rollback, this object is beta. However, it may be subject to name and representation changes in future releases, and clients should not depend on its stability. It is primarily for internal use by controllers.

CronJob 🔗

CronJob represents the configuration of a single cron job.

CustomResourceDefinition 🔗

CustomResourceDefinition represents a resource that should be exposed on the API server. Its name MUST be in the format <>.<>.

DaemonSet 🔗

DaemonSet represents the configuration of a daemon set.

DeleteOptions 🔗

DeleteOptions may be provided when deleting an API object.

Deployment 🔗

Deployment enables declarative updates for Pods and ReplicaSets.

EndpointSlice 🔗

EndpointSlice represents a subset of the endpoints that implement a service. For a given service there may be multiple EndpointSlice objects, selected by labels, which must be joined to produce the full set of endpoints.

Endpoints 🔗

Endpoints is a collection of endpoints that implement the actual service. Example: Name: "mysvc", Subsets: [ { Addresses: [{"ip": ""}, {"ip": ""}], Ports: [{"name": "a", "port": 8675}, {"name": "b", "port": 309}] }, { Addresses: [{"ip": ""}], Ports: [{"name": "a", "port": 93}, {"name": "b", "port": 76}] }, ]

Event 🔗

Event is a report of an event somewhere in the cluster. Events have a limited retention time and triggers and messages may evolve with time. Event consumers should not rely on the timing of an event with a given Reason reflecting a consistent underlying trigger, or the continued existence of events with that Reason. Events should be treated as informative, best-effort, supplemental data.

Eviction 🔗

Eviction evicts a pod from its node subject to certain policies and safety constraints. This is a subresource of Pod. A request to cause such an eviction is created by POSTing to .../pods/<pod name>/evictions.

FlowSchema 🔗

FlowSchema defines the schema of a group of flows. Note that a flow is made up of a set of inbound API requests with similar attributes and is identified by a pair of strings: the name of the FlowSchema and a "flow distinguisher".

HorizontalPodAutoscaler 🔗

configuration of a horizontal pod autoscaler.

IPAddress 🔗

IPAddress represents a single IP of a single IP Family. The object is designed to be used by APIs that operate on IP addresses. The object is used by the Service core API for allocation of IP addresses. An IP address can be represented in different formats, to guarantee the uniqueness of the IP, the name of the object is the IP address in canonical format, four decimal digits separated by dots suppressing leading zeros for IPv4 and the representation defined by RFC 5952 for IPv6. Valid: or 2001:db8::1 or 2001:db8:aaaa:bbbb:cccc:dddd:eeee:1 Invalid: or 2001:db8:0:0:0::1

Ingress 🔗

Ingress is a collection of rules that allow inbound connections to reach the endpoints defined by a backend. An Ingress can be configured to give services externally-reachable urls, load balance traffic, terminate SSL, offer name based virtual hosting etc.

IngressClass 🔗

IngressClass represents the class of the Ingress, referenced by the Ingress Spec. The `` annotation can be used to indicate that an IngressClass should be considered default. When a single IngressClass resource has this annotation set to true, new Ingress resources without a class specified will be assigned this default class.

Job 🔗

Job represents the configuration of a single job.

Lease 🔗

Lease defines a lease concept.

LimitRange 🔗

LimitRange sets resource usage limits for each kind of resource in a Namespace.

LocalSubjectAccessReview 🔗

LocalSubjectAccessReview checks whether or not a user or group can perform an action in a given namespace. Having a namespace scoped resource makes it much easier to grant namespace scoped policy that includes permissions checking.

MutatingWebhookConfiguration 🔗

MutatingWebhookConfiguration describes the configuration of and admission webhook that accept or reject and may change the object.

Namespace 🔗

Namespace provides a scope for Names. Use of multiple namespaces is optional.

NetworkPolicy 🔗

NetworkPolicy describes what network traffic is allowed for a set of Pods

Node 🔗

Node is a worker node in Kubernetes. Each node will have a unique identifier in the cache (i.e. in etcd).

PersistentVolume 🔗

PersistentVolume (PV) is a storage resource provisioned by an administrator. It is analogous to a node. More info:

PersistentVolumeClaim 🔗

PersistentVolumeClaim is a user's request for and claim to a persistent volume

Pod 🔗

Pod is a collection of containers that can run on a host. This resource is created by clients and scheduled onto hosts.

PodDisruptionBudget 🔗

PodDisruptionBudget is an object to define the max disruption that can be caused to a collection of pods

PodSchedulingContext 🔗

PodSchedulingContext objects hold information that is needed to schedule a Pod with ResourceClaims that use "WaitForFirstConsumer" allocation mode. This is an alpha type and requires enabling the DynamicResourceAllocation feature gate.

PodTemplate 🔗

PodTemplate describes a template for creating copies of a predefined pod.

PriorityClass 🔗

PriorityClass defines mapping from a priority class name to the priority integer value. The value can be any valid integer.

PriorityLevelConfiguration 🔗

PriorityLevelConfiguration represents the configuration of a priority level.

ReplicaSet 🔗

ReplicaSet ensures that a specified number of pod replicas are running at any given time.

ReplicationController 🔗

ReplicationController represents the configuration of a replication controller.

ResourceClaim 🔗

ResourceClaim describes which resources are needed by a resource consumer. Its status tracks whether the resource has been allocated and what the resulting attributes are. This is an alpha type and requires enabling the DynamicResourceAllocation feature gate.

ResourceClaimTemplate 🔗

ResourceClaimTemplate is used to produce ResourceClaim objects.

ResourceClass 🔗

ResourceClass is used by administrators to influence how resources are allocated. This is an alpha type and requires enabling the DynamicResourceAllocation feature gate.

ResourceQuota 🔗

ResourceQuota sets aggregate quota restrictions enforced per namespace

Role 🔗

Role is a namespaced, logical grouping of PolicyRules that can be referenced as a unit by a RoleBinding.

RoleBinding 🔗

RoleBinding references a role, but does not contain it. It can reference a Role in the same namespace or a ClusterRole in the global namespace. It adds who information via Subjects and namespace information by which namespace it exists in. RoleBindings in a given namespace only have effect in that namespace.

RuntimeClass 🔗

RuntimeClass defines a class of container runtime supported in the cluster. The RuntimeClass is used to determine which container runtime is used to run all containers in a pod. RuntimeClasses are manually defined by a user or cluster provisioner, and referenced in the PodSpec. The Kubelet is responsible for resolving the RuntimeClassName reference before running the pod. For more details, see

Scale 🔗

Scale represents a scaling request for a resource.

Secret 🔗

Secret holds secret data of a certain type. The total bytes of the values in the Data field must be less than MaxSecretSize bytes.

SelfSubjectAccessReview 🔗

SelfSubjectAccessReview checks whether or the current user can perform an action. Not filling in a spec.namespace means "in all namespaces". Self is a special case, because users should always be able to check whether they can perform an action

SelfSubjectReview 🔗

SelfSubjectReview contains the user information that the kube-apiserver has about the user making this request. When using impersonation, users will receive the user info of the user being impersonated. If impersonation or request header authentication is used, any extra keys will have their case ignored and returned as lowercase.

SelfSubjectRulesReview 🔗

SelfSubjectRulesReview enumerates the set of actions the current user can perform within a namespace. The returned list of actions may be incomplete depending on the server's authorization mode, and any errors experienced during the evaluation. SelfSubjectRulesReview should be used by UIs to show/hide actions, or to quickly let an end user reason about their permissions. It should NOT Be used by external systems to drive authorization decisions as this raises confused deputy, cache lifetime/revocation, and correctness concerns. SubjectAccessReview, and LocalAccessReview are the correct way to defer authorization decisions to the API server.

Service 🔗

Service is a named abstraction of software service (for example, mysql) consisting of local port (for example 3306) that the proxy listens on, and the selector that determines which pods will answer requests sent through the proxy.

ServiceAccount 🔗

ServiceAccount binds together: * a name, understood by users, and perhaps by peripheral systems, for an identity * a principal that can be authenticated and authorized * a set of secrets

StatefulSet 🔗

StatefulSet represents a set of pods with consistent identities. Identities are defined as: - Network: A single stable DNS and hostname. - Storage: As many VolumeClaims as requested. The StatefulSet guarantees that a given network identity will always map to the same storage identity.

Status 🔗

Status is a return value for calls that don't return other objects.

StorageClass 🔗

StorageClass describes the parameters for a class of storage for which PersistentVolumes can be dynamically provisioned. StorageClasses are non-namespaced; the name of the storage class according to etcd is in ObjectMeta.Name.

StorageVersion 🔗

Storage version of a specific resource.

SubjectAccessReview 🔗

SubjectAccessReview checks whether or not a user or group can perform an action.

TokenRequest 🔗

TokenRequest requests a token for a given service account.

TokenReview 🔗

TokenReview attempts to authenticate a token to a known user. Note: TokenReview requests may be cached by the webhook token authenticator plugin in the kube-apiserver.

ValidatingAdmissionPolicy 🔗

ValidatingAdmissionPolicy describes the definition of an admission validation policy that accepts or rejects an object without changing it.

ValidatingAdmissionPolicyBinding 🔗

ValidatingAdmissionPolicyBinding binds the ValidatingAdmissionPolicy with paramerized resources. ValidatingAdmissionPolicyBinding and parameter CRDs together define how cluster administrators configure policies for clusters. For a given admission request, each binding will cause its policy to be evaluated N times, where N is 1 for policies/bindings that don't use params, otherwise N is the number of parameters selected by the binding. The CEL expressions of a policy must have a computed CEL cost below the maximum CEL budget. Each evaluation of the policy is given an independent CEL cost budget. Adding/removing policies, bindings, or params can not affect whether a given (policy, binding, param) combination is within its own CEL budget.

ValidatingWebhookConfiguration 🔗

ValidatingWebhookConfiguration describes the configuration of and admission webhook that accept or reject and object without changing it.

VolumeAttachment 🔗

VolumeAttachment captures the intent to attach or detach the specified volume to/from the specified node. VolumeAttachment objects are non-namespaced.

WatchEvent 🔗

Event represents a single event to a watched resource.

See an issue here?