whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Correct links

Browse Source 
Signed-off-by: Celeste Horgan <celeste@cncf.io>
This commit is contained in:
Celeste Horgan
2020-05-12 10:04:27 -07:00
parent dfeed456d3
commit e0ae1338cd
15 changed files with 53 additions and 58 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/concepts/cluster-administration/flow-control.md
+9 -9
View File
@@ -131,14 +131,14 @@ classes:
namespace). These are important to isolate from other traffic because failures
in leader election cause their controllers to fail and restart, which in turn
causes more expensive traffic as the new controllers sync their informers.
* The `workload-high` priority level is for other requests from built-in
controllers.
* The `workload-low` priority level is for requests from any other service
account, which will typically include all requests from controllers runing in
Pods.
* The `global-default` priority level handles all other traffic, e.g.
interactive `kubectl` commands run by nonprivileged users.
@@ -150,7 +150,7 @@ are built in and may not be overwritten:
special `exempt` FlowSchema classifies all requests from the `system:masters`
group into this priority level. You may define other FlowSchemas that direct
other requests to this priority level, if appropriate.
* The special `catch-all` priority level is used in combination with the special
`catch-all` FlowSchema to make sure that every request gets some kind of
classification. Typically you should not rely on this catch-all configuration,
@@ -164,7 +164,7 @@ are built in and may not be overwritten:
## Resources
The flow control API involves two kinds of resources.
[PriorityLevelConfigurations](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io)
[PriorityLevelConfigurations](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io)
define the available isolation classes, the share of the available concurrency
budget that each can handle, and allow for fine-tuning queuing behavior.
[FlowSchemas](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#flowschema-v1alpha1-flowcontrol-apiserver-k8s-io)
@@ -204,7 +204,7 @@ to balance progress between request flows.
The queuing configuration allows tuning the fair queuing algorithm for a
priority level. Details of the algorithm can be read in the [enhancement
proposal](#what-s-next), but in short:
proposal](#whats-next), but in short:
* Increasing `queues` reduces the rate of collisions between different flows, at
the cost of increased memory usage. A value of 1 here effectively disables the
@@ -291,7 +291,7 @@ enabled has two extra headers: `X-Kubernetes-PF-FlowSchema-UID` and
`X-Kubernetes-PF-PriorityLevel-UID`, noting the flow schema that matched the request
and the priority level to which it was assigned, respectively. The API objects'
names are not included in these headers in case the requesting user does not
have permission to view them, so when debugging you can use a command like
have permission to view them, so when debugging you can use a command like
```shell
kubectl get flowschemas -o custom-columns="uid:{metadata.uid},name:{metadata.name}"
@@ -363,7 +363,7 @@ poorly-behaved workloads that may be harming system health.
* `apiserver_flowcontrol_request_execution_seconds` gives a histogram of how
long requests took to actually execute, grouped by the FlowSchema that matched the
request and the PriorityLevel to which it was assigned.
{{% /capture %}}
@@ -374,4 +374,4 @@ the [enhancement proposal](https://github.com/kubernetes/enhancements/blob/maste
You can make suggestions and feature requests via [SIG API
Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery).
{{% /capture %}}
{{% /capture %}}
content/en/docs/concepts/extend-kubernetes/operator.md
+2 -2
View File
@@ -106,7 +106,7 @@ as well as keeping the existing service in good shape.
## Writing your own Operator {#writing-operator}
If there isn't an Operator in the ecosystem that implements the behavior you
want, you can code your own. In [What's next](#what-s-next) you'll find a few
want, you can code your own. In [What's next](#whats-next) you'll find a few
links to libraries and tools you can use to write your own cloud native
Operator.
@@ -129,4 +129,4 @@ that can act as a [client for the Kubernetes API](/docs/reference/using-api/clie
* Read [CoreOS' original article](https://coreos.com/blog/introducing-operators.html) that introduced the Operator pattern
* Read an [article](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps) from Google Cloud about best practices for building Operators
{{% /capture %}}
{{% /capture %}}
content/en/docs/concepts/scheduling-eviction/scheduling-framework.md
+3 -3
View File
@@ -157,13 +157,13 @@ the three things:
1. **wait** (with a timeout) \
If a Permit plugin returns "wait", then the Pod is kept in an internal "waiting"
Pods list, and the binding cycle of this Pod starts but directly blocks until it
gets [approved](#frameworkhandle). If a timeout occurs, **wait** becomes **deny**
gets approved. If a timeout occurs, **wait** becomes **deny**
and the Pod is returned to the scheduling queue, triggering [Unreserve](#unreserve)
plugins.
{{< note >}}
While any plugin can access the list of "waiting" Pods and approve them
(see [`FrameworkHandle`](#frameworkhandle)), we expect only the permit
(see [`FrameworkHandle`](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20180409-scheduling-framework.md#frameworkhandle)), we expect only the permit
plugins to approve binding of reserved Pods that are in "waiting" state. Once a Pod
is approved, it is sent to the [PreBind](#pre-bind) phase.
{{< /note >}}
@@ -239,4 +239,4 @@ If you are using Kubernetes v1.18 or later, you can configure a set of plugins a
a scheduler profile and then define multiple profiles to fit various kinds of workload.
Learn more at [multiple profiles](/docs/reference/scheduling/profiles/#multiple-profiles).
{{% /capture %}}
{{% /capture %}}
content/en/docs/concepts/services-networking/dns-pod-service.md
+3 -5
View File
@@ -171,7 +171,7 @@ following pod-specific DNS policies. These policies are specified in the
- "`None`": It allows a Pod to ignore DNS settings from the Kubernetes
environment. All DNS settings are supposed to be provided using the
`dnsConfig` field in the Pod Spec.
See [Pod's DNS config](#pod-s-dns-config) subsection below.
See [Pod's DNS config](#pod-dns-config) subsection below.
{{< note >}}
"Default" is not the default DNS policy. If `dnsPolicy` is not
@@ -201,7 +201,7 @@ spec:
dnsPolicy: ClusterFirstWithHostNet
```
### Pod's DNS Config
### Pod's DNS Config {#pod-dns-config}
Pod's DNS Config allows users more control on the DNS settings for a Pod.
@@ -269,6 +269,4 @@ The availability of Pod DNS Config and DNS Policy "`None`"" is shown as below.
For guidance on administering DNS configurations, check
[Configure DNS Service](/docs/tasks/administer-cluster/dns-custom-nameservers/)
{{% /capture %}}
{{% /capture %}}
content/en/docs/concepts/storage/persistent-volumes.md
+4 -4
View File
@@ -736,9 +736,9 @@ and need persistent storage, it is recommended that you use the following patter
`persistentVolumeClaim.storageClassName` field.
This will cause the PVC to match the right storage
class if the cluster has StorageClasses enabled by the admin.
- If the user does not provide a storage class name, leave the
`persistentVolumeClaim.storageClassName` field as nil. This will cause a
PV to be automatically provisioned for the user with the default StorageClass
- If the user does not provide a storage class name, leave the
`persistentVolumeClaim.storageClassName` field as nil. This will cause a
PV to be automatically provisioned for the user with the default StorageClass
in the cluster. Many cluster environments have a default StorageClass installed,
or administrators can create their own default StorageClass.
- In your tooling, watch for PVCs that are not getting bound after some time
@@ -759,4 +759,4 @@ and need persistent storage, it is recommended that you use the following patter
* [PersistentVolumeSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumespec-v1-core)
* [PersistentVolumeClaim](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core)
* [PersistentVolumeClaimSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaimspec-v1-core)
{{% /capture %}}
{{% /capture %}}
content/en/docs/concepts/workloads/pods/init-containers.md
+2 -2
View File
@@ -241,7 +241,7 @@ myapp-pod 1/1 Running 0 9m
```
This simple example should provide some inspiration for you to create your own
init containers. [What's next](#what-s-next) contains a link to a more detailed example.
init containers. [What's next](#whats-next) contains a link to a more detailed example.
## Detailed behavior
@@ -325,4 +325,4 @@ reasons:
* Read about [creating a Pod that has an init container](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container)
* Learn how to [debug init containers](/docs/tasks/debug-application-cluster/debug-init-containers/)
{{% /capture %}}
{{% /capture %}}