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

Merge remote-tracking branch 'upstream/main' into dev-1.26

pull/38316/head
carolina valencia 2022-12-07 11:40:37 -03:00
parent 0ecc914172 0b0c6a813a
commit 7cd85d1fc4
53 changed files with 1266 additions and 1217 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
Makefile
View File

@ -14,6 +14,9 @@ CONTAINER_RUN = "$(CONTAINER_ENGINE)" run --rm --interactive --tty --volume
CCRED=\033[0;31m
CCEND=\033[0m
# Docker buildx related settings for multi-arch images
DOCKER_BUILDX ?= docker buildx
.PHONY: all build build-preview help serve
help: ## Show this help.
@ -74,6 +77,23 @@ container-image: ## Build a container image for the preview of the website
container-push: container-image ## Push container image for the preview of the website
$(CONTAINER_ENGINE) push $(CONTAINER_IMAGE)
PLATFORMS ?= linux/arm64,linux/amd64
docker-push: ## Build a multi-architecture image and push that into the registry
docker run --rm --privileged tonistiigi/binfmt:qemu-v6.2.0-26@sha256:5bf63a53ad6222538112b5ced0f1afb8509132773ea6dd3991a197464962854e --install all
docker version
$(DOCKER_BUILDX) version
$(DOCKER_BUILDX) inspect image-builder > /dev/null 2>&1 || $(DOCKER_BUILDX) create --name image-builder --use
# copy existing Dockerfile and insert --platform=${TARGETPLATFORM} into Dockerfile.cross, and preserve the original Dockerfile
sed -e 's/\(^FROM\)/FROM --platform=\$$\{TARGETPLATFORM\}/' Dockerfile > Dockerfile.cross
$(DOCKER_BUILDX) build \
--push \
--platform=$(PLATFORMS) \
--build-arg HUGO_VERSION=$(HUGO_VERSION) \
--tag $(CONTAINER_IMAGE) \
-f Dockerfile.cross .
$(DOCKER_BUILDX) stop image-builder
rm Dockerfile.cross
container-build: module-check
$(CONTAINER_RUN) --read-only --mount type=tmpfs,destination=/tmp,tmpfs-mode=01777 $(CONTAINER_IMAGE) sh -c "npm ci && hugo --minify --environment development"

10
cloudbuild.yaml
View File

@ -1,24 +1,28 @@
# See https://cloud.google.com/cloud-build/docs/build-config
# this must be specified in seconds. If omitted, defaults to 600s (10 mins)
timeout: 1200s
timeout: 9000s
# this prevents errors if you don't use both _GIT_TAG and _PULL_BASE_REF,
# or any new substitutions added in the future.
options:
substitution_option: ALLOW_LOOSE
machineType: 'E2_HIGHCPU_8'
steps:
# It's fine to bump the tag to a recent version, as needed
- name: "gcr.io/k8s-staging-test-infra/gcb-docker-gcloud:v20210917-12df099d55"
- name: "gcr.io/k8s-staging-test-infra/gcb-docker-gcloud:v20220830-45cbff55bc"
entrypoint: 'bash'
env:
- DOCKER_CLI_EXPERIMENTAL=enabled
- DOCKER_BUILDKIT=1
- DOCKER_BUILDX=/root/.docker/cli-plugins/docker-buildx
- TAG=$_GIT_TAG
- BASE_REF=$_PULL_BASE_REF
args:
- -c
- |
gcloud auth configure-docker \
&& make container-push
&& apk add sed \
&& make docker-push
substitutions:
# _GIT_TAG will be filled with a git-based tag for the image, of the form vYYYYMMDD-hash, and
# can be used as a substitution

94
content/en/docs/concepts/cluster-administration/flow-control.md
View File

@ -538,26 +538,15 @@ poorly-behaved workloads that may be harming system health.
last window's high water mark of number of requests actively being
served.
* `apiserver_flowcontrol_read_vs_write_request_count_samples` is a
histogram vector of observations of the then-current number of
requests, broken down by the labels `phase` (which takes on the
values `waiting` and `executing`) and `request_kind` (which takes on
the values `mutating` and `readOnly`). The observations are made
periodically at a high rate. Each observed value is a ratio,
between 0 and 1, of a number of requests divided by the
corresponding limit on the number of requests (queue length limit
for waiting and concurrency limit for executing).
* `apiserver_flowcontrol_read_vs_write_request_count_watermarks` is a
histogram vector of high or low water marks of the number of
requests (divided by the corresponding limit to get a ratio in the
range 0 to 1) broken down by the labels `phase` (which takes on the
values `waiting` and `executing`) and `request_kind` (which takes on
the values `mutating` and `readOnly`); the label `mark` takes on
values `high` and `low`. The water marks are accumulated over
windows bounded by the times when an observation was added to
`apiserver_flowcontrol_read_vs_write_request_count_samples`. These
water marks show the range of values that occurred between samples.
* `apiserver_flowcontrol_read_vs_write_current_requests` is a
histogram vector of observations, made at the end of every
nanosecond, of the number of requests broken down by the labels
`phase` (which takes on the values `waiting` and `executing`) and
`request_kind` (which takes on the values `mutating` and
`readOnly`). Each observed value is a ratio, between 0 and 1, of a
number of requests divided by the corresponding limit on the number
of requests (queue volume limit for waiting and concurrency limit
for executing).
* `apiserver_flowcontrol_current_inqueue_requests` is a gauge vector
holding the instantaneous number of queued (not executing) requests,
@ -572,52 +561,27 @@ poorly-behaved workloads that may be harming system health.
holding the instantaneous number of occupied seats, broken down by
the labels `priority_level` and `flow_schema`.
* `apiserver_flowcontrol_priority_level_request_count_samples` is a
histogram vector of observations of the then-current number of
requests broken down by the labels `phase` (which takes on the
values `waiting` and `executing`) and `priority_level`. Each
histogram gets observations taken periodically, up through the last
activity of the relevant sort. The observations are made at a high
rate. Each observed value is a ratio, between 0 and 1, of a number
of requests divided by the corresponding limit on the number of
requests (queue length limit for waiting and concurrency limit for
executing).
* `apiserver_flowcontrol_priority_level_request_utilization` is a
histogram vector of observations, made at the end of each
nanosecond, of the number of requests broken down by the labels
`phase` (which takes on the values `waiting` and `executing`) and
`priority_level`. Each observed value is a ratio, between 0 and 1,
of a number of requests divided by the corresponding limit on the
number of requests (queue volume limit for waiting and concurrency
limit for executing).
* `apiserver_flowcontrol_priority_level_request_count_watermarks` is a
histogram vector of high or low water marks of the number of
requests (divided by the corresponding limit to get a ratio in the
range 0 to 1) broken down by the labels `phase` (which takes on the
values `waiting` and `executing`) and `priority_level`; the label
`mark` takes on values `high` and `low`. The water marks are
accumulated over windows bounded by the times when an observation
was added to
`apiserver_flowcontrol_priority_level_request_count_samples`. These
water marks show the range of values that occurred between samples.
* `apiserver_flowcontrol_priority_level_seat_count_samples` is a
histogram vector of observations of the utilization of a priority
level's concurrency limit, broken down by `priority_level`. This
utilization is the fraction (number of seats occupied) /
(concurrency limit). This metric considers all stages of execution
(both normal and the extra delay at the end of a write to cover for
the corresponding notification work) of all requests except WATCHes;
for those it considers only the initial stage that delivers
notifications of pre-existing objects. Each histogram in the vector
is also labeled with `phase: executing` (there is no seat limit for
the waiting phase). Each histogram gets observations taken
periodically, up through the last activity of the relevant sort.
The observations
are made at a high rate.
* `apiserver_flowcontrol_priority_level_seat_count_watermarks` is a
histogram vector of high or low water marks of the utilization of a
priority level's concurrency limit, broken down by `priority_level`
and `mark` (which takes on values `high` and `low`). Each histogram
in the vector is also labeled with `phase: executing` (there is no
seat limit for the waiting phase). The water marks are accumulated
over windows bounded by the times when an observation was added to
`apiserver_flowcontrol_priority_level_seat_count_samples`. These
water marks show the range of values that occurred between samples.
* `apiserver_flowcontrol_priority_level_seat_utilization` is a
histogram vector of observations, made at the end of each
nanosecond, of the utilization of a priority level's concurrency
limit, broken down by `priority_level`. This utilization is the
fraction (number of seats occupied) / (concurrency limit). This
metric considers all stages of execution (both normal and the extra
delay at the end of a write to cover for the corresponding
notification work) of all requests except WATCHes; for those it
considers only the initial stage that delivers notifications of
pre-existing objects. Each histogram in the vector is also labeled
with `phase: executing` (there is no seat limit for the waiting
phase).
* `apiserver_flowcontrol_request_queue_length_after_enqueue` is a
histogram vector of queue lengths for the queues, broken down by

2
content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
View File

@ -265,7 +265,7 @@ message ContainerDevices {
```
{{< note >}}
cpu_ids in the `ContainerResources` in the `List` endpoint correspond to exclusive CPUs allocated
to a partilar container. If the goal is to evaluate CPUs that belong to the shared pool, the `List`
to a particular container. If the goal is to evaluate CPUs that belong to the shared pool, the `List`
endpoint needs to be used in conjunction with the `GetAllocatableResources` endpoint as explained
below:
1. Call `GetAllocatableResources` to get a list of all the allocatable CPUs

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

@ -32,11 +32,12 @@ is the default scheduler for Kubernetes and runs as part of the
kube-scheduler is designed so that, if you want and need to, you can
write your own scheduling component and use that instead.
For every newly created pod or other unscheduled pods, kube-scheduler
selects an optimal node for them to run on. However, every container in
pods has different requirements for resources and every pod also has
different requirements. Therefore, existing nodes need to be filtered
according to the specific scheduling requirements.
Kube-scheduler selects an optimal node to run newly created or not yet
scheduled (unscheduled) pods. Since containers in pods - and pods themselves -
can have different requirements, the scheduler filters out any nodes that
don't meet a Pod's specific scheduling needs. Alternatively, the API lets
you specify a node for a Pod when you create it, but this is unusual
and is only done in special cases.
In a cluster, Nodes that meet the scheduling requirements for a Pod
are called _feasible_ nodes. If none of the nodes are suitable, the pod

99
content/en/docs/concepts/services-networking/dns-pod-service.md
View File

@ -1,6 +1,7 @@
---
reviewers:
- davidopp
- jbelamaric
- bowei
- thockin
title: DNS for Services and Pods
content_type: concept
@ -16,13 +17,13 @@ Services with consistent DNS names instead of IP addresses.
<!-- body -->
Kubernetes DNS schedules a DNS Pod and Service on the cluster, and configures
the kubelets to tell individual containers to use the DNS Service's IP to
resolve DNS names.
Kubernetes publishes information about Pods and Services which is used
to program DNS. Kubelet configures Pods' DNS so that running containers
can lookup Services by name rather than IP.
Every Service defined in the cluster (including the DNS server itself) is
assigned a DNS name. By default, a client Pod's DNS search list includes the
Pod's own namespace and the cluster's default domain.
Services defined in the cluster are assigned DNS names. By default, a
client Pod's DNS search list includes the Pod's own namespace and the
cluster's default domain.
### Namespaces of Services
@ -39,7 +40,7 @@ A query for `data.prod` returns the intended result, because it specifies the
namespace.
DNS queries may be expanded using the Pod's `/etc/resolv.conf`. Kubelet
sets this file for each Pod. For example, a query for just `data` may be
configures this file for each Pod. For example, a query for just `data` may be
expanded to `data.test.svc.cluster.local`. The values of the `search` option
are used to expand queries. To learn more about DNS queries, see
[the `resolv.conf` manual page.](https://www.man7.org/linux/man-pages/man5/resolv.conf.5.html)
@ -70,29 +71,28 @@ For more up-to-date specification, see
### A/AAAA records
"Normal" (not headless) Services are assigned a DNS A or AAAA record,
depending on the IP family of the Service, for a name of the form
"Normal" (not headless) Services are assigned DNS A and/or AAAA records,
depending on the IP family or families of the Service, with a name of the form
`my-svc.my-namespace.svc.cluster-domain.example`. This resolves to the cluster IP
of the Service.
"Headless" (without a cluster IP) Services are also assigned a DNS A or AAAA record,
depending on the IP family of the Service, for a name of the form
`my-svc.my-namespace.svc.cluster-domain.example`. Unlike normal
Services, this resolves to the set of IPs of the Pods selected by the Service.
[Headless Services](/docs/concepts/services-networking/service/#headless-services)
(without a cluster IP) Services are also assigned DNS A and/or AAAA records,
with a name of the form `my-svc.my-namespace.svc.cluster-domain.example`. Unlike normal
Services, this resolves to the set of IPs of all of the Pods selected by the Service.
Clients are expected to consume the set or else use standard round-robin
selection from the set.
### SRV records
SRV Records are created for named ports that are part of normal or [Headless
Services](/docs/concepts/services-networking/service/#headless-services).
For each named port, the SRV record would have the form
`_my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster-domain.example`.
SRV Records are created for named ports that are part of normal or headless
services. For each named port, the SRV record has the form
`_port-name._port-protocol.my-svc.my-namespace.svc.cluster-domain.example`.
For a regular Service, this resolves to the port number and the domain name:
`my-svc.my-namespace.svc.cluster-domain.example`.
For a headless Service, this resolves to multiple answers, one for each Pod
that is backing the Service, and contains the port number and the domain name of the Pod
of the form `auto-generated-name.my-svc.my-namespace.svc.cluster-domain.example`.
of the form `hostname.my-svc.my-namespace.svc.cluster-domain.example`.
## Pods
@ -113,17 +113,25 @@ Any Pods exposed by a Service have the following DNS resolution available:
### Pod's hostname and subdomain fields
Currently when a Pod is created, its hostname is the Pod's `metadata.name` value.
Currently when a Pod is created, its hostname (as observed from within the Pod)
is the Pod's `metadata.name` value.
The Pod spec has an optional `hostname` field, which can be used to specify the
Pod's hostname. When specified, it takes precedence over the Pod's name to be
the hostname of the Pod. For example, given a Pod with `hostname` set to
"`my-host`", the Pod will have its hostname set to "`my-host`".
The Pod spec has an optional `hostname` field, which can be used to specify a
different hostname. When specified, it takes precedence over the Pod's name to be
the hostname of the Pod (again, as observed from within the Pod). For example,
given a Pod with `spec.hostname` set to `"my-host"`, the Pod will have its
hostname set to `"my-host"`.
The Pod spec also has an optional `subdomain` field which can be used to specify
its subdomain. For example, a Pod with `hostname` set to "`foo`", and `subdomain`
set to "`bar`", in namespace "`my-namespace`", will have the fully qualified
domain name (FQDN) "`foo.bar.my-namespace.svc.cluster-domain.example`".
The Pod spec also has an optional `subdomain` field which can be used to indicate
that the pod is part of sub-group of the namespace. For example, a Pod with `spec.hostname`
set to `"foo"`, and `spec.subdomain` set to `"bar"`, in namespace `"my-namespace"`, will
have its hostname set to `"foo"` and its fully qualified domain name (FQDN) set to
`"foo.bar.my-namespace.svc.cluster.local"` (once more, as observed from within
the Pod).
If there exists a headless Service in the same namespace as the Pod, with
the same name as the subdomain, the cluster's DNS Server also returns A and/or AAAA
records for the Pod's fully qualified hostname.
Example:
@ -131,15 +139,14 @@ Example:
apiVersion: v1
kind: Service
metadata:
name: default-subdomain
name: busybox-subdomain
spec:
selector:
name: busybox
clusterIP: None
ports:
- name: foo # Actually, no port is needed.
- name: foo # name is not required for single-port Services
port: 1234
targetPort: 1234
---
apiVersion: v1
kind: Pod
@ -149,7 +156,7 @@ metadata:
name: busybox
spec:
hostname: busybox-1
subdomain: default-subdomain
subdomain: busybox-subdomain
containers:
- image: busybox:1.28
command:
@ -165,7 +172,7 @@ metadata:
name: busybox
spec:
hostname: busybox-2
subdomain: default-subdomain
subdomain: busybox-subdomain
containers:
- image: busybox:1.28
command:
@ -174,24 +181,20 @@ spec:
name: busybox
```
If there exists a headless Service in the same namespace as the Pod and with
the same name as the subdomain, the cluster's DNS Server also returns an A or AAAA
record for the Pod's fully qualified hostname.
For example, given a Pod with the hostname set to "`busybox-1`" and the subdomain set to
"`default-subdomain`", and a headless Service named "`default-subdomain`" in
the same namespace, the Pod will see its own FQDN as
"`busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example`". DNS serves an
A or AAAA record at that name, pointing to the Pod's IP. Both Pods "`busybox1`" and
"`busybox2`" can have their distinct A or AAAA records.
Given the above Service `"busybox-subdomain"` and the Pods which set `spec.subdomain`
to `"busybox-subdomain"`, the first Pod will see its own FQDN as
`"busybox-1.busybox-subdomain.my-namespace.svc.cluster-domain.example"`. DNS serves
A and/or AAAA records at that name, pointing to the Pod's IP. Both Pods "`busybox1`" and
"`busybox2`" will have their own address records.
An {{<glossary_tooltip term_id="endpoint-slice" text="EndpointSlice">}} can specify
the DNS hostname for any endpoint addresses, along with its IP.
{{< note >}}
Because A or AAAA records are not created for Pod names, `hostname` is required for the Pod's A or AAAA
Because A and AAAA records are not created for Pod names, `hostname` is required for the Pod's A or AAAA
record to be created. A Pod with no `hostname` but with `subdomain` will only create the
A or AAAA record for the headless Service (`default-subdomain.my-namespace.svc.cluster-domain.example`),
pointing to the Pod's IP address. Also, Pod needs to become ready in order to have a
A or AAAA record for the headless Service (`busybox-subdomain.my-namespace.svc.cluster-domain.example`),
pointing to the Pods' IP addresses. Also, the Pod needs to be ready in order to have a
record unless `publishNotReadyAddresses=True` is set on the Service.
{{< /note >}}
@ -199,7 +202,11 @@ record unless `publishNotReadyAddresses=True` is set on the Service.
{{< feature-state for_k8s_version="v1.22" state="stable" >}}
When a Pod is configured to have fully qualified domain name (FQDN), its hostname is the short hostname. For example, if you have a Pod with the fully qualified domain name `busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example`, then by default the `hostname` command inside that Pod returns `busybox-1` and the `hostname --fqdn` command returns the FQDN.
When a Pod is configured to have fully qualified domain name (FQDN), its
hostname is the short hostname. For example, if you have a Pod with the fully
qualified domain name `busybox-1.busybox-subdomain.my-namespace.svc.cluster-domain.example`,
then by default the `hostname` command inside that Pod returns `busybox-1` and the
`hostname --fqdn` command returns the FQDN.
When you set `setHostnameAsFQDN: true` in the Pod spec, the kubelet writes the Pod's FQDN into the hostname for that Pod's namespace. In this case, both `hostname` and `hostname --fqdn` return the Pod's FQDN.

2
content/en/docs/concepts/services-networking/ingress.md
View File

@ -170,7 +170,7 @@ supported path types:
{{< note >}} If the last element of the path is a substring of the last
element in request path, it is not a match (for example: `/foo/bar`
matches`/foo/bar/baz`, but does not match `/foo/barbaz`). {{< /note >}}
matches `/foo/bar/baz`, but does not match `/foo/barbaz`). {{< /note >}}
### Examples

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

@ -99,7 +99,7 @@ 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
(see [Virtual IPs and service proxies](#virtual-ips-and-service-proxies) below).
(see [Virtual IP addressing mechanism](#virtual-ip-addressing-mechanism) below).
The controller for the Service selector continuously scans for Pods that
match its selector, and then POSTs any updates to an Endpoint object

2
content/en/docs/concepts/storage/volume-snapshots.md
View File

@ -230,7 +230,7 @@ If you want to allow users to create a `PersistentVolumeClaim` from an existing
`snapshot.storage.kubernetes.io/allowVolumeModeChange: "true"`needs to be added to
the `VolumeSnapshotContent` that corresponds to the `VolumeSnapshot`.
For pre-provisioned snapshots, `Spec.SourceVolumeMode` needs to be populated
For pre-provisioned snapshots, `spec.sourceVolumeMode` needs to be populated
by the cluster administrator.
An example `VolumeSnapshotContent` resource with this feature enabled would look like:

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

@ -805,7 +805,7 @@ should connect to. This is used mainly for etcd cluster health check purposes.
### kubeadm.kubernetes.io/kube-apiserver.advertise-address.endpoint
Example: `kubeadm.kubernetes.io/kube-apiserver.advertise-address.endpoint: https//172.17.0.18:6443`
Example: `kubeadm.kubernetes.io/kube-apiserver.advertise-address.endpoint: https://172.17.0.18:6443`
Used on: Pod

7
content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md
View File

@ -267,10 +267,13 @@ to download the certificates when additional control-plane nodes are joining, by
The following phase command can be used to re-upload the certificates after expiration:
```shell
kubeadm init phase upload-certs --upload-certs --certificate-key=SOME_VALUE --config=SOME_YAML_FILE
kubeadm init phase upload-certs --upload-certs --config=SOME_YAML_FILE
```
{{< note >}}
A predefined `certificateKey` can be provided in `InitConfiguration` when passing the [configuration file](https://kubernetes.io/docs/reference/config-api/kubeadm-config.v1beta3/) with `--config`.
{{< /note >}}
If the flag `--certificate-key` is not passed to `kubeadm init` and
If a predefined certificate key is not passed to `kubeadm init` and
`kubeadm init phase upload-certs` a new key will be generated automatically.
The following command can be used to generate a new key on demand:

2
content/en/releases/patch-releases.md
View File

@ -78,7 +78,7 @@ releases may also occur in between these.
| Monthly Patch Release | Cherry Pick Deadline | Target date |
| --------------------- | -------------------- | ----------- |
| December 2022 | 2022-12-02 | 2022-12-07 |
| December 2022 | 2022-12-02 | 2022-12-08 |
| January 2023 | 2023-01-13 | 2023-01-18 |
| February 2023 | 2023-02-10 | 2023-02-15 |

7
content/en/releases/release-managers.md
View File

@ -88,6 +88,7 @@ GitHub Mentions: [@kubernetes/release-engineering](https://github.com/orgs/kuber
- Adolfo García Veytia ([@puerco](https://github.com/puerco))
- Carlos Panato ([@cpanato](https://github.com/cpanato))
- Jeremy Rickard ([@jeremyrickard](https://github.com/jeremyrickard))
- Marko Mudrinić ([@xmudrii](https://github.com/xmudrii))
- Nabarun Pal ([@palnabarun](https://github.com/palnabarun))
- Sascha Grunert ([@saschagrunert](https://github.com/saschagrunert))
@ -134,14 +135,8 @@ GitHub Mentions: @kubernetes/release-engineering
- Arnaud Meukam ([@ameukam](https://github.com/ameukam))
- Cici Huang ([@cici37](https://github.com/cici37))
- Jeremy Rickard ([@jeremyrickard](https://github.com/jeremyrickard))
- Jim Angel ([@jimangel](https://github.com/jimangel))
- Joseph Sandoval ([@jrsapi](https://github.com/jrsapi))
- Joyce Kung ([@thejoycekung](https://github.com/thejoycekung))
- Max Körbächer ([@mkorbi](https://github.com/mkorbi))
- Seth McCombs ([@sethmccombs](https://github.com/sethmccombs))
- Taylor Dolezal ([@onlydole](https://github.com/onlydole))
- Wilson Husin ([@wilsonehusin](https://github.com/wilsonehusin))
- Xander Grzywinski([@salaxander](https://github.com/salaxander))
### Becoming a Release Manager Associate

2
content/fr/docs/concepts/cluster-administration/certificates.md
View File

@ -114,7 +114,7 @@ manuellement grâce à `easyrsa`, `openssl` ou `cfssl`.
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \
-CAcreateserial -out server.crt -days 10000 \
-extensions v3_ext -extfile csr.conf
-extensions v3_ext -extfile csr.conf -sha256
1. Vérifiez le certificat:
openssl x509 -noout -text -in ./server.crt

2
content/id/docs/concepts/cluster-administration/certificates.md
View File

@ -113,7 +113,7 @@ secara manual melalui `easyrsa`, `openssl` atau `cfssl`.
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \
-CAcreateserial -out server.crt -days 10000 \
-extensions v3_ext -extfile csr.conf
-extensions v3_ext -extfile csr.conf -sha256
1. Lihat sertifikat:
openssl x509 -noout -text -in ./server.crt

20
content/ja/docs/concepts/architecture/nodes.md
View File

@ -294,6 +294,26 @@ Message: Node is shutting, evicting pods
{{< /note >}}
## ノードの非正常終了 {#non-graceful-node-shutdown}
{{< feature-state state="alpha" for_k8s_version="v1.24" >}}
コマンドがkubeletのinhibitor locksメカニズムをトリガーしない場合や、ShutdownGracePeriodやShutdownGracePeriodCriticalPodsが適切に設定されていないといったユーザーによるミス等が原因で、ノードがシャットダウンしたことをkubeletのNode Shutdownマネージャーが検知できないことがあります。詳細は上記セクション[ノードの正常終了](#graceful-node-shutdown)を参照ください。
ノードのシャットダウンがkubeletのNode Shutdownマネージャーに検知されない場合、StatefulSetを構成するPodはシャットダウン状態のノード上でterminating状態のままになってしまい、他の実行中のノードに移動することができなくなってしまいます。これは、ノードがシャットダウンしているため、その上のkubeletがPodを削除できず、それにより、StatefulSetが新しいPodを同じ名前で作成できなくなってしまうためです。Podがボリュームを使用している場合、VolumeAttachmentsはシャットダウン状態のノードによって削除されないため、Podが使用しているボリュームは他の実行中のノードにアタッチすることができなくなってしまいます。その結果として、StatefulSet上で実行中のアプリケーションは適切に機能しなくなってしまいます。シャットダウンしていたノードが復旧した場合、そのノード上のPodはkubeletに削除され、他の実行中のノード上に作成されます。また、シャットダウン状態のノードが復旧できなかった場合は、そのノード上のPodは永久にterminating状態のままとなります。
上記の状況を脱却するには、ユーザーが手動で`NoExecute`または`NoSchedule` effectを設定して`node.kubernetes.io/out-of-service` taintをノードに付与することで、故障中の状態に設定することができます。`kube-controller-manager` において `NodeOutOfServiceVolumeDetach`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)が有効になっており、かつノードがtaintによって故障中としてマークされている場合は、ノードに一致するtolerationがないPodは強制的に削除され、ノード上のterminating状態のPodに対するボリュームデタッチ操作が直ちに実行されます。これにより、故障中のノード上のPodを異なるノード上にすばやく復旧させることが可能になります。
non-graceful shutdownの間に、Podは以下の2段階で終了します:
1. 一致する`out-of-service` tolerationを持たないPodを強制的に削除する。
2. 上記のPodに対して即座にボリュームデタッチ操作を行う。
{{< note >}}
- `node.kubernetes.io/out-of-service` taintを付与する前に、ノードがシャットダウンしているか電源がオフになっていることを確認してください(再起動中ではないこと)。
- Podの別ノードへの移動後、シャットダウンしていたノードが回復した場合は、ユーザーが手動で付与したout-of-service taintをユーザー自ら手動で削除する必要があります。
{{< /note >}}
## スワップメモリの管理 {#swap-memory}
{{< feature-state state="alpha" for_k8s_version="v1.22" >}}

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

@ -62,7 +62,7 @@ weight: 10
セレクターからリリース固有のラベルを省略することで、Serviceを複数のDeploymentにまたがるように作成できます。 [Deployment](/ja/docs/concepts/workloads/controllers/deployment/)により、ダウンタイムなしで実行中のサービスを簡単に更新できます。
オブジェクトの望ましい状態はDeploymentによって記述され、その仕様への変更が _適用_ されると、Deploymentコントローラは制御された速度で実際の状態を望ましい状態に変更します。
オブジェクトの望ましい状態はDeploymentによって記述され、その仕様への変更が _適用_ されると、Deploymentコントローラーは制御された速度で実際の状態を望ましい状態に変更します。
- デバッグ用にラベルを操作できます。Kubernetesコントローラー（ReplicaSetなど）とServiceはセレクターラベルを使用してPodとマッチするため、Podから関連ラベルを削除すると、コントローラーによって考慮されたり、Serviceによってトラフィックを処理されたりすることがなくなります。既存のPodのラベルを削除すると、そのコントローラーはその代わりに新しいPodを作成します。これは、「隔離」環境で以前の「ライブ」Podをデバッグするのに便利な方法です。対話的にラベルを削除または追加するには、[`kubectl label`](/docs/reference/generated/kubectl/kubectl-commands#label)を使います。

2
content/ja/docs/concepts/overview/working-with-objects/labels.md
View File

@ -94,7 +94,7 @@ Kubernetes APIは現在2タイプのセレクターをサポートしていま
そしてセレクターを使うAPIタイプは、それらのセレクターの妥当性とそれらが示す意味をドキュメントに記載するべきです。
{{< note >}}
ReplicaSetなど、いくつかのAPIタイプにおいて、2つのインスタンスのラベルセレクターは単一の名前空間において重複してはいけません。重複していると、コントローラがそれらのラベルセレクターがコンフリクトした操作とみなし、どれだけの数のレプリカを稼働させるべきか決めることができなくなります。
ReplicaSetなど、いくつかのAPIタイプにおいて、2つのインスタンスのラベルセレクターは単一の名前空間において重複してはいけません。重複していると、コントローラーがそれらのラベルセレクターがコンフリクトした操作とみなし、どれだけの数のレプリカを稼働させるべきか決めることができなくなります。
{{< /note >}}
{{< caution >}}

2
content/ja/docs/concepts/services-networking/network-policies.md
View File

@ -210,7 +210,7 @@ Kubernetes1.20現在、ネットワークポリシーAPIに以下の機能は存
Kubernetesのネットワークセキュリティを初めて使用する場合は、ネットワークポリシーAPIを使用して以下のユーザーストーリーを(まだ)実装できないことに注意してください。これらのユーザーストーリーの一部(全てではありません)は、ネットワークポリシーAPIの将来のリリースで活発に議論されています。
- クラスター内トラフィックを強制的に共通ゲートウェイを通過させる(これは、サービスメッシュもしくは他のプロキシで提供するのが最適な場合があります)。
- TLS関連のもの(これにはサービスメッシュまたはIngressコントローラを使用します)。
- TLS関連のもの(これにはサービスメッシュまたはIngressコントローラーを使用します)。
- ノードの固有のポリシー(これらにはCIDR表記を使用できますが、Kubernetesのアイデンティティでノードを指定することはできません)。
- 名前空間またはサービスを名前で指定する(ただし、Podまたは名前空間を{{< glossary_tooltip text="ラベル" term_id="label" >}}で指定することができます。これは多くの場合で実行可能な回避策です)。
- サードパーティによって実行される「ポリシー要求」の作成または管理

2
content/ja/docs/reference/access-authn-authz/rbac.md
View File

@ -707,7 +707,7 @@ Secretsの内容を読み取るとNamespaceのServiceAccountのクレデンシ
Kubernetes {{< glossary_tooltip term_id="kube-controller-manager" text="controller manager" >}}は、Kubernetesコントロールプレーンに組み込まれている{{< glossary_tooltip term_id="controller" text="controllers" >}}を実行します。
`--use-service-account-credentials`を指定して呼び出すと、kube-controller-manager個別のサービスアカウントを使用して各コントローラーを起動します。
組み込みコントローラーごとに、プレフィックス`system:controller:`付きの対応するRoleが存在します。
コントローラーマネージャーが`--use-service-account-credentials`で開始されていない場合、コントローラマネージャーは、関連するすべてのRoleを付与する必要がある自身のクレデンシャルを使用して、すべてのコントロールループを実行します。
コントローラーマネージャーが`--use-service-account-credentials`で開始されていない場合、コントローラーマネージャーは、関連するすべてのRoleを付与する必要がある自身のクレデンシャルを使用して、すべてのコントロールループを実行します。
これらのRoleは次のとおりです。
* `system:controller:attachdetach-controller`

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

@ -101,7 +101,7 @@ APIサーバー上で`--runtime-config`を設定することで、有効にし
{{< note >}}
グループやリソースを有効または無効にした場合、
APIサーバーとコントローラマネージャーを再起動して、`--runtime-config`の変更を反映させる必要があります。
APIサーバーとコントローラーマネージャーを再起動して、`--runtime-config`の変更を反映させる必要があります。
{{< /note >}}
## 永続化

4
content/ja/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md
View File

@ -277,7 +277,7 @@ yum install docker-ce-18.06.1.ce-3.el7.x86_64
## cloud-controller-managerによってノードが初期化される前にkube-proxyがスケジューリングされる
クラウドプロバイダのシナリオでは、クラウドコントローラマネージャがノードアドレスを初期化する前に、kube-proxyが新しいワーカーノードでスケジューリングされてしまうことがあります。これにより、kube-proxyがノードのIPアドレスを正しく拾えず、ロードバランサを管理するプロキシ機能に悪影響を及ぼします。
クラウドプロバイダのシナリオでは、クラウドコントローラーマネージャがノードアドレスを初期化する前に、kube-proxyが新しいワーカーノードでスケジューリングされてしまうことがあります。これにより、kube-proxyがノードのIPアドレスを正しく拾えず、ロードバランサを管理するプロキシ機能に悪影響を及ぼします。
kube-proxy Podsでは以下のようなエラーが発生します:
```
@ -345,4 +345,4 @@ nodeRegistration:
## `kubeadm upgrade plan`が`context deadline exceeded`エラーメッセージを表示する
このエラーメッセージは、外部etcdを実行している場合に`kubeadm`でKubernetesクラスタをアップグレードする際に表示されます。これは致命的なバグではなく、古いバージョンのkubeadmが外部etcdクラスタのバージョンチェックを行うために発生します。`kubeadm upgrade apply ...`で進めることができます。
この問題はバージョン1.19で修正されます。
この問題はバージョン1.19で修正されます。

2
content/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md
View File

@ -66,7 +66,7 @@ Kubernetesの主要な要素は、WindowsでもLinuxと同じように機能し
* リソース制限
* [Controllers](/ja/docs/concepts/workloads/controllers/)
Kubernetesコントローラは、Podの望ましい状態を処理します。次のワークロードコントローラーは、Windowsコンテナでサポートされています。:
Kubernetesコントローラーは、Podの望ましい状態を処理します。次のワークロードコントローラーは、Windowsコンテナでサポートされています。:
* ReplicaSet
* ReplicationController

381
content/ja/docs/tasks/administer-cluster/certificates.md
View File

@ -1,5 +1,5 @@
---
title: 証明書
title: 証明書を手動で生成する
content_type: task
weight: 20
---
@ -7,7 +7,7 @@ weight: 20
<!-- overview -->
クライアント証明書認証を使用する場合、`easyrsa`,`openssl`または`cfssl`を使って手動で証明書を生成することができます。
クライアント証明書認証を使用する場合、[`easyrsa`](https://github.com/OpenVPN/easy-rsa)、[`openssl`](https://github.com/openssl/openssl)または[`cfssl`](https://github.com/cloudflare/cfssl)を使って手動で証明書を生成することができます。
<!-- body -->
@ -15,199 +15,255 @@ weight: 20
**easyrsa**はクラスターの証明書を手動で生成することができます。
1. パッチが適用されたバージョンのeasyrsa3をダウンロードし、解凍し、初期化します。
1. パッチが適用されたバージョンの`easyrsa3`をダウンロードして解凍し、初期化します。
curl -LO https://storage.googleapis.com/kubernetes-release/easy-rsa/easy-rsa.tar.gz
tar xzf easy-rsa.tar.gz
cd easy-rsa-master/easyrsa3
./easyrsa init-pki
1. 新しい認証局(CA)を生成します。
`req-cn`はCAの新しいルート証明書のコモンネーム(CN)を指定します。
```shell
curl -LO https://storage.googleapis.com/kubernetes-release/easy-rsa/easy-rsa.tar.gz
tar xzf easy-rsa.tar.gz
cd easy-rsa-master/easyrsa3
./easyrsa init-pki
```
./easyrsa --batch "--req-cn=${MASTER_IP}@`date +%s`" build-ca nopass
1. サーバー証明書と鍵を生成します。
引数`--subject-alt-name`は、APIサーバーがアクセス可能なIPとDNS名を設定します。
`MASTER_CLUSTER_IP`は通常、APIサーバーとコントローラーマネージャーコンポーネントの両方で`--service-cluster-ip-range`引数に指定したサービスCIDRの最初のIPとなります。
引数`--days`は、証明書の有効期限が切れるまでの日数を設定するために使用します。
また、以下のサンプルでは、デフォルトのDNSドメイン名として`cluster.local`を使用することを想定しています。
1. 新しい認証局(CA)を生成します。
`--batch`で自動モードに設定します。`--req-cn`はCAの新しいルート証明書のコモンネーム(CN)を指定します。
./easyrsa --subject-alt-name="IP:${MASTER_IP},"\
"IP:${MASTER_CLUSTER_IP},"\
"DNS:kubernetes,"\
"DNS:kubernetes.default,"\
"DNS:kubernetes.default.svc,"\
"DNS:kubernetes.default.svc.cluster,"\
"DNS:kubernetes.default.svc.cluster.local" \
--days=10000 \
build-server-full server nopass
1. `pki/ca.crt`,`pki/issued/server.crt`,`pki/private/server.key`を自分のディレクトリにコピーします。
1. APIサーバーのスタートパラメーターに以下のパラメーターを記入し、追加します。
```shell
./easyrsa --batch "--req-cn=${MASTER_IP}@`date +%s`" build-ca nopass
```
--client-ca-file=/yourdirectory/ca.crt
--tls-cert-file=/yourdirectory/server.crt
--tls-private-key-file=/yourdirectory/server.key
1. サーバー証明書と鍵を生成します。
引数`--subject-alt-name`は、APIサーバーがアクセス可能なIPとDNS名を設定します。
`MASTER_CLUSTER_IP`は通常、APIサーバーとコントローラーマネージャーコンポーネントの両方で`--service-cluster-ip-range`引数に指定したサービスCIDRの最初のIPとなります。
引数`--days`は、証明書の有効期限が切れるまでの日数を設定するために使用します。
また、以下のサンプルでは、デフォルトのDNSドメイン名として`cluster.local`を使用することを想定しています。
```shell
./easyrsa --subject-alt-name="IP:${MASTER_IP},"\
"IP:${MASTER_CLUSTER_IP},"\
"DNS:kubernetes,"\
"DNS:kubernetes.default,"\
"DNS:kubernetes.default.svc,"\
"DNS:kubernetes.default.svc.cluster,"\
"DNS:kubernetes.default.svc.cluster.local" \
--days=10000 \
build-server-full server nopass
```
1. `pki/ca.crt`、`pki/issued/server.crt`、`pki/private/server.key`を自分のディレクトリにコピーします。
1. APIサーバーのスタートパラメーターに以下のパラメーターを記入し、追加します。
```shell
--client-ca-file=/yourdirectory/ca.crt
--tls-cert-file=/yourdirectory/server.crt
--tls-private-key-file=/yourdirectory/server.key
```
### openssl
**openssl**は、クラスター用の証明書を手動で生成することができます。
1. 2048bitのca.keyを生成します:
1. 2048bitのca.keyを生成します:
openssl genrsa -out ca.key 2048
1. ca.keyに従ってca.crtを生成します(-daysで証明書の有効期限を設定します)。
```shell
openssl genrsa -out ca.key 2048
```
openssl req -x509 -new -nodes -key ca.key -subj "/CN=${MASTER_IP}" -days 10000 -out ca.crt
1. 2048bitでserver.keyを生成します:
1. ca.keyに従ってca.crtを生成します(`-days`で証明書の有効期限を設定します):
openssl genrsa -out server.key 2048
1. 証明書署名要求(CSR)を生成するための設定ファイルを作成します。
角括弧で囲まれた値(例:`<MASTER_IP>`)は必ず実際の値に置き換えてから、ファイル(例:`csr.conf`)に保存してください。`MASTER_CLUSTER_IP`の値は、前のサブセクションで説明したように、APIサーバーのサービスクラスターのIPであることに注意してください。また、以下のサンプルでは、デフォルトのDNSドメイン名として`cluster.local`を使用することを想定しています。
```shell
openssl req -x509 -new -nodes -key ca.key -subj "/CN=${MASTER_IP}" -days 10000 -out ca.crt
```
[ req ]
default_bits = 2048
prompt = no
default_md = sha256
req_extensions = req_ext
distinguished_name = dn
1. 2048bitでserver.keyを生成します:
[ dn ]
C = <country>
ST = <state>
L = <city>
O = <organization>
OU = <organization unit>
CN = <MASTER_IP>
```shell
openssl genrsa -out server.key 2048
```
[ req_ext ]
subjectAltName = @alt_names
1. 証明書署名要求(CSR)を生成するための設定ファイルを作成します。
[ alt_names ]
DNS.1 = kubernetes
DNS.2 = kubernetes.default
DNS.3 = kubernetes.default.svc
DNS.4 = kubernetes.default.svc.cluster
DNS.5 = kubernetes.default.svc.cluster.local
IP.1 = <MASTER_IP>
IP.2 = <MASTER_CLUSTER_IP>
山括弧で囲まれた値(例:`<MASTER_IP>`)は必ず実際の値に置き換えてから、ファイル(例:`csr.conf`)に保存してください。`MASTER_CLUSTER_IP`の値は、前のサブセクションで説明したように、APIサーバーのサービスクラスターのIPであることに注意してください。また、以下のサンプルでは、デフォルトのDNSドメイン名として`cluster.local`を使用することを想定しています。
[ v3_ext ]
authorityKeyIdentifier=keyid,issuer:always
basicConstraints=CA:FALSE
keyUsage=keyEncipherment,dataEncipherment
extendedKeyUsage=serverAuth,clientAuth
subjectAltName=@alt_names
1. 設定ファイルに基づき、証明書署名要求を生成します:
```ini
[ req ]
default_bits = 2048
prompt = no
default_md = sha256
req_extensions = req_ext
distinguished_name = dn
openssl req -new -key server.key -out server.csr -config csr.conf
1. ca.key、ca.crt、server.csrを使用して、サーバー証明書を生成します:
[ dn ]
C = <country>
ST = <state>
L = <city>
O = <organization>
OU = <organization unit>
CN = <MASTER_IP>
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \
-CAcreateserial -out server.crt -days 10000 \
-extensions v3_ext -extfile csr.conf
1. 証明書署名要求を表示します:
[ req_ext ]
subjectAltName = @alt_names
openssl req -noout -text -in ./server.csr
1. 証明書を表示します:
[ alt_names ]
DNS.1 = kubernetes
DNS.2 = kubernetes.default
DNS.3 = kubernetes.default.svc
DNS.4 = kubernetes.default.svc.cluster
DNS.5 = kubernetes.default.svc.cluster.local
IP.1 = <MASTER_IP>
IP.2 = <MASTER_CLUSTER_IP>
openssl x509 -noout -text -in ./server.crt
[ v3_ext ]
authorityKeyIdentifier=keyid,issuer:always
basicConstraints=CA:FALSE
keyUsage=keyEncipherment,dataEncipherment
extendedKeyUsage=serverAuth,clientAuth
subjectAltName=@alt_names
```
1. 設定ファイルに基づき、証明書署名要求を生成します:
```shell
openssl req -new -key server.key -out server.csr -config csr.conf
```
1. ca.key、ca.crt、server.csrを使用して、サーバー証明書を生成します:
```shell
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \
-CAcreateserial -out server.crt -days 10000 \
-extensions v3_ext -extfile csr.conf -sha256
```
1. 証明書署名要求を表示します:
```shell
openssl req -noout -text -in ./server.csr
```
1. 証明書を表示します:
```shell
openssl x509 -noout -text -in ./server.crt
```
最後に、同じパラメーターをAPIサーバーのスタートパラメーターに追加します。
### cfssl
**cfssl**も証明書生を成するためのツールです。
**cfssl**も証明書を生成するためのツールです。
1. 以下のように、コマンドラインツールをダウンロードし、解凍して準備してください。
なお、サンプルのコマンドは、お使いのハードウェア・アーキテクチャやCFSSLのバージョンに合わせる必要があるかもしれません。
1. 以下のように、コマンドラインツールをダウンロードし、解凍して準備してください。
curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl_1.5.0_linux_amd64 -o cfssl
chmod +x cfssl
curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssljson_1.5.0_linux_amd64 -o cfssljson
chmod +x cfssljson
curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl-certinfo_1.5.0_linux_amd64 -o cfssl-certinfo
chmod +x cfssl-certinfo
1. 成果物を格納するディレクトリを作成し、cfsslを初期化します:
なお、サンプルのコマンドは、お使いのハードウェア・アーキテクチャやCFSSLのバージョンに合わせる必要があるかもしれません。
mkdir cert
cd cert
../cfssl print-defaults config > config.json
../cfssl print-defaults csr > csr.json
1. CAファイルを生成するためのJSON設定ファイル、例えば`ca-config.json`を作成します:
```shell
curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl_1.5.0_linux_amd64 -o cfssl
chmod +x cfssl
curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssljson_1.5.0_linux_amd64 -o cfssljson
chmod +x cfssljson
curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl-certinfo_1.5.0_linux_amd64 -o cfssl-certinfo
chmod +x cfssl-certinfo
```
{
"signing": {
"default": {
"expiry": "8760h"
},
"profiles": {
"kubernetes": {
"usages": [
"signing",
"key encipherment",
"server auth",
"client auth"
],
"expiry": "8760h"
}
}
}
}
1. CA証明書署名要求(CSR)用のJSON設定ファイル(例:`ca-csr.json`)を作成します。
角括弧で囲まれた値は、必ず使用したい実際の値に置き換えてください。
1. 成果物を格納するディレクトリを作成し、cfsslを初期化します:
{
"CN": "kubernetes",
"key": {
"algo": "rsa",
"size": 2048
},
"names":[{
"C": "<country>",
"ST": "<state>",
"L": "<city>",
"O": "<organization>",
"OU": "<organization unit>"
}]
}
1. CAキー(`ca-key.pem`)と証明書(`ca.pem`)を生成します:
```shell
mkdir cert
cd cert
../cfssl print-defaults config > config.json
../cfssl print-defaults csr > csr.json
```
../cfssl gencert -initca ca-csr.json | ../cfssljson -bare ca
1. APIサーバーの鍵と証明書を生成するためのJSON設定ファイル、例えば`server-csr.json`を作成します。
角括弧内の値は、必ず使用したい実際の値に置き換えてください。
`MASTER_CLUSTER_IP`は、前のサブセクションで説明したように、APIサーバーのサービスクラスターのIPです。
また、以下のサンプルでは、デフォルトのDNSドメイン名として`cluster.local`を使用することを想定しています。
1. CAファイルを生成するためのJSON設定ファイル、例えば`ca-config.json`を作成します:
{
"CN": "kubernetes",
"hosts": [
"127.0.0.1",
"<MASTER_IP>",
"<MASTER_CLUSTER_IP>",
"kubernetes",
"kubernetes.default",
"kubernetes.default.svc",
"kubernetes.default.svc.cluster",
"kubernetes.default.svc.cluster.local"
],
"key": {
"algo": "rsa",
"size": 2048
},
"names": [{
"C": "<country>",
"ST": "<state>",
"L": "<city>",
"O": "<organization>",
"OU": "<organization unit>"
}]
}
1. APIサーバーの鍵と証明書を生成します。
デフォルトでは、それぞれ`server-key.pem`と`server.pem`というファイルに保存されます:
```json
{
"signing": {
"default": {
"expiry": "8760h"
},
"profiles": {
"kubernetes": {
"usages": [
"signing",
"key encipherment",
"server auth",
"client auth"
],
"expiry": "8760h"
}
}
}
}
```
../cfssl gencert -ca=ca.pem -ca-key=ca-key.pem \
1. CA証明書署名要求(CSR)用のJSON設定ファイル(例:`ca-csr.json`)を作成します。
山括弧で囲まれた値は、必ず使用したい実際の値に置き換えてください。
```json
{
"CN": "kubernetes",
"key": {
"algo": "rsa",
"size": 2048
},
"names":[{
"C": "<country>",
"ST": "<state>",
"L": "<city>",
"O": "<organization>",
"OU": "<organization unit>"
}]
}
```
1. CAキー(`ca-key.pem`)と証明書(`ca.pem`)を生成します:
```shell
../cfssl gencert -initca ca-csr.json | ../cfssljson -bare ca
```
1. APIサーバーの鍵と証明書を生成するためのJSON設定ファイル、例えば`server-csr.json`を作成します。
山括弧内の値は、必ず使用したい実際の値に置き換えてください。
`MASTER_CLUSTER_IP`は、前のサブセクションで説明したように、APIサーバーのサービスクラスターのIPです。
また、以下のサンプルでは、デフォルトのDNSドメイン名として`cluster.local`を使用することを想定しています。
```json
{
"CN": "kubernetes",
"hosts": [
"127.0.0.1",
"<MASTER_IP>",
"<MASTER_CLUSTER_IP>",
"kubernetes",
"kubernetes.default",
"kubernetes.default.svc",
"kubernetes.default.svc.cluster",
"kubernetes.default.svc.cluster.local"
],
"key": {
"algo": "rsa",
"size": 2048
},
"names": [{
"C": "<country>",
"ST": "<state>",
"L": "<city>",
"O": "<organization>",
"OU": "<organization unit>"
}]
}
```
1. APIサーバーの鍵と証明書を生成します。
デフォルトでは、それぞれ`server-key.pem`と`server.pem`というファイルに保存されます:
```shell
../cfssl gencert -ca=ca.pem -ca-key=ca-key.pem \
--config=ca-config.json -profile=kubernetes \
server-csr.json | ../cfssljson -bare server
```
## 自己署名入りCA証明書を配布する
@ -217,12 +273,12 @@ weight: 20
各クライアントで、次の操作を実行します:
```bash
```shell
sudo cp ca.crt /usr/local/share/ca-certificates/kubernetes.crt
sudo update-ca-certificates
```
```
```none
Updating certificates in /etc/ssl/certs...
1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d....
@ -231,5 +287,4 @@ done.
## 証明書API
認証に使用するx509証明書のプロビジョニングには`certificates.k8s.io` APIを使用することができます。[ここ](/docs/tasks/tls/managing-tls-in-a-cluster)に記述されています。
認証に使用するx509証明書のプロビジョニングには`certificates.k8s.io`APIを使用することができます。[クラスターでのTLSの管理](/docs/tasks/tls/managing-tls-in-a-cluster)に記述されています。

4
content/ja/docs/tasks/debug/debug-cluster/_index.md
View File

@ -60,13 +60,13 @@ kubectl cluster-info dump
### 具体的なシナリオ
- apiserver VMのシャットダウンまたはapiserverのクラッシュ
- 新しいPod、サービス、レプリケーションコントローラの停止、更新、起動ができない
- 新しいPod、サービス、レプリケーションコントローラーの停止、更新、起動ができない
- Kubernetes APIに依存していない限り、既存のPodやサービスは正常に動作し続けるはずです
- apiserverのバックアップストレージが失われた
- apiserverが立ち上がらない
- kubeletsは到達できなくなりますが、同じPodを実行し、同じサービスのプロキシを提供し続けます
- apiserverを再起動する前に、手動でapiserverの状態を回復または再現する必要がある
- サポートサービス(ノードコントローラ、レプリケーションコントローラーマネージャー、スケジューラーなど)VMのシャットダウンまたはクラッシュ
- サポートサービス(ノードコントローラー、レプリケーションコントローラーマネージャー、スケジューラーなど)VMのシャットダウンまたはクラッシュ
- 現在、これらはapiserverとコロケーションしており、使用できない場合はapiserverと同様の影響があります
- 将来的には、これらも複製されるようになり、同じ場所に配置されない可能性があります
- 独自の永続的な状態を持っていない。

2
content/ja/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
View File

@ -6,7 +6,7 @@ weight: 100
<!-- overview -->
Horizontal Pod Autoscalerは、Deployment、ReplicaSetまたはStatefulSetといったレプリケーションコントローラ内のPodの数を、観測されたCPU使用率（もしくはベータサポートの、アプリケーションによって提供されるその他のメトリクス）に基づいて自動的にスケールさせます。
Horizontal Pod Autoscalerは、Deployment、ReplicaSetまたはStatefulSetといったレプリケーションコントローラー内のPodの数を、観測されたCPU使用率（もしくはベータサポートの、アプリケーションによって提供されるその他のメトリクス）に基づいて自動的にスケールさせます。
このドキュメントはphp-apacheサーバーに対しHorizontal Pod Autoscalerを有効化するという例に沿ってウォークスルーで説明していきます。Horizontal Pod Autoscalerの動作についてのより詳細な情報を知りたい場合は、[Horizontal Pod Autoscalerユーザーガイド](/docs/tasks/run-application/horizontal-pod-autoscale/)をご覧ください。

2
content/ja/docs/tutorials/stateful-application/basic-stateful-set.md
View File

@ -492,7 +492,7 @@ web-0 1/1 Running 0 10s
StatefulSet内のPodは、順序インデックスの逆順に更新されました。StatefulSetコントローラーは各Podを終了させ、次のPodを更新する前に、新しいPodがRunningかつReadyの状態に変わるまで待機します。ここで、StatefulSetコントローラーは順序インデックスの前のPodがRunningかつReadyの状態になるまで次のPodの更新を始めず、現在の状態へのアップデートに失敗したPodがあった場合、そのPodをリストアすることに注意してください。
すでにアップデートを受け取ったPodは、アップデートされたバージョンにリストアされます。まだアップデートを受け取っていないPodは、前のバージョンにリストアされます。このような方法により、もし途中で失敗が起こっても、コントローラはアプリケーションが健全な状態を保ち続けられるようにし、更新が一貫したものになるようにします。
すでにアップデートを受け取ったPodは、アップデートされたバージョンにリストアされます。まだアップデートを受け取っていないPodは、前のバージョンにリストアされます。このような方法により、もし途中で失敗が起こっても、コントローラーはアプリケーションが健全な状態を保ち続けられるようにし、更新が一貫したものになるようにします。
Podを取得して、コンテナイメージを確認してみましょう。

2
content/ko/docs/tutorials/security/apparmor.md
View File

@ -158,7 +158,7 @@ kubectl get events | grep Created
컨테이너의 루트 프로세스가 올바른 프로파일로 실행되는지는 proc attr을 확인하여 직접 검증할 수 있다.
```shell
kubectl exec <pod_name> cat /proc/1/attr/current
kubectl exec <pod_name> -- cat /proc/1/attr/current
```
```
k8s-apparmor-example-deny-write (enforce)

2
content/pl/docs/concepts/overview/kubernetes-api.md
View File

@ -104,7 +104,7 @@ opisane są następującym schematem:
}
}
```
<!-- for editors: intionally use yaml instead of json here, to prevent syntax highlight error. -->
<!-- for editors: intentionally use yaml instead of json here, to prevent syntax highlight error. -->
Względne adresy URL wskazują na niezmieniające się opisy OpenAPI,
aby umożliwić trzymanie cache po stronie klienta. Serwer API zwraca

2
content/ru/docs/tasks/administer-cluster/certificates.md
View File

@ -128,7 +128,7 @@ weight: 20
```shell
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \
-CAcreateserial -out server.crt -days 10000 \
-extensions v3_ext -extfile csr.conf
-extensions v3_ext -extfile csr.conf -sha256
```
1. Используйте следующую команду, чтобы просмотреть запрос на подписание сертификата:

329
content/zh-cn/docs/concepts/cluster-administration/flow-control.md
View File

@ -4,6 +4,12 @@ content_type: concept
min-kubernetes-server-version: v1.18
weight: 110
---
<!--
title: API Priority and Fairness
content_type: concept
min-kubernetes-server-version: v1.18
weight: 110
-->
<!-- overview -->
@ -75,39 +81,40 @@ APF 适用于 **watch** 请求。当 APF 被禁用时，**watch** 请求不受 `
<!--
The API Priority and Fairness feature is controlled by a feature gate
and is enabled by default. See
and is enabled by default. See
[Feature Gates](/docs/reference/command-line-tools-reference/feature-gates/)
for a general explanation of feature gates and how to enable and
disable them. The name of the feature gate for APF is
"APIPriorityAndFairness". This feature also involves an {{<
glossary_tooltip term_id="api-group" text="API Group" >}} with: (a) a
`v1alpha1` version, disabled by default, and (b) `v1beta1` and
`v1beta2` versions, enabled by default. You can disable the feature
gate and API group beta versions by adding the following
command-line flags to your `kube-apiserver` invocation:
`v1alpha1` version and a `v1beta1` version, disabled by default, and
(b) `v1beta2` and `v1beta3` versions, enabled by default. You can
disable the feature gate and API group beta versions by adding the
following command-line flags to your `kube-apiserver` invocation:
-->
API 优先级与公平性（APF）特性由特性门控控制，默认情况下启用。
有关特性门控的一般性描述以及如何启用和禁用特性门控，
请参见[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)。
APF 的特性门控称为 `APIPriorityAndFairness`。
此特性也与某个 {{< glossary_tooltip term_id="api-group" text="API 组" >}}相关：
(a) `v1alpha1` 版本，默认被禁用；
(b) `v1beta1` 和 `v1beta2` 版本，默认被启用。
(a) `v1alpha1` 和 `v1beta1` 版本，默认被禁用；
(b) `v1beta2` 和 `v1beta3` 版本，默认被启用。
你可以在启动 `kube-apiserver` 时，添加以下命令行标志来禁用此功能门控及 API Beta 组：
```shell
kube-apiserver \
--feature-gates=APIPriorityAndFairness=false \
--runtime-config=flowcontrol.apiserver.k8s.io/v1beta1=false,flowcontrol.apiserver.k8s.io/v1beta2=false \
--runtime-config=flowcontrol.apiserver.k8s.io/v1beta2=false,flowcontrol.apiserver.k8s.io/v1beta3=false \
# ...其他配置不变
```
<!--
Alternatively, you can enable the v1alpha1 version of the API group
with `--runtime-config=flowcontrol.apiserver.k8s.io/v1alpha1=true`.
Alternatively, you can enable the v1alpha1 and v1beta1 versions of the API group
with `--runtime-config=flowcontrol.apiserver.k8s.io/v1alpha1=true,flowcontrol.apiserver.k8s.io/v1beta1=true`.
-->
或者，你也可以通过 `--runtime-config=flowcontrol.apiserver.k8s.io/v1alpha1=true`
启用 API 组的 v1alpha1 版本。
或者，你也可以通过
`--runtime-config=flowcontrol.apiserver.k8s.io/v1alpha1=true,flowcontrol.apiserver.k8s.io/v1beta1=true`
启用 API 组的 v1alpha1 和 v1beta1 版本。
<!--
The command-line flag `--enable-priority-and-fairness=false` will disable the
@ -118,6 +125,7 @@ API Priority and Fairness feature, even if other flags have enabled it.
<!--
## Concepts
There are several distinct features involved in the API Priority and Fairness
feature. Incoming requests are classified by attributes of the request using
_FlowSchemas_, and assigned to priority levels. Priority levels add a degree of
@ -144,14 +152,14 @@ Without APF enabled, overall concurrency in the API server is limited by the
defined by these flags are summed and then the sum is divided up among a
configurable set of _priority levels_. Each incoming request is assigned to a
single priority level, and each priority level will only dispatch as many
concurrent requests as its configuration allows.
concurrent requests as its particular limit allows.
-->
### 优先级 {#Priority-Levels}
如果未启用 APF，API 服务器中的整体并发量将受到 `kube-apiserver` 的参数
`--max-requests-inflight` 和 `--max-mutating-requests-inflight` 的限制。
启用 APF 后，将对这些参数定义的并发限制进行求和，然后将总和分配到一组可配置的 **优先级** 中。
每个传入的请求都会分配一个优先级；每个优先级都有各自的配置，设定允许分发的并发请求数。
每个传入的请求都会分配一个优先级；每个优先级都有各自的限制，设定特定限制允许分发的并发请求数。
<!--
The default configuration, for example, includes separate priority levels for
@ -163,6 +171,18 @@ from succeeding.
例如，默认配置包括针对领导者选举请求、内置控制器请求和 Pod 请求都单独设置优先级。
这表示即使异常的 Pod 向 API 服务器发送大量请求，也无法阻止领导者选举或内置控制器的操作执行成功。
<!--
The concurrency limits of the priority levels are periodically
adjusted, allowing under-utilized priority levels to temporarily lend
concurrency to heavily-utilized levels. These limits are based on
nominal limits and bounds on how much concurrency a priority level may
lend and how much it may borrow, all derived from the configuration
objects mentioned below.
-->
优先级的并发限制会被定期调整，允许利用率较低的优先级将并发度临时借给利用率很高的优先级。
这些限制基于一个优先级可以借出多少个并发度以及可以借用多少个并发度的额定限制和界限，
所有这些均源自下述配置对象。
<!--
### Seats Occupied by a Request
@ -324,22 +344,61 @@ requests, and limitations on the number of queued requests.
对未完成的请求数有各自的限制，对排队中的请求数也有限制。
<!--
Concurrency limits for PriorityLevelConfigurations are not specified in absolute
number of requests, but rather in "concurrency shares." The total concurrency
limit for the API Server is distributed among the existing
PriorityLevelConfigurations in proportion with these shares. This allows a
cluster administrator to scale up or down the total amount of traffic to a
server by restarting `kube-apiserver` with a different value for
`--max-requests-inflight` (or `--max-mutating-requests-inflight`), and all
PriorityLevelConfigurations will see their maximum allowed concurrency go up (or
down) by the same fraction.
The nominal oncurrency limit for a PriorityLevelConfiguration is not
specified in an absolute number of seats, but rather in "nominal
concurrency shares." The total concurrency limit for the API Server is
distributed among the existing PriorityLevelConfigurations in
proportion to these shares, to give each level its nominal limit in
terms of seats. This allows a cluster administrator to scale up or
down the total amount of traffic to a server by restarting
`kube-apiserver` with a different value for `--max-requests-inflight`
(or `--max-mutating-requests-inflight`), and all
PriorityLevelConfigurations will see their maximum allowed concurrency
go up (or down) by the same fraction.
-->
PriorityLevelConfiguration 的并发限制不是指定请求绝对数量，而是在“并发份额”中指定。
API 服务器的总并发量限制通过这些份额按例分配到现有 PriorityLevelConfiguration 中。
PriorityLevelConfiguration 的额定并发限制不是指定请求绝对数量，而是以“额定并发份额”的形式指定。
API 服务器的总并发量限制通过这些份额按例分配到现有 PriorityLevelConfiguration 中，
为每个级别按照数量赋予其额定限制。
集群管理员可以更改 `--max-requests-inflight` （或 `--max-mutating-requests-inflight`）的值，
再重新启动 `kube-apiserver` 来增加或减小服务器的总流量，
然后所有的 PriorityLevelConfiguration 将看到其最大并发增加（或减少）了相同的比例。
{{< caution >}}
<!--
In the versions before `v1beta3` the relevant
PriorityLevelConfiguration field is named "assured concurrency shares"
rather than "nominal concurrency shares". Also, in Kubernetes release
1.25 and earlier there were no periodic adjustments: the
nominal/assured limits were always applied without adjustment.
-->
在 `v1beta3` 之前的版本中，相关的 PriorityLevelConfiguration
字段被命名为“保证并发份额”而不是“额定并发份额”。此外在 Kubernetes v1.25
及更早的版本中，不存在定期的调整：所实施的始终是额定/保证的限制，不存在调整。
{{< /caution >}}
<!--
The bounds on how much concurrency a priority level may lend and how
much it may borrow are expressed in the PriorityLevelConfiguration as
percentages of the level's nominal limit. These are resolved to
absolute numbers of seats by multiplying with the nominal limit /
100.0 and rounding. The dynamically adjusted concurrency limit of a
priority level is constrained to lie between (a) a lower bound of its
nominal limit minus its lendable seats and (b) an upper bound of its
nominal limit plus the seats it may borrow. At each adjustment the
dynamic limits are derived by each priority level reclaiming any lent
seats for which demand recently appeared and then jointly fairly
responding to the recent seat demand on the priority levels, within
the bounds just described.
-->
一个优先级可以借出的并发数界限以及可以借用的并发数界限在
PriorityLevelConfiguration 表现该优先级的额定限制。
这些界限值乘以额定限制/100.0 并取整，被解析为绝对席位数量。
某优先级的动态调整并发限制范围被约束在
(a) 其额定限制的下限值减去其可借出的席位和
(b) 其额定限制的上限值加上它可以借用的席位之间。
在每次调整时，通过每个优先级推导得出动态限制，具体过程为回收最近出现需求的所有借出的席位，
然后在刚刚描述的界限内共同公平地响应有关这些优先级最近的席位需求。
{{< caution >}}
<!--
With the Priority and Fairness feature enabled, the total concurrency limit for
@ -349,10 +408,9 @@ between mutating and non-mutating requests; if you want to treat them
separately for a given resource, make separate FlowSchemas that match the
mutating and non-mutating verbs respectively.
-->
启用 APF 特性后，服务器的总并发量限制将设置为
`--max-requests-inflight` 和 `--max-mutating-requests-inflight` 之和。
可变请求和不可变请求之间不再有任何区别；
如果对于某种资源，你需要区别对待不同请求，请创建不同的 FlowSchema 分别匹配可变请求和不可变请求。
启用 APF 特性时，服务器的总并发限制被设置为 `--max-requests-inflight` 及
`--max-mutating-requests-inflight` 之和。变更性和非变更性请求之间不再有任何不同；
如果你想针对某给定资源分别进行处理，请制作单独的 FlowSchema，分别匹配变更性和非变更性的动作。
{{< /caution >}}
<!--
@ -842,15 +900,16 @@ poorly-behaved workloads that may be harming system health.
* `apiserver_flowcontrol_rejected_requests_total` is a counter vector
(cumulative since server start) of requests that were rejected,
broken down by the labels `flow_schema` (indicating the one that
matched the request), `priority_evel` (indicating the one to which
matched the request), `priority_level` (indicating the one to which
the request was assigned), and `reason`. The `reason` label will be
have one of the following values:
-->
* `apiserver_flowcontrol_rejected_requests_total` 是一个计数器向量，
记录被拒绝的请求数量（自服务器启动以来累计值），
由标签 `flow_chema`（表示与请求匹配的 FlowSchema）、`priority_evel`
由标签 `flow_chema`（表示与请求匹配的 FlowSchema）、`priority_level`
（表示分配给请该求的优先级）和 `reason` 来区分。
`reason` 标签将具有以下值之一：
<!--
* `queue-full`, indicating that too many requests were already
queued,
@ -895,42 +954,22 @@ poorly-behaved workloads that may be harming system health.
（该量保存了最后一个窗口中，正在处理的请求数量的高水位线）。
<!--
* `apiserver_flowcontrol_read_vs_write_request_count_samples` is a
histogram vector of observations of the then-current number of
requests, broken down by the labels `phase` (which takes on the
values `waiting` and `executing`) and `request_kind` (which takes on
the values `mutating` and `readOnly`). The observations are made
periodically at a high rate. Each observed value is a ratio,
between 0 and 1, of a number of requests divided by the
corresponding limit on the number of requests (queue length limit
for waiting and concurrency limit for executing).
* `apiserver_flowcontrol_read_vs_write_current_requests` is a
histogram vector of observations, made at the end of every
nanosecond, of the number of requests broken down by the labels
`phase` (which takes on the values `waiting` and `executing`) and
`request_kind` (which takes on the values `mutating` and
`readOnly`). Each observed value is a ratio, between 0 and 1, of a
number of requests divided by the corresponding limit on the number
of requests (queue volume limit for waiting and concurrency limit
for executing).
-->
* `apiserver_flowcontrol_read_vs_write_request_count_samples` 是一个直方图向量，
记录当前请求数量的观察值，
由标签 `phase`（取值为 `waiting` 及 `executing`）和 `request_kind`
（取值 `mutating` 及 `readOnly`）拆分。定期以高速率观察该值。
* `apiserver_flowcontrol_read_vs_write_current_requests` 是一个直方图向量，
在每个纳秒结束时记录请求数量的观察值，由标签 `phase`（取值为 `waiting` 及 `executing`）
和 `request_kind`（取值为 `mutating` 及 `readOnly`）区分。
每个观察到的值是一个介于 0 和 1 之间的比值，计算方式为请求数除以该请求数的对应限制
（等待的队列长度限制和执行所用的并发限制）。
<!--
* `apiserver_flowcontrol_read_vs_write_request_count_watermarks` is a
histogram vector of high or low water marks of the number of
requests (divided by the corresponding limit to get a ratio in the
range 0 to 1) broken down by the labels `phase` (which takes on the
values `waiting` and `executing`) and `request_kind` (which takes on
the values `mutating` and `readOnly`); the label `mark` takes on
values `high` and `low`. The water marks are accumulated over
windows bounded by the times when an observation was added to
`apiserver_flowcontrol_read_vs_write_request_count_samples`. These
water marks show the range of values that occurred between samples.
-->
* `apiserver_flowcontrol_read_vs_write_request_count_watermarks`
是请求数量的高或低水位线的直方图向量（除以相应的限制，得到介于 0 至 1 的比率），
由标签 `phase`（取值为 `waiting` 及 `executing`）和 `request_kind`
（取值为 `mutating` 及 `readOnly`）拆分；标签 `mark` 取值为 `high` 和 `low`。
`apiserver_flowcontrol_read_vs_write_request_count_samples` 向量观察到有值新增，
则该向量累积。这些水位线显示了样本值的范围。
<!--
* `apiserver_flowcontrol_current_inqueue_requests` is a gauge vector
holding the instantaneous number of queued (not executing) requests,
@ -938,7 +977,7 @@ poorly-behaved workloads that may be harming system health.
-->
* `apiserver_flowcontrol_current_inqueue_requests` 是一个表向量，
记录包含排队中的（未执行）请求的瞬时数量，
由标签 `priority_level` 和 `flow_schema` 拆分。
由标签 `priority_level` 和 `flow_schema` 区分。
<!--
* `apiserver_flowcontrol_current_executing_requests` is a gauge vector
@ -959,43 +998,41 @@ poorly-behaved workloads that may be harming system health.
包含占用座位的瞬时数量，由标签 `priority_level` 和 `flow_schema` 进一步区分。
<!--
* `apiserver_flowcontrol_priority_level_request_count_samples` is a
histogram vector of observations of the then-current number of
requests broken down by the labels `phase` (which takes on the
values `waiting` and `executing`) and `priority_level`. Each
histogram gets observations taken periodically, up through the last
activity of the relevant sort. The observations are made at a high
rate. Each observed value is a ratio, between 0 and 1, of a number
of requests divided by the corresponding limit on the number of
requests (queue length limit for waiting and concurrency limit for
executing).
* `apiserver_flowcontrol_priority_level_request_utilization` is a
histogram vector of observations, made at the end of each
nanosecond, of the number of requests broken down by the labels
`phase` (which takes on the values `waiting` and `executing`) and
`priority_level`. Each observed value is a ratio, between 0 and 1,
of a number of requests divided by the corresponding limit on the
number of requests (queue volume limit for waiting and concurrency
limit for executing).
-->
* `apiserver_flowcontrol_priority_level_request_count_samples` 是一个直方图向量，
记录当前请求的观测值，由标签 `phase`（取值为`waiting` 及 `executing`）和
`priority_level` 进一步区分。
每个直方图都会定期进行观察，直到相关类别的最后活动为止。观察频率高。
所观察到的值都是请求数除以相应的请求数限制（等待的队列长度限制和执行的并发限制）的比率，
介于 0 和 1 之间。
* `apiserver_flowcontrol_priority_level_request_utilization` 是一个直方图向量，
在每个纳秒结束时记录请求数量的观察值，
由标签 `phase`（取值为 `waiting` 及 `executing`）和 `priority_level` 区分。
每个观察到的值是一个介于 0 和 1 之间的比值，计算方式为请求数除以该请求数的对应限制
（等待的队列长度限制和执行所用的并发限制）。
<!--
* `apiserver_flowcontrol_priority_level_request_count_watermarks` is a
histogram vector of high or low water marks of the number of
requests (divided by the corresponding limit to get a ratio in the
range 0 to 1) broken down by the labels `phase` (which takes on the
values `waiting` and `executing`) and `priority_level`; the label
`mark` takes on values `high` and `low`. The water marks are
accumulated over windows bounded by the times when an observation
was added to
`apiserver_flowcontrol_priority_level_request_count_samples`. These
water marks show the range of values that occurred between samples.
* `apiserver_flowcontrol_priority_level_seat_utilization` is a
histogram vector of observations, made at the end of each
nanosecond, of the utilization of a priority level's concurrency
limit, broken down by `priority_level`. This utilization is the
fraction (number of seats occupied) / (concurrency limit). This
metric considers all stages of execution (both normal and the extra
delay at the end of a write to cover for the corresponding
notification work) of all requests except WATCHes; for those it
considers only the initial stage that delivers notifications of
pre-existing objects. Each histogram in the vector is also labeled
with `phase: executing` (there is no seat limit for the waiting
phase).
-->
* `apiserver_flowcontrol_priority_level_request_count_watermarks`
是请求数量的高或低水位线的直方图向量（除以相应的限制，得到 0 到 1 的范围内的比率），
由标签 `phase`（取值为 `waiting` 及 `executing`）和
`priority_level` 拆分；
标签 `mark` 取值为 `high` 和 `low`。
`apiserver_flowcontrol_priority_level_request_count_samples` 向量观察到有值新增，
则该向量累积。这些水位线显示了样本值的范围。
* `apiserver_flowcontrol_priority_level_seat_utilization` 是一个直方图向量，
在每个纳秒结束时记录某个优先级并发度限制利用率的观察值，由标签 `priority_level` 区分。
此利用率是一个分数：（占用的席位数）/（并发限制）。
此指标考虑了除 WATCH 之外的所有请求的所有执行阶段（包括写入结束时的正常延迟和额外延迟，
以覆盖相应的通知操作）；对于 WATCH 请求，只考虑传递预先存在对象通知的初始阶段。
该向量中的每个直方图也带有 `phase: executing`（等待阶段没有席位限制）的标签。
<!--
* `apiserver_flowcontrol_request_queue_length_after_enqueue` is a
@ -1027,14 +1064,98 @@ poorly-behaved workloads that may be harming system health.
{{< /note >}}
<!--
* `apiserver_flowcontrol_request_concurrency_limit` is a gauge vector
holding the computed concurrency limit (based on the API server's
total concurrency limit and PriorityLevelConfigurations' concurrency
shares), broken down by the label `priority_level`.
* `apiserver_flowcontrol_request_concurrency_limit` is the same as
`apiserver_flowcontrol_nominal_limit_seats`. Before the
introduction of concurrency borrowing between priority levels, this
was always equal to `apiserver_flowcontrol_current_limit_seats`
(which did not exist as a distinct metric).
-->
* `apiserver_flowcontrol_request_concurrency_limit` 是一个表向量，
记录并发限制的计算值（基于 API 服务器的总并发限制和 PriorityLevelConfiguration
的并发份额），并按标签 `priority_level` 进一步区分。
* `apiserver_flowcontrol_request_concurrency_limit` 与
`apiserver_flowcontrol_nominal_limit_seats` 相同。在优先级之间引入并发度借用之前，
此字段始终等于 `apiserver_flowcontrol_current_limit_seats`
（它过去不作为一个独立的指标存在）。
<!--
* `apiserver_flowcontrol_nominal_limit_seats` is a gauge vector
holding each priority level's nominal concurrency limit, computed
from the API server's total concurrency limit and the priority
level's configured nominal concurrency shares.
-->
* `apiserver_flowcontrol_nominal_limit_seats` 是一个表向量，包含每个优先级的额定并发度限制，
指标值根据 API 服务器的总并发度限制和各优先级所配置的额定并发度份额计算得出。
<!--
* `apiserver_flowcontrol_lower_limit_seats` is a gauge vector holding
the lower bound on each priority level's dynamic concurrency limit.
-->
* `apiserver_flowcontrol_lower_limit_seats` 是一个表向量，包含每个优先级的动态并发度限制的下限。
<!--
* `apiserver_flowcontrol_upper_limit_seats` is a gauge vector holding
the upper bound on each priority level's dynamic concurrency limit.
-->
* `apiserver_flowcontrol_upper_limit_seats` 是一个表向量，包含每个优先级的动态并发度限制的上限。
<!--
* `apiserver_flowcontrol_demand_seats` is a histogram vector counting
observations, at the end of every nanosecond, of each priority
level's ratio of (seat demand) / (nominal concurrency limit). A
priority level's seat demand is the sum, over both queued requests
and those in the initial phase of execution, of the maximum of the
number of seats occupied in the request's initial and final
execution phases.
-->
* `apiserver_flowcontrol_demand_seats` 是一个直方图向量，
统计每纳秒结束时每个优先级的（席位需求）/（额定并发限制）比率的观察值。
某优先级的席位需求是针对排队的请求和初始执行阶段的请求，在请求的初始和最终执行阶段占用的最大席位数之和。
<!--
* `apiserver_flowcontrol_demand_seats_high_watermark` is a gauge vector
holding, for each priority level, the maximum seat demand seen
during the last concurrency borrowing adjustment period.
-->
* `apiserver_flowcontrol_demand_seats_high_watermark` 是一个表向量，
为每个优先级包含了上一个并发度借用调整期间所观察到的最大席位需求。
<!--
* `apiserver_flowcontrol_demand_seats_average` is a gauge vector
holding, for each priority level, the time-weighted average seat
demand seen during the last concurrency borrowing adjustment period.
-->
* `apiserver_flowcontrol_demand_seats_average` 是一个表向量，
为每个优先级包含了上一个并发度借用调整期间所观察到的时间加权平均席位需求。
<!--
* `apiserver_flowcontrol_demand_seats_stdev` is a gauge vector
holding, for each priority level, the time-weighted population
standard deviation of seat demand seen during the last concurrency
borrowing adjustment period.
-->
* `apiserver_flowcontrol_demand_seats_stdev` 是一个表向量，
为每个优先级包含了上一个并发度借用调整期间所观察到的席位需求的时间加权总标准偏差。
<!--
* `apiserver_flowcontrol_target_seats` is a gauge vector holding, for
each priority level, the concurrency target going into the borrowing
allocation problem.
-->
* `apiserver_flowcontrol_target_seats` 是一个表向量，
包含每个优先级触发借用分配问题的并发度目标值。
<!--
* `apiserver_flowcontrol_seat_fair_frac` is a gauge holding the fair
allocation fraction determined in the last borrowing adjustment.
-->
* `apiserver_flowcontrol_seat_fair_frac` 是一个表向量，
包含了上一个借用调整期间确定的公平分配比例。
<!--
* `apiserver_flowcontrol_current_limit_seats` is a gauge vector
holding, for each priority level, the dynamic concurrency limit
derived in the last adjustment.
-->
* `apiserver_flowcontrol_current_limit_seats` 是一个表向量，
包含每个优先级的上一次调整期间得出的动态并发限制。
<!--
* `apiserver_flowcontrol_request_wait_duration_seconds` is a histogram

18
content/zh-cn/docs/concepts/scheduling-eviction/kube-scheduler.md
View File

@ -64,16 +64,16 @@ write your own scheduling component and use that instead.
在设计上允许你自己编写一个调度组件并替换原有的 kube-scheduler。
<!--
For every newly created pods or other unscheduled pods, kube-scheduler
selects a optimal node for them to run on. However, every container in
pods has different requirements for resources and every pod also has
different requirements. Therefore, existing nodes need to be filtered
according to the specific scheduling requirements.
Kube-scheduler selects an optimal node to run newly created or not yet
scheduled (unscheduled) pods. Since containers in pods - and pods themselves -
can have different requirements, the scheduler filters out any nodes that
don't meet a Pod's specific scheduling needs. Alternatively, the API lets
you specify a node for a Pod when you create it, but this is unusual
and is only done in special cases.
-->
对每一个新创建的 Pod 或者是未被调度的 Pod，kube-scheduler 会选择一个最优的节点去运行这个 Pod。
然而，Pod 内的每一个容器对资源都有不同的需求，
而且 Pod 本身也有不同的需求。因此，Pod 在被调度到节点上之前，
根据这些特定的调度需求，需要对集群中的节点进行一次过滤。
Kube-scheduler 选择一个最佳节点来运行新创建的或尚未调度（unscheduled）的 Pod。
由于 Pod 中的容器和 Pod 本身可能有不同的要求，调度程序会过滤掉任何不满足 Pod 特定调度需求的节点。
或者，API 允许你在创建 Pod 时为它指定一个节点，但这并不常见，并且仅在特殊情况下才会这样做。
<!--
In a cluster, Nodes that meet the scheduling requirements for a Pod

34
content/zh-cn/docs/concepts/services-networking/ingress.md
View File

@ -4,7 +4,7 @@ content_type: concept
description: >-
使用一种能感知协议配置的机制来理解 URI、主机名称、路径和更多 Web 概念，使得 HTTP（或 HTTPS）网络服务可用。
Ingress 概念允许你通过 Kubernetes API 定义的规则将流量映射到不同的后端。
weight: 20
weight: 30
---
<!--
reviewers:
@ -16,7 +16,7 @@ description: >-
mechanism, that understands web concepts like URIs, hostnames, paths, and more.
The Ingress concept lets you map traffic to different backends based on rules you define
via the Kubernetes API.
weight: 20
weight: 30
-->
<!-- overview -->
@ -199,7 +199,7 @@ Each HTTP rule contains the following information:
load balancer directs traffic to the referenced Service.
* A backend is a combination of Service and port names as described in the
[Service doc](/docs/concepts/services-networking/service/). HTTP (and HTTPS) requests to the
Ingress that matches the host and path of the rule are sent to the listed backend.
Ingress that match the host and path of the rule are sent to the listed backend.
-->
* 可选的 `host`。在此示例中，未指定 `host`，因此该规则适用于通过指定 IP 地址的所有入站 HTTP 通信。
如果提供了 `host`（例如 foo.bar.com），则 `rules` 适用于该 `host`。
@ -234,8 +234,8 @@ routed to your default backend.
没有设置规则的 Ingress 将所有流量发送到同一个默认后端，而
`.spec.defaultBackend` 则是在这种情况下处理请求的那个默认后端。
`defaultBackend` 通常是
[Ingress 控制器](/zh-cn/docs/concepts/services-networking/ingress-controllers)的配置选项，而非在
Ingress 资源中指定。
[Ingress 控制器](/zh-cn/docs/concepts/services-networking/ingress-controllers)的配置选项，
而非在 Ingress 资源中指定。
如果未设置任何的 `.spec.rules`，那么必须指定 `.spec.defaultBackend`。
如果未设置 `defaultBackend`，那么如何处理所有与规则不匹配的流量将交由
Ingress 控制器决定（请参考你的 Ingress 控制器的文档以了解它是如何处理那些流量的）。
@ -309,7 +309,7 @@ Ingress 中的每个路径都需要有对应的路径类型（Path Type）。未
If the last element of the path is a substring of the last
element in request path, it is not a match (for example: `/foo/bar`
matches`/foo/bar/baz`, but does not match `/foo/barbaz`).
matches `/foo/bar/baz`, but does not match `/foo/barbaz`).
-->
* `ImplementationSpecific`：对于这种路径类型，匹配方法取决于 IngressClass。
具体实现可以将其作为单独的 `pathType` 处理或者与 `Prefix` 或 `Exact` 类型作相同处理。
@ -318,7 +318,7 @@ Ingress 中的每个路径都需要有对应的路径类型（Path Type）。未
* `Prefix`：基于以 `/` 分隔的 URL 路径前缀匹配。匹配区分大小写，并且对路径中的元素逐个完成。
路径元素指的是由 `/` 分隔符分隔的路径中的标签列表。
如果每个 _p_ 都是请求路径 _p_ 的元素前缀，则请求与路径 _p_ 匹配。
如果每个 **p** 都是请求路径 **p** 的元素前缀，则请求与路径 **p** 匹配。
{{< note >}}
如果路径的最后一个元素是请求路径中最后一个元素的子字符串，则不会匹配
@ -396,8 +396,8 @@ equal to the suffix of the wildcard rule.
-->
## 主机名通配符 {#hostname-wildcards}
主机名可以是精确匹配（例如“`foo.bar.com`”）或者使用通配符来匹配
（例如“`*.foo.com`”）。
主机名可以是精确匹配（例如 “`foo.bar.com`”）或者使用通配符来匹配
（例如 “`*.foo.com`”）。
精确匹配要求 HTTP `host` 头部字段与 `host` 字段值完全匹配。
通配符匹配则要求 HTTP `host` 头部字段与通配符规则中的后缀部分相同。
@ -471,8 +471,8 @@ For example:
IngressClass 的参数默认是集群范围的。
如果你设置了 `.spec.parameters` 字段且未设置 `.spec.parameters.scope`
字段，或是将 `.spec.parameters.scope` 字段设为了 `Cluster`，那么该
IngressClass 所指代的即是一个集群作用域的资源。
字段，或是将 `.spec.parameters.scope` 字段设为了 `Cluster`，
那么该 IngressClass 所指代的即是一个集群作用域的资源。
参数的 `kind`（和 `apiGroup` 一起）指向一个集群作用域的
API（可能是一个定制资源（Custom Resource）），而它的
`name` 则为此 API 确定了一个具体的集群作用域的资源。
@ -578,8 +578,8 @@ never formally defined, but was widely supported by Ingress controllers.
-->
### 废弃的注解 {#deprecated-annotation}
在 Kubernetes 1.18 版本引入 IngressClass 资源和 `ingressClassName` 字段之前，Ingress
类是通过 Ingress 中的一个 `kubernetes.io/ingress.class` 注解来指定的。
在 Kubernetes 1.18 版本引入 IngressClass 资源和 `ingressClassName` 字段之前，
Ingress 类是通过 Ingress 中的一个 `kubernetes.io/ingress.class` 注解来指定的。
这个注解从未被正式定义过，但是得到了 Ingress 控制器的广泛支持。
<!--
@ -649,7 +649,7 @@ There are existing Kubernetes concepts that allow you to expose a single Service
### 由单个 Service 来完成的 Ingress {#single-service-ingress}
现有的 Kubernetes 概念允许你暴露单个 Service (参见[替代方案](#alternatives))。
你也可以通过指定无规则的 *默认后端* 来对 Ingress 进行此操作。
你也可以通过指定无规则的**默认后端**来对 Ingress 进行此操作。
{{< codenew file="service/networking/test-ingress.yaml" >}}
@ -767,8 +767,8 @@ Name-based virtual hosts support routing HTTP traffic to multiple host names at
The following Ingress tells the backing load balancer to route requests based on
the [Host header](https://tools.ietf.org/html/rfc7230#section-5.4).
-->
以下 Ingress 让后台负载均衡器基于[host 头部字段](https://tools.ietf.org/html/rfc7230#section-5.4)
来路由请求。
以下 Ingress 让后台负载均衡器基于
[host 头部字段](https://tools.ietf.org/html/rfc7230#section-5.4)来路由请求。
{{< codenew file="service/networking/name-virtual-host-ingress.yaml" >}}
@ -1034,7 +1034,7 @@ You can expose a Service in multiple ways that don't directly involve the Ingres
* Learn about [Ingress Controllers](/docs/concepts/services-networking/ingress-controllers/)
* [Set up Ingress on Minikube with the NGINX Controller](/docs/tasks/access-application-cluster/ingress-minikube/)
-->
* 进一步了解 [Ingress](/docs/reference/kubernetes-api/service-resources/ingress-v1/) API
* 进一步了解 [Ingress](/zh-cn/docs/reference/kubernetes-api/service-resources/ingress-v1/) API
* 进一步了解 [Ingress 控制器](/zh-cn/docs/concepts/services-networking/ingress-controllers/)
* [使用 NGINX 控制器在 Minikube 上安装 Ingress](/zh-cn/docs/tasks/access-application-cluster/ingress-minikube/)

733
content/zh-cn/docs/concepts/services-networking/service.md
View File

@ -165,7 +165,7 @@ 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
(see [Virtual IPs and service proxies](#virtual-ips-and-service-proxies) below).
(see [Virtual IP addressing mechanism](#virtual-ip-addressing-mechanism) below).
The controller for the Service selector continuously scans for Pods that
match its selector, and then POSTs any updates to an Endpoint object
@ -175,7 +175,7 @@ also named "my-service".
TCP 端口 9376，并且具有标签 `app.kubernetes.io/name=MyApp` 的 Pod 上。
Kubernetes 为该服务分配一个 IP 地址（有时称为 “集群 IP”），该 IP 地址由服务代理使用。
(请参见下面的 [VIP 和 Service 代理](#virtual-ips-and-service-proxies)).
(请参见下面的[虚拟 IP 寻址机制](#virtual-ip-addressing-mechanism)).
服务选择算符的控制器不断扫描与其选择算符匹配的 Pod，然后将所有更新发布到也称为
“my-service” 的 Endpoint 对象。
@ -240,14 +240,16 @@ in the next version of your backend software, without breaking clients.
例如，你可以在新版本中更改 Pod 中后端软件公开的端口号，而不会破坏客户端。
<!--
The default protocol for Services is TCP; you can also use any other
[supported protocol](#protocol-support).
The default protocol for Services is
[TCP](/docs/reference/networking/service-protocols/#protocol-tcp); you can also
use any other [supported protocol](/docs/reference/networking/service-protocols/).
As many Services need to expose more than one port, Kubernetes supports multiple
port definitions on a Service object.
Each port definition can have the same `protocol`, or a different one.
-->
服务的默认协议是 TCP；你还可以使用任何其他[受支持的协议](#protocol-support)。
服务的默认协议是 TCP(/zh-cn/docs/reference/networking/service-protocols/#protocol-tcp)；
你还可以使用任何其他[受支持的协议](/zh-cn/docs/reference/networking/service-protocols/)。
由于许多服务需要公开多个端口，因此 Kubernetes 在服务对象上支持多个端口定义。
每个端口定义可以具有相同的 `protocol`，也可以具有不同的协议。
@ -518,263 +520,6 @@ domain prefixed names such as `mycompany.com/my-custom-protocol`.
其值可以是 [IANA 标准服务名称](https://www.iana.org/assignments/service-names)
或以域名为前缀的名称，如 `mycompany.com/my-custom-protocol`。
<!--
## Virtual IPs and service proxies
Every node in a Kubernetes cluster runs a `kube-proxy`. `kube-proxy` is
responsible for implementing a form of virtual IP for `Services` of type other
than [`ExternalName`](#externalname).
-->
## 虚拟 IP 和 Service 代理 {#virtual-ips-and-service-proxies}
在 Kubernetes 集群中，每个 Node 运行一个 `kube-proxy` 进程。
`kube-proxy` 负责为 Service 实现了一种 VIP（虚拟 IP）的形式，而不是
[`ExternalName`](#externalname) 的形式。
<!--
### Why not use round-robin DNS?
A question that pops up every now and then is why Kubernetes relies on
proxying to forward inbound traffic to backends. What about other
approaches? For example, would it be possible to configure DNS records that
have multiple A values (or AAAA for IPv6), and rely on round-robin name
resolution?
There are a few reasons for using proxying for Services:
* There is a long history of DNS implementations not respecting record TTLs,
and caching the results of name lookups after they should have expired.
* Some apps do DNS lookups only once and cache the results indefinitely.
* Even if apps and libraries did proper re-resolution, the low or zero TTLs
on the DNS records could impose a high load on DNS that then becomes
difficult to manage.
-->
### 为什么不使用 DNS 轮询？ {#why-not-use-round-robin-dns}
时不时会有人问到为什么 Kubernetes 依赖代理将入站流量转发到后端。那其他方法呢？
例如，是否可以配置具有多个 A 值（或 IPv6 为 AAAA）的 DNS 记录，并依靠轮询名称解析？
使用服务代理有以下几个原因：
* DNS 实现的历史由来已久，它不遵守记录 TTL，并且在名称查找结果到期后对其进行缓存。
* 有些应用程序仅执行一次 DNS 查找，并无限期地缓存结果。
* 即使应用和库进行了适当的重新解析，DNS 记录上的 TTL 值低或为零也可能会给
DNS 带来高负载，从而使管理变得困难。
<!--
Later in this page you can read about how 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,
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`
executable supports a `cleanup` function, this function is not an official feature and
thus is only available to use as-is.
-->
在本页下文中，你可以了解各种 kube-proxy 实现是如何工作的。
总的来说，你应该注意当运行 `kube-proxy` 时，内核级别的规则可能会被修改（例如，可能会创建 iptables 规则），
在某些情况下直到你重新引导才会清理这些内核级别的规则。
因此，运行 kube-proxy 只能由了解在计算机上使用低级别、特权网络代理服务后果的管理员来完成。
尽管 `kube-proxy` 可执行文件支持 `cleanup` 功能，但此功能不是官方特性，因此只能按原样使用。
<!--
### Configuration
Note that the kube-proxy starts up in different modes, which are determined by its configuration.
- The kube-proxy's configuration is done via a ConfigMap, and the ConfigMap for kube-proxy
effectively deprecates the behavior for almost all of the flags for the kube-proxy.
- The ConfigMap for the kube-proxy does not support live reloading of configuration.
- The ConfigMap parameters for the kube-proxy cannot all be validated and verified on startup.
For example, if your operating system doesn't allow you to run iptables commands,
the standard kernel kube-proxy implementation will not work.
Likewise, if you have an operating system which doesn't support `netsh`,
it will not run in Windows userspace mode.
-->
### 配置 {#configuration}
请注意，kube-proxy 可以以不同的模式启动，具体取决于其配置。
- kube-proxy 的配置是通过 ConfigMap 完成的，并且 kube-proxy 的 ConfigMap 有效地弃用了 kube-proxy 几乎所有标志的行为。
- kube-proxy 的 ConfigMap 不支持实时重新加载配置。
- kube-proxy 的 ConfigMap 参数不能在启动时被全部校验和验证。
例如，如果你的操作系统不允许你运行 iptables 命令，则标准内核 kube-proxy 实现将无法工作。
同样，如果你的操作系统不支持 `netsh`，它将无法在 Windows 用户空间模式下运行。
<!--
### User space proxy mode {#proxy-mode-userspace}
In this (legacy) mode, kube-proxy watches the Kubernetes control plane for the addition and
removal of Service and Endpoint objects. For each Service it opens a
port (randomly chosen) on the local node. Any connections to this "proxy port"
are proxied to one of the Service's backend Pods (as reported via
Endpoints). kube-proxy takes the `SessionAffinity` setting of the Service into
account when deciding which backend Pod to use.
Lastly, the user-space proxy installs iptables rules which capture traffic to
the Service's `clusterIP` (which is virtual) and `port`. The rules
redirect that traffic to the proxy port which proxies the backend Pod.
By default, kube-proxy in userspace mode chooses a backend via a round-robin algorithm.
![Services overview diagram for userspace proxy](/images/docs/services-userspace-overview.svg)
-->
### userspace 代理模式 {#proxy-mode-userspace}
在这种（遗留）模式下，kube-proxy 会监视 Kubernetes 控制平面对 Service 对象和 Endpoints 对象的添加和移除操作。
对每个 Service，它会在本地 Node 上打开一个端口（随机选择）。
任何连接到“代理端口”的请求，都会被代理到 Service 的后端 `Pods` 中的某个上面（如 `Endpoints` 所报告的一样）。
使用哪个后端 Pod，是 kube-proxy 基于 `SessionAffinity` 来确定的。
最后，它配置 iptables 规则，捕获到达该 Service 的 `clusterIP`（是虚拟 IP）
和 `Port` 的请求，并重定向到代理端口，代理端口再代理请求到后端Pod。
默认情况下，用户空间模式下的 kube-proxy 通过轮转算法选择后端。
![userspace 代理模式下 Service 概览图](/images/docs/services-userspace-overview.svg)
<!--
### `iptables` proxy mode {#proxy-mode-iptables}
In this mode, kube-proxy watches the Kubernetes control plane for the addition and
removal of Service and Endpoint objects. For each Service, it installs
iptables rules, which capture traffic to the Service's `clusterIP` and `port`,
and redirect that traffic to one of the Service's
backend sets. For each Endpoint object, it installs iptables rules which
select a backend Pod.
By default, kube-proxy in iptables mode chooses a backend at random.
Using iptables to handle traffic has a lower system overhead, because traffic
is handled by Linux netfilter without the need to switch between userspace and the
kernel space. This approach is also likely to be more reliable.
If kube-proxy is running in iptables mode and the first Pod that's selected
does not respond, the connection fails. This is different from userspace
mode: in that scenario, kube-proxy would detect that the connection to the first
Pod had failed and would automatically retry with a different backend Pod.
You can use Pod [readiness probes](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)
to verify that backend Pods are working OK, so that kube-proxy in iptables mode
only sees backends that test out as healthy. Doing this means you avoid
having traffic sent via kube-proxy to a Pod that's known to have failed.
![Services overview diagram for iptables proxy](/images/docs/services-iptables-overview.svg)
-->
### iptables 代理模式 {#proxy-mode-iptables}
这种模式，`kube-proxy` 会监视 Kubernetes 控制节点对 Service 对象和 Endpoints 对象的添加和移除。
对每个 Service，它会配置 iptables 规则，从而捕获到达该 Service 的 `clusterIP`
和端口的请求，进而将请求重定向到 Service 的一组后端中的某个 Pod 上面。
对于每个 Endpoints 对象，它也会配置 iptables 规则，这个规则会选择一个后端组合。
默认的策略是，kube-proxy 在 iptables 模式下随机选择一个后端。
使用 iptables 处理流量具有较低的系统开销，因为流量由 Linux netfilter 处理，
而无需在用户空间和内核空间之间切换。 这种方法也可能更可靠。
如果 kube-proxy 在 iptables 模式下运行，并且所选的第一个 Pod 没有响应，则连接失败。
这与用户空间模式不同：在这种情况下，kube-proxy 将检测到与第一个 Pod 的连接已失败，
并会自动使用其他后端 Pod 重试。
你可以使用 Pod [就绪探测器](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)
验证后端 Pod 可以正常工作，以便 iptables 模式下的 kube-proxy 仅看到测试正常的后端。
这样做意味着你避免将流量通过 kube-proxy 发送到已知已失败的 Pod。
![iptables 代理模式下 Service 概览图](/images/docs/services-iptables-overview.svg)
<!--
### IPVS proxy mode {#proxy-mode-ipvs}
-->
### IPVS 代理模式 {#proxy-mode-ipvs}
{{< feature-state for_k8s_version="v1.11" state="stable" >}}
<!--
In `ipvs` mode, kube-proxy watches Kubernetes Services and Endpoints,
calls `netlink` interface to create IPVS rules accordingly and synchronizes
IPVS rules with Kubernetes Services and Endpoints periodically.
This control loop ensures that IPVS status matches the desired
state.
When accessing a Service, IPVS directs traffic to one of the backend Pods.
The IPVS proxy mode is based on netfilter hook function that is similar to
iptables mode, but uses a hash table as the underlying data structure and works
in the kernel space.
That means kube-proxy in IPVS mode redirects traffic with lower latency than
kube-proxy in iptables mode, with much better performance when synchronizing
proxy rules. Compared to the other proxy modes, IPVS mode also supports a
higher throughput of network traffic.
IPVS provides more options for balancing traffic to backend Pods;
these are:
-->
在 `ipvs` 模式下，kube-proxy 监视 Kubernetes 服务和端点，调用 `netlink` 接口相应地创建 IPVS 规则，
并定期将 IPVS 规则与 Kubernetes 服务和端点同步。该控制循环可确保 IPVS
状态与所需状态匹配。访问服务时，IPVS 将流量定向到后端 Pod 之一。
IPVS 代理模式基于类似于 iptables 模式的 netfilter 挂钩函数，
但是使用哈希表作为基础数据结构，并且在内核空间中工作。
这意味着，与 iptables 模式下的 kube-proxy 相比，IPVS 模式下的 kube-proxy
重定向通信的延迟要短，并且在同步代理规则时具有更好的性能。
与其他代理模式相比，IPVS 模式还支持更高的网络流量吞吐量。
IPVS 提供了更多选项来平衡后端 Pod 的流量。这些是：
* `rr`：轮替（Round-Robin）
* `lc`：最少链接（Least Connection），即打开链接数量最少者优先
* `dh`：目标地址哈希（Destination Hashing）
* `sh`：源地址哈希（Source Hashing）
* `sed`：最短预期延迟（Shortest Expected Delay）
* `nq`：从不排队（Never Queue）
{{< note >}}
<!--
To run kube-proxy in IPVS mode, you must make IPVS available on
the node before starting kube-proxy.
When kube-proxy starts in IPVS proxy mode, it verifies whether IPVS
kernel modules are available. If the IPVS kernel modules are not detected, then kube-proxy
falls back to running in iptables proxy mode.
-->
要在 IPVS 模式下运行 kube-proxy，必须在启动 kube-proxy 之前使 IPVS 在节点上可用。
当 kube-proxy 以 IPVS 代理模式启动时，它将验证 IPVS 内核模块是否可用。
如果未检测到 IPVS 内核模块，则 kube-proxy 将退回到以 iptables 代理模式运行。
{{< /note >}}
<!--
![Services overview diagram for IPVS proxy](/images/docs/services-ipvs-overview.svg)
In these proxy models, the traffic bound for the Service's IP:Port is
proxied to an appropriate backend without the clients knowing anything
about Kubernetes or Services or Pods.
If you want to make sure that connections from a particular client
are passed to the same Pod each time, you can select the session affinity based
on the client's IP addresses by setting `service.spec.sessionAffinity` to "ClientIP"
(the default is "None").
You can also set the maximum session sticky time by setting
`service.spec.sessionAffinityConfig.clientIP.timeoutSeconds` appropriately.
(the default value is 10800, which works out to be 3 hours).
-->
![IPVS 代理的 Services 概述图](/images/docs/services-ipvs-overview.svg)
在这些代理模型中，绑定到服务 IP 的流量：
在客户端不了解 Kubernetes 或服务或 Pod 的任何信息的情况下，将 Port 代理到适当的后端。
如果要确保每次都将来自特定客户端的连接传递到同一 Pod，
则可以通过将 `service.spec.sessionAffinity` 设置为 "ClientIP"
（默认值是 "None"），来基于客户端的 IP 地址选择会话亲和性。
你还可以通过适当设置 `service.spec.sessionAffinityConfig.clientIP.timeoutSeconds`
来设置最大会话停留时间。（默认值为 10800 秒，即 3 小时）。
{{< note >}}
<!--
On Windows, setting the maximum session sticky time for Services is not supported.
-->
在 Windows 上，不支持为服务设置最大会话停留时间。
{{< /note >}}
<!--
## Multi-Port Services
@ -847,79 +592,6 @@ server will return a 422 HTTP status code to indicate that there's a problem.
这对 API 服务器来说是通过一个标识来指定的。
如果 IP 地址不合法，API 服务器会返回 HTTP 状态码 422，表示值不合法。
<!--
## Traffic policies
-->
## 流量策略 {#traffic-policies}
<!--
### External traffic policy
-->
### 外部流量策略 {#external-traffic-policy}
<!--
You can set the `spec.externalTrafficPolicy` field to control how traffic from external sources is routed.
Valid values are `Cluster` and `Local`. Set the field to `Cluster` to route external traffic to all ready endpoints
and `Local` to only route to ready node-local endpoints. If the traffic policy is `Local` and there are no node-local
endpoints, the kube-proxy does not forward any traffic for the relevant Service.
-->
你可以通过设置 `spec.externalTrafficPolicy` 字段来控制来自于外部的流量是如何路由的。
可选值有 `Cluster` 和 `Local`。字段设为 `Cluster` 会将外部流量路由到所有就绪的端点，
设为 `Local` 会只路由到当前节点上就绪的端点。
如果流量策略设置为 `Local`，而且当前节点上没有就绪的端点，kube-proxy 不会转发请求相关服务的任何流量。
{{< note >}}
{{< feature-state for_k8s_version="v1.22" state="alpha" >}}
<!--
If you enable the `ProxyTerminatingEndpoints`
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
for the kube-proxy, the kube-proxy checks if the node
has local endpoints and whether or not all the local endpoints are marked as terminating.
-->
如果你启用了 kube-proxy 的 `ProxyTerminatingEndpoints`
[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)，
kube-proxy 会检查节点是否有本地的端点，以及是否所有的本地端点都被标记为终止中。
<!--
If there are local endpoints and **all** of those are terminating, then the kube-proxy ignores
any external traffic policy of `Local`. Instead, whilst the node-local endpoints remain as all
terminating, the kube-proxy forwards traffic for that Service to healthy endpoints elsewhere,
as if the external traffic policy were set to `Cluster`.
-->
如果本地有端点，而且所有端点处于终止中的状态，那么 kube-proxy 会忽略任何设为 `Local` 的外部流量策略。
在所有本地端点处于终止中的状态的同时，kube-proxy 将请求指定服务的流量转发到位于其它节点的状态健康的端点，
如同外部流量策略设为 `Cluster`。
<!--
This forwarding behavior for terminating endpoints exists to allow external load balancers to
gracefully drain connections that are backed by `NodePort` Services, even when the health check
node port starts to fail. Otherwise, traffic can be lost between the time a node is still in the node pool of a load
balancer and traffic is being dropped during the termination period of a pod.
-->
针对处于正被终止状态的端点这一转发行为使得外部负载均衡器可以优雅地排出由
`NodePort` 服务支持的连接，就算是健康检查节点端口开始失败也是如此。
否则，当节点还在负载均衡器的节点池内，在 Pod 终止过程中的流量会被丢掉，这些流量可能会丢失。
{{< /note >}}
<!--
### Internal traffic policy
-->
### 内部流量策略 {#internal-traffic-policy}
{{< feature-state for_k8s_version="v1.22" state="beta" >}}
<!--
You can set the `spec.internalTrafficPolicy` field to control how traffic from internal sources is routed.
Valid values are `Cluster` and `Local`. Set the field to `Cluster` to route internal traffic to all ready endpoints
and `Local` to only route to ready node-local endpoints. If the traffic policy is `Local` and there are no node-local
endpoints, traffic is dropped by kube-proxy.
-->
你可以设置 `spec.internalTrafficPolicy` 字段来控制内部来源的流量是如何转发的。可设置的值有 `Cluster` 和 `Local`。
将字段设置为 `Cluster` 会将内部流量路由到所有就绪端点，设置为 `Local` 只会路由到当前节点上就绪的端点。
如果流量策略是 `Local`，而且当前节点上没有就绪的端点，那么 kube-proxy 会丢弃流量。
<!--
## Discovering services
@ -1148,6 +820,18 @@ Kubernetes `ServiceTypes` 允许指定你所需要的 Service 类型。
你需要使用 kube-dns 1.7 及以上版本或者 CoreDNS 0.0.8 及以上版本才能使用 `ExternalName` 类型。
{{< /note >}}
<!--
The `type` field was designed as nested functionality - each level adds to the
previous. This is not strictly required on all cloud providers (for example: Google
Compute Engine does not need to allocate a node port to make `type: LoadBalancer` work,
but another cloud provider integration might do). Although strict nesting is not required,
but the Kubernetes API design for Service requires it anyway.
-->
`type` 字段被设计为嵌套功能 - 每个级别都添加到前一个级别。
这并不是所有云提供商都严格要求的（例如：Google Compute Engine
不需要分配节点端口来使 `type: LoadBalancer` 工作，但另一个云提供商集成可能会这样做）。
虽然不需要严格的嵌套，但是 Service 的 Kubernetes API 设计无论如何都需要它。
<!--
You can also use [Ingress](/docs/concepts/services-networking/ingress/) to expose your Service.
Ingress is not a Service type, but it acts as the entry point for your cluster.
@ -2173,239 +1857,17 @@ spec:
```
<!--
## Shortcomings
## Session stickiness
Using the userspace proxy for VIPs works at small to medium scale, but will
not scale to very large clusters with thousands of Services. The
[original design proposal for portals](https://github.com/kubernetes/kubernetes/issues/1107)
has more details on this.
Using the userspace proxy obscures the source IP address of a packet accessing
a Service.
This makes some kinds of network filtering (firewalling) impossible. The iptables
proxy mode does not
obscure in-cluster source IPs, but it does still impact clients coming through
a load balancer or node-port.
The `Type` field is designed as nested functionality - each level adds to the
previous. This is not strictly required on all cloud providers (e.g. Google Compute Engine does
not need to allocate a `NodePort` to make `LoadBalancer` work, but AWS does)
but the Kubernetes API design for Service requires it anyway.
If you want to make sure that connections from a particular client are passed to
the same Pod each time, you can configure session affinity based on the client's
IP address. Read [session affinity](/docs/reference/networking/virtual-ips/#session-affinity)
to learn more.
-->
## 不足之处 {#shortcomings}
## 粘性会话 {#session-stickiness}
为 VIP 使用用户空间代理，将只适合小型到中型规模的集群，不能够扩展到上千 Service 的大型集群。
查看[最初设计方案](https://github.com/kubernetes/kubernetes/issues/1107) 获取更多细节。
使用用户空间代理，隐藏了访问 Service 的数据包的源 IP 地址。
这使得一些类型的防火墙无法起作用。
iptables 代理不会隐藏 Kubernetes 集群内部的 IP 地址，
但却要求客户端请求必须通过一个负载均衡器或 Node 端口。
`Type` 字段支持嵌套功能 —— 每一层需要添加到上一层里面。
不会严格要求所有云提供商（例如，GCE 就没必要为了使一个 `LoadBalancer`
能工作而分配一个 `NodePort`，但是 AWS 需要 ），但针对服务的 Kubernetes API 设计是强制要求的。
<!--
## Virtual IP implementation {#the-gory-details-of-virtual-ips}
The previous information should be sufficient for many people who want to
use Services. However, there is a lot going on behind the scenes that may be
worth understanding.
-->
## 虚拟 IP 实施 {#the-gory-details-of-virtual-ips}
对很多想使用 Service 的人来说，前面的信息应该足够了。
然而，有很多内部原理性的内容，还是值去理解的。
<!--
### Avoiding collisions
One of the primary philosophies of Kubernetes is that you should not be
exposed to situations that could cause your actions to fail through no fault
of your own. For the design of the Service resource, this means not making
you choose your own port number if that choice might collide with
someone else's choice. That is an isolation failure.
In order to allow you to choose a port number for your Services, we must
ensure that no two Services can collide. Kubernetes does that by allocating each
Service its own IP address from within the `service-cluster-ip-range`
CIDR range that is configured for the API server.
To ensure each Service receives a unique IP, an internal allocator atomically
updates a global allocation map in {{< glossary_tooltip term_id="etcd" >}}
prior to creating each Service. The map object must exist in the registry for
Services to get IP address assignments, otherwise creations will
fail with a message indicating an IP address could not be allocated.
In the control plane, a background controller is responsible for creating that
map (needed to support migrating from older versions of Kubernetes that used
in-memory locking). Kubernetes also uses controllers to check for invalid
assignments (e.g. due to administrator intervention) and for cleaning up allocated
IP addresses that are no longer used by any Services.
-->
### 避免冲突 {#avoiding-collisions}
Kubernetes 最主要的哲学之一，是用户不应该暴露那些能够导致他们操作失败、但又不是他们的过错的场景。
对于 Service 资源的设计，这意味着如果用户的选择有可能与他人冲突，那就不要让用户自行选择端口号。
这是一个隔离性的失败。
为了使用户能够为他们的 Service 选择一个端口号，我们必须确保不能有 2 个 Service 发生冲突。
Kubernetes 通过在为 API 服务器配置的 `service-cluster-ip-range` CIDR
范围内为每个服务分配自己的 IP 地址来实现。
为了保证每个 Service 被分配到一个唯一的 IP，需要一个内部的分配器能够原子地更新
{{< glossary_tooltip term_id="etcd" >}} 中的一个全局分配映射表，
这个更新操作要先于创建每一个 Service。
为了使 Service 能够获取到 IP，这个映射表对象必须在注册中心存在，
否则创建 Service 将会失败，指示一个 IP 不能被分配。
在控制平面中，一个后台 Controller 的职责是创建映射表
（需要支持从使用了内存锁的 Kubernetes 的旧版本迁移过来）。
同时 Kubernetes 会通过控制器检查不合理的分配（如管理员干预导致的）
以及清理已被分配但不再被任何 Service 使用的 IP 地址。
<!--
#### IP address ranges for `type: ClusterIP` Services {#service-ip-static-sub-range}
{{< feature-state for_k8s_version="v1.25" state="beta" >}}
However, there is a problem with this `ClusterIP` allocation strategy, because a user
can also [choose their own address for the service](#choosing-your-own-ip-address).
This could result in a conflict if the internal allocator selects the same IP address
for another Service.
-->
#### `type: ClusterIP` 服务的 IP 地址范围 {#service-ip-static-sub-range}
{{< feature-state for_k8s_version="v1.25" state="beta" >}}
但是，这种 `ClusterIP` 分配策略存在一个问题，因为用户还可以[为服务选择自己的地址](#choosing-your-own-ip-address)。
如果内部分配器为另一个服务选择相同的 IP 地址，这可能会导致冲突。
<!--
The `ServiceIPStaticSubrange`
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled by default in v1.25
and later, using an allocation strategy that divides the `ClusterIP` range into two bands, based on
the size of the configured `service-cluster-ip-range` by using the following formula
`min(max(16, cidrSize / 16), 256)`, described as _never less than 16 or more than 256,
with a graduated step function between them_. Dynamic IP allocations will be preferentially
chosen from the upper band, reducing risks of conflicts with the IPs
assigned from the lower band.
This allows users to use the lower band of the `service-cluster-ip-range` for their
Services with static IPs assigned with a very low risk of running into conflicts.
-->
`ServiceIPStaticSubrange` [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)在
v1.25 及后续版本中默认启用，其分配策略根据配置的 `service-cluster-ip-range` 的大小，使用以下公式
`min(max(16, cidrSize / 16), 256)` 进行划分，该公式可描述为
“在不小于 16 且不大于 256 之间有一个步进量（Graduated Step）”，将
`ClusterIP` 范围分成两段。动态 IP 分配将优先从上半段地址中选择，
从而降低与下半段地址分配的 IP 冲突的风险。
这允许用户将 `service-cluster-ip-range` 的下半段地址用于他们的服务，
与所分配的静态 IP 的冲突风险非常低。
<!--
### Service IP addresses {#ips-and-vips}
Unlike Pod IP addresses, which actually route to a fixed destination,
Service IPs are not actually answered by a single host. Instead, kube-proxy
uses iptables (packet processing logic in Linux) to define _virtual_ IP addresses
which are transparently redirected as needed. When clients connect to the
VIP, their traffic is automatically transported to an appropriate endpoint.
The environment variables and DNS for Services are actually populated in
terms of the Service's virtual IP address (and port).
kube-proxy supports three proxy modes&mdash;userspace, iptables and IPVS&mdash;which
each operate slightly differently.
-->
### Service IP 地址 {#ips-and-vips}
不像 Pod 的 IP 地址，它实际路由到一个固定的目的地，Service 的 IP 实际上不能通过单个主机来进行应答。
相反，我们使用 `iptables`（Linux 中的数据包处理逻辑）来定义一个虚拟 IP 地址（VIP），
它可以根据需要透明地进行重定向。
当客户端连接到 VIP 时，它们的流量会自动地传输到一个合适的 Endpoint。
环境变量和 DNS，实际上会根据 Service 的 VIP 和端口来进行填充。
kube-proxy 支持三种代理模式: 用户空间、iptables 和 IPVS；它们各自的操作略有不同。
#### Userspace {#userspace}
<!--
As an example, consider the image processing application described above.
When the backend Service is created, the Kubernetes master assigns a virtual
IP address, for example 10.0.0.1. Assuming the Service port is 1234, the
Service is observed by all of the kube-proxy instances in the cluster.
When a proxy sees a new Service, it opens a new random port, establishes an
iptables redirect from the virtual IP address to this new port, and starts accepting
connections on it.
When a client connects to the Service's virtual IP address, the iptables
rule kicks in, and redirects the packets to the proxy's own port.
The "Service proxy" chooses a backend, and starts proxying traffic from the client to the backend.
This means that Service owners can choose any port they want without risk of
collision. Clients can connect to an IP and port, without being aware
of which Pods they are actually accessing.
-->
作为一个例子，考虑前面提到的图片处理应用程序。
当创建后端 Service 时，Kubernetes master 会给它指派一个虚拟 IP 地址，比如 10.0.0.1。
假设 Service 的端口是 1234，该 Service 会被集群中所有的 `kube-proxy` 实例观察到。
当代理看到一个新的 Service，它会打开一个新的端口，
建立一个从该 VIP 重定向到新端口的 iptables，并开始接收请求连接。
当一个客户端连接到一个 VIP，iptables 规则开始起作用，它会重定向该数据包到
"服务代理" 的端口。
"服务代理" 选择一个后端，并将客户端的流量代理到后端上。
这意味着 Service 的所有者能够选择任何他们想使用的端口，而不存在冲突的风险。
客户端可以连接到一个 IP 和端口，而不需要知道实际访问了哪些 Pod。
#### iptables
<!--
Again, consider the image processing application described above.
When the backend Service is created, the Kubernetes control plane assigns a virtual
IP address, for example 10.0.0.1. Assuming the Service port is 1234, the
Service is observed by all of the kube-proxy instances in the cluster.
When a proxy sees a new Service, it installs a series of iptables rules which
redirect from the virtual IP address to per-Service rules. The per-Service
rules link to per-Endpoint rules which redirect traffic (using destination NAT)
to the backends.
When a client connects to the Service's virtual IP address the iptables rule kicks in.
A backend is chosen (either based on session affinity or randomly) and packets are
redirected to the backend. Unlike the userspace proxy, packets are never
copied to userspace, the kube-proxy does not have to be running for the virtual
IP address to work, and Nodes see traffic arriving from the unaltered client IP
address.
This same basic flow executes when traffic comes in through a node-port or
through a load-balancer, though in those cases the client IP does get altered.
-->
再次考虑前面提到的图片处理应用程序。
当创建后端 Service 时，Kubernetes 控制面板会给它指派一个虚拟 IP 地址，比如 10.0.0.1。
假设 Service 的端口是 1234，该 Service 会被集群中所有的 `kube-proxy` 实例观察到。
当代理看到一个新的 Service， 它会配置一系列的 iptables 规则，从 VIP 重定向到每个 Service 规则。
该特定于服务的规则连接到特定于 Endpoint 的规则，而后者会重定向（目标地址转译）到后端。
当客户端连接到一个 VIP，iptables 规则开始起作用。一个后端会被选择（或者根据会话亲和性，或者随机），
数据包被重定向到这个后端。
不像用户空间代理，数据包从来不拷贝到用户空间，kube-proxy 不是必须为该 VIP 工作而运行，
并且客户端 IP 是不可更改的。
当流量打到 Node 的端口上，或通过负载均衡器，会执行相同的基本流程，
但是在那些案例中客户端 IP 是可以更改的。
#### IPVS
<!--
iptables operations slow down dramatically in large scale cluster e.g. 10,000 Services.
IPVS is designed for load balancing and based on in-kernel hash tables.
So you can achieve performance consistency in large number of Services from IPVS-based kube-proxy.
Meanwhile, IPVS-based kube-proxy has more sophisticated load balancing algorithms
(least conns, locality, weighted, persistence).
-->
在大规模集群（例如 10000 个服务）中，iptables 操作会显着降低速度。
IPVS 专为负载均衡而设计，并基于内核内哈希表。
因此，你可以通过基于 IPVS 的 kube-proxy 在大量服务中实现性能一致性。
同时，基于 IPVS 的 kube-proxy 具有更复杂的负载均衡算法（最小连接、局部性、加权、持久性）。
如果你想确保来自特定客户端的连接每次都传递到同一个 Pod，你可以配置根据客户端 IP 地址来执行的会话亲和性。
阅读[会话亲和性](/zh-cn/docs/reference/networking/virtual-ips/#session-affinity)了解更多。
<!--
## API Object
@ -2413,7 +1875,6 @@ IPVS 专为负载均衡而设计，并基于内核内哈希表。
Service is a top-level resource in the Kubernetes REST API. You can find more details
about the [Service API object](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#service-v1-core).
## Supported protocols {#protocol-support}
-->
## API 对象 {#api-object}
@ -2421,130 +1882,19 @@ Service 是 Kubernetes REST API 中的顶级资源。你可以找到有关
[Service 对象 API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#service-v1-core)
的更多详细信息。
## 受支持的协议 {#protocol-support}
### TCP
<!-- preserve existing hyperlinks -->
<a id="shortcomings" /><a id="#the-gory-details-of-virtual-ips" />
<!--
You can use TCP for any kind of Service, and it's the default network protocol.
## Virtual IP addressing mechanism
Read [Virtual IPs and Service Proxies](/docs/reference/networking/virtual-ips/) to learn about the
mechanism Kubernetes provides to expose a Service with a virtual IP address.
-->
你可以将 TCP 用于任何类型的服务，这是默认的网络协议。
## 虚拟 IP 寻址机制 {#virtual-ip-addressing-mechanism}
### UDP
<!--
You can use UDP for most Services. For type=LoadBalancer Services, UDP support
depends on the cloud provider offering this facility.
-->
你可以将 UDP 用于大多数服务。 对于 type=LoadBalancer 服务，对 UDP 的支持取决于提供此功能的云提供商。
<!--
### SCTP
When using a network plugin that supports SCTP traffic, you can use SCTP for
most Services. For type=LoadBalancer Services, SCTP support depends on the cloud
provider offering this facility. (Most do not).
-->
### SCTP
{{< feature-state for_k8s_version="v1.20" state="stable" >}}
一旦你使用了支持 SCTP 流量的网络插件，你就可以使用 SCTP 于更多的服务。
对于 type = LoadBalancer 的服务，SCTP 的支持取决于提供此设施的云供应商（大多数不支持）。
<!--
#### Warnings {#caveat-sctp-overview}
##### Support for multihomed SCTP associations {#caveat-sctp-multihomed}
-->
#### 警告 {#caveat-sctp-overview}
##### 支持多宿主 SCTP 关联 {#caveat-sctp-multihomed}
{{< warning >}}
<!--
The support of multihomed SCTP associations requires that the CNI plugin can support the
assignment of multiple interfaces and IP addresses to a Pod.
NAT for multihomed SCTP associations requires special logic in the corresponding kernel modules.
-->
支持多宿主 SCTP 关联要求 CNI 插件能够支持为一个 Pod 分配多个接口和 IP 地址。
用于多宿主 SCTP 关联的 NAT 在相应的内核模块中需要特殊的逻辑。
{{< /warning >}}
<!--
##### Windows {#caveat-sctp-windows-os}
-->
##### Windows {#caveat-sctp-windows-os}
{{< note >}}
<!--
SCTP is not supported on Windows based nodes.
-->
基于 Windows 的节点不支持 SCTP。
{{< /note >}}
<!--
##### Userspace kube-proxy {#caveat-sctp-kube-proxy-userspace}
-->
##### 用户空间 kube-proxy {#caveat-sctp-kube-proxy-userspace}
{{< warning >}}
<!--
The kube-proxy does not support the management of SCTP associations when it is in userspace mode.
-->
当 kube-proxy 处于用户空间模式时，它不支持 SCTP 关联的管理。
{{< /warning >}}
### HTTP
<!--
If your cloud provider supports it, you can use a Service in LoadBalancer mode
to set up external HTTP / HTTPS reverse proxying, forwarded to the Endpoints
of the Service.
-->
如果你的云提供商支持它，则可以在 LoadBalancer 模式下使用服务来设置外部
HTTP/HTTPS 反向代理，并将其转发到该服务的 Endpoints。
{{< note >}}
<!--
You can also use {{< glossary_tooltip term_id="ingress" >}} in place of Service
to expose HTTP/HTTPS Services.
-->
你还可以使用 {{< glossary_tooltip text="Ingress" term_id="ingress" >}} 代替
Service 来公开 HTTP/HTTPS 服务。
{{< /note >}}
<!--
### PROXY protocol
If your cloud provider supports it,
you can use a Service in LoadBalancer mode to configure a load balancer outside
of Kubernetes itself, that will forward connections prefixed with
[PROXY protocol](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt).
The load balancer will send an initial series of octets describing the
incoming connection, similar to this example
-->
### PROXY 协议 {#proxy-protocol}
如果你的云提供商支持它，
则可以在 LoadBalancer 模式下使用 Service 在 Kubernetes 本身之外配置负载均衡器，
该负载均衡器将转发前缀为
[PROXY 协议](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)
的连接。
负载均衡器将发送一系列初始字节，描述传入的连接，类似于此示例：
```
PROXY TCP4 192.0.2.202 10.0.42.7 12345 7\r\n
```
<!--
followed by the data from the client.
-->
上述是来自客户端的数据。
阅读[虚拟 IP 和 Service 代理](/zh-cn/docs/reference/networking/virtual-ips/)以了解
Kubernetes 提供的使用虚拟 IP 地址公开服务的机制。
## {{% heading "whatsnext" %}}
@ -2552,7 +1902,18 @@ followed by the data from the client.
* Follow the [Connecting Applications with Services](/docs/tutorials/services/connect-applications-service/) tutorial
* Read about [Ingress](/docs/concepts/services-networking/ingress/)
* Read about [EndpointSlices](/docs/concepts/services-networking/endpoint-slices/)
For more context:
* Read [Virtual IPs and Service Proxies](/docs/reference/networking/virtual-ips/)
* Read the [API reference](/docs/reference/kubernetes-api/service-resources/service-v1/) for the Service API
* Read the [API reference](/docs/reference/kubernetes-api/service-resources/endpoints-v1/) for the Endpoints API
* Read the [API reference](/docs/reference/kubernetes-api/service-resources/endpoint-slice-v1/) for the EndpointSlice API
-->
* 遵循[使用 Service 连接到应用](/zh-cn/docs/tutorials/services/connect-applications-service/)教程
* 阅读了解 [Ingress](/zh-cn/docs/concepts/services-networking/ingress/)
* 阅读了解[端点切片（Endpoint Slices）](/zh-cn/docs/concepts/services-networking/endpoint-slices/)
更多上下文：
* 阅读[虚拟 IP 和 Service 代理](/zh-cn/docs/reference/networking/virtual-ips/)
* 阅读 Service API 的 [API 参考](/zh-cn/docs/reference/kubernetes-api/service-resources/service-v1/)
* 阅读 EndpointSlice API 的 [API 参考](/zh-cn/docs/reference/kubernetes-api/service-resources/endpoint-slice-v1/)

16
content/zh-cn/docs/concepts/storage/persistent-volumes.md
View File

@ -544,11 +544,11 @@ the following types of volumes:
* azureDisk
* azureFile
* awsElasticBlockStore
* cinder (deprecated)
* cinder （已弃用）
* {{< glossary_tooltip text="csi" term_id="csi" >}}
* flexVolume (deprecated)
* flexVolume （已弃用）
* gcePersistentDisk
* glusterfs
* glusterfs （已弃用）
* rbd
* portworxVolume
@ -557,12 +557,12 @@ You can only expand a PVC if its storage class's `allowVolumeExpansion` field is
-->
只有当 PVC 的存储类中将 `allowVolumeExpansion` 设置为 true 时，你才可以扩充该 PVC 申领。
``` yaml
```yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: gluster-vol-default
provisioner: kubernetes.io/glusterfs
name: example-vol-default
provisioner: vendor-name.example/magicstorage
parameters:
resturl: "http://192.168.10.100:8080"
restuser: ""
@ -1145,14 +1145,14 @@ The following volume types support mount options:
* `cephfs`
* `cinder`（于 v1.18 **弃用**）
* `gcePersistentDisk`
* `glusterfs`
* `glusterfs`（于 v1.25 **弃用**）
* `iscsi`
* `nfs`
* `rbd`
* `vsphereVolume`
<!--
Mount options are not validated, If a mount option is invalid, the mount fails.
Mount options are not validated. If a mount option is invalid, the mount fails.
-->
Kubernetes 不对挂载选项执行合法性检查。如果挂载选项是非法的，挂载就会失败。

22
content/zh-cn/docs/concepts/workloads/controllers/job.md
View File

@ -364,7 +364,8 @@ Jobs with _fixed completion count_ - that is, jobs that have non null
- As part of the Pod hostname, following the pattern `$(job-name)-$(index)`.
When you use an Indexed Job in combination with a
{{< glossary_tooltip term_id="Service" >}}, Pods within the Job can use
the deterministic hostnames to address each other via DNS.
the deterministic hostnames to address each other via DNS. For more information about
how to configure this, see [Job with Pod-to-Pod Communication](/docs/tasks/job/job-with-pod-to-pod-communication/).
- From the containerized task, in the environment variable `JOB_COMPLETION_INDEX`.
The Job is considered complete when there is one successfully completed Pod
@ -382,6 +383,7 @@ Jobs with _fixed completion count_ - that is, jobs that have non null
- 作为 Pod 主机名的一部分，遵循模式 `$(job-name)-$(index)`。
当你同时使用带索引的 Job（Indexed Job）与 {{< glossary_tooltip term_id="Service" >}}，
Job 中的 Pod 可以通过 DNS 使用确切的主机名互相寻址。
有关如何配置的更多信息，请参阅[带 Pod 间通信的 Job](/zh-cn/docs/tasks/job/job-with-pod-to-pod-communication/)。
- 对于容器化的任务，在环境变量 `JOB_COMPLETION_INDEX` 中。
当每个索引都对应一个成功完成的 Pod 时，Job 被认为是已完成的。
@ -719,6 +721,7 @@ The pattern names are also links to examples and more detailed description.
| [Pod 数量可变的队列](/zh-cn/docs/tasks/job/fine-parallel-processing-work-queue/) | ✓ | ✓ | |
| [静态任务分派的带索引的 Job](/zh-cn/docs/tasks/job/indexed-parallel-processing-static) | ✓ | | ✓ |
| [Job 模板扩展](/zh-cn/docs/tasks/job/parallel-processing-expansion/) | | | ✓ |
| [带 Pod 间通信的 Job](/zh-cn/docs/tasks/job/job-with-pod-to-pod-communication/) | ✓ | 有时 | 有时 |
<!--
When you specify completions with `.spec.completions`, each Pod created by the Job controller
@ -745,6 +748,7 @@ Here, `W` is the number of work items.
| [Pod 个数可变的队列](/zh-cn/docs/tasks/job/fine-parallel-processing-work-queue/) | 1 | 任意值 |
| [静态任务分派的带索引的 Job](/zh-cn/docs/tasks/job/indexed-parallel-processing-static) | W | | 任意值 |
| [Job 模板扩展](/zh-cn/docs/tasks/job/parallel-processing-expansion/) | 1 | 应该为 1 |
| [带 Pod 间通信的 Job](/zh-cn/docs/tasks/job/job-with-pod-to-pod-communication/) | W | W |
<!--
## Advanced usage
@ -943,7 +947,7 @@ The [suspend](#suspending-a-job) field is the first step towards achieving those
custom queue controller to decide when a job should start; However, once a job is unsuspended,
a custom queue controller has no influence on where the pods of a job will actually land.
-->
[suspend](#suspend-a-job) 字段是实现这些语义的第一步。
[suspend](#suspending-a-job) 字段是实现这些语义的第一步。
suspend 允许自定义队列控制器，以决定工作何时开始；然而，一旦工作被取消暂停，
自定义队列控制器对 Job 中 Pod 的实际放置位置没有影响。
@ -1099,7 +1103,7 @@ Pod disruption conditions in the Pod failure policy (see also:
available in Kubernetes v1.25.
-->
只有你在集群中启用了
`JobPodFailurePolicy` [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)
`JobPodFailurePolicy` [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)，
你才能为某个 Job 配置 Pod 失效策略。
此外，建议启用 `PodDisruptionConditions` 特性门控以便在 Pod 失效策略中检测和处理 Pod 干扰状况
（参考：[Pod 干扰状况](/zh-cn/docs/concepts/workloads/pods/disruptions#pod-disruption-conditions)）。
@ -1193,6 +1197,7 @@ being counted towards the `.spec.backoffLimit` limit of retries.
Pod 失效策略的第二条规则，
指定对于状况为 `DisruptionTarget` 的失效 Pod 采取 `Ignore` 操作，
统计 `.spec.backoffLimit` 重试次数限制时不考虑 Pod 因干扰而发生的异常。
{{< note >}}
<!--
If the Job failed, either by the Pod failure policy or Pod backoff
@ -1256,10 +1261,10 @@ and the [controller manager](/docs/reference/command-line-tools-reference/kube-c
It is enabled by default.
-->
要使用该行为，你必须为 [API 服务器](/zh-cn/docs/reference/command-line-tools-reference/kube-apiserver/)
和[控制器管理器](/zh-cn/docs/reference/command-line-tools-reference/kube-controller-manager/)
启用 `JobTrackingWithFinalizers`
和[控制器管理器](/zh-cn/docs/reference/command-line-tools-reference/kube-controller-manager/)启用
`JobTrackingWithFinalizers`
[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)。
默认是启用的。
该特性默认是启用的。
<!--
When enabled, the control plane tracks new Jobs using the behavior described
@ -1410,5 +1415,6 @@ object, but maintains complete control over what Pods are created and how work i
* 基于一个模板运行多个 Job：[使用展开的方式进行并行处理](/zh-cn/docs/tasks/job/parallel-processing-expansion/)
* 跟随[自动清理完成的 Job](#clean-up-finished-jobs-automatically) 文中的链接，了解你的集群如何清理完成和失败的任务。
* `Job` 是 Kubernetes REST API 的一部分。阅读 {{< api-reference page="workload-resources/job-v1" >}}
对象定义理解关于该资源的 API。
* 阅读 [`CronJob`](/zh-cn/docs/concepts/workloads/controllers/cron-jobs/)，它允许你定义一系列定期运行的 Job，类似于 UNIX 工具 `cron`。
对象定义理解关于该资源的 API。
* 阅读 [`CronJob`](/zh-cn/docs/concepts/workloads/controllers/cron-jobs/)，
它允许你定义一系列定期运行的 Job，类似于 UNIX 工具 `cron`。

4
content/zh-cn/docs/reference/_index.md
View File

@ -104,7 +104,7 @@ client libraries:
* [Scheduler Policies](/docs/reference/scheduling/policies)
* [Scheduler Profiles](/docs/reference/scheduling/config#profiles)
* List of [ports and protocols](/docs/reference/ports-and-protocols/) that
* List of [ports and protocols](/docs/reference/networking/ports-and-protocols/) that
should be open on control plane and worker nodes
-->
## 组件 {#components}
@ -122,7 +122,7 @@ client libraries:
* [调度策略](/zh-cn/docs/reference/scheduling/policies)
* [调度配置](/zh-cn/docs/reference/scheduling/config#profiles)
* 应该在控制平面和工作节点上打开的[端口和协议](/zh-cn/docs/reference/ports-and-protocols/)列表
* 应该在控制平面和工作节点上打开的[端口和协议](/zh-cn/docs/reference/networking/ports-and-protocols/)列表
<!--
## Config APIs

13
content/zh-cn/docs/reference/glossary/dynamic-volume-provisioning.md
View File

@ -1,5 +1,5 @@
---
title: 动态卷供应（Dynamic Volume Provisioning）
title: 动态卷制备（Dynamic Volume Provisioning）
id: dynamicvolumeprovisioning
date: 2018-04-12
full_link: /zh-cn/docs/concepts/storage/dynamic-provisioning/
@ -26,7 +26,7 @@ tags:
-->
<!--
Allows users to request automatic creation of storage {{< glossary_tooltip text="Volumes" term_id="volume" >}}.
Allows users to request automatic creation of storage {{< glossary_tooltip text="Volumes" term_id="volume" >}}.
-->
允许用户请求自动创建存储{{< glossary_tooltip text="卷" term_id="volume" >}}。
@ -35,7 +35,8 @@ tags:
<!--
Dynamic provisioning eliminates the need for cluster administrators to pre-provision storage. Instead, it automatically provisions storage by user request. Dynamic volume provisioning is based on an API object, {{< glossary_tooltip text="StorageClass" term_id="storage-class" >}}, referring to a {{< glossary_tooltip text="Volume Plugin" term_id="volume-plugin" >}} that provisions a {{< glossary_tooltip text="Volume" term_id="volume" >}} and the set of parameters to pass to the Volume Plugin.
-->
动态供应让集群管理员无需再预先供应存储。相反，它通过用户请求自动地供应存储。
动态卷供应是基于 API 对象 {{< glossary_tooltip text="StorageClass" term_id="storage-class" >}} 的，
StorageClass 可以引用 {{< glossary_tooltip text="卷插件（Volume Plugin）" term_id="volume-plugin" >}} 提供的
{{< glossary_tooltip text="卷" term_id="volume" >}}，也可以引用传递给卷插件的参数集。
动态制备让集群管理员无需再预先制备存储。这种机制转为通过用户请求自动地制备存储。
动态卷制备是基于 API 对象 {{< glossary_tooltip text="StorageClass" term_id="storage-class" >}} 的，
StorageClass 可以引用{{< glossary_tooltip text="卷插件（Volume Plugin）" term_id="volume-plugin" >}}
提供的{{< glossary_tooltip text="卷" term_id="volume" >}}，
也可以引用传递给卷插件的参数集。

20
content/zh-cn/docs/reference/glossary/replication-controller.md
View File

@ -1,10 +1,10 @@
---
title: 副本控制器（Replication Controller）
title: 副本控制器（ReplicationController）
id: replication-controller
date: 2018-04-12
full_link:
short_description: >
一种管理多副本应用的（已启用）的 API 对象。
一种管理多副本应用的（已弃用）的 API 对象。
aka:
tags:
@ -13,7 +13,7 @@ tags:
---
<!--
title: Replication Controller
title: ReplicationController
id: replication-controller
date: 2018-04-12
full_link:
@ -27,27 +27,27 @@ tags:
-->
<!--
A workload resource that manages a replicated application, ensuring that
A workload resource that manages a replicated application, ensuring that
a specific number of instances of a {{< glossary_tooltip text="Pod" term_id="pod" >}} are running.
-->
一种工作管理多副本应用的负载资源，能够确保特定个数的
一种管理多副本应用的工作负载资源，能够确保特定个数的
{{< glossary_tooltip text="Pod" term_id="pod" >}}
实例处于运行状态。
<!--more-->
<!--more-->
<!--
The control plane ensures that the defined number of Pods are running, even if some
Pods fail, if you delete Pods manually, or if too many are started by mistake.
-->
控制面确保所指定的个数的 Pods 处于运行状态，即使某些 Pod 会失效，
比如被你手动删除或者因为其他错误启动过多 Pod 时。
控制平面确保即使某些 Pod 失效、被你手动删除或错误地启动了过多 Pod 时，
指定数量的 Pod 仍处于运行状态。
{{< note >}}
<!--
ReplicationController is deprecated. See
{{< glossary_tooltip text="Deployment" term_id="deployment" >}}, which is similar.
-->
ReplicationController 已被启用。请参见 Deployment 执行类似功能。
ReplicationController 已被弃用。请参见执行类似功能的
{{< glossary_tooltip text="Deployment" term_id="deployment" >}}。
{{< /note >}}

14
content/zh-cn/docs/reference/glossary/taint.md
View File

@ -4,7 +4,7 @@ id: taint
date: 2019-01-11
full_link: /zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration/
short_description: >
污点是一种一个核心对象，包含三个必需的属性：key、value 和 effect。
污点是一种核心对象，包含三个必需的属性：key、value 和 effect。
污点会阻止在节点或节点组上调度 Pod。
aka:
@ -17,7 +17,7 @@ tags:
title: Taint
id: taint
date: 2019-01-11
full_link: /docs/concepts/configuration/taint-and-toleration/
full_link: /docs/concepts/scheduling-eviction/taint-and-toleration/
short_description: >
A core object consisting of three required properties: key, value, and effect. Taints prevent the scheduling of pods on nodes or node groups.
@ -25,14 +25,14 @@ aka:
tags:
- core-object
- fundamental
-->
-->
<!--
A core object consisting of three required properties: key, value, and effect. Taints prevent the scheduling of {{< glossary_tooltip text="Pods" term_id="pod" >}} on {{< glossary_tooltip text="nodes" term_id="node" >}} or node groups.
A core object consisting of three required properties: key, value, and effect. Taints prevent the scheduling of {{< glossary_tooltip text="Pods" term_id="pod" >}} on {{< glossary_tooltip text="nodes" term_id="node" >}} or node groups.
-->
污点是一种一个核心对象，包含三个必需的属性：key、value 和 effect。
污点会阻止在{{< glossary_tooltip text="节点" term_id="node" >}}
或节点组上调度 {{< glossary_tooltip text="Pods" term_id="pod" >}}。
污点是一种核心对象，包含三个必需的属性：key、value 和 effect。
污点会阻止在{{< glossary_tooltip text="节点" term_id="node" >}}或节点组上调度
{{< glossary_tooltip text="Pod" term_id="pod" >}}。
<!--more-->

26
content/zh-cn/docs/reference/glossary/toleration.md
View File

@ -4,7 +4,7 @@ id: toleration
date: 2019-01-11
full_link: /zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration/
short_description: >
一个核心对象，由三个必需的属性组成：key、value 和 effect。
容忍度是一种核心对象，包含三个必需的属性：key、value 和 effect。
容忍度允许将 Pod 调度到具有对应污点的节点或节点组上。
aka:
@ -20,7 +20,7 @@ date: 2019-01-11
full_link: /docs/concepts/scheduling-eviction/taint-and-toleration/
short_description: >
A core object consisting of three required properties: key, value, and effect. Tolerations enable the scheduling of pods on nodes or node groups that have a matching taint.
aka:
tags:
- core-object
@ -28,22 +28,18 @@ tags:
-->
<!--
A core object consisting of three required properties: key, value, and effect. Tolerations enable the scheduling of pods on nodes or node groups that have matching {{< glossary_tooltip text="taints" term_id="taint" >}}.
A core object consisting of three required properties: key, value, and effect. Tolerations enable the scheduling of pods on nodes or node groups that have matching {{< glossary_tooltip text="taints" term_id="taint" >}}.
-->
一个核心对象，由三个必需的属性组成：key、value 和 effect。
容忍度允许将 Pod 调度到具有对应{{< glossary_tooltip text="污点" term_id="taint" >}}
的节点或节点组上。
容忍度是一种核心对象，包含三个必需的属性：key、value 和 effect。容忍度允许将 Pod
调度到具有对应{{< glossary_tooltip text="污点" term_id="taint" >}}的节点或节点组上。
<!--more-->
<!--
Tolerations and {{< glossary_tooltip text="taints" term_id="taint" >}} work together to ensure that pods are not scheduled onto inappropriate nodes. One or more tolerations are applied to a {{< glossary_tooltip text="pod" term_id="pod" >}}. A toleration indicates that the {{< glossary_tooltip text="pod" term_id="pod" >}} is allowed (but not required) to be scheduled on nodes or node groups with matching {{< glossary_tooltip text="taints" term_id="taint" >}}.
-->
容忍度和{{< glossary_tooltip text="污点" term_id="taint" >}}共同作用可以
确保不会将 Pod 调度在不适合的节点上。
在同一 {{< glossary_tooltip text="Pod" term_id="pod" >}} 上可以设置一个
或者多个容忍度。
容忍度表示在包含对应{{< glossary_tooltip text="污点" term_id="taint" >}}
的节点或节点组上调度 {{< glossary_tooltip text="Pod" term_id="pod" >}}
是允许的（但不必要）。
容忍度和{{< glossary_tooltip text="污点" term_id="taint" >}}共同作用可以确保不会将 Pod
调度在不适合的节点上。在同一 {{< glossary_tooltip text="Pod" term_id="pod" >}}
上可以设置一个或者多个容忍度。
容忍度表示在包含对应{{< glossary_tooltip text="污点" term_id="taint" >}}的节点或节点组上调度
{{< glossary_tooltip text="Pod" term_id="pod" >}}是允许的（但并非必需）。

16
content/zh-cn/docs/reference/kubectl/cheatsheet.md
View File

@ -42,7 +42,7 @@ This page contains a list of commonly used `kubectl` commands and flags.
<!--
```bash
source <(kubectl completion bash) # setup autocomplete in bash into the current shell, bash-completion package should be installed first.
source <(kubectl completion bash) # set up autocomplete in bash into the current shell, bash-completion package should be installed first.
echo "source <(kubectl completion bash)" >> ~/.bashrc # add autocomplete permanently to your bash shell.
```
@ -64,7 +64,7 @@ complete -o default -F __start_kubectl k
<!--
```bash
source <(kubectl completion zsh) # setup autocomplete in zsh into the current shell
source <(kubectl completion zsh) # set up autocomplete in zsh into the current shell
echo '[[ $commands[kubectl] ]] && source <(kubectl completion zsh)' >> ~/.zshrc # add autocomplete permanently to your zsh shell
```
-->
@ -74,9 +74,9 @@ echo '[[ $commands[kubectl] ]] && source <(kubectl completion zsh)' >> ~/.zshrc
```
<!--
### A Note on --all-namespaces
### A Note on `--all-namespaces`
-->
### 关于 --all-namespaces 的一点说明 {#a-note-on-all-namespaces}
### 关于 `--all-namespaces` 的一点说明 {#a-note-on-all-namespaces}
<!--
Appending `--all-namespaces` happens frequently enough where you should be aware of the shorthand for `--all-namespaces`:
@ -312,7 +312,7 @@ EOF
```
<!--
## Viewing, finding resources
## Viewing and finding resources
-->
## 查看和查找资源 {#viewing-finding-resources}
@ -514,6 +514,7 @@ kubectl expose rc nginx --port=80 --target-port=8000
kubectl get pod mypod -o yaml | sed 's/\(image: myimage\):.*$/\1:v4/' | kubectl replace -f -
kubectl label pods my-pod new-label=awesome # Add a Label
kubectl label pods my-pod new-label- # Remove a label
kubectl annotate pods my-pod icon-url=http://goo.gl/XXBTWq # Add an annotation
kubectl autoscale deployment foo --min=2 --max=10 # Auto scale a deployment "foo"
```
@ -538,6 +539,7 @@ kubectl expose rc nginx --port=80 --target-port=8000
kubectl get pod mypod -o yaml | sed 's/\(image: myimage\):.*$/\1:v4/' | kubectl replace -f -
kubectl label pods my-pod new-label=awesome # 添加标签
kubectl label pods my-pod new-label- # 移除标签
kubectl annotate pods my-pod icon-url=http://goo.gl/XXBTWq # 添加注解
kubectl autoscale deployment foo --min=2 --max=10 # 对 "foo" Deployment 自动伸缩容
```
@ -706,7 +708,7 @@ kubectl top pod POD_NAME --sort-by=cpu # 显示给定 Pod 的指标
```
<!--
## Copy files and directories to and from containers
## Copying files and directories to and from containers
-->
## 从容器中复制文件和目录 {#copy-files-and-directories-to-and-from-containers}
@ -727,7 +729,7 @@ kubectl cp my-namespace/my-pod:/tmp/foo /tmp/bar # 将 /tmp/foo 从远程
{{< note >}}
<!--
`kubectl cp` requires that the 'tar' binary is present in your container image. If 'tar' is not present,`kubectl cp` will fail.
`kubectl cp` requires that the 'tar' binary is present in your container image. If 'tar' is not present, `kubectl cp` will fail.
For advanced use cases, such as symlinks, wildcard expansion or file mode preservation consider using `kubectl exec`.
-->
`kubectl cp` 要求容器镜像中存在 “tar” 二进制文件。如果 “tar” 不存在，`kubectl cp` 将失败。

4
content/zh-cn/docs/reference/labels-annotations-taints/_index.md
View File

@ -1644,11 +1644,11 @@ kubeadm 为本地管理的 etcd Pod 设置的注解，用来跟踪 etcd 客户
### kubeadm.kubernetes.io/kube-apiserver.advertise-address.endpoint {#kube-apiserver-advertise-address-endpoint}
<!--
Example: `kubeadm.kubernetes.io/kube-apiserver.advertise-address.endpoint: https//172.17.0.18:6443`
Example: `kubeadm.kubernetes.io/kube-apiserver.advertise-address.endpoint: https://172.17.0.18:6443`
Used on: Pod
-->
例子：`kubeadm.kubernetes.io/kube-apiserver.advertise-address.endpoint: https//172.17.0.18:6443`
例子：`kubeadm.kubernetes.io/kube-apiserver.advertise-address.endpoint: https://172.17.0.18:6443`
用于：Pod

21
content/zh-cn/docs/reference/networking/_index.md Normal file
View File

@ -0,0 +1,21 @@
---
title: 网络参考
content_type: reference
weight: 85
---
<!--
title: Networking Reference
content_type: reference
weight: 85
-->
<!-- overview -->
<!--
This section of the Kubernetes documentation provides reference details
of Kubernetes networking.
-->
Kubernetes 文档的这一部分提供了 Kubernetes 网络的参考详细信息。
<!-- body -->

9
content/zh-cn/docs/reference/ports-and-protocols.md → content/zh-cn/docs/reference/networking/ports-and-protocols.md
View File

@ -3,12 +3,11 @@ title: 端口和协议
content_type: reference
weight: 50
---
<!--
---
title: Ports and Protocols
content_type: reference
weight: 50
---
-->
<!--
@ -17,7 +16,8 @@ as on-premises datacenter with physical network firewalls or Virtual
Networks in Public Cloud, it is useful to be aware of the ports and protocols
used by Kubernetes components
-->
当你在一个有严格网络边界的环境里运行 Kubernetes，例如拥有物理网络防火墙或者拥有公有云中虚拟网络的自有数据中心，了解 Kubernetes 组件使用了哪些端口和协议是非常有用的。
当你在一个有严格网络边界的环境里运行 Kubernetes，例如拥有物理网络防火墙或者拥有公有云中虚拟网络的自有数据中心，
了解 Kubernetes 组件使用了哪些端口和协议是非常有用的。
<!--
## Control plane
@ -74,4 +74,5 @@ on the default port.
所有默认端口都可以重新配置。当使用自定义的端口时，你需要打开这些端口来代替这里提到的默认端口。
一个常见的例子是 API 服务器的端口有时会配置为443。或者你也可以使用默认端口，把 API 服务器放到一个监听443 端口的负载均衡器后面，并且路由所有请求到 API 服务器的默认端口。
一个常见的例子是 API 服务器的端口有时会配置为 443。或者你也可以使用默认端口，
把 API 服务器放到一个监听 443 端口的负载均衡器后面，并且路由所有请求到 API 服务器的默认端口。

226
content/zh-cn/docs/reference/networking/service-protocols.md Normal file
View File

@ -0,0 +1,226 @@
---
title: Service 所用的协议
content_type: reference
weight: 10
---
<!--
title: Protocols for Services
content_type: reference
weight: 10
-->
<!-- overview -->
<!--
If you configure a {{< glossary_tooltip text="Service" term_id="service" >}},
you can select from any network protocol that Kubernetes supports.
Kubernetes supports the following protocols with Services:
- [`SCTP`](#protocol-sctp)
- [`TCP`](#protocol-tcp) _(the default)_
- [`UDP`](#protocol-udp)
-->
如果你配置 {{< glossary_tooltip text="Service" term_id="service" >}}，
你可以从 Kubernetes 支持的任何网络协议中选择一个协议。
Kubernetes 支持以下协议用于 Service：
- [`SCTP`](#protocol-sctp)
- [`TCP`](#protocol-tcp) **（默认值）**
- [`UDP`](#protocol-udp)
<!--
When you define a Service, you can also specify the
[application protocol](/docs/concepts/services-networking/service/#application-protocol)
that it uses.
This document details some special cases, all of them typically using TCP
as a transport protocol:
- [HTTP](#protocol-http-special) and [HTTPS](#protocol-http-special)
- [PROXY protocol](#protocol-proxy-special)
- [TLS](#protocol-tls-special) termination at the load balancer
-->
当你定义 Service 时，
你还可以指定其使用的[应用协议](/zh-cn/docs/concepts/services-networking/service/#application-protocol)。
本文详细说明了一些特殊场景，这些场景通常均使用 TCP 作为传输协议：
- [HTTP](#protocol-http-special) 和 [HTTPS](#protocol-http-special)
- [PROXY 协议](#protocol-proxy-special)
- [TLS](#protocol-tls-special) 终止于负载均衡器处
<!-- body -->
<!--
## Supported protocols {#protocol-support}
There are 3 valid values for the `protocol` of a port for a Service:
-->
## 支持的协议 {#protocol-support}
Service 端口的 `protocol` 有 3 个有效值：
### `SCTP` {#protocol-sctp}
{{< feature-state for_k8s_version="v1.20" state="stable" >}}
<!--
When using a network plugin that supports SCTP traffic, you can use SCTP for
most Services. For `type: LoadBalancer` Services, SCTP support depends on the cloud
provider offering this facility. (Most do not).
SCTP is not supported on nodes that run Windows.
-->
当使用支持 SCTP 流量的网络插件时，你可以为大多数 Service 使用 SCTP。
对于 `type: LoadBalancer` Service，对 SCTP 的支持情况取决于提供此项设施的云供应商（大部分不支持）。
运行 Windows 的节点不支持 SCTP。
<!--
#### Support for multihomed SCTP associations {#caveat-sctp-multihomed}
The support of multihomed SCTP associations requires that the CNI plugin can support the assignment of multiple interfaces and IP addresses to a Pod.
NAT for multihomed SCTP associations requires special logic in the corresponding kernel modules.
-->
#### 支持多宿主 SCTP 关联 {#caveat-sctp-multihomed}
对多宿主 SCTP 关联的支持要求 CNI 插件可以支持为 Pod 分配多个接口和 IP 地址。
针对多宿主 SCTP 关联的 NAT 需要在对应的内核模块具有特殊的逻辑。
{{< note >}}
<!--
The kube-proxy does not support the management of SCTP associations when it is in userspace mode.
-->
当 kube-proxy 处于 userspace 模式时不支持管理 SCTP 关联。
{{< /note >}}
### `TCP` {#protocol-tcp}
<!--
You can use TCP for any kind of Service, and it's the default network protocol.
-->
你可以将 TCP 用于任何类别的 Service，这是默认的网络协议。
### `UDP` {#protocol-udp}
<!--
You can use UDP for most Services. For `type: LoadBalancer` Services,
UDP support depends on the cloud provider offering this facility.
-->
你可以将 UDP 用于大多数 Service。对于 `type: LoadBalancer` Service，
UDP 的支持与否取决于提供此项设施的云供应商。
<!--
## Special cases
-->
## 特殊场景 {#special-cases}
### HTTP {#protocol-http-special}
<!--
If your cloud provider supports it, you can use a Service in LoadBalancer mode to
configure a load balancer outside of your Kubernetes cluster, in a special mode
where your cloud provider's load balancer implements HTTP / HTTPS reverse proxying,
with traffic forwarded to the backend endpoints for that Service.
-->
如果你的云供应商支持负载均衡，而且尤其是该云供应商的负载均衡器实现了 HTTP/HTTPS 反向代理，
可将流量转发到该 Service 的后端端点，那么你就可以使用 LoadBalancer 模式的 Service 以便在
Kubernetes 集群外部配置负载均衡器。
<!--
Typically, you set the protocol for the Service to `TCP` and add an
{{< glossary_tooltip text="annotation" term_id="annotation" >}}
(usually specific to your cloud provider) that configures the load balancer
to handle traffic at the HTTP level.
This configuration might also include serving HTTPS (HTTP over TLS) and
reverse-proxying plain HTTP to your workload.
-->
通常，你将 Service 协议设置为 `TCP`，
并添加一个{{< glossary_tooltip text="注解" term_id="annotation" >}}
（一般取决于你的云供应商）配置负载均衡器，以便在 HTTP 级别处理流量。
此配置也可能包括为你的工作负载提供 HTTPS（基于 TLS 的 HTTP）并反向代理纯 HTTP。
{{< note >}}
<!--
You can also use an {{< glossary_tooltip term_id="ingress" >}} to expose
HTTP/HTTPS Services.
-->
你也可以使用 {{< glossary_tooltip term_id="ingress" >}} 来暴露 HTTP/HTTPS Service。
{{< /note >}}
<!--
You might additionally want to specify that the
[application protocol](/docs/concepts/services-networking/service/#application-protocol)
of the connection is `http` or `https`. Use `http` if the session from the
load balancer to your workload is HTTP without TLS, and use `https` if the
session from the load balancer to your workload uses TLS encryption.
-->
你可能还想指定连接的[应用协议](/zh-cn/docs/concepts/services-networking/service/#application-protocol)是
`http` 还是 `https`。如果从负载均衡器到工作负载的会话是不带 TLS 的 HTTP，请使用 `http`；
如果从负载均衡器到工作负载的会话使用 TLS 加密，请使用 `https`。
<!--
### PROXY protocol {#protocol-proxy-special}
If your cloud provider supports it, you can use a Service set to `type: LoadBalancer`
to configure a load balancer outside of Kubernetes itself, that will forward connections
wrapped with the
[PROXY protocol](https://www.haproxy.org/download/2.5/doc/proxy-protocol.txt).
The load balancer then sends an initial series of octets describing the
incoming connection, similar to this example (PROXY protocol v1):
-->
### PROXY 协议 {#protocol-proxy-special}
如果你的云供应商支持此协议，你可以使用设置为 `type: LoadBalancer` 的 Service，
在 Kubernetes 本身的外部配置负载均衡器，以转发用
[PROXY 协议](https://www.haproxy.org/download/2.5/doc/proxy-protocol.txt)封装的连接。
负载均衡器然后发送一个初始的八位元组系列来描述传入的连接，这类似于以下示例（PROXY 协议 v1）：
```
PROXY TCP4 192.0.2.202 10.0.42.7 12345 7\r\n
```
<!--
The data after the proxy protocol preamble are the original
data from the client. When either side closes the connection,
the load balancer also triggers a connection close and sends
any remaining data where feasible.
Typically, you define a Service with the protocol to `TCP`.
You also set an annotation, specific to your
cloud provider, that configures the load balancer to wrap each incoming connection in the PROXY protocol.
-->
代理协议前导码之后的数据是来自客户端的原始数据。
当任何一侧关闭连接时，负载均衡器也会触发连接关闭并在可行的情况下发送所有残留数据。
通常，你会将 Service 协议定义为 `TCP`。
你还会设置一个特定于云供应商的注解，将负载均衡器配置为以 PROXY 协议封装所有传入的连接。
### TLS {#protocol-tls-special}
<!--
If your cloud provider supports it, you can use a Service set to `type: LoadBalancer` as
a way to set up external reverse proxying, where the connection from client to load
balancer is TLS encrypted and the load balancer is the TLS server peer.
The connection from the load balancer to your workload can also be TLS,
or might be plain text. The exact options available to you depend on your
cloud provider or custom Service implementation.
Typically, you set the protocol to `TCP` and set an annotation
(usually specific to your cloud provider) that configures the load balancer
to act as a TLS server. You would configure the TLS identity (as server,
and possibly also as a client that connects to your workload) using
mechanisms that are specific to your cloud provider.
-->
如果你的云供应商支持 TLS，你可以使用设置为 `type: LoadBalancer` 的 Service
作为设置外部反向代理的一种方式，其中从客户端到负载均衡器的连接是 TLS 加密的且该负载均衡器是
TLS 对等服务器。从负载均衡器到工作负载的连接可以是 TLS，或可能是纯文本。
你可以使用的确切选项取决于你的云供应商或自定义 Service 实现。
通常，你会将协议设置为 `TCP` 并设置一个注解（通常特定于你的云供应商），
将负载均衡器配置为充当一个 TLS 服务器。你将使用特定于云供应商的机制来配置 TLS 身份
（作为服务器，也可能作为连接到工作负载的客户端）。

26
content/zh-cn/docs/reference/node/_index.md
View File

@ -1,9 +1,31 @@
---
title: 节点参考信息
weight: 40
weight: 80
no_list: true
---
<!--
title: Node Reference Information
weight: 40
weight: 80
no_list: true
-->
<!--
This section contains the following reference topics about nodes:
* the kubelet's [checkpoint API](/docs/reference/node/kubelet-checkpoint-api/)
* a list of [Articles on dockershim Removal and on Using CRI-compatible Runtimes](/docs/reference/node/topics-on-dockershim-and-cri-compatible-runtimes/)
You can also read node reference details from elsewhere in the
Kubernetes documentation, including:
* [Node Metrics Data](/docs/reference/instrumentation/node-metrics).
-->
本部分包含以下有关节点的参考主题：
* Kubelet 的 [Checkpoint API](/zh-cn/docs/reference/node/kubelet-checkpoint-api/)
* 一系列[关于 dockershim 移除和使用兼容 CRI 运行时的文章](/zh-cn/docs/reference/node/topics-on-dockershim-and-cri-compatible-runtimes/)
你还可以从 Kubernetes 文档的其他地方阅读节点的详细参考信息，包括：
* [节点指标数据](/zh-cn/docs/reference/instrumentation/node-metrics)。

14
content/zh-cn/docs/reference/setup-tools/kubeadm/kubeadm-init.md
View File

@ -522,16 +522,24 @@ The following phase command can be used to re-upload the certificates after expi
以下阶段命令可用于证书到期后重新上传证书：
```shell
kubeadm init phase upload-certs --upload-certs --certificate-key=SOME_VALUE --config=SOME_YAML_FILE
kubeadm init phase upload-certs --upload-certs --config=SOME_YAML_FILE
```
{{< note >}}
<!--
A predefined `certificateKey` can be provided in `InitConfiguration` when passing the [configuration file](https://kubernetes.io/docs/reference/config-api/kubeadm-config.v1beta3/) with `--config`.
-->
在使用 `--config`
传递[配置文件](https://kubernetes.io/zh-cn/docs/reference/config-api/kubeadm-config.v1beta3/)时，
可以在 `InitConfiguration` 中提供预定义的 `certificateKey`。
{{< /note >}}
<!--
If the flag `--certificate-key` is not passed to `kubeadm init` and
If a predefined certificate key is not passed to `kubeadm init` and
`kubeadm init phase upload-certs` a new key will be generated automatically.
The following command can be used to generate a new key on demand:
-->
如果未将参数 `--certificate-key` 传递给 `kubeadm init` 和 `kubeadm init phase upload-certs`，
如果未将预定义的证书密钥传递给 `kubeadm init` 和 `kubeadm init phase upload-certs`，
则会自动生成一个新密钥。
以下命令可用于按需生成新密钥：

4
content/zh-cn/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
View File

@ -85,12 +85,12 @@ route, we recommend you add IP route(s) so Kubernetes cluster addresses go via t
<!--
## Check required ports
These
[required ports](/docs/reference/ports-and-protocols/)
[required ports](/docs/reference/networking/ports-and-protocols/)
need to be open in order for Kubernetes components to communicate with each other. You can use tools like netcat to check if a port is open. For example:
-->
## 检查所需端口{#check-required-ports}
启用这些[必要的端口](/zh-cn/docs/reference/ports-and-protocols/)后才能使 Kubernetes 的各组件相互通信。
启用这些[必要的端口](/zh-cn/docs/reference/networking/ports-and-protocols/)后才能使 Kubernetes 的各组件相互通信。
可以使用 netcat 之类的工具来检查端口是否启用，例如：
```shell

8
content/zh-cn/docs/tasks/administer-cluster/certificates.md
View File

@ -4,20 +4,20 @@ content_type: task
weight: 20
---
<!--
---
title: Generate Certificates Manually
content_type: task
weight: 20
---
-->
<!-- overview -->
<!--
When using client certificate authentication, you can generate certificates
manually through `easyrsa`, `openssl` or `cfssl`.
manually through [`easyrsa`](https://github.com/OpenVPN/easy-rsa), [`openssl`](https://github.com/openssl/openssl) or [`cfssl`](https://github.com/cloudflare/cfssl).
-->
在使用客户端证书认证的场景下，你可以通过 `easyrsa`、`openssl` 或 `cfssl` 等工具以手工方式生成证书。
在使用客户端证书认证的场景下，你可以通过 [`easyrsa`](https://github.com/OpenVPN/easy-rsa)、
[`openssl`](https://github.com/openssl/openssl) 或 [`cfssl`](https://github.com/cloudflare/cfssl)
等工具以手工方式生成证书。
<!-- body -->

2
content/zh-cn/docs/tasks/administer-cluster/memory-manager.md
View File

@ -188,7 +188,7 @@ NUMA 节点的分组，从而扩展内存容量。解决这个问题的详细描
## 内存管理器配置 {#memory-manager-configuration}
<!--
Other Managers should be first pre-configured. Next, the Memory Manger feature should be enabled
Other Managers should be first pre-configured. Next, the Memory Manager feature should be enabled
and be run with `Static` policy (section [Static policy](#policy-static)).
Optionally, some amount of memory can be reserved for system or kubelet processes to increase
node stability (section [Reserved memory flag](#reserved-memory-flag)).

188
content/zh-cn/docs/tasks/job/job-with-pod-to-pod-communication.md Normal file
View File

@ -0,0 +1,188 @@
---
title: 带 Pod 间通信的 Job
content_type: task
min-kubernetes-server-version: v1.21
weight: 30
---
<!--
title: Job with Pod-to-Pod Communication
content_type: task
min-kubernetes-server-version: v1.21
weight: 30
-->
<!-- overview -->
<!--
In this example, you will run a Job in [Indexed completion mode](/blog/2021/04/19/introducing-indexed-jobs/) configured such that
the pods created by the Job can communicate with each other using pod hostnames rather than pod IP addresses.
Pods within a Job might need to communicate among themselves. The user workload running in each pod could query the Kubernetes API server
to learn the IPs of the other Pods, but it's much simpler to rely on Kubernetes' built-in DNS resolution.
-->
在此例中，你将以[索引完成模式](/blog/2021/04/19/introducing-indexed-jobs/)运行一个 Job，
并通过配置使得该 Job 所创建的各 Pod 之间可以使用 Pod 主机名而不是 Pod IP 地址进行通信。
某 Job 内的 Pod 之间可能需要通信。每个 Pod 中运行的用户工作负载可以查询 Kubernetes API
服务器以获知其他 Pod 的 IP，但使用 Kubernetes 内置的 DNS 解析会更加简单。
<!--
Jobs in Indexed completion mode automatically set the pods' hostname to be in the format of
`${jobName}-${completionIndex}`. You can use this format to deterministically build
pod hostnames and enable pod communication *without* needing to create a client connection to
the Kubernetes control plane to obtain pod hostnames/IPs via API requests.
This configuration is useful
for use cases where pod networking is required but you don't want to depend on a network
connection with the Kubernetes API server.
-->
索引完成模式下的 Job 自动将 Pod 的主机名设置为 `${jobName}-${completionIndex}` 的格式。
你可以使用此格式确定性地构建 Pod 主机名并启用 Pod 通信，无需创建到 Kubernetes
控制平面的客户端连接来通过 API 请求获取 Pod 主机名/IP。
此配置可用于需要 Pod 联网但不想依赖 Kubernetes API 服务器网络连接的使用场景。
## {{% heading "prerequisites" %}}
<!--
You should already be familiar with the basic use of [Job](/docs/concepts/workloads/controllers/job/).
-->
你应该已熟悉了 [Job](/zh-cn/docs/concepts/workloads/controllers/job/) 的基本用法。
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{<note>}}
<!--
If you are using MiniKube or a similar tool, you may need to take
[extra steps](https://minikube.sigs.k8s.io/docs/handbook/addons/ingress-dns/)
to ensure you have DNS.
-->
如果你正在使用 MiniKube 或类似的工具，
你可能需要采取[额外的步骤](https://minikube.sigs.k8s.io/docs/handbook/addons/ingress-dns/)来确保你拥有 DNS。
{{</note>}}
<!-- steps -->
<!--
## Starting a Job with Pod-to-Pod Communication
To enable pod-to-pod communication using pod hostnames in a Job, you must do the following:
-->
## 启动带 Pod 间通信的 Job {#starting-a-job-with-pod-to-pod-communication}
要在某 Job 中启用使用 Pod 主机名的 Pod 间通信，你必须执行以下操作：
<!--
1. Set up a [headless service](/docs/concepts/services-networking/service/#headless-services)
with a valid label selector for the pods created by your Job. The headless service must be in the same namespace as
the Job. One easy way to do this is to use the `job-name: <your-job-name>` selector, since the `job-name` label will be automatically added by Kubernetes. This configuration will trigger the DNS system to create records of the hostnames of
the pods running your Job.
2. Configure the headless service as subdomain service for the Job pods by including the following value in your Job template spec:
-->
1. 对于 Job 所创建的那些 Pod，
使用一个有效的标签选择算符创建[无头服务](/zh-cn/docs/concepts/services-networking/service/#headless-services)。
该无头服务必须位于与该 Job 相同的名字空间内。
实现这一目的的一种简单的方式是使用 `job-name: <任务名称>` 作为选择算符，
因为 `job-name` 标签将由 Kubernetes 自动添加。
此配置将触发 DNS 系统为运行 Job 的 Pod 创建其主机名的记录。
2. 通过将以下值包括到你的 Job 模板规约中，针对该 Job 的 Pod，将无头服务配置为其子域服务：
```yaml
subdomain: <无头服务的名称>
```
<!--
### Example
Below is a working example of a Job with pod-to-pod communication via pod hostnames enabled.
The Job is completed only after all pods successfully ping each other using hostnames.
-->
### 示例 {#example}
以下是启用通过 Pod 主机名来完成 Pod 间通信的 Job 示例。
只有在使用主机名成功 ping 通所有 Pod 之后，此 Job 才会结束。
{{<note>}}
<!--
In the Bash script executed on each pod in the example below, the pod hostnames can be prefixed
by the namespace as well if the pod needs to be reached from outside the namespace.
-->
在以下示例中的每个 Pod 中执行的 Bash 脚本中，如果需要从名字空间外到达 Pod，
Pod 主机名也可以带有该名字空间作为前缀。
{{</note>}}
```yaml
apiVersion: v1
kind: Service
metadata:
name: headless-svc
spec:
clusterIP: None # clusterIP 必须为 None 以创建无头服务
selector:
job-name: example-job # 必须与 Job 名称匹配
---
apiVersion: batch/v1
kind: Job
metadata:
name: example-job
spec:
completions: 3
parallelism: 3
completionMode: Indexed
template:
spec:
subdomain: headless-svc # 必须与 Service 名称匹配
restartPolicy: Never
containers:
- name: example-workload
image: bash:latest
command:
- bash
- -c
- |
for i in 0 1 2
do
gotStatus="-1"
wantStatus="0"
while [ $gotStatus -ne $wantStatus ]
do
ping -c 1 example-job-${i}.headless-svc > /dev/null 2>&1
gotStatus=$?
if [ $gotStatus -ne $wantStatus ]; then
echo "Failed to ping pod example-job-${i}.headless-svc, retrying in 1 second..."
sleep 1
fi
done
echo "Successfully pinged pod: example-job-${i}.headless-svc"
done
```
<!--
After applying the example above, reach each other over the network
using: `<pod-hostname>.<headless-service-name>`. You should see output similar to the following:
-->
应用上述示例之后，使用 `<Pod 主机名>.<无头服务名>` 通过网络到达彼此。
你应看到类似以下的输出：
```shell
kubectl logs example-job-0-qws42
```
```
Failed to ping pod example-job-0.headless-svc, retrying in 1 second...
Successfully pinged pod: example-job-0.headless-svc
Successfully pinged pod: example-job-1.headless-svc
Successfully pinged pod: example-job-2.headless-svc
```
{{<note>}}
<!--
Keep in mind that the `<pod-hostname>.<headless-service-name>` name format used
in this example would not work with DNS policy set to `None` or `Default`.
You can learn more about pod DNS policies [here](/docs/concepts/services-networking/dns-pod-service/#pod-s-dns-policy).
-->
谨记此例中使用的 `<Pod 主机名>.<无头服务名称>` 名称格式不适用于设置为 `None` 或 `Default` 的 DNS 策略。
你可以在[此处](/zh-cn/docs/concepts/services-networking/dns-pod-service/#pod-s-dns-policy)了解有关
Pod DNS 策略的更多信息。
{{</note>}}

41
content/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale.md
View File

@ -88,7 +88,33 @@ horizontal pod autoscaling.
-->
## HorizontalPodAutoscaler 是如何工作的？ {#how-does-a-horizontalpodautoscaler-work}
{{< figure src="/images/docs/horizontal-pod-autoscaler.svg" caption="HorizontalPodAutoscaler 控制 Deployment 及其 ReplicaSet 的规模" class="diagram-medium">}}
{{< mermaid >}}
graph BT
hpa[Pod 水平自动扩缩] --> scale[规模]
subgraph rc[RC / Deployment]
scale
end
scale -.-> pod1[Pod 1]
scale -.-> pod2[Pod 2]
scale -.-> pod3[Pod N]
classDef hpa fill:#D5A6BD,stroke:#1E1E1D,stroke-width:1px,color:#1E1E1D;
classDef rc fill:#F9CB9C,stroke:#1E1E1D,stroke-width:1px,color:#1E1E1D;
classDef scale fill:#B6D7A8,stroke:#1E1E1D,stroke-width:1px,color:#1E1E1D;
classDef pod fill:#9FC5E8,stroke:#1E1E1D,stroke-width:1px,color:#1E1E1D;
class hpa hpa;
class rc rc;
class scale scale;
class pod1,pod2,pod3 pod
{{< /mermaid >}}
<!--
Figure 1. HorizontalPodAutoscaler controls the scale of a Deployment and its ReplicaSet
-->
图 1. HorizontalPodAutoscaler 控制 Deployment 及其 ReplicaSet 的规模
<!--
Kubernetes implements horizontal pod autoscaling as a control loop that runs intermittently
@ -123,8 +149,8 @@ or the custom metrics API (for all other metrics).
the number of desired replicas.
-->
* 对于按 Pod 统计的资源指标（如 CPU），控制器从资源指标 API 中获取每一个
HorizontalPodAutoscaler 指定的 Pod 的度量值，如果设置了目标使用率，
控制器获取每个 Pod 中的容器[资源使用](/zh-cn/docs/concepts/configuration/manage-resources-containers/#requests-and-limits) 情况，
HorizontalPodAutoscaler 指定的 Pod 的度量值，如果设置了目标使用率，控制器获取每个 Pod
中的容器[资源使用](/zh-cn/docs/concepts/configuration/manage-resources-containers/#requests-and-limits)情况，
并计算资源使用率。如果设置了 target 值，将直接使用原始数据（不再计算百分比）。
接下来，控制器根据平均的资源使用率或原始值计算出扩缩的比例，进而计算出目标副本数。
@ -178,7 +204,7 @@ number of replicas and examine each of their current states.
For general information about subresources in the Kubernetes API, see
[Kubernetes API Concepts](/docs/reference/using-api/api-concepts/).
-->
对 [Metrics API 的支持](#support-for-metrics-apis)解释了这些不同 API 的稳定性保证和支持状态
对 [Metrics API 的支持](#support-for-metrics-apis)解释了这些不同 API 的稳定性保证和支持状态。
HorizontalPodAutoscaler 控制器访问支持扩缩的相应工作负载资源（例如：Deployment 和 StatefulSet）。
这些资源每个都有一个名为 `scale` 的子资源，该接口允许你动态设置副本的数量并检查它们的每个当前状态。
@ -231,7 +257,7 @@ are [`Ready`](/docs/concepts/workloads/pods/pod-lifecycle/#pod-conditions).
那么将会把指定 Pod 度量值的平均值做为 `currentMetricValue`。
在检查容差并决定最终值之前，控制平面还会考虑是否缺少任何指标，
以及有多少 Pod [`已就绪`](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#pod-conditions)。
以及有多少 Pod [`Ready`](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#pod-conditions)。
<!--
All Pods with a deletion timestamp set (objects with a deletion timestamp are
@ -613,8 +639,8 @@ APIs, cluster administrators must ensure that:
它可以作为集群插件启动。
* 对于自定义指标，将使用 `custom.metrics.k8s.io` API。
它由其他度量指标方案厂商的“适配器（Adapter）” API 服务器提供。
检查你的指标管道以查看是否有可用的 Kubernetes 指标适配器。
它由其他度量指标方案厂商的“适配器（Adapter）” API 服务器提供。
检查你的指标管道以查看是否有可用的 Kubernetes 指标适配器。
* 对于外部指标，将使用 `external.metrics.k8s.io` API。可能由上面的自定义指标适配器提供。
@ -676,6 +702,7 @@ change is the policy which is selected by default. The following example shows t
while scaling down:
-->
### 扩缩策略 {#scaling-policies}
可以在规约的 `behavior` 部分中指定一个或多个扩缩策略。当指定多个策略时，
允许最大更改量的策略是默认选择的策略。以下示例显示了缩小时的这种行为：