diff --git a/Makefile b/Makefile index f964ad79f2d..b36f211313c 100644 --- a/Makefile +++ b/Makefile @@ -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" diff --git a/cloudbuild.yaml b/cloudbuild.yaml index 542d58016c7..12506bf949b 100644 --- a/cloudbuild.yaml +++ b/cloudbuild.yaml @@ -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 diff --git a/content/en/docs/concepts/cluster-administration/flow-control.md b/content/en/docs/concepts/cluster-administration/flow-control.md index b4bd4894726..86fdcf9fb27 100644 --- a/content/en/docs/concepts/cluster-administration/flow-control.md +++ b/content/en/docs/concepts/cluster-administration/flow-control.md @@ -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 diff --git a/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md b/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md index c633223f52f..6645984559b 100644 --- a/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md +++ b/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md @@ -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 diff --git a/content/en/docs/concepts/scheduling-eviction/kube-scheduler.md b/content/en/docs/concepts/scheduling-eviction/kube-scheduler.md index c27013f6b7a..6c78f52b8c8 100644 --- a/content/en/docs/concepts/scheduling-eviction/kube-scheduler.md +++ b/content/en/docs/concepts/scheduling-eviction/kube-scheduler.md @@ -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 diff --git a/content/en/docs/concepts/services-networking/dns-pod-service.md b/content/en/docs/concepts/services-networking/dns-pod-service.md index 30672a32fac..adb62683049 100644 --- a/content/en/docs/concepts/services-networking/dns-pod-service.md +++ b/content/en/docs/concepts/services-networking/dns-pod-service.md @@ -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. -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 {{}} 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. diff --git a/content/en/docs/concepts/services-networking/ingress.md b/content/en/docs/concepts/services-networking/ingress.md index 0c9e5c1df36..a311d40f8b3 100644 --- a/content/en/docs/concepts/services-networking/ingress.md +++ b/content/en/docs/concepts/services-networking/ingress.md @@ -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 diff --git a/content/en/docs/concepts/services-networking/service.md b/content/en/docs/concepts/services-networking/service.md index 9bd08bc8ac6..c98d344b8de 100644 --- a/content/en/docs/concepts/services-networking/service.md +++ b/content/en/docs/concepts/services-networking/service.md @@ -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 diff --git a/content/en/docs/concepts/storage/volume-snapshots.md b/content/en/docs/concepts/storage/volume-snapshots.md index 9432bca66c0..ef7bb83f9ef 100644 --- a/content/en/docs/concepts/storage/volume-snapshots.md +++ b/content/en/docs/concepts/storage/volume-snapshots.md @@ -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: diff --git a/content/en/docs/reference/labels-annotations-taints/_index.md b/content/en/docs/reference/labels-annotations-taints/_index.md index 5256c6ca206..75974454588 100644 --- a/content/en/docs/reference/labels-annotations-taints/_index.md +++ b/content/en/docs/reference/labels-annotations-taints/_index.md @@ -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 diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md index 39f7d0cce92..4d102d1a153 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md +++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md @@ -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: diff --git a/content/en/releases/patch-releases.md b/content/en/releases/patch-releases.md index b5d9f308a78..d3eead78be0 100644 --- a/content/en/releases/patch-releases.md +++ b/content/en/releases/patch-releases.md @@ -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 | diff --git a/content/en/releases/release-managers.md b/content/en/releases/release-managers.md index 7a87ed9cee2..1e248bf9d25 100644 --- a/content/en/releases/release-managers.md +++ b/content/en/releases/release-managers.md @@ -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 diff --git a/content/fr/docs/concepts/cluster-administration/certificates.md b/content/fr/docs/concepts/cluster-administration/certificates.md index aea92f49676..46637f2fda5 100644 --- a/content/fr/docs/concepts/cluster-administration/certificates.md +++ b/content/fr/docs/concepts/cluster-administration/certificates.md @@ -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 diff --git a/content/id/docs/concepts/cluster-administration/certificates.md b/content/id/docs/concepts/cluster-administration/certificates.md index 8bd58954752..51ab0306a67 100644 --- a/content/id/docs/concepts/cluster-administration/certificates.md +++ b/content/id/docs/concepts/cluster-administration/certificates.md @@ -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 diff --git a/content/ja/docs/concepts/architecture/nodes.md b/content/ja/docs/concepts/architecture/nodes.md index 65a00d397c2..6affe7ccb70 100644 --- a/content/ja/docs/concepts/architecture/nodes.md +++ b/content/ja/docs/concepts/architecture/nodes.md @@ -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" >}} diff --git a/content/ja/docs/concepts/configuration/overview.md b/content/ja/docs/concepts/configuration/overview.md index 911d078b80c..9bec6f87fbe 100644 --- a/content/ja/docs/concepts/configuration/overview.md +++ b/content/ja/docs/concepts/configuration/overview.md @@ -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)を使います。 diff --git a/content/ja/docs/concepts/overview/working-with-objects/labels.md b/content/ja/docs/concepts/overview/working-with-objects/labels.md index 95d6dfc09f9..3c4ed0397a5 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/labels.md +++ b/content/ja/docs/concepts/overview/working-with-objects/labels.md @@ -94,7 +94,7 @@ Kubernetes APIは現在2タイプのセレクターをサポートしていま そしてセレクターを使うAPIタイプは、それらのセレクターの妥当性とそれらが示す意味をドキュメントに記載するべきです。 {{< note >}} -ReplicaSetなど、いくつかのAPIタイプにおいて、2つのインスタンスのラベルセレクターは単一の名前空間において重複してはいけません。重複していると、コントローラがそれらのラベルセレクターがコンフリクトした操作とみなし、どれだけの数のレプリカを稼働させるべきか決めることができなくなります。 +ReplicaSetなど、いくつかのAPIタイプにおいて、2つのインスタンスのラベルセレクターは単一の名前空間において重複してはいけません。重複していると、コントローラーがそれらのラベルセレクターがコンフリクトした操作とみなし、どれだけの数のレプリカを稼働させるべきか決めることができなくなります。 {{< /note >}} {{< caution >}} diff --git a/content/ja/docs/concepts/services-networking/network-policies.md b/content/ja/docs/concepts/services-networking/network-policies.md index 441063aeae4..d73a8581d9b 100644 --- a/content/ja/docs/concepts/services-networking/network-policies.md +++ b/content/ja/docs/concepts/services-networking/network-policies.md @@ -210,7 +210,7 @@ Kubernetes1.20現在、ネットワークポリシーAPIに以下の機能は存 Kubernetesのネットワークセキュリティを初めて使用する場合は、ネットワークポリシーAPIを使用して以下のユーザーストーリーを(まだ)実装できないことに注意してください。これらのユーザーストーリーの一部(全てではありません)は、ネットワークポリシーAPIの将来のリリースで活発に議論されています。 - クラスター内トラフィックを強制的に共通ゲートウェイを通過させる(これは、サービスメッシュもしくは他のプロキシで提供するのが最適な場合があります)。 -- TLS関連のもの(これにはサービスメッシュまたはIngressコントローラを使用します)。 +- TLS関連のもの(これにはサービスメッシュまたはIngressコントローラーを使用します)。 - ノードの固有のポリシー(これらにはCIDR表記を使用できますが、Kubernetesのアイデンティティでノードを指定することはできません)。 - 名前空間またはサービスを名前で指定する(ただし、Podまたは名前空間を{{< glossary_tooltip text="ラベル" term_id="label" >}}で指定することができます。これは多くの場合で実行可能な回避策です)。 - サードパーティによって実行される「ポリシー要求」の作成または管理 diff --git a/content/ja/docs/reference/access-authn-authz/rbac.md b/content/ja/docs/reference/access-authn-authz/rbac.md index 677d039a72c..ef3d82a0252 100644 --- a/content/ja/docs/reference/access-authn-authz/rbac.md +++ b/content/ja/docs/reference/access-authn-authz/rbac.md @@ -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` diff --git a/content/ja/docs/reference/using-api/_index.md b/content/ja/docs/reference/using-api/_index.md index 4cf5b25a953..543b78b2c84 100644 --- a/content/ja/docs/reference/using-api/_index.md +++ b/content/ja/docs/reference/using-api/_index.md @@ -101,7 +101,7 @@ APIサーバー上で`--runtime-config`を設定することで、有効にし {{< note >}} グループやリソースを有効または無効にした場合、 -APIサーバーとコントローラマネージャーを再起動して、`--runtime-config`の変更を反映させる必要があります。 +APIサーバーとコントローラーマネージャーを再起動して、`--runtime-config`の変更を反映させる必要があります。 {{< /note >}} ## 永続化 diff --git a/content/ja/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md b/content/ja/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md index 8579317b769..c7877449f64 100644 --- a/content/ja/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md +++ b/content/ja/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md @@ -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で修正されます。 \ No newline at end of file +この問題はバージョン1.19で修正されます。 diff --git a/content/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md b/content/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md index e3c9f1ecf8b..577d38a5a89 100644 --- a/content/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md +++ b/content/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md @@ -66,7 +66,7 @@ Kubernetesの主要な要素は、WindowsでもLinuxと同じように機能し * リソース制限 * [Controllers](/ja/docs/concepts/workloads/controllers/) - Kubernetesコントローラは、Podの望ましい状態を処理します。次のワークロードコントローラーは、Windowsコンテナでサポートされています。: + Kubernetesコントローラーは、Podの望ましい状態を処理します。次のワークロードコントローラーは、Windowsコンテナでサポートされています。: * ReplicaSet * ReplicationController diff --git a/content/ja/docs/tasks/administer-cluster/certificates.md b/content/ja/docs/tasks/administer-cluster/certificates.md index 56a0d4349d8..48c898d9c43 100644 --- a/content/ja/docs/tasks/administer-cluster/certificates.md +++ b/content/ja/docs/tasks/administer-cluster/certificates.md @@ -1,5 +1,5 @@ --- -title: 証明書 +title: 証明書を手動で生成する content_type: task weight: 20 --- @@ -7,7 +7,7 @@ weight: 20 -クライアント証明書認証を使用する場合、`easyrsa`,`openssl`または`cfssl`を使って手動で証明書を生成することができます。 +クライアント証明書認証を使用する場合、[`easyrsa`](https://github.com/OpenVPN/easy-rsa)、[`openssl`](https://github.com/openssl/openssl)または[`cfssl`](https://github.com/cloudflare/cfssl)を使って手動で証明書を生成することができます。 @@ -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)を生成するための設定ファイルを作成します。 - 角括弧で囲まれた値(例:``)は必ず実際の値に置き換えてから、ファイル(例:`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 = - ST = - L = - O = - OU = - CN = + ```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 = - IP.2 = + 山括弧で囲まれた値(例:``)は必ず実際の値に置き換えてから、ファイル(例:`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 = + ST = + L = + O = + OU = + CN = - 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 = + IP.2 = - 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": "", - "ST": "", - "L": "", - "O": "", - "OU": "" - }] - } -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", - "", - "", - "kubernetes", - "kubernetes.default", - "kubernetes.default.svc", - "kubernetes.default.svc.cluster", - "kubernetes.default.svc.cluster.local" - ], - "key": { - "algo": "rsa", - "size": 2048 - }, - "names": [{ - "C": "", - "ST": "", - "L": "", - "O": "", - "OU": "" - }] - } -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": "", + "ST": "", + "L": "", + "O": "", + "OU": "" + }] + } + ``` + +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", + "", + "", + "kubernetes", + "kubernetes.default", + "kubernetes.default.svc", + "kubernetes.default.svc.cluster", + "kubernetes.default.svc.cluster.local" + ], + "key": { + "algo": "rsa", + "size": 2048 + }, + "names": [{ + "C": "", + "ST": "", + "L": "", + "O": "", + "OU": "" + }] + } + ``` + +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)に記述されています。 diff --git a/content/ja/docs/tasks/debug/debug-cluster/_index.md b/content/ja/docs/tasks/debug/debug-cluster/_index.md index c787281895a..feae8fbb330 100644 --- a/content/ja/docs/tasks/debug/debug-cluster/_index.md +++ b/content/ja/docs/tasks/debug/debug-cluster/_index.md @@ -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と同様の影響があります - 将来的には、これらも複製されるようになり、同じ場所に配置されない可能性があります - 独自の永続的な状態を持っていない。 diff --git a/content/ja/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/content/ja/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md index a395a412ba5..61e003fd46a 100644 --- a/content/ja/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md +++ b/content/ja/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md @@ -6,7 +6,7 @@ weight: 100 -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/)をご覧ください。 diff --git a/content/ja/docs/tutorials/stateful-application/basic-stateful-set.md b/content/ja/docs/tutorials/stateful-application/basic-stateful-set.md index 093962f2cea..81e67375c72 100644 --- a/content/ja/docs/tutorials/stateful-application/basic-stateful-set.md +++ b/content/ja/docs/tutorials/stateful-application/basic-stateful-set.md @@ -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を取得して、コンテナイメージを確認してみましょう。 diff --git a/content/ko/docs/tutorials/security/apparmor.md b/content/ko/docs/tutorials/security/apparmor.md index f8eff05b434..c04d05e24f1 100644 --- a/content/ko/docs/tutorials/security/apparmor.md +++ b/content/ko/docs/tutorials/security/apparmor.md @@ -158,7 +158,7 @@ kubectl get events | grep Created 컨테이너의 루트 프로세스가 올바른 프로파일로 실행되는지는 proc attr을 확인하여 직접 검증할 수 있다. ```shell -kubectl exec cat /proc/1/attr/current +kubectl exec -- cat /proc/1/attr/current ``` ``` k8s-apparmor-example-deny-write (enforce) diff --git a/content/pl/docs/concepts/overview/kubernetes-api.md b/content/pl/docs/concepts/overview/kubernetes-api.md index b6606786913..b7696304589 100644 --- a/content/pl/docs/concepts/overview/kubernetes-api.md +++ b/content/pl/docs/concepts/overview/kubernetes-api.md @@ -104,7 +104,7 @@ opisane są następującym schematem: } } ``` - + Względne adresy URL wskazują na niezmieniające się opisy OpenAPI, aby umożliwić trzymanie cache po stronie klienta. Serwer API zwraca diff --git a/content/ru/docs/tasks/administer-cluster/certificates.md b/content/ru/docs/tasks/administer-cluster/certificates.md index 11cc06610b0..dfb94c44c8e 100644 --- a/content/ru/docs/tasks/administer-cluster/certificates.md +++ b/content/ru/docs/tasks/administer-cluster/certificates.md @@ -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. Используйте следующую команду, чтобы просмотреть запрос на подписание сертификата: diff --git a/content/zh-cn/docs/concepts/cluster-administration/flow-control.md b/content/zh-cn/docs/concepts/cluster-administration/flow-control.md index 50027f7cd0d..c713975625e 100644 --- a/content/zh-cn/docs/concepts/cluster-administration/flow-control.md +++ b/content/zh-cn/docs/concepts/cluster-administration/flow-control.md @@ -4,6 +4,12 @@ content_type: concept min-kubernetes-server-version: v1.18 weight: 110 --- + @@ -75,39 +81,40 @@ APF 适用于 **watch** 请求。当 APF 被禁用时，**watch** 请求不受 ` 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 \ # ...其他配置不变 ``` -或者，你也可以通过 `--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 版本。 ### 优先级 {#Priority-Levels} 如果未启用 APF，API 服务器中的整体并发量将受到 `kube-apiserver` 的参数 `--max-requests-inflight` 和 `--max-mutating-requests-inflight` 的限制。 启用 APF 后，将对这些参数定义的并发限制进行求和，然后将总和分配到一组可配置的 **优先级** 中。 -每个传入的请求都会分配一个优先级；每个优先级都有各自的配置，设定允许分发的并发请求数。 +每个传入的请求都会分配一个优先级；每个优先级都有各自的限制，设定特定限制允许分发的并发请求数。 +优先级的并发限制会被定期调整，允许利用率较低的优先级将并发度临时借给利用率很高的优先级。 +这些限制基于一个优先级可以借出多少个并发度以及可以借用多少个并发度的额定限制和界限， +所有这些均源自下述配置对象。 + -PriorityLevelConfiguration 的并发限制不是指定请求绝对数量，而是在“并发份额”中指定。 -API 服务器的总并发量限制通过这些份额按例分配到现有 PriorityLevelConfiguration 中。 +PriorityLevelConfiguration 的额定并发限制不是指定请求绝对数量，而是以“额定并发份额”的形式指定。 +API 服务器的总并发量限制通过这些份额按例分配到现有 PriorityLevelConfiguration 中， +为每个级别按照数量赋予其额定限制。 集群管理员可以更改 `--max-requests-inflight` （或 `--max-mutating-requests-inflight`）的值， 再重新启动 `kube-apiserver` 来增加或减小服务器的总流量， 然后所有的 PriorityLevelConfiguration 将看到其最大并发增加（或减少）了相同的比例。 +{{< caution >}} + +在 `v1beta3` 之前的版本中，相关的 PriorityLevelConfiguration +字段被命名为“保证并发份额”而不是“额定并发份额”。此外在 Kubernetes v1.25 +及更早的版本中，不存在定期的调整：所实施的始终是额定/保证的限制，不存在调整。 +{{< /caution >}} + + +一个优先级可以借出的并发数界限以及可以借用的并发数界限在 +PriorityLevelConfiguration 表现该优先级的额定限制。 +这些界限值乘以额定限制/100.0 并取整，被解析为绝对席位数量。 +某优先级的动态调整并发限制范围被约束在 +(a) 其额定限制的下限值减去其可借出的席位和 +(b) 其额定限制的上限值加上它可以借用的席位之间。 +在每次调整时，通过每个优先级推导得出动态限制，具体过程为回收最近出现需求的所有借出的席位， +然后在刚刚描述的界限内共同公平地响应有关这些优先级最近的席位需求。 + {{< caution >}} -启用 APF 特性后，服务器的总并发量限制将设置为 -`--max-requests-inflight` 和 `--max-mutating-requests-inflight` 之和。 -可变请求和不可变请求之间不再有任何区别； -如果对于某种资源，你需要区别对待不同请求，请创建不同的 FlowSchema 分别匹配可变请求和不可变请求。 +启用 APF 特性时，服务器的总并发限制被设置为 `--max-requests-inflight` 及 +`--max-mutating-requests-inflight` 之和。变更性和非变更性请求之间不再有任何不同； +如果你想针对某给定资源分别进行处理，请制作单独的 FlowSchema，分别匹配变更性和非变更性的动作。 {{< /caution >}} * `apiserver_flowcontrol_rejected_requests_total` 是一个计数器向量， 记录被拒绝的请求数量（自服务器启动以来累计值）， - 由标签 `flow_chema`（表示与请求匹配的 FlowSchema）、`priority_evel` + 由标签 `flow_chema`（表示与请求匹配的 FlowSchema）、`priority_level` （表示分配给请该求的优先级）和 `reason` 来区分。 `reason` 标签将具有以下值之一： + -* `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` - 是请求数量的高或低水位线的直方图向量（除以相应的限制，得到介于 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` 是一个表向量， 记录包含排队中的（未执行）请求的瞬时数量， - 由标签 `priority_level` 和 `flow_schema` 拆分。 + 由标签 `priority_level` 和 `flow_schema` 区分。 -* `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` - 是请求数量的高或低水位线的直方图向量（除以相应的限制，得到 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_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` 是一个表向量，包含每个优先级的额定并发度限制， + 指标值根据 API 服务器的总并发度限制和各优先级所配置的额定并发度份额计算得出。 + + +* `apiserver_flowcontrol_lower_limit_seats` 是一个表向量，包含每个优先级的动态并发度限制的下限。 + + +* `apiserver_flowcontrol_upper_limit_seats` 是一个表向量，包含每个优先级的动态并发度限制的上限。 + + +* `apiserver_flowcontrol_demand_seats` 是一个直方图向量， + 统计每纳秒结束时每个优先级的（席位需求）/（额定并发限制）比率的观察值。 + 某优先级的席位需求是针对排队的请求和初始执行阶段的请求，在请求的初始和最终执行阶段占用的最大席位数之和。 + + +* `apiserver_flowcontrol_demand_seats_high_watermark` 是一个表向量， + 为每个优先级包含了上一个并发度借用调整期间所观察到的最大席位需求。 + + +* `apiserver_flowcontrol_demand_seats_average` 是一个表向量， + 为每个优先级包含了上一个并发度借用调整期间所观察到的时间加权平均席位需求。 + + +* `apiserver_flowcontrol_demand_seats_stdev` 是一个表向量， + 为每个优先级包含了上一个并发度借用调整期间所观察到的席位需求的时间加权总标准偏差。 + + +* `apiserver_flowcontrol_target_seats` 是一个表向量， + 包含每个优先级触发借用分配问题的并发度目标值。 + + +* `apiserver_flowcontrol_seat_fair_frac` 是一个表向量， + 包含了上一个借用调整期间确定的公平分配比例。 + + +* `apiserver_flowcontrol_current_limit_seats` 是一个表向量， + 包含每个优先级的上一次调整期间得出的动态并发限制。 -对每一个新创建的 Pod 或者是未被调度的 Pod，kube-scheduler 会选择一个最优的节点去运行这个 Pod。 -然而，Pod 内的每一个容器对资源都有不同的需求， -而且 Pod 本身也有不同的需求。因此，Pod 在被调度到节点上之前， -根据这些特定的调度需求，需要对集群中的节点进行一次过滤。 +Kube-scheduler 选择一个最佳节点来运行新创建的或尚未调度（unscheduled）的 Pod。 +由于 Pod 中的容器和 Pod 本身可能有不同的要求，调度程序会过滤掉任何不满足 Pod 特定调度需求的节点。 +或者，API 允许你在创建 Pod 时为它指定一个节点，但这并不常见，并且仅在特殊情况下才会这样做。 @@ -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 控制器的广泛支持。 -以下 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/) diff --git a/content/zh-cn/docs/concepts/services-networking/service.md b/content/zh-cn/docs/concepts/services-networking/service.md index be8ece1709a..db8907865d0 100644 --- a/content/zh-cn/docs/concepts/services-networking/service.md +++ b/content/zh-cn/docs/concepts/services-networking/service.md @@ -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 中后端软件公开的端口号，而不会破坏客户端。 -服务的默认协议是 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`。 - -## 虚拟 IP 和 Service 代理 {#virtual-ips-and-service-proxies} - -在 Kubernetes 集群中，每个 Node 运行一个 `kube-proxy` 进程。 -`kube-proxy` 负责为 Service 实现了一种 VIP（虚拟 IP）的形式，而不是 -[`ExternalName`](#externalname) 的形式。 - - -### 为什么不使用 DNS 轮询？ {#why-not-use-round-robin-dns} - -时不时会有人问到为什么 Kubernetes 依赖代理将入站流量转发到后端。那其他方法呢？ -例如，是否可以配置具有多个 A 值（或 IPv6 为 AAAA）的 DNS 记录，并依靠轮询名称解析？ - -使用服务代理有以下几个原因： - -* DNS 实现的历史由来已久，它不遵守记录 TTL，并且在名称查找结果到期后对其进行缓存。 -* 有些应用程序仅执行一次 DNS 查找，并无限期地缓存结果。 -* 即使应用和库进行了适当的重新解析，DNS 记录上的 TTL 值低或为零也可能会给 - DNS 带来高负载，从而使管理变得困难。 - - -在本页下文中，你可以了解各种 kube-proxy 实现是如何工作的。 -总的来说，你应该注意当运行 `kube-proxy` 时，内核级别的规则可能会被修改（例如，可能会创建 iptables 规则）， -在某些情况下直到你重新引导才会清理这些内核级别的规则。 -因此，运行 kube-proxy 只能由了解在计算机上使用低级别、特权网络代理服务后果的管理员来完成。 -尽管 `kube-proxy` 可执行文件支持 `cleanup` 功能，但此功能不是官方特性，因此只能按原样使用。 - - -### 配置 {#configuration} - -请注意，kube-proxy 可以以不同的模式启动，具体取决于其配置。 - -- kube-proxy 的配置是通过 ConfigMap 完成的，并且 kube-proxy 的 ConfigMap 有效地弃用了 kube-proxy 几乎所有标志的行为。 -- kube-proxy 的 ConfigMap 不支持实时重新加载配置。 -- kube-proxy 的 ConfigMap 参数不能在启动时被全部校验和验证。 - 例如，如果你的操作系统不允许你运行 iptables 命令，则标准内核 kube-proxy 实现将无法工作。 - 同样，如果你的操作系统不支持 `netsh`，它将无法在 Windows 用户空间模式下运行。 - - -### 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-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-ipvs} - -{{< feature-state for_k8s_version="v1.11" state="stable" >}} - - -在 `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 >}} - -要在 IPVS 模式下运行 kube-proxy，必须在启动 kube-proxy 之前使 IPVS 在节点上可用。 - -当 kube-proxy 以 IPVS 代理模式启动时，它将验证 IPVS 内核模块是否可用。 -如果未检测到 IPVS 内核模块，则 kube-proxy 将退回到以 iptables 代理模式运行。 -{{< /note >}} - - - -![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 >}} - -在 Windows 上，不支持为服务设置最大会话停留时间。 -{{< /note >}} -## 流量策略 {#traffic-policies} - - -### 外部流量策略 {#external-traffic-policy} - - -你可以通过设置 `spec.externalTrafficPolicy` 字段来控制来自于外部的流量是如何路由的。 -可选值有 `Cluster` 和 `Local`。字段设为 `Cluster` 会将外部流量路由到所有就绪的端点， -设为 `Local` 会只路由到当前节点上就绪的端点。 -如果流量策略设置为 `Local`，而且当前节点上没有就绪的端点，kube-proxy 不会转发请求相关服务的任何流量。 - -{{< note >}} -{{< feature-state for_k8s_version="v1.22" state="alpha" >}} - - -如果你启用了 kube-proxy 的 `ProxyTerminatingEndpoints` -[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)， -kube-proxy 会检查节点是否有本地的端点，以及是否所有的本地端点都被标记为终止中。 - - -如果本地有端点，而且所有端点处于终止中的状态，那么 kube-proxy 会忽略任何设为 `Local` 的外部流量策略。 -在所有本地端点处于终止中的状态的同时，kube-proxy 将请求指定服务的流量转发到位于其它节点的状态健康的端点， -如同外部流量策略设为 `Cluster`。 - - -针对处于正被终止状态的端点这一转发行为使得外部负载均衡器可以优雅地排出由 -`NodePort` 服务支持的连接，就算是健康检查节点端口开始失败也是如此。 -否则，当节点还在负载均衡器的节点池内，在 Pod 终止过程中的流量会被丢掉，这些流量可能会丢失。 - -{{< /note >}} - - -### 内部流量策略 {#internal-traffic-policy} - -{{< feature-state for_k8s_version="v1.22" state="beta" >}} - - -你可以设置 `spec.internalTrafficPolicy` 字段来控制内部来源的流量是如何转发的。可设置的值有 `Cluster` 和 `Local`。 -将字段设置为 `Cluster` 会将内部流量路由到所有就绪端点，设置为 `Local` 只会路由到当前节点上就绪的端点。 -如果流量策略是 `Local`，而且当前节点上没有就绪的端点，那么 kube-proxy 会丢弃流量。 - +`type` 字段被设计为嵌套功能 - 每个级别都添加到前一个级别。 +这并不是所有云提供商都严格要求的（例如：Google Compute Engine +不需要分配节点端口来使 `type: LoadBalancer` 工作，但另一个云提供商集成可能会这样做）。 +虽然不需要严格的嵌套，但是 Service 的 Kubernetes API 设计无论如何都需要它。 + -## 不足之处 {#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 设计是强制要求的。 - - -## 虚拟 IP 实施 {#the-gory-details-of-virtual-ips} - -对很多想使用 Service 的人来说，前面的信息应该足够了。 -然而，有很多内部原理性的内容，还是值去理解的。 - - -### 避免冲突 {#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 地址。 - - -#### `type: ClusterIP` 服务的 IP 地址范围 {#service-ip-static-sub-range} - -{{< feature-state for_k8s_version="v1.25" state="beta" >}} -但是，这种 `ClusterIP` 分配策略存在一个问题，因为用户还可以[为服务选择自己的地址](#choosing-your-own-ip-address)。 -如果内部分配器为另一个服务选择相同的 IP 地址，这可能会导致冲突。 - - -`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 地址 {#ips-and-vips} - -不像 Pod 的 IP 地址，它实际路由到一个固定的目的地，Service 的 IP 实际上不能通过单个主机来进行应答。 -相反，我们使用 `iptables`（Linux 中的数据包处理逻辑）来定义一个虚拟 IP 地址（VIP）， -它可以根据需要透明地进行重定向。 -当客户端连接到 VIP 时，它们的流量会自动地传输到一个合适的 Endpoint。 -环境变量和 DNS，实际上会根据 Service 的 VIP 和端口来进行填充。 - -kube-proxy 支持三种代理模式: 用户空间、iptables 和 IPVS；它们各自的操作略有不同。 - -#### Userspace {#userspace} - - -作为一个例子，考虑前面提到的图片处理应用程序。 -当创建后端 Service 时，Kubernetes master 会给它指派一个虚拟 IP 地址，比如 10.0.0.1。 -假设 Service 的端口是 1234，该 Service 会被集群中所有的 `kube-proxy` 实例观察到。 -当代理看到一个新的 Service，它会打开一个新的端口， -建立一个从该 VIP 重定向到新端口的 iptables，并开始接收请求连接。 - -当一个客户端连接到一个 VIP，iptables 规则开始起作用，它会重定向该数据包到 -"服务代理" 的端口。 -"服务代理" 选择一个后端，并将客户端的流量代理到后端上。 - -这意味着 Service 的所有者能够选择任何他们想使用的端口，而不存在冲突的风险。 -客户端可以连接到一个 IP 和端口，而不需要知道实际访问了哪些 Pod。 - -#### iptables - - -再次考虑前面提到的图片处理应用程序。 -当创建后端 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 - - -在大规模集群（例如 10000 个服务）中，iptables 操作会显着降低速度。 -IPVS 专为负载均衡而设计，并基于内核内哈希表。 -因此，你可以通过基于 IPVS 的 kube-proxy 在大量服务中实现性能一致性。 -同时，基于 IPVS 的 kube-proxy 具有更复杂的负载均衡算法（最小连接、局部性、加权、持久性）。 +如果你想确保来自特定客户端的连接每次都传递到同一个 Pod，你可以配置根据客户端 IP 地址来执行的会话亲和性。 +阅读[会话亲和性](/zh-cn/docs/reference/networking/virtual-ips/#session-affinity)了解更多。 ## 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 + + -你可以将 TCP 用于任何类型的服务，这是默认的网络协议。 +## 虚拟 IP 寻址机制 {#virtual-ip-addressing-mechanism} -### UDP - - -你可以将 UDP 用于大多数服务。 对于 type=LoadBalancer 服务，对 UDP 的支持取决于提供此功能的云提供商。 - - -### SCTP - -{{< feature-state for_k8s_version="v1.20" state="stable" >}} - -一旦你使用了支持 SCTP 流量的网络插件，你就可以使用 SCTP 于更多的服务。 -对于 type = LoadBalancer 的服务，SCTP 的支持取决于提供此设施的云供应商（大多数不支持）。 - - -#### 警告 {#caveat-sctp-overview} - -##### 支持多宿主 SCTP 关联 {#caveat-sctp-multihomed} - -{{< warning >}} - -支持多宿主 SCTP 关联要求 CNI 插件能够支持为一个 Pod 分配多个接口和 IP 地址。 - -用于多宿主 SCTP 关联的 NAT 在相应的内核模块中需要特殊的逻辑。 -{{< /warning >}} - - -##### Windows {#caveat-sctp-windows-os} - -{{< note >}} - -基于 Windows 的节点不支持 SCTP。 -{{< /note >}} - - -##### 用户空间 kube-proxy {#caveat-sctp-kube-proxy-userspace} - -{{< warning >}} - -当 kube-proxy 处于用户空间模式时，它不支持 SCTP 关联的管理。 -{{< /warning >}} - -### HTTP - - -如果你的云提供商支持它，则可以在 LoadBalancer 模式下使用服务来设置外部 -HTTP/HTTPS 反向代理，并将其转发到该服务的 Endpoints。 - -{{< note >}} - -你还可以使用 {{< glossary_tooltip text="Ingress" term_id="ingress" >}} 代替 -Service 来公开 HTTP/HTTPS 服务。 -{{< /note >}} - - -### 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 -``` - - -上述是来自客户端的数据。 +阅读[虚拟 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/) \ No newline at end of file diff --git a/content/zh-cn/docs/concepts/storage/persistent-volumes.md b/content/zh-cn/docs/concepts/storage/persistent-volumes.md index ed6525d8538..487337b263b 100644 --- a/content/zh-cn/docs/concepts/storage/persistent-volumes.md +++ b/content/zh-cn/docs/concepts/storage/persistent-volumes.md @@ -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` Kubernetes 不对挂载选项执行合法性检查。如果挂载选项是非法的，挂载就会失败。 diff --git a/content/zh-cn/docs/concepts/workloads/controllers/job.md b/content/zh-cn/docs/concepts/workloads/controllers/job.md index 63e26065c5c..f42e09b2145 100644 --- a/content/zh-cn/docs/concepts/workloads/controllers/job.md +++ b/content/zh-cn/docs/concepts/workloads/controllers/job.md @@ -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/) | ✓ | 有时 | 有时 | -[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 >}} 要使用该行为，你必须为 [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/)。 -默认是启用的。 +该特性默认是启用的。 ## 组件 {#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/)列表 允许用户请求自动创建存储{{< glossary_tooltip text="卷" term_id="volume" >}}。 @@ -35,7 +35,8 @@ tags: -动态供应让集群管理员无需再预先供应存储。相反，它通过用户请求自动地供应存储。 -动态卷供应是基于 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" >}}， +也可以引用传递给卷插件的参数集。 diff --git a/content/zh-cn/docs/reference/glossary/replication-controller.md b/content/zh-cn/docs/reference/glossary/replication-controller.md index 3ac4033f422..304466f7c7e 100644 --- a/content/zh-cn/docs/reference/glossary/replication-controller.md +++ b/content/zh-cn/docs/reference/glossary/replication-controller.md @@ -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: --- -一种工作管理多副本应用的负载资源，能够确保特定个数的 +一种管理多副本应用的工作负载资源，能够确保特定个数的 {{< glossary_tooltip text="Pod" term_id="pod" >}} 实例处于运行状态。 - + -控制面确保所指定的个数的 Pods 处于运行状态，即使某些 Pod 会失效， -比如被你手动删除或者因为其他错误启动过多 Pod 时。 +控制平面确保即使某些 Pod 失效、被你手动删除或错误地启动了过多 Pod 时， +指定数量的 Pod 仍处于运行状态。 {{< note >}} -ReplicationController 已被启用。请参见 Deployment 执行类似功能。 +ReplicationController 已被弃用。请参见执行类似功能的 +{{< glossary_tooltip text="Deployment" term_id="deployment" >}}。 {{< /note >}} - diff --git a/content/zh-cn/docs/reference/glossary/taint.md b/content/zh-cn/docs/reference/glossary/taint.md index 65040d6bbe7..48f1141c6c4 100644 --- a/content/zh-cn/docs/reference/glossary/taint.md +++ b/content/zh-cn/docs/reference/glossary/taint.md @@ -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 - --> +--> -污点是一种一个核心对象，包含三个必需的属性：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" >}}。 diff --git a/content/zh-cn/docs/reference/glossary/toleration.md b/content/zh-cn/docs/reference/glossary/toleration.md index d42ff669589..ae8c7727deb 100644 --- a/content/zh-cn/docs/reference/glossary/toleration.md +++ b/content/zh-cn/docs/reference/glossary/toleration.md @@ -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: --> -一个核心对象，由三个必需的属性组成：key、value 和 effect。 -容忍度允许将 Pod 调度到具有对应{{< glossary_tooltip text="污点" term_id="taint" >}} -的节点或节点组上。 - +容忍度是一种核心对象，包含三个必需的属性：key、value 和 effect。容忍度允许将 Pod +调度到具有对应{{< glossary_tooltip text="污点" 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" >}}是允许的（但并非必需）。 diff --git a/content/zh-cn/docs/reference/kubectl/cheatsheet.md b/content/zh-cn/docs/reference/kubectl/cheatsheet.md index 964920adb92..1c588820984 100644 --- a/content/zh-cn/docs/reference/kubectl/cheatsheet.md +++ b/content/zh-cn/docs/reference/kubectl/cheatsheet.md @@ -42,7 +42,7 @@ This page contains a list of commonly used `kubectl` commands and flags. @@ -74,9 +74,9 @@ echo '[[ $commands[kubectl] ]] && source <(kubectl completion zsh)' >> ~/.zshrc ``` -### 关于 --all-namespaces 的一点说明 {#a-note-on-all-namespaces} +### 关于 `--all-namespaces` 的一点说明 {#a-note-on-all-namespaces} ## 查看和查找资源 {#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} @@ -727,7 +729,7 @@ kubectl cp my-namespace/my-pod:/tmp/foo /tmp/bar # 将 /tmp/foo 从远程 {{< note >}} `kubectl cp` 要求容器镜像中存在 “tar” 二进制文件。如果 “tar” 不存在，`kubectl cp` 将失败。 diff --git a/content/zh-cn/docs/reference/labels-annotations-taints/_index.md b/content/zh-cn/docs/reference/labels-annotations-taints/_index.md index 8d11ab3bdca..3748d199c37 100644 --- a/content/zh-cn/docs/reference/labels-annotations-taints/_index.md +++ b/content/zh-cn/docs/reference/labels-annotations-taints/_index.md @@ -1644,11 +1644,11 @@ kubeadm 为本地管理的 etcd Pod 设置的注解，用来跟踪 etcd 客户 ### kubeadm.kubernetes.io/kube-apiserver.advertise-address.endpoint {#kube-apiserver-advertise-address-endpoint} -例子：`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 diff --git a/content/zh-cn/docs/reference/networking/_index.md b/content/zh-cn/docs/reference/networking/_index.md new file mode 100644 index 00000000000..554617a030f --- /dev/null +++ b/content/zh-cn/docs/reference/networking/_index.md @@ -0,0 +1,21 @@ +--- +title: 网络参考 +content_type: reference +weight: 85 +--- + + + + + + +Kubernetes 文档的这一部分提供了 Kubernetes 网络的参考详细信息。 + + \ No newline at end of file diff --git a/content/zh-cn/docs/reference/ports-and-protocols.md b/content/zh-cn/docs/reference/networking/ports-and-protocols.md similarity index 92% rename from content/zh-cn/docs/reference/ports-and-protocols.md rename to content/zh-cn/docs/reference/networking/ports-and-protocols.md index 4bd3aab5d57..90a97f38b25 100644 --- a/content/zh-cn/docs/reference/ports-and-protocols.md +++ b/content/zh-cn/docs/reference/networking/ports-and-protocols.md @@ -3,12 +3,11 @@ title: 端口和协议 content_type: reference weight: 50 --- + -当你在一个有严格网络边界的环境里运行 Kubernetes，例如拥有物理网络防火墙或者拥有公有云中虚拟网络的自有数据中心，了解 Kubernetes 组件使用了哪些端口和协议是非常有用的。 +当你在一个有严格网络边界的环境里运行 Kubernetes，例如拥有物理网络防火墙或者拥有公有云中虚拟网络的自有数据中心， +了解 Kubernetes 组件使用了哪些端口和协议是非常有用的。 + + + +如果你配置 {{< glossary_tooltip text="Service" term_id="service" >}}， +你可以从 Kubernetes 支持的任何网络协议中选择一个协议。 + +Kubernetes 支持以下协议用于 Service： + +- [`SCTP`](#protocol-sctp) +- [`TCP`](#protocol-tcp) **（默认值）** +- [`UDP`](#protocol-udp) + + +当你定义 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) 终止于负载均衡器处 + + + +## 支持的协议 {#protocol-support} + +Service 端口的 `protocol` 有 3 个有效值： + +### `SCTP` {#protocol-sctp} + +{{< feature-state for_k8s_version="v1.20" state="stable" >}} + + +当使用支持 SCTP 流量的网络插件时，你可以为大多数 Service 使用 SCTP。 +对于 `type: LoadBalancer` Service，对 SCTP 的支持情况取决于提供此项设施的云供应商（大部分不支持）。 + +运行 Windows 的节点不支持 SCTP。 + + +#### 支持多宿主 SCTP 关联 {#caveat-sctp-multihomed} + +对多宿主 SCTP 关联的支持要求 CNI 插件可以支持为 Pod 分配多个接口和 IP 地址。 + +针对多宿主 SCTP 关联的 NAT 需要在对应的内核模块具有特殊的逻辑。 + +{{< note >}} + +当 kube-proxy 处于 userspace 模式时不支持管理 SCTP 关联。 +{{< /note >}} + +### `TCP` {#protocol-tcp} + + +你可以将 TCP 用于任何类别的 Service，这是默认的网络协议。 + +### `UDP` {#protocol-udp} + + +你可以将 UDP 用于大多数 Service。对于 `type: LoadBalancer` Service， +UDP 的支持与否取决于提供此项设施的云供应商。 + + +## 特殊场景 {#special-cases} + +### HTTP {#protocol-http-special} + + +如果你的云供应商支持负载均衡，而且尤其是该云供应商的负载均衡器实现了 HTTP/HTTPS 反向代理， +可将流量转发到该 Service 的后端端点，那么你就可以使用 LoadBalancer 模式的 Service 以便在 +Kubernetes 集群外部配置负载均衡器。 + + +通常，你将 Service 协议设置为 `TCP`， +并添加一个{{< glossary_tooltip text="注解" term_id="annotation" >}} +（一般取决于你的云供应商）配置负载均衡器，以便在 HTTP 级别处理流量。 +此配置也可能包括为你的工作负载提供 HTTPS（基于 TLS 的 HTTP）并反向代理纯 HTTP。 + +{{< note >}} + +你也可以使用 {{< glossary_tooltip term_id="ingress" >}} 来暴露 HTTP/HTTPS Service。 +{{< /note >}} + + +你可能还想指定连接的[应用协议](/zh-cn/docs/concepts/services-networking/service/#application-protocol)是 +`http` 还是 `https`。如果从负载均衡器到工作负载的会话是不带 TLS 的 HTTP，请使用 `http`； +如果从负载均衡器到工作负载的会话使用 TLS 加密，请使用 `https`。 + + +### 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 +``` + + +代理协议前导码之后的数据是来自客户端的原始数据。 +当任何一侧关闭连接时，负载均衡器也会触发连接关闭并在可行的情况下发送所有残留数据。 + +通常，你会将 Service 协议定义为 `TCP`。 +你还会设置一个特定于云供应商的注解，将负载均衡器配置为以 PROXY 协议封装所有传入的连接。 + +### TLS {#protocol-tls-special} + + +如果你的云供应商支持 TLS，你可以使用设置为 `type: LoadBalancer` 的 Service +作为设置外部反向代理的一种方式，其中从客户端到负载均衡器的连接是 TLS 加密的且该负载均衡器是 +TLS 对等服务器。从负载均衡器到工作负载的连接可以是 TLS，或可能是纯文本。 +你可以使用的确切选项取决于你的云供应商或自定义 Service 实现。 + +通常，你会将协议设置为 `TCP` 并设置一个注解（通常特定于你的云供应商）， +将负载均衡器配置为充当一个 TLS 服务器。你将使用特定于云供应商的机制来配置 TLS 身份 +（作为服务器，也可能作为连接到工作负载的客户端）。 diff --git a/content/zh-cn/docs/reference/node/_index.md b/content/zh-cn/docs/reference/node/_index.md index fa14be0a6c1..837d17c7b9f 100644 --- a/content/zh-cn/docs/reference/node/_index.md +++ b/content/zh-cn/docs/reference/node/_index.md @@ -1,9 +1,31 @@ --- title: 节点参考信息 -weight: 40 +weight: 80 +no_list: true --- + + +本部分包含以下有关节点的参考主题： + +* 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)。 \ No newline at end of file diff --git a/content/zh-cn/docs/reference/setup-tools/kubeadm/kubeadm-init.md b/content/zh-cn/docs/reference/setup-tools/kubeadm/kubeadm-init.md index f78fb8f388b..8f255401fa6 100644 --- a/content/zh-cn/docs/reference/setup-tools/kubeadm/kubeadm-init.md +++ b/content/zh-cn/docs/reference/setup-tools/kubeadm/kubeadm-init.md @@ -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 >}} + +在使用 `--config` +传递[配置文件](https://kubernetes.io/zh-cn/docs/reference/config-api/kubeadm-config.v1beta3/)时， +可以在 `InitConfiguration` 中提供预定义的 `certificateKey`。 +{{< /note >}} -如果未将参数 `--certificate-key` 传递给 `kubeadm init` 和 `kubeadm init phase upload-certs`， +如果未将预定义的证书密钥传递给 `kubeadm init` 和 `kubeadm init phase upload-certs`， 则会自动生成一个新密钥。 以下命令可用于按需生成新密钥： diff --git a/content/zh-cn/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md b/content/zh-cn/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md index a72516ff4d5..c97690bb80a 100644 --- a/content/zh-cn/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md +++ b/content/zh-cn/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md @@ -85,12 +85,12 @@ route, we recommend you add IP route(s) so Kubernetes cluster addresses go via t ## 检查所需端口{#check-required-ports} -启用这些[必要的端口](/zh-cn/docs/reference/ports-and-protocols/)后才能使 Kubernetes 的各组件相互通信。 +启用这些[必要的端口](/zh-cn/docs/reference/networking/ports-and-protocols/)后才能使 Kubernetes 的各组件相互通信。 可以使用 netcat 之类的工具来检查端口是否启用，例如： ```shell diff --git a/content/zh-cn/docs/tasks/administer-cluster/certificates.md b/content/zh-cn/docs/tasks/administer-cluster/certificates.md index 9f55998edd3..db7653e95d1 100644 --- a/content/zh-cn/docs/tasks/administer-cluster/certificates.md +++ b/content/zh-cn/docs/tasks/administer-cluster/certificates.md @@ -4,20 +4,20 @@ content_type: task weight: 20 --- -在使用客户端证书认证的场景下，你可以通过 `easyrsa`、`openssl` 或 `cfssl` 等工具以手工方式生成证书。 +在使用客户端证书认证的场景下，你可以通过 [`easyrsa`](https://github.com/OpenVPN/easy-rsa)、 +[`openssl`](https://github.com/openssl/openssl) 或 [`cfssl`](https://github.com/cloudflare/cfssl) +等工具以手工方式生成证书。 diff --git a/content/zh-cn/docs/tasks/administer-cluster/memory-manager.md b/content/zh-cn/docs/tasks/administer-cluster/memory-manager.md index 2cccd2f65cc..e4185fa44fc 100644 --- a/content/zh-cn/docs/tasks/administer-cluster/memory-manager.md +++ b/content/zh-cn/docs/tasks/administer-cluster/memory-manager.md @@ -188,7 +188,7 @@ NUMA 节点的分组，从而扩展内存容量。解决这个问题的详细描 ## 内存管理器配置 {#memory-manager-configuration} + + + + +在此例中，你将以[索引完成模式](/blog/2021/04/19/introducing-indexed-jobs/)运行一个 Job， +并通过配置使得该 Job 所创建的各 Pod 之间可以使用 Pod 主机名而不是 Pod IP 地址进行通信。 + +某 Job 内的 Pod 之间可能需要通信。每个 Pod 中运行的用户工作负载可以查询 Kubernetes API +服务器以获知其他 Pod 的 IP，但使用 Kubernetes 内置的 DNS 解析会更加简单。 + + +索引完成模式下的 Job 自动将 Pod 的主机名设置为 `${jobName}-${completionIndex}` 的格式。 +你可以使用此格式确定性地构建 Pod 主机名并启用 Pod 通信，无需创建到 Kubernetes +控制平面的客户端连接来通过 API 请求获取 Pod 主机名/IP。 + +此配置可用于需要 Pod 联网但不想依赖 Kubernetes API 服务器网络连接的使用场景。 + +## {{% heading "prerequisites" %}} + + +你应该已熟悉了 [Job](/zh-cn/docs/concepts/workloads/controllers/job/) 的基本用法。 + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +{{}} + +如果你正在使用 MiniKube 或类似的工具， +你可能需要采取[额外的步骤](https://minikube.sigs.k8s.io/docs/handbook/addons/ingress-dns/)来确保你拥有 DNS。 +{{}} + + + + +## 启动带 Pod 间通信的 Job {#starting-a-job-with-pod-to-pod-communication} + +要在某 Job 中启用使用 Pod 主机名的 Pod 间通信，你必须执行以下操作： + + +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} + +以下是启用通过 Pod 主机名来完成 Pod 间通信的 Job 示例。 +只有在使用主机名成功 ping 通所有 Pod 之后，此 Job 才会结束。 + +{{}} + +在以下示例中的每个 Pod 中执行的 Bash 脚本中，如果需要从名字空间外到达 Pod， +Pod 主机名也可以带有该名字空间作为前缀。 +{{}} + +```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 +``` + + +应用上述示例之后，使用 `.<无头服务名>` 通过网络到达彼此。 +你应看到类似以下的输出： + +```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 +``` + +{{}} + +谨记此例中使用的 `.<无头服务名称>` 名称格式不适用于设置为 `None` 或 `Default` 的 DNS 策略。 +你可以在[此处](/zh-cn/docs/concepts/services-networking/dns-pod-service/#pod-s-dns-policy)了解有关 +Pod DNS 策略的更多信息。 +{{}} diff --git a/content/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale.md b/content/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale.md index a33cf6874a5..b0aa334b91a 100644 --- a/content/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale.md +++ b/content/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale.md @@ -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 >}} + + +图 1. HorizontalPodAutoscaler 控制 Deployment 及其 ReplicaSet 的规模 * 对于按 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)。 ### 扩缩策略 {#scaling-policies} + 可以在规约的 `behavior` 部分中指定一个或多个扩缩策略。当指定多个策略时， 允许最大更改量的策略是默认选择的策略。以下示例显示了缩小时的这种行为：