Reorganize Working with Kubernetes Objects section
- move Understanding Kubernetes Objects to be section overview - within the section, consistently link to the new (moved) page from the first mention of “object” - add a redirect Co-authored-by: Divya Mohan <divya.mohan0209@gmail.com>pull/39576/head
Tim Bannister
parent
cd4cad9599
commit
634c17f61c
|
|
@ -26,7 +26,7 @@ closer to the desired state, by turning equipment on or off.
|
|||
## Controller pattern
|
||||
|
||||
A controller tracks at least one Kubernetes resource type.
|
||||
These [objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects)
|
||||
These {{< glossary_tooltip text="objects" term_id="object" >}}
|
||||
have a spec field that represents the desired state. The
|
||||
controller(s) for that resource are responsible for making the current
|
||||
state come closer to that desired state.
|
||||
|
|
@ -162,7 +162,7 @@ controller does.
|
|||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* Read about the [Kubernetes control plane](/docs/concepts/overview/components/#control-plane-components)
|
||||
* Discover some of the basic [Kubernetes objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/)
|
||||
* Discover some of the basic [Kubernetes objects](/docs/concepts/overview/working-with-objects/)
|
||||
* Learn more about the [Kubernetes API](/docs/concepts/overview/kubernetes-api/)
|
||||
* If you want to write your own controller, see
|
||||
[Extension Patterns](/docs/concepts/extend-kubernetes/#extension-patterns)
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ separate database or file service.
|
|||
|
||||
## ConfigMap object
|
||||
|
||||
A ConfigMap is an API [object](/docs/concepts/overview/working-with-objects/kubernetes-objects/)
|
||||
A ConfigMap is an {{< glossary_tooltip text="API object" term_id="object" >}}
|
||||
that lets you store configuration for other objects to use. Unlike most
|
||||
Kubernetes objects that have a `spec`, a ConfigMap has `data` and `binaryData`
|
||||
fields. These fields accept key-value pairs as their values. Both the `data`
|
||||
|
|
|
|||
|
|
@ -226,7 +226,7 @@ see the [Troubleshooting](#troubleshooting) section.
|
|||
### Monitoring compute & memory resource usage
|
||||
|
||||
The kubelet reports the resource usage of a Pod as part of the Pod
|
||||
[`status`](/docs/concepts/overview/working-with-objects/kubernetes-objects/#object-spec-and-status).
|
||||
[`status`](/docs/concepts/overview/working-with-objects/#object-spec-and-status).
|
||||
|
||||
If optional [tools for monitoring](/docs/tasks/debug/debug-cluster/resource-usage-monitoring/)
|
||||
are available in your cluster, then Pod resource usage can be retrieved either
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ methods for adding custom resources and how to choose between them.
|
|||
## Custom resources
|
||||
|
||||
A *resource* is an endpoint in the [Kubernetes API](/docs/concepts/overview/kubernetes-api/) that
|
||||
stores a collection of [API objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/)
|
||||
stores a collection of {{< glossary_tooltip text="API objects" term_id="object" >}}
|
||||
of a certain kind; for example, the built-in *pods* resource contains a collection of Pod objects.
|
||||
|
||||
A *custom resource* is an extension of the Kubernetes API that is not necessarily available in a default
|
||||
|
|
|
|||
|
|
@ -1,7 +1,137 @@
|
|||
---
|
||||
title: "Working with Kubernetes Objects"
|
||||
weight: 40
|
||||
title: Understanding Kubernetes Objects
|
||||
content_type: concept
|
||||
weight: 10
|
||||
description: >
|
||||
Kubernetes objects are persistent entities in the Kubernetes system. Kubernetes uses these entities to represent the state of your cluster.
|
||||
Kubernetes objects are persistent entities in the Kubernetes system.
|
||||
Kubernetes uses these entities to represent the state of your cluster.
|
||||
Learn about the Kubernetes object model and how to work with these objects.
|
||||
simple_list: true
|
||||
card:
|
||||
name: concepts
|
||||
weight: 40
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
This page explains how Kubernetes objects are represented in the Kubernetes API, and how you can
|
||||
express them in `.yaml` format.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Objects in Kubernetes {#kubernetes-objects}
|
||||
|
||||
*Kubernetes objects* are persistent entities in the Kubernetes system. Kubernetes uses these
|
||||
entities to represent the state of your cluster. Specifically, they can describe:
|
||||
|
||||
* What containerized applications are running (and on which nodes)
|
||||
* The resources available to those applications
|
||||
* The policies around how those applications behave, such as restart policies, upgrades, and fault-tolerance
|
||||
|
||||
A Kubernetes object is a "record of intent"--once you create the object, the Kubernetes system
|
||||
will constantly work to ensure that object exists. By creating an object, you're effectively
|
||||
telling the Kubernetes system what you want your cluster's workload to look like; this is your
|
||||
cluster's *desired state*.
|
||||
|
||||
To work with Kubernetes objects--whether to create, modify, or delete them--you'll need to use the
|
||||
[Kubernetes API](/docs/concepts/overview/kubernetes-api/). When you use the `kubectl` command-line
|
||||
interface, for example, the CLI makes the necessary Kubernetes API calls for you. You can also use
|
||||
the Kubernetes API directly in your own programs using one of the
|
||||
[Client Libraries](/docs/reference/using-api/client-libraries/).
|
||||
|
||||
### Object spec and status
|
||||
|
||||
Almost every Kubernetes object includes two nested object fields that govern
|
||||
the object's configuration: the object *`spec`* and the object *`status`*.
|
||||
For objects that have a `spec`, you have to set this when you create the object,
|
||||
providing a description of the characteristics you want the resource to have:
|
||||
its _desired state_.
|
||||
|
||||
The `status` describes the _current state_ of the object, supplied and updated
|
||||
by the Kubernetes system and its components. The Kubernetes
|
||||
{{< glossary_tooltip text="control plane" term_id="control-plane" >}} continually
|
||||
and actively manages every object's actual state to match the desired state you
|
||||
supplied.
|
||||
|
||||
For example: in Kubernetes, a Deployment is an object that can represent an
|
||||
application running on your cluster. When you create the Deployment, you
|
||||
might set the Deployment `spec` to specify that you want three replicas of
|
||||
the application to be running. The Kubernetes system reads the Deployment
|
||||
spec and starts three instances of your desired application--updating
|
||||
the status to match your spec. If any of those instances should fail
|
||||
(a status change), the Kubernetes system responds to the difference
|
||||
between spec and status by making a correction--in this case, starting
|
||||
a replacement instance.
|
||||
|
||||
For more information on the object spec, status, and metadata, see the
|
||||
[Kubernetes API Conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md).
|
||||
|
||||
### Describing a Kubernetes object
|
||||
|
||||
When you create an object in Kubernetes, you must provide the object spec that describes its
|
||||
desired state, as well as some basic information about the object (such as a name). When you use
|
||||
the Kubernetes API to create the object (either directly or via `kubectl`), that API request must
|
||||
include that information as JSON in the request body. **Most often, you provide the information to
|
||||
`kubectl` in a .yaml file.** `kubectl` converts the information to JSON when making the API
|
||||
request.
|
||||
|
||||
Here's an example `.yaml` file that shows the required fields and object spec for a Kubernetes Deployment:
|
||||
|
||||
{{< codenew file="application/deployment.yaml" >}}
|
||||
|
||||
One way to create a Deployment using a `.yaml` file like the one above is to use the
|
||||
[`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply) command
|
||||
in the `kubectl` command-line interface, passing the `.yaml` file as an argument. Here's an example:
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/application/deployment.yaml
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
```
|
||||
deployment.apps/nginx-deployment created
|
||||
```
|
||||
|
||||
### Required fields
|
||||
|
||||
In the `.yaml` file for the Kubernetes object you want to create, you'll need to set values for the following fields:
|
||||
|
||||
* `apiVersion` - Which version of the Kubernetes API you're using to create this object
|
||||
* `kind` - What kind of object you want to create
|
||||
* `metadata` - Data that helps uniquely identify the object, including a `name` string, `UID`, and optional `namespace`
|
||||
* `spec` - What state you desire for the object
|
||||
|
||||
The precise format of the object `spec` is different for every Kubernetes object, and contains
|
||||
nested fields specific to that object. The [Kubernetes API Reference](/docs/reference/kubernetes-api/)
|
||||
can help you find the spec format for all of the objects you can create using Kubernetes.
|
||||
|
||||
For example, see the [`spec` field](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec)
|
||||
for the Pod API reference.
|
||||
For each Pod, the `.spec` field specifies the pod and its desired state (such as the container image name for
|
||||
each container within that pod).
|
||||
Another example of an object specification is the
|
||||
[`spec` field](/docs/reference/kubernetes-api/workload-resources/stateful-set-v1/#StatefulSetSpec)
|
||||
for the StatefulSet API. For StatefulSet, the `.spec` field specifies the StatefulSet and
|
||||
its desired state.
|
||||
Within the `.spec` of a StatefulSet is a [template](/docs/concepts/workloads/pods/#pod-templates)
|
||||
for Pod objects. That template describes Pods that the StatefulSet controller will create in order to
|
||||
satisfy the StatefulSet specification.
|
||||
Different kinds of object can also have different `.status`; again, the API reference pages
|
||||
detail the structure of that `.status` field, and its content for each different type of object.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
If you're new to Kubernetes, read more about the following:
|
||||
|
||||
* [Pods](/docs/concepts/workloads/pods/) which are the most important basic Kubernetes objects.
|
||||
* [Deployment](/docs/concepts/workloads/controllers/deployment/) objects.
|
||||
* [Controllers](/docs/concepts/architecture/controller/) in Kubernetes.
|
||||
* [kubectl](/docs/reference/kubectl/) and [kubectl commands](/docs/reference/generated/kubectl/kubectl-commands).
|
||||
|
||||
To learn about the Kubernetes API in general, visit:
|
||||
|
||||
* [Kubernetes API overview](/docs/reference/using-api/)
|
||||
|
||||
To learn about objects in Kubernetes in more depth, read other pages in this section:
|
||||
<!-- Docsy automatically includes a list of pages in the section -->
|
||||
|
|
|
|||
|
|
@ -6,7 +6,8 @@ weight: 60
|
|||
|
||||
<!-- overview -->
|
||||
You can use Kubernetes annotations to attach arbitrary non-identifying metadata
|
||||
to objects. Clients such as tools and libraries can retrieve this metadata.
|
||||
to {{< glossary_tooltip text="objects" term_id="object" >}}.
|
||||
Clients such as tools and libraries can retrieve this metadata.
|
||||
|
||||
<!-- body -->
|
||||
## Attaching metadata to objects
|
||||
|
|
|
|||
|
|
@ -4,7 +4,8 @@ content_type: concept
|
|||
weight: 70
|
||||
---
|
||||
|
||||
_Field selectors_ let you [select Kubernetes resources](/docs/concepts/overview/working-with-objects/kubernetes-objects) based on the value of one or more resource fields. Here are some examples of field selector queries:
|
||||
_Field selectors_ let you select Kubernetes {{< glossary_tooltip text="objects" term_id="object" >}} based on the
|
||||
value of one or more resource fields. Here are some examples of field selector queries:
|
||||
|
||||
* `metadata.name=my-service`
|
||||
* `metadata.namespace!=default`
|
||||
|
|
|
|||
|
|
@ -8,6 +8,10 @@ weight: 80
|
|||
|
||||
{{<glossary_definition term_id="finalizer" length="long">}}
|
||||
|
||||
You can use finalizers to control {{<glossary_tooltip text="garbage collection" term_id="garbage-collection">}}
|
||||
of {{< glossary_tooltip text="objects" term_id="object" >}} by alerting {{<glossary_tooltip text="controllers" term_id="controller">}}
|
||||
to perform specific cleanup tasks before deleting the target resource.
|
||||
|
||||
Finalizers don't usually specify the code to execute. Instead, they are
|
||||
typically lists of keys on a specific resource similar to annotations.
|
||||
Kubernetes specifies some finalizers automatically, but you can also specify
|
||||
|
|
|
|||
|
|
@ -1,126 +0,0 @@
|
|||
---
|
||||
title: Understanding Kubernetes Objects
|
||||
content_type: concept
|
||||
weight: 10
|
||||
card:
|
||||
name: concepts
|
||||
weight: 40
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
This page explains how Kubernetes objects are represented in the Kubernetes API, and how you can
|
||||
express them in `.yaml` format.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Understanding Kubernetes objects {#kubernetes-objects}
|
||||
|
||||
*Kubernetes objects* are persistent entities in the Kubernetes system. Kubernetes uses these
|
||||
entities to represent the state of your cluster. Specifically, they can describe:
|
||||
|
||||
* What containerized applications are running (and on which nodes)
|
||||
* The resources available to those applications
|
||||
* The policies around how those applications behave, such as restart policies, upgrades, and fault-tolerance
|
||||
|
||||
A Kubernetes object is a "record of intent"--once you create the object, the Kubernetes system
|
||||
will constantly work to ensure that object exists. By creating an object, you're effectively
|
||||
telling the Kubernetes system what you want your cluster's workload to look like; this is your
|
||||
cluster's *desired state*.
|
||||
|
||||
To work with Kubernetes objects--whether to create, modify, or delete them--you'll need to use the
|
||||
[Kubernetes API](/docs/concepts/overview/kubernetes-api/). When you use the `kubectl` command-line
|
||||
interface, for example, the CLI makes the necessary Kubernetes API calls for you. You can also use
|
||||
the Kubernetes API directly in your own programs using one of the
|
||||
[Client Libraries](/docs/reference/using-api/client-libraries/).
|
||||
|
||||
### Object spec and status
|
||||
|
||||
Almost every Kubernetes object includes two nested object fields that govern
|
||||
the object's configuration: the object *`spec`* and the object *`status`*.
|
||||
For objects that have a `spec`, you have to set this when you create the object,
|
||||
providing a description of the characteristics you want the resource to have:
|
||||
its _desired state_.
|
||||
|
||||
The `status` describes the _current state_ of the object, supplied and updated
|
||||
by the Kubernetes system and its components. The Kubernetes
|
||||
{{< glossary_tooltip text="control plane" term_id="control-plane" >}} continually
|
||||
and actively manages every object's actual state to match the desired state you
|
||||
supplied.
|
||||
|
||||
For example: in Kubernetes, a Deployment is an object that can represent an
|
||||
application running on your cluster. When you create the Deployment, you
|
||||
might set the Deployment `spec` to specify that you want three replicas of
|
||||
the application to be running. The Kubernetes system reads the Deployment
|
||||
spec and starts three instances of your desired application--updating
|
||||
the status to match your spec. If any of those instances should fail
|
||||
(a status change), the Kubernetes system responds to the difference
|
||||
between spec and status by making a correction--in this case, starting
|
||||
a replacement instance.
|
||||
|
||||
For more information on the object spec, status, and metadata, see the
|
||||
[Kubernetes API Conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md).
|
||||
|
||||
### Describing a Kubernetes object
|
||||
|
||||
When you create an object in Kubernetes, you must provide the object spec that describes its
|
||||
desired state, as well as some basic information about the object (such as a name). When you use
|
||||
the Kubernetes API to create the object (either directly or via `kubectl`), that API request must
|
||||
include that information as JSON in the request body. **Most often, you provide the information to
|
||||
`kubectl` in a .yaml file.** `kubectl` converts the information to JSON when making the API
|
||||
request.
|
||||
|
||||
Here's an example `.yaml` file that shows the required fields and object spec for a Kubernetes Deployment:
|
||||
|
||||
{{< codenew file="application/deployment.yaml" >}}
|
||||
|
||||
One way to create a Deployment using a `.yaml` file like the one above is to use the
|
||||
[`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply) command
|
||||
in the `kubectl` command-line interface, passing the `.yaml` file as an argument. Here's an example:
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/application/deployment.yaml
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
```
|
||||
deployment.apps/nginx-deployment created
|
||||
```
|
||||
|
||||
### Required fields
|
||||
|
||||
In the `.yaml` file for the Kubernetes object you want to create, you'll need to set values for the following fields:
|
||||
|
||||
* `apiVersion` - Which version of the Kubernetes API you're using to create this object
|
||||
* `kind` - What kind of object you want to create
|
||||
* `metadata` - Data that helps uniquely identify the object, including a `name` string, `UID`, and optional `namespace`
|
||||
* `spec` - What state you desire for the object
|
||||
|
||||
The precise format of the object `spec` is different for every Kubernetes object, and contains
|
||||
nested fields specific to that object. The [Kubernetes API Reference](/docs/reference/kubernetes-api/)
|
||||
can help you find the spec format for all of the objects you can create using Kubernetes.
|
||||
|
||||
For example, see the [`spec` field](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec)
|
||||
for the Pod API reference.
|
||||
For each Pod, the `.spec` field specifies the pod and its desired state (such as the container image name for
|
||||
each container within that pod).
|
||||
Another example of an object specification is the
|
||||
[`spec` field](/docs/reference/kubernetes-api/workload-resources/stateful-set-v1/#StatefulSetSpec)
|
||||
for the StatefulSet API. For StatefulSet, the `.spec` field specifies the StatefulSet and
|
||||
its desired state.
|
||||
Within the `.spec` of a StatefulSet is a [template](/docs/concepts/workloads/pods/#pod-templates)
|
||||
for Pod objects. That template describes Pods that the StatefulSet controller will create in order to
|
||||
satisfy the StatefulSet specification.
|
||||
Different kinds of object can also have different `.status`; again, the API reference pages
|
||||
detail the structure of that `.status` field, and its content for each different type of object.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
Learn more about the following:
|
||||
|
||||
* [Pods](/docs/concepts/workloads/pods/) which are the most important basic Kubernetes objects.
|
||||
* [Deployment](/docs/concepts/workloads/controllers/deployment/) objects.
|
||||
* [Controllers](/docs/concepts/architecture/controller/) in Kubernetes.
|
||||
* [Kubernetes API overview](/docs/reference/using-api/) which explains some more API concepts.
|
||||
* [kubectl](/docs/reference/kubectl/) and [kubectl commands](/docs/reference/generated/kubectl/kubectl-commands).
|
||||
|
|
@ -8,7 +8,8 @@ weight: 40
|
|||
|
||||
<!-- overview -->
|
||||
|
||||
_Labels_ are key/value pairs that are attached to objects, such as pods.
|
||||
_Labels_ are key/value pairs that are attached to
|
||||
{{< glossary_tooltip text="objects" term_id="object" >}} such as Pods.
|
||||
Labels are intended to be used to specify identifying attributes of objects
|
||||
that are meaningful and relevant to users, but do not directly imply semantics
|
||||
to the core system. Labels can be used to organize and to select subsets of
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ weight: 30
|
|||
|
||||
<!-- overview -->
|
||||
|
||||
Each object in your cluster has a [_Name_](#names) that is unique for that type of resource.
|
||||
Each {{< glossary_tooltip text="object" term_id="object" >}} in your cluster has a [_Name_](#names) that is unique for that type of resource.
|
||||
Every Kubernetes object also has a [_UID_](#uids) that is unique across your whole cluster.
|
||||
|
||||
For example, you can only have one Pod named `myapp-1234` within the same [namespace](/docs/concepts/overview/working-with-objects/namespaces/), but you can have one Pod and one Deployment that are each named `myapp-1234`.
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ weight: 45
|
|||
|
||||
<!-- overview -->
|
||||
|
||||
In Kubernetes, _namespaces_ provides a mechanism for isolating groups of resources within a single cluster. Names of resources need to be unique within a namespace, but not across namespaces. Namespace-based scoping is applicable only for namespaced objects _(e.g. Deployments, Services, etc)_ and not for cluster-wide objects _(e.g. StorageClass, Nodes, PersistentVolumes, etc)_.
|
||||
In Kubernetes, _namespaces_ provides a mechanism for isolating groups of resources within a single cluster. Names of resources need to be unique within a namespace, but not across namespaces. Namespace-based scoping is applicable only for namespaced {{< glossary_tooltip text="objects" term_id="object" >}} _(e.g. Deployments, Services, etc)_ and not for cluster-wide objects _(e.g. StorageClass, Nodes, PersistentVolumes, etc)_.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ weight: 20
|
|||
|
||||
<!-- overview -->
|
||||
The `kubectl` command-line tool supports several different ways to create and manage
|
||||
Kubernetes objects. This document provides an overview of the different
|
||||
Kubernetes {{< glossary_tooltip text="objects" term_id="object" >}}. This document provides an overview of the different
|
||||
approaches. Read the [Kubectl book](https://kubectl.docs.kubernetes.io) for
|
||||
details of managing objects by Kubectl.
|
||||
|
||||
|
|
|
|||
|
|
@ -6,9 +6,10 @@ weight: 90
|
|||
|
||||
<!-- overview -->
|
||||
|
||||
In Kubernetes, some {{< glossary_tooltip text="objects" term_id="Object" >}} are *owners* of other objects. For example, a
|
||||
{{<glossary_tooltip text="ReplicaSet" term_id="replica-set">}} is the owner of a set of {{<glossary_tooltip text="Pods" term_id="pod">}}. These owned objects are *dependents*
|
||||
of their owner.
|
||||
In Kubernetes, some {{< glossary_tooltip text="objects" term_id="object" >}} are
|
||||
*owners* of other objects. For example, a
|
||||
{{<glossary_tooltip text="ReplicaSet" term_id="replica-set">}} is the owner
|
||||
of a set of Pods. These owned objects are *dependents* of their owner.
|
||||
|
||||
Ownership is different from the [labels and selectors](/docs/concepts/overview/working-with-objects/labels/)
|
||||
mechanism that some resources also use. For example, consider a Service that
|
||||
|
|
|
|||
|
|
@ -29,9 +29,9 @@ kube-apiserver --authorization-mode=Example,RBAC --other-options --more-options
|
|||
## API objects {#api-overview}
|
||||
|
||||
The RBAC API declares four kinds of Kubernetes object: _Role_, _ClusterRole_,
|
||||
_RoleBinding_ and _ClusterRoleBinding_. You can
|
||||
[describe objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/#understanding-kubernetes-objects),
|
||||
or amend them, using tools such as `kubectl`, just like any other Kubernetes object.
|
||||
_RoleBinding_ and _ClusterRoleBinding_. You can describe or amend the RBAC
|
||||
{{< glossary_tooltip text="objects" term_id="object" >}}
|
||||
using tools such as `kubectl`, just like any other Kubernetes object.
|
||||
|
||||
{{< caution >}}
|
||||
These objects, by design, impose access restrictions. If you are making changes
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
title: Object
|
||||
id: object
|
||||
date: 2020-10-12
|
||||
full_link: https://kubernetes.io/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects
|
||||
full_link: /docs/concepts/overview/working-with-objects/#kubernetes-objects
|
||||
short_description: >
|
||||
A entity in the Kubernetes system, representing part of the state of your cluster.
|
||||
aka:
|
||||
|
|
|
|||
|
|
@ -402,7 +402,7 @@ kubectl taint nodes foo dedicated=special-user:NoSchedule
|
|||
|
||||
### Resource types
|
||||
|
||||
List all supported resource types along with their shortnames, [API group](/docs/concepts/overview/kubernetes-api/#api-groups-and-versioning), whether they are [namespaced](/docs/concepts/overview/working-with-objects/namespaces), and [Kind](/docs/concepts/overview/working-with-objects/kubernetes-objects):
|
||||
List all supported resource types along with their shortnames, [API group](/docs/concepts/overview/kubernetes-api/#api-groups-and-versioning), whether they are [namespaced](/docs/concepts/overview/working-with-objects/namespaces), and [kind](/docs/concepts/overview/working-with-objects/):
|
||||
|
||||
```bash
|
||||
kubectl api-resources
|
||||
|
|
|
|||
|
|
@ -39,7 +39,7 @@ API concepts:
|
|||
* For some resource types, the API includes one or more *sub-resources*, which are represented as URI paths below the resource
|
||||
|
||||
Most Kubernetes API resource types are
|
||||
[objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects):
|
||||
{{< glossary_tooltip text="objects" term_id="object" >}} –
|
||||
they represent a concrete instance of a concept on the cluster, like a
|
||||
pod or namespace. A smaller number of API resource types are *virtual* in
|
||||
that they often represent operations on objects, rather than objects, such
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ min-kubernetes-server-version: 1.16
|
|||
|
||||
Server-Side Apply helps users and controllers manage their resources through
|
||||
declarative configurations. Clients can create and modify their
|
||||
[objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/)
|
||||
{{< glossary_tooltip text="objects" term_id="object" >}}
|
||||
declaratively by sending their fully specified intent.
|
||||
|
||||
A fully specified intent is a partial object that only includes the fields and
|
||||
|
|
|
|||
|
|
@ -109,7 +109,7 @@ Create the Pod:
|
|||
kubectl apply -f https://k8s.io/examples/admin/resource/cpu-defaults-pod-2.yaml --namespace=default-cpu-example
|
||||
```
|
||||
|
||||
View the [specification](/docs/concepts/overview/working-with-objects/kubernetes-objects/#object-spec-and-status)
|
||||
View the [specification](/docs/concepts/overview/working-with-objects/#object-spec-and-status)
|
||||
of the Pod that you created:
|
||||
|
||||
```
|
||||
|
|
@ -140,8 +140,7 @@ Create the Pod:
|
|||
kubectl apply -f https://k8s.io/examples/admin/resource/cpu-defaults-pod-3.yaml --namespace=default-cpu-example
|
||||
```
|
||||
|
||||
View the [specification](/docs/concepts/overview/working-with-objects/kubernetes-objects/#object-spec-and-status)
|
||||
of the Pod that you created:
|
||||
View the specification of the Pod that you created:
|
||||
|
||||
```
|
||||
kubectl get pod default-cpu-demo-3 --output=yaml --namespace=default-cpu-example
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@
|
|||
/docs/concepts/abstractions/controllers/garbage-collection/ /docs/concepts/workloads/controllers/garbage-collection/ 301
|
||||
/docs/concepts/abstractions/controllers/statefulsets/ /docs/concepts/workloads/controllers/statefulset/ 301
|
||||
/docs/concepts/abstractions/init-containers/ /docs/concepts/workloads/pods/init-containers/ 301
|
||||
/docs/concepts/abstractions/overview/ /docs/concepts/overview/working-with-objects/kubernetes-objects/ 301
|
||||
/docs/concepts/abstractions/overview/ /docs/concepts/overview/working-with-objects/ 301
|
||||
/docs/concepts/abstractions/pod/ /docs/concepts/workloads/pods/ 301
|
||||
/docs/concepts/api-extension/apiserver-aggregation/ /docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/ 301
|
||||
/docs/concepts/api-extension/custom-resources/ /docs/concepts/extend-kubernetes/api-extension/custom-resources/ 301
|
||||
|
|
@ -102,6 +102,7 @@
|
|||
/docs/concepts/tools/kubectl/object-management-using-declarative-config/ /docs/concepts/overview/object-management-kubectl/declarative-config/ 301
|
||||
/docs/concepts/tools/kubectl/object-management-using-imperative-commands/ /docs/concepts/overview/object-management-kubectl/imperative-command/ 301
|
||||
/docs/concepts/tools/kubectl/object-management-using-imperative-config/ /docs/concepts/overview/object-management-kubectl/imperative-config/ 301
|
||||
/docs/concepts/overview/working-with-objects/kubernetes-objects/ /docs/concepts/overview/working-with-objects/ 301
|
||||
/docs/concepts/overview/object-management-kubectl/overview/ /docs/concepts/overview/working-with-objects/object-management/ 301
|
||||
/docs/concepts/overview/object-management-kubectl/declarative-config/ /docs/tasks/manage-kubernetes-objects/declarative-config/ 301
|
||||
/docs/concepts/overview/object-management-kubectl/imperative-command/ /docs/tasks/manage-kubernetes-objects/imperative-command/ 301
|
||||
|
|
|
|||
Loading…
Reference in New Issue