Fix links in concepts section
Qiming Teng
parent
1996d94faa
commit
070023b24a
|
|
@ -49,7 +49,7 @@ To verify this connection, use the `--kubelet-certificate-authority` flag to pro
|
|||
If that is not possible, use [SSH tunneling](#ssh-tunnels) between the apiserver and kubelet if required to avoid connecting over an
|
||||
untrusted or public network.
|
||||
|
||||
Finally, [Kubelet authentication and/or authorization](/docs/admin/kubelet-authentication-authorization/) should be enabled to secure the kubelet API.
|
||||
Finally, [Kubelet authentication and/or authorization](/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/) should be enabled to secure the kubelet API.
|
||||
|
||||
### apiserver to nodes, pods, and services
|
||||
|
||||
|
|
|
|||
|
|
@ -24,8 +24,8 @@ the description of how logs are stored and handled on the node to be useful.
|
|||
|
||||
In this section, you can see an example of basic logging in Kubernetes that
|
||||
outputs data to the standard output stream. This demonstration uses
|
||||
a [pod specification](/examples/debug/counter-pod.yaml) with
|
||||
a container that writes some text to standard output once per second.
|
||||
a pod specification with a container that writes some text to standard output
|
||||
once per second.
|
||||
|
||||
{{< codenew file="debug/counter-pod.yaml" >}}
|
||||
|
||||
|
|
|
|||
|
|
@ -104,7 +104,7 @@ The kubelet collects accelerator metrics through cAdvisor. To collect these metr
|
|||
|
||||
The responsibility for collecting accelerator metrics now belongs to the vendor rather than the kubelet. Vendors must provide a container that collects metrics and exposes them to the metrics service (for example, Prometheus).
|
||||
|
||||
The [`DisableAcceleratorUsageMetrics` feature gate](/docs/references/command-line-tools-reference/feature-gate.md#feature-gates-for-alpha-or-beta-features:~:text= DisableAcceleratorUsageMetrics,-false) disables metrics collected by the kubelet, with a [timeline for enabling this feature by default](https://github.com/kubernetes/enhancements/tree/411e51027db842355bd489691af897afc1a41a5e/keps/sig-node/1867-disable-accelerator-usage-metrics#graduation-criteria).
|
||||
The [`DisableAcceleratorUsageMetrics` feature gate](/docs/reference/command-line-tools-reference/feature-gates/#feature-gates-for-alpha-or-beta-features:~:text= DisableAcceleratorUsageMetrics,-false) disables metrics collected by the kubelet, with a [timeline for enabling this feature by default](https://github.com/kubernetes/enhancements/tree/411e51027db842355bd489691af897afc1a41a5e/keps/sig-node/1867-disable-accelerator-usage-metrics#graduation-criteria).
|
||||
|
||||
## Component metrics
|
||||
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ weight: 70
|
|||
|
||||
{{< feature-state for_k8s_version="v1.14" state="stable" >}}
|
||||
|
||||
[Pods](/docs/concepts/workloads/pods/pod/) can have _priority_. Priority indicates the
|
||||
[Pods](/docs/concepts/workloads/pods/) can have _priority_. Priority indicates the
|
||||
importance of a Pod relative to other Pods. If a Pod cannot be scheduled, the
|
||||
scheduler tries to preempt (evict) lower priority Pods to make scheduling of the
|
||||
pending Pod possible.
|
||||
|
|
|
|||
|
|
@ -183,7 +183,7 @@ are accounted for in Kubernetes.
|
|||
|
||||
- [RuntimeClass Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md)
|
||||
- [RuntimeClass Scheduling Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md#runtimeclass-scheduling)
|
||||
- Read about the [Pod Overhead](/docs/concepts/configuration/pod-overhead/) concept
|
||||
- Read about the [Pod Overhead](/docs/concepts/scheduling-eviction/pod-overhead/) concept
|
||||
- [PodOverhead Feature Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md)
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ During the registration, the device plugin needs to send:
|
|||
* The name of its Unix socket.
|
||||
* The Device Plugin API version against which it was built.
|
||||
* The `ResourceName` it wants to advertise. Here `ResourceName` needs to follow the
|
||||
[extended resource naming scheme](/docs/concepts/configuration/manage-resources-container/#extended-resources)
|
||||
[extended resource naming scheme](/docs/concepts/configuration/manage-resources-containers/#extended-resources)
|
||||
as `vendor-domain/resourcetype`.
|
||||
(For example, an NVIDIA GPU is advertised as `nvidia.com/gpu`.)
|
||||
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ Kubernetes' {{< glossary_tooltip text="controllers" term_id="controller" >}}
|
|||
concept lets you extend the cluster's behaviour without modifying the code
|
||||
of Kubernetes itself.
|
||||
Operators are clients of the Kubernetes API that act as controllers for
|
||||
a [Custom Resource](/docs/concepts/api-extension/custom-resources/).
|
||||
a [Custom Resource](/docs/concepts/extend-kubernetes/api-extension/custom-resources/).
|
||||
|
||||
## An example Operator {#example}
|
||||
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ The Kubernetes API lets you query and manipulate the state of objects in the Kub
|
|||
Most operations can be performed through the
|
||||
[kubectl](/docs/reference/kubectl/overview/) command-line interface or other
|
||||
command-line tools, such as
|
||||
[kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/), which in turn use the
|
||||
[kubeadm](/docs/reference/setup-tools/kubeadm/), which in turn use the
|
||||
API. However, you can also access the API directly using REST calls.
|
||||
|
||||
Consider using one of the [client libraries](/docs/reference/using-api/client-libraries/)
|
||||
|
|
|
|||
|
|
@ -188,7 +188,7 @@ kubectl get pods -l 'environment,environment notin (frontend)'
|
|||
Some Kubernetes objects, such as [`services`](/docs/concepts/services-networking/service/)
|
||||
and [`replicationcontrollers`](/docs/concepts/workloads/controllers/replicationcontroller/),
|
||||
also use label selectors to specify sets of other resources, such as
|
||||
[pods](/docs/concepts/workloads/pods/pod/).
|
||||
[pods](/docs/concepts/workloads/pods/).
|
||||
|
||||
#### Service and ReplicationController
|
||||
|
||||
|
|
|
|||
|
|
@ -79,7 +79,7 @@ of the scheduler:
|
|||
|
||||
|
||||
1. [Scheduling Policies](/docs/reference/scheduling/policies) allow you to configure _Predicates_ for filtering and _Priorities_ for scoring.
|
||||
1. [Scheduling Profiles](/docs/reference/scheduling/profiles) allow you to configure Plugins that implement different scheduling stages, including: `QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit`, and others. You can also configure the kube-scheduler to run different profiles.
|
||||
1. [Scheduling Profiles](/docs/reference/scheduling/config/#profiles) allow you to configure Plugins that implement different scheduling stages, including: `QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit`, and others. You can also configure the kube-scheduler to run different profiles.
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
|
@ -89,7 +89,7 @@ of the scheduler:
|
|||
* Read the [reference documentation](/docs/reference/command-line-tools-reference/kube-scheduler/) for kube-scheduler
|
||||
* Learn about [configuring multiple schedulers](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)
|
||||
* Learn about [topology management policies](/docs/tasks/administer-cluster/topology-manager/)
|
||||
* Learn about [Pod Overhead](/docs/concepts/configuration/pod-overhead/)
|
||||
* Learn about [Pod Overhead](/docs/concepts/scheduling-eviction/pod-overhead/)
|
||||
* Learn about scheduling of Pods that use volumes in:
|
||||
* [Volume Topology Support](/docs/concepts/storage/storage-classes/#volume-binding-mode)
|
||||
* [Storage Capacity Tracking](/docs/concepts/storage/storage-capacity/)
|
||||
|
|
|
|||
|
|
@ -46,10 +46,9 @@ different purposes:
|
|||
[downwardAPI](/docs/concepts/storage/volumes/#downwardapi),
|
||||
[secret](/docs/concepts/storage/volumes/#secret): inject different
|
||||
kinds of Kubernetes data into a Pod
|
||||
- [CSI ephemeral
|
||||
volumes](docs/concepts/storage/volumes/#csi-ephemeral-volumes):
|
||||
similar to the previous volume kinds, but provided by special [CSI
|
||||
drivers](https://github.com/container-storage-interface/spec/blob/master/spec.md)
|
||||
- [CSI ephemeral volumes](#csi-ephemeral-volume):
|
||||
similar to the previous volume kinds, but provided by special
|
||||
[CSI drivers](https://github.com/container-storage-interface/spec/blob/master/spec.md)
|
||||
which specifically [support this feature](https://kubernetes-csi.github.io/docs/drivers.html)
|
||||
- [generic ephemeral volumes](#generic-ephemeral-volumes), which
|
||||
can be provided by all storage drivers that also support persistent volumes
|
||||
|
|
@ -181,8 +180,8 @@ spec:
|
|||
|
||||
### Lifecycle and PersistentVolumeClaim
|
||||
|
||||
The key design idea is that the [parameters for a
|
||||
volume claim](/docs/reference/generated/kubernetes-api/#ephemeralvolumesource-v1alpha1-core)
|
||||
The key design idea is that the
|
||||
[parameters for a volume claim](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ephemeralvolumesource-v1alpha1-core)
|
||||
are allowed inside a volume source of the Pod. Labels, annotations and
|
||||
the whole set of fields for a PersistentVolumeClaim are supported. When such a Pod gets
|
||||
created, the ephemeral volume controller then creates an actual PersistentVolumeClaim
|
||||
|
|
|
|||
|
|
@ -183,7 +183,7 @@ By specifying a PersistentVolume in a PersistentVolumeClaim, you declare a bindi
|
|||
If the PersistentVolume exists and has not reserved PersistentVolumeClaims through its `claimRef` field, then the PersistentVolume and PersistentVolumeClaim will be bound.
|
||||
|
||||
The binding happens regardless of some volume matching criteria, including node affinity.
|
||||
The control plane still checks that [storage class](https://kubernetes.io/docs/concepts/storage/storage-classes/), access modes, and requested storage size are valid.
|
||||
The control plane still checks that [storage class](/docs/concepts/storage/storage-classes/), access modes, and requested storage size are valid.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ Container starts with a clean state. Second, when running Containers together
|
|||
in a `Pod` it is often necessary to share files between those Containers. The
|
||||
Kubernetes `Volume` abstraction solves both of these problems.
|
||||
|
||||
Familiarity with [Pods](/docs/concepts/workloads/pods/pod/) is suggested.
|
||||
Familiarity with [Pods](/docs/concepts/workloads/pods/) is suggested.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
|
|
@ -52,8 +52,7 @@ field) and where to mount those into Containers (the
|
|||
field).
|
||||
|
||||
A process in a container sees a filesystem view composed from their Docker
|
||||
image and volumes. The [Docker
|
||||
image](https://docs.docker.com/userguide/dockerimages/) is at the root of the
|
||||
image and volumes. The [Docker image](https://docs.docker.com/userguide/dockerimages/) is at the root of the
|
||||
filesystem hierarchy, and any volumes are mounted at the specified paths within
|
||||
the image. Volumes can not mount onto other volumes or have hard links to
|
||||
other volumes. Each Container in the Pod must independently specify where to
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ Those workload resources include:
|
|||
* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) for running Pods that provide
|
||||
node-local facilities, such as a storage driver or network plugin;
|
||||
* [Job](/docs/concepts/workloads/controllers/job/) and
|
||||
[CronJob](/docs/concepts/workloads/controllers/cronjob/)
|
||||
[CronJob](/docs/concepts/workloads/controllers/cron-jobs/)
|
||||
for tasks that run to completion.
|
||||
|
||||
There are also two supporting concepts that you might find relevant:
|
||||
|
|
|
|||
|
|
@ -233,7 +233,7 @@ A ReplicaSet also needs a [`.spec` section](https://git.k8s.io/community/contrib
|
|||
|
||||
### Pod Template
|
||||
|
||||
The `.spec.template` is a [pod template](/docs/concepts/workloads/Pods/pod-overview/#pod-templates) which is also
|
||||
The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/#pod-templates) which is also
|
||||
required to have labels in place. In our `frontend.yaml` example we had one label: `tier: frontend`.
|
||||
Be careful not to overlap with the selectors of other controllers, lest they try to adopt this Pod.
|
||||
|
||||
|
|
@ -351,7 +351,7 @@ Unlike the case where a user directly created Pods, a ReplicaSet replaces Pods t
|
|||
|
||||
### Job
|
||||
|
||||
Use a [`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/) instead of a ReplicaSet for Pods that are expected to terminate on their own
|
||||
Use a [`Job`](/docs/concepts/workloads/controllers/job/) instead of a ReplicaSet for Pods that are expected to terminate on their own
|
||||
(that is, batch jobs).
|
||||
|
||||
### DaemonSet
|
||||
|
|
|
|||
|
|
@ -145,7 +145,7 @@ from a _pod template_ and manage those Pods on your behalf.
|
|||
|
||||
PodTemplates are specifications for creating Pods, and are included in workload resources such as
|
||||
[Deployments](/docs/concepts/workloads/controllers/deployment/),
|
||||
[Jobs](/docs/concepts/jobs/run-to-completion-finite-workloads/), and
|
||||
[Jobs](/docs/concepts/workloads/controllers/job/), and
|
||||
[DaemonSets](/docs/concepts/workloads/controllers/daemonset/).
|
||||
|
||||
Each controller for a workload resource uses the `PodTemplate` inside the workload
|
||||
|
|
@ -264,7 +264,7 @@ but cannot be controlled from there.
|
|||
* [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) explains common layouts for Pods with more than one container.
|
||||
|
||||
To understand the context for why Kubernetes wraps a common Pod API in other resources (such as {{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}} or {{< glossary_tooltip text="Deployments" term_id="deployment" >}}, you can read about the prior art, including:
|
||||
* [Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)
|
||||
* [Aurora](https://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)
|
||||
* [Borg](https://research.google.com/pubs/pub43438.html)
|
||||
* [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html)
|
||||
* [Omega](https://research.google/pubs/pub41684/)
|
||||
|
|
|
|||
|
|
@ -228,7 +228,8 @@ When a Pod's containers are Ready but at least one custom condition is missing o
|
|||
## Container probes
|
||||
|
||||
A [Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) is a diagnostic
|
||||
performed periodically by the [kubelet](/docs/admin/kubelet/)
|
||||
performed periodically by the
|
||||
[kubelet](/docs/reference/command-line-tools-reference/kubelet/)
|
||||
on a Container. To perform a diagnostic,
|
||||
the kubelet calls a
|
||||
[Handler](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#handler-v1-core) implemented by
|
||||
|
|
|
|||
Loading…
Reference in New Issue