kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #35582 from krol3/merged-main-dev-1.25 

Merge main branch into dev-1.25
This commit is contained in:
Kubernetes Prow Robot 2022-08-01 10:46:29 -07:00 committed by GitHub
parent 552925f112 d4fb248a84
commit acdef19888
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
227 changed files with 28740 additions and 4973 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
.gitignore vendored
View File

@ -29,6 +29,7 @@ nohup.out
# Hugo output
public/
resources/
.hugo_build.lock
# Netlify Functions build output
package-lock.json

4
content/de/_index.html
View File

@ -42,12 +42,12 @@ Kubernetes ist Open Source und bietet Dir die Freiheit, die Infrastruktur vor Or
<button id="desktopShowVideoButton" onclick="kub.showVideo()">Video ansehen</button>
<br>
<br>
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe-2022/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu22" button id="desktopKCButton">Besuche die KubeCon Europe vom 16. bis 20. Mai 2022</a>
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/" button id="desktopKCButton">Besuchen die KubeCon North America vom 24. bis 28. Oktober 2022</a>
<br>
<br>
<br>
<br>
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncna22" button id="desktopKCButton">Besuchen die KubeCon North America vom 24. bis 28. Oktober 2022</a>
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/" button id="desktopKCButton">Besuche die KubeCon Europe vom 17. bis 21. April 2023</a>
</div>
<div id="videoPlayer">
<iframe data-url="https://www.youtube.com/embed/H06qrNmGqyE?autoplay=1" frameborder="0" allowfullscreen></iframe>

6
content/en/_index.html
View File

@ -16,7 +16,7 @@ It groups containers that make up an application into logical units for easy man
{{% blocks/feature image="scalable" %}}
#### Planet Scale
Designed on the same principles that allows Google to run billions of containers a week, Kubernetes can scale without increasing your ops team.
Designed on the same principles that allow Google to run billions of containers a week, Kubernetes can scale without increasing your operations team.
{{% /blocks/feature %}}
@ -43,12 +43,12 @@ Kubernetes is open source giving you the freedom to take advantage of on-premise
<button id="desktopShowVideoButton" onclick="kub.showVideo()">Watch Video</button>
<br>
<br>
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncna22" button id="desktopKCButton">Attend KubeCon North America on October 24-28, 2022</a>
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america" button id="desktopKCButton">Attend KubeCon North America on October 24-28, 2022</a>
<br>
<br>
<br>
<br>
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe-2023/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu23" button id="desktopKCButton">Attend KubeCon Europe on April 17-21, 2023</a>
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/" button id="desktopKCButton">Attend KubeCon Europe on April 17-21, 2023</a>
</div>
<div id="videoPlayer">
<iframe data-url="https://www.youtube.com/embed/H06qrNmGqyE?autoplay=1" frameborder="0" allowfullscreen></iframe>

2
content/en/blog/_posts/2020-05-05-introducing-podtopologyspread.md
View File

@ -67,7 +67,7 @@ Let's see an example of a cluster to understand this API.
As the feature name "PodTopologySpread" implies, the basic usage of this feature
is to run your workload with an absolute even manner (maxSkew=1), or relatively
even manner (maxSkew>=2). See the [official
document](/docs/concepts/workloads/pods/pod-topology-spread-constraints/)
document](/docs/concepts/scheduling-eviction/topology-spread-constraints/)
for more details.
In addition to this basic usage, there are some advanced usage examples that

2
content/en/blog/_posts/2020-09-30-writing-crl-scheduler/index.md
View File

@ -70,7 +70,7 @@ To correct the latter issue, we now employ a "hunt and peck" approach to removin
### 1. Upgrade to kubernetes 1.18 and make use of Pod Topology Spread Constraints
While this seems like it could have been the perfect solution, at the time of writing Kubernetes 1.18 was unavailable on the two most common managed Kubernetes services in public cloud, EKS and GKE.
Furthermore, [pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/) were still a [beta feature in 1.18](https://v1-18.docs.kubernetes.io/docs/concepts/workloads/pods/pod-topology-spread-constraints/) which meant that it [wasn't guaranteed to be available in managed clusters](https://cloud.google.com/kubernetes-engine/docs/concepts/types-of-clusters#kubernetes_feature_choices) even when v1.18 became available.
Furthermore, [pod topology spread constraints](/docs/concepts/scheduling-eviction/topology-spread-constraints/) were still a beta feature in 1.18 which meant that it [wasn't guaranteed to be available in managed clusters](https://cloud.google.com/kubernetes-engine/docs/concepts/types-of-clusters#kubernetes_feature_choices) even when v1.18 became available.
The entire endeavour was concerningly reminiscent of checking [caniuse.com](https://caniuse.com/) when Internet Explorer 8 was still around.
### 2. Deploy a statefulset _per zone_.

2
content/en/blog/_posts/2022-04-07-Kubernetes-1-24-removals-and-deprecations.md
View File

@ -84,7 +84,7 @@ As stated earlier, there are several guides about
You can start with [Finding what container runtime are on your nodes](/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use/).
If your nodes are using dockershim, there are other possible Docker Engine dependencies such as
Pods or third-party tools executing Docker commands or private registries in the Docker configuration file. You can follow the
[Check whether Dockershim deprecation affects you](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/) guide to review possible
[Check whether Dockershim removal affects you](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-removal-affects-you/) guide to review possible
Docker Engine dependencies. Before upgrading to v1.24, you decide to either remain using Docker Engine and
[Migrate Docker Engine nodes from dockershim to cri-dockerd](/docs/tasks/administer-cluster/migrating-from-dockershim/migrate-dockershim-dockerd/) or migrate to a CRI-compatible runtime. Here's a guide to
[change the container runtime on a node from Docker Engine to containerd](/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd/).

2
content/en/docs/concepts/configuration/overview.md
View File

@ -63,7 +63,7 @@ DNS server watches the Kubernetes API for new `Services` and creates a set of DN
## Using Labels
- Define and use [labels](/docs/concepts/overview/working-with-objects/labels/) that identify __semantic attributes__ of your application or Deployment, such as `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`. You can use these labels to select the appropriate Pods for other resources; for example, a Service that selects all `tier: frontend` Pods, or all `phase: test` components of `app: myapp`. See the [guestbook](https://github.com/kubernetes/examples/tree/master/guestbook/) app for examples of this approach.
- Define and use [labels](/docs/concepts/overview/working-with-objects/labels/) that identify __semantic attributes__ of your application or Deployment, such as `{ app.kubernetes.io/name: MyApp, tier: frontend, phase: test, deployment: v3 }`. You can use these labels to select the appropriate Pods for other resources; for example, a Service that selects all `tier: frontend` Pods, or all `phase: test` components of `app.kubernetes.io/name: MyApp`. See the [guestbook](https://github.com/kubernetes/examples/tree/master/guestbook/) app for examples of this approach.
A Service can be made to span multiple Deployments by omitting release-specific labels from its selector. When you need to update a running service without downtime, use a [Deployment](/docs/concepts/workloads/controllers/deployment/).

2
content/en/docs/concepts/containers/runtime-class.md
View File

@ -116,7 +116,7 @@ Runtime handlers are configured through containerd's configuration at
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.${HANDLER_NAME}]
```
See containerd's [config documentation](https://github.com/containerd/cri/blob/master/docs/config.md)
See containerd's [config documentation](https://github.com/containerd/containerd/blob/main/docs/cri/config.md)
for more details:
#### {{< glossary_tooltip term_id="cri-o" >}}

1
content/en/docs/concepts/scheduling-eviction/_index.md
View File

@ -23,6 +23,7 @@ of terminating one or more Pods on Nodes.
* [Kubernetes Scheduler](/docs/concepts/scheduling-eviction/kube-scheduler/)
* [Assigning Pods to Nodes](/docs/concepts/scheduling-eviction/assign-pod-node/)
* [Pod Overhead](/docs/concepts/scheduling-eviction/pod-overhead/)
* [Pod Topology Spread Constraints](/docs/concepts/scheduling-eviction/topology-spread-constraints/)
* [Taints and Tolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/)
* [Scheduling Framework](/docs/concepts/scheduling-eviction/scheduling-framework)
* [Scheduler Performance Tuning](/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)

51
content/en/docs/concepts/scheduling-eviction/assign-pod-node.md
View File

@ -11,24 +11,27 @@ weight: 20
<!-- overview -->
You can constrain a {{< glossary_tooltip text="Pod" term_id="pod" >}} so that it can only run on particular set of
{{< glossary_tooltip text="node(s)" term_id="node" >}}.
You can constrain a {{< glossary_tooltip text="Pod" term_id="pod" >}} so that it is
_restricted_ to run on particular {{< glossary_tooltip text="node(s)" term_id="node" >}},
or to _prefer_ to run on particular nodes.
There are several ways to do this and the recommended approaches all use
[label selectors](/docs/concepts/overview/working-with-objects/labels/) to facilitate the selection.
Generally such constraints are unnecessary, as the scheduler will automatically do a reasonable placement
Often, you do not need to set any such constraints; the
{{< glossary_tooltip text="scheduler" term_id="kube-scheduler" >}} will automatically do a reasonable placement
(for example, spreading your Pods across nodes so as not place Pods on a node with insufficient free resources).
However, there are some circumstances where you may want to control which node
the Pod deploys to, for example, to ensure that a Pod ends up on a node with an SSD attached to it, or to co-locate Pods from two different
services that communicate a lot into the same availability zone.
the Pod deploys to, for example, to ensure that a Pod ends up on a node with an SSD attached to it,
or to co-locate Pods from two different services that communicate a lot into the same availability zone.
<!-- body -->
You can use any of the following methods to choose where Kubernetes schedules
specific Pods:
specific Pods:
* [nodeSelector](#nodeselector) field matching against [node labels](#built-in-node-labels)
* [Affinity and anti-affinity](#affinity-and-anti-affinity)
* [nodeName](#nodename) field
* [Pod topology spread constraints](#pod-topology-spread-constraints)
## Node labels {#built-in-node-labels}
@ -170,7 +173,7 @@ For example, consider the following Pod spec:
{{< codenew file="pods/pod-with-affinity-anti-affinity.yaml" >}}
If there are two possible nodes that match the
`requiredDuringSchedulingIgnoredDuringExecution` rule, one with the
`preferredDuringSchedulingIgnoredDuringExecution` rule, one with the
`label-1:key-1` label and another with the `label-2:key-2` label, the scheduler
considers the `weight` of each node and adds the weight to the other scores for
that node, and schedules the Pod onto the node with the highest final score.
@ -337,13 +340,15 @@ null `namespaceSelector` matches the namespace of the Pod where the rule is defi
Inter-pod affinity and anti-affinity can be even more useful when they are used with higher
level collections such as ReplicaSets, StatefulSets, Deployments, etc. These
rules allow you to configure that a set of workloads should
be co-located in the same defined topology, eg., the same node.
be co-located in the same defined topology; for example, preferring to place two related
Pods onto the same node.
Take, for example, a three-node cluster running a web application with an
in-memory cache like redis. You could use inter-pod affinity and anti-affinity
to co-locate the web servers with the cache as much as possible.
For example: imagine a three-node cluster. You use the cluster to run a web application
and also an in-memory cache (such as Redis). For this example, also assume that latency between
the web application and the memory cache should be as low as is practical. You could use inter-pod
affinity and anti-affinity to co-locate the web servers with the cache as much as possible.
In the following example Deployment for the redis cache, the replicas get the label `app=store`. The
In the following example Deployment for the Redis cache, the replicas get the label `app=store`. The
`podAntiAffinity` rule tells the scheduler to avoid placing multiple replicas
with the `app=store` label on a single node. This creates each cache in a
separate node.
@ -378,10 +383,10 @@ spec:
image: redis:3.2-alpine
```
The following Deployment for the web servers creates replicas with the label `app=web-store`. The
Pod affinity rule tells the scheduler to place each replica on a node that has a
Pod with the label `app=store`. The Pod anti-affinity rule tells the scheduler
to avoid placing multiple `app=web-store` servers on a single node.
The following example Deployment for the web servers creates replicas with the label `app=web-store`.
The Pod affinity rule tells the scheduler to place each replica on a node that has a Pod
with the label `app=store`. The Pod anti-affinity rule tells the scheduler never to place
multiple `app=web-store` servers on a single node.
```yaml
apiVersion: apps/v1
@ -430,6 +435,10 @@ where each web server is co-located with a cache, on three separate nodes.
| *webserver-1* | *webserver-2* | *webserver-3* |
| *cache-1* | *cache-2* | *cache-3* |
The overall effect is that each cache instance is likely to be accessed by a single client, that
is running on the same node. This approach aims to minimize both skew (imbalanced load) and latency.
You might have other reasons to use Pod anti-affinity.
See the [ZooKeeper tutorial](/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure)
for an example of a StatefulSet configured with anti-affinity for high
availability, using the same technique as this example.
@ -468,6 +477,16 @@ spec:
The above Pod will only run on the node `kube-01`.
## Pod topology spread constraints
You can use _topology spread constraints_ to control how {{< glossary_tooltip text="Pods" term_id="Pod" >}}
are spread across your cluster among failure-domains such as regions, zones, nodes, or among any other
topology domains that you define. You might do this to improve performance, expected availability, or
overall utilization.
Read [Pod topology spread constraints](/docs/concepts/scheduling-eviction/topology-spread-constraints/)
to learn more about how these work.
## {{% heading "whatsnext" %}}
* Read more about [taints and tolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/) .

2
content/en/docs/concepts/scheduling-eviction/kube-scheduler.md
View File

@ -83,7 +83,7 @@ of the scheduler:
## {{% heading "whatsnext" %}}
* Read about [scheduler performance tuning](/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)
* Read about [Pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/)
* Read about [Pod topology spread constraints](/docs/concepts/scheduling-eviction/topology-spread-constraints/)
* Read the [reference documentation](/docs/reference/command-line-tools-reference/kube-scheduler/) for kube-scheduler
* Read the [kube-scheduler config (v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/) reference
* Learn about [configuring multiple schedulers](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)

12
content/en/docs/concepts/scheduling-eviction/node-pressure-eviction.md
View File

@ -91,9 +91,9 @@ Some kubelet garbage collection features are deprecated in favor of eviction:
| ------------- | -------- | --------- |
| `--image-gc-high-threshold` | `--eviction-hard` or `--eviction-soft` | existing eviction signals can trigger image garbage collection |
| `--image-gc-low-threshold` | `--eviction-minimum-reclaim` | eviction reclaims achieve the same behavior |
| `--maximum-dead-containers` | | deprecated once old logs are stored outside of container's context |
| `--maximum-dead-containers-per-container` | | deprecated once old logs are stored outside of container's context |
| `--minimum-container-ttl-duration` | | deprecated once old logs are stored outside of container's context |
| `--maximum-dead-containers` | - | deprecated once old logs are stored outside of container's context |
| `--maximum-dead-containers-per-container` | - | deprecated once old logs are stored outside of container's context |
| `--minimum-container-ttl-duration` | - | deprecated once old logs are stored outside of container's context |
### Eviction thresholds
@ -216,7 +216,7 @@ the kubelet frees up disk space in the following order:
If the kubelet's attempts to reclaim node-level resources don't bring the eviction
signal below the threshold, the kubelet begins to evict end-user pods.
The kubelet uses the following parameters to determine pod eviction order:
The kubelet uses the following parameters to determine the pod eviction order:
1. Whether the pod's resource usage exceeds requests
1. [Pod Priority](/docs/concepts/scheduling-eviction/pod-priority-preemption/)
@ -319,7 +319,7 @@ The kubelet sets an `oom_score_adj` value for each container based on the QoS fo
{{<note>}}
The kubelet also sets an `oom_score_adj` value of `-997` for containers in Pods that have
`system-node-critical` {{<glossary_tooltip text="Priority" term_id="pod-priority">}}
`system-node-critical` {{<glossary_tooltip text="Priority" term_id="pod-priority">}}.
{{</note>}}
If the kubelet can't reclaim memory before a node experiences OOM, the
@ -401,7 +401,7 @@ counted as `active_file`. If enough of these kernel block buffers are on the
active LRU list, the kubelet is liable to observe this as high resource use and
taint the node as experiencing memory pressure - triggering pod eviction.
For more more details, see [https://github.com/kubernetes/kubernetes/issues/43916](https://github.com/kubernetes/kubernetes/issues/43916)
For more details, see [https://github.com/kubernetes/kubernetes/issues/43916](https://github.com/kubernetes/kubernetes/issues/43916)
You can work around that behavior by setting the memory limit and memory request
the same for containers likely to perform intensive I/O activity. You will need

570
content/en/docs/concepts/scheduling-eviction/topology-spread-constraints.md Normal file
View File

@ -0,0 +1,570 @@
---
title: Pod Topology Spread Constraints
content_type: concept
weight: 40
---
<!-- overview -->
You can use _topology spread constraints_ to control how
{{< glossary_tooltip text="Pods" term_id="Pod" >}} are spread across your cluster
among failure-domains such as regions, zones, nodes, and other user-defined topology
domains. This can help to achieve high availability as well as efficient resource
utilization.
You can set [cluster-level constraints](#cluster-level-default-constraints) as a default,
or configure topology spread constraints for individual workloads.
<!-- body -->
## Motivation
Imagine that you have a cluster of up to twenty nodes, and you want to run a
{{< glossary_tooltip text="workload" term_id="workload" >}}
that automatically scales how many replicas it uses. There could be as few as
two Pods or as many as fifteen.
When there are only two Pods, you'd prefer not to have both of those Pods run on the
same node: you would run the risk that a single node failure takes your workload
offline.
In addition to this basic usage, there are some advanced usage examples that
enable your workloads to benefit on high availability and cluster utilization.
As you scale up and run more Pods, a different concern becomes important. Imagine
that you have three nodes running five Pods each. The nodes have enough capacity
to run that many replicas; however, the clients that interact with this workload
are split across three different datacenters (or infrastructure zones). Now you
have less concern about a single node failure, but you notice that latency is
higher than you'd like, and you are paying for network costs associated with
sending network traffic between the different zones.
You decide that under normal operation you'd prefer to have a similar number of replicas
[scheduled](/docs/concepts/scheduling-eviction/) into each infrastructure zone,
and you'd like the cluster to self-heal in the case that there is a problem.
Pod topology spread constraints offer you a declarative way to configure that.
## `topologySpreadConstraints` field
The Pod API includes a field, `spec.topologySpreadConstraints`. Here is an example:
```yaml
---
apiVersion: v1
kind: Pod
metadata:
name: example-pod
spec:
# Configure a topology spread constraint
topologySpreadConstraints:
- maxSkew: <integer>
minDomains: <integer> # optional; alpha since v1.24
topologyKey: <string>
whenUnsatisfiable: <string>
labelSelector: <object>
### other Pod fields go here
```
You can read more about this field by running `kubectl explain Pod.spec.topologySpreadConstraints`.
### Spread constraint definition
You can define one or multiple `topologySpreadConstraints` entries to instruct the
kube-scheduler how to place each incoming Pod in relation to the existing Pods across
your cluster. Those fields are:
- **maxSkew** describes the degree to which Pods may be unevenly distributed. You must
specify this field and the number must be greater than zero. Its semantics differ
according to the value of `whenUnsatisfiable`:
- if you select `whenUnsatisfiable: DoNotSchedule`, then `maxSkew` defines the
maximum permitted difference between the number of matching pods in the target
topology and the _global minimum_
(the minimum number of pods that match the label selector in a topology domain).
For example, if you have 3 zones with 2, 4 and 5 matching pods respectively,
then the global minimum is 2 and `maxSkew` is compared relative to that number.
- if you select `whenUnsatisfiable: ScheduleAnyway`, the scheduler gives higher
precedence to topologies that would help reduce the skew.
- **minDomains** indicates a minimum number of eligible domains. This field is optional.
A domain is a particular instance of a topology. An eligible domain is a domain whose
nodes match the node selector.
{{< note >}}
The `minDomains` field is an alpha field added in 1.24. You have to enable the
`MinDomainsInPodToplogySpread` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
in order to use it.
{{< /note >}}
- The value of `minDomains` must be greater than 0, when specified.
You can only specify `minDomains` in conjunction with `whenUnsatisfiable: DoNotSchedule`.
- When the number of eligible domains with match topology keys is less than `minDomains`,
Pod topology spread treats global minimum as 0, and then the calculation of `skew` is performed.
The global minimum is the minimum number of matching Pods in an eligible domain,
or zero if the number of eligible domains is less than `minDomains`.
- When the number of eligible domains with matching topology keys equals or is greater than
`minDomains`, this value has no effect on scheduling.
- If you do not specify `minDomains`, the constraint behaves as if `minDomains` is 1.
- **topologyKey** is the key of [node labels](#node-labels). If two Nodes are labelled
with this key and have identical values for that label, the scheduler treats both
Nodes as being in the same topology. The scheduler tries to place a balanced number
of Pods into each topology domain.
- **whenUnsatisfiable** indicates how to deal with a Pod if it doesn't satisfy the spread constraint:
- `DoNotSchedule` (default) tells the scheduler not to schedule it.
- `ScheduleAnyway` tells the scheduler to still schedule it while prioritizing nodes that minimize the skew.
- **labelSelector** is used to find matching Pods. Pods
that match this label selector are counted to determine the
number of Pods in their corresponding topology domain.
See [Label Selectors](/docs/concepts/overview/working-with-objects/labels/#label-selectors)
for more details.
When a Pod defines more than one `topologySpreadConstraint`, those constraints are
combined using a logical AND operation: the kube-scheduler looks for a node for the incoming Pod
that satisfies all the configured constraints.
### Node labels
Topology spread constraints rely on node labels to identify the topology
domain(s) that each {{< glossary_tooltip text="node" term_id="node" >}} is in.
For example, a node might have labels:
```yaml
region: us-east-1
zone: us-east-1a
```
{{< note >}}
For brevity, this example doesn't use the
[well-known](/docs/reference/labels-annotations-taints/) label keys
`topology.kubernetes.io/zone` and `topology.kubernetes.io/region`. However,
those registered label keys are nonetheless recommended rather than the private
(unqualified) label keys `region` and `zone` that are used here.
You can't make a reliable assumption about the meaning of a private label key
between different contexts.
{{< /note >}}
Suppose you have a 4-node cluster with the following labels:
```
NAME STATUS ROLES AGE VERSION LABELS
node1 Ready <none> 4m26s v1.16.0 node=node1,zone=zoneA
node2 Ready <none> 3m58s v1.16.0 node=node2,zone=zoneA
node3 Ready <none> 3m17s v1.16.0 node=node3,zone=zoneB
node4 Ready <none> 2m43s v1.16.0 node=node4,zone=zoneB
```
Then the cluster is logically viewed as below:
{{<mermaid>}}
graph TB
subgraph "zoneB"
n3(Node3)
n4(Node4)
end
subgraph "zoneA"
n1(Node1)
n2(Node2)
end
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
class n1,n2,n3,n4 k8s;
class zoneA,zoneB cluster;
{{< /mermaid >}}
## Consistency
You should set the same Pod topology spread constraints on all pods in a group.
Usually, if you are using a workload controller such as a Deployment, the pod template
takes care of this for you. If you mix different spread constraints then Kubernetes
follows the API definition of the field; however, the behavior is more likely to become
confusing and troubleshooting is less straightforward.
You need a mechanism to ensure that all the nodes in a topology domain (such as a
cloud provider region) are labelled consistently.
To avoid you needing to manually label nodes, most clusters automatically
populate well-known labels such as `topology.kubernetes.io/hostname`. Check whether
your cluster supports this.
## Topology spread constraint examples
### Example: one topology spread constraint {#example-one-topologyspreadconstraint}
Suppose you have a 4-node cluster where 3 Pods labelled `foo: bar` are located in
node1, node2 and node3 respectively:
{{<mermaid>}}
graph BT
subgraph "zoneB"
p3(Pod) --> n3(Node3)
n4(Node4)
end
subgraph "zoneA"
p1(Pod) --> n1(Node1)
p2(Pod) --> n2(Node2)
end
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
class n1,n2,n3,n4,p1,p2,p3 k8s;
class zoneA,zoneB cluster;
{{< /mermaid >}}
If you want an incoming Pod to be evenly spread with existing Pods across zones, you
can use a manifest similar to:
{{< codenew file="pods/topology-spread-constraints/one-constraint.yaml" >}}
From that manifest, `topologyKey: zone` implies the even distribution will only be applied
to nodes that are labelled `zone: <any value>` (nodes that don't have a `zone` label
are skipped). The field `whenUnsatisfiable: DoNotSchedule` tells the scheduler to let the
incoming Pod stay pending if the scheduler can't find a way to satisfy the constraint.
If the scheduler placed this incoming Pod into zone `A`, the distribution of Pods would
become `[3, 1]`. That means the actual skew is then 2 (calculated as `3 - 1`), which
violates `maxSkew: 1`. To satisfy the constraints and context for this example, the
incoming Pod can only be placed onto a node in zone `B`:
{{<mermaid>}}
graph BT
subgraph "zoneB"
p3(Pod) --> n3(Node3)
p4(mypod) --> n4(Node4)
end
subgraph "zoneA"
p1(Pod) --> n1(Node1)
p2(Pod) --> n2(Node2)
end
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
class n1,n2,n3,n4,p1,p2,p3 k8s;
class p4 plain;
class zoneA,zoneB cluster;
{{< /mermaid >}}
OR
{{<mermaid>}}
graph BT
subgraph "zoneB"
p3(Pod) --> n3(Node3)
p4(mypod) --> n3
n4(Node4)
end
subgraph "zoneA"
p1(Pod) --> n1(Node1)
p2(Pod) --> n2(Node2)
end
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
class n1,n2,n3,n4,p1,p2,p3 k8s;
class p4 plain;
class zoneA,zoneB cluster;
{{< /mermaid >}}
You can tweak the Pod spec to meet various kinds of requirements:
- Change `maxSkew` to a bigger value - such as `2` - so that the incoming Pod can
be placed into zone `A` as well.
- Change `topologyKey` to `node` so as to distribute the Pods evenly across nodes
instead of zones. In the above example, if `maxSkew` remains `1`, the incoming
Pod can only be placed onto the node `node4`.
- Change `whenUnsatisfiable: DoNotSchedule` to `whenUnsatisfiable: ScheduleAnyway`
to ensure the incoming Pod to be always schedulable (suppose other scheduling APIs
are satisfied). However, it's preferred to be placed into the topology domain which
has fewer matching Pods. (Be aware that this preference is jointly normalized
with other internal scheduling priorities such as resource usage ratio).
### Example: multiple topology spread constraints {#example-multiple-topologyspreadconstraints}
This builds upon the previous example. Suppose you have a 4-node cluster where 3
existing Pods labeled `foo: bar` are located on node1, node2 and node3 respectively:
{{<mermaid>}}
graph BT
subgraph "zoneB"
p3(Pod) --> n3(Node3)
n4(Node4)
end
subgraph "zoneA"
p1(Pod) --> n1(Node1)
p2(Pod) --> n2(Node2)
end
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
class n1,n2,n3,n4,p1,p2,p3 k8s;
class p4 plain;
class zoneA,zoneB cluster;
{{< /mermaid >}}
You can combine two topology spread constraints to control the spread of Pods both
by node and by zone:
{{< codenew file="pods/topology-spread-constraints/two-constraints.yaml" >}}
In this case, to match the first constraint, the incoming Pod can only be placed onto
nodes in zone `B`; while in terms of the second constraint, the incoming Pod can only be
scheduled to the node `node4`. The scheduler only considers options that satisfy all
defined constraints, so the only valid placement is onto node `node4`.
### Example: conflicting topology spread constraints {#example-conflicting-topologyspreadconstraints}
Multiple constraints can lead to conflicts. Suppose you have a 3-node cluster across 2 zones:
{{<mermaid>}}
graph BT
subgraph "zoneB"
p4(Pod) --> n3(Node3)
p5(Pod) --> n3
end
subgraph "zoneA"
p1(Pod) --> n1(Node1)
p2(Pod) --> n1
p3(Pod) --> n2(Node2)
end
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
class n1,n2,n3,n4,p1,p2,p3,p4,p5 k8s;
class zoneA,zoneB cluster;
{{< /mermaid >}}
If you were to apply
[`two-constraints.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/pods/topology-spread-constraints/two-constraints.yaml)
(the manifest from the previous example)
to **this** cluster, you would see that the Pod `mypod` stays in the `Pending` state.
This happens because: to satisfy the first constraint, the Pod `mypod` can only
be placed into zone `B`; while in terms of the second constraint, the Pod `mypod`
can only schedule to node `node2`. The intersection of the two constraints returns
an empty set, and the scheduler cannot place the Pod.
To overcome this situation, you can either increase the value of `maxSkew` or modify
one of the constraints to use `whenUnsatisfiable: ScheduleAnyway`. Depending on
circumstances, you might also decide to delete an existing Pod manually - for example,
if you are troubleshooting why a bug-fix rollout is not making progress.
#### Interaction with node affinity and node selectors
The scheduler will skip the non-matching nodes from the skew calculations if the
incoming Pod has `spec.nodeSelector` or `spec.affinity.nodeAffinity` defined.
### Example: topology spread constraints with node affinity {#example-topologyspreadconstraints-with-nodeaffinity}
Suppose you have a 5-node cluster ranging across zones A to C:
{{<mermaid>}}
graph BT
subgraph "zoneB"
p3(Pod) --> n3(Node3)
n4(Node4)
end
subgraph "zoneA"
p1(Pod) --> n1(Node1)
p2(Pod) --> n2(Node2)
end
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
class n1,n2,n3,n4,p1,p2,p3 k8s;
class p4 plain;
class zoneA,zoneB cluster;
{{< /mermaid >}}
{{<mermaid>}}
graph BT
subgraph "zoneC"
n5(Node5)
end
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
class n5 k8s;
class zoneC cluster;
{{< /mermaid >}}
and you know that zone `C` must be excluded. In this case, you can compose a manifest
as below, so that Pod `mypod` will be placed into zone `B` instead of zone `C`.
Similarly, Kubernetes also respects `spec.nodeSelector`.
{{< codenew file="pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml" >}}
## Implicit conventions
There are some implicit conventions worth noting here:
- Only the Pods holding the same namespace as the incoming Pod can be matching candidates.
- The scheduler bypasses any nodes that don't have any `topologySpreadConstraints[*].topologyKey`
present. This implies that:
1. any Pods located on those bypassed nodes do not impact `maxSkew` calculation - in the
above example, suppose the node `node1` does not have a label "zone", then the 2 Pods will
be disregarded, hence the incoming Pod will be scheduled into zone `A`.
2. the incoming Pod has no chances to be scheduled onto this kind of nodes -
in the above example, suppose a node `node5` has the **mistyped** label `zone-typo: zoneC`
(and no `zone` label set). After node `node5` joins the cluster, it will be bypassed and
Pods for this workload aren't scheduled there.
- Be aware of what will happen if the incoming Pod's
`topologySpreadConstraints[*].labelSelector` doesn't match its own labels. In the
above example, if you remove the incoming Pod's labels, it can still be placed onto
nodes in zone `B`, since the constraints are still satisfied. However, after that
placement, the degree of imbalance of the cluster remains unchanged - it's still zone `A`
having 2 Pods labelled as `foo: bar`, and zone `B` having 1 Pod labelled as
`foo: bar`. If this is not what you expect, update the workload's
`topologySpreadConstraints[*].labelSelector` to match the labels in the pod template.
## Cluster-level default constraints
It is possible to set default topology spread constraints for a cluster. Default
topology spread constraints are applied to a Pod if, and only if:
- It doesn't define any constraints in its `.spec.topologySpreadConstraints`.
- It belongs to a Service, ReplicaSet, StatefulSet or ReplicationController.
Default constraints can be set as part of the `PodTopologySpread` plugin
arguments in a [scheduling profile](/docs/reference/scheduling/config/#profiles).
The constraints are specified with the same [API above](#api), except that
`labelSelector` must be empty. The selectors are calculated from the Services,
ReplicaSets, StatefulSets or ReplicationControllers that the Pod belongs to.
An example configuration might look like follows:
```yaml
apiVersion: kubescheduler.config.k8s.io/v1beta3
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: default-scheduler
pluginConfig:
- name: PodTopologySpread
args:
defaultConstraints:
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: ScheduleAnyway
defaultingType: List
```
{{< note >}}
The [`SelectorSpread` plugin](/docs/reference/scheduling/config/#scheduling-plugins)
is disabled by default. The Kubernetes project recommends using `PodTopologySpread`
to achieve similar behavior.
{{< /note >}}
### Built-in default constraints {#internal-default-constraints}
{{< feature-state for_k8s_version="v1.24" state="stable" >}}
If you don't configure any cluster-level default constraints for pod topology spreading,
then kube-scheduler acts as if you specified the following default topology constraints:
```yaml
defaultConstraints:
- maxSkew: 3
topologyKey: "kubernetes.io/hostname"
whenUnsatisfiable: ScheduleAnyway
- maxSkew: 5
topologyKey: "topology.kubernetes.io/zone"
whenUnsatisfiable: ScheduleAnyway
```
Also, the legacy `SelectorSpread` plugin, which provides an equivalent behavior,
is disabled by default.
{{< note >}}
The `PodTopologySpread` plugin does not score the nodes that don't have
the topology keys specified in the spreading constraints. This might result
in a different default behavior compared to the legacy `SelectorSpread` plugin when
using the default topology constraints.
If your nodes are not expected to have **both** `kubernetes.io/hostname` and
`topology.kubernetes.io/zone` labels set, define your own constraints
instead of using the Kubernetes defaults.
{{< /note >}}
If you don't want to use the default Pod spreading constraints for your cluster,
you can disable those defaults by setting `defaultingType` to `List` and leaving
empty `defaultConstraints` in the `PodTopologySpread` plugin configuration:
```yaml
apiVersion: kubescheduler.config.k8s.io/v1beta3
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: default-scheduler
pluginConfig:
- name: PodTopologySpread
args:
defaultConstraints: []
defaultingType: List
```
## Comparison with podAffinity and podAntiAffinity {#comparison-with-podaffinity-podantiaffinity}
In Kubernetes, [inter-Pod affinity and anti-affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity)
control how Pods are scheduled in relation to one another - either more packed
or more scattered.
`podAffinity`
: attracts Pods; you can try to pack any number of Pods into qualifying
topology domain(s)
`podAntiAffinity`
: repels Pods. If you set this to `requiredDuringSchedulingIgnoredDuringExecution` mode then
only a single Pod can be scheduled into a single topology domain; if you choose
`preferredDuringSchedulingIgnoredDuringExecution` then you lose the ability to enforce the
constraint.
For finer control, you can specify topology spread constraints to distribute
Pods across different topology domains - to achieve either high availability or
cost-saving. This can also help on rolling update workloads and scaling out
replicas smoothly.
For more context, see the
[Motivation](https://github.com/kubernetes/enhancements/tree/master/keps/sig-scheduling/895-pod-topology-spread#motivation)
section of the enhancement proposal about Pod topology spread constraints.
## Known limitations
- There's no guarantee that the constraints remain satisfied when Pods are removed. For
example, scaling down a Deployment may result in imbalanced Pods distribution.
You can use a tool such as the [Descheduler](https://github.com/kubernetes-sigs/descheduler)
to rebalance the Pods distribution.
- Pods matched on tainted nodes are respected.
See [Issue 80921](https://github.com/kubernetes/kubernetes/issues/80921).
- The scheduler doesn't have prior knowledge of all the zones or other topology
domains that a cluster has. They are determined from the existing nodes in the
cluster. This could lead to a problem in autoscaled clusters, when a node pool (or
node group) is scaled to zero nodes, and you're expecting the cluster to scale up,
because, in this case, those topology domains won't be considered until there is
at least one node in them.
You can work around this by using an cluster autoscaling tool that is aware of
Pod topology spread constraints and is also aware of the overall set of topology
domains.
## {{% heading "whatsnext" %}}
- The blog article [Introducing PodTopologySpread](/blog/2020/05/introducing-podtopologyspread/)
explains `maxSkew` in some detail, as well as covering some advanced usage examples.
- Read the [scheduling](/docs/reference/kubernetes-api/workload-resources/pod-v1/#scheduling) section of
the API reference for Pod.

45
content/en/docs/concepts/security/pod-security-policy.md
View File

@ -214,6 +214,9 @@ controller selects policies according to the following criteria:
2. If the pod must be defaulted or mutated, the first PodSecurityPolicy
(ordered by name) to allow the pod is selected.
When a Pod is validated against a PodSecurityPolicy, [a `kubernetes.io/psp` annotation](/docs/reference/labels-annotations-taints/#kubernetes-io-psp)
is added to the Pod, with the name of the PodSecurityPolicy as the annotation value.
{{< note >}}
During update operations (during which mutations to pod specs are disallowed)
only non-mutating PodSecurityPolicies are used to validate the pod.
@ -245,8 +248,7 @@ alias kubectl-user='kubectl --as=system:serviceaccount:psp-example:fake-user -n
### Create a policy and a pod
Define the example PodSecurityPolicy object in a file. This is a policy that
prevents the creation of privileged pods.
This is a policy that prevents the creation of privileged pods.
The name of a PodSecurityPolicy object must be a valid
[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
@ -255,7 +257,7 @@ The name of a PodSecurityPolicy object must be a valid
And create it with kubectl:
```shell
kubectl-admin create -f example-psp.yaml
kubectl-admin create -f https://k8s.io/examples/policy/example-psp.yaml
```
Now, as the unprivileged user, try to create a simple pod:
@ -284,6 +286,11 @@ pod's service account nor `fake-user` have permission to use the new policy:
```shell
kubectl-user auth can-i use podsecuritypolicy/example
```
The output is similar to this:
```
no
```
@ -300,14 +307,27 @@ kubectl-admin create role psp:unprivileged \
--verb=use \
--resource=podsecuritypolicy \
--resource-name=example
role "psp:unprivileged" created
```
```
role "psp:unprivileged" created
```
```shell
kubectl-admin create rolebinding fake-user:psp:unprivileged \
--role=psp:unprivileged \
--serviceaccount=psp-example:fake-user
rolebinding "fake-user:psp:unprivileged" created
```
```
rolebinding "fake-user:psp:unprivileged" created
```
```shell
kubectl-user auth can-i use podsecuritypolicy/example
```
```
yes
```
@ -332,7 +352,20 @@ The output is similar to this
pod "pause" created
```
It works as expected! But any attempts to create a privileged pod should still
It works as expected! You can verify that the pod was validated against the
newly created PodSecurityPolicy:
```shell
kubectl-user get pod pause -o yaml | grep kubernetes.io/psp
```
The output is similar to this
```
kubernetes.io/psp: example
```
But any attempts to create a privileged pod should still
be denied:
```shell

17
content/en/docs/concepts/security/rbac-good-practices.md
View File

@ -24,15 +24,15 @@ The good practices laid out here should be read in conjunction with the general
### Least privilege
Ideally minimal RBAC rights should be assigned to users and service accounts. Only permissions
explicitly required for their operation should be used. Whilst each cluster will be different,
Ideally, minimal RBAC rights should be assigned to users and service accounts. Only permissions
explicitly required for their operation should be used. While each cluster will be different,
some general rules that can be applied are :
- Assign permissions at the namespace level where possible. Use RoleBindings as opposed to
ClusterRoleBindings to give users rights only within a specific namespace.
- Avoid providing wildcard permissions when possible, especially to all resources.
As Kubernetes is an extensible system, providing wildcard access gives rights
not just to all object types presently in the cluster, but also to all future object types
not just to all object types that currently exist in the cluster, but also to all future object types
which are created in the future.
- Administrators should not use `cluster-admin` accounts except where specifically needed.
Providing a low privileged account with
@ -66,7 +66,7 @@ the RBAC rights provided by default can provide opportunities for security harde
In general, changes should not be made to rights provided to `system:` accounts some options
to harden cluster rights exist:
- Review bindings for the `system:unauthenticated` group and remove where possible, as this gives
- Review bindings for the `system:unauthenticated` group and remove them where possible, as this gives
access to anyone who can contact the API server at a network level.
- Avoid the default auto-mounting of service account tokens by setting
`automountServiceAccountToken: false`. For more details, see
@ -129,20 +129,19 @@ PersistentVolumes, and constrained users should use PersistentVolumeClaims to ac
### Access to `proxy` subresource of Nodes
Users with access to the proxy sub-resource of node objects have rights to the Kubelet API,
which allows for command execution on every pod on the node(s) which they have rights to.
which allows for command execution on every pod on the node(s) to which they have rights.
This access bypasses audit logging and admission control, so care should be taken before
granting rights to this resource.
### Escalate verb
Generally the RBAC system prevents users from creating clusterroles with more rights than
they possess. The exception to this is the `escalate` verb. As noted in the
[RBAC documentation](/docs/reference/access-authn-authz/rbac/#restrictions-on-role-creation-or-update),
Generally, the RBAC system prevents users from creating clusterroles with more rights than the user possesses.
The exception to this is the `escalate` verb. As noted in the [RBAC documentation](/docs/reference/access-authn-authz/rbac/#restrictions-on-role-creation-or-update),
users with this right can effectively escalate their privileges.
### Bind verb
Similar to the `escalate` verb, granting users this right allows for bypass of Kubernetes
Similar to the `escalate` verb, granting users this right allows for the bypass of Kubernetes
in-built protections against privilege escalation, allowing users to create bindings to
roles with rights they do not already have.

18
content/en/docs/concepts/services-networking/dual-stack.md
View File

@ -37,7 +37,7 @@ IPv4/IPv6 dual-stack on your Kubernetes cluster provides the following features:
The following prerequisites are needed in order to utilize IPv4/IPv6 dual-stack Kubernetes clusters:
* Kubernetes 1.20 or later
* Kubernetes 1.20 or later
For information about using dual-stack services with earlier
Kubernetes versions, refer to the documentation for that version
@ -95,7 +95,7 @@ set the `.spec.ipFamilyPolicy` field to one of the following values:
If you would like to define which IP family to use for single stack or define the order of IP
families for dual-stack, you can choose the address families by setting an optional field,
`.spec.ipFamilies`, on the Service.
`.spec.ipFamilies`, on the Service.
{{< note >}}
The `.spec.ipFamilies` field is immutable because the `.spec.ClusterIP` cannot be reallocated on a
@ -133,11 +133,11 @@ These examples demonstrate the behavior of various dual-stack Service configurat
address assignments. The field `.spec.ClusterIPs` is the primary field, and contains both assigned
IP addresses; `.spec.ClusterIP` is a secondary field with its value calculated from
`.spec.ClusterIPs`.
* For the `.spec.ClusterIP` field, the control plane records the IP address that is from the
same address family as the first service cluster IP range.
same address family as the first service cluster IP range.
* On a single-stack cluster, the `.spec.ClusterIPs` and `.spec.ClusterIP` fields both only list
one address.
one address.
* On a cluster with dual-stack enabled, specifying `RequireDualStack` in `.spec.ipFamilyPolicy`
behaves the same as `PreferDualStack`.
@ -174,7 +174,7 @@ dual-stack.)
kind: Service
metadata:
labels:
app: MyApp
app.kubernetes.io/name: MyApp
name: my-service
spec:
clusterIP: 10.0.197.123
@ -188,7 +188,7 @@ dual-stack.)
protocol: TCP
targetPort: 80
selector:
app: MyApp
app.kubernetes.io/name: MyApp
type: ClusterIP
status:
loadBalancer: {}
@ -214,7 +214,7 @@ dual-stack.)
kind: Service
metadata:
labels:
app: MyApp
app.kubernetes.io/name: MyApp
name: my-service
spec:
clusterIP: None
@ -228,7 +228,7 @@ dual-stack.)
protocol: TCP
targetPort: 80
selector:
app: MyApp
app.kubernetes.io/name: MyApp
```
#### Switching Services between single-stack and dual-stack

2
content/en/docs/concepts/services-networking/service-traffic-policy.md
View File

@ -43,7 +43,7 @@ metadata:
name: my-service
spec:
selector:
app: MyApp
app.kubernetes.io/name: MyApp
ports:
- protocol: TCP
port: 80

45
content/en/docs/concepts/services-networking/service.md
View File

@ -75,7 +75,7 @@ The name of a Service object must be a valid
[RFC 1035 label name](/docs/concepts/overview/working-with-objects/names#rfc-1035-label-names).
For example, suppose you have a set of Pods where each listens on TCP port 9376
and contains a label `app=MyApp`:
and contains a label `app.kubernetes.io/name=MyApp`:
```yaml
apiVersion: v1
@ -84,7 +84,7 @@ metadata:
name: my-service
spec:
selector:
app: MyApp
app.kubernetes.io/name: MyApp
ports:
- protocol: TCP
port: 80
@ -92,7 +92,7 @@ spec:
```
This specification creates a new Service object named "my-service", which
targets TCP port 9376 on any Pod with the `app=MyApp` label.
targets TCP port 9376 on any Pod with the `app.kubernetes.io/name=MyApp` label.
Kubernetes assigns this Service an IP address (sometimes called the "cluster IP"),
which is used by the Service proxies
@ -126,7 +126,7 @@ spec:
ports:
- containerPort: 80
name: http-web-svc
---
apiVersion: v1
kind: Service
@ -144,9 +144,9 @@ spec:
This works even if there is a mixture of Pods in the Service using a single
configured name, with the same network protocol available via different
port numbers. This offers a lot of flexibility for deploying and evolving
your Services. For example, you can change the port numbers that Pods expose
configured name, with the same network protocol available via different
port numbers. This offers a lot of flexibility for deploying and evolving
your Services. For example, you can change the port numbers that Pods expose
in the next version of your backend software, without breaking clients.
The default protocol for Services is TCP; you can also use any other
@ -159,7 +159,7 @@ Each port definition can have the same `protocol`, or a different one.
### Services without selectors
Services most commonly abstract access to Kubernetes Pods thanks to the selector,
but when used with a corresponding Endpoints object and without a selector, the Service can abstract other kinds of backends,
but when used with a corresponding Endpoints object and without a selector, the Service can abstract other kinds of backends,
including ones that run outside the cluster. For example:
* You want to have an external database cluster in production, but in your
@ -222,10 +222,10 @@ In the example above, traffic is routed to the single endpoint defined in
the YAML: `192.0.2.42:9376` (TCP).
{{< note >}}
The Kubernetes API server does not allow proxying to endpoints that are not mapped to
pods. Actions such as `kubectl proxy <service-name>` where the service has no
selector will fail due to this constraint. This prevents the Kubernetes API server
from being used as a proxy to endpoints the caller may not be authorized to access.
The Kubernetes API server does not allow proxying to endpoints that are not mapped to
pods. Actions such as `kubectl proxy <service-name>` where the service has no
selector will fail due to this constraint. This prevents the Kubernetes API server
from being used as a proxy to endpoints the caller may not be authorized to access.
{{< /note >}}
An ExternalName Service is a special case of Service that does not have
@ -289,7 +289,7 @@ There are a few reasons for using proxying for Services:
Later in this page you can read about various kube-proxy implementations work. Overall,
you should note that, when running `kube-proxy`, kernel level rules may be
modified (for example, iptables rules might get created), which won't get cleaned up,
modified (for example, iptables rules might get created), which won't get cleaned up,
in some cases until you reboot. Thus, running kube-proxy is something that should
only be done by an administrator which understands the consequences of having a
low level, privileged network proxying service on a computer. Although the `kube-proxy`
@ -423,7 +423,7 @@ metadata:
name: my-service
spec:
selector:
app: MyApp
app.kubernetes.io/name: MyApp
ports:
- name: http
protocol: TCP
@ -636,7 +636,7 @@ to specify IP address ranges that kube-proxy should consider as local to this no
For example, if you start kube-proxy with the `--nodeport-addresses=127.0.0.0/8` flag,
kube-proxy only selects the loopback interface for NodePort Services.
The default for `--nodeport-addresses` is an empty list.
The default for `--nodeport-addresses` is an empty list.
his means that kube-proxy should consider all available network interfaces for NodePort.
(That's also compatible with earlier Kubernetes releases).
@ -666,7 +666,7 @@ metadata:
spec:
type: NodePort
selector:
app: MyApp
app.kubernetes.io/name: MyApp
ports:
# By default and for convenience, the `targetPort` is set to the same value as the `port` field.
- port: 80
@ -692,7 +692,7 @@ metadata:
name: my-service
spec:
selector:
app: MyApp
app.kubernetes.io/name: MyApp
ports:
- protocol: TCP
port: 80
@ -765,13 +765,13 @@ You must explicitly remove the `nodePorts` entry in every Service port to de-all
`spec.loadBalancerClass` enables you to use a load balancer implementation other than the cloud provider default.
By default, `spec.loadBalancerClass` is `nil` and a `LoadBalancer` type of Service uses
the cloud provider's default load balancer implementation if the cluster is configured with
a cloud provider using the `--cloud-provider` component flag.
a cloud provider using the `--cloud-provider` component flag.
If `spec.loadBalancerClass` is specified, it is assumed that a load balancer
implementation that matches the specified class is watching for Services.
Any default load balancer implementation (for example, the one provided by
the cloud provider) will ignore Services that have this field set.
`spec.loadBalancerClass` can be set on a Service of type `LoadBalancer` only.
Once set, it cannot be changed.
Once set, it cannot be changed.
The value of `spec.loadBalancerClass` must be a label-style identifier,
with an optional prefix such as "`internal-vip`" or "`example.com/internal-vip`".
Unprefixed names are reserved for end-users.
@ -1073,7 +1073,7 @@ There are other annotations to manage Classic Elastic Load Balancers that are de
# A list of existing security groups to be configured on the ELB created. Unlike the annotation
# service.beta.kubernetes.io/aws-load-balancer-extra-security-groups, this replaces all other
# security groups previously assigned to the ELB and also overrides the creation
# security groups previously assigned to the ELB and also overrides the creation
# of a uniquely generated security group for this ELB.
# The first security group ID on this list is used as a source to permit incoming traffic to
# target worker nodes (service traffic and health checks).
@ -1087,7 +1087,7 @@ There are other annotations to manage Classic Elastic Load Balancers that are de
# generated security group in place, this ensures that every ELB
# has a unique security group ID and a matching permit line to allow traffic to the target worker nodes
# (service traffic and health checks).
# Security groups defined here can be shared between services.
# Security groups defined here can be shared between services.
service.beta.kubernetes.io/aws-load-balancer-extra-security-groups: "sg-53fae93f,sg-42efd82e"
# A comma separated list of key-value pairs which are used
@ -1263,7 +1263,7 @@ metadata:
name: my-service
spec:
selector:
app: MyApp
app.kubernetes.io/name: MyApp
ports:
- name: http
protocol: TCP
@ -1481,4 +1481,3 @@ followed by the data from the client.
* Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/)
* Read about [Ingress](/docs/concepts/services-networking/ingress/)
* Read about [EndpointSlices](/docs/concepts/services-networking/endpoint-slices/)

2
content/en/docs/concepts/storage/dynamic-provisioning.md
View File

@ -116,7 +116,7 @@ can enable this behavior by:
is enabled on the API server.
An administrator can mark a specific `StorageClass` as default by adding the
`storageclass.kubernetes.io/is-default-class` annotation to it.
`storageclass.kubernetes.io/is-default-class` [annotation](/docs/reference/labels-annotations-taints/#storageclass-kubernetes-io-is-default-class) to it.
When a default `StorageClass` exists in a cluster and a user creates a
`PersistentVolumeClaim` with `storageClassName` unspecified, the
`DefaultStorageClass` admission controller automatically adds the

4
content/en/docs/concepts/windows/user-guide.md
View File

@ -105,12 +105,12 @@ port 80 of the container directly to the Service.
* Node-to-pod communication across the network, `curl` port 80 of your pod IPs from the Linux control plane node
to check for a web server response
* Pod-to-pod communication, ping between pods (and across hosts, if you have more than one Windows node)
using docker exec or kubectl exec
using `docker exec` or `kubectl exec`
* Service-to-pod communication, `curl` the virtual service IP (seen under `kubectl get services`)
from the Linux control plane node and from individual pods
* Service discovery, `curl` the service name with the Kubernetes [default DNS suffix](/docs/concepts/services-networking/dns-pod-service/#services)
* Inbound connectivity, `curl` the NodePort from the Linux control plane node or machines outside of the cluster
* Outbound connectivity, `curl` external IPs from inside the pod using kubectl exec
* Outbound connectivity, `curl` external IPs from inside the pod using `kubectl exec`
{{< note >}}
Windows container hosts are not able to access the IP of services scheduled on them due to current platform limitations of the Windows networking stack.

2
content/en/docs/concepts/workloads/pods/_index.md
View File

@ -320,12 +320,12 @@ in the Pod Lifecycle documentation.
* Learn about the [lifecycle of a Pod](/docs/concepts/workloads/pods/pod-lifecycle/).
* Learn about [RuntimeClass](/docs/concepts/containers/runtime-class/) and how you can use it to
configure different Pods with different container runtime configurations.
* Read about [Pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/).
* Read about [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/) and how you can use it to manage application availability during disruptions.
* Pod is a top-level resource in the Kubernetes REST API.
The {{< api-reference page="workload-resources/pod-v1" >}}
object definition describes the object in detail.
* [The Distributed System Toolkit: Patterns for Composite Containers](/blog/2015/06/the-distributed-system-toolkit-patterns/) explains common layouts for Pods with more than one container.
* Read about [Pod topology spread constraints](/docs/concepts/scheduling-eviction/topology-spread-constraints/)
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:

6
content/en/docs/concepts/workloads/pods/init-containers.md
View File

@ -28,7 +28,7 @@ Init containers are exactly like regular containers, except:
* Init containers always run to completion.
* Each init container must complete successfully before the next one starts.
If a Pod's init container fails, the kubelet repeatedly restarts that init container until it succeeds.
If a Pod's init container fails, the kubelet repeatedly restarts that init container until it succeeds.
However, if the Pod has a `restartPolicy` of Never, and an init container fails during startup of that Pod, Kubernetes treats the overall Pod as failed.
To specify an init container for a Pod, add the `initContainers` field into
@ -115,7 +115,7 @@ kind: Pod
metadata:
name: myapp-pod
labels:
app: myapp
app.kubernetes.io/name: MyApp
spec:
containers:
- name: myapp-container
@ -159,7 +159,7 @@ The output is similar to this:
Name: myapp-pod
Namespace: default
[...]
Labels: app=myapp
Labels: app.kubernetes.io/name=MyApp
Status: Pending
[...]
Init Containers:

421
content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
View File

@ -1,421 +0,0 @@
---
title: Pod Topology Spread Constraints
content_type: concept
weight: 40
---
<!-- overview -->
You can use _topology spread constraints_ to control how {{< glossary_tooltip text="Pods" term_id="Pod" >}} are spread across your cluster among failure-domains such as regions, zones, nodes, and other user-defined topology domains. This can help to achieve high availability as well as efficient resource utilization.
<!-- body -->
## Prerequisites
### Node Labels
Topology spread constraints rely on node labels to identify the topology domain(s) that each Node is in. For example, a Node might have labels: `node=node1,zone=us-east-1a,region=us-east-1`
Suppose you have a 4-node cluster with the following labels:
```
NAME STATUS ROLES AGE VERSION LABELS
node1 Ready <none> 4m26s v1.16.0 node=node1,zone=zoneA
node2 Ready <none> 3m58s v1.16.0 node=node2,zone=zoneA
node3 Ready <none> 3m17s v1.16.0 node=node3,zone=zoneB
node4 Ready <none> 2m43s v1.16.0 node=node4,zone=zoneB
```
Then the cluster is logically viewed as below:
{{<mermaid>}}
graph TB
subgraph "zoneB"
n3(Node3)
n4(Node4)
end
subgraph "zoneA"
n1(Node1)
n2(Node2)
end
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
class n1,n2,n3,n4 k8s;
class zoneA,zoneB cluster;
{{< /mermaid >}}
Instead of manually applying labels, you can also reuse the [well-known labels](/docs/reference/labels-annotations-taints/) that are created and populated automatically on most clusters.
## Spread Constraints for Pods
### API
The API field `pod.spec.topologySpreadConstraints` is defined as below:
```yaml
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
topologySpreadConstraints:
- maxSkew: <integer>
minDomains: <integer>
topologyKey: <string>
whenUnsatisfiable: <string>
labelSelector: <object>
```
You can define one or multiple `topologySpreadConstraint` to instruct the kube-scheduler how to place each incoming Pod in relation to the existing Pods across your cluster. The fields are:
- **maxSkew** describes the degree to which Pods may be unevenly distributed.
It must be greater than zero. Its semantics differs according to the value of `whenUnsatisfiable`:
- when `whenUnsatisfiable` equals to "DoNotSchedule", `maxSkew` is the maximum
permitted difference between the number of matching pods in the target
topology and the global minimum
(the minimum number of pods that match the label selector in a topology domain.
For example, if you have 3 zones with 0, 2 and 3 matching pods respectively,
The global minimum is 0).
- when `whenUnsatisfiable` equals to "ScheduleAnyway", scheduler gives higher
precedence to topologies that would help reduce the skew.
- **minDomains** indicates a minimum number of eligible domains.
A domain is a particular instance of a topology. An eligible domain is a domain whose
nodes match the node selector.
- The value of `minDomains` must be greater than 0, when specified.
- When the number of eligible domains with match topology keys is less than `minDomains`,
Pod topology spread treats "global minimum" as 0, and then the calculation of `skew` is performed.
The "global minimum" is the minimum number of matching Pods in an eligible domain,
or zero if the number of eligible domains is less than `minDomains`.
- When the number of eligible domains with matching topology keys equals or is greater than
`minDomains`, this value has no effect on scheduling.
- When `minDomains` is nil, the constraint behaves as if `minDomains` is 1.
- When `minDomains` is not nil, the value of `whenUnsatisfiable` must be "`DoNotSchedule`".
{{< note >}}
The `minDomains` field is an alpha field added in 1.24. You have to enable the
`MinDomainsInPodToplogySpread` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
in order to use it.
{{< /note >}}
- **topologyKey** is the key of node labels. If two Nodes are labelled with this key and have identical values for that label, the scheduler treats both Nodes as being in the same topology. The scheduler tries to place a balanced number of Pods into each topology domain.
- **whenUnsatisfiable** indicates how to deal with a Pod if it doesn't satisfy the spread constraint:
- `DoNotSchedule` (default) tells the scheduler not to schedule it.
- `ScheduleAnyway` tells the scheduler to still schedule it while prioritizing nodes that minimize the skew.
- **labelSelector** is used to find matching Pods. Pods that match this label selector are counted to determine the number of Pods in their corresponding topology domain. See [Label Selectors](/docs/concepts/overview/working-with-objects/labels/#label-selectors) for more details.
When a Pod defines more than one `topologySpreadConstraint`, those constraints are ANDed: The kube-scheduler looks for a node for the incoming Pod that satisfies all the constraints.
You can read more about this field by running `kubectl explain Pod.spec.topologySpreadConstraints`.
### Example: One TopologySpreadConstraint
Suppose you have a 4-node cluster where 3 Pods labeled `foo:bar` are located in node1, node2 and node3 respectively:
{{<mermaid>}}
graph BT
subgraph "zoneB"
p3(Pod) --> n3(Node3)
n4(Node4)
end
subgraph "zoneA"
p1(Pod) --> n1(Node1)
p2(Pod) --> n2(Node2)
end
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
class n1,n2,n3,n4,p1,p2,p3 k8s;
class zoneA,zoneB cluster;
{{< /mermaid >}}
If we want an incoming Pod to be evenly spread with existing Pods across zones, the spec can be given as:
{{< codenew file="pods/topology-spread-constraints/one-constraint.yaml" >}}
`topologyKey: zone` implies the even distribution will only be applied to the nodes which have label pair "zone:&lt;any value&gt;" present. `whenUnsatisfiable: DoNotSchedule` tells the scheduler to let it stay pending if the incoming Pod can't satisfy the constraint.
If the scheduler placed this incoming Pod into "zoneA", the Pods distribution would become [3, 1], hence the actual skew is 2 (3 - 1) - which violates `maxSkew: 1`. In this example, the incoming Pod can only be placed into "zoneB":
{{<mermaid>}}
graph BT
subgraph "zoneB"
p3(Pod) --> n3(Node3)
p4(mypod) --> n4(Node4)
end
subgraph "zoneA"
p1(Pod) --> n1(Node1)
p2(Pod) --> n2(Node2)
end
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
class n1,n2,n3,n4,p1,p2,p3 k8s;
class p4 plain;
class zoneA,zoneB cluster;
{{< /mermaid >}}
OR
{{<mermaid>}}
graph BT
subgraph "zoneB"
p3(Pod) --> n3(Node3)
p4(mypod) --> n3
n4(Node4)
end
subgraph "zoneA"
p1(Pod) --> n1(Node1)
p2(Pod) --> n2(Node2)
end
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
class n1,n2,n3,n4,p1,p2,p3 k8s;
class p4 plain;
class zoneA,zoneB cluster;
{{< /mermaid >}}
You can tweak the Pod spec to meet various kinds of requirements:
- Change `maxSkew` to a bigger value like "2" so that the incoming Pod can be placed into "zoneA" as well.
- Change `topologyKey` to "node" so as to distribute the Pods evenly across nodes instead of zones. In the above example, if `maxSkew` remains "1", the incoming Pod can only be placed onto "node4".
- Change `whenUnsatisfiable: DoNotSchedule` to `whenUnsatisfiable: ScheduleAnyway` to ensure the incoming Pod to be always schedulable (suppose other scheduling APIs are satisfied). However, it's preferred to be placed onto the topology domain which has fewer matching Pods. (Be aware that this preferability is jointly normalized with other internal scheduling priorities like resource usage ratio, etc.)
### Example: Multiple TopologySpreadConstraints
This builds upon the previous example. Suppose you have a 4-node cluster where 3 Pods labeled `foo:bar` are located in node1, node2 and node3 respectively:
{{<mermaid>}}
graph BT
subgraph "zoneB"
p3(Pod) --> n3(Node3)
n4(Node4)
end
subgraph "zoneA"
p1(Pod) --> n1(Node1)
p2(Pod) --> n2(Node2)
end
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
class n1,n2,n3,n4,p1,p2,p3 k8s;
class p4 plain;
class zoneA,zoneB cluster;
{{< /mermaid >}}
You can use 2 TopologySpreadConstraints to control the Pods spreading on both zone and node:
{{< codenew file="pods/topology-spread-constraints/two-constraints.yaml" >}}
In this case, to match the first constraint, the incoming Pod can only be placed into "zoneB"; while in terms of the second constraint, the incoming Pod can only be placed onto "node4". Then the results of 2 constraints are ANDed, so the only viable option is to place on "node4".
Multiple constraints can lead to conflicts. Suppose you have a 3-node cluster across 2 zones:
{{<mermaid>}}
graph BT
subgraph "zoneB"
p4(Pod) --> n3(Node3)
p5(Pod) --> n3
end
subgraph "zoneA"
p1(Pod) --> n1(Node1)
p2(Pod) --> n1
p3(Pod) --> n2(Node2)
end
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
class n1,n2,n3,n4,p1,p2,p3,p4,p5 k8s;
class zoneA,zoneB cluster;
{{< /mermaid >}}
If you apply "two-constraints.yaml" to this cluster, you will notice "mypod" stays in `Pending` state. This is because: to satisfy the first constraint, "mypod" can only placed into "zoneB"; while in terms of the second constraint, "mypod" can only be placed onto "node2". Then a joint result of "zoneB" and "node2" returns nothing.
To overcome this situation, you can either increase the `maxSkew` or modify one of the constraints to use `whenUnsatisfiable: ScheduleAnyway`.
### Interaction With Node Affinity and Node Selectors
The scheduler will skip the non-matching nodes from the skew calculations if the incoming Pod has `spec.nodeSelector` or `spec.affinity.nodeAffinity` defined.
### Example: TopologySpreadConstraints with NodeAffinity
Suppose you have a 5-node cluster ranging from zoneA to zoneC:
{{<mermaid>}}
graph BT
subgraph "zoneB"
p3(Pod) --> n3(Node3)
n4(Node4)
end
subgraph "zoneA"
p1(Pod) --> n1(Node1)
p2(Pod) --> n2(Node2)
end
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
class n1,n2,n3,n4,p1,p2,p3 k8s;
class p4 plain;
class zoneA,zoneB cluster;
{{< /mermaid >}}
{{<mermaid>}}
graph BT
subgraph "zoneC"
n5(Node5)
end
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
class n5 k8s;
class zoneC cluster;
{{< /mermaid >}}
and you know that "zoneC" must be excluded. In this case, you can compose the yaml as below, so that "mypod" will be placed into "zoneB" instead of "zoneC". Similarly `spec.nodeSelector` is also respected.
{{< codenew file="pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml" >}}
The scheduler doesn't have prior knowledge of all the zones or other topology domains that a cluster has. They are determined from the existing nodes in the cluster. This could lead to a problem in autoscaled clusters, when a node pool (or node group) is scaled to zero nodes and the user is expecting them to scale up, because, in this case, those topology domains won't be considered until there is at least one node in them.
### Other Noticeable Semantics
There are some implicit conventions worth noting here:
- Only the Pods holding the same namespace as the incoming Pod can be matching candidates.
- The scheduler will bypass the nodes without `topologySpreadConstraints[*].topologyKey` present. This implies that:
1. the Pods located on those nodes do not impact `maxSkew` calculation - in the above example, suppose "node1" does not have label "zone", then the 2 Pods will be disregarded, hence the incoming Pod will be scheduled into "zoneA".
2. the incoming Pod has no chances to be scheduled onto such nodes - in the above example, suppose a "node5" carrying label `{zone-typo: zoneC}` joins the cluster, it will be bypassed due to the absence of label key "zone".
- Be aware of what will happen if the incoming Pod's `topologySpreadConstraints[*].labelSelector` doesn't match its own labels. In the above example, if we remove the incoming Pod's labels, it can still be placed into "zoneB" since the constraints are still satisfied. However, after the placement, the degree of imbalance of the cluster remains unchanged - it's still zoneA having 2 Pods which hold label {foo:bar}, and zoneB having 1 Pod which holds label {foo:bar}. So if this is not what you expect, we recommend the workload's `topologySpreadConstraints[*].labelSelector` to match its own labels.
### Cluster-level default constraints
It is possible to set default topology spread constraints for a cluster. Default
topology spread constraints are applied to a Pod if, and only if:
- It doesn't define any constraints in its `.spec.topologySpreadConstraints`.
- It belongs to a service, replication controller, replica set or stateful set.
Default constraints can be set as part of the `PodTopologySpread` plugin args
in a [scheduling profile](/docs/reference/scheduling/config/#profiles).
The constraints are specified with the same [API above](#api), except that
`labelSelector` must be empty. The selectors are calculated from the services,
replication controllers, replica sets or stateful sets that the Pod belongs to.
An example configuration might look like follows:
```yaml
apiVersion: kubescheduler.config.k8s.io/v1beta3
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: default-scheduler
pluginConfig:
- name: PodTopologySpread
args:
defaultConstraints:
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: ScheduleAnyway
defaultingType: List
```
{{< note >}}
[`SelectorSpread` plugin](/docs/reference/scheduling/config/#scheduling-plugins)
is disabled by default. It's recommended to use `PodTopologySpread` to achieve similar
behavior.
{{< /note >}}
#### Built-in default constraints {#internal-default-constraints}
{{< feature-state for_k8s_version="v1.24" state="stable" >}}
If you don't configure any cluster-level default constraints for pod topology spreading,
then kube-scheduler acts as if you specified the following default topology constraints:
```yaml
defaultConstraints:
- maxSkew: 3
topologyKey: "kubernetes.io/hostname"
whenUnsatisfiable: ScheduleAnyway
- maxSkew: 5
topologyKey: "topology.kubernetes.io/zone"
whenUnsatisfiable: ScheduleAnyway
```
Also, the legacy `SelectorSpread` plugin, which provides an equivalent behavior,
is disabled by default.
{{< note >}}
The `PodTopologySpread` plugin does not score the nodes that don't have
the topology keys specified in the spreading constraints. This might result
in a different default behavior compared to the legacy `SelectorSpread` plugin when
using the default topology constraints.
If your nodes are not expected to have **both** `kubernetes.io/hostname` and
`topology.kubernetes.io/zone` labels set, define your own constraints
instead of using the Kubernetes defaults.
{{< /note >}}
If you don't want to use the default Pod spreading constraints for your cluster,
you can disable those defaults by setting `defaultingType` to `List` and leaving
empty `defaultConstraints` in the `PodTopologySpread` plugin configuration:
```yaml
apiVersion: kubescheduler.config.k8s.io/v1beta3
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: default-scheduler
pluginConfig:
- name: PodTopologySpread
args:
defaultConstraints: []
defaultingType: List
```
## Comparison with PodAffinity/PodAntiAffinity
In Kubernetes, directives related to "Affinity" control how Pods are
scheduled - more packed or more scattered.
- For `PodAffinity`, you can try to pack any number of Pods into qualifying
topology domain(s)
- For `PodAntiAffinity`, only one Pod can be scheduled into a
single topology domain.
For finer control, you can specify topology spread constraints to distribute
Pods across different topology domains - to achieve either high availability or
cost-saving. This can also help on rolling update workloads and scaling out
replicas smoothly. See
[Motivation](https://github.com/kubernetes/enhancements/tree/master/keps/sig-scheduling/895-pod-topology-spread#motivation)
for more details.
## Known Limitations
- There's no guarantee that the constraints remain satisfied when Pods are removed. For example, scaling down a Deployment may result in imbalanced Pods distribution.
You can use [Descheduler](https://github.com/kubernetes-sigs/descheduler) to rebalance the Pods distribution.
- Pods matched on tainted nodes are respected. See [Issue 80921](https://github.com/kubernetes/kubernetes/issues/80921)
## {{% heading "whatsnext" %}}
- [Blog: Introducing PodTopologySpread](/blog/2020/05/introducing-podtopologyspread/)
explains `maxSkew` in details, as well as bringing up some advanced usage examples.

2
content/en/docs/contribute/style/diagram-guide.md
View File

@ -438,7 +438,7 @@ Note that the live editor doesn't recognize Hugo shortcodes.
### Example 1 - Pod topology spread constraints
Figure 6 shows the diagram appearing in the
[Pod topology pread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/#node-labels)
[Pod topology spread constraints](/docs/concepts/scheduling-eviction/topology-spread-constraints/#node-labels)
page.
{{< mermaid >}}

34
content/en/docs/contribute/style/style-guide.md
View File

@ -46,10 +46,6 @@ When you refer specifically to interacting with an API object, use [UpperCamelCa
When you are generally discussing an API object, use [sentence-style capitalization](https://docs.microsoft.com/en-us/style-guide/text-formatting/using-type/use-sentence-style-capitalization).
You may use the word "resource", "API", or "object" to clarify a Kubernetes resource type in a sentence.
Don't split an API object name into separate words. For example, use PodTemplateList, not Pod Template List.
The following examples focus on capitalization. For more information about formatting API object names, review the related guidance on [Code Style](#code-style-inline-code).
{{< table caption = "Do and Don't - Use Pascal case for API objects" >}}
@ -187,6 +183,36 @@ Set the value of `image` to nginx:1.16. | Set the value of `image` to `nginx:1.1
Set the value of the `replicas` field to 2. | Set the value of the `replicas` field to `2`.
{{< /table >}}
## Referring to Kubernetes API resources
This section talks about how we reference API resources in the documentation.
### Clarification about "resource"
Kubernetes uses the word "resource" to refer to API resources, such as `pod`, `deployment`, and so on. We also use "resource" to talk about CPU and memory requests and limits. Always refer to API resources as "API resources" to avoid confusion with CPU and memory resources.
### When to use Kubernetes API terminologies
The different Kubernetes API terminologies are:
- Resource type: the name used in the API URL (such as `pods`, `namespaces`)
- Resource: a single instance of a resource type (such as `pod`, `secret`)
- Object: a resource that serves as a "record of intent". An object is a desired state for a specific part of your cluster, which the Kubernetes control plane tries to maintain.
Always use "resource" or "object" when referring to an API resource in docs. For example, use "a `Secret` object" over just "a `Secret`".
### API resource names
Always format API resource names using [UpperCamelCase](https://en.wikipedia.org/wiki/Camel_case), also known as PascalCase, and code formatting.
For inline code in an HTML document, use the `<code>` tag. In a Markdown document, use the backtick (`` ` ``).
Don't split an API object name into separate words. For example, use `PodTemplateList`, not Pod Template List.
For more information about PascalCase and code formatting, please review the related guidance on [Use upper camel case for API objects](/docs/contribute/style/style-guide/#use-upper-camel-case-for-api-objects) and [Use code style for inline code, commands, and API objects](/docs/contribute/style/style-guide/#code-style-inline-code).
For more information about Kubernetes API terminologies, please review the related guidance on [Kubernetes API terminology](/docs/reference/using-api/api-concepts/#standard-api-terminology).
## Code snippet formatting
### Don't include the command prompt

2
content/en/docs/reference/_index.md
View File

@ -77,7 +77,7 @@ operator to use or manage a cluster.
* [kube-apiserver configuration (v1alpha1)](/docs/reference/config-api/apiserver-config.v1alpha1/)
* [kube-apiserver configuration (v1)](/docs/reference/config-api/apiserver-config.v1/)
* [kube-apiserver encryption (v1)](/docs/reference/config-api/apiserver-encryption.v1/)
* [kube-apiserver event rate limit (v1alpha1)](/docs/reference/config-api/apiserver-eventratelimit.v1/)
* [kube-apiserver event rate limit (v1alpha1)](/docs/reference/config-api/apiserver-eventratelimit.v1alpha1/)
* [kubelet configuration (v1alpha1)](/docs/reference/config-api/kubelet-config.v1alpha1/) and
[kubelet configuration (v1beta1)](/docs/reference/config-api/kubelet-config.v1beta1/)
* [kubelet credential providers (v1alpha1)](/docs/reference/config-api/kubelet-credentialprovider.v1alpha1/)

6
content/en/docs/reference/command-line-tools-reference/feature-gates.md
View File

@ -809,7 +809,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
availability during update per node.
See [Perform a Rolling Update on a DaemonSet](/docs/tasks/manage-daemon/update-daemon-set/).
- `DefaultPodTopologySpread`: Enables the use of `PodTopologySpread` scheduling plugin to do
[default spreading](/docs/concepts/workloads/pods/pod-topology-spread-constraints/#internal-default-constraints).
[default spreading](/docs/concepts/scheduling-eviction/topology-spread-constraints/#internal-default-constraints).
- `DelegateFSGroupToCSIDriver`: If supported by the CSI driver, delegates the
role of applying `fsGroup` from a Pod's `securityContext` to the driver by
passing `fsGroup` through the NodeStageVolume and NodePublishVolume CSI calls.
@ -855,7 +855,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
{{< glossary_tooltip text="ephemeral containers" term_id="ephemeral-container" >}}
to running pods.
- `EvenPodsSpread`: Enable pods to be scheduled evenly across topology domains. See
[Pod Topology Spread Constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/).
[Pod Topology Spread Constraints](/docs/concepts/scheduling-eviction/topology-spread-constraints/).
- `ExecProbeTimeout`: Ensure kubelet respects exec probe timeouts.
This feature gate exists in case any of your existing workloads depend on a
now-corrected fault where Kubernetes ignored exec probe timeouts. See
@ -996,7 +996,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
- `MemoryQoS`: Enable memory protection and usage throttle on pod / container using
cgroup v2 memory controller.
- `MinDomainsInPodTopologySpread`: Enable `minDomains` in Pod
[topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/).
[topology spread constraints](/docs/concepts/scheduling-eviction/topology-spread-constraints/).
- `MixedProtocolLBService`: Enable using different protocols in the same `LoadBalancer` type
Service instance.
- `MountContainers`: Enable using utility containers on host as the volume mounter.

2
content/en/docs/reference/glossary/api-eviction.md
View File

@ -22,6 +22,6 @@ When an `Eviction` object is created, the API server terminates the Pod.
API-initiated evictions respect your configured [`PodDisruptionBudgets`](/docs/tasks/run-application/configure-pdb/)
and [`terminationGracePeriodSeconds`](/docs/concepts/workloads/pods/pod-lifecycle#pod-termination).
API-initiated eviction is not the same as [node-pressure eviction](/docs/concepts/scheduling-eviction/eviction/#kubelet-eviction).
API-initiated eviction is not the same as [node-pressure eviction](/docs/concepts/scheduling-eviction/node-pressure-eviction/).
* See [API-initiated eviction](/docs/concepts/scheduling-eviction/api-eviction/) for more information.

10
content/en/docs/reference/labels-annotations-taints/_index.md
View File

@ -618,6 +618,16 @@ or updating objects that contain Pod templates, such as Deployments, Jobs, State
See [Enforcing Pod Security at the Namespace Level](/docs/concepts/security/pod-security-admission)
for more information.
### kubernetes.io/psp (deprecated) {#kubernetes-io-psp}
Example: `kubernetes.io/psp: restricted`
This annotation is only relevant if you are using [PodSecurityPolicies](/docs/concepts/security/pod-security-policy/).
When the PodSecurityPolicy admission controller admits a Pod, the admission controller
modifies the Pod to have this annotation.
The value of the annotation is the name of the PodSecurityPolicy that was used for validation.
### seccomp.security.alpha.kubernetes.io/pod (deprecated) {#seccomp-security-alpha-kubernetes-io-pod}
This annotation has been deprecated since Kubernetes v1.19 and will become non-functional in v1.25.

2
content/en/docs/reference/scheduling/config.md
View File

@ -123,7 +123,7 @@ extension points:
and [node affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity).
Extension points: `filter`, `score`.
- `PodTopologySpread`: Implements
[Pod topology spread](/docs/concepts/workloads/pods/pod-topology-spread-constraints/).
[Pod topology spread](/docs/concepts/scheduling-eviction/topology-spread-constraints/).
Extension points: `preFilter`, `filter`, `preScore`, `score`.
- `NodeUnschedulable`: Filters out nodes that have `.spec.unschedulable` set to
true.

2
content/en/docs/setup/best-practices/multiple-zones.md
View File

@ -63,7 +63,7 @@ These labels can include
If your cluster spans multiple zones or regions, you can use node labels
in conjunction with
[Pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/)
[Pod topology spread constraints](/docs/concepts/scheduling-eviction/topology-spread-constraints/)
to control how Pods are spread across your cluster among fault domains:
regions, zones, and even specific nodes.
These hints enable the

2
content/en/docs/setup/production-environment/container-runtimes.md
View File

@ -217,7 +217,7 @@ When using kubeadm, manually configure the
#### Overriding the sandbox (pause) image {#override-pause-image-containerd}
In your [containerd config](https://github.com/containerd/cri/blob/master/docs/config.md) you can overwrite the
In your [containerd config](https://github.com/containerd/containerd/blob/main/docs/cri/config.md) you can overwrite the
sandbox image by setting the following config:
```toml

52
content/en/docs/setup/production-environment/tools/kubespray.md
View File

@ -8,19 +8,24 @@ weight: 30
This quickstart helps to install a Kubernetes cluster hosted on GCE, Azure, OpenStack, AWS, vSphere, Equinix Metal (formerly Packet), Oracle Cloud Infrastructure (Experimental) or Baremetal with [Kubespray](https://github.com/kubernetes-sigs/kubespray).
Kubespray is a composition of [Ansible](https://docs.ansible.com/) playbooks, [inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/ansible.md), provisioning tools, and domain knowledge for generic OS/Kubernetes clusters configuration management tasks. Kubespray provides:
Kubespray is a composition of [Ansible](https://docs.ansible.com/) playbooks, [inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/ansible.md#inventory), provisioning tools, and domain knowledge for generic OS/Kubernetes clusters configuration management tasks.
* a highly available cluster
* composable attributes
* support for most popular Linux distributions
* Ubuntu 16.04, 18.04, 20.04, 22.04
* CentOS/RHEL/Oracle Linux 7, 8
* Debian Buster, Jessie, Stretch, Wheezy
* Fedora 34, 35
* Fedora CoreOS
* openSUSE Leap 15
* Flatcar Container Linux by Kinvolk
* continuous integration tests
Kubespray provides:
* Highly available cluster.
* Composable (Choice of the network plugin for instance).
* Supports most popular Linux distributions:
- Flatcar Container Linux by Kinvolk
- Debian Bullseye, Buster, Jessie, Stretch
- Ubuntu 16.04, 18.04, 20.04, 22.04
- CentOS/RHEL 7, 8
- Fedora 34, 35
- Fedora CoreOS
- openSUSE Leap 15.x/Tumbleweed
- Oracle Linux 7, 8
- Alma Linux 8
- Rocky Linux 8
- Amazon Linux 2
* Continuous integration tests.
To choose a tool which best fits your use case, read [this comparison](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md) to
[kubeadm](/docs/reference/setup-tools/kubeadm/) and [kops](/docs/setup/production-environment/tools/kops/).
@ -33,13 +38,13 @@ To choose a tool which best fits your use case, read [this comparison](https://g
Provision servers with the following [requirements](https://github.com/kubernetes-sigs/kubespray#requirements):
* **Ansible v2.11 and python-netaddr are installed on the machine that will run Ansible commands**
* **Jinja 2.11 (or newer) is required to run the Ansible Playbooks**
* The target servers must have access to the Internet in order to pull docker images. Otherwise, additional configuration is required ([See Offline Environment](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/offline-environment.md))
* The target servers are configured to allow **IPv4 forwarding**
* **Your ssh key must be copied** to all the servers in your inventory
* **Firewalls are not managed by kubespray**. You'll need to implement appropriate rules as needed. You should disable your firewall in order to avoid any issues during deployment
* If kubespray is run from a non-root user account, correct privilege escalation method should be configured in the target servers and the `ansible_become` flag or command parameters `--become` or `-b` should be specified
* **Minimum required version of Kubernetes is v1.22**
* **Ansible v2.11+, Jinja 2.11+ and python-netaddr is installed on the machine that will run Ansible commands**
* The target servers must have **access to the Internet** in order to pull docker images. Otherwise, additional configuration is required See ([Offline Environment](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/offline-environment.md))
* The target servers are configured to allow **IPv4 forwarding**.
* If using IPv6 for pods and services, the target servers are configured to allow **IPv6 forwarding**.
* The **firewalls are not managed**, you'll need to implement your own rules the way you used to. in order to avoid any issue during deployment you should disable your firewall.
* If kubespray is run from non-root user account, correct privilege escalation method should be configured in the target servers. Then the `ansible_become` flag or command parameters `--become` or `-b` should be specified.
Kubespray provides the following utilities to help provision your environment:
@ -110,11 +115,10 @@ When running the reset playbook, be sure not to accidentally target your product
## Feedback
* Slack Channel: [#kubespray](https://kubernetes.slack.com/messages/kubespray/) (You can get your invite [here](https://slack.k8s.io/))
* [GitHub Issues](https://github.com/kubernetes-sigs/kubespray/issues)
* Slack Channel: [#kubespray](https://kubernetes.slack.com/messages/kubespray/) (You can get your invite [here](https://slack.k8s.io/)).
* [GitHub Issues](https://github.com/kubernetes-sigs/kubespray/issues).
## {{% heading "whatsnext" %}}
Check out planned work on Kubespray's [roadmap](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/roadmap.md).
* Check out planned work on Kubespray's [roadmap](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/roadmap.md).
* Learn more about [Kubespray](https://github.com/kubernetes-sigs/kubespray).

2
content/en/docs/tasks/administer-cluster/access-cluster-api.md
View File

@ -226,7 +226,7 @@ mvn install
See [https://github.com/kubernetes-client/java/releases](https://github.com/kubernetes-client/java/releases) to see which versions are supported.
The Java client can use the same [kubeconfig file](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
as the kubectl CLI does to locate and authenticate to the API server. See this [example](https://github.com/kubernetes-client/java/blob/master/examples/src/main/java/io/kubernetes/client/examples/KubeConfigFileClientExample.java):
as the kubectl CLI does to locate and authenticate to the API server. See this [example](https://github.com/kubernetes-client/java/blob/master/examples/examples-release-15/src/main/java/io/kubernetes/client/examples/KubeConfigFileClientExample.java):
```java
package io.kubernetes.client.examples;

1
content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md
View File

@ -266,6 +266,7 @@ without compromising the minimum required capacity for running your workloads.
apt-mark unhold kubelet kubectl && \
apt-get update && apt-get install -y kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 && \
apt-mark hold kubelet kubectl
```
{{% /tab %}}
{{% tab name="CentOS, RHEL or Fedora" %}}
```shell

8
content/en/docs/tasks/administer-cluster/kubelet-config-file.md
View File

@ -27,12 +27,12 @@ The configuration file must be a JSON or YAML representation of the parameters
in this struct. Make sure the Kubelet has read permissions on the file.
Here is an example of what this file might look like:
```
```yaml
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
address: "192.168.0.8",
port: 20250,
serializeImagePulls: false,
address: "192.168.0.8"
port: 20250
serializeImagePulls: false
evictionHard:
memory.available: "200Mi"
```

6
content/en/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd.md
View File

@ -5,8 +5,8 @@ content_type: task
---
This task outlines the steps needed to update your container runtime to containerd from Docker. It
is applicable for cluster operators running Kubernetes 1.23 or earlier. Also this covers an
example scenario for migrating from dockershim to containerd and alternative container runtimes
is applicable for cluster operators running Kubernetes 1.23 or earlier. This also covers an
example scenario for migrating from dockershim to containerd. Alternative container runtimes
can be picked from this [page](/docs/setup/production-environment/container-runtimes/).
## {{% heading "prerequisites" %}}
@ -100,7 +100,7 @@ then run the following commands:
Edit the file `/var/lib/kubelet/kubeadm-flags.env` and add the containerd runtime to the flags.
`--container-runtime=remote` and
`--container-runtime-endpoint=unix:///run/containerd/containerd.sock"`.
`--container-runtime-endpoint=unix:///run/containerd/containerd.sock`.
Users using kubeadm should be aware that the `kubeadm` tool stores the CRI socket for each host as
an annotation in the Node object for that host. To change it you can execute the following command

14
content/en/docs/tasks/administer-cluster/nodelocaldns.md
View File

@ -3,7 +3,7 @@ reviewers:
- bowei
- zihongz
- sftim
title: Using NodeLocal DNSCache in Kubernetes clusters
title: Using NodeLocal DNSCache in Kubernetes Clusters
content_type: task
---
@ -40,7 +40,7 @@ hostnames ("`cluster.local`" suffix by default).
[conntrack races](https://github.com/kubernetes/kubernetes/issues/56903)
and avoid UDP DNS entries filling up conntrack table.
* Connections from local caching agent to kube-dns service can be upgraded to TCP.
* Connections from the local caching agent to kube-dns service can be upgraded to TCP.
TCP conntrack entries will be removed on connection close in contrast with
UDP entries that have to timeout
([default](https://www.kernel.org/doc/Documentation/networking/nf_conntrack-sysctl.txt)
@ -52,7 +52,7 @@ hostnames ("`cluster.local`" suffix by default).
* Metrics & visibility into DNS requests at a node level.
* Negative caching can be re-enabled, thereby reducing number of queries to kube-dns service.
* Negative caching can be re-enabled, thereby reducing the number of queries for the kube-dns service.
## Architecture Diagram
@ -66,7 +66,7 @@ This is the path followed by DNS Queries after NodeLocal DNSCache is enabled:
{{< note >}}
The local listen IP address for NodeLocal DNSCache can be any address that
can be guaranteed to not collide with any existing IP in your cluster.
It's recommended to use an address with a local scope, per example,
It's recommended to use an address with a local scope, for example,
from the 'link-local' range '169.254.0.0/16' for IPv4 or from the
'Unique Local Address' range in IPv6 'fd00::/8'.
{{< /note >}}
@ -77,9 +77,9 @@ This feature can be enabled using the following steps:
[`nodelocaldns.yaml`](https://github.com/kubernetes/kubernetes/blob/master/cluster/addons/dns/nodelocaldns/nodelocaldns.yaml)
and save it as `nodelocaldns.yaml.`
* If using IPv6, the CoreDNS configuration file need to enclose all the IPv6 addresses
* If using IPv6, the CoreDNS configuration file needs to enclose all the IPv6 addresses
into square brackets if used in 'IP:Port' format.
If you are using the sample manifest from the previous point, this will require to modify
If you are using the sample manifest from the previous point, this will require you to modify
[the configuration line L70](https://github.com/kubernetes/kubernetes/blob/b2ecd1b3a3192fbbe2b9e348e095326f51dc43dd/cluster/addons/dns/nodelocaldns/nodelocaldns.yaml#L70)
like this: "`health [__PILLAR__LOCAL__DNS__]:8080`"
@ -103,7 +103,7 @@ This feature can be enabled using the following steps:
`__PILLAR__CLUSTER__DNS__` and `__PILLAR__UPSTREAM__SERVERS__` will be populated by
the `node-local-dns` pods.
In this mode, the `node-local-dns` pods listen on both the kube-dns service IP
as well as `<node-local-address>`, so pods can lookup DNS records using either IP address.
as well as `<node-local-address>`, so pods can look up DNS records using either IP address.
* If kube-proxy is running in IPVS mode:

123
content/en/docs/tasks/configmap-secret/managing-secret-using-config-file.md
View File

@ -13,65 +13,70 @@ description: Creating Secret objects using resource configuration file.
<!-- steps -->
## Create the Config file
## Create the Secret {#create-the-config-file}
You can create a Secret in a file first, in JSON or YAML format, and then
create that object. The
You can define the `Secret` object in a manifest first, in JSON or YAML format,
and then create that object. The
[Secret](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)
resource contains two maps: `data` and `stringData`.
The `data` field is used to store arbitrary data, encoded using base64. The
`stringData` field is provided for convenience, and it allows you to provide
Secret data as unencoded strings.
the same data as unencoded strings.
The keys of `data` and `stringData` must consist of alphanumeric characters,
`-`, `_` or `.`.
For example, to store two strings in a Secret using the `data` field, convert
the strings to base64 as follows:
The following example stores two strings in a Secret using the `data` field.
```shell
echo -n 'admin' | base64
```
1. Convert the strings to base64:
The output is similar to:
```shell
echo -n 'admin' | base64
echo -n '1f2d1e2e67df' | base64
```
```
YWRtaW4=
```
{{< note >}}
The serialized JSON and YAML values of Secret data are encoded as base64 strings. Newlines are not valid within these strings and must be omitted. When using the `base64` utility on Darwin/macOS, users should avoid using the `-b` option to split long lines. Conversely, Linux users *should* add the option `-w 0` to `base64` commands or the pipeline `base64 | tr -d '\n'` if the `-w` option is not available.
{{< /note >}}
```shell
echo -n '1f2d1e2e67df' | base64
```
The output is similar to:
The output is similar to:
```
YWRtaW4=
MWYyZDFlMmU2N2Rm
```
```
MWYyZDFlMmU2N2Rm
```
1. Create the manifest:
Write a Secret config file that looks like this:
```yaml
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
username: YWRtaW4=
password: MWYyZDFlMmU2N2Rm
```
```yaml
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
username: YWRtaW4=
password: MWYyZDFlMmU2N2Rm
```
Note that the name of a Secret object must be a valid
[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
Note that the name of a Secret object must be a valid
[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
1. Create the Secret using [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply):
{{< note >}}
The serialized JSON and YAML values of Secret data are encoded as base64
strings. Newlines are not valid within these strings and must be omitted. When
using the `base64` utility on Darwin/macOS, users should avoid using the `-b`
option to split long lines. Conversely, Linux users *should* add the option
`-w 0` to `base64` commands or the pipeline `base64 | tr -d '\n'` if the `-w`
option is not available.
{{< /note >}}
```shell
kubectl apply -f ./secret.yaml
```
The output is similar to:
```
secret/mysecret created
```
To verify that the Secret was created and to decode the Secret data, refer to
[Managing Secrets using kubectl](/docs/tasks/configmap-secret/managing-secret-using-kubectl/#verify-the-secret).
### Specify unencoded data when creating a Secret
For certain scenarios, you may wish to use the `stringData` field instead. This
field allows you to put a non-base64 encoded string directly into the Secret,
@ -103,25 +108,10 @@ stringData:
username: <user>
password: <password>
```
When you retrieve the Secret data, the command returns the encoded values,
and not the plaintext values you provided in `stringData`.
## Create the Secret object
Now create the Secret using [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply):
```shell
kubectl apply -f ./secret.yaml
```
The output is similar to:
```
secret/mysecret created
```
## Check the Secret
The `stringData` field is a write-only convenience field. It is never output when
retrieving Secrets. For example, if you run the following command:
For example, if you run the following command:
```shell
kubectl get secret mysecret -o yaml
@ -143,14 +133,11 @@ metadata:
type: Opaque
```
The commands `kubectl get` and `kubectl describe` avoid showing the contents of a `Secret` by
default. This is to protect the `Secret` from being exposed accidentally to an onlooker,
or from being stored in a terminal log.
To check the actual content of the encoded data, please refer to
[decoding secret](/docs/tasks/configmap-secret/managing-secret-using-kubectl/#decoding-secret).
### Specifying both `data` and `stringData`
If a field, such as `username`, is specified in both `data` and `stringData`,
the value from `stringData` is used. For example, the following Secret definition:
If you specify a field in both `data` and `stringData`, the value from `stringData` is used.
For example, if you define the following Secret:
```yaml
apiVersion: v1
@ -164,7 +151,7 @@ stringData:
username: administrator
```
Results in the following Secret:
The `Secret` object is created as follows:
```yaml
apiVersion: v1
@ -180,7 +167,7 @@ metadata:
type: Opaque
```
Where `YWRtaW5pc3RyYXRvcg==` decodes to `administrator`.
`YWRtaW5pc3RyYXRvcg==` decodes to `administrator`.
## Clean Up

2
content/en/docs/tasks/configmap-secret/managing-secret-using-kubectl.md
View File

@ -113,6 +113,8 @@ The commands `kubectl get` and `kubectl describe` avoid showing the contents
of a `Secret` by default. This is to protect the `Secret` from being exposed
accidentally, or from being stored in a terminal log.
To check the actual content of the encoded data, refer to [Decoding the Secret](#decoding-secret).
## Decoding the Secret {#decoding-secret}
To view the contents of the Secret you created, run the following command:

4
content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md
View File

@ -97,7 +97,7 @@ kubectl describe pod liveness-exec
```
At the bottom of the output, there are messages indicating that the liveness
probes have failed, and the containers have been killed and recreated.
probes have failed, and the failed containers have been killed and recreated.
```
Type Reason Age From Message
@ -117,7 +117,7 @@ Wait another 30 seconds, and verify that the container has been restarted:
kubectl get pod liveness-exec
```
The output shows that `RESTARTS` has been incremented:
The output shows that `RESTARTS` has been incremented. Note that the `RESTARTS` counter increments as soon as a failed container comes back to the running state:
```
NAME READY STATUS RESTARTS AGE

90
content/en/docs/tasks/configure-pod-container/configure-pod-configmap.md
View File

@ -10,7 +10,7 @@ card:
<!-- overview -->
Many applications rely on configuration which is used during either application initialization or runtime.
Most of the times there is a requirement to adjust values assigned to configuration parameters.
ConfigMaps is the kubernetes way to inject application pods with configuration data.
ConfigMaps are the Kubernetes way to inject application pods with configuration data.
ConfigMaps allow you to decouple configuration artifacts from image content to keep containerized applications portable. This page provides a series of usage examples demonstrating how to create ConfigMaps and configure Pods using data stored in ConfigMaps.
@ -623,24 +623,6 @@ Like before, all previous files in the `/etc/config/` directory will be deleted.
You can project keys to specific paths and specific permissions on a per-file
basis. The [Secrets](/docs/concepts/configuration/secret/#using-secrets-as-files-from-a-pod) user guide explains the syntax.
### Optional References
A ConfigMap reference may be marked "optional". If the ConfigMap is non-existent, the mounted volume will be empty. If the ConfigMap exists, but the referenced
key is non-existent the path will be absent beneath the mount point.
### Mounted ConfigMaps are updated automatically
When a mounted ConfigMap is updated, the projected content is eventually updated too. This applies in the case where an optionally referenced ConfigMap comes into
existence after a pod has started.
Kubelet checks whether the mounted ConfigMap is fresh on every periodic sync. However, it uses its local TTL-based cache for getting the current value of the
ConfigMap. As a result, the total delay from the moment when the ConfigMap is updated to the moment when new keys are projected to the pod can be as long as
kubelet sync period (1 minute by default) + TTL of ConfigMaps cache (1 minute by default) in kubelet.
{{< note >}}
A container using a ConfigMap as a [subPath](/docs/concepts/storage/volumes/#using-subpath) volume will not receive ConfigMap updates.
{{< /note >}}
<!-- discussion -->
@ -675,7 +657,7 @@ data:
### Restrictions
- You must create a ConfigMap before referencing it in a Pod specification (unless you mark the ConfigMap as "optional"). If you reference a ConfigMap that doesn't exist, the Pod won't start. Likewise, references to keys that don't exist in the ConfigMap will prevent the pod from starting.
- You must create the `ConfigMap` object before you reference it in a Pod specification. Alternatively, mark the ConfigMap reference as `optional` in the Pod spec (see [Optional ConfigMaps](#optional-configmaps)). If you reference a ConfigMap that doesn't exist and you don't mark the reference as `optional`, the Pod won't start. Similarly, references to keys that don't exist in the ConfigMap will also prevent the Pod from starting, unless you mark the key references as `optional`.
- If you use `envFrom` to define environment variables from ConfigMaps, keys that are considered invalid will be skipped. The pod will be allowed to start, but the invalid names will be recorded in the event log (`InvalidVariableNames`). The log message lists each skipped key. For example:
@ -693,7 +675,75 @@ data:
- You can't use ConfigMaps for {{< glossary_tooltip text="static pods" term_id="static-pod" >}}, because the Kubelet does not support this.
### Optional ConfigMaps
You can mark a reference to a ConfigMap as _optional_ in a Pod specification.
If the ConfigMap doesn't exist, the configuration for which it provides data in the Pod (e.g. environment variable, mounted volume) will be empty.
If the ConfigMap exists, but the referenced key is non-existent the data is also empty.
For example, the following Pod specification marks an environment variable from a ConfigMap as optional:
```yaml
apiVersion: v1
kind: Pod
metadata:
name: dapi-test-pod
spec:
containers:
- name: test-container
image: gcr.io/google_containers/busybox
command: [ "/bin/sh", "-c", "env" ]
env:
- name: SPECIAL_LEVEL_KEY
valueFrom:
configMapKeyRef:
name: a-config
key: akey
optional: true # mark the variable as optional
restartPolicy: Never
```
If you run this pod, and there is no ConfigMap named `a-config`, the output is empty.
If you run this pod, and there is a ConfigMap named `a-config` but that ConfigMap doesn't have
a key named `akey`, the output is also empty. If you do set a value for `akey` in the `a-config`
ConfigMap, this pod prints that value and then terminates.
You can also mark the volumes and files provided by a ConfigMap as optional. Kubernetes always creates the mount paths for the volume, even if the referenced ConfigMap or key doesn't exist. For example, the following
Pod specification marks a volume that references a ConfigMap as optional:
```yaml
apiVersion: v1
kind: Pod
metadata:
name: dapi-test-pod
spec:
containers:
- name: test-container
image: gcr.io/google_containers/busybox
command: [ "/bin/sh", "-c", "ls /etc/config" ]
volumeMounts:
- name: config-volume
mountPath: /etc/config
volumes:
- name: config-volume
configMap:
name: no-config
optional: true # mark the source ConfigMap as optional
restartPolicy: Never
```
### Mounted ConfigMaps are updated automatically
When a mounted ConfigMap is updated, the projected content is eventually updated too. This applies in the case where an optionally referenced ConfigMap comes into
existence after a pod has started.
The kubelet checks whether the mounted ConfigMap is fresh on every periodic sync. However, it uses its local TTL-based cache for getting the current value of the
ConfigMap. As a result, the total delay from the moment when the ConfigMap is updated to the moment when new keys are projected to the pod can be as long as
kubelet sync period (1 minute by default) + TTL of ConfigMaps cache (1 minute by default) in kubelet.
{{< note >}}
A container using a ConfigMap as a [subPath](/docs/concepts/storage/volumes/#using-subpath) volume will not receive ConfigMap updates.
{{< /note >}}
## {{% heading "whatsnext" %}}

6
content/en/docs/tasks/configure-pod-container/configure-service-account.md
View File

@ -29,7 +29,7 @@ When they do, they are authenticated as a particular Service Account (for exampl
<!-- steps -->
## Use the Default Service Account to access the API server.
## Use the Default Service Account to access the API server
When you create a pod, if you do not specify a service account, it is
automatically assigned the `default` service account in the same namespace.
@ -68,7 +68,7 @@ spec:
The pod spec takes precedence over the service account if both specify a `automountServiceAccountToken` value.
## Use Multiple Service Accounts.
## Use Multiple Service Accounts
Every namespace has a default service account resource called `default`.
You can list this and any other serviceAccount resources in the namespace with this command:
@ -136,7 +136,7 @@ You can clean up the service account from this example like this:
kubectl delete serviceaccount/build-robot
```
## Manually create a service account API token.
## Manually create a service account API token
Suppose we have an existing service account named "build-robot" as mentioned above, and we create
a new secret manually.

4
content/en/docs/tasks/debug/debug-application/debug-statefulset.md
View File

@ -24,11 +24,11 @@ This task shows you how to debug a StatefulSet.
## Debugging a StatefulSet
In order to list all the pods which belong to a StatefulSet, which have a label `app=myapp` set on them,
In order to list all the pods which belong to a StatefulSet, which have a label `app.kubernetes.io/name=MyApp` set on them,
you can use the following:
```shell
kubectl get pods -l app=myapp
kubectl get pods -l app.kubernetes.io/name=MyApp
```
If you find that any Pods listed are in `Unknown` or `Terminating` state for an extended period of time,

18
content/en/docs/tasks/network/validate-dual-stack.md
View File

@ -134,7 +134,7 @@ spec:
protocol: TCP
targetPort: 9376
selector:
app: MyApp
app.kubernetes.io/name: MyApp
sessionAffinity: None
type: ClusterIP
status:
@ -158,7 +158,7 @@ apiVersion: v1
kind: Service
metadata:
labels:
app: MyApp
app.kubernetes.io/name: MyApp
name: my-service
spec:
clusterIP: fd00::5118
@ -172,7 +172,7 @@ spec:
protocol: TCP
targetPort: 80
selector:
app: MyApp
app.kubernetes.io/name: MyApp
sessionAffinity: None
type: ClusterIP
status:
@ -187,7 +187,7 @@ Create the following Service that explicitly defines `PreferDualStack` in `.spec
The `kubectl get svc` command will only show the primary IP in the `CLUSTER-IP` field.
```shell
kubectl get svc -l app=MyApp
kubectl get svc -l app.kubernetes.io/name=MyApp
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
my-service ClusterIP 10.0.216.242 <none> 80/TCP 5s
@ -197,15 +197,15 @@ my-service ClusterIP 10.0.216.242 <none> 80/TCP 5s
Validate that the Service gets cluster IPs from the IPv4 and IPv6 address blocks using `kubectl describe`. You may then validate access to the service via the IPs and ports.
```shell
kubectl describe svc -l app=MyApp
kubectl describe svc -l app.kubernetes.io/name=MyApp
```
```
Name: my-service
Namespace: default
Labels: app=MyApp
Labels: app.kubernetes.io/name=MyApp
Annotations: <none>
Selector: app=MyApp
Selector: app.kubernetes.io/name=MyApp
Type: ClusterIP
IP Family Policy: PreferDualStack
IP Families: IPv4,IPv6
@ -220,14 +220,14 @@ Events: <none>
### Create a dual-stack load balanced Service
If the cloud provider supports the provisioning of IPv6 enabled external load balancers, create the following Service with `PreferDualStack` in `.spec.ipFamilyPolicy`, `IPv6` as the first element of the `.spec.ipFamilies` array and the `type` field set to `LoadBalancer`.
If the cloud provider supports the provisioning of IPv6 enabled external load balancers, create the following Service with `PreferDualStack` in `.spec.ipFamilyPolicy`, `IPv6` as the first element of the `.spec.ipFamilies` array and the `type` field set to `LoadBalancer`.
{{< codenew file="service/networking/dual-stack-prefer-ipv6-lb-svc.yaml" >}}
Check the Service:
```shell
kubectl get svc -l app=MyApp
kubectl get svc -l app.kubernetes.io/name=MyApp
```
Validate that the Service receives a `CLUSTER-IP` address from the IPv6 address block along with an `EXTERNAL-IP`. You may then validate access to the service via the IP and port.

10
content/en/docs/tasks/run-application/delete-stateful-set.md
View File

@ -50,10 +50,10 @@ For example:
kubectl delete -f <file.yaml> --cascade=orphan
```
By passing `--cascade=orphan` to `kubectl delete`, the Pods managed by the StatefulSet are left behind even after the StatefulSet object itself is deleted. If the pods have a label `app=myapp`, you can then delete them as follows:
By passing `--cascade=orphan` to `kubectl delete`, the Pods managed by the StatefulSet are left behind even after the StatefulSet object itself is deleted. If the pods have a label `app.kubernetes.io/name=MyApp`, you can then delete them as follows:
```shell
kubectl delete pods -l app=myapp
kubectl delete pods -l app.kubernetes.io/name=MyApp
```
### Persistent Volumes
@ -70,13 +70,13 @@ To delete everything in a StatefulSet, including the associated pods, you can ru
```shell
grace=$(kubectl get pods <stateful-set-pod> --template '{{.spec.terminationGracePeriodSeconds}}')
kubectl delete statefulset -l app=myapp
kubectl delete statefulset -l app.kubernetes.io/name=MyApp
sleep $grace
kubectl delete pvc -l app=myapp
kubectl delete pvc -l app.kubernetes.io/name=MyApp
```
In the example above, the Pods have the label `app=myapp`; substitute your own label as appropriate.
In the example above, the Pods have the label `app.kubernetes.io/name=MyApp`; substitute your own label as appropriate.
### Force deletion of StatefulSet pods

4
content/en/docs/tasks/tls/managing-tls-in-a-cluster.md
View File

@ -18,7 +18,7 @@ draft](https://github.com/ietf-wg-acme/acme/).
{{< note >}}
Certificates created using the `certificates.k8s.io` API are signed by a
[dedicated CA](#a-note-to-cluster-administrators). It is possible to configure your cluster to use the cluster root
[dedicated CA](#configuring-your-cluster-to-provide-signing). It is possible to configure your cluster to use the cluster root
CA for this purpose, but you should never rely on this. Do not assume that
these certificates will validate against the cluster root CA.
{{< /note >}}
@ -42,7 +42,7 @@ install it via your operating system's software sources, or fetch it from
## Trusting TLS in a cluster
Trusting the [custom CA](#a-note-to-cluster-administrators) from an application running as a pod usually requires
Trusting the [custom CA](#configuring-your-cluster-to-provide-signing) from an application running as a pod usually requires
some extra application configuration. You will need to add the CA certificate
bundle to the list of CA certificates that the TLS client or server trusts. For
example, you would do this with a golang TLS config by parsing the certificate

13
content/en/docs/tasks/tools/install-kubectl-linux.md
View File

@ -110,7 +110,11 @@ For example, to download version {{< param "fullversion" >}} on Linux, type:
```shell
sudo apt-get update
sudo apt-get install -y apt-transport-https ca-certificates curl
sudo apt-get install -y ca-certificates curl
```
If you use Debian 9 (stretch) or earlier you would also need to install `apt-transport-https`:
```shell
sudo apt-get install -y apt-transport-https
```
2. Download the Google Cloud public signing key:
@ -134,7 +138,8 @@ For example, to download version {{< param "fullversion" >}} on Linux, type:
{{% /tab %}}
{{< tab name="Red Hat-based distributions" codelang="bash" >}}
{{% tab name="Red Hat-based distributions" %}}
```bash
cat <<EOF | sudo tee /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
@ -144,7 +149,9 @@ gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF
sudo yum install -y kubectl
{{< /tab >}}
```
{{% /tab %}}
{{< /tabs >}}
### Install using other package management

4
content/en/examples/service/networking/dual-stack-default-svc.yaml
View File

@ -3,10 +3,10 @@ kind: Service
metadata:
name: my-service
labels:
app: MyApp
app.kubernetes.io/name: MyApp
spec:
selector:
app: MyApp
app.kubernetes.io/name: MyApp
ports:
- protocol: TCP
port: 80

4
content/en/examples/service/networking/dual-stack-ipfamilies-ipv6.yaml
View File

@ -3,12 +3,12 @@ kind: Service
metadata:
name: my-service
labels:
app: MyApp
app.kubernetes.io/name: MyApp
spec:
ipFamilies:
- IPv6
selector:
app: MyApp
app.kubernetes.io/name: MyApp
ports:
- protocol: TCP
port: 80

4
content/en/examples/service/networking/dual-stack-ipv6-svc.yaml
View File

@ -5,8 +5,8 @@ metadata:
spec:
ipFamily: IPv6
selector:
app: MyApp
app.kubernetes.io/name: MyApp
ports:
- protocol: TCP
port: 80
targetPort: 9376
targetPort: 9376

4
content/en/examples/service/networking/dual-stack-prefer-ipv6-lb-svc.yaml
View File

@ -3,14 +3,14 @@ kind: Service
metadata:
name: my-service
labels:
app: MyApp
app.kubernetes.io/name: MyApp
spec:
ipFamilyPolicy: PreferDualStack
ipFamilies:
- IPv6
type: LoadBalancer
selector:
app: MyApp
app.kubernetes.io/name: MyApp
ports:
- protocol: TCP
port: 80

4
content/en/examples/service/networking/dual-stack-preferred-ipfamilies-svc.yaml
View File

@ -3,14 +3,14 @@ kind: Service
metadata:
name: my-service
labels:
app: MyApp
app.kubernetes.io/name: MyApp
spec:
ipFamilyPolicy: PreferDualStack
ipFamilies:
- IPv6
- IPv4
selector:
app: MyApp
app.kubernetes.io/name: MyApp
ports:
- protocol: TCP
port: 80

4
content/en/examples/service/networking/dual-stack-preferred-svc.yaml
View File

@ -3,11 +3,11 @@ kind: Service
metadata:
name: my-service
labels:
app: MyApp
app.kubernetes.io/name: MyApp
spec:
ipFamilyPolicy: PreferDualStack
selector:
app: MyApp
app.kubernetes.io/name: MyApp
ports:
- protocol: TCP
port: 80

4
content/es/_index.html
View File

@ -41,12 +41,12 @@ Kubernetes es código abierto lo que le brinda la libertad de aprovechar su infr
<button id="desktopShowVideoButton" onclick="kub.showVideo()">Ver vídeo</button>
<br>
<br>
<a href="https://events.linuxfoundation.org/events/kubecon-cloudnativecon-north-america-2019" button id="desktopKCButton">Asista a la KubeCon en San Diego del 18 al 21 de Nov. 2019</a>
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/" button id="desktopKCButton">Asista a la KubeCon en Norte América del 24 al 28 de Octubre 2022</a>
<br>
<br>
<br>
<br>
<a href="https://events.linuxfoundation.org/events/kubecon-cloudnativecon-europe-2020/" button id="desktopKCButton">Asista a la KubeCon en Amsterdam del 30 Marzo al 2 Abril</a>
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe-2023/" button id="desktopKCButton">Asista a la KubeCon en Europa del 17 al 21 de Abril 2023</a>
</div>
<div id="videoPlayer">
<iframe data-url="https://www.youtube.com/embed/H06qrNmGqyE?autoplay=1" frameborder="0" allowfullscreen></iframe>

287
content/es/docs/concepts/services-networking/network-policies.md Normal file
View File

@ -0,0 +1,287 @@
---
reviewers:
- raelga
- electrocucaracha
title: Políticas de red (Network Policies)
content_type: concept
weight: 50
---
<!-- overview -->
Si quieres controlar el tráfico de red a nivel de dirección IP o puerto (capa OSI 3 o 4), puedes considerar el uso de Kubernetes NetworkPolicies para las aplicaciones que corren en tu clúster. Las NetworkPolicies son una estructura enfocada en las aplicaciones que permite establecer cómo un {{< glossary_tooltip text="Pod" term_id="pod">}} puede comunicarse con otras "entidades" (utilizamos la palabra "entidad" para evitar sobrecargar términos más comunes como "Endpoint" o "Service", que tienen connotaciones específicas de Kubernetes) a través de la red. Las NetworkPolicies se aplican a uno o ambos extremos de la conexión a un Pod, sin afectar a otras conexiones.
Las entidades con las que un Pod puede comunicarse son de una combinación de estos 3 tipos:
1. Otros Pods permitidos (excepción: un Pod no puede bloquear el acceso a sí mismo)
2. Namespaces permitidos
3. Bloqueos de IP (excepción: el tráfico hacia y desde el nodo donde se ejecuta un Pod siempre está permitido, independientemente de la dirección IP del Pod o del nodo)
Cuando se define una NetworkPolicy basada en Pods o Namespaces, se utiliza un {{< glossary_tooltip text="Selector" term_id="selector">}} para especificar qué tráfico se permite desde y hacia los Pod(s) que coinciden con el selector.
Por otro lado, cuando se crean NetworkPolicies basadas en IP, se definen políticas basadas en bloques de IP (rangos CIDR).
<!-- body -->
## Prerrequisitos
Las políticas de red son implementadas por el [plugin de red](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/). Para usar políticas de red, debes estar utilizando una solución de red que soporte NetworkPolicy. Crear un recurso NetworkPolicy sin un controlador que lo habilite no tendrá efecto alguno.
## Dos Tipos de Aislamiento de Pod
Hay dos tipos de aislamiento para un Pod: el aislamiento para la salida y el aislamiento para la entrada. Estos se refieren a las conexiones que pueden establecerse. El término "Aislamiento" en el contexto de este documento no es absoluto, sino que significa "se aplican algunas restricciones". La alternativa, "no aislado para $dirección", significa que no se aplican restricciones en la dirección descrita. Los dos tipos de aislamiento (o no) se declaran independientemente, y ambos son relevantes para una conexión de un Pod a otro.
Por defecto, un Pod no está aislado para la salida; todas las conexiones salientes están permitidas. Un Pod está aislado para la salida si hay alguna NetworkPolicy con "Egress" en su `policyTypes` que seleccione el Pod; decimos que tal política se aplica al Pod para la salida. Cuando un Pod está aislado para la salida, las únicas conexiones permitidas desde el Pod son las permitidas por la lista `egress` de las NetworkPolicy que se aplique al Pod para la salida. Los valores de esas listas `egress` se combinan de forma aditiva.
Por defecto, un Pod no está aislado para la entrada; todas las conexiones entrantes están permitidas. Un Pod está aislado para la entrada si hay alguna NetworkPolicy con "Ingress" en su `policyTypes` que seleccione el Pod; decimos que tal política se aplica al Pod para la entrada. Cuando un Pod está aislado para la entrada, las únicas conexiones permitidas en el Pod son las del nodo del Pod y las permitidas por la lista `ingress` de alguna NetworkPolicy que se aplique al Pod para la entrada. Los valores de esas listas de direcciones se combinan de forma aditiva.
Las políticas de red no entran en conflicto; son aditivas. Si alguna política(s) se aplica a un Pod para una dirección determinada, las conexiones permitidas en esa dirección desde ese Pod es la unión de lo que permiten las políticas aplicables. Por tanto, el orden de evaluación no afecta al resultado de la política.
Para que se permita una conexión desde un Pod de origen a un Pod de destino, tanto la política de salida del Pod de origen como la de entrada del Pod de destino deben permitir la conexión. Si cualquiera de los dos lados no permite la conexión, ésta no se producirá.
## El Recurso NetworkPolicy {#networkpolicy-resource}
Ver la referencia [NetworkPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#networkpolicy-v1-networking-k8s-io) para una definición completa del recurso.
Un ejemplo de NetworkPolicy pudiera ser este:
{{< codenew file="service/networking/networkpolicy.yaml" >}}
{{< note >}}
Enviar esto al API Server de su clúster no tendrá ningún efecto a menos que su solución de red soporte de políticas de red.
{{< /note >}}
__Campos Obligatorios__: Como con todos los otras configuraciones de Kubernetes, una NetworkPolicy
necesita los campos `apiVersion`, `kind`, y `metadata`. Para obtener información general
sobre cómo funcionan esos ficheros de configuración, puedes consultar
[Configurar un Pod para usar un ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/),
y [Gestión de Objetos](/docs/concepts/overview/working-with-objects/object-management).
__spec__: NetworkPolicy [spec](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) contiene toda la información necesaria para definir una política de red dado un Namespace.
__podSelector__: Cada NetworkPolicy incluye un `podSelector` el cual selecciona el grupo de Pods en los cuales aplica la política. La política de ejemplo selecciona Pods con el label "role=db". Un `podSelector` vacío selecciona todos los Pods en un Namespace.
__policyTypes__: Cada NetworkPolicy incluye una lista de `policyTypes` la cual puede incluir `Ingress`, `Egress`, o ambas. Los campos `policyTypes` indican si la política aplica o no al tráfico de entrada hacia el Pod seleccionado, el tráfico de salida desde el Pod seleccionado, o ambos. Si no se especifican `policyTypes` en una NetworkPolicy el valor `Ingress` será siempre aplicado por defecto y `Egress` será aplicado si la NetworkPolicy contiene alguna regla de salida.
__ingress__: Cada NetworkPolicy puede incluir una lista de reglas `ingress` permitidas. Cada regla permite el tráfico con que se relaciona a ambos valores de las secciones de `from` y `ports`. La política de ejemplo contiene una única regla, la cual se relaciona con el tráfico sobre un solo puerto, desde uno de los tres orígenes definidos, el primero especificado por el valor `ipBlock`, el segundo especificado por el valor `namespaceSelector` y el tercero especificado por el `podSelector`.
__egress__: Cada NetworkPolicy puede incluir una lista de reglas de `egress` permitidas. Cada regla permite el tráfico con que se relaciona a ambos valores de las secciones de `to` and `ports`. La política de ejemplo contiene una única regla, la cual se relaciona con el tráfico en un único puerto para cualquier destino en el rango de IPs `10.0.0.0/24`.
Por lo tanto, la NetworkPolicy de ejemplo:
1. Aísla los Pods "role=db" en el Namespace "default" para ambos tipos de tráfico ingress y egress (si ellos no están aún aislados)
2. (Reglas Ingress) permite la conexión hacia todos los Pods en el Namespace "default" con el label "role=db" en el puerto TCP 6379 desde los siguientes orígenes:
* cualquier Pod en el Namespace "default" con el label "role=frontend"
* cualquier Pod en un Namespace con el label "project=myproject"
* La dirección IP en los rangos 172.17.0.0–172.17.0.255 y 172.17.2.0–172.17.255.255 (por ejemplo, todo el rango de IPs de 172.17.0.0/16 con excepción del 172.17.1.0/24)
3. (Egress rules) permite conexión desde cualquier Pod en el Namespace "default" con el label "role=db" hacia CIDR 10.0.0.0/24 en el puerto TCP 5978
Ver el artículo de [Declarar Network Policy](/docs/tasks/administer-clúster/declare-network-policy/) para más ejemplos.
## Comportamiento de los selectores `to` y `from`
Existen cuatro tipos de selectores que pueden ser especificados en una sección de `ingress` `from` o en una sección de `egress` `to`:
__podSelector__: Este selector selecciona Pods específicos en el mismo Namespace que la NetworkPolicy para permitir el tráfico como origen de entrada o destino de salida.
__namespaceSelector__: Este selector selecciona Namespaces específicos para permitir el tráfico como origen de entrada o destino de salida.
__namespaceSelector__ *y* __podSelector__: Una única entrada `to`/`from` que especifica tanto `namespaceSelector` como `podSelector` selecciona Pods específicos dentro de Namespaces específicos. Es importante revisar que se utiliza la sintaxis de YAML correcta. A continuación se muestra un ejemplo de esta política:
```yaml
...
ingress:
- from:
- namespaceSelector:
matchLabels:
user: alice
podSelector:
matchLabels:
role: client
...
```
contiene un elemento `from` permitiendo conexiones desde los Pods con el label `role=client` en Namespaces con el label `user=alice`. Por el contrario, *esta* política:
```yaml
...
ingress:
- from:
- namespaceSelector:
matchLabels:
user: alice
- podSelector:
matchLabels:
role: client
...
```
contiene dos elementos en el array `from`, y permite conexiones desde Pods en los Namespaces con el label `role=client`, *o* desde cualquier Pod en cualquier Namespace con el label `user=alice`.
En caso de duda, utilice `kubectl describe` para ver cómo Kubernetes ha interpretado la política.
<a name="behavior-of-ipblock-selectors"></a>
__ipBlock__: Este selector selecciona rangos CIDR de IP específicos para permitirlas como origen de entrada o destino de salida. Estas IPs deben ser externas al clúster, ya que las IPs de Pod son efímeras e impredecibles.
Los mecanismos de entrada y salida del clúster a menudo requieren reescribir la IP de origen o destino
de los paquetes. En los casos en los que esto ocurre, no está definido si esto ocurre antes o
después del procesamiento de NetworkPolicy, y el comportamiento puede ser diferente para diferentes
combinaciones de plugin de red, proveedor de nube, implementación de `Service`, etc.
En el caso de la entrada, esto significa que en algunos casos se pueden filtrar paquetes
entrantes basándose en la IP de origen real, mientras que en otros casos, la "IP de origen" sobre la que actúa la
la NetworkPolicy actúa puede ser la IP de un `LoadBalancer` o la IP del Nodo donde este el Pod involucrado, etc.
Para la salida, esto significa que las conexiones de los Pods a las IPs de `Service` que se reescriben a
IPs externas al clúster pueden o no estar sujetas a políticas basadas en `ipBlock`.
## Políticas por defecto
Por defecto, si no existen políticas en un Namespace, se permite todo el tráfico de entrada y salida hacia y desde los Pods de ese Namespace. Los siguientes ejemplos muestran cómo cambiar el comportamiento por defecto en ese Namespace.
### Denegar todo el tráfico de entrada por defecto
Puedes crear una política que "por defecto" aisle a un Namespace del tráfico de entrada con la creación de una política que seleccione todos los Pods del Namespace pero no permite ningún tráfico de entrada en esos Pods.
{{< codenew file="service/networking/network-policy-default-deny-ingress.yaml" >}}
Esto asegura que incluso los Pods que no están seleccionados por ninguna otra NetworkPolicy también serán aislados del tráfico de entrada. Esta política no afecta el aislamiento en el tráfico de salida desde cualquier Pod.
### Permitir todo el tráfico de entrada
Si tu quieres permitir todo el tráfico de entrada a todos los Pods en un Namespace, puedes crear una política que explícitamente permita eso.
{{< codenew file="service/networking/network-policy-allow-all-ingress.yaml" >}}
Con esta política en curso, ninguna política(s) adicional puede hacer que se niegue cualquier conexión entrante a esos Pods. Esta política no tiene efecto sobre el aislamiento del tráfico de salida de cualquier Pod.
### Denegar por defecto todo el tráfico de salida
Puedes crear una política que "por defecto" aisle el tráfico de salida para un Namespace, creando una NetworkPolicy que seleccione todos los Pods pero que no permita ningún tráfico de salida desde esos Pods.
{{< codenew file="service/networking/network-policy-default-deny-egress.yaml" >}}
Esto asegura que incluso los Pods que no son seleccionados por ninguna otra NetworkPolicy no tengan permitido el tráfico de salida. Esta política no cambia el comportamiento de aislamiento para el tráfico de entrada de ningún Pod.
### Permitir todo el tráfico de salida
Si quieres permitir todas las conexiones desde todos los Pods de un Namespace, puedes crear una política que permita explícitamente todas las conexiones salientes de los Pods de ese Namespace.
{{< codenew file="service/networking/network-policy-allow-all-egress.yaml" >}}
Con esta política en vigor, ninguna política(s) adicional puede hacer que se niegue cualquier conexión de salida desde esos Pods. Esta política no tiene efecto sobre el aislamiento para el tráfico de entrada a cualquier Pod.
### Denegar por defecto todo el tráfico de entrada y de salida
Puede crear una política que "por defecto" en un Namespace impida todo el tráfico de entrada y de salida creando la siguiente NetworkPolicy en ese Namespace.
{{< codenew file="service/networking/network-policy-default-deny-all.yaml" >}}
Esto asegura que incluso los Pods que no son seleccionados por ninguna otra NetworkPolicy no tendrán permitido el tráfico de entrada o salida.
## Soporte a SCTP
{{< feature-state for_k8s_version="v1.20" state="stable" >}}
Como característica estable, está activada por defecto. Para deshabilitar SCTP a nivel de clúster, usted (o el administrador de su clúster) tiene que deshabilitar la [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `SCTPSupport` para el API Server con el flag `--feature-gates=SCTPSupport=false,...`.
Cuando esta feature gate está habilitada, puede establecer el campo `protocol` de una NetworkPolicy como `SCTP`.
{{< note >}}
Debes utilizar un plugin de {{< glossary_tooltip text="CNI" term_id="cni" >}} que soporte el protocolo SCTP NetworkPolicies.
{{< /note >}}
## Apuntar a un rango de puertos
{{< feature-state for_k8s_version="v1.22" state="beta" >}}
Cuando se escribe una NetworkPolicy, se puede apuntar a un rango de puertos en lugar de un solo puerto.
Esto se puede lograr con el uso del campo `endPort`, como el siguiente ejemplo:
```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: multi-port-egress
namespace: default
spec:
podSelector:
matchLabels:
role: db
policyTypes:
- Egress
egress:
- to:
- ipBlock:
cidr: 10.0.0.0/24
ports:
- protocol: TCP
port: 32000
endPort: 32768
```
La regla anterior permite que cualquier Pod con la etiqueta `role=db` en el Namespace `default` se comunique
con cualquier IP dentro del rango `10.0.0.0/24` sobre el protocolo TCP, siempre que el puerto
esté entre el rango 32000 y 32768.
Se aplican las siguientes restricciones al utilizar este campo:
* Como característica en estado beta, está activada por defecto. Para desactivar el campo `endPort` a nivel de clúster, usted (o su administrador de clúster) debe desactivar la [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `NetworkPolicyEndPort`
en el API Server con el flag `--feature-gates=NetworkPolicyEndPort=false,...`.
* El campo `endPort` debe ser igual o mayor que el campo `port`.
* Sólo se puede definir `endPort` si también se define `port`.
* Ambos puertos deben ser numéricos.
{{< note >}}
Su clúster debe utilizar un plugin de {{< glossary_tooltip text="CNI" term_id="cni" >}} que
soporte el campo `endPort` en las especificaciones de NetworkPolicy.
Si su [plugin de red](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
no soporta el campo `endPort` y usted especifica una NetworkPolicy que use este campo,
la política se aplicará sólo para el campo `port`.
{{< /note >}}
## Como apuntar a un Namespace usando su nombre
{{< feature-state for_k8s_version="1.22" state="stable" >}}
El plano de control de Kubernetes establece una etiqueta inmutable `kubernetes.io/metadata.name` en todos los
Namespaces, siempre que se haya habilitado la [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `NamespaceDefaultLabelName`.
El valor de la etiqueta es el nombre del Namespace.
Aunque NetworkPolicy no puede apuntar a un Namespace por su nombre con algún campo de objeto, puede utilizar la etiqueta estandarizada para apuntar a un Namespace específico.
## Que no puedes hacer con políticas de red (al menos, aún no)
Actualmente, en Kubernetes {{< skew currentVersion >}}, la siguiente funcionalidad no existe en la API de NetworkPolicy, pero es posible que se puedan implementar soluciones mediante componentes del sistema operativo (como SELinux, OpenVSwitch, IPTables, etc.) o tecnologías de capa 7 (Ingress controllers, implementaciones de Service Mesh) o controladores de admisión. En caso de que seas nuevo en la seguridad de la red en Kubernetes, vale la pena señalar que las siguientes historias de usuario no pueden (todavía) ser implementadas usando la API NetworkPolicy.
- Forzar que el tráfico interno del clúster pase por una puerta de enlace común (esto se puede implementar con una malla de servicios u otro proxy).
- Cualquier cosa relacionada con TLS (se puede implementar con una malla de servicios o un Ingress controllers para esto).
- Políticas específicas de los nodos (se puede utilizar la notación CIDR para esto, pero no se puede apuntar a los nodos por sus identidades Kubernetes específicamente).
- Apuntar Services por nombre (sin embargo, puede orientar los Pods o los Namespaces por su {{< glossary_tooltip text="labels" term_id="label" >}}, lo que suele ser una solución viable).
- Creación o gestión de "solicitudes de políticas" que son atendidas por un tercero.
- Políticas que por defecto son aplicadas a todos los Namespaces o Pods (hay algunas distribuciones y proyectos de Kubernetes de terceros que pueden hacer esto).
- Consulta avanzada de políticas y herramientas de accesibilidad.
- La capacidad de registrar los eventos de seguridad de la red (por ejemplo, las conexiones bloqueadas o aceptadas).
- La capacidad de negar explícitamente las políticas (actualmente el modelo para NetworkPolicies es negar por defecto, con sólo la capacidad de añadir reglas de permitir).
- La capacidad de impedir el tráfico entrante de Loopback o de Host (actualmente los Pods no pueden bloquear el acceso al host local, ni tienen la capacidad de bloquear el acceso desde su nodo residente).
## {{% heading "whatsnext" %}}
- Leer el artículo de como [Declarar de Políticas de Red](/docs/tasks/administer-clúster/declare-network-policy/) para ver más ejemplos.
- Ver más [recetas](https://github.com/ahmetb/kubernetes-network-policy-recipes) de escenarios comunes habilitados por los recursos de las NetworkPolicy.

11
content/es/examples/service/networking/network-policy-allow-all-egress.yaml Normal file
View File

@ -0,0 +1,11 @@
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-all-egress
spec:
podSelector: {}
egress:
- {}
policyTypes:
- Egress

11
content/es/examples/service/networking/network-policy-allow-all-ingress.yaml Normal file
View File

@ -0,0 +1,11 @@
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-all-ingress
spec:
podSelector: {}
ingress:
- {}
policyTypes:
- Ingress

10
content/es/examples/service/networking/network-policy-default-deny-all.yaml Normal file
View File

@ -0,0 +1,10 @@
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-all
spec:
podSelector: {}
policyTypes:
- Ingress
- Egress

9
content/es/examples/service/networking/network-policy-default-deny-egress.yaml Normal file
View File

@ -0,0 +1,9 @@
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-egress
spec:
podSelector: {}
policyTypes:
- Egress

9
content/es/examples/service/networking/network-policy-default-deny-ingress.yaml Normal file
View File

@ -0,0 +1,9 @@
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-ingress
spec:
podSelector: {}
policyTypes:
- Ingress

35
content/es/examples/service/networking/networkpolicy.yaml Normal file
View File

@ -0,0 +1,35 @@
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: test-network-policy
namespace: default
spec:
podSelector:
matchLabels:
role: db
policyTypes:
- Ingress
- Egress
ingress:
- from:
- ipBlock:
cidr: 172.17.0.0/16
except:
- 172.17.1.0/24
- namespaceSelector:
matchLabels:
project: myproject
- podSelector:
matchLabels:
role: frontend
ports:
- protocol: TCP
port: 6379
egress:
- to:
- ipBlock:
cidr: 10.0.0.0/24
ports:
- protocol: TCP
port: 5978

2
content/ja/docs/reference/using-api/_index.md
View File

@ -30,7 +30,7 @@ JSONとProtobufなどのシリアル化スキーマの変更については同
以下の説明は、両方のフォーマットをカバーしています。
APIのバージョニングとソフトウェアのバージョニングは間接的に関係しています。
[API and release versioning proposal](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md)は、APIバージョニングとソフトウェアバージョニングの関係を説明しています。
[API and release versioning proposal](https://git.k8s.io/sig-release/release-engineering/versioning.md)は、APIバージョニングとソフトウェアバージョニングの関係を説明しています。
APIのバージョンが異なると、安定性やサポートのレベルも異なります。
各レベルの基準については、[API Changes documentation](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)で詳しく説明しています。

2
content/ja/docs/setup/release/version-skew-policy.md
View File

@ -12,7 +12,7 @@ weight: 30
## サポートされるバージョン {#supported-versions}
Kubernetesのバージョンは**x.y.z**の形式で表現され、**x**はメジャーバージョン、**y**はマイナーバージョン、**z**はパッチバージョンを指します。これは[セマンティック バージョニング](https://semver.org/)に従っています。詳細は、[Kubernetesのリリースバージョニング](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/release/versioning.md#kubernetes-release-versioning)を参照してください。
Kubernetesのバージョンは**x.y.z**の形式で表現され、**x**はメジャーバージョン、**y**はマイナーバージョン、**z**はパッチバージョンを指します。これは[セマンティック バージョニング](https://semver.org/)に従っています。詳細は、[Kubernetesのリリースバージョニング](https://git.k8s.io/sig-release/release-engineering/versioning.md#kubernetes-release-versioning)を参照してください。
Kubernetesプロジェクトでは、最新の3つのマイナーリリースについてリリースブランチを管理しています ({{< skew latestVersion >}}, {{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}})。

2
content/ko/docs/reference/access-authn-authz/authorization.md
View File

@ -87,7 +87,7 @@ DELETE | delete(개별 리소스), deletecollection(리소스 모음)
쿠버네티스 API 서버는 몇 가지 인가 모드 중 하나를 사용하여 요청을 승인할 수 있다.
* **Node** - 실행되도록 스케줄된 파드에 따라 kubelet에게 권한을 부여하는 특수 목적 인가 모드. Node 인가 모드 사용에 대한 자세한 내용은 [Node 인가](/docs/reference/access-authn-authz/node/)을 참조한다.
* **Node** - 실행되도록 스케줄된 파드에 따라 kubelet에게 권한을 부여하는 특수 목적 인가 모드. Node 인가 모드 사용에 대한 자세한 내용은 [Node 인가](/docs/reference/access-authn-authz/node/)를 참조한다.
* **ABAC** - 속성 기반 접근 제어 (ABAC, Attribute-based access control)는 속성과 결합한 정책의 사용을 통해 사용자에게 접근 권한을 부여하는 접근 제어 패러다임을 말한다. 이 정책은 모든 유형의 속성(사용자 속성, 리소스 속성, 오브젝트, 환경 속성 등)을 사용할 수 있다. ABAC 모드 사용에 대한 자세한 내용은 [ABAC 모드](/docs/reference/access-authn-authz/abac/)를 참조한다.
* **RBAC** - 역할 기반 접근 제어(RBAC, Role-based access control)는 기업 내 개별 사용자의 역할을 기반으로 컴퓨터나 네트워크 리소스에 대한 접근을 규제하는 방식이다. 이 맥락에서 접근은 개별 사용자가 파일을 보거나 만들거나 수정하는 것과 같은 특정 작업을 수행할 수 있는 능력이다. RBAC 모드 사용에 대한 자세한 내용은 [RBAC 모드](/docs/reference/access-authn-authz/rbac/)를 참조한다.
* 지정된 RBAC(역할 기반 접근 제어)이 인가 결정을 위해 `rbac.authorization.k8s.io` API 그룹을 사용하면, 관리자가 쿠버네티스 API를 통해 권한 정책을 동적으로 구성할 수 있다.

4
content/pl/_index.html
View File

@ -44,12 +44,12 @@ Kubernetes jako projekt open-source daje Ci wolność wyboru ⏤ skorzystaj z pr
<button id="desktopShowVideoButton" onclick="kub.showVideo()">Obejrzyj wideo</button>
<br>
<br>
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe-2022/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu22" button id="desktopKCButton">Weź udział w KubeCon Europe 17-20.06.2022</a>
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/" button id="desktopKCButton">Weź udział w KubeCon North America 24-28.10.2022</a>
<br>
<br>
<br>
<br>
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncna21" button id="desktopKCButton">Weź udział w KubeCon North America 24-28.10.2022</a>
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/" button id="desktopKCButton">Weź udział w KubeCon Europe 17-21.04.2023</a>
</div>
<div id="videoPlayer">

385
content/pt-br/docs/concepts/architecture/nodes.md Normal file
View File

@ -0,0 +1,385 @@
---
title: Nós
content_type: conceito
weight: 10
---
<!-- overview -->
O Kubernetes executa sua carga de trabalho colocando contêineres em Pods para serem executados em _Nós_. Um nó pode ser uma máquina virtual ou física, dependendo do cluster. Cada nó é gerenciado pela {{< glossary_tooltip text="camada de gerenciamento" term_id="control-plane" >}} e contém os serviços necessários para executar {{< glossary_tooltip text="Pods" term_id="pod" >}}.
Normalmente, você tem vários nós em um cluster; em um ambiente de aprendizado ou limitado por recursos, você pode ter apenas um nó.
Os [componentes](/docs/concepts/overview/components/#node-components) em um nó incluem o {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}, um {{< glossary_tooltip text="agente de execução de contêiner" term_id="container-runtime" >}}, e o {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}.
<!-- body -->
## Administração
Existem duas maneiras principais de adicionar Nós ao {{< glossary_tooltip text="Servidor da API" term_id="kube-apiserver" >}}:
1. O kubelet em um nó se registra automaticamente na camada de gerenciamento
2. Você (ou outro usuário humano) adiciona manualmente um objeto Nó
Depois de criar um {{< glossary_tooltip text="objeto" term_id="object" >}} Nó, ou o kubelet em um nó se registra automaticamente, a camada de gerenciamento verifica se o novo objeto Nó é válido. Por exemplo, se você tentar criar um nó a partir do seguinte manifesto JSON:
```json
{
"kind": "Node",
"apiVersion": "v1",
"metadata": {
"name": "10.240.79.157",
"labels": {
"name": "my-first-k8s-node"
}
}
}
```
O Kubernetes cria um objeto nó internamente (a representação). O Kubernetes verifica se um kubelet se registrou no servidor da API que corresponde ao campo `metadata.name` do Nó. Se o nó estiver íntegro (ou seja, todos os serviços necessários estiverem em execução), ele será elegível para executar um Pod. Caso contrário, esse nó é ignorado para qualquer atividade de cluster até que se torne íntegro.
{{< note >}}
O Kubernetes mantém o objeto nó inválido e continua verificando se ele se torna íntegro.
Você, ou um {{< glossary_tooltip term_id="controller" text="controlador">}}, deve excluir explicitamente o objeto Nó para interromper essa verificação de integridade.
{{< /note >}}
O nome de um objeto nó deve ser um nome de [subdomínio válido de DNS](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
### Singularidade de nome do nó
O [nome](/docs/concepts/overview/working-with-objects/names#names) identifica um nó. Dois nós não podem ter o mesmo nome ao mesmo tempo. O Kubernetes também assume que um recurso com o mesmo nome é o mesmo objeto. No caso de um nó, assume-se implicitamente que uma instância usando o mesmo nome terá o mesmo estado (por exemplo, configurações de rede, conteúdo do disco raiz) e atributos como label de nó. Isso pode levar a inconsistências se uma instância for modificada sem alterar seu nome. Se o nó precisar ser substituído ou atualizado significativamente, o objeto Nó existente precisa ser removido do servidor da API primeiro e adicionado novamente após a atualização.
### Auto-registro de Nós
Quando a opção `--register-node` do kubelet for verdadeira (padrão), o kubelet tentará se registrar no servidor da API. Este é o padrão preferido, usado pela maioria das distribuições.
Para auto-registro, o kubelet é iniciado com as seguintes opções:
- `--kubeconfig` - O caminho das credenciais para se autenticar no servidor da API.
- `--cloud-provider` - Como comunicar com um {{< glossary_tooltip text="provedor de nuvem" term_id="cloud-provider" >}}
para ler metadados sobre si mesmo.
- `--register-node` - Registrar automaticamente no servidor da API.
- `--register-with-taints` - Registra o nó com a lista fornecida de {{< glossary_tooltip text="taints" term_id="taint" >}} (separadas por vírgula `<key>=<value>:<effect>`).
Não funciona se o `register-node` for falso.
- `--node-ip` - endereço IP do nó.
- `--node-labels` - {{< glossary_tooltip text="Labels" term_id="label" >}} a serem adicionados ao registrar o nó
no cluster (consulte as restrições de label impostas pelo [plug-in de admissão NodeRestriction](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)).
- `--node-status-update-frequency` - Especifica com que frequência o kubelet publica o status do nó no servidor da API.
Quando o [modo de autorização do nó](/docs/reference/access-authn-authz/node/) e o [plug-in de admissão NodeRestriction](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) estão ativados, os kubelets somente estarão autorizados a criar/modificar seu próprio recurso do nó.
{{< note >}}
Como mencionado na seção de [singularidade do nome do nó](#singularidade-de-nome-do-no), quando a configuração do nó precisa ser atualizada, é uma boa prática registrar novamente o nó no servidor da API. Por exemplo, se o kubelet estiver sendo reiniciado com o novo conjunto de `--node-labels`, mas o mesmo nome de nó for usado, a alteração não entrará em vigor, pois os labels estão sendo definidos no registro do Nó.
Pods já agendados no Nó podem ter um comportamento anormal ou causar problemas se a configuração do Nó for alterada na reinicialização do kubelet. Por exemplo, o Pod já em execução pode estar marcado diferente dos labels atribuídos ao Nó, enquanto outros Pods, que são incompatíveis com esse Pod, serão agendados com base nesse novo label. O novo registro do nó garante que todos os Pods sejam drenados e devidamente reiniciados.
{{< /note >}}
### Administração manual de nós
Você pode criar e modificar objetos Nó usando o {{< glossary_tooltip text="kubectl" term_id="kubectl" >}}.
Quando você quiser manualmente criar objetos Nó, defina a opção do kubelet `--register-node=false`.
Você pode modificar os objetos Nó, independentemente da configuração de `--register-node`. Por exemplo, você pode definir labels em um nó existente ou marcá-lo como não disponível.
Você pode usar labels nos Nós em conjunto com seletores de nós nos Pods para controlar a disponibilidade. Por exemplo, você pode restringir um Pod a ser elegível apenas para ser executado em um subconjunto dos nós disponíveis.
Marcar um nó como não disponível impede que o escalonador coloque novos pods nesse nó, mas não afeta os Pods existentes no nó. Isso é útil como uma etapa preparatória antes da reinicialização de um nó ou outra manutenção.
Para marcar um nó como não disponível, execute:
```shell
kubectl cordon $NODENAME
```
Consulte [Drenar um nó com segurança](/docs/tasks/administer-cluster/safely-drain-node/) para obter mais detalhes.
{{< note >}}
Os Pods que fazem parte de um {{< glossary_tooltip term_id="daemonset" >}} toleram ser executados em um nó não disponível. Os DaemonSets geralmente fornecem serviços locais de nós que devem ser executados em um Nó, mesmo que ele esteja sendo drenado de aplicativos de carga de trabalho.
{{< /note >}}
## Status do Nó
O status de um nó contém as seguintes informações:
* [Endereços](#addresses)
* [Condições](#condition)
* [Capacidade](#capacity)
* [Informação](#info)
Você pode usar o `kubectl` para visualizar o status de um nó e outros detalhes:
```shell
kubectl describe node <insira-nome-do-nó-aqui>
```
Cada seção da saída está descrita abaixo.
### Endereços
O uso desses campos pode mudar dependendo do seu provedor de nuvem ou configuração dedicada.
* HostName: O nome do host relatado pelo `kernel` do nó. Pode ser substituído através do parâmetro kubelet `--hostname-override`.
* ExternalIP: Geralmente, o endereço IP do nó que é roteável externamente (disponível fora do `cluster`).
* InternalIP: Geralmente, o endereço IP do nó que é roteável somente dentro do `cluster`.
### Condições {#conditions}
O campo `conditions` descreve o status de todos os nós em execução. Exemplos de condições incluem:
{{< table caption = "Condições do nó e uma descrição de quando cada condição se aplica." >}}
| Condições do nó | Descrição |
|----------------------|-------------|
| `Ready` | `True` Se o nó estiver íntegro e pronto para aceitar pods, `False` se o nó não estiver íntegro e não estiver aceitando pods, e desconhecido `Unknown` se o controlador do nó tiver sem notícias do nó no último `node-monitor-grace-period` (o padrão é de 40 segundos) |
| `DiskPressure` | `True` Se houver pressão sobre o tamanho do disco, ou seja, se a capacidade do disco for baixa; caso contrário `False` |
| `MemoryPressure` | `True` Se houver pressão na memória do nó, ou seja, se a memória do nó estiver baixa; caso contrário `False` |
| `PIDPressure` | `True` Se houver pressão sobre os processos, ou seja, se houver muitos processos no nó; caso contrário `False` |
| `NetworkUnavailable` | `True` Se a rede do nó não estiver configurada corretamente, caso contrário `False` |
{{< /table >}}
{{< note >}}
Se você usar as ferramentas de linha de comando para mostrar os detalhes de um nó isolado, a `Condition` inclui `SchedulingDisabled`. `SchedulingDisabled` não é uma condição na API do Kubernetes; em vez disso, os nós isolados são marcados como `Unschedulable` em suas especificações.
{{< /note >}}
Na API do Kubernetes, a condição de um nó é representada como parte do `.status` do recurso do nó. Por exemplo, a seguinte estrutura JSON descreve um nó íntegro:
```json
"conditions": [
{
"type": "Ready",
"status": "True",
"reason": "KubeletReady",
"message": "kubelet is posting ready status",
"lastHeartbeatTime": "2019-06-05T18:38:35Z",
"lastTransitionTime": "2019-06-05T11:41:27Z"
}
]
```
Se o status da condição `Ready` permanecer desconhecido (`Unknown`) ou falso (`False`) por mais tempo do que o limite da remoção do pod (`pod-eviction-timeout`) (um argumento passado para o {{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager">}}), o [controlador de nó](#node-controller) acionará o {{< glossary_tooltip text="remoção iniciado pela API" term_id="api-eviction" >}} para todos os Pods atribuídos a esse nó. A duração padrão do tempo limite da remoção é de **cinco minutos**. Em alguns casos, quando o nó está inacessível, o servidor da API não consegue se comunicar com o kubelet no nó. A decisão de excluir os pods não pode ser comunicada ao kubelet até que a comunicação com o servidor da API seja restabelecida. Enquanto isso, os pods agendados para exclusão podem continuar a ser executados no nó particionado.
O controlador de nós não força a exclusão dos pods até que seja confirmado que eles pararam de ser executados no cluster. Você pode ver os pods que podem estar sendo executados em um nó inacessível como estando no estado de terminando (`Terminating`) ou desconhecido (`Unknown`). Nos casos em que o Kubernetes não retirar da infraestrutura subjacente se um nó tiver deixado permanentemente um cluster, o administrador do cluster pode precisar excluir o objeto do nó manualmente. Excluir o objeto do nó do Kubernetes faz com que todos os objetos Pod em execução no nó sejam excluídos do servidor da API e libera seus nomes.
Quando ocorrem problemas nos nós, a camada de gerenciamento do Kubernetes cria automaticamente [`taints`](/docs/concepts/scheduling-eviction/taint-and-toleration/) que correspondem às condições que afetam o nó. O escalonador leva em consideração as `taints` do Nó ao atribuir um Pod a um Nó. Os Pods também podem ter {{< glossary_tooltip text="tolerations" term_id="toleration" >}} que os permitem funcionar em um nó, mesmo que tenha uma `taint` específica.
Consulte [Nó Taint por Condição](/pt-br/docs/concepts/scheduling-eviction/taint-and-toleration/#taints-por-condições-de-nó)
para mais detalhes.
### Capacidade e Alocável {#capacity}
Descreve os recursos disponíveis no nó: CPU, memória e o número máximo de pods que podem ser agendados no nó.
Os campos no bloco de capacidade indicam a quantidade total de recursos que um nó possui. O bloco alocado indica a quantidade de recursos em um nó que está disponível para ser consumido por Pods normais.
Você pode ler mais sobre capacidade e recursos alocados enquanto aprende a [reservar recursos de computação](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) em um nó.
### Info
Descreve informações gerais sobre o nó, como a versão do kernel, a versão do Kubernetes (versão do kubelet e kube-proxy), detalhes do tempo de execução do contêiner e qual sistema operacional o nó usa. O kubelet coleta essas informações do nó e as publica na API do Kubernetes.
## Heartbeats
Os `Heartbeats`, enviados pelos nós do Kubernetes, ajudam seu cluster a determinar a disponibilidade de cada nó e a agir quando as falhas forem detectadas.
Para nós, existem duas formas de `heartbeats`:
* atualizações para o `.status` de um Nó
* Objetos [Lease](/docs/reference/kubernetes-api/cluster-resources/lease-v1/) dentro do {{< glossary_tooltip term_id="namespace" text="namespace">}} `kube-node-lease`. Cada nó tem um objeto de `Lease` associado.
Em comparação com as atualizações no `.status` de um nó, um Lease é um recurso mais leve. O uso de Leases para `heartbeats` reduz o impacto no desempenho dessas atualizações para grandes clusters.
O kubelet é responsável por criar e atualizar o `.status` dos Nós e por atualizar suas Leases relacionadas.
- O kubelet atualiza o .status do nó quando há mudança de status ou se não houve atualização para um intervalo configurado. O intervalo padrão para atualizações .status para Nós é de 5 minutos, o que é muito maior do que o tempo limite padrão de 40 segundos para nós inacessíveis.
- O kubelet cria e atualiza seu objeto `Lease` a cada 10 segundos (o intervalo de atualização padrão). As atualizações de Lease ocorrem independentemente das atualizações no `.status` do Nó. Se a atualização do `Lease` falhar, o kubelet voltará a tentativas, usando um recuo exponencial que começa em 200 milissegundos e limitado a 7 segundos.
## Controlador de Nós
O {{< glossary_tooltip text="controlador" term_id="controller" >}} de nós é um componente da camada de gerenciamento do Kubernetes que gerencia vários aspectos dos nós.
O controlador de nó tem várias funções na vida útil de um nó. O primeiro é atribuir um bloco CIDR ao nó quando ele é registrado (se a atribuição CIDR estiver ativada).
O segundo é manter a lista interna de nós do controlador de nós atualizada com a lista de máquinas disponíveis do provedor de nuvem. Ao ser executado em um ambiente de nuvem e sempre que um nó não é íntegro, o controlador de nó pergunta ao provedor de nuvem se a VM desse nó ainda está disponível. Caso contrário, o controlador de nós exclui o nó de sua lista de nós.
O terceiro é monitorar a saúde dos nós. O controlador do nó é responsável por:
- No caso de um nó se tornar inacessível, atualizar a condição NodeReady dentro do campo `.status` do nó. Nesse caso, o controlador do nó define a condição de pronto (`NodeReady`) como condição desconhecida (`ConditionUnknown`).
- Se um nó permanecer inacessível: será iniciado a [remoção pela API](/docs/concepts/scheduling-eviction/api-eviction/) para todos os Pods no nó inacessível. Por padrão, o controlador do nó espera 5 minutos entre marcar o nó como condição desconhecida (`ConditionUnknown`) e enviar a primeira solicitação de remoção.
O controlador de nó verifica o estado de cada nó a cada `--node-monitor-period` segundos.
### Limites de taxa de remoção
Na maioria dos casos, o controlador de nós limita a taxa de remoção a `--node-eviction-rate` (0,1 por padrão) por segundo, o que significa que ele não removerá pods de mais de 1 nó por 10 segundos.
O comportamento de remoção do nó muda quando um nó em uma determinada zona de disponibilidade se torna não íntegro. O controlador de nós verifica qual porcentagem de nós na zona não são íntegras (a condição `NodeReady` é desconhecida `ConditionUnknown` ou falsa `ConditionFalse`) ao mesmo tempo:
- Se a fração de nós não íntegros for ao menos `--unhealthy-zone-threshold` (padrão 0,55), então a taxa de remoção será reduzida.
- Se o cluster for pequeno (ou seja, tiver número de nós menor ou igual ao valor da opção `--large-cluster-size-threshold` - padrão 50), então as remoções serão interrompidas.
- Caso contrário, a taxa de remoção é reduzida para `--secondary-node-eviction-rate` de nós secundários (padrão 0,01) por segundo.
A razão pela qual essas políticas são implementadas por zona de disponibilidade é porque a camada de gerenciamento pode perder conexão com uma zona de disponibilidade, enquanto as outras permanecem conectadas. Se o seu cluster não abranger várias zonas de disponibilidade de provedores de nuvem, o mecanismo de remoção não levará em conta a indisponibilidade por zona.
Uma das principais razões para espalhar seus nós pelas zonas de disponibilidade é para que a carga de trabalho possa ser transferida para zonas íntegras quando uma zona inteira cair. Portanto, se todos os nós em uma zona não estiverem íntegros, o controlador do nó removerá na taxa normal de `--node-eviction-rate`. O caso especial é quando todas as zonas estiverem completamente insalubres (nenhum dos nós do cluster será íntegro). Nesse caso, o controlador do nó assume que há algum problema com a conectividade entre a camada de gerenciamento e os nós e não realizará nenhuma remoção. (Se houver uma interrupção e alguns nós reaparecerem, o controlador do nó expulsará os pods dos nós restantes que estiverem insalubres ou inacessíveis).
O controlador de nós também é responsável por remover pods em execução nos nós com `NoExecute` taints, a menos que esses pods tolerem essa taint. O controlador de nó também adiciona as {{< glossary_tooltip text="taints" term_id="taint" >}} correspondentes aos problemas de nó, como nó inacessível ou não pronto. Isso significa que o escalonador não colocará Pods em nós não íntegros.
## Rastreamento de capacidade de recursos {#node-capacity}
Os objetos do nó rastreiam informações sobre a capacidade de recursos do nó: por exemplo, a quantidade de memória disponível e o número de CPUs. Os nós que se [auto-registram](#self-registration-of-nodes) relatam sua capacidade durante o registro. Se você adicionar [manualmente](#manual-node-administration) um nó, precisará definir as informações de capacidade do nó ao adicioná-lo.
O {{< glossary_tooltip text="escalonador" term_id="kube-scheduler" >}} do Kubernetes garante que haja recursos suficientes para todos os Pods em um nó. O escalonador verifica se a soma das solicitações de contêineres no nó não é maior do que a capacidade do nó. Essa soma de solicitações inclui todos os contêineres gerenciados pelo kubelet, mas exclui quaisquer contêineres iniciados diretamente pelo agente de execução de contêiner e também exclui quaisquer processos executados fora do controle do kubelet.
{{< note >}}
Se você quiser reservar explicitamente recursos para processos que não sejam do Pod, consulte [reserva de recursos para daemons do sistema](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved).
{{< /note >}}
## Topologia do Nó
{{< feature-state state="alpha" for_k8s_version="v1.16" >}}
Se você ativou os [recursos]](/docs/reference/command-line-tools-reference/feature-gates/) de `TopologyManager`, o kubelet pode usar dicas da topologia ao tomar decisões de atribuição de recursos. Consulte [Controle das Políticas de Gerenciamento de Topologia em um Nó](/docs/tasks/administer-cluster/topology-manager/) para obter mais informações.
## Desligamento gracioso do nó {#graceful-node-shutdown}
{{< feature-state state="beta" for_k8s_version="v1.21" >}}
O kubelet tenta detectar o desligamento do sistema do nó e encerra os pods em execução no nó.
O Kubelet garante que os pods sigam o processo normal de [término do pod](/docs/concepts/workloads/pods/)pod-lifecycle/#pod-termination) durante o desligamento do nó.
O recurso de desligamento gradual do nó depende do systemd, pois aproveita os [bloqueios do inibidor do systemd](https://www.freedesktop.org/wiki/Software/systemd/inhibit/) para atrasar o desligamento do nó com uma determinada duração.
O desligamento gradual do nó é controlado com [recursos](/docs/reference/command-line-tools-reference/feature-gates/) `GracefulNodeShutdown`, que é ativado por padrão na versão 1.21.
Observe que, por padrão, ambas as opções de configuração descritas abaixo, `shutdownGracePeriod` and `shutdownGracePeriodCriticalPods` estão definidas como zero, não ativando assim a funcionalidade de desligamento gradual do nó. Para ativar o recurso, as duas configurações do kubelet devem ser configuradas adequadamente e definidas como valores diferentes de zero.
Durante um desligamento gradual, o kubelet encerra os pods em duas fases:
1. Encerra os pods regulares em execução no nó.
2. Encerra os [pods críticos](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical) em execução no nó.
O recurso de desligamento gradual do nó é configurado com duas opções [`KubeletConfiguration`](/docs/tasks/administer-cluster/kubelet-config-file/):
* `shutdownGracePeriod`:
* Especifica a duração total pela qual o nó deve atrasar o desligamento. Este é o período de carência total para o término dos pods regulares e os [críticos](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical).
* `shutdownGracePeriodCriticalPods`:
* Especifica a duração utlizada para encerrar [pods críticos](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical) durante um desligamento de nó. Este valor deve ser menor que `shutdownGracePeriod`.
Por exemplo, se `shutdownGracePeriod=30s` e `shutdownGracePeriodCriticalPods=10s`, o kubelet atrasará o desligamento do nó em 30 segundos. Durante o desligamento, os primeiros 20 (30-10) segundos seriam reservados para encerrar gradualmente os pods normais, e os últimos 10 segundos seriam reservados para encerrar [pods críticos](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical).
{{< note >}}
Quando os pods forem removidos durante o desligamento gradual do nó, eles serão marcados como desligados. Executar o `kubectl get pods` para mostrar o status dos pods removidos como `Terminated`. E o `kubectl describe pod` indica que o pod foi removido por causa do desligamento do nó:
```
Reason: Terminated
Message: Pod was terminated in response to imminent node shutdown.
```
{{< /note >}}
### Desligamento gradual do nó baseado em prioridade do Pod {#pod-priority-graceful-node-shutdown}
{{< feature-state state="alpha" for_k8s_version="v1.23" >}}
Para fornecer mais flexibilidade durante o desligamento gradual do nó em torno da ordem de pods durante o desligamento, o desligamento gradual do nó respeita a PriorityClass dos Pods, desde que você tenha ativado esse recurso em seu cluster. O recurso permite que o cluster defina explicitamente a ordem dos pods durante o desligamento gradual do nó com base em [classes de prioridade](/docs/concepts/scheduling-eviction/pod-priority-preemption/#priorityclass).
O recurso [Desligamento Gradual do Nó](#graceful-node-shutdown), conforme descrito acima, desliga pods em duas fases, pods não críticos, seguidos por pods críticos. Se for necessária flexibilidade adicional para definir explicitamente a ordem dos pods durante o desligamento de uma maneira mais granular, o desligamento gradual baseado na prioridade do pod pode ser usado.
Quando o desligamento gradual do nó respeita as prioridades do pod, isso torna possível fazer o desligamento gradual do nó em várias fases, cada fase encerrando uma classe de prioridade específica de pods. O kubelet pode ser configurado com as fases exatas e o tempo de desligamento por fase.
Assumindo as seguintes classes de prioridade de pod personalizadas em um cluster,
|Nome das classes de prioridade|Valor das classes de prioridade|
|-------------------------|------------------------|
|`custom-class-a` | 100000 |
|`custom-class-b` | 10000 |
|`custom-class-c` | 1000 |
|`regular/unset` | 0 |
Na [configuração do kubelet](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration), as configurações para `shutdownGracePeriodByPodPriority` são semelhantes a:
|Valor das classes de prioridade|Tempo de desligamento|
|------------------------|---------------|
| 100000 |10 segundos |
| 10000 |180 segundos |
| 1000 |120 segundos |
| 0 |60 segundos |
A configuração correspondente do YAML do kubelet seria:
```yaml
shutdownGracePeriodByPodPriority:
- priority: 100000
shutdownGracePeriodSeconds: 10
- priority: 10000
shutdownGracePeriodSeconds: 180
- priority: 1000
shutdownGracePeriodSeconds: 120
- priority: 0
shutdownGracePeriodSeconds: 60
```
A tabela acima implica que qualquer pod com valor `priority` >= 100000 terá apenas 10 segundos para parar qualquer pod com valor >= 10000 e < 100000 e terá 180 segundos para parar, qualquer pod com valor >= 1000 e < 10000 terá 120 segundos para parar. Finalmente, todos os outros pods terão 60 segundos para parar.
Não é preciso especificar valores correspondentes para todas as classes. Por exemplo, você pode usar estas configurações:
|Valor das classes de prioridade|Tempo de desligamento|
|------------------------|---------------|
| 100000 |300 segundos |
| 1000 |120 segundos |
| 0 |60 segundos |
No caso acima, os pods com `custom-class-b` irão para o mesmo bucket que `custom-class-c` para desligamento.
Se não houver pods em um intervalo específico, o kubelet não irá espera por pods nesse intervalo de prioridades. Em vez disso, o kubelet pula imediatamente para o próximo intervalo de valores da classe de prioridade.
Se esse recurso estiver ativado e nenhuma configuração for fornecida, nenhuma ação de pedido será tomada.
O uso desse recurso requer ativar os recursos `GracefulNodeShutdownBasedOnPodPriority` e definir o `ShutdownGracePeriodByPodPriority` da configuração do kubelet para a configuração desejada, contendo os valores da classe de prioridade do pod e seus respectivos períodos de desligamento.
## Gerenciamento da memória swap {#swap-memory}
{{< feature-state state="alpha" for_k8s_version="v1.22" >}}
Antes do Kubernetes 1.22, os nós não suportavam o uso de memória swap, e um kubelet, por padrão, não iniciaria se a troca fosse detectada em um nó. A partir de 1.22, o suporte a memória swap pode ser ativado por nó.
Para ativar a troca em um nó, o recursos `NodeSwap` deve estar ativado no kubelet, e a [configuração](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration) de comando de linha `--fail-swap-on` ou `failSwapOn` deve ser definida como falsa.
{{< warning >}}
Quando o recurso de memória swap está ativado, os dados do Kubernetes, como o conteúdo de objetos `Secret` que foram gravados no `tmpfs`, agora podem ser trocados para o disco.
{{< /warning >}}
Opcionalmente, um usuário também pode configurar `memorySwap.swapBehavior` para especificar como um nó usará memória swap. Por exemplo,
```yaml
memorySwap:
swapBehavior: LimitedSwap
```
As opções de configuração disponíveis para `swapBehavior` são:
- `LimitedSwap`: As cargas de trabalho do Kubernetes são limitadas na quantidade de troca que podem usar. Cargas de trabalho no nó não gerenciadas pelo Kubernetes ainda podem ser trocadas.
- `UnlimitedSwap`: As cargas de trabalho do Kubernetes podem usar tanta memória de swap quanto solicitarem, até o limite do sistema.
Se a configuração do `memorySwap` não for especificada e o recurso estiver ativado, por padrão, o kubelet aplicará o mesmo comportamento que a configuração `LimitedSwap`.
O comportamento da configuração `LimitedSwap` depende se o nó estiver sendo executado com v1 ou v2 de grupos de controle (também conhecidos como "cgroups"):
- **cgroupsv1**: As cargas de trabalho do Kubernetes podem usar qualquer combinação de memória e swap, até o limite de memória do pod, se definido.
- **cgroupsv2**: As cargas de trabalho do Kubernetes não podem usar memória swap.
Para obter mais informações e para ajudar nos testes e fornecer feedback, consulte [KEP-2400](https://github.com/kubernetes/enhancements/issues/2400) e sua [proposta de design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/2400-node-swap/README.md).
## {{% heading "whatsnext" %}}
* Saiba mais sobre [componentes](/docs/concepts/overview/components/#node-components) que compõem um nó.
* Leia a [definição da API para um Nó](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core).
* Leia a seção [Nó](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node) do documento de design de arquitetura.
* Leia sobre [taints e tolerâncias](/docs/concepts/scheduling-eviction/taint-and-toleration/).

1450
content/pt-br/docs/concepts/configuration/secret.md
View File

File diff suppressed because it is too large Load Diff

2
content/pt-br/docs/concepts/containers/runtime-class.md
View File

@ -176,4 +176,4 @@ Pods utilizando-se desse Runtimeclass e assim contabilizar esses recursos para o
- [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)
- Leia mais sobre [Sobrecarga de Pods](/docs/concepts/scheduling-eviction/pod-overhead/)
- [PodOverhead Feature Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md)
- [PodOverhead Feature Design](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/688-pod-overhead)

2
content/pt-br/docs/concepts/scheduling-eviction/pod-overhead.md
View File

@ -188,6 +188,6 @@ mas é esperado em uma próxima versão. Os usuários necessitarão entretanto c
* [RuntimeClass](/docs/concepts/containers/runtime-class/)
* [PodOverhead Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md)
* [PodOverhead Design](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/688-pod-overhead)

2
content/pt-br/docs/concepts/storage/persistent-volumes.md
View File

@ -723,7 +723,7 @@ Se você está criando templates ou exemplos que rodam numa grande quantidade de
* Saiba mais sobre [Criando um PersistentVolume](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume).
* Saiba mais sobre [Criando um PersistentVolumeClaim](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolumeclaim).
* Leia a [documentação sobre planejamento de Armazenamento Persistente](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md).
* Leia a [documentação sobre planejamento de Armazenamento Persistente](https://git.k8s.io/design-proposals-archive/storage/persistent-storage.md).
### Referência

2
content/pt-br/docs/reference/access-authn-authz/bootstrap-tokens.md
View File

@ -57,7 +57,7 @@ do gerenciador de controle - kube-controller-manager.
## Formato do _secret_ dos tokens de inicialização
Cada token válido possui um _secret_ no namespace `kube-system`. Você pode
encontrar a documentação completa [aqui](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/cluster-lifecycle/bootstrap-discovery.md).
encontrar a documentação completa [aqui](https://github.com/kubernetes/design-proposals-archive/blob/main/cluster-lifecycle/bootstrap-discovery.md).
Um _secret_ de token se parece com o exemplo abaixo:

18
content/pt-br/docs/reference/glossary/kubectl.md Normal file
View File

@ -0,0 +1,18 @@
---
title: Kubectl
id: kubectl
date: 2018-04-12
full_link: /pt-br/docs/user-guide/kubectl-overview/
short_description: >
Uma ferramenta de linha de comando para se comunicar com um cluster Kubernetes.
aka:
- kubectl
tags:
- tool
- fundamental
---
Ferramenta de linha de comando para se comunicar com a {{< glossary_tooltip text="camada de gerenciamento" term_id="control-plane" >}} de um cluster Kubernetes usando a API do Kubernetes.
<!--more-->
Você pode usar `kubectl` para criar, inspecionar, atualizar e excluir objetos Kubernetes.

19
content/pt-br/docs/reference/glossary/sig.md Normal file
View File

@ -0,0 +1,19 @@
---
title: SIG (grupo de interesse especial)
id: sig
date: 2018-04-12
full_link: https://github.com/kubernetes/community/blob/master/sig-list.md#master-sig-list
short_description: >
Membros da comunidade que gerenciam coletivamente e continuamente uma parte ou projeto maior do código aberto do Kubernetes.
aka:
tags:
- community
---
{{< glossary_tooltip text="Membros da comunidade" term_id="member" >}} que gerenciam coletivamente e continuamente uma parte ou projeto maior do código aberto do Kubernetes.
<!--more-->
Os membros dentro de um grupo de interesse especial (do inglês - Special Interest Group, SIG) têm um interesse comum em contribuir em uma área específica, como arquitetura, API ou documentação. Os SIGs devem seguir as [diretrizes de governança](https://github.com/kubernetes/community/blob/master/committee-steering/governance/sig-governance.md) do SIG, mas podem ter sua própria política de contribuição e canais de comunicação.
Para mais informações, consulte o repositório [kubernetes/community](https://github.com/kubernetes/community) e a lista atual de [SIGs e Grupos de Trabalho](https://github.com/kubernetes/community/blob/master/sig-list.md).

24
content/pt-br/docs/reference/glossary/userns.md Normal file
View File

@ -0,0 +1,24 @@
---
title: Namespace do usuário
id: userns
date: 2021-07-13
full_link: https://man7.org/linux/man-pages/man7/user_namespaces.7.html
short_description: >
Um recurso do kernel Linux para emular privilégios de superusuário para usuários sem privilégios.
aka:
tags:
- security
---
Um recurso do kernel para emular o root. Usado para "contêineres sem root".
<!--more-->
Os namespaces do usuário são um recurso do kernel Linux que permite que um usuário não root emule privilégios de superusuário ("root"), por exemplo, para executar contêineres sem ser um superusuário fora do contêiner.
O namespace do usuário é eficaz para mitigar os danos de um potencial ataque em que o adversário escapa dos limites do contêiner.
No contexto de namespaces de usuário, o namespace é um recurso do kernel Linux, e não um {{< glossary_tooltip text="namespace" term_id="namespace" >}} no sentido do termo Kubernetes.
<!-- TODO: https://kinvolk.io/blog/2020/12/improving-kubernetes-and-container-security-with-user-namespaces/ -->

126
content/pt-br/docs/reference/setup-tools/kubeadm/generated/kubeadm_token_create.md Normal file
View File

@ -0,0 +1,126 @@
<!--
The file is auto-generated from the Go source code of the component using a generic
[generator](https://github.com/kubernetes-sigs/reference-docs/). To learn how
to generate the reference documentation, please read
[Contributing to the reference documentation](/docs/contribute/generate-ref-docs/).
To update the reference conent, please follow the
[Contributing upstream](/docs/contribute/generate-ref-docs/contribute-upstream/)
guide. You can file document formatting bugs against the
[reference-docs](https://github.com/kubernetes-sigs/reference-docs/) project.
-->
Crie tokens de inicialização no servidor
### Sinopse
Este comando criará um token de inicialização. Você pode especificar os usos para este token, o "tempo de vida" e uma descrição amigável, que é opcional.
O [token] é o token real para gravar. Este deve ser um token aleatório gerado com segurança da forma "[a-z0-9]{6}.[a-z0-9]{16}". Se nenhum [token] for fornecido, o kubeadm gerará um token aleatório.
```
kubeadm token create [token]
```
### Opções
<table style="width: 100%; table-layout: fixed;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--certificate-key string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>Quando usado em conjunto com '--print-join-command', exibe a flag completa 'kubeadm join' necessária para se unir ao cluster como um nó de camada de gerenciamento. Para criar uma nova chave de certificado, você deve usar 'kubeadm init phase upload-certs --upload-certs'.</p></td>
</tr>
<tr>
<td colspan="2">--config string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>Caminho para o arquivo de configuração kubeadm.</p></td>
</tr>
<tr>
<td colspan="2">--description string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>Uma descrição amigável de como esse token é usado.</p></td>
</tr>
<tr>
<td colspan="2">--groups strings&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Padrão: "system:bootstrappers:kubeadm:default-node-token"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>Grupos extras que este token autenticará quando usado para autenticação. Deve corresponder &quot;\Asystem:bootstrappers:[a-z0-9:-]{0,255}[a-z0-9]\z&quot;</p></td>
</tr>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>ajuda para create</p></td>
</tr>
<tr>
<td colspan="2">--print-join-command</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>Em vez de exibir apenas o token, exibe a flag completa 'kubeadm join' necessária para se associar ao cluster usando o token.</p></td>
</tr>
<tr>
<td colspan="2">--ttl duração&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Padrão: 24h0m0s</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>A duração antes do token ser excluído automaticamente (por exemplo, 1s, 2m, 3h). Se definido como '0', o token nunca expirará</p></td>
</tr>
<tr>
<td colspan="2">--usages strings&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Padrão: "signing,authentication"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>Descreve as maneiras pelas quais esse token pode ser usado. Você pode passar --usages várias vezes ou fornecer uma lista de opções separada por vírgulas. Opções válidas: [signing,authentication]</p></td>
</tr>
</tbody>
</table>
### Opções herdadas dos comandos superiores
<table style="width: 100%; table-layout: fixed;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--dry-run</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>Ativar ou não o modo de execução dry-run</p></td>
</tr>
<tr>
<td colspan="2">--kubeconfig string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Padrão: "/etc/kubernetes/admin.conf"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>O arquivo kubeconfig a ser usado para se comunicar com o cluster. Se a flag não estiver definida, um conjunto de locais predefinidos pode ser pesquisado por um arquivo kubeconfig existente.</p></td>
</tr>
<tr>
<td colspan="2">--rootfs string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>[EXPERIMENTAL] O caminho para o 'real' sistema de arquivos raiz do host.</p></td>
</tr>
</tbody>
</table>

80
content/pt-br/docs/reference/setup-tools/kubeadm/generated/kubeadm_token_delete.md Normal file
View File

@ -0,0 +1,80 @@
<!--
The file is auto-generated from the Go source code of the component using a generic
[generator](https://github.com/kubernetes-sigs/reference-docs/). To learn how
to generate the reference documentation, please read
[Contributing to the reference documentation](/docs/contribute/generate-ref-docs/).
To update the reference conent, please follow the
[Contributing upstream](/docs/contribute/generate-ref-docs/contribute-upstream/)
guide. You can file document formatting bugs against the
[reference-docs](https://github.com/kubernetes-sigs/reference-docs/) project.
-->
Excluir tokens de inicialização no servidor
### Sinopse
Este comando excluirá uma lista de tokens de inicialização para você.
O [token-value] é um Token completo na forma "[a-z0-9]{6}.[a-z0-9]{16}" ou o ID do Token na forma "[a-z0-9]{6}" a ser excluído.
```
kubeadm token delete [token-value] ...
```
### Opções
<table style="width: 100%; table-layout: fixed;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>ajuda para delete</p></td>
</tr>
</tbody>
</table>
### Opções herdadas dos comandos superiores
<table style="width: 100%; table-layout: fixed;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--dry-run</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>Ativar ou não o modo de execução dry-run</p></td>
</tr>
<tr>
<td colspan="2">--kubeconfig string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Padrão: "/etc/kubernetes/admin.conf"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>O arquivo kubeconfig a ser usado para se comunicar com o cluster. Se a flag não estiver definida, um conjunto de locais predefinidos pode ser pesquisado por um arquivo kubeconfig existente.</p></td>
</tr>
<tr>
<td colspan="2">--rootfs string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>[EXPERIMENTAL] O caminho para o 'real' sistema de arquivos raiz do host.</p></td>
</tr>
</tbody>
</table>

82
content/pt-br/docs/reference/setup-tools/kubeadm/generated/kubeadm_token_generate.md Normal file
View File

@ -0,0 +1,82 @@
<!--
The file is auto-generated from the Go source code of the component using a generic
[generator](https://github.com/kubernetes-sigs/reference-docs/). To learn how
to generate the reference documentation, please read
[Contributing to the reference documentation](/docs/contribute/generate-ref-docs/).
To update the reference conent, please follow the
[Contributing upstream](/docs/contribute/generate-ref-docs/contribute-upstream/)
guide. You can file document formatting bugs against the
[reference-docs](https://github.com/kubernetes-sigs/reference-docs/) project.
-->
Gere e exiba um token de inicialização, mas não o crie no servidor
### Sinopse
Este comando exibirá um token de inicialização gerado aleatoriamente que pode ser usado com os comandos "init" e "join".
Você não precisa usar este comando para gerar um token. Você pode fazer isso sozinho, desde que esteja no formato "[a-z0-9]{6}.[a-z0-9]{16}". Este comando é fornecido por conveniência para gerar tokens no formato fornecido.
Você também pode usar "kubeadm init" sem especificar um token e ele gerará e exibirá um para você.
```
kubeadm token generate [flags]
```
### Opções
<table style="width: 100%; table-layout: fixed;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>ajuda para generate</p></td>
</tr>
</tbody>
</table>
### Opções herdadas dos comandos superiores
<table style="width: 100%; table-layout: fixed;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--dry-run</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>Ativar ou não o modo de execução dry-run</p></td>
</tr>
<tr>
<td colspan="2">--kubeconfig string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Padrão: "/etc/kubernetes/admin.conf"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>O arquivo kubeconfig a ser usado para se comunicar com o cluster. Se a flag não estiver definida, um conjunto de locais predefinidos pode ser pesquisado por um arquivo kubeconfig existente.</p></td>
</tr>
<tr>
<td colspan="2">--rootfs string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>[EXPERIMENTAL] O caminho para o 'real' sistema de arquivos raiz do host.</p></td>
</tr>
</tbody>
</table>

99
content/pt-br/docs/reference/setup-tools/kubeadm/generated/kubeadm_token_list.md Normal file
View File

@ -0,0 +1,99 @@
<!--
The file is auto-generated from the Go source code of the component using a generic
[generator](https://github.com/kubernetes-sigs/reference-docs/). To learn how
to generate the reference documentation, please read
[Contributing to the reference documentation](/docs/contribute/generate-ref-docs/).
To update the reference conent, please follow the
[Contributing upstream](/docs/contribute/generate-ref-docs/contribute-upstream/)
guide. You can file document formatting bugs against the
[reference-docs](https://github.com/kubernetes-sigs/reference-docs/) project.
-->
Liste tokens de inicialização no servidor
### Sinopse
Este comando listará todos os tokens de inicialização para você
```
kubeadm token list [flags]
```
### Opções
<table style="width: 100%; table-layout: fixed;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--allow-missing-template-keys&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Padrão: true</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>Se verdadeiro (true), ignora quaisquer erros nos modelos quando um campo ou chave de mapa estiver faltando no modelo. Aplica-se apenas aos formatos de saída golang e jsonpath.</p></td>
</tr>
<tr>
<td colspan="2">-o, --experimental-output string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Padrão: "text"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>Formato de saída. Valores válidos: text|json|yaml|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file.</p></td>
</tr>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>ajuda para list</p></td>
</tr>
<tr>
<td colspan="2">--show-managed-fields</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>Se verdadeiro (true), mantém os managedFields ao exibir os objetos no formato JSON ou YAML.</p></td>
</tr>
</tbody>
</table>
### Opções herdadas dos comandos superiores
<table style="width: 100%; table-layout: fixed;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--dry-run</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>Ativar ou não o modo de execução dry-run</p></td>
</tr>
<tr>
<td colspan="2">--kubeconfig string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Padrão: "/etc/kubernetes/admin.conf"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>O arquivo kubeconfig a ser usado para se comunicar com o cluster. Se a flag não estiver definida, um conjunto de locais predefinidos pode ser pesquisado por um arquivo kubeconfig existente.</p></td>
</tr>
<tr>
<td colspan="2">--rootfs string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>[EXPERIMENTAL] O caminho para o 'real' sistema de arquivos raiz do host.</p></td>
</tr>
</tbody>
</table>

72
content/pt-br/docs/reference/setup-tools/kubeadm/generated/kubeadm_version.md Normal file
View File

@ -0,0 +1,72 @@
<!--
The file is auto-generated from the Go source code of the component using a generic
[generator](https://github.com/kubernetes-sigs/reference-docs/). To learn how
to generate the reference documentation, please read
[Contributing to the reference documentation](/docs/contribute/generate-ref-docs/).
To update the reference conent, please follow the
[Contributing upstream](/docs/contribute/generate-ref-docs/contribute-upstream/)
guide. You can file document formatting bugs against the
[reference-docs](https://github.com/kubernetes-sigs/reference-docs/) project.
-->
Exibe a versão do kubeadm
### Sinopse
Exibe a versão do kubeadm
```
kubeadm version [flags]
```
### Opções
<table style="width: 100%; table-layout: fixed;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">-h, --help</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>ajuda para version</p></td>
</tr>
<tr>
<td colspan="2">-o, --output string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>Formato de saída; as opções disponíveis são 'yaml', 'json' e 'short'</p></td>
</tr>
</tbody>
</table>
### Opção herdada do comando superior
<table style="width: 100%; table-layout: fixed;">
<colgroup>
<col span="1" style="width: 10px;" />
<col span="1" />
</colgroup>
<tbody>
<tr>
<td colspan="2">--rootfs string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>[EXPERIMENTAL] O caminho para o 'real' sistema de arquivos raiz do host.</p></td>
</tr>
</tbody>
</table>

27
content/pt-br/docs/reference/setup-tools/kubeadm/kubeadm-token.md Normal file
View File

@ -0,0 +1,27 @@
---
title: kubeadm token
content_type: concept
weight: 70
---
<!-- overview -->
Os Bootstrap tokens são usados para estabelecer uma relação de confiança bidirecional entre um nó que se junta ao cluster e um nó do plano de controle, conforme descrito na [autenticação com tokens de inicialização](/docs/reference/access-authn-authz/bootstrap-tokens/).
O `kubeadm init` cria um token inicial com um TTL de 24 horas. Os comandos a seguir permitem que você gerencie esse token e também crie e gerencie os novos.
<!-- body -->
## kubeadm token create {#cmd-token-create}
{{< include "generated/kubeadm_token_create.md" >}}
## kubeadm token delete {#cmd-token-delete}
{{< include "generated/kubeadm_token_delete.md" >}}
## kubeadm token generate {#cmd-token-generate}
{{< include "generated/kubeadm_token_generate.md" >}}
## kubeadm token list {#cmd-token-list}
{{< include "generated/kubeadm_token_list.md" >}}
## {{% heading "whatsnext" %}}
* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join) para inicializar um nó de carga de trabalho do Kubernetes e associá-lo ao cluster

10
content/pt-br/docs/reference/setup-tools/kubeadm/kubeadm-version.md Normal file
View File

@ -0,0 +1,10 @@
---
title: kubeadm version
content_type: concept
weight: 80
---
<!-- overview -->
Este comando exibe a versão do kubeadm.
<!-- body -->
{{< include "generated/kubeadm_version.md" >}}

2
content/pt-br/includes/task-tutorial-prereqs.md
View File

@ -2,5 +2,5 @@ Você precisa de um cluster Kubernetes e a ferramenta de linha de comando kubect
precisa estar configurada para acessar o seu cluster. Se você ainda não tem um
cluster, pode criar um usando o [minikube](/docs/tasks/tools/#minikube)
ou você pode usar um dos seguintes ambientes:
* [Katacoda](https://www.katacoda.com/courses/kubernetes/playground)
* [Killercoda](https://killercoda.com/playgrounds/scenario/kubernetes)
* [Play with Kubernetes](http://labs.play-with-k8s.com/)

32
content/zh-cn/_index.html
View File

@ -60,21 +60,21 @@ Kubernetes 是开源系统，可以自由地部署在企业内部，私有云、
{{< blocks/section id="video" background-image="kub_video_banner_homepage" >}}
<div class="light-text">
<!-- <h2>The Challenges of Migrating 150+ Microservices to Kubernetes</h2> -->
<h2>将 150+ 微服务迁移到 Kubernetes 上的挑战</h2>
<!-- <p>By Sarah Wells, Technical Director for Operations and Reliability, Financial Times</p> -->
<p>Sarah Wells, 运营和可靠性技术总监, 金融时报</p>
<button id="desktopShowVideoButton" onclick="kub.showVideo()">Watch Video</button>
<br>
<br>
<!-- <a href="https://www.lfasiallc.com/events/kubecon-cloudnativecon-china-2018/" button id="desktopKCButton">Attend KubeCon in Shanghai on Nov. 13-15, 2018</a> -->
<a href="https://www.lfasiallc.com/events/kubecon-cloudnativecon-china-2018/" button id="desktopKCButton">参加11月13日到15日的上海 KubeCon</a>
<br>
<br>
<br>
<br>
<!-- <a href="https://events.linuxfoundation.org/events/kubecon-cloudnativecon-north-america-2018/" button id="desktopKCButton">Attend KubeCon in Seattle on Dec. 11-13, 2018</a> -->
<a href="https://events.linuxfoundation.org/events/kubecon-cloudnativecon-north-america-2018/" button id="desktopKCButton">参加12月11日到13日的西雅图 KubeCon</a>
<!-- <h2>The Challenges of Migrating 150+ Microservices to Kubernetes</h2> -->
<h2>将 150+ 微服务迁移到 Kubernetes 上的挑战</h2>
<!-- <p>By Sarah Wells, Technical Director for Operations and Reliability, Financial Times</p> -->
<p>Sarah Wells, 运营和可靠性技术总监, 金融时报</p>
<button id="desktopShowVideoButton" onclick="kub.showVideo()">观看视频</button>
<br>
<br>
<!-- <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/" button id="desktopKCButton">Attend KubeCon North America on October 24-28, 2022</a> -->
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/" button id="desktopKCButton">参加 2022 年 10 月 24-28 日的北美 KubeCon</a>
<br>
<br>
<br>
<br>
<!-- <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe-2023/" button id="desktopKCButton">Attend KubeCon Europe on April 17-21, 2023</a> -->
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe-2023/" button id="desktopKCButton">参加 2023 年 4 月 17-21 日的欧洲 KubeCon</a>
</div>
<div id="videoPlayer">
<iframe data-url="https://www.youtube.com/embed/H06qrNmGqyE?autoplay=1" frameborder="0" allowfullscreen></iframe>
@ -84,4 +84,4 @@ Kubernetes 是开源系统，可以自由地部署在企业内部，私有云、
{{< blocks/kubernetes-features >}}
{{< blocks/case-studies >}}
{{< blocks/case-studies >}}

31
content/zh-cn/blog/_posts/2018-10-10-runtimeclass.md
View File

@ -19,11 +19,11 @@ date: 2018-10-10
Kubernetes originally launched with support for Docker containers running native applications on a Linux host. Starting with [rkt](https://kubernetes.io/blog/2016/07/rktnetes-brings-rkt-container-engine-to-kubernetes/) in Kubernetes 1.3 more runtimes were coming, which lead to the development of the [Container Runtime Interface](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/) (CRI). Since then, the set of alternative runtimes has only expanded: projects like [Kata Containers](https://katacontainers.io/) and [gVisor](https://github.com/google/gvisor) were announced for stronger workload isolation, and Kubernetes' Windows support has been [steadily progressing](https://kubernetes.io/blog/2018/01/kubernetes-v19-beta-windows-support/).
-->
Kubernetes 最初是为了支持在 Linux 主机上运行本机应用程序的 Docker 容器而创建的。
从 Kubernetes 1.3中的 [rkt](https://kubernetes.io/blog/2016/07/rktnetes-brings-rkt-container-engine-to-kubernetes/) 开始，更多的运行时间开始涌现，
从 Kubernetes 1.3 中的 [rkt](https://kubernetes.io/blog/2016/07/rktnetes-brings-rkt-container-engine-to-kubernetes/) 开始，更多的运行时间开始涌现，
这导致了[容器运行时接口（Container Runtime Interface）](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/)（CRI）的开发。
从那时起，备用运行时集合越来越大：
为了加强工作负载隔离，[Kata Containers](https://katacontainers.io/) 和 [gVisor](https://github.com/google/gvisor) 等项目被发起，
并且 Kubernetes 对 Windows 的支持正在 [稳步发展](https://kubernetes.io/blog/2018/01/kubernetes-v19-beta-windows-support/) 。
并且 Kubernetes 对 Windows 的支持正在[稳步发展](https://kubernetes.io/blog/2018/01/kubernetes-v19-beta-windows-support/)。
<!--
With runtimes targeting so many different use cases, a clear need for mixed runtimes in a cluster arose. But all these different ways of running containers have brought a new set of problems to deal with:
@ -56,7 +56,7 @@ With runtimes targeting so many different use cases, a clear need for mixed runt
RuntimeClass was recently introduced as an alpha feature in Kubernetes 1.12. The initial implementation focuses on providing a runtime selection API, and paves the way to address the other open problems.
-->
最近，RuntimeClass 在 Kubernetes 1.12 中作为 alpha 功能引入。
最初的实现侧重于提供运行时选择 API ，并为解决其他未解决的问题铺平道路。
最初的实现侧重于提供运行时选择 API，并为解决其他未解决的问题铺平道路。
<!--
The RuntimeClass resource represents a container runtime supported in a Kubernetes cluster. The cluster provisioner sets up, configures, and defines the concrete runtimes backing the RuntimeClass. In its current form, a RuntimeClassSpec holds a single field, the **RuntimeHandler**. The RuntimeHandler is interpreted by the CRI implementation running on a node, and mapped to the actual runtime configuration. Meanwhile the PodSpec has been expanded with a new field, **RuntimeClassName**, which names the RuntimeClass that should be used to run the pod.
@ -81,14 +81,14 @@ Kubernetes 资源模型期望 Pod 中的容器之间可以共享某些资源。
## 下一步是什么？
<!--
The RuntimeClass resource is an important foundation for surfacing runtime properties to the control plane. For example, to implement scheduler support for clusters with heterogeneous nodes supporting different runtimes, we might add [NodeAffinity](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity) terms to the RuntimeClass definition. Another area to address is managing the variable resource requirements to run pods of different runtimes. The [Pod Overhead proposal](https://docs.google.com/document/d/1EJKT4gyl58-kzt2bnwkv08MIUZ6lkDpXcxkHqCvvAp4/preview) was an early take on this that aligns nicely with the RuntimeClass design, and may be pursued further.
The RuntimeClass resource is an important foundation for surfacing runtime properties to the control plane. For example, to implement scheduler support for clusters with heterogeneous nodes supporting different runtimes, we might add [NodeAffinity](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity) terms to the RuntimeClass definition. Another area to address is managing the variable resource requirements to run pods of different runtimes. The [Pod Overhead proposal](https://docs.google.com/document/d/1EJKT4gyl58-kzt2bnwkv08MIUZ6lkDpXcxkHqCvvAp4/preview) was an early take on this that aligns nicely with the RuntimeClass design, and may be pursued further.
-->
RuntimeClass 资源是将运行时属性显示到控制平面的重要基础。
例如，要对具有支持不同运行时间的异构节点的集群实施调度程序支持，我们可以在 RuntimeClass 定义中添加
[NodeAffinity](/zh-cn/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)条件。
[NodeAffinity](/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity) 条件。
另一个需要解决的领域是管理可变资源需求以运行不同运行时的 Pod。
[Pod Overhead 提案](https://docs.google.com/document/d/1EJKT4gyl58-kzt2bnwkv08MIUZ6lkDpXcxkHqCvvAp4/preview)
是一项较早的尝试，与 RuntimeClass 设计非常吻合，并且可能会进一步推广。
[Pod Overhead 提案](https://docs.google.com/document/d/1EJKT4gyl58-kzt2bnwkv08MIUZ6lkDpXcxkHqCvvAp4/preview)是一项较早的尝试，与
RuntimeClass 设计非常吻合，并且可能会进一步推广。
<!--
Many other RuntimeClass extensions have also been proposed, and will be revisited as the feature continues to develop and mature. A few more extensions that are being considered include:
@ -107,13 +107,13 @@ Many other RuntimeClass extensions have also been proposed, and will be revisite
- 自动运行时或功能发现，支持无需手动配置的调度决策。
- 标准化或一致的 RuntimeClass 名称，用于定义一组具有相同名称的 RuntimeClass 的集群应支持的属性。
- 动态注册附加的运行时，因此用户可以在不停机的情况下在现有集群上安装新的运行时。
- 根据 Pod 的要求“匹配” RuntimeClass。
- 根据 Pod 的要求“匹配” RuntimeClass。
例如，指定运行时属性并使系统与适当的 RuntimeClass 匹配，而不是通过名称显式分配 RuntimeClass。
<!--
RuntimeClass will be under active development at least through 2019, and we’re excited to see the feature take shape, starting with the RuntimeClass alpha in Kubernetes 1.12.
-->
至少要到2019年，RuntimeClass 才会得到积极的开发，我们很高兴看到从 Kubernetes 1.12 中的 RuntimeClass alpha 开始，此功能得以形成。
至少要到 2019 年，RuntimeClass 才会得到积极的开发，我们很高兴看到从 Kubernetes 1.12 中的 RuntimeClass alpha 开始，此功能得以形成。
<!--
## Learn More
@ -127,10 +127,9 @@ RuntimeClass will be under active development at least through 2019, and we’re
- Join the discussions and help shape the future of RuntimeClass with the [SIG-Node community](https://github.com/kubernetes/community/tree/master/sig-node)
-->
- 试试吧！ 作为Alpha功能，还有一些其他设置步骤可以使用RuntimeClass。
有关如何使其运行，请参考 [RuntimeClass文档](/zh-cn/docs/concepts/containers/runtime-class/#runtime-class) 。
- 查看 [RuntimeClass Kubernetes 增强建议](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md) 以获取更多细节设计细节。
- [沙盒隔离级别决策](https://docs.google.com/document/d/1fe7lQUjYKR0cijRmSbH_y0_l3CYPkwtQa5ViywuNo8Q/preview)
记录了最初使 RuntimeClass 成为 Pod 级别选项的思考过程。
- 加入讨论，并通过 [SIG-Node社区](https://github.com/kubernetes/community/tree/master/sig-node) 帮助塑造 RuntimeClass 的未来。
- 试试吧！作为 Alpha 功能，还有一些其他设置步骤可以使用 RuntimeClass。
有关如何使其运行，请参考 [RuntimeClass 文档](/zh-cn/docs/concepts/containers/runtime-class/#runtime-class)。
- 查看 [RuntimeClass Kubernetes 增强建议](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md)以获取更多细节设计细节。
- [沙盒隔离级别决策](https://docs.google.com/document/d/1fe7lQUjYKR0cijRmSbH_y0_l3CYPkwtQa5ViywuNo8Q/preview)记录了最初使
RuntimeClass 成为 Pod 级别选项的思考过程。
- 加入讨论，并通过 [SIG-Node 社区](https://github.com/kubernetes/community/tree/master/sig-node)帮助塑造 RuntimeClass 的未来。

5
content/zh-cn/blog/_posts/2020-09-30-writing-crl-scheduler/index.md
View File

@ -188,7 +188,7 @@ To correct the latter issue, we now employ a "hunt and peck" approach to removin
### 1. Upgrade to kubernetes 1.18 and make use of Pod Topology Spread Constraints
While this seems like it could have been the perfect solution, at the time of writing Kubernetes 1.18 was unavailable on the two most common managed Kubernetes services in public cloud, EKS and GKE.
Furthermore, [pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/) were still a [beta feature in 1.18](https://v1-18.docs.kubernetes.io/docs/concepts/workloads/pods/pod-topology-spread-constraints/) which meant that it [wasn't guaranteed to be available in managed clusters](https://cloud.google.com/kubernetes-engine/docs/concepts/types-of-clusters#kubernetes_feature_choices) even when v1.18 became available.
Furthermore, [pod topology spread constraints](/docs/concepts/scheduling-eviction/topology-spread-constraints/) were still a beta feature in 1.18 which meant that it [wasn't guaranteed to be available in managed clusters](https://cloud.google.com/kubernetes-engine/docs/concepts/types-of-clusters#kubernetes_feature_choices) even when v1.18 became available.
The entire endeavour was concerningly reminiscent of checking [caniuse.com](https://caniuse.com/) when Internet Explorer 8 was still around.
-->
## 一场头脑风暴后我们有了 3 个选择。
@ -197,8 +197,7 @@ The entire endeavour was concerningly reminiscent of checking [caniuse.com](http
虽然这似乎是一个完美的解决方案，但在写这篇文章的时候，Kubernetes 1.18 在公有云中两个最常见的
托管 Kubernetes 服务（ EKS 和 GKE ）上是不可用的。
此外，[Pod 拓扑分布约束](/zh-cn/docs/concepts/workloads/pods/pod-topology-spread-constraints/)在
[1.18 中仍是测试版功能](https://v1-18.docs.kubernetes.io/docs/concepts/workloads/pods/pod-topology-spread-constraints/)，
此外，[Pod 拓扑分布约束](/zh-cn/docs/concepts/scheduling-eviction/topology-spread-constraints/)在 1.18 中仍是测试版功能，
这意味着即使在 v1.18 可用时，它[也不能保证在托管集群中可用](https://cloud.google.com/kubernetes-engine/docs/concepts/types-of-clusters#kubernetes_feature_choices)。
整个努力让人联想到在 Internet Explorer 8 还存在的时候访问 [caniuse.com](https://caniuse.com/)。

2
content/zh-cn/blog/_posts/2020-12-02-dockershim-faq.md
View File

@ -29,7 +29,7 @@ Also, you can read [check whether Dockershim removal affects you](/docs/tasks/ad
关于 Kubernetes kubelets 从容器运行时的角度弃用 Docker 的细节以及这些细节背后的含义，请参考博文
[别慌: Kubernetes 和 Docker](/blog/2020/12/02/dont-panic-kubernetes-and-docker/)。
此外，你可以阅读[检查 Dockershim 移除是否影响你](/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/)以检查它是否会影响你。
此外，你可以阅读[检查 Dockershim 移除是否影响你](/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-removal-affects-you/)以检查它是否会影响你。
<!--
### Why is dockershim being deprecated?

6
content/zh-cn/blog/_posts/2022-02-17-updated-dockershim-faq.md
View File

@ -4,7 +4,7 @@ title: "更新：移除 Dockershim 的常见问题"
linkTitle: "移除 Dockershim 的常见问题"
date: 2022-02-17
slug: dockershim-faq
aliases: [ 'zh/dockershim' ]
aliases: [ '/zh-cn/dockershim' ]
---
<!--
layout: blog
@ -51,7 +51,7 @@ To determine the impact that the removal of dockershim would have for you or you
you can read [Check whether dockershim removal affects you](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-removal-affects-you/).
-->
要确定移除 dockershim 是否会对你或你的组织的影响，可以查阅：
[检查弃用 Dockershim 对你的影响](/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/)
[检查弃用 Dockershim 对你的影响](/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-removal-affects-you/)
这篇文章。
<!--
@ -91,7 +91,7 @@ special code to help with the transition, and made that _dockershim_ code part o
itself.
-->
Kubernetes 的早期版本仅适用于特定的容器运行时：Docker Engine。
后来，Kubernetes 增加了对使用其他容器运行时的支持。[创建](/blog/2016/12/container-runtime-interface-cri-in-kubernetes/) CRI
后来，Kubernetes 增加了对使用其他容器运行时的支持。[创建](/blog/2016/12/container-runtime-interface-cri-in-kubernetes/) CRI
标准是为了实现编排器（如 Kubernetes）和许多不同的容器运行时之间交互操作。
Docker Engine 没有实现（CRI）接口，因此 Kubernetes 项目创建了特殊代码来帮助过渡，
并使 dockershim 代码成为 Kubernetes 的一部分。

4
content/zh-cn/blog/_posts/2022-04-07-Kubernetes-1-24-removals-and-deprecations.md
View File

@ -204,7 +204,7 @@ As stated earlier, there are several guides about
You can start with [Finding what container runtime are on your nodes](/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use/).
If your nodes are using dockershim, there are other possible Docker Engine dependencies such as
Pods or third-party tools executing Docker commands or private registries in the Docker configuration file. You can follow the
[Check whether Dockershim deprecation affects you](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/) guide to review possible
[Check whether Dockershim deprecation affects you](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-removal-affects-you/) guide to review possible
Docker Engine dependencies. Before upgrading to v1.24, you decide to either remain using Docker Engine and
[Migrate Docker Engine nodes from dockershim to cri-dockerd](/docs/tasks/administer-cluster/migrating-from-dockershim/migrate-dockershim-dockerd/) or migrate to a CRI-compatible runtime. Here's a guide to
[change the container runtime on a node from Docker Engine to containerd](/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd/).
@ -216,7 +216,7 @@ Docker Engine dependencies. Before upgrading to v1.24, you decide to either rema
你可以[从查明节点上所使用的容器运行时](/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use/)开始。
如果你的节点使用 dockershim，则还有其他可能的 Docker Engine 依赖项，
例如 Pod 或执行 Docker 命令的第三方工具或 Docker 配置文件中的私有注册表。
你可以按照[检查弃用 Dockershim 对你的影响](/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/)
你可以按照[检查弃用 Dockershim 对你的影响](/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-removal-affects-you/)
的指南来查看可能的 Docker 引擎依赖项。在升级到 1.24 版本之前， 你决定要么继续使用 Docker Engine 并
[将 Docker Engine 节点从 dockershim 迁移到 cri-dockerd](/docs/tasks/administer-cluster/migrating-from-dockershim/migrate-dockershim-dockerd/)，
要么迁移到与 CRI 兼容的运行时。这是[将节点上的容器运行时从 Docker Engine 更改为 containerd](/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd/) 的指南。

286
content/zh-cn/blog/_posts/2022-04-28-Increasing-the-security-bar-in-Ingress-NGINX/index.md Normal file
View File

@ -0,0 +1,286 @@
---
layout: blog
title: '在 Ingress-NGINX v1.2.0 中提高安全标准'
date: 2022-04-28
slug: ingress-nginx-1-2-0
---
<!--
layout: blog
title: 'Increasing the security bar in Ingress-NGINX v1.2.0'
date: 2022-04-28
slug: ingress-nginx-1-2-0
-->
<!--
**Authors:** Ricardo Katz (VMware), James Strong (Chainguard)
-->
**作者：** Ricardo Katz (VMware), James Strong (Chainguard)
<!--
The [Ingress](/docs/concepts/services-networking/ingress/) may be one of the most targeted components
of Kubernetes. An Ingress typically defines an HTTP reverse proxy, exposed to the Internet, containing
multiple websites, and with some privileged access to Kubernetes API (such as to read Secrets relating to
TLS certificates and their private keys).
-->
[Ingress](/zh-cn/docs/concepts/services-networking/ingress/) 可能是 Kubernetes 最容易受攻击的组件之一。
Ingress 通常定义一个 HTTP 反向代理，暴露在互联网上，包含多个网站，并具有对 Kubernetes API
的一些特权访问（例如读取与 TLS 证书及其私钥相关的 Secret）。
<!--
While it is a risky component in your architecture, it is still the most popular way to properly expose your services.
-->
虽然它是架构中的一个风险组件，但它仍然是正常公开服务的最流行方式。
<!--
Ingress-NGINX has been part of security assessments that figured out we have a big problem: we don't
do all proper sanitization before turning the configuration into an `nginx.conf` file, which may lead to information
disclosure risks.
-->
Ingress-NGINX 一直是安全评估的重头戏，这类评估会发现我们有着很大的问题：
在将配置转换为 `nginx.conf` 文件之前，我们没有进行所有适当的清理，这可能会导致信息泄露风险。
<!--
While we understand this risk and the real need to fix this, it's not an easy process to do, so we took another approach to reduce (but not remove!) this risk in the current (v1.2.0) release.
-->
虽然我们了解此风险以及解决此问题的真正需求，但这并不是一个容易的过程，
因此我们在当前(v1.2.0)版本中采取了另一种方法来减少（但不是消除！）这种风险。
<!--
## Meet Ingress NGINX v1.2.0 and the chrooted NGINX process
-->
## 了解 Ingress NGINX v1.2.0 和 chrooted NGINX 进程
<!--
One of the main challenges is that Ingress-NGINX runs the web proxy server (NGINX) alongside the Ingress
controller (the component that has access to Kubernetes API that and that creates the `nginx.conf` file).
-->
主要挑战之一是 Ingress-NGINX 运行着 Web 代理服务器（NGINX），并与 Ingress 控制器一起运行
（后者是一个可以访问 Kubernetes API 并创建 `nginx.conf` 的组件）。
<!--
So, NGINX does have the same access to the filesystem of the controller (and Kubernetes service account token, and other configurations from the container). While splitting those components is our end goal, the project needed a fast response; that lead us to the idea of using `chroot()`.
-->
因此，NGINX 对控制器的文件系统（和 Kubernetes 服务帐户令牌，以及容器中的其他配置）具有相同的访问权限。
虽然拆分这些组件是我们的最终目标，但该项目需要快速响应；这让我们想到了使用 `chroot()`。
<!--
Let's take a look into what an Ingress-NGINX container looked like before this change:
-->
让我们看一下 Ingress-NGINX 容器在此更改之前的样子：
![Ingress NGINX pre chroot](ingress-pre-chroot.png)
<!--
As we can see, the same container (not the Pod, the container!) that provides HTTP Proxy is the one that watches Ingress objects and writes the Container Volume
-->
正如我们所见，用来提供 HTTP Proxy 的容器（不是 Pod，是容器！）也是是监视 Ingress
对象并将数据写入容器卷的容器。
<!--
Now, meet the new architecture:
-->
现在，见识一下新架构：
![Ingress NGINX post chroot](ingress-post-chroot.png)
<!--
What does all of this mean? A basic summary is: that we are isolating the NGINX service as a container inside the
controller container.
-->
这一切意味着什么？一个基本的总结是：我们将 NGINX 服务隔离为控制器容器内的容器。
<!--
While this is not strictly true, to understand what was done here, it's good to understand how
Linux containers (and underlying mechanisms such as kernel namespaces) work.
You can read about cgroups in the Kubernetes glossary: [`cgroup`](https://kubernetes.io/docs/reference/glossary/?fundamental=true#term-cgroup) and learn more about cgroups interact with namespaces in the NGINX project article
[What Are Namespaces and cgroups, and How Do They Work?](https://www.nginx.com/blog/what-are-namespaces-cgroups-how-do-they-work/).
(As you read that, bear in mind that Linux kernel namespaces are a different thing from
[Kubernetes namespaces](/docs/concepts/overview/working-with-objects/namespaces/)).
-->
虽然这并不完全正确，但要了解这里所做的事情，最好了解 Linux 容器（以及内核命名空间等底层机制）是如何工作的。
你可以在 Kubernetes 词汇表中阅读有关 cgroup 的信息：[`cgroup`](/zh-cn/docs/reference/glossary/?fundamental=true#term-cgroup)，
并在 NGINX 项目文章[什么是命名空间和 cgroup，以及它们如何工作？](https://www.nginx.com/blog/what-are-namespaces-cgroups-how-do-they-work/)
中了解有关 cgroup 与命名空间交互的更多信息。（当你阅读时，请记住 Linux 内核命名空间与
[Kubernetes 命名空间](/zh-cn/docs/concepts/overview/working-with-objects/namespaces/)不同）。
<!--
## Skip the talk, what do I need to use this new approach?
-->
## 跳过谈话，我需要什么才能使用这种新方法？
<!--
While this increases the security, we made this feature an opt-in in this release so you can have
time to make the right adjustments in your environment(s). This new feature is only available from
release v1.2.0 of the Ingress-NGINX controller.
-->
虽然这增加了安全性，但我们在这个版本中把这个功能作为一个选项，这样你就可以有时间在你的环境中做出正确的调整。
此新功能仅在 Ingress-NGINX 控制器的 v1.2.0 版本中可用。
<!--
There are two required changes in your deployments to use this feature:
* Append the suffix "-chroot" to the container image name. For example: `gcr.io/k8s-staging-ingress-nginx/controller-chroot:v1.2.0`
* In your Pod template for the Ingress controller, find where you add the capability `NET_BIND_SERVICE` and add the capability `SYS_CHROOT`. After you edit the manifest, you'll see a snippet like:
-->
要使用这个功能，在你的部署中有两个必要的改变：
* 将后缀 "-chroot" 添加到容器镜像名称中。例如：`gcr.io/k8s-staging-ingress-nginx/controller-chroot:v1.2.0`
* 在你的 Ingress 控制器的 Pod 模板中，找到添加 `NET_BIND_SERVICE` 权能的位置并添加 `SYS_CHROOT` 权能。
编辑清单后，你将看到如下代码段：
```yaml
capabilities:
drop:
- ALL
add:
- NET_BIND_SERVICE
- SYS_CHROOT
```
<!--
If you deploy the controller using the official Helm chart then change the following setting in
`values.yaml`:
-->
如果你使用官方 Helm Chart 部署控制器，则在 `values.yaml` 中更改以下设置：
```yaml
controller:
image:
chroot: true
```
<!--
Ingress controllers are normally set up cluster-wide (the IngressClass API is cluster scoped). If you manage the
Ingress-NGINX controller but you're not the overall cluster operator, then check with your cluster admin about
whether you can use the `SYS_CHROOT` capability, **before** you enable it in your deployment.
-->
Ingress 控制器通常部署在集群作用域（IngressClass API 是集群作用域的）。
如果你管理 Ingress-NGINX 控制器但你不是整个集群的操作员，
请在部署中启用它**之前**与集群管理员确认你是否可以使用 `SYS_CHROOT` 功能。
<!--
## OK, but how does this increase the security of my Ingress controller?
Take the following configuration snippet and imagine, for some reason it was added to your `nginx.conf`:
-->
## 好吧，但这如何能提高我的 Ingress 控制器的安全性呢？
以下面的配置片段为例，想象一下，由于某种原因，它被添加到你的 `nginx.conf` 中：
```
location /randomthing/ {
alias /;
autoindex on;
}
```
<!--
If you deploy this configuration, someone can call `http://website.example/randomthing` and get some listing (and access) to the whole filesystem of the Ingress controller.
Now, can you spot the difference between chrooted and non chrooted Nginx on the listings below?
-->
如果你部署了这种配置，有人可以调用 `http://website.example/randomthing` 并获取对 Ingress 控制器的整个文件系统的一些列表（和访问权限）。
现在，你能在下面的列表中发现 chroot 处理过和未经 chroot 处理过的 Nginx 之间的区别吗？
| 不额外调用 `chroot()` | 额外调用 `chroot()` |
|----------------------------|--------|
| `bin` | `bin` |
| `dev` | `dev` |
| `etc` | `etc` |
| `home` | |
| `lib` | `lib` |
| `media` | |
| `mnt` | |
| `opt` | `opt` |
| `proc` | `proc` |
| `root` | |
| `run` | `run` |
| `sbin` | |
| `srv` | |
| `sys` | |
| `tmp` | `tmp` |
| `usr` | `usr` |
| `var` | `var` |
| `dbg` | |
| `nginx-ingress-controller` | |
| `wait-shutdown` | |
<!--
The one in left side is not chrooted. So NGINX has full access to the filesystem. The one in right side is chrooted, so a new filesystem with only the required files to make NGINX work is created.
-->
左侧的那个没有 chroot 处理。所以 NGINX 可以完全访问文件系统。右侧的那个经过 chroot 处理，
因此创建了一个新文件系统，其中只有使 NGINX 工作所需的文件。
<!--
## What about other security improvements in this release?
-->
## 此版本中的其他安全改进如何？
<!--
We know that the new `chroot()` mechanism helps address some portion of the risk, but still, someone
can try to inject commands to read, for example, the `nginx.conf` file and extract sensitive information.
-->
我们知道新的 `chroot()` 机制有助于解决部分风险，但仍然有人可以尝试注入命令来读取，例如 `nginx.conf` 文件并提取敏感信息。
<!--
So, another change in this release (this is opt-out!) is the _deep inspector_.
We know that some directives or regular expressions may be dangerous to NGINX, so the deep inspector
checks all fields from an Ingress object (during its reconciliation, and also with a
[validating admission webhook](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook))
to verify if any fields contains these dangerous directives.
-->
所以，这个版本的另一个变化（可选择取消）是 **深度探测（Deep Inspector）**。
我们知道某些指令或正则表达式可能对 NGINX 造成危险，因此深度探测器会检查 Ingress 对象中的所有字段
（在其协调期间，并且还使用[验证准入 webhook](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook))
验证是否有任何字段包含这些危险指令。
<!--
The ingress controller already does this for annotations, and our goal is to move this existing validation to happen inside
deep inspection as part of a future release.
-->
Ingress 控制器已经通过注解做了这个工作，我们的目标是把现有的验证转移到深度探测中，作为未来版本的一部分。
<!--
You can take a look into the existing rules in [https://github.com/kubernetes/ingress-nginx/blob/main/internal/ingress/inspector/rules.go](https://github.com/kubernetes/ingress-nginx/blob/main/internal/ingress/inspector/rules.go).
-->
你可以在 [https://github.com/kubernetes/ingress-nginx/blob/main/internal/ingress/inspector/rules.go](https://github.com/kubernetes/ingress-nginx/blob/main/internal/ingress/inspector/rules.go) 中查看现有规则。
<!--
Due to the nature of inspecting and matching all strings within relevant Ingress objects, this new feature may consume a bit more CPU. You can disable it by running the ingress controller with the command line argument `--deep-inspect=false`.
-->
由于检查和匹配相关 Ingress 对象中的所有字符串的性质，此新功能可能会消耗更多 CPU。
你可以通过使用命令行参数 `--deep-inspect=false` 运行 Ingress 控制器来禁用它。
<!--
## What's next?
This is not our final goal. Our final goal is to split the control plane and the data plane processes.
In fact, doing so will help us also achieve a [Gateway](https://gateway-api.sigs.k8s.io/) API implementation,
as we may have a different controller as soon as it "knows" what to provide to the data plane
(we need some help here!!)
-->
## 下一步是什么?
这不是我们的最终目标。我们的最终目标是拆分控制平面和数据平面进程。
事实上，这样做也将帮助我们实现 [Gateway](https://gateway-api.sigs.k8s.io/) API 实现，
因为一旦它“知道”要提供什么，我们可能会有不同的控制器 数据平面（我们需要一些帮助！！）
<!--
Some other projects in Kubernetes already take this approach
(like [KPNG](https://github.com/kubernetes-sigs/kpng), the proposed replacement for `kube-proxy`),
and we plan to align with them and get the same experience for Ingress-NGINX.
-->
Kubernetes 中的其他一些项目已经采用了这种方法（如 [KPNG](https://github.com/kubernetes-sigs/kpng)，
建议替换 `kube-proxy`），我们计划与他们保持一致，并为 Ingress-NGINX 获得相同的体验。
<!--
## Further reading
If you want to take a look into how chrooting was done in Ingress NGINX, take a look
into [https://github.com/kubernetes/ingress-nginx/pull/8337](https://github.com/kubernetes/ingress-nginx/pull/8337)
The release v1.2.0 containing all the changes can be found at
[https://github.com/kubernetes/ingress-nginx/releases/tag/controller-v1.2.0](https://github.com/kubernetes/ingress-nginx/releases/tag/controller-v1.2.0)
-->
## 延伸阅读
如果你想了解如何在 Ingress NGINX 中完成 chrooting，请查看
[https://github.com/kubernetes/ingress-nginx/pull/8337](https://github.com/kubernetes/ingress-nginx/pull/8337)。
包含所有更改的版本 v1.2.0 可以在以下位置找到
[https://github.com/kubernetes/ingress-nginx/releases/tag/controller-v1.2.0](https://github.com/kubernetes/ingress-nginx/releases/tag/controller-v1.2.0)

BIN
content/zh-cn/blog/_posts/2022-04-28-Increasing-the-security-bar-in-Ingress-NGINX/ingress-post-chroot.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 59 KiB

BIN
content/zh-cn/blog/_posts/2022-04-28-Increasing-the-security-bar-in-Ingress-NGINX/ingress-pre-chroot.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 51 KiB

38
content/zh-cn/blog/_posts/2022-05-03-kubernetes-release-1.24.md
View File

@ -44,10 +44,10 @@ see [this guide](/blog/2022/03/31/ready-for-dockershim-removal/).
### 从 kubelet 中删除 Dockershim
在 v1.20 版本中被废弃后，dockershim 组件已被从 Kubernetes v1.24 版本的 kubelet 中移除。
从v1.24开始，如果你依赖 Docker Engine 作为容器运行时，
从 v1.24 开始，如果你依赖 Docker Engine 作为容器运行时，
则需要使用其他[受支持的运行时](/zh-cn/docs/setup/production-environment/container-runtimes/)之一
（如 containerd 或 CRI-O）或使用 CRI dockerd。
有关确保群集已准备好进行此删除的更多信息，请参阅[本指南](/zh-cn/blog/2022/03/31/ready-for-dockershim-removal/)。
有关确保集群已准备好进行此删除的更多信息，请参阅[本指南](/zh-cn/blog/2022/03/31/ready-for-dockershim-removal/)。
<!--
### Beta APIs Off by Default
@ -98,7 +98,7 @@ for resizing existing persistent volumes.
[存储容量跟踪](https://github.com/kubernetes/enhancements/issues/1472)支持通过
[CSIStorageCapacity 对象](/zh-cn/docs/concepts/storage/storage-capacity/#api)公开当前可用的存储容量，
并增强使用具有后期绑定的 CSI 卷的 pod 的调度。
并增强使用具有后期绑定的 CSI 卷的 Pod 的调度。
[卷的扩展](https://github.com/kubernetes/enhancements/issues/284)增加了对调整现有持久性卷大小的支持。
@ -139,7 +139,7 @@ using an extra executable.
在 Kubernetes 1.24 中，[gRPC 探测功能](https://github.com/kubernetes/enhancements/issues/2727)
已进入测试版，默认可用。现在，你可以在 Kubernetes 中为你的 gRPC
应用程序原生地[配置启动、活跃度和就绪性探测](/zh-cn/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes)，
应用程序原生地[配置启动、存活和就绪性探测](/zh-cn/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes)，
而无需暴露 HTTP 端点或使用额外的可执行文件。
<!--
@ -202,10 +202,10 @@ Service `ClusterIP` are unique; hence, trying to create a Service with a `Cluste
After being deprecated in Kubernetes 1.22, Dynamic Kubelet Configuration has been removed from the kubelet. The feature will be removed from the API server in Kubernetes 1.26.
-->
### 从 Kubelet 中删除动态 Kubelet 配置
### 从 Kubelet 中移除动态 Kubelet 配置
在 Kubernetes 1.22 中被弃用后，动态 Kubelet 配置已从 kubelet 中删除。
该功能将从 Kubernetes 1.26 的 API 服务器中删除。
在 Kubernetes 1.22 中被弃用后，动态 Kubelet 配置已从 kubelet 中移除。
该功能将从 Kubernetes 1.26 的 API 服务器中移除。
<!--
## CNI Version-Related Breaking Change
@ -237,7 +237,7 @@ declare the CNI config version, you might encounter the following "Incompatible
CNI versions" or "Failed to destroy network for sandbox" error conditions.
-->
当 CNI 插件尚未升级和/或 CNI 配置版本未在 CNI 配置文件中声明时，在 containerd v1.6.0–v1.6.3
中存在 pod CNI 网络设置和拆除的服务问题。containerd 团队报告说，“这些问题在 containerd v1.6.4 中得到解决。”
中存在 Pod CNI 网络设置和拆除的服务问题。containerd 团队报告说，“这些问题在 containerd v1.6.4 中得到解决。”
在 containerd v1.6.0-v1.6.3 版本中，如果你不升级 CNI 插件和/或声明 CNI 配置版本，
你可能会遇到以下 “Incompatible CNI versions” 或 “Failed to destroy network for sandbox” 的错误情况。
@ -256,7 +256,7 @@ Volume snapshot and restore functionality for Kubernetes and the Container Stora
[VolumeSnapshot v1beta1 CRD 已被移除](https://github.com/kubernetes/enhancements/issues/177)。
Kubernetes 和容器存储接口 (CSI) 的卷快照和恢复功能，提供标准化的 API 设计 (CRD) 并添加了对 CSI 卷驱动程序的
PV 快照/恢复支持，在 v1.20 中移至 GA。VolumeSnapshot v1beta1 在 v1.20 中被弃用，现在不受支持。
PV 快照/恢复支持，在 v1.20 中升级至 GA。VolumeSnapshot v1beta1 在 v1.20 中被弃用，现在不受支持。
有关详细信息，请参阅 [KEP-177: CSI 快照](https://git.k8s.io/enhancements/keps/sig-storage/177-volume-snapshot#kep-177-csi-snapshot)
和[卷快照 GA 博客](/blog/2020/12/10/kubernetes-1.20-volume-snapshot-moves-to-ga/)。
@ -269,7 +269,7 @@ This release saw fourteen enhancements promoted to stable:
-->
## 其他更新
### 毕业到稳定
### 毕业到稳定版
在此版本中，有 14 项增强功能升级为稳定版：
@ -297,7 +297,7 @@ This release saw fourteen enhancements promoted to stable:
* [高效的监视恢复](https://github.com/kubernetes/enhancements/issues/1904)：
kube-apiserver 重新启动后，可以高效地恢复监视。
* [Service Type=LoadBalancer 类字段](https://github.com/kubernetes/enhancements/issues/1959)：
引入新的服务注解 `service.kubernetes.io/load-balancer-class` ，
引入新的服务注解 `service.kubernetes.io/load-balancer-class`，
允许在同一个集群中提供 `type: LoadBalancer` 服务的多个实现。
* [带索引的 Job](https://github.com/kubernetes/enhancements/issues/2214)：为带有固定完成计数的 Job 的 Pod 添加完成索引。
* [在 Job API 中增加 suspend 字段](https://github.com/kubernetes/enhancements/issues/2232)：
@ -317,12 +317,12 @@ This release saw two major changes:
* [Dockershim Removal](https://github.com/kubernetes/enhancements/issues/2221)
* [Beta APIs are off by Default](https://github.com/kubernetes/enhancements/issues/3136)
-->
### 主要变化
### 主要变更
此版本有两个主要变化：
此版本有两个主要变更：
* [Dockershim 移除](https://github.com/kubernetes/enhancements/issues/2221)
* [Beta APIs 默认关闭](https://github.com/kubernetes/enhancements/issues/3136)
* [移除 Dockershim](https://github.com/kubernetes/enhancements/issues/2221)
* [默认关闭 Beta API](https://github.com/kubernetes/enhancements/issues/3136)
<!--
### Release Notes
@ -361,7 +361,7 @@ release for the Kubernetes community.
-->
### 发布团队
如果没有组成 Kubernetes 1.24 发布团队的坚定个人的共同努力，这个版本是不可能实现的。
如果没有 Kubernetes 1.24 发布团队每个人做出的共同努力，这个版本是不可能实现的。
该团队齐心协力交付每个 Kubernetes 版本中的所有组件，包括代码、文档、发行说明等。
特别感谢我们的发布负责人 James Laverack 指导我们完成了一个成功的发布周期，
@ -394,7 +394,7 @@ is the work of hundreds of contributors across the globe and thousands of end-us
applications that serve millions. Every one is a star in our sky, helping us chart our course.
-->
古代天文学家到建造 James Webb 太空望远镜的科学家，几代人都怀着敬畏和惊奇的心情仰望星空。
星星启发了我们，点燃了我们的想象力，并引导我们在艰难的海上度过了漫长的夜晚。
是这些星辰启发了我们，点燃了我们的想象力，引导我们在艰难的海上度过了漫长的夜晚。
通过此版本，我们向上凝视，当我们的社区聚集在一起时可能发生的事情。
Kubernetes 是全球数百名贡献者和数千名最终用户支持的成果，
@ -450,7 +450,7 @@ all the stargazers out there. ✨
-->
### 生态系统更新
* KubeCon + CloudNativeCon Europe 2022 将于 2022 年 5 月 16 日至 20 日在西班牙巴伦西亚举行！
* KubeCon + CloudNativeCon Europe 2022 于 2022 年 5 月 16 日至 20 日在西班牙巴伦西亚举行！
你可以在[活动网站](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/)上找到有关会议和注册的更多信息。
* 在 [2021 年云原生调查](https://www.cncf.io/announcements/2022/02/10/cncf-sees-record-kubernetes-and-container-adoption-in-2021-cloud-native-survey/)
中，CNCF 看到了创纪录的 Kubernetes 和容器采用。参阅[调查结果](https://www.cncf.io/reports/cncf-annual-survey-2021/)。
@ -509,7 +509,7 @@ Have something you’d like to broadcast to the Kubernetes community? Share your
-->
## 参与进来
参与 Kubernetes 的最简单方法是加入符合你兴趣的众多 [特别兴趣组](https://git.k8s.io/community/sig-list.md)(SIG) 之一。
参与 Kubernetes 的最简单方法是加入符合你兴趣的众多[特别兴趣组](https://git.k8s.io/community/sig-list.md)（SIG）之一。
你有什么想向 Kubernetes 社区广播的内容吗？
在我们的每周的[社区会议](https://git.k8s.io/community/communication)上分享你的声音，并通过以下渠道：

334
content/zh-cn/blog/_posts/2022-07-13-gateway-api-in-beta.md Normal file
View File

@ -0,0 +1,334 @@
---
layout: blog
title: Kubernetes Gateway API 进入 Beta 阶段
date: 2022-07-13
slug: gateway-api-graduates-to-beta
---
<!--
layout: blog
title: Kubernetes Gateway API Graduates to Beta
date: 2022-07-13
slug: gateway-api-graduates-to-beta
canonicalUrl: https://gateway-api.sigs.k8s.io/blog/2022/graduating-to-beta/
-->
<!--
**Authors:** Shane Utt (Kong), Rob Scott (Google), Nick Young (VMware), Jeff Apple (HashiCorp)
-->
**作者：** Shane Utt (Kong)、Rob Scott (Google)、Nick Young (VMware)、Jeff Apple (HashiCorp)
<!--
We are excited to announce the v0.5.0 release of Gateway API. For the first
time, several of our most important Gateway API resources are graduating to
beta. Additionally, we are starting a new initiative to explore how Gateway API
can be used for mesh and introducing new experimental concepts such as URL
rewrites. We'll cover all of this and more below.
-->
我们很高兴地宣布 Gateway API 的 v0.5.0 版本发布。
我们最重要的几个 Gateway API 资源首次进入 Beta 阶段。
此外，我们正在启动一项新的倡议，探索如何将 Gateway API 用于网格，还引入了 URL 重写等新的实验性概念。
下文涵盖了这部分内容和更多说明。
<!--
## What is Gateway API?
-->
## 什么是 Gateway API？
<!--
Gateway API is a collection of resources centered around [Gateway][gw] resources
(which represent the underlying network gateways / proxy servers) to enable
robust Kubernetes service networking through expressive, extensible and
role-oriented interfaces that are implemented by many vendors and have broad
industry support.
-->
Gateway API 是以 [Gateway][gw] 资源（代表底层网络网关/代理服务器）为中心的资源集合，
Kubernetes 服务网络的健壮性得益于众多供应商实现、得到广泛行业支持且极具表达力、可扩展和面向角色的各个接口。
<!--
Originally conceived as a successor to the well known [Ingress][ing] API, the
benefits of Gateway API include (but are not limited to) explicit support for
many commonly used networking protocols (e.g. `HTTP`, `TLS`, `TCP`, `UDP`) as
well as tightly integrated support for Transport Layer Security (TLS). The
`Gateway` resource in particular enables implementations to manage the lifecycle
of network gateways as a Kubernetes API.
-->
Gateway API 最初被认为是知名 [Ingress][ing] API 的继任者，
Gateway API 的好处包括（但不限于）对许多常用网络协议的显式支持
（例如 `HTTP`、`TLS`、`TCP `、`UDP`) 以及对传输层安全 (TLS) 的紧密集成支持。
特别是 `Gateway` 资源能够实现作为 Kubernetes API 来管理网络网关的生命周期。
<!--
If you're an end-user interested in some of the benefits of Gateway API we
invite you to jump in and find an implementation that suits you. At the time of
this release there are over a dozen [implementations][impl] for popular API
gateways and service meshes and guides are available to start exploring quickly.
-->
如果你是对 Gateway API 的某些优势感兴趣的终端用户，我们邀请你加入并找到适合你的实现方式。
值此版本发布之时，对于流行的 API 网关和服务网格有十多种[实现][impl]，还提供了操作指南便于快速开始探索。
<!--
[gw]:https://gateway-api.sigs.k8s.io/api-types/gateway/
[ing]:https://kubernetes.io/docs/reference/kubernetes-api/service-resources/ingress-v1/
[impl]:https://gateway-api.sigs.k8s.io/implementations/
-->
[gw]:https://gateway-api.sigs.k8s.io/api-types/gateway/
[ing]:/zh-cn/docs/reference/kubernetes-api/service-resources/ingress-v1/
[impl]:https://gateway-api.sigs.k8s.io/implementations/
<!--
### Getting started
-->
### 入门
<!--
Gateway API is an official Kubernetes API like
[Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/).
Gateway API represents a superset of Ingress functionality, enabling more
advanced concepts. Similar to Ingress, there is no default implementation of
Gateway API built into Kubernetes. Instead, there are many different
[implementations][impl] available, providing significant choice in terms of underlying
technologies while providing a consistent and portable experience.
-->
Gateway API 是一个类似 [Ingress](/zh-cn/docs/concepts/services-networking/ingress/)
的正式 Kubernetes API。Gateway API 代表了 Ingress 功能的一个父集，使得一些更高级的概念成为可能。
与 Ingress 类似，Kubernetes 中没有内置 Gateway API 的默认实现。
相反，有许多不同的[实现][impl]可用，在提供一致且可移植体验的同时，还在底层技术方面提供了重要的选择。
<!--
Take a look at the [API concepts documentation][concepts] and check out some of
the [Guides][guides] to start familiarizing yourself with the APIs and how they
work. When you're ready for a practical application open the [implementations
page][impl] and select an implementation that belongs to an existing technology
you may already be familiar with or the one your cluster provider uses as a
default (if applicable). Gateway API is a [Custom Resource Definition
(CRD)][crd] based API so you'll need to [install the CRDs][install-crds] onto a
cluster to use the API.
-->
查看 [API 概念文档][concepts] 并查阅一些[指南][guides]以开始熟悉这些 API 及其工作方式。
当你准备好一个实用的应用程序时，
请打开[实现页面][impl]并选择属于你可能已经熟悉的现有技术或集群提供商默认使用的技术（如果适用）的实现。
Gateway API 是一个基于 [CRD][crd] 的 API，因此你将需要[安装 CRD][install-crds] 到集群上才能使用该 API。
<!--
If you're specifically interested in helping to contribute to Gateway API, we
would love to have you! Please feel free to [open a new issue][issue] on the
repository, or join in the [discussions][disc]. Also check out the [community
page][community] which includes links to the Slack channel and community meetings.
-->
如果你对 Gateway API 做贡献特别有兴趣，我们非常欢迎你的加入！
你可以随时在仓库上[提一个新的 issue][issue]，或[加入讨论][disc]。
另请查阅[社区页面][community]以了解 Slack 频道和社区会议的链接。
<!--
[crd]:https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/
[concepts]:https://gateway-api.sigs.k8s.io/concepts/api-overview/
[guides]:https://gateway-api.sigs.k8s.io/guides/getting-started/
[impl]:https://gateway-api.sigs.k8s.io/implementations/
[install-crds]:https://gateway-api.sigs.k8s.io/guides/getting-started/#install-the-crds
[issue]:https://github.com/kubernetes-sigs/gateway-api/issues/new/choose
[disc]:https://github.com/kubernetes-sigs/gateway-api/discussions
[community]:https://gateway-api.sigs.k8s.io/contributing/community/
-->
[crd]:/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/
[concepts]:https://gateway-api.sigs.k8s.io/concepts/api-overview/
[guides]:https://gateway-api.sigs.k8s.io/guides/getting-started/
[impl]:https://gateway-api.sigs.k8s.io/implementations/
[install-crds]:https://gateway-api.sigs.k8s.io/guides/getting-started/#install-the-crds
[issue]:https://github.com/kubernetes-sigs/gateway-api/issues/new/choose
[disc]:https://github.com/kubernetes-sigs/gateway-api/discussions
[community]:https://gateway-api.sigs.k8s.io/contributing/community/
<!--
## Release highlights
### Graduation to beta
-->
## 发布亮点
### 进入 Beta 阶段
<!--
The `v0.5.0` release is particularly historic because it marks the growth in
maturity to a beta API version (`v1beta1`) release for some of the key APIs:
-->
`v0.5.0` 版本特别具有历史意义，因为它标志着一些关键 API 成长至 Beta API 版本（`v1beta1`）：
- [GatewayClass](https://gateway-api.sigs.k8s.io/api-types/gatewayclass/)
- [Gateway](https://gateway-api.sigs.k8s.io/api-types/gateway/)
- [HTTPRoute](https://gateway-api.sigs.k8s.io/api-types/httproute/)
<!--
This achievement was marked by the completion of several graduation criteria:
- API has been [widely implemented][impl].
- Conformance tests provide basic coverage for all resources and have multiple implementations passing tests.
- Most of the API surface is actively being used.
- Kubernetes SIG Network API reviewers have approved graduation to beta.
-->
这一成就的标志是达到了以下几个进入标准：
- API 已[广泛实现][impl]。
- 合规性测试基本覆盖了所有资源且可以让多种实现通过测试。
- 大多数 API 接口正被积极地使用。
- Kubernetes SIG Network API 评审团队已批准其进入 Beta 阶段。
<!--
For more information on Gateway API versioning, refer to the [official
documentation](https://gateway-api.sigs.k8s.io/concepts/versioning/). To see
what's in store for future releases check out the [next steps](#next-steps)
section.
-->
有关 Gateway API 版本控制的更多信息，请参阅[官方文档](https://gateway-api.sigs.k8s.io/concepts/versioning/)。
要查看未来版本的计划，请查看[下一步](#next-steps)。
[impl]:https://gateway-api.sigs.k8s.io/implementations/
<!--
### Release channels
This release introduces the `experimental` and `standard` [release channels][ch]
which enable a better balance of maintaining stability while still enabling
experimentation and iterative development.
-->
### 发布渠道
此版本引入了 `experimental` 和 `standard` [发布渠道][ch]，
这样能够更好地保持平衡，在确保稳定性的同时，还能支持实验和迭代开发。
<!--
The `standard` release channel includes:
- resources that have graduated to beta
- fields that have graduated to standard (no longer considered experimental)
-->
`standard` 发布渠道包括：
- 已进入 Beta 阶段的资源
- 已进入 standard 的字段（不再被视为 experimental）
<!--
The `experimental` release channel includes everything in the `standard` release
channel, plus:
- `alpha` API resources
- fields that are considered experimental and have not graduated to `standard` channel
-->
`experimental` 发布渠道包括 `standard` 发布渠道的所有内容，另外还有：
- `alpha` API 资源
- 视为 experimental 且还未进入 `standard` 渠道的字段
<!--
Release channels are used internally to enable iterative development with
quick turnaround, and externally to indicate feature stability to implementors
and end-users.
-->
使用发布渠道能让内部实现快速流转的迭代开发，且能让外部实现者和最终用户标示功能稳定性。
<!--
For this release we've added the following experimental features:
- [Routes can attach to Gateways by specifying port numbers](https://gateway-api.sigs.k8s.io/geps/gep-957/)
- [URL rewrites and path redirects](https://gateway-api.sigs.k8s.io/geps/gep-726/)
-->
本次发布新增了以下实验性的功能特性：
- [路由通过指定端口号可以挂接到 Gateway](https://gateway-api.sigs.k8s.io/geps/gep-957/)
- [URL 重写和路径重定向](https://gateway-api.sigs.k8s.io/geps/gep-726/)
[ch]:https://gateway-api.sigs.k8s.io/concepts/versioning/#release-channels-eg-experimental-standard
<!--
### Other improvements
For an exhaustive list of changes included in the `v0.5.0` release, please see
the [v0.5.0 release notes](https://github.com/kubernetes-sigs/gateway-api/releases/tag/v0.5.0).
-->
### 其他改进
有关 `v0.5.0` 版本中包括的完整变更清单，请参阅
[v0.5.0 发布说明](https://github.com/kubernetes-sigs/gateway-api/releases/tag/v0.5.0)。
<!--
## Gateway API for service mesh: the GAMMA Initiative
Some service mesh projects have [already implemented support for the Gateway
API](https://gateway-api.sigs.k8s.io/implementations/). Significant overlap
between the Service Mesh Interface (SMI) APIs and the Gateway API has [inspired
discussion in the SMI
community](https://github.com/servicemeshinterface/smi-spec/issues/249) about
possible integration.
-->
## 适用于服务网格的 Gateway API：GAMMA 倡议
某些服务网格项目[已实现对 Gateway API 的支持](https://gateway-api.sigs.k8s.io/implementations/)。
服务网格接口 (Service Mesh Interface，SMI) API 和 Gateway API 之间的显著重叠
[已激发了 SMI 社区讨论](https://github.com/servicemeshinterface/smi-spec/issues/249)可能的集成方式。
<!--
We are pleased to announce that the service mesh community, including
representatives from Cilium Service Mesh, Consul, Istio, Kuma, Linkerd, NGINX
Service Mesh and Open Service Mesh, is coming together to form the [GAMMA
Initiative](https://gateway-api.sigs.k8s.io/contributing/gamma/), a dedicated
workstream within the Gateway API subproject focused on Gateway API for Mesh
Management and Administration.
-->
我们很高兴地宣布，来自 Cilium Service Mesh、Consul、Istio、Kuma、Linkerd、NGINX Service Mesh
和 Open Service Mesh 等服务网格社区的代表汇聚一堂组成
[GAMMA 倡议小组](https://gateway-api.sigs.k8s.io/contributing/gamma/)，
这是 Gateway API 子项目内一个专门的工作流，专注于网格管理所用的 Gateway API。
<!--
This group will deliver [enhancement
proposals](https://gateway-api.sigs.k8s.io/v1beta1/contributing/gep/) consisting
of resources, additions, and modifications to the Gateway API specification for
mesh and mesh-adjacent use-cases.
This work has begun with [an exploration of using Gateway API for
service-to-service
traffic](https://docs.google.com/document/d/1T_DtMQoq2tccLAtJTpo3c0ohjm25vRS35MsestSL9QU/edit#heading=h.jt37re3yi6k5)
and will continue with enhancement in areas such as authentication and
authorization policy.
-->
这个小组将交付[增强提案](https://gateway-api.sigs.k8s.io/v1beta1/contributing/gep/)，
包括对网格和网格相关用例适用的 Gateway API 规约的资源、添加和修改。
这项工作已从
[探索针对服务间流量使用 Gateway API](https://docs.google.com/document/d/1T_DtMQoq2tccLAtJTpo3c0ohjm25vRS35MsestSL9QU/edit#heading=h.jt37re3yi6k5)
开始，并将继续增强身份验证和鉴权策略等领域。
<!--
## Next steps
As we continue to mature the API for production use cases, here are some of the highlights of what we'll be working on for the next Gateway API releases:
- [GRPCRoute][gep1016] for [gRPC][grpc] traffic routing
- [Route delegation][pr1085]
- Layer 4 API maturity: Graduating [TCPRoute][tcpr], [UDPRoute][udpr] and
[TLSRoute][tlsr] to beta
- [GAMMA Initiative](https://gateway-api.sigs.k8s.io/contributing/gamma/) - Gateway API for Service Mesh
-->
## 下一步
随着我们不断完善用于生产用例的 API，以下是我们将为下一个 Gateway API 版本所做的一些重点工作：
- 针对 [gRPC][grpc] 流量路由的 [GRPCRoute][gep1016]
- [路由代理][pr1085]
- 4 层 API 成熟度：[TCPRoute][tcpr]、[UDPRoute][udpr] 和 [TLSRoute][tlsr] 正进入 Beta 阶段
- [GAMMA 倡议](https://gateway-api.sigs.k8s.io/contributing/gamma/) - 针对服务网格的 Gateway API
<!--
If there's something on this list you want to get involved in, or there's
something not on this list that you want to advocate for to get on the roadmap
please join us in the #sig-network-gateway-api channel on Kubernetes Slack or our weekly [community calls](https://gateway-api.sigs.k8s.io/contributing/community/#meetings).
-->
如果你想参与此列表中的某些工作，或者你想倡导加入路线图的内容不在此列表中，
请通过 Kubernetes Slack 的 #sig-network-gateway-api 频道或我们每周的
[社区电话会议](https://gateway-api.sigs.k8s.io/contributing/community/#meetings)加入我们。
[gep1016]:https://github.com/kubernetes-sigs/gateway-api/blob/master/site-src/geps/gep-1016.md
[grpc]:https://grpc.io/
[pr1085]:https://github.com/kubernetes-sigs/gateway-api/pull/1085
[tcpr]:https://github.com/kubernetes-sigs/gateway-api/blob/main/apis/v1alpha2/tcproute_types.go
[udpr]:https://github.com/kubernetes-sigs/gateway-api/blob/main/apis/v1alpha2/udproute_types.go
[tlsr]:https://github.com/kubernetes-sigs/gateway-api/blob/main/apis/v1alpha2/tlsroute_types.go
[community]:https://gateway-api.sigs.k8s.io/contributing/community/

245
content/zh-cn/case-studies/netease/index.html
View File

@ -1,105 +1,174 @@
---
title: 案例研究：NetEase
linkTitle: NetEase
case_study_styles: true
cid: caseStudies
css: /css/style_case_studies.css
logo: netease_featured_logo.png
featured: false
new_case_study_styles: true
heading_background: /images/case-studies/netease/banner1.jpg
heading_title_logo: /images/netease_logo.png
subheading: >
NetEase 如何利用 Kubernetes 支持在全球的互联网业务
case_study_details:
- 公司: NetEase
- 位置: Hangzhou， China
- 行业: 互联网科技
---
<!--
title: NetEase Case Study
linkTitle: NetEase
case_study_styles: true
cid: caseStudies
logo: netease_featured_logo.png
featured: false
<!-- <div class="banner1" style="background-image: url('/images/case-studies/netease/banner1.jpg')">
<h1> CASE STUDY:<img src="/images/netease_logo.png" class="header_logo" style="width:22%;margin-bottom:-1%"><br> <div class="subhead" style="margin-top:1%"> How NetEase Leverages Kubernetes to Support Internet Business Worldwide</div></h1>
new_case_study_styles: true
heading_background: /images/case-studies/netease/banner1.jpg
heading_title_logo: /images/netease_logo.png
subheading: >
How NetEase Leverages Kubernetes to Support Internet Business Worldwide
case_study_details:
- Company: NetEase
- Location: Hangzhou, China
- Industry: Internet technology
-->
</div> -->
<div class="banner1" style="background-image: url('/images/case-studies/netease/banner1.jpg')">
<h1> 案例研究：<img src="/images/netease_logo.png" class="header_logo" style="width:22%;margin-bottom:-1%"><br> <div class="subhead" style="margin-top:1%"> 网易如何利用 Kubernetes 支持在全球的互联网业务</div></h1>
<!--
<h2>Challenge</h2>
-->
<h2>挑战</h2>
</div>
<!--
<p>Its gaming business is one of the largest in the world, but that's not all that <a href="https://netease-na.com/">NetEase</a> provides to Chinese consumers. The company also operates e-commerce, advertising, music streaming, online education, and email platforms; the last of which serves almost a billion users with free email services through sites like <a href="https://www.163.com/">163.com</a>. In 2015, the NetEase Cloud team providing the infrastructure for all of these systems realized that their R&D process was slowing down developers. "Our users needed to prepare all of the infrastructure by themselves," says Feng Changjian, Architect for NetEase Cloud and Container Service. "We were eager to provide the infrastructure and tools for our users automatically via serverless container service."</p>
-->
<p>其游戏业务是世界上最大的游戏业务之一，但这不是 <a href="https://netease-na.com/">NetEase</a> 为中国消费者提供的所有。公司还经营电子商务、广告、音乐流媒体、在线教育和电子邮件平台；其中最后一个服务有近10亿用户通过网站使用免费的电子邮件服务，如 <a href="https://www.163.com/">163.com</a>。在2015 年，为所有这些系统提供基础设施的 NetEase Cloud 团队意识到，他们的研发流程正在减缓开发人员的速度。NetEase Cloud 和容器服务架构师 Feng Changjian 表示：“我们的用户需要自己准备所有基础设施。”“我们希望通过无服务器容器服务自动为用户提供基础设施和工具。”</p>
<!--
<h2>Solution</h2>
-->
<h2>解决方案</h2>
<div class="details" style="font-size:1em">
公司 &nbsp;<b>网易</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;位置 &nbsp;<b>杭州，中国</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;行业 &nbsp;<b>互联网科技</b>
</div>
<!--
<p>After considering building its own orchestration solution, NetEase decided to base its private cloud platform on <a href="https://kubernetes.io/">Kubernetes</a>. The fact that the technology came out of Google gave the team confidence that it could keep up with NetEase's scale. "After our 2-to-3-month evaluation, we believed it could satisfy our needs," says Feng. The team started working with Kubernetes in 2015, before it was even 1.0. Today, the NetEase internal cloud platform—which also leverages the CNCF projects <a href="https://prometheus.io/">Prometheus</a>, <a href="https://www.envoyproxy.io/">Envoy</a>, <a href="https://goharbor.io/">Harbor</a>, <a href="https://grpc.io/">gRPC</a>, and <a href="https://helm.sh/">Helm</a>—runs 10,000 nodes in a production cluster and can support up to 30,000 nodes in a cluster. Based on its learnings from its internal platform, the company introduced a Kubernetes-based cloud and microservices-oriented PaaS product, <a href="https://landscape.cncf.io/selected=netease-qingzhou-microservice">NetEase Qingzhou Microservice</a>, to outside customers.</p>
-->
<p>在考虑构建自己的业务流程解决方案后，NetEase 决定将其私有云平台建立在 <a href="https://kubernetes.io/">Kubernetes</a> 的基础上。这项技术来自 Google，这一事实让团队有信心，它能够跟上 NetEase 的规模。“经过2到3个月的评估，我们相信它能满足我们的需求，”Feng Changjian 说。该团队于 2015 年开始与 Kubernetes 合作，那会它甚至还不是 1.0 版本。如今，NetEase 内部云平台还使用了 CNCF 项目 <a href="https://prometheus.io/">Prometheus</a>、<a href="https://www.envoyproxy.io/">Envoy</a>、<a href="https://goharbor.io/">Harbor</a>、<a href="https://grpc.io/">gRPC</a> 和 <a href="https://helm.sh/">Helm</a>， 在生产集群中运行 10000 个节点，并可支持集群多达 30000 个节点。基于对内部平台的学习，公司向外部客户推出了基于 Kubernetes 的云和微服务型 PaaS 产品，NetEase 轻舟微服务。</p>
<hr>
<section class="section1">
<div class="cols">
<div class="col1" style="margin-left:-1.5% !important">
<h2>挑战</h2>
<!-- Its gaming business is one of the largest in the world, but that’s not all that <a href="https://netease-na.com/">NetEase</a> provides to Chinese consumers. The company also operates e-commerce, advertising, music streaming, online education, and email platforms; the last of which serves almost a billion users with free email services through sites like <a href="https://www.163.com/">163.com</a>. In 2015, the NetEase Cloud team providing the infrastructure for all of these systems realized that their R&D process was slowing down developers. “Our users needed to prepare all of the infrastructure by themselves,” says Feng Changjian, Architect for NetEase Cloud and Container Service. “We were eager to provide the infrastructure and tools for our users automatically via serverless container service.” -->
其游戏业务是世界上最大的游戏业务之一，但这不是<a href="https://netease-na.com/">网易</a>为中国消费者提供的所有。公司还经营电子商务、广告、音乐流媒体、在线教育和电子邮件平台；其中最后一个服务有近10亿用户通过网站使用免费的电子邮件服务，如<a href="https://www.163.com/">163.com</a>。2015 年，为所有这些系统提供基础设施的网易云团队意识到，他们的研发流程正在减缓开发人员的速度。网易云和容器服务架构师冯长健表示：“我们的用户需要自己准备所有基础设施。”“我们希望通过无服务器容器服务自动为用户提供基础设施和工具。”
<br><br>
<h2>解决方案</h2>
<!-- After considering building its own orchestration solution, NetEase decided to base its private cloud platform on <a href="https://kubernetes.io/">Kubernetes</a>. The fact that the technology came out of Google gave the team confidence that it could keep up with NetEase’s scale. “After our 2-to-3-month evaluation, we believed it could satisfy our needs,” says Feng. The team started working with Kubernetes in 2015, before it was even 1.0. Today, the NetEase internal cloud platform—which also leverages the CNCF projects <a href="https://prometheus.io/">Prometheus</a>, <a href="https://www.envoyproxy.io/">Envoy</a>, <a href="https://goharbor.io/">Harbor</a>, <a href="https://grpc.io/">gRPC</a>, and <a href="https://helm.sh/">Helm</a>—runs 10,000 nodes in a production cluster and can support up to 30,000 nodes in a cluster. Based on its learnings from its internal platform, the company introduced a Kubernetes-based cloud and microservices-oriented PaaS product, <a href="https://landscape.cncf.io/selected=netease-qingzhou-microservice">NetEase Qingzhou Microservice</a>, to outside customers. -->
在考虑构建自己的业务流程解决方案后，网易决定将其私有云平台建立在 <a href="https://kubernetes.io/">Kubernetes</a> 的基础上。这项技术来自 Google，这一事实让团队有信心，它能够跟上网易的规模。“经过2到3个月的评估，我们相信它能满足我们的需求，”冯长健说。该团队于 2015 年开始与 Kubernetes 合作，那会它甚至还不是1.0版本。如今，网易内部云平台还使用了 CNCF 项目 <a href="https://prometheus.io/">Prometheus</a>、<a href="https://www.envoyproxy.io/">Envoy</a>、<a href="https://goharbor.io/">Harbor</a>、<a href="https://grpc.io/">gRPC</a> 和 <a href="https://helm.sh/">Helm</a>， 在生产集群中运行 10000 个节点，并可支持集群多达 30000 个节点。基于对内部平台的学习，公司向外部客户推出了基于 Kubernetes 的云和微服务型 PaaS 产品，网易轻舟微服务。
<br><br>
<!--
<h2>Impact</h2>
-->
<h2>影响</h2>
<!-- The NetEase team reports that Kubernetes has increased R&D efficiency by more than 100%. Deployment efficiency has improved by 280%. “In the past, if we wanted to do upgrades, we needed to work with other teams, even in other departments,” says Feng. “We needed special staff to prepare everything, so it took about half an hour. Now we can do it in only 5 minutes.” The new platform also allows for mixed deployments using GPU and CPU resources. “Before, if we put all the resources toward the GPU, we won’t have spare resources for the CPU. But now we have improvements thanks to the mixed deployments,” he says. Those improvements have also brought an increase in resource utilization. -->
网易团队报告说，Kubernetes 已经提高了研发效率一倍多，部署效率提高了 2.8倍。“过去，如果我们想要进行升级，我们需要与其他团队合作，甚至加入其他部门，”冯长健说。“我们需要专人来准备一切，需要花费约半个小时。现在我们只需 5 分钟即可完成。”新平台还允许使用 GPU 和 CPU 资源进行混合部署。“以前，如果我们将所有资源都用于 GPU，则 CPU 的备用资源将没有。但是现在，由于混合部署，我们有了很大的改进，”他说。这些改进也提高了资源的利用率。
</div>
</div>
</section>
<div class="banner2">
<div class="banner2text">
<!-- "The system can support 30,000 nodes in a single cluster. In production, we have gotten the data of 10,000 nodes in a single cluster. The whole internal system is using this system for development, test, and production."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>— Zeng Yuxing, Architect, NetEase</span> -->
“系统可以在单个群集中支持 30000 个节点。在生产中，我们在单个群集中获取到了 10000 个节点的数据。整个内部系统都在使用该系统进行开发、测试和生产。”<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>— 曾宇兴,网易架构师</span>
</div>
</div>
<section class="section2">
<div class="fullcol">
<!-- <h2>Its gaming business is the <a href="https://newzoo.com/insights/rankings/top-25-companies-game-revenues/">fifth-largest</a> in the world, but that’s not all that <a href="https://netease-na.com/">NetEase</a> provides consumers.</h2>The company also operates e-commerce, advertising, music streaming, online education, and email platforms in China; the last of which serves almost a billion users with free email services through popular sites like <a href="https://www.163.com/">163.com</a> and <a href="https://www.126.com/">126.com</a>. With that kind of scale, the NetEase Cloud team providing the infrastructure for all of these systems realized in 2015 that their R&D process was making it hard for developers to keep up with demand. “Our users needed to prepare all of the infrastructure by themselves,” says Feng Changjian, Architect for NetEase Cloud and Container Service. “We were eager to provide the infrastructure and tools for our users automatically via serverless container service.”<br><br> -->
<h2>其游戏业务是世界<a href="https://newzoo.com/insights/rankings/top-25-companies-game-revenues/">第五大</a>游戏业务，但这不是<a href="https://netease-na.com/">网易</a>为消费者提供的所有业务。</h2>公司还在中国经营电子商务、广告、音乐流媒体、在线教育和电子邮件平台；其中最后一个服务是有近10亿用户使用的网站，如<a href="https://www.163.com/">163.com</a>和<a href="https://www.126.com/">126.com</a>免费电子邮件服务。有了这样的规模，为所有这些系统提供基础设施的网易云团队在 2015 年就意识到，他们的研发流程使得开发人员难以跟上需求。网易云和容器服务架构师冯长健表示：“我们的用户需要自己准备所有基础设施。”“我们渴望通过无服务器容器服务自动为用户提供基础设施和工具。”<br><br>
<!-- After considering building its own orchestration solution, NetEase decided to base its private cloud platform on <a href="https://kubernetes.io/">Kubernetes</a>. The fact that the technology came out of Google gave the team confidence that it could keep up with NetEase’s scale. “After our 2-to-3-month evaluation, we believed it could satisfy our needs,” says Feng. -->
在考虑构建自己的业务流程解决方案后，网易决定将其私有云平台建立在 <a href="https://kubernetes.io/">Kubernetes</a> 的基础上。这项技术来自谷歌，这一事实让团队有信心，它能够跟上网易的规模。“经过2到3个月的评估，我们相信它能满足我们的需求，”冯长健说。
</div>
</section>
<div class="banner3" style="background-image: url('/images/case-studies/netease/banner3.jpg')">
<div class="banner3text">
<!-- "We leveraged the programmability of Kubernetes so that we can build a platform to satisfy the needs of our internal customers for upgrades and deployment." -->
“我们利用 Kubernetes 的可编程性，构建一个平台，以满足内部客户对升级和部署的需求。”<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- 冯长健,网易云和容器托管平台架构师</span>
</div>
</div>
<section class="section3">
<div class="fullcol">
<!-- The team started adopting Kubernetes in 2015, before it was even 1.0, because it was relatively easy to use and enabled DevOps at the company. “We abandoned some of the concepts of Kubernetes; we only wanted to use the standardized framework,” says Feng. “We leveraged the programmability of Kubernetes so that we can build a platform to satisfy the needs of our internal customers for upgrades and deployment.”<br><br> -->
该团队于 2015 年开始采用 Kubernetes，那会它甚至还不是1.0版本，因为它相对易于使用，并且使 DevOps 在公司中得以实现。“我们放弃了 Kubernetes 的一些概念；我们只想使用标准化框架，”冯长健说。“我们利用 Kubernetes 的可编程性，构建一个平台，以满足内部客户对升级和部署的需求。”<br><br>
<!-- The team first focused on building the container platform to manage resources better, and then turned their attention to improving its support of microservices by adding internal systems such as monitoring. That has meant integrating the CNCF projects <a href="https://prometheus.io/">Prometheus</a>, <a href="https://www.envoyproxy.io/">Envoy</a>, <a href="https://goharbor.io/">Harbor</a>, <a href="https://grpc.io/">gRPC</a>, and <a href="https://helm.sh/">Helm</a>. “We are trying to provide a simplified and standardized process, so our users and customers can leverage our best practices,” says Feng.<br><br> -->
团队首先专注于构建容器平台以更好地管理资源，然后通过添加内部系统（如监视）来改进对微服务的支持。这意味着整合了 CNCF 项目 <a href="https://prometheus.io/">Prometheus</a>，<a href="https://www.envoyproxy.io/">Envoy</a>，<a href="https://goharbor.io/">Harbor</a>，<a href="https://grpc.io/">gRPC</a> 和 <a href="https://helm.sh/">Helm</a>。“我们正在努力提供简化和标准化的流程，以便我们的用户和客户能够利用我们的最佳实践，”冯长健说。<br><br>
<!-- And the team is continuing to make improvements. For example, the e-commerce part of the business needs to leverage mixed deployments, which in the past required using two separate platforms: the infrastructure-as-a-service platform and the Kubernetes platform. More recently, NetEase has created a cross-platform application that enables using both with one-command deployment. -->
团队正在继续改进。例如，企业的电子商务部分需要利用混合部署，过去需要使用两个单独的平台：基础架构即服务平台和 Kubernetes 平台。最近，网易创建了一个跨平台应用程序，支持将两者同时使用单命令部署。
</div>
</section>
<div class="banner4" style="background-image: url('/images/case-studies/netease/banner4.jpg')">
<div class="banner4text">
<!-- "As long as a company has a mature team and enough developers, I think Kubernetes is a very good technology that can help them."<span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br><br>- Li Lanqing, Kubernetes Developer, NetEase</span> -->
“只要公司拥有成熟的团队和足够的开发人员，我认为 Kubernetes 是一个很好的有所助力的技术。”<span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br><br>- 李兰青, 网易 Kubernetes 开发人员</span>
</div>
</div>
</div>
<!--
<p>The NetEase team reports that Kubernetes has increased R&D efficiency by more than 100%. Deployment efficiency has improved by 280%. "In the past, if we wanted to do upgrades, we needed to work with other teams, even in other departments," says Feng. "We needed special staff to prepare everything, so it took about half an hour. Now we can do it in only 5 minutes." The new platform also allows for mixed deployments using GPU and CPU resources. "Before, if we put all the resources toward the GPU, we won't have spare resources for the CPU. But now we have improvements thanks to the mixed deployments," he says. Those improvements have also brought an increase in resource utilization.</p>
-->
<p>NetEase 团队报告说，Kubernetes 已经提高了研发效率一倍多，部署效率提高了 2.8 倍。“过去，如果我们想要进行升级，我们需要与其他团队合作，甚至加入其他部门，”Feng Changjian 说。“我们需要专人来准备一切，需要花费约半个小时。现在我们只需 5 分钟即可完成。”新平台还允许使用 GPU 和 CPU 资源进行混合部署。“以前，如果我们将所有资源都用于 GPU，则 CPU 的备用资源将没有。但是现在，由于混合部署，我们有了很大的改进，”他说。这些改进也提高了资源的利用率。</p>
<section class="section5" style="padding:0px !important">
<div class="fullcol">
<!-- Today, the NetEase internal cloud platform “can support 30,000 nodes in a single cluster,” says Architect Zeng Yuxing. “In production, we have gotten the data of 10,000 nodes in a single cluster. The whole internal system is using this system for development, test, and production.” <br><br> -->
“系统可以在单个群集中支持 30000 个节点。在生产中，我们在单个群集中获取到了 10000 个节点的数据。整个内部系统都在使用该系统进行开发、测试和生产。”<br><br>
<!-- The NetEase team reports that Kubernetes has increased R&D efficiency by more than 100%. Deployment efficiency has improved by 280%. “In the past, if we wanted to do upgrades, we needed to work with other teams, even in other departments,” says Feng. “We needed special staff to prepare everything, so it took about half an hour. Now we can do it in only 5 minutes.” The new platform also allows for mixed deployments using GPU and CPU resources. “Before, if we put all the resources toward the GPU, we won’t have spare resources for the CPU. But now we have improvements thanks to the mixed deployments.” Those improvements have also brought an increase in resource utilization. -->
网易团队报告说，Kubernetes 已经提高了研发效率一倍多。部署效率提高了 2.8倍。“过去，如果我们想要进行升级，我们需要与其他团队合作，甚至加入其他部门，”冯长健说。“我们需要专人来准备一切，需要花费约半个小时。现在我们只需 5 分钟即可完成。”新平台还允许使用 GPU 和 CPU 资源进行混合部署。“以前，如果我们将所有资源都用于 GPU，则 CPU 的备用资源将没有。但是现在，由于混合部署，我们有了很大的改进，”他说。这些改进也提高了资源的利用率。
<!--
{{< case-studies/quote author="Zeng Yuxing, Architect, NetEase" >}}
"The system can support 30,000 nodes in a single cluster. In production, we have gotten the data of 10,000 nodes in a single cluster. The whole internal system is using this system for development, test, and production."
{{< /case-studies/quote >}}
-->
{{< case-studies/quote author="Zeng Yuxing，NetEase 架构师" >}}
“系统可以在单个集群中支持 30000 个节点。在生产中，我们在单个集群中获取到了 10000 个节点的数据。整个内部系统都在使用该系统进行开发、测试和生产。”
{{< /case-studies/quote >}}
</div>
<!--
{{< case-studies/lead >}}
Its gaming business is the <a href="https://newzoo.com/insights/rankings/top-25-companies-game-revenues/">fifth-largest</a> in the world, but that's not all that <a href="https://netease-na.com/">NetEase</a> provides consumers.
{{< /case-studies/lead >}}
-->
{{< case-studies/lead >}}
其游戏业务是世界<a href="https://newzoo.com/insights/rankings/top-25-companies-game-revenues/">第五大</a>游戏业务，但这不是 <a href="https://netease-na.com/">NetEase</a> 为消费者提供的所有业务。
{{< /case-studies/lead >}}
<div class="banner5">
<div class="banner5text">
<!-- "By engaging with this community, we can gain some experience from it and we can also benefit from it. We can see what are the concerns and the challenges faced by the community, so we can get involved."<span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br><br>- Li Lanqing, Kubernetes Developer, NetEase</span> -->
“通过与这个社区接触，我们可以从中获得一些经验，我们也可以从中获益。我们可以看到社区所关心的问题和挑战，以便我们参与其中。”<span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br><br>- 李兰青, 网易 Kubernetes 开发人员</span>
</div>
</div>
<div class="fullcol">
<!-- Based on the results and learnings from using its internal platform, the company introduced a Kubernetes-based cloud and microservices-oriented PaaS product, <a href="https://landscape.cncf.io/selected=netease-qingzhou-microservice">NetEase Qingzhou Microservice</a>, to outside customers. “The idea is that we can find the problems encountered by our game and e-commerce and cloud music providers, so we can integrate their experiences and provide a platform to satisfy the needs of our users,” says Zeng. <br><br> -->
基于使用内部平台的成果和学习，公司向外部客户推出了基于 Kubernetes 的云和微服务型 PaaS 产品，网易轻舟微服务。“我们的想法是，我们可以找到我们的游戏和电子商务以及云音乐提供商遇到的问题，所以我们可以整合他们的体验，并提供一个平台，以满足所有用户的需求，”曾宇兴说。<br><br>
<!-- With or without the use of the NetEase product, the team encourages other companies to try Kubernetes. “As long as a company has a mature team and enough developers, I think Kubernetes is a very good technology that can help them,” says Kubernetes developer Li Lanqing.<br><br> -->
无论是否使用网易产品，该团队鼓励其他公司尝试 Kubernetes。Kubernetes 开发者李兰青表示：“只要公司拥有成熟的团队和足够的开发人员，我认为 Kubernetes 是一个很好的技术，可以帮助他们。”<br><br>
<!-- As an end user as well as a vendor, NetEase has become more involved in the community, learning from other companies and sharing what they’ve done. The team has been contributing to the Harbor and Envoy projects, providing feedback as the technologies are being tested at NetEase scale. “We are a team focusing on addressing the challenges of microservices architecture,” says Feng. “By engaging with this community, we can gain some experience from it and we can also benefit from it. We can see what are the concerns and the challenges faced by the community, so we can get involved.” -->
作为最终用户和供应商，网易已经更多地参与社区，向其他公司学习，分享他们所做的工作。该团队一直在为 Harbor 和 Envoy 项目做出贡献，在网易进行规模测试技术时提供反馈。“我们是一个团队，专注于应对微服务架构的挑战，”冯长健说。“通过与这个社区接触，我们可以从中获得一些经验，我们也可以从中获益。我们可以看到社区所关心的问题和挑战，以便我们参与其中。”
</div>
</section>
<!--
<p>The company also operates e-commerce, advertising, music streaming, online education, and email platforms in China; the last of which serves almost a billion users with free email services through popular sites like <a href="https://www.163.com/">163.com</a> and <a href="https://www.126.com/">126.com</a>. With that kind of scale, the NetEase Cloud team providing the infrastructure for all of these systems realized in 2015 that their R&D process was making it hard for developers to keep up with demand. "Our users needed to prepare all of the infrastructure by themselves," says Feng Changjian, Architect for NetEase Cloud and Container Service. "We were eager to provide the infrastructure and tools for our users automatically via serverless container service."</p>
-->
<p>公司还在中国经营电子商务、广告、音乐流媒体、在线教育和电子邮件平台；其中最后一个服务是有近 10 亿用户使用的网站，如 <a href="https://www.163.com/">163.com</a> 和 <a href="https://www.126.com/">126.com</a> 免费电子邮件服务。有了这样的规模，为所有这些系统提供基础设施的 NetEase Cloud 团队在 2015 年就意识到，他们的研发流程使得开发人员难以跟上需求。NetEase Cloud 和容器服务架构师 Feng Changjian 表示：“我们的用户需要自己准备所有基础设施。”“我们渴望通过无服务器容器服务自动为用户提供基础设施和工具。”</p>
<!--
<p>After considering building its own orchestration solution, NetEase decided to base its private cloud platform on <a href="https://kubernetes.io/">Kubernetes</a>. The fact that the technology came out of Google gave the team confidence that it could keep up with NetEase's scale. "After our 2-to-3-month evaluation, we believed it could satisfy our needs," says Feng.</p>
-->
<p>在考虑构建自己的业务流程解决方案后，NetEase 决定将其私有云平台建立在 <a href="https://kubernetes.io/">Kubernetes</a> 的基础上。这项技术来自 Google，这一事实让团队有信心，它能够跟上 NetEase 的规模。“经过 2 到 3 个月的评估，我们相信它能满足我们的需求，”Feng Changjian 说。</p>
<!--
{{< case-studies/quote
image="/images/case-studies/netease/banner3.jpg"
author="Feng Changjian, Architect for NetEase Cloud and Container Service, NetEase"
>}}
"We leveraged the programmability of Kubernetes so that we can build a platform to satisfy the needs of our internal customers for upgrades and deployment."
{{< /case-studies/quote >}}
-->
{{< case-studies/quote
image="/images/case-studies/netease/banner3.jpg"
author="Feng Changjian，NetEase Cloud 和容器托管平台架构师"
>}}
“我们利用 Kubernetes 的可编程性，构建一个平台，以满足内部客户对升级和部署的需求。”
{{< /case-studies/quote >}}
<!--
<p>The team started adopting Kubernetes in 2015, before it was even 1.0, because it was relatively easy to use and enabled DevOps at the company. "We abandoned some of the concepts of Kubernetes; we only wanted to use the standardized framework," says Feng. "We leveraged the programmability of Kubernetes so that we can build a platform to satisfy the needs of our internal customers for upgrades and deployment."</p>
-->
<p>该团队于 2015 年开始采用 Kubernetes，那会它甚至还不是 1.0 版本，因为它相对易于使用，并且使 DevOps 在公司中得以实现。“我们放弃了 Kubernetes 的一些概念；我们只想使用标准化框架，”Feng Changjian 说。“我们利用 Kubernetes 的可编程性，构建一个平台，以满足内部客户对升级和部署的需求。”</p>
<!--
<p>The team first focused on building the container platform to manage resources better, and then turned their attention to improving its support of microservices by adding internal systems such as monitoring. That has meant integrating the CNCF projects <a href="https://prometheus.io/">Prometheus</a>, <a href="https://www.envoyproxy.io/">Envoy</a>, <a href="https://goharbor.io/">Harbor</a>, <a href="https://grpc.io/">gRPC</a>, and <a href="https://helm.sh/">Helm</a>. "We are trying to provide a simplified and standardized process, so our users and customers can leverage our best practices," says Feng.</p>
-->
<p>团队首先专注于构建容器平台以更好地管理资源，然后通过添加内部系统（如监视）来改进对微服务的支持。这意味着整合了 CNCF 项目 <a href="https://prometheus.io/">Prometheus</a>，<a href="https://www.envoyproxy.io/">Envoy</a>，<a href="https://goharbor.io/">Harbor</a>，<a href="https://grpc.io/">gRPC</a> 和 <a href="https://helm.sh/">Helm</a>。“我们正在努力提供简化和标准化的流程，以便我们的用户和客户能够利用我们的最佳实践，”Feng Changjian 说。</p>
<!--
<p>And the team is continuing to make improvements. For example, the e-commerce part of the business needs to leverage mixed deployments, which in the past required using two separate platforms: the infrastructure-as-a-service platform and the Kubernetes platform. More recently, NetEase has created a cross-platform application that enables using both with one-command deployment.</p>
-->
<p>团队正在继续改进。例如，企业的电子商务部分需要利用混合部署，过去需要使用两个单独的平台：基础架构即服务平台和 Kubernetes 平台。最近，NetEase 创建了一个跨平台应用程序，支持将两者同时使用单命令部署。</p>
<!--
{{< case-studies/quote
image="/images/case-studies/netease/banner4.jpg"
author="Li Lanqing, Kubernetes Developer, NetEase"
>}}
"As long as a company has a mature team and enough developers, I think Kubernetes is a very good technology that can help them."
{{< /case-studies/quote >}}
-->
{{< case-studies/quote
image="/images/case-studies/netease/banner4.jpg"
author="Li Lanqing，NetEase Kubernetes 开发人员"
>}}
“只要公司拥有成熟的团队和足够的开发人员，我认为 Kubernetes 是一个很好的有所助力的技术。”
{{< /case-studies/quote >}}
<!--
<p>Today, the NetEase internal cloud platform "can support 30,000 nodes in a single cluster," says Architect Zeng Yuxing. "In production, we have gotten the data of 10,000 nodes in a single cluster. The whole internal system is using this system for development, test, and production."</p>
-->
<p>“如今，系统可以在单个集群中支持 30000 个节点，“架构师 Zeng Yuxing 说。“在生产中，我们在单个集群中获取到了 10000 个节点的数据。整个内部系统都在使用该系统进行开发、测试和生产。”</p>
<!--
<p>The NetEase team reports that Kubernetes has increased R&D efficiency by more than 100%. Deployment efficiency has improved by 280%. "In the past, if we wanted to do upgrades, we needed to work with other teams, even in other departments," says Feng. "We needed special staff to prepare everything, so it took about half an hour. Now we can do it in only 5 minutes." The new platform also allows for mixed deployments using GPU and CPU resources. "Before, if we put all the resources toward the GPU, we won't have spare resources for the CPU. But now we have improvements thanks to the mixed deployments." Those improvements have also brought an increase in resource utilization.</p>
-->
<p>NetEase 团队报告说，Kubernetes 已经提高了研发效率一倍多。部署效率提高了 2.8 倍。“过去，如果我们想要进行升级，我们需要与其他团队合作，甚至加入其他部门，”Feng Changjian 说。“我们需要专人来准备一切，需要花费约半个小时。现在我们只需 5 分钟即可完成。”新平台还允许使用 GPU 和 CPU 资源进行混合部署。“以前，如果我们将所有资源都用于 GPU，则 CPU 的备用资源将没有。但是现在，由于混合部署，我们有了很大的改进，”他说。这些改进也提高了资源的利用率。</p>
<!--
{{< case-studies/quote author="Li Lanqing, Kubernetes Developer, NetEase">}}
"By engaging with this community, we can gain some experience from it and we can also benefit from it. We can see what are the concerns and the challenges faced by the community, so we can get involved."
{{< /case-studies/quote >}}
-->
{{< case-studies/quote author="Li Lanqing，NetEase Kubernetes 开发人员">}}
“通过与这个社区接触，我们可以从中获得一些经验，我们也可以从中获益。我们可以看到社区所关心的问题和挑战，以便我们参与其中。”
{{< /case-studies/quote >}}
<!--
<p>Based on the results and learnings from using its internal platform, the company introduced a Kubernetes-based cloud and microservices-oriented PaaS product, <a href="https://landscape.cncf.io/selected=netease-qingzhou-microservice">NetEase Qingzhou Microservice</a>, to outside customers. "The idea is that we can find the problems encountered by our game and e-commerce and cloud music providers, so we can integrate their experiences and provide a platform to satisfy the needs of our users," says Zeng.</p>
-->
<p>基于使用内部平台的成果和学习，公司向外部客户推出了基于 Kubernetes 的云和微服务型 PaaS 产品，<a href="https://landscape.cncf.io/selected=netease-qingzhou-microservice">NetEase 轻舟微服务</a>。“我们的想法是，我们可以找到我们的游戏和电子商务以及云音乐提供商遇到的问题，所以我们可以整合他们的体验，并提供一个平台，以满足所有用户的需求，”Zeng Yuxing 说。</p>
<!--
<p>With or without the use of the NetEase product, the team encourages other companies to try Kubernetes. "As long as a company has a mature team and enough developers, I think Kubernetes is a very good technology that can help them," says Kubernetes developer Li Lanqing.</p>
-->
<p>无论是否使用 NetEase 产品，该团队鼓励其他公司尝试 Kubernetes。Kubernetes 开发者 Li Lanqing 表示：“只要公司拥有成熟的团队和足够的开发人员，我认为 Kubernetes 是一个很好的技术，可以帮助他们。”</p>
<!--
<p>As an end user as well as a vendor, NetEase has become more involved in the community, learning from other companies and sharing what they've done. The team has been contributing to the Harbor and Envoy projects, providing feedback as the technologies are being tested at NetEase scale. "We are a team focusing on addressing the challenges of microservices architecture," says Feng. "By engaging with this community, we can gain some experience from it and we can also benefit from it. We can see what are the concerns and the challenges faced by the community, so we can get involved."</p>
-->
<p>作为最终用户和供应商，NetEase 已经更多地参与社区，向其他公司学习，分享他们所做的工作。该团队一直在为 Harbor 和 Envoy 项目做出贡献，在 NetEase 进行规模测试技术时提供反馈。“我们是一个团队，专注于应对微服务架构的挑战，”Feng Changjian 说。“通过与这个社区接触，我们可以从中获得一些经验，我们也可以从中获益。我们可以看到社区所关心的问题和挑战，以便我们参与其中。”</p>

1
content/zh-cn/case-studies/netease/netease_featured_logo.svg Normal file
View File

File diff suppressed because one or more lines are too long
Side by Side

After

Width:  |  Height:  |  Size: 26 KiB

271
content/zh-cn/case-studies/nordstrom/index.html
View File

@ -2,151 +2,156 @@
title: 案例研究：Nordstrom
case_study_styles: true
cid: caseStudies
css: /css/style_case_studies.css
new_case_study_styles: true
heading_background: /images/case-studies/nordstrom/banner1.jpg
heading_title_logo: /images/nordstrom_logo.png
subheading: >
在艰难的零售环境下寻找数百万的潜在成本节约
case_study_details:
- 公司: Nordstrom
- 地点: Seattle, Washington
- 行业: 零售
---
<!-- <div class="banner1" style="background-image: url('/images/case-studies/nordstrom/banner1.jpg')">
<h1> CASE STUDY:<img src="/images/nordstrom_logo.png" class="header_logo" style="margin-bottom:-1.5% !important;width:20% !important;"><br> <div class="subhead">Finding Millions in Potential Savings in a Tough Retail Climate
</div></h1>
</div> -->
<div class="banner1" style="background-image: url('/images/case-studies/nordstrom/banner1.jpg')">
<h1> 案例研究:<img src="/images/nordstrom_logo.png" class="header_logo" style="margin-bottom:-1.5% !important;width:20% !important;"><br> <div class="subhead">在艰难的零售环境下寻找数百万的潜在成本节约
</div></h1>
</div>
<!-- <div class="details">
Company &nbsp;<b>Nordstrom</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Seattle, Washington</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Retail</b>
</div> -->
<div class="details">
公司 &nbsp;<b>Nordstrom</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;地点 &nbsp;<b>西雅图, 华盛顿</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;行业 &nbsp;<b>零售</b>
</div>
<hr>
<section class="section1">
<div class="cols">
<div class="col1">
<!-- <h2>Challenge</h2>
Nordstrom wanted to increase the efficiency and speed of its technology operations, which includes the Nordstrom.com e-commerce site. At the same time, Nordstrom Technology was looking for ways to tighten its technology operational costs. -->
<!--
<h2>Challenge</h2>
-->
<h2>挑战</h2>
Nordstrom 希望提高其技术运营的效率和速度，其中包括 Nordstrom.com 电子商务网站。与此同时，Nordstrom 技术公司正在寻找压缩技术运营成本的方法。
<br>
<!-- <h2>Solution</h2>
After embracing a DevOps transformation and launching a continuous integration/continuous deployment (CI/CD) project four years ago, the company reduced its deployment time from three months to 30 minutes. But they wanted to go even faster across environments, so they began their cloud native journey, adopting Docker containers orchestrated with <a href="http://kubernetes.io/">Kubernetes</a>. -->
<!--
<p>Nordstrom wanted to increase the efficiency and speed of its technology operations, which includes the Nordstrom.com e-commerce site. At the same time, Nordstrom Technology was looking for ways to tighten its technology operational costs.</p>
-->
<p>Nordstrom 希望提高其技术运营的效率和速度，其中包括 Nordstrom.com 电子商务网站。与此同时，Nordstrom 技术公司正在寻找压缩技术运营成本的方法。</p>
<!--
<h2>Solution</h2>
-->
<h2>解决方案</h2>
在四年前采用 DevOps 转型并启动持续集成/部署 (CI/CD)项目后，该公司将部署时间从 3 个月缩短到 30 分钟。但是他们想在部署环境上走得更快，所以他们开始他们的云原生之旅，采用与<a href="http://kubernetes.io/"> Kubernetes </a>协调的Docker容器。
<br>
</div>
<div class="col2">
<!-- <h2>Impact</h2>
Nordstrom Technology developers using Kubernetes now deploy faster and can "just focus on writing applications," says Dhawal Patel, a senior engineer on the team building a Kubernetes enterprise platform for Nordstrom. Furthermore, the team has increased Ops efficiency, improving CPU utilization from 5x to 12x depending on the workload. "We run thousands of virtual machines (VMs), but aren’t effectively using all those resources," says Patel. "With Kubernetes, without even trying to make our cluster efficient, we are currently at a 10x increase." -->
<!--
<p>After embracing a DevOps transformation and launching a continuous integration/continuous deployment (CI/CD) project four years ago, the company reduced its deployment time from three months to 30 minutes. But they wanted to go even faster across environments, so they began their cloud native journey, adopting Docker containers orchestrated with <a href="http://kubernetes.io/">Kubernetes</a>.</p>
-->
<p>在四年前采用 DevOps 转型并启动持续集成/部署 (CI/CD)项目后，该公司将部署时间从 3 个月缩短到 30 分钟。但是他们想在部署环境上走得更快，所以他们开始他们的云原生之旅，采用与 <a href="http://kubernetes.io/">Kubernetes</a> 协调的 Docker 容器。</p>
<!--
<h2>Impact</h2>
-->
<h2>影响</h2>
为 Nordstrom 构建 Kubernetes 企业平台的团队高级工程师 Dhawal Patel 说，“使用 Kubernetes 的 Nordstrom 技术开发人员现在项目部署得更快，并且能够只专注于编写应用程序。”此外，该团队还提高了运营效率,根据工作负载将 CPU 利用率从 5 倍提高到 12 倍。Patel 说：“我们运行了数千台虚拟机 (VM),但无法有效地使用所有这些资源。借助 Kubernetes ,我们甚至不需要尝试去提高群集的效率,就能使运营效率增长 10 倍。”
</div>
</div>
</section>
<div class="banner2">
<div class="banner2text">
<!-- "We are always looking for ways to optimize and provide more value through technology. With Kubernetes we are showcasing two types of efficiency that we can bring: Dev efficiency and Ops efficiency. It’s a win-win." -->
“我们一直在寻找通过技术进行优化和提供更多价值的方法。通过 Kubernetes ，我们在开发效率和运营效率这两方面取得了示范性的提升。这是一个双赢。”
<!-- <br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>-— Dhawal Patel, senior engineer at Nordstrom</span> -->
<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>-— Dhawal Patel, Nordstrom 高级工程师</span>
</div>
</div>
<section class="section2">
<div class="fullcol">
<!-- When Dhawal Patel joined <a href="http://shop.nordstrom.com/">Nordstrom</a> five years ago as an application developer for the retailer’s website, he realized there was an opportunity to help speed up development cycles. -->
当 Dhawal Patel 五年前加入<a href="http://shop.nordstrom.com/"> Nordstrom </a>，担任该零售商网站的应用程序开发人员时，他意识到有机会帮助加快开发周期。
<br><br>
<!-- In those early DevOps days, Nordstrom Technology still followed a traditional model of silo teams and functions. "As a developer, I was spending more time fixing environments than writing code and adding value to business," Patel says. "I was passionate about that—so I was given the opportunity to help fix it." -->
在早期的 DevOps 时代,，Nordstrom 技术仍然遵循传统的孤岛团队和功能模型。Patel 说：“作为开发人员，我花在维护环境上的时间比编写代码和为业务增加价值的时间要多。我对此充满热情，因此我有机会参与帮助修复它。”
<br><br>
<!-- The company was eager to move faster, too, and in 2013 launched the first continuous integration/continuous deployment (CI/CD) project. That project was the first step in Nordstrom’s cloud native journey. -->
公司也渴望加快步伐，并在 2013 年启动了首个持续集成/部署 (CI/CD)项目。该项目是 Nordstrom 云原生之旅的第一步。
<br><br>
<!-- Dev and Ops team members built a CI/CD pipeline, working with the company’s servers on premise. The team chose <a href="https://www.chef.io/chef/">Chef</a>, and wrote cookbooks that automated virtual IP creation, servers, and load balancing. "After we completed the project, deployment went from three months to 30 minutes," says Patel. "We still had multiple environments—dev, test, staging, then production—so with each environment running the Chef cookbooks, it took 30 minutes. It was a huge achievement at that point." -->
开发人员和运营团队成员构建了一个 CI/CD 管道，在内部使用公司的服务器。团队选择了<a href="https://www.chef.io/chef/"> Chef </a>，并编写了自动虚拟 IP 创建、服务器和负载均衡的指导手册。Patel 说：“项目完成后,部署时间从 3 个月减少到 30 分钟。我们仍有开发、测试、暂存、然后生产等多个环境需要重新部署。之后，每个运行 Chef 说明书的环境部署都只花 30 分钟。在那个时候，这是一个巨大的成就。”
<br><br>
<!-- But new environments still took too long to turn up, so the next step was working in the cloud. Today, Nordstrom Technology has built an enterprise platform that allows the company’s 1,500 developers to deploy applications running as Docker containers in the cloud, orchestrated with Kubernetes. -->
但是，新环境仍然需要很长时间才能出现，因此下一步是在云中工作。如今，Nordstrom Technology 已经构建了一个企业平台，允许公司的1500 名开发人员在云中部署以 Docker 容器身份运行的应用程序，这些应用程序由 Kubernetes 进行编排。
</div>
</section>
<div class="banner3" style="background-image: url('/images/case-studies/nordstrom/banner3.jpg')">
<div class="banner3text">
<!-- "We made a bet that Kubernetes was going to take off, informed by early indicators of community support and project velocity, so we rebuilt our system with Kubernetes at the core," -->
<!--
<p>Nordstrom Technology developers using Kubernetes now deploy faster and can "just focus on writing applications," says Dhawal Patel, a senior engineer on the team building a Kubernetes enterprise platform for Nordstrom. Furthermore, the team has increased Ops efficiency, improving CPU utilization from 5x to 12x depending on the workload. "We run thousands of virtual machines (VMs), but aren't effectively using all those resources," says Patel. "With Kubernetes, without even trying to make our cluster efficient, we are currently at a 10x increase."</p>
-->
<p>为 Nordstrom 构建 Kubernetes 企业平台的团队高级工程师 Dhawal Patel 说，“使用 Kubernetes 的 Nordstrom 技术开发人员现在项目部署得更快，并且能够只专注于编写应用程序。”此外，该团队还提高了运营效率，根据工作负载将 CPU 利用率从 5 倍提高到 12 倍。Patel 说：“我们运行了数千台虚拟机（VM），但无法有效地使用所有这些资源。借助 Kubernetes，我们甚至不需要尝试去提高集群的效率，就能使运营效率增长 10 倍。”</p>
<!--
{{< case-studies/quote author="Dhawal Patel, senior engineer at Nordstrom" >}}
"We are always looking for ways to optimize and provide more value through technology. With Kubernetes we are showcasing two types of efficiency that we can bring: Dev efficiency and Ops efficiency. It's a win-win."
{{< /case-studies/quote >}}
-->
{{< case-studies/quote author="Dhawal Patel， Nordstrom 高级工程师" >}}
“我们一直在寻找通过技术进行优化和提供更多价值的方法。通过 Kubernetes，我们在开发效率和运营效率这两方面取得了示范性的提升。这是一个双赢。”
{{< /case-studies/quote >}}
<!--
<p>When Dhawal Patel joined <a href="http://shop.nordstrom.com/">Nordstrom</a> five years ago as an application developer for the retailer's website, he realized there was an opportunity to help speed up development cycles.</p> -->
<p>当 Dhawal Patel 五年前加入 <a href="http://shop.nordstrom.com/">Nordstrom</a>，担任该零售商网站的应用程序开发人员时，他意识到有机会帮助加快开发周期。</p>
<!--
<p>In those early DevOps days, Nordstrom Technology still followed a traditional model of silo teams and functions. "As a developer, I was spending more time fixing environments than writing code and adding value to business," Patel says. "I was passionate about that—so I was given the opportunity to help fix it."</p>
-->
<p>在早期的 DevOps 时代，Nordstrom 技术仍然遵循传统的孤岛团队和功能模型。Patel 说：“作为开发人员，我花在维护环境上的时间比编写代码和为业务增加价值的时间要多。我对此充满热情，因此我有机会参与帮助修复它。”</p>
<!--
<p>The company was eager to move faster, too, and in 2013 launched the first continuous integration/continuous deployment (CI/CD) project. That project was the first step in Nordstrom's cloud native journey.</p>
-->
<p>公司也渴望加快步伐，并在 2013 年启动了首个持续集成/部署（CI/CD）项目。该项目是 Nordstrom 云原生之旅的第一步。</p>
<!--
<p>Dev and Ops team members built a CI/CD pipeline, working with the company's servers on premise. The team chose <a href="https://www.chef.io/chef/">Chef</a>, and wrote cookbooks that automated virtual IP creation, servers, and load balancing. "After we completed the project, deployment went from three months to 30 minutes," says Patel. "We still had multiple environments—dev, test, staging, then production—so with each environment running the Chef cookbooks, it took 30 minutes. It was a huge achievement at that point."</p>
-->
<p>开发人员和运营团队成员构建了一个 CI/CD 管道，在内部使用公司的服务器。团队选择了 <a href="https://www.chef.io/chef/">Chef</a>，并编写了自动虚拟 IP 创建、服务器和负载均衡的指导手册。Patel 说：“项目完成后，部署时间从 3 个月减少到 30 分钟。我们仍有开发、测试、暂存、然后生产等多个环境需要重新部署。之后，每个运行 Chef 说明书的环境部署都只花 30 分钟。在那个时候，这是一个巨大的成就。”</p>
<!--
<p>But new environments still took too long to turn up, so the next step was working in the cloud. Today, Nordstrom Technology has built an enterprise platform that allows the company's 1,500 developers to deploy applications running as Docker containers in the cloud, orchestrated with Kubernetes.</p> -->
<p>但是，新环境仍然需要很长时间才能出现，因此下一步是在云中工作。如今，Nordstrom Technology 已经构建了一个企业平台，允许公司的 1500 名开发人员在云中部署以 Docker 容器身份运行的应用程序，这些应用程序由 Kubernetes 进行编排。</p>
<!--
{{< case-studies/quote image="/images/case-studies/nordstrom/banner3.jpg" >}}
"We made a bet that Kubernetes was going to take off, informed by early indicators of community support and project velocity, so we rebuilt our system with Kubernetes at the core,"
{{< /case-studies/quote >}}
-->
{{< case-studies/quote image="/images/case-studies/nordstrom/banner3.jpg" >}}
“了解到早期的社区支持和项目迭代指标，我们肯定 Kubernetes 一定会成功的，因此我们以 Kubernetes 为核心重建了我们的系统。”
</div>
</div>
<section class="section3">
<div class="fullcol">
{{< /case-studies/quote >}}
<!-- "The cloud provided faster access to resources, because it took weeks for us to get a virtual machine (VM) on premises," says Patel. "But now we can do the same thing in only five minutes." -->
Patel 说：“云提供了对资源的更快访问,因为我们在内部需要花数周时间才能部署一个虚拟机 (VM)来提供服务。但现在我们可以做同样的事情，只需五分钟。”
<br><br>
<!-- Nordstrom’s first foray into scheduling containers on a cluster was a homegrown system based on CoreOS fleet. They began doing a few proofs of concept projects with that system until Kubernetes 1.0 was released when they made the switch. "We made a bet that Kubernetes was going to take off, informed by early indicators of community support and project velocity, so we rebuilt our system with Kubernetes at the core," says Marius Grigoriu, Sr. Manager of the Kubernetes team at Nordstrom. -->
Nordstrom 首次尝试在集群上调度容器，是基于 CoreOS fleet 的原生系统。他们开始使用该系统做一些概念验证项目，直到 Kubernetes 1.0发布时才将正式项目迁移到里面。Nordstrom 的 Kubernetes 团队经理 Marius Grigoriu 表示：“了解到早期的社区支持和项目迭代指标，我们肯定 Kubernetes 一定会成功的，因此我们以 Kubernetes 为核心重建了我们的系统。”
<!-- While Kubernetes is often thought as a platform for microservices, the first application to launch on Kubernetes in a critical production role at Nordstrom was Jira. "It was not the ideal microservice we were hoping to get as our first application," Patel admits, "but the team that was working on it was really passionate about Docker and Kubernetes, and they wanted to try it out. They had their application running on premises, and wanted to move it to Kubernetes." -->
虽然 Kubernetes 通常被视为微服务的平台，但在 Nordstrom 担任关键生产角色的 Kubernetes 上推出的第一个应用程序是 Jira。Patel 承认：“这不是我们希望作为第一个应用程序获得的理想微服务，但致力于此应用程序的团队对 Docker 和 Kubernetes 非常热情，他们希望尝试一下。他们的应用程序部署在内部运行，并希望将其移动到 Kubernetes。
<br><br>
<!-- The benefits were immediate for the teams that came on board. "Teams running on our Kubernetes cluster loved the fact that they had fewer issues to worry about. They didn’t need to manage infrastructure or operating systems," says Grigoriu. "Early adopters loved the declarative nature of Kubernetes. They loved the reduced surface area they had to deal with." -->
对于加入的团队来说,这些好处是立竿见影的。Grigoriu 说：“在我们的 Kubernetes 集群中运行的团队喜欢这样一个事实，即他们担心的问题更少，他们不需要管理基础设施或操作系统。早期使用者喜欢 Kubernetes 的声明特性，让他们不得不处理的面积减少。
</div>
</section>
<div class="banner4" style="background-image: url('/images/case-studies/nordstrom/banner4.jpg')">
<div class="banner4text">
<!-- "Teams running on our Kubernetes cluster loved the fact that they had fewer issues to worry about. They didn’t need to manage infrastructure or operating systems," says Grigoriu. "Early adopters loved the declarative nature of Kubernetes. They loved the reduced surface area they had to deal with." -->
<!--
<p>"The cloud provided faster access to resources, because it took weeks for us to get a virtual machine (VM) on premises," says Patel. "But now we can do the same thing in only five minutes."</p>
-->
<p>Patel 说：“云提供了对资源的更快访问，因为我们在内部需要花数周时间才能部署一个虚拟机（VM）来提供服务。但现在我们可以做同样的事情，只需五分钟。”</p>
<!--
<p>Nordstrom's first foray into scheduling containers on a cluster was a homegrown system based on CoreOS fleet. They began doing a few proofs of concept projects with that system until Kubernetes 1.0 was released when they made the switch. "We made a bet that Kubernetes was going to take off, informed by early indicators of community support and project velocity, so we rebuilt our system with Kubernetes at the core," says Marius Grigoriu, Sr. Manager of the Kubernetes team at Nordstrom.</p>
-->
<p>Nordstrom 首次尝试在集群上调度容器，是基于 CoreOS fleet 的原生系统。他们开始使用该系统做一些概念验证项目，直到 Kubernetes 1.0 发布时才将正式项目迁移到里面。Nordstrom 的 Kubernetes 团队经理 Marius Grigoriu 表示：“了解到早期的社区支持和项目迭代指标，我们肯定 Kubernetes 一定会成功的，因此我们以 Kubernetes 为核心重建了我们的系统。”</p>
<!--
<p>While Kubernetes is often thought as a platform for microservices, the first application to launch on Kubernetes in a critical production role at Nordstrom was Jira. "It was not the ideal microservice we were hoping to get as our first application," Patel admits, "but the team that was working on it was really passionate about Docker and Kubernetes, and they wanted to try it out. They had their application running on premises, and wanted to move it to Kubernetes."</p>
-->
<p>虽然 Kubernetes 通常被视为微服务的平台，但在 Nordstrom 担任关键生产角色的 Kubernetes 上推出的第一个应用程序是 Jira。Patel 承认：“这不是我们希望作为第一个应用程序获得的理想微服务，但致力于此应用程序的团队对 Docker 和 Kubernetes 非常热情，他们希望尝试一下。他们的应用程序部署在内部运行，并希望将其移动到 Kubernetes。</p>
<!--
<p>The benefits were immediate for the teams that came on board. "Teams running on our Kubernetes cluster loved the fact that they had fewer issues to worry about. They didn't need to manage infrastructure or operating systems," says Grigoriu. "Early adopters loved the declarative nature of Kubernetes. They loved the reduced surface area they had to deal with."</p> -->
<p>对于加入的团队来说，这些好处是立竿见影的。Grigoriu 说：“在我们的 Kubernetes 集群中运行的团队喜欢这样一个事实，即他们担心的问题更少，他们不需要管理基础设施或操作系统。早期使用者喜欢 Kubernetes 的声明特性，让他们不得不处理的面积减少。</p>
<!--
{{< case-studies/quote image="/images/case-studies/nordstrom/banner4.jpg">}}
"Teams running on our Kubernetes cluster loved the fact that they had fewer issues to worry about. They didn't need to manage infrastructure or operating systems," says Grigoriu. "Early adopters loved the declarative nature of Kubernetes. They loved the reduced surface area they had to deal with."
{{< /case-studies/quote >}}
-->
{{< case-studies/quote image="/images/case-studies/nordstrom/banner4.jpg">}}
Grigoriu 说：“在我们的 Kubernetes 集群中运行的团队喜欢这样一个事实，即他们担心的问题更少，他们不需要管理基础设施或操作系统。早期使用者喜欢 Kubernetes 的声明特性，让他们不得不处理的面积减少。”
</div>
</div>
{{< /case-studies/quote >}}
<section class="section5">
<div class="fullcol">
<!-- To support these early adopters, Patel’s team began growing the cluster and building production-grade services. "We integrated with <a href="https://prometheus.io/">Prometheus</a> for monitoring, with a <a href="https://grafana.com/">Grafana</a> front end; we used <a href="http://www.fluentd.org/">Fluentd</a> to push logs to <a href="https://www.elastic.co/">Elasticsearch</a>, so that gives us log aggregation," says Patel. The team also added dozens of open-source components, including CNCF projects and has made contributions to Kubernetes, Terraform, and kube2iam. -->
为了支持这些早期使用者，Patel 的团队开始发展集群并构建生产级服务。“我们与<a href="https://prometheus.io/"> Prometheus </a>集成了监控功能，并配有<a href="https://grafana.com/"> Grafana </a>前端；我们使用<a href="http://www.fluentd.org/"> Fluentd </a>将日志推送到<a href="https://www.elastic.co/"> Elasticsearch </a>，从而提供日志聚合”Patel 说。该团队还增加了数十个开源组件，包括 CNCF 项目，而且把这些成果都贡献给了 Kubernetes 、Terraform 和 kube2iam 。
<br><br>
<!-- There are now more than 60 development teams running Kubernetes in Nordstrom Technology, and as success stories have popped up, more teams have gotten on board. "Our initial customer base, the ones who were willing to try this out, are now going and evangelizing to the next set of users," says Patel. "One early adopter had Docker containers and he was not sure how to run it in production. We sat with him and within 15 minutes we deployed it in production. He thought it was amazing, and more people in his org started coming in." -->
现在有60多个开发团队在 Nordstrom 上运行 Kubernetes ，随着成功案例的涌现，更多的团队加入
进来。Patel 说：“我们最初的客户群，那些愿意尝试这些的客户群，现在已经开始向后续用户宣传。一个早期使用者拥有 Docker 容器，他不知道如何在生产中运行它。我们和他坐在一起，在15分钟内，我们将其部署到生产中。他认为这是惊人的，他所在的组织更多的人开始加入进来。”
<br><br>
<!-- For Nordstrom Technology, going cloud-native has vastly improved development and operational efficiency. The developers using Kubernetes now deploy faster and can focus on building value in their applications. One such team started with a 25-minute merge to deploy by launching virtual machines in the cloud. Switching to Kubernetes was a 5x speedup in their process, improving their merge to deploy time to 5 minutes. -->
对于 Nordstrom 而言，云原生极大地提高了开发和运营
效率。现在，使用 Kubernetes 的开发人员部署速度更快，可以专注于在其应用程序中构建价值。一个团队从 25 分钟的合并开始，通过在云中启动虚拟机来进行部署。切换到 Kubernetes 的过程速度是原来 5 倍，将合并时间缩短为 5 分钟。
</div>
<!--
<p>To support these early adopters, Patel's team began growing the cluster and building production-grade services. "We integrated with <a href="https://prometheus.io/">Prometheus</a> for monitoring, with a <a href="https://grafana.com/">Grafana</a> front end; we used <a href="http://www.fluentd.org/">Fluentd</a> to push logs to <a href="https://www.elastic.co/">Elasticsearch</a>, so that gives us log aggregation," says Patel. The team also added dozens of open-source components, including CNCF projects and has made contributions to Kubernetes, Terraform, and kube2iam.</p>
-->
<p>为了支持这些早期使用者，Patel 的团队开始发展集群并构建生产级服务。“我们与 <a href="https://prometheus.io/">Prometheus</a> 集成了监控功能，并配有 <a href="https://grafana.com/">Grafana</a> 前端；我们使用 <a href="http://www.fluentd.org/">Fluentd</a> 将日志推送到 <a href="https://www.elastic.co/">Elasticsearch</a>，从而提供日志聚合”Patel 说。该团队还增加了数十个开源组件，包括 CNCF 项目，而且把这些成果都贡献给了 Kubernetes、Terraform 和 kube2iam。</p>
<div class="banner5">
<div class="banner5text">
<!-- "With Kubernetes, without even trying to make our cluster efficient, we are currently at 40 percent CPU utilization—a 10x increase. we are running 2600+ customer pods that would have been 2600+ VMs if they had gone directly to the cloud. We are running them on 40 VMs now, so that’s a huge reduction in operational overhead." -->
“借助 Kubernetes ，我们甚至不需要尝试去提高群集的效率，目前 CPU 利用率为 40%，较之前增长了 10 倍。我们正在运行 2600 多个客户 pod ，如果它们直接进入云，这些 Pod 将是 2600 多个 VM。我们现在在 40 台 VM 上运行它们，因此这大大降低了运营开销。
</div>
</div>
<!--
<p>There are now more than 60 development teams running Kubernetes in Nordstrom Technology, and as success stories have popped up, more teams have gotten on board. "Our initial customer base, the ones who were willing to try this out, are now going and evangelizing to the next set of users," says Patel. "One early adopter had Docker containers and he was not sure how to run it in production. We sat with him and within 15 minutes we deployed it in production. He thought it was amazing, and more people in his org started coming in."</p>
-->
<p>现在有 60 多个开发团队在 Nordstrom 上运行 Kubernetes，随着成功案例的涌现，更多的团队加入进来。Patel 说：“我们最初的客户群，那些愿意尝试这些的客户群，现在已经开始向后续用户宣传。一个早期使用者拥有 Docker 容器，他不知道如何在生产中运行它。我们和他一起协作，在 15 分钟内，我们将其部署到生产中。他认为这是惊人的，他所在的组织更多的人开始加入进来。”</p>
<div class="fullcol">
<!-- Speed is great, and easily demonstrated, but perhaps the bigger impact lies in the operational efficiency. "We run thousands of VMs on AWS, and their overall average CPU utilization is about four percent," says Patel. "With Kubernetes, without even trying to make our cluster efficient, we are currently at 40 percent CPU utilization—a 10x increase. We are running 2600+ customer pods that would have been 2600+ VMs if they had gone directly to the cloud. We are running them on 40 VMs now, so that’s a huge reduction in operational overhead." -->
速度是伟大的，并且很容易证明，但也许更大的影响在于运营效率。Patel 说：“我们在 AWS 上运行了数千个 VM ，它们的总体平均 CPU 利用率约为 4%。借助 Kubernetes ，我们甚至不需要尝试去提高群集的效率，目前 CPU 利用率为 40%，较之前增长了 10 倍。我们正在运行 2600 多个客户 pod ，如果它们直接进入云，这些 Pod 将是 2600 多个 VM。我们现在在 40 台 VM 上运行它们，因此这大大降低了运营开销。
<br><br>
<!-- Nordstrom Technology is also exploring running Kubernetes on bare metal on premises. "If we can build an on-premises Kubernetes cluster," says Patel, "we could bring the power of cloud to provision resources fast on-premises. Then for the developer, their interface is Kubernetes; they might not even realize or care that their services are now deployed on premises because they’re only working with Kubernetes." -->
Patel 说：“如果我们能构建一个本地 Kubernetes 集群，我们就能将云的力量带到本地快速调配资源。然后，对于开发人员，他们的接口是Kubernetes；他们甚至可能没有意识到或不关心他们的服务现在部署在内部，因为他们只与 Kubernetes 合作。
<!-- For that reason, Patel is eagerly following Kubernetes’ development of multi-cluster capabilities. "With cluster federation, we can have our on-premise as the primary cluster and the cloud as a secondary burstable cluster," he says. "So, when there is an anniversary sale or Black Friday sale, and we need more containers - we can go to the cloud." -->
因此，Patel 热切关注 Kubernetes 多集群能力的发展。他说：“有了集群联合，我们可以将内部部署作为主群集，将云作为辅助可突发集群。因此,当有周年销售或黑色星期五销售,我们需要更多的容器时，我们可以去云。”
<br><br>
<!-- That kind of possibility—as well as the impact that Grigoriu and Patel’s team has already delivered using Kubernetes—is what led Nordstrom on its cloud native journey in the first place. "The way the retail environment is today, we are trying to build responsiveness and flexibility where we can," says Grigoriu. "Kubernetes makes it easy to: bring efficiency to both the Dev and Ops side of the equation. It’s a win-win." -->
这种可能性以及 Grigoriu 和 Patel 的团队已经使用Kubernetes所提供的影响，是 Nordstrom 最初在云原生之旅中所起
的作用。Grigoriu 说：“在当下的零售模式下，我们正在努力在力所能及的地方建立响应能力和灵活性。Kubernetes 使得为开发端和运维端同时带来效率的提升，这是一个双赢。”
</div>
</section>
<!--
<p>For Nordstrom Technology, going cloud-native has vastly improved development and operational efficiency. The developers using Kubernetes now deploy faster and can focus on building value in their applications. One such team started with a 25-minute merge to deploy by launching virtual machines in the cloud. Switching to Kubernetes was a 5x speedup in their process, improving their merge to deploy time to 5 minutes.</p>
-->
<p>对于 Nordstrom 而言，云原生极大地提高了开发和运营效率。现在，使用 Kubernetes 的开发人员部署速度更快，可以专注于在其应用程序中构建价值。一个团队从 25 分钟的合并开始，通过在云中启动虚拟机来进行部署。切换到 Kubernetes 的过程速度是原来 5 倍，将合并时间缩短为 5 分钟。</p>
<!--
{{< case-studies/quote >}}
"With Kubernetes, without even trying to make our cluster efficient, we are currently at 40 percent CPU utilization—a 10x increase. we are running 2600+ customer pods that would have been 2600+ VMs if they had gone directly to the cloud. We are running them on 40 VMs now, so that's a huge reduction in operational overhead."
{{< /case-studies/quote >}}
-->
{{< case-studies/quote >}}
“借助 Kubernetes，我们甚至不需要尝试去提高集群的效率，目前 CPU 利用率为 40%，较之前增长了 10 倍。我们正在运行 2600 多个客户 Pod，如果它们直接进入云，这些 Pod 将是 2600 多个 VM。我们现在在 40 台 VM 上运行它们，因此这大大降低了运营开销。
{{< /case-studies/quote >}}
<!--
<p>Speed is great, and easily demonstrated, but perhaps the bigger impact lies in the operational efficiency. "We run thousands of VMs on AWS, and their overall average CPU utilization is about four percent," says Patel. "With Kubernetes, without even trying to make our cluster efficient, we are currently at 40 percent CPU utilization—a 10x increase. We are running 2600+ customer pods that would have been 2600+ VMs if they had gone directly to the cloud. We are running them on 40 VMs now, so that's a huge reduction in operational overhead."</p>
-->
<p>速度很重要，并且很容易证明，但也许更大的影响在于运营效率。Patel 说：“我们在 AWS 上运行了数千个 VM，它们的总体平均 CPU 利用率约为 4%。借助 Kubernetes，我们甚至不需要尝试去提高集群的效率，目前 CPU 利用率为 40%，较之前增长了 10 倍。我们正在运行 2600 多个客户 Pod，如果它们直接上云，这些 Pod 将是 2600 多个 VM。我们现在在 40 台 VM 上运行它们，因此这大大降低了运营开销。</p>
<!--
<p>Nordstrom Technology is also exploring running Kubernetes on bare metal on premises. "If we can build an on-premises Kubernetes cluster," says Patel, "we could bring the power of cloud to provision resources fast on-premises. Then for the developer, their interface is Kubernetes; they might not even realize or care that their services are now deployed on premises because they're only working with Kubernetes."</p>
-->
<p>Patel 说：“如果我们能构建一个本地 Kubernetes 集群，我们就能将云的力量带到本地快速调配资源。之后对于开发人员来说，他们面向的接口是 Kubernetes；他们甚至可能没有意识到或不关心他们的服务现在部署在内部，因为他们只与 Kubernetes 一起工作。</p>
<!--
<p>For that reason, Patel is eagerly following Kubernetes' development of multi-cluster capabilities. "With cluster federation, we can have our on-premise as the primary cluster and the cloud as a secondary burstable cluster," he says. "So, when there is an anniversary sale or Black Friday sale, and we need more containers - we can go to the cloud."</p>
-->
<p>因此，Patel 热切关注 Kubernetes 多集群能力的发展。他说：“有了集群联合，我们可以将内部部署作为主集群，将云作为辅助可突发集群。因此，当有周年销售或黑色星期五销售并且我们需要更多的容器时，我们可以上云。”</p>
<!--
<p>That kind of possibility—as well as the impact that Grigoriu and Patel's team has already delivered using Kubernetes—is what led Nordstrom on its cloud native journey in the first place. "The way the retail environment is today, we are trying to build responsiveness and flexibility where we can," says Grigoriu. "Kubernetes makes it easy to: bring efficiency to both the Dev and Ops side of the equation. It's a win-win."</p>
-->
<p>这种可能性以及 Grigoriu 和 Patel 的团队已经使用Kubernetes所提供的影响，是 Nordstrom 最初在云原生之旅中所起的作用。Grigoriu 说：“在当下的零售模式下，我们正在努力在力所能及的地方建立响应能力和灵活性。Kubernetes 使得为开发端和运维端同时带来效率的提升，这是一个双赢。”</p>

88
content/zh-cn/docs/concepts/architecture/nodes.md
View File

@ -17,13 +17,13 @@ weight: 10
<!--
Kubernetes runs your workload by placing containers into Pods to run on _Nodes_.
A node may be a virtual or physical machine, depending on the cluster. Each node
is managed by the
is managed by the
{{< glossary_tooltip text="control plane" term_id="control-plane" >}}
and contains the services necessary to run
{{< glossary_tooltip text="Pods" term_id="pod" >}}.
Typically you have several nodes in a cluster; in a learning or resource-limited
environment, you might have just one.
environment, you might have only one node.
The [components](/docs/concepts/overview/components/#node-components) on a node include the
{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}, a
@ -32,11 +32,10 @@ The [components](/docs/concepts/overview/components/#node-components) on a node
-->
Kubernetes 通过将容器放入在节点（Node）上运行的 Pod 中来执行你的工作负载。
节点可以是一个虚拟机或者物理机器，取决于所在的集群配置。
每个节点包含运行 {{< glossary_tooltip text="Pods" term_id="pod" >}} 所需的服务；
每个节点包含运行 {{< glossary_tooltip text="Pod" term_id="pod" >}} 所需的服务；
这些节点由 {{< glossary_tooltip text="控制面" term_id="control-plane" >}} 负责管理。
通常集群中会有若干个节点；而在一个学习用或者资源受限的环境中，你的集群中也可能
只有一个节点。
通常集群中会有若干个节点；而在一个学习所用或者资源受限的环境中，你的集群中也可能只有一个节点。
节点上的[组件](/zh-cn/docs/concepts/overview/components/#node-components)包括
{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}、
@ -50,7 +49,7 @@ Kubernetes 通过将容器放入在节点（Node）上运行的 Pod 中来执行
There are two main ways to have Nodes added to the {{< glossary_tooltip text="API server" term_id="kube-apiserver" >}}:
1. The kubelet on a node self-registers to the control plane
2. You, or another human user, manually add a Node object
2. You (or another human user) manually add a Node object
After you create a Node {{< glossary_tooltip text="object" term_id="object" >}},
or the kubelet on a node self-registers, the control plane checks whether the new Node object is
@ -61,7 +60,7 @@ valid. For example, if you try to create a Node from the following JSON manifest
向 {{< glossary_tooltip text="API 服务器" term_id="kube-apiserver" >}}添加节点的方式主要有两种：
1. 节点上的 `kubelet` 向控制面执行自注册；
2. 你，或者别的什么人，手动添加一个 Node 对象。
2. 你（或者别的什么人）手动添加一个 Node 对象。
在你创建了 Node {{< glossary_tooltip text="对象" term_id="object" >}}或者节点上的
`kubelet` 执行了自注册操作之后，控制面会检查新的 Node 对象是否合法。
@ -83,14 +82,14 @@ valid. For example, if you try to create a Node from the following JSON manifest
<!--
Kubernetes creates a Node object internally (the representation). Kubernetes checks
that a kubelet has registered to the API server that matches the `metadata.name`
field of the Node. If the node is healthy (if all necessary services are running),
it is eligible to run a Pod. Otherwise, that node is ignored for any cluster activity
field of the Node. If the node is healthy (i.e. all necessary services are running),
then it is eligible to run a Pod. Otherwise, that node is ignored for any cluster activity
until it becomes healthy.
-->
Kubernetes 会在内部创建一个 Node 对象作为节点的表示。Kubernetes 检查 `kubelet`
向 API 服务器注册节点时使用的 `metadata.name` 字段是否匹配。
如果节点是健康的（即所有必要的服务都在运行中），则该节点可以用来运行 Pod。
否则，直到该节点变为健康之前，所有的集群活动都会忽略该节点。
否则，直到该节点变为健康之前，所有的集群活动都会忽略该节点。
{{< note >}}
<!--
@ -136,7 +135,7 @@ first and re-added after the update.
<!--
### Self-registration of Nodes
When the kubelet flag `-register-node` is true (the default), the kubelet will attempt to
When the kubelet flag `--register-node` is true (the default), the kubelet will attempt to
register itself with the API server. This is the preferred pattern, used by most distros.
For self-registration, the kubelet is started with the following options:
@ -175,7 +174,7 @@ When the [Node authorization mode](/docs/reference/access-authn-authz/node/) and
[NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) are enabled,
kubelets are only authorized to create/modify their own Node resource.
-->
启用[Node 鉴权模式](/zh-cn/docs/reference/access-authn-authz/node/)和
启用 [Node 鉴权模式](/zh-cn/docs/reference/access-authn-authz/node/)和
[NodeRestriction 准入插件](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#noderestriction)时，
仅授权 `kubelet` 创建或修改其自己的节点资源。
@ -216,7 +215,7 @@ You can create and modify Node objects using
When you want to create Node objects manually, set the kubelet flag `--register-node=false`.
You can modify Node objects regardless of the setting of `--register-node`.
For example, you can set labels on an existing Node, or mark it unschedulable.
For example, you can set labels on an existing Node or mark it unschedulable.
-->
### 手动节点管理 {#manual-node-administration}
@ -226,15 +225,15 @@ For example, you can set labels on an existing Node, or mark it unschedulable.
如果你希望手动创建节点对象时，请设置 kubelet 标志 `--register-node=false`。
你可以修改 Node 对象（忽略 `--register-node` 设置）。
例如，修改节点上的标签或标记其为不可调度。
例如，你可以修改节点上的标签或并标记其为不可调度。
<!--
You can use labels on Nodes in conjunction with node selectors on Pods to control
scheduling. For example, you can to constrain a Pod to only be eligible to run on
scheduling. For example, you can constrain a Pod to only be eligible to run on
a subset of the available nodes.
Marking a node as unschedulable prevents the scheduler from placing new pods onto
that Node, but does not affect existing Pods on the Node. This is useful as a
that Node but does not affect existing Pods on the Node. This is useful as a
preparatory step before a node reboot or other maintenance.
To mark a Node unschedulable, run:
@ -271,9 +270,9 @@ DaemonSet 通常提供节点本地的服务，即使节点上的负载应用已
{{< /note >}}
<!--
## Node Status
## Node status
A node's status contains the following information:
A Node's status contains the following information:
* [Addresses](#addresses)
* [Conditions](#condition)
@ -330,13 +329,13 @@ The `conditions` field describes the status of all `Running` nodes. Examples of
<!--
{{< table caption = "Node conditions, and a description of when each condition applies." >}}
| Node Condition | Description |
|----------------|-------------|
| Node Condition | Description |
|----------------------|-------------|
| `Ready` | `True` if the node is healthy and ready to accept pods, `False` if the node is not healthy and is not accepting pods, and `Unknown` if the node controller has not heard from the node in the last `node-monitor-grace-period` (default is 40 seconds) |
| `DiskPressure` | `True` if pressure exists on the disk size—that is, if the disk capacity is low; otherwise `False` |
| `MemoryPressure` | `True` if pressure exists on the node memory—that is, if the node memory is low; otherwise `False` |
| `PIDPressure` | `True` if pressure exists on the processes - that is, if there are too many processes on the node; otherwise `False` |
| `NetworkUnavailable` | `True` if the network for the node is not correctly configured, otherwise `False` |
| `PIDPressure` | `True` if pressure exists on the processes—that is, if there are too many processes on the node; otherwise `False` |
| `NetworkUnavailable` | `True` if the network for the node is not correctly configured, otherwise `False` |
{{< /table >}}
-->
{{< table caption = "节点状况及每种状况适用场景的描述" >}}
@ -364,7 +363,7 @@ Condition，被保护起来的节点在其规约中被标记为不可调度（Un
In the Kubernetes API, a node's condition is represented as part of the `.status`
of the Node resource. For example, the following JSON structure describes a healthy node:
-->
在 Kubernetes API 中，节点的状况表示节点资源中`.status` 的一部分。
在 Kubernetes API 中，节点的状况表示节点资源中`.status` 的一部分。
例如，以下 JSON 结构描述了一个健康节点：
```json
@ -393,7 +392,7 @@ for all Pods assigned to that node. The default eviction timeout duration is
`pod-eviction-timeout` 值（一个传递给
{{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}
的参数），[节点控制器](#node-controller)会对节点上的所有 Pod 触发
{{< glossary_tooltip text="API-发起的驱逐" term_id="api-eviction" >}}。
{{< glossary_tooltip text="API 发起的驱逐" term_id="api-eviction" >}}。
默认的逐出超时时长为 **5 分钟**。
<!--
@ -411,8 +410,8 @@ The node controller does not force delete pods until it is confirmed that they h
running in the cluster. You can see the pods that might be running on an unreachable node as
being in the `Terminating` or `Unknown` state. In cases where Kubernetes cannot deduce from the
underlying infrastructure if a node has permanently left a cluster, the cluster administrator
may need to delete the node object by hand. Deleting the node object from Kubernetes causes
all the Pod objects running on the node to be deleted from the API server, and frees up their
may need to delete the node object by hand. Deleting the node object from Kubernetes causes
all the Pod objects running on the node to be deleted from the API server and frees up their
names.
-->
节点控制器在确认 Pod 在集群中已经停止运行前，不会强制删除它们。
@ -461,7 +460,8 @@ Node that is available to be consumed by normal Pods.
<!--
You may read more about capacity and allocatable resources while learning how
to [reserve compute resources](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) on a Node.
to [reserve compute resources](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)
on a Node.
-->
可以在学习如何在节点上[预留计算资源](/zh-cn/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)
的时候了解有关容量和可分配资源的更多信息。
@ -505,7 +505,7 @@ Kubernetes 节点发送的心跳帮助你的集群确定每个节点的可用性
-->
* 更新节点的 `.status`
* `kube-node-lease` {{<glossary_tooltip term_id="namespace" text="名字空间">}}中的
[Lease（租约）](/docs/reference/kubernetes-api/cluster-resources/lease-v1/)对象。
[Lease（租约）](/zh-cn/docs/reference/kubernetes-api/cluster-resources/lease-v1/)对象。
每个节点都有一个关联的 Lease 对象。
<!--
@ -539,7 +539,7 @@ kubelet 负责创建和更新节点的 `.status`，以及更新它们对应的 L
最长重试间隔为 7 秒钟。
<!--
## Node Controller
## Node controller
The node {{< glossary_tooltip text="controller" term_id="controller" >}} is a
Kubernetes control plane component that manages various aspects of nodes.
@ -558,7 +558,7 @@ CIDR block to the node when it is registered (if CIDR assignment is turned on).
<!--
The second is keeping the node controller's internal list of nodes up to date with
the cloud provider's list of available machines. When running in a cloud
environment, whenever a node is unhealthy, the node controller asks the cloud
environment and whenever a node is unhealthy, the node controller asks the cloud
provider if the VM for that node is still available. If not, the node
controller deletes the node from its list of nodes.
-->
@ -586,7 +586,7 @@ This period can be configured using the `--node-monitor-period` flag on the
第三个是监控节点的健康状况。节点控制器负责：
- 在节点不可达的情况下，在 Node 的 `.status` 中更新 `Ready` 状况。
在这种情况下，节点控制器将 NodeReady 状况更新为 `Unknown` 。
在这种情况下，节点控制器将 NodeReady 状况更新为 `Unknown`。
- 如果节点仍然无法访问：对于不可达节点上的所有 Pod 触发
[API 发起的逐出](/zh-cn/docs/concepts/scheduling-eviction/api-eviction/)操作。
默认情况下，节点控制器在将节点标记为 `Unknown` 后等待 5 分钟提交第一个驱逐请求。
@ -598,7 +598,7 @@ This period can be configured using the `--node-monitor-period` flag on the
### Rate limits on eviction
In most cases, the node controller limits the eviction rate to
`-node-eviction-rate` (default 0.1) per second, meaning it won't evict pods
`--node-eviction-rate` (default 0.1) per second, meaning it won't evict pods
from more than 1 node per 10 seconds.
-->
### 逐出速率限制 {#rate-limits-on-eviction}
@ -627,7 +627,7 @@ the same time:
- 如果不健康节点的比例超过 `--unhealthy-zone-threshold` （默认为 0.55），
驱逐速率将会降低。
- 如果集群较小（意即小于等于 `--large-cluster-size-threshold` 个节点 - 默认为 50），
驱逐操作将会停止。
驱逐操作将会停止。
- 否则驱逐速率将降为每秒 `--secondary-node-eviction-rate` 个（默认为 0.01）。
<!--
@ -643,8 +643,8 @@ then the eviction mechanism does not take per-zone unavailability into account.
<!--
A key reason for spreading your nodes across availability zones is so that the
workload can be shifted to healthy zones when one entire zone goes down.
Therefore, if all nodes in a zone are unhealthy then node controller evicts at
the normal rate `-node-eviction-rate`. The corner case is when all zones are
Therefore, if all nodes in a zone are unhealthy, then the node controller evicts at
the normal rate of `--node-eviction-rate`. The corner case is when all zones are
completely unhealthy (none of the nodes in the cluster are healthy). In such a
case, the node controller assumes that there is some problem with connectivity
between the control plane and the nodes, and doesn't perform any evictions.
@ -660,9 +660,9 @@ evict pods from the remaining nodes that are unhealthy or unreachable).
（如果故障后部分节点重新连接，节点控制器会从剩下不健康或者不可达节点中驱逐 Pod）。
<!--
The Node Controller is also responsible for evicting pods running on nodes with
`NoExecute` taints, unless the pods do not tolerate the taints.
The Node Controller also adds {{< glossary_tooltip text="taints" term_id="taint" >}}
The node controller is also responsible for evicting pods running on nodes with
`NoExecute` taints, unless those pods tolerate that taint.
The node controller also adds {{< glossary_tooltip text="taints" term_id="taint" >}}
corresponding to node problems like node unreachable or not ready. This means
that the scheduler won't place Pods onto unhealthy nodes.
-->
@ -743,7 +743,7 @@ Kubelet ensures that pods follow the normal
[pod termination process](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)
during the node shutdown.
-->
kubelet 会尝试检测节点系统关闭事件并终止在节点上运行的 Pods。
kubelet 会尝试检测节点系统关闭事件并终止在节点上运行的所有 Pod。
在节点终止期间，kubelet 保证 Pod 遵从常规的
[Pod 终止流程](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)。
@ -763,7 +763,7 @@ Graceful node shutdown is controlled with the `GracefulNodeShutdown`
enabled by default in 1.21.
-->
节点体面关闭特性受 `GracefulNodeShutdown`
[特性门控](/docs/reference/command-line-tools-reference/feature-gates/)控制，
[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)控制，
在 1.21 版本中是默认启用的。
<!--
@ -840,7 +840,7 @@ Message: Pod was terminated in response to imminent node shutdown.
{{< feature-state state="alpha" for_k8s_version="v1.24" >}}
<!--
A node shutdown action may not be detected by kubelet's Node Shutdown Mananger,
A node shutdown action may not be detected by kubelet's Node Shutdown Manager,
either because the command does not trigger the inhibitor locks mechanism used by
kubelet or because of a user error, i.e., the ShutdownGracePeriod and
ShutdownGracePeriodCriticalPods are not configured properly. Please refer to above
@ -888,7 +888,7 @@ different node.
-->
为了缓解上述情况，用户可以手动将具有 `NoExecute` 或 `NoSchedule` 效果的
`node kubernetes.io/out-of-service` 污点添加到节点上，标记其无法提供服务。
如果在 `kube-controller-manager` 上启用了 `NodeOutOfServiceVolumeDetach`
如果在 `kube-controller-manager` 上启用了 `NodeOutOfServiceVolumeDetach`
[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)，
并且节点被通过污点标记为无法提供服务，如果节点 Pod 上没有设置对应的容忍度，
那么这样的 Pod 将被强制删除，并且该在节点上被终止的 Pod 将立即进行卷分离操作。
@ -1058,7 +1058,7 @@ their respective shutdown periods.
-->
如果此功能特性被启用，但没有提供配置数据，则不会出现排序操作。
使用此功能特性需要启用 `GracefulNodeShutdownBasedOnPodPriority`
使用此功能特性需要启用 `GracefulNodeShutdownBasedOnPodPriority`
[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)，
并将 [kubelet 配置](/zh-cn/docs/reference/config-api/kubelet-config.v1beta1/)
中的 `shutdownGracePeriodByPodPriority` 设置为期望的配置，
@ -1074,7 +1074,7 @@ the feature is Beta and is enabled by default.
{{< note >}}
在节点体面关闭期间考虑 Pod 优先级的能力是作为 Kubernetes v1.23 中的 Alpha 功能引入的。
在 Kubernetes {{< skew currentVersion >}} 中该功能是 Beta 版，默认启用。
{{< /note >}}
{{< /note >}}
<!--
Metrics `graceful_shutdown_start_time_seconds` and `graceful_shutdown_end_time_seconds`

43
content/zh-cn/docs/concepts/cluster-administration/logging.md
View File

@ -28,7 +28,7 @@ In a cluster, logs should have a separate storage and lifecycle independent of n
但是，由容器引擎或运行时提供的原生功能通常不足以构成完整的日志记录方案。
例如，如果发生容器崩溃、Pod 被逐出或节点宕机等情况，你可能想访问应用日志。
在集群中，日志应该具有独立的存储和生命周期，与节点、Pod 或容器的生命周期相独立。
这个概念叫 _集群级的日志_ 。
这个概念叫 **集群级的日志**。
<!-- body -->
@ -175,11 +175,11 @@ The two kubelet parameters [`containerLogMaxSize` and `containerLogMaxFiles`](/d
in [kubelet config file](/docs/tasks/administer-cluster/kubelet-config-file/)
can be used to configure the maximum size for each log file and the maximum number of files allowed for each container respectively.
-->
当使用某 *CRI 容器运行时* 时，kubelet 要负责对日志进行轮换，并
管理日志目录的结构。kubelet 将此信息发送给 CRI 容器运行时，后者
将容器日志写入到指定的位置。在 [kubelet 配置文件](/docs/tasks/administer-cluster/kubelet-config-file/)
当使用某 **CRI 容器运行时** 时，kubelet 要负责对日志进行轮换，并管理日志目录的结构。
kubelet 将此信息发送给 CRI 容器运行时，后者将容器日志写入到指定的位置。
在 [kubelet 配置文件](/zh-cn/docs/tasks/administer-cluster/kubelet-config-file/)
中的两个 kubelet 参数
[`containerLogMaxSize` 和 `containerLogMaxFiles`](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)
[`containerLogMaxSize` 和 `containerLogMaxFiles`](/zh-cn/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)
可以用来配置每个日志文件的最大长度和每个容器可以生成的日志文件个数上限。
<!--
@ -198,11 +198,10 @@ the rotation and there are two files: one file that is 10MB in size and a second
`kubectl logs` returns the latest log file which in this example is an empty response.
-->
{{< note >}}
如果有外部系统执行日志轮转或者使用了 CRI 容器运行时，那么 `kubectl logs`
如果有外部系统执行日志轮转或者使用了 CRI 容器运行时，那么 `kubectl logs`
仅可查询到最新的日志内容。
比如，对于一个 10MB 大小的文件，通过 `logrotate` 执行轮转后生成两个文件，
一个 10MB 大小，一个为空，`kubectl logs` 返回最新的日志文件，而该日志文件
在这个例子中为空。
一个 10MB 大小，一个为空，`kubectl logs` 返回最新的日志文件，而该日志文件在这个例子中为空。
{{< /note >}}
<!--
@ -278,7 +277,7 @@ While Kubernetes does not provide a native solution for cluster-level logging, t
<!--
You can implement cluster-level logging by including a _node-level logging agent_ on each node. The logging agent is a dedicated tool that exposes logs or pushes logs to a backend. Commonly, the logging agent is a container that has access to a directory with log files from all of the application containers on that node.
-->
你可以通过在每个节点上使用 _节点级的日志记录代理_ 来实现集群级日志记录。
你可以通过在每个节点上使用 **节点级的日志记录代理** 来实现集群级日志记录。
日志记录代理是一种用于暴露日志或将日志推送到后端的专用工具。
通常，日志记录代理程序是一个容器，它可以访问包含该节点上所有应用程序容器的日志文件的目录。
@ -294,8 +293,7 @@ Node-level logging creates only one agent per node, and doesn't require any chan
Containers write to stdout and stderr, but with no agreed format. A node-level agent collects these logs and forwards them for aggregation.
-->
容器向标准输出和标准错误输出写出数据，但在格式上并不统一。
节点级代理
收集这些日志并将其进行转发以完成汇总。
节点级代理收集这些日志并将其进行转发以完成汇总。
<!--
### Using a sidecar container with the logging agent {#sidecar-container-with-logging-agent}
@ -342,7 +340,7 @@ like `kubectl logs`.
-->
这种方法允许你将日志流从应用程序的不同部分分离开，其中一些可能缺乏对写入
`stdout` 或 `stderr` 的支持。重定向日志背后的逻辑是最小的，因此它的开销几乎可以忽略不计。
另外，因为 `stdout`、`stderr` 由 kubelet 处理，你可以使用内置的工具 `kubectl logs`。
另外，因为 `stdout` 和 `stderr` 由 kubelet 处理，所以你可以使用内置的工具 `kubectl logs`。
<!--
For example, a pod runs a single container, and the container
@ -350,7 +348,7 @@ writes to two different log files, using two different formats. Here's a
configuration file for the Pod:
-->
例如，某 Pod 中运行一个容器，该容器向两个文件写不同格式的日志。
下面是这个 pod 的配置文件:
下面是这个 Pod 的配置文件:
{{< codenew file="admin/logging/two-files-counter-pod.yaml" >}}
@ -361,9 +359,9 @@ the container. Instead, you can create two sidecar containers. Each sidecar
container could tail a particular log file from a shared volume and then redirect
the logs to its own `stdout` stream.
-->
不建议在同一个日志流中写入不同格式的日志条目，即使你成功地将其重定向到容器的
`stdout` 流。相反，你可以创建两个边车容器。每个边车容器可以从共享卷
跟踪特定的日志文件，并将文件内容重定向到各自的 `stdout` 流。
不建议在同一个日志流中写入不同格式的日志条目，即使你成功地将其重定向到容器的 `stdout` 流。
相反，你可以创建两个边车容器。每个边车容器可以从共享卷跟踪特定的日志文件，
并将文件内容重定向到各自的 `stdout` 流。
<!--
Here's a configuration file for a pod that has two sidecar containers:
@ -439,8 +437,7 @@ and retention policies to the kubelet.
-->
应用本身如果不具备轮转日志文件的功能，可以通过边车容器实现。
该方式的一个例子是运行一个小的、定期轮转日志的容器。
然而，还是推荐直接使用 `stdout` 和 `stderr`，将日志的轮转和保留策略
交给 kubelet。
然而，还是推荐直接使用 `stdout` 和 `stderr`，将日志的轮转和保留策略交给 kubelet。
<!--
#### Sidecar container with a logging agent
@ -456,8 +453,8 @@ If the node-level logging agent is not flexible enough for your situation, you
can create a sidecar container with a separate logging agent that you have
configured specifically to run with your application.
-->
如果节点级日志记录代理程序对于你的场景来说不够灵活，你可以创建一个
带有单独日志记录代理的边车容器，将代理程序专门配置为与你的应用程序一起运行。
如果节点级日志记录代理程序对于你的场景来说不够灵活，
你可以创建一个带有单独日志记录代理的边车容器，将代理程序专门配置为与你的应用程序一起运行。
{{< note >}}
<!--
@ -499,8 +496,7 @@ flutend 通过 Pod 的挂载卷获取它的配置数据。
<!--
In the sample configurations, you can replace fluentd with any logging agent, reading from any source inside an application container.
-->
在示例配置中，你可以将 fluentd 替换为任何日志代理，从应用容器内
的任何来源读取数据。
在示例配置中，你可以将 fluentd 替换为任何日志代理，从应用容器内的任何来源读取数据。
<!--
### Exposing logs directly from the application
@ -514,6 +510,5 @@ In the sample configurations, you can replace fluentd with any logging agent, re
<!--
Cluster-logging that exposes or pushes logs directly from every application is outside the scope of Kubernetes.
-->
从各个应用中直接暴露和推送日志数据的集群日志机制
已超出 Kubernetes 的范围。
从各个应用中直接暴露和推送日志数据的集群日志机制已超出 Kubernetes 的范围。

15
content/zh-cn/docs/concepts/configuration/manage-resources-containers.md
View File

@ -235,7 +235,7 @@ Kubernetes 不允许设置精度小于 `1m` 的 CPU 资源。
Limits and requests for `memory` are measured in bytes. You can express memory as
a plain integer or as a fixed-point number using one of these
[quantity](/docs/reference/kubernetes-api/common-definitions/quantity/) suffixes:
E, P, T, G, M, K. You can also use the power-of-two equivalents: Ei, Pi, Ti, Gi,
E, P, T, G, M, k. You can also use the power-of-two equivalents: Ei, Pi, Ti, Gi,
Mi, Ki. For example, the following represent roughly the same value:
-->
## 内存资源单位 {#meaning-of-memory}
@ -256,8 +256,8 @@ Pay attention to the case of the suffixes. If you request `400m` of memory, this
for 0.4 bytes. Someone who types that probably meant to ask for 400 mebibytes (`400Mi`)
or 400 megabytes (`400M`).
-->
请注意后缀的大小写。如果你请求 `400m` 内存，实际上请求的是 0.4 字节。
如果有人这样设定资源请求或限制，可能他的实际想法是申请 400 兆字节（`400Mi`）
请注意后缀的大小写。如果你请求 `400m` 临时存储，实际上所请求的是 0.4 字节。
如果有人这样设定资源请求或限制，可能他的实际想法是申请 400Mi 字节（`400Mi`）
或者 400M 字节。
<!--
@ -629,6 +629,15 @@ Pod 中的每个容器可以设置以下属性：
- `129M`
- `123Mi`
<!--
Pay attention to the case of the suffixes. If you request `400m` of ephemeral-storage, this is a request
for 0.4 bytes. Someone who types that probably meant to ask for 400 mebibytes (`400Mi`)
or 400 megabytes (`400M`).
-->
请注意后缀的大小写。如果你请求 `400m` 临时存储，实际上所请求的是 0.4 字节。
如果有人这样设定资源请求或限制，可能他的实际想法是申请 400Mi 字节（`400Mi`）
或者 400M 字节。
<!--
In the following example, the Pod has two containers. Each container has a request of
2GiB of local ephemeral storage. Each container has a limit of 4GiB of local ephemeral

Some files were not shown because too many files have changed in this diff Show More