diff --git a/Makefile b/Makefile index e3f7d58bad114..b55021909ead9 100644 --- a/Makefile +++ b/Makefile @@ -2,6 +2,9 @@ HUGO_VERSION = $(shell grep ^HUGO_VERSION netlify.toml | tail -n 1 | cut -d NODE_BIN = node_modules/.bin NETLIFY_FUNC = $(NODE_BIN)/netlify-lambda +# The segments variable is used to specify which segments to render. +segments ?= all + # The CONTAINER_ENGINE variable is used for specifying the container engine. By default 'docker' is used # but this can be overridden when calling make, e.g. # CONTAINER_ENGINE=podman make container-image @@ -69,7 +72,7 @@ non-production-build: module-check ## Build the non-production site, which adds GOMAXPROCS=1 hugo --cleanDestinationDir --enableGitInfo --environment nonprod serve: module-check ## Boot the development server. - hugo server --buildDrafts --buildFuture --environment development + hugo server --buildDrafts --buildFuture --environment development --renderSegments $(segments) docker-image: @echo -e "$(CCRED)**** The use of docker-image is deprecated. Use container-image instead. ****$(CCEND)" @@ -118,7 +121,7 @@ container-build: module-check container-serve: module-check ## Boot the development server using container. $(CONTAINER_RUN_TTY) --cap-drop=ALL --cap-add=AUDIT_WRITE $(CONTAINER_HUGO_MOUNTS) \ -p 1313:1313 $(CONTAINER_IMAGE) \ - hugo server --buildDrafts --buildFuture --environment development --bind 0.0.0.0 --destination /tmp/public --cleanDestinationDir --noBuildLock + hugo server --buildDrafts --buildFuture --environment development --bind 0.0.0.0 --destination /tmp/public --cleanDestinationDir --noBuildLock --renderSegments $(segments) test-examples: scripts/test_examples.sh install diff --git a/README.md b/README.md index 7ab196f99682e..e1b5f3fa1f7f9 100644 --- a/README.md +++ b/README.md @@ -55,10 +55,20 @@ To build the site in a container, run the following: ```bash # You can set $CONTAINER_ENGINE to the name of any Docker-like container tool + +# Render the full website make container-serve + +# Render only a specific language segment (e.g., English) +make container-serve segments=en + +# Render multiple languages (e.g., English and Korean) +make container-serve segments=en,ko ``` -If you see errors, it probably means that the hugo container did not have enough computing resources available. To solve it, increase the amount of allowed CPU and memory usage for Docker on your machine ([MacOS](https://docs.docker.com/desktop/settings/mac/) and [Windows](https://docs.docker.com/desktop/settings/windows/)). +**💡 Tip:** Using _Hugo segments_ speeds up local preview builds, by rendering only selected language(s). + +If you see errors, it probably means that the Hugo container did not have enough computing resources available. To solve it, increase the amount of allowed CPU and memory usage for Docker on your machine ([macOS](https://docs.docker.com/desktop/settings/mac/) and [Windows](https://docs.docker.com/desktop/settings/windows/)). Open up your browser to to view the website. As you make changes to the source files, Hugo updates the website and forces a browser refresh. @@ -70,9 +80,19 @@ To install dependencies, deploy and test the site locally, run: ```bash npm ci + + # Render the full site (default) make serve + + # Render only a specific language segment + make serve segments=en + + # Render multiple language segments + make serve segments=en,ko ``` +**💡 Tip:** Hugo segments are defined in `hugo.toml` and allow faster rendering by limiting the scope to specific language(s). + - For Windows (PowerShell) ```powershell @@ -82,6 +102,7 @@ To install dependencies, deploy and test the site locally, run: This will start the local Hugo server on port 1313. Open up your browser to to view the website. As you make changes to the source files, Hugo updates the website and forces a browser refresh. + ## Building the API reference pages The API reference pages located in `content/en/docs/reference/kubernetes-api` are built from the Swagger specification, also known as OpenAPI specification, using . 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 effdaeb51420b..93ad8d267f025 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 @@ -246,7 +246,7 @@ In order to monitor resources provided by device plugins, monitoring agents need discover the set of devices that are in-use on the node and obtain metadata to describe which container the metric should be associated with. [Prometheus](https://prometheus.io/) metrics exposed by device monitoring agents should follow the -[Kubernetes Instrumentation Guidelines](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/instrumentation.md), +[Kubernetes Instrumentation Guidelines](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/metric-instrumentation.md), identifying containers using `pod`, `namespace`, and `container` prometheus labels. The kubelet provides a gRPC service to enable discovery of in-use devices, and to provide metadata diff --git a/content/en/docs/concepts/extend-kubernetes/operator.md b/content/en/docs/concepts/extend-kubernetes/operator.md index 7f9cab1d0cd62..3bd5483006fca 100644 --- a/content/en/docs/concepts/extend-kubernetes/operator.md +++ b/content/en/docs/concepts/extend-kubernetes/operator.md @@ -117,7 +117,7 @@ operator. * [Kopf](https://github.com/nolar/kopf) (Kubernetes Operator Pythonic Framework) * [kube-rs](https://kube.rs/) (Rust) * [kubebuilder](https://book.kubebuilder.io/) -* [KubeOps](https://buehler.github.io/dotnet-operator-sdk/) (.NET operator SDK) +* [KubeOps](https://dotnet.github.io/dotnet-operator-sdk/) (.NET operator SDK) * [Mast](https://docs.ansi.services/mast/user_guide/operator/) * [Metacontroller](https://metacontroller.github.io/metacontroller/intro.html) along with WebHooks that you implement yourself 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 fd55849035702..cfb1b66f4e6b4 100644 --- a/content/en/docs/concepts/services-networking/dns-pod-service.md +++ b/content/en/docs/concepts/services-networking/dns-pod-service.md @@ -105,7 +105,7 @@ Kube-DNS versions, prior to the implementation of the had the following DNS resolution: ``` -pod-ipv4-address.my-namespace.pod.cluster-domain.example +..pod. ``` For example, if a Pod in the `default` namespace has the IP address 172.17.0.3, @@ -121,6 +121,14 @@ Some cluster DNS mechanisms, like [CoreDNS](https://coredns.io/), also provide ` ...svc. ``` +For example, if a Pod in the `cafe` namespace has the IP address 172.17.0.3, +is an endpoint of a Service named `barista`, and the domain name for your cluster is +`cluster.local`, then the Pod would have this service-scoped DNS `A` record. + +``` +172-17-0-3.barista.cafe.svc.cluster.local +``` + ### Pod's hostname and subdomain fields Currently when a Pod is created, its hostname (as observed from within the Pod) diff --git a/content/en/docs/reference/command-line-tools-reference/feature-gates/APIServingWithRoute.md b/content/en/docs/reference/command-line-tools-reference/feature-gates/APIServingWithRoutine.md similarity index 93% rename from content/en/docs/reference/command-line-tools-reference/feature-gates/APIServingWithRoute.md rename to content/en/docs/reference/command-line-tools-reference/feature-gates/APIServingWithRoutine.md index 66a7d68eb7654..690bfa9afdeb0 100644 --- a/content/en/docs/reference/command-line-tools-reference/feature-gates/APIServingWithRoute.md +++ b/content/en/docs/reference/command-line-tools-reference/feature-gates/APIServingWithRoutine.md @@ -1,5 +1,5 @@ --- -title: APIServingWithRoute +title: APIServingWithRoutine content_type: feature_gate _build: list: never diff --git a/content/en/docs/reference/glossary/kubelet.md b/content/en/docs/reference/glossary/kubelet.md index 7ff09cb017b53..53a514a4bf62f 100644 --- a/content/en/docs/reference/glossary/kubelet.md +++ b/content/en/docs/reference/glossary/kubelet.md @@ -2,7 +2,7 @@ title: Kubelet id: kubelet date: 2018-04-12 -full_link: /docs/reference/generated/kubelet +full_link: /docs/reference/command-line-tools-reference/kubelet short_description: > An agent that runs on each node in the cluster. It makes sure that containers are running in a pod. diff --git a/content/en/docs/reference/using-api/cel.md b/content/en/docs/reference/using-api/cel.md index 3bbd7a8d7d9dd..cd55d6dfe3842 100644 --- a/content/en/docs/reference/using-api/cel.md +++ b/content/en/docs/reference/using-api/cel.md @@ -166,7 +166,16 @@ introduced at the specified Kubernetes versions: upperAscii, replace, split, join, substring, trim - All Kubernetes versions + Kubernetes versions between 1.25 and 1.30 + + + Extended strings library, Version 2 + + charAt, indexOf, lastIndexOf, lowerAscii, + upperAscii, replace, split, join, substring, + trim + + Kubernetes versions 1.30+ Kubernetes list library @@ -195,6 +204,25 @@ introduced at the specified Kubernetes versions: All Kubernetes versions + + Kubernetes IP address library + See + + Kubernetes IP address library + + + Kubernetes versions 1.31+ + + + Kubernetes CIDR library + See + + Kubernetes CIDR library + + + Kubernetes versions 1.31+ + + Kubernetes authorizer library See @@ -213,6 +241,24 @@ introduced at the specified Kubernetes versions: Kubernetes versions 1.29+ + + Kubernetes semver library + See + + Kubernetes semver library + + + Kubernetes versions 1.34+ + + + Kubernetes format library + See + + Kubernetes format library + + + Kubernetes versions 1.32+ + CEL optional types See @@ -230,6 +276,14 @@ introduced at the specified Kubernetes versions: Kubernetes versions 1.29+ + + CEL TwoVarComprehensions + See + + CEL TwoVarComprehensions + + + Kubernetes versions 1.33+ @@ -362,6 +416,273 @@ Examples: See the [Kubernetes URL library](https://pkg.go.dev/k8s.io/apiextensions-apiserver/pkg/apiserver/schema/cel/library#URLs) godoc for more information. +### Kubernetes IP address library + +To make it easier and safer to process IP addresses, the following functions have been added: + +- `isIP(string)` checks if a string is a valid IP address. +- `ip(string) IP` converts a string to an IP address object or results in an error if the string is not a valid IP address. + +For both functions, the IP address must be an IPv4 or IPv6 address. +IPv4-mapped IPv6 addresses (e.g. `::ffff:1.2.3.4`) are not allowed. +IP addresses with zones (e.g. `fe80::1%eth0`) are not allowed. +Leading zeros in IPv4 address octets are not allowed. + +Once parsed via the `ip` function, the resulting IP object has the +following library of member functions: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Available member functions of an IP address object
Member FunctionCEL Return ValueDescription
isCanonical()bool + Returns true if the IP address is in its canonical form. + There is exactly one canonical form for every IP address, so fields containing + IPs in canonical form can just be treated as strings when checking for equality or uniqueness. +
family()intReturns the IP address family, 4 for IPv4 and 6 for IPv6.
isUnspecified()bool + Returns true if the IP address is the unspecified address. + Either the IPv4 address "0.0.0.0" or the IPv6 address "::". +
isLoopback()bool + Returns true if the IP address is the loopback address. + Either an IPv4 address with a value of 127.x.x.x or an IPv6 address with a value of ::1. +
isLinkLocalMulticast()bool + Returns true if the IP address is a link-local multicast address. + Either an IPv4 address with a value of 224.0.0.x or an IPv6 address in the network ff00::/8. +
isLinkLocalUnicast()bool + Returns true if the IP address is a link-local unicast address. + Either an IPv4 address with a value of 169.254.x.x or an IPv6 address in the network fe80::/10. +
isGlobalUnicast()bool + Returns true if the IP address is a global unicast address. + Either an IPv4 address that is not zero or 255.255.255.255 or an IPv6 address that is not a link-local unicast, loopback or multicast address. +
+ +Examples: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Examples of CEL expressions using IP address library functions
CEL ExpressionPurpose
isIP('127.0.0.1')Returns true for a valid IP.
ip('2001:db8::abcd').isCanonical()Returns true for a canonical IPv6.
ip('2001:DB8::ABCD').isCanonical()Returns false because the canonical form is lowercase.
ip('127.0.0.1').family() == 4Check the address family of an IP.
ip('::1').isLoopback()Check if an IP is a loopback address.
ip('192.168.0.1').isGlobalUnicast()Check if an IP is a global unicast address.
+ +See the [Kubernetes IP address library](https://pkg.go.dev/k8s.io/apiserver/pkg/cel/library#IP) godoc for more information. + +### Kubernetes CIDR library + +CIDR provides a CEL function library extension of {{< glossary_tooltip text="CIDR" term_id="CIDR" >}} notation parsing functions. + +#### `cidr` + +Converts a string in CIDR notation to a network address representation or results in an error if the string is not a valid CIDR notation. +The CIDR must be an IPv4 or IPv6 subnet address with a mask. +Leading zeros in IPv4 address octets are not allowed. +IPv4-mapped IPv6 addresses (e.g. `::ffff:1.2.3.4/24`) are not allowed. + +cidr(<string>) <CIDR> + +Examples: + +cidr('192.168.0.0/16') // returns an IPv4 address with a CIDR mask +cidr('::1/128') // returns an IPv6 address with a CIDR mask +cidr('192.168.0.0/33') // error +cidr('::1/129') // error +cidr('192.168.0.1/16') // error, because there are non-0 bits after the prefix + +#### `isCIDR` + +Returns true if a string is a valid CIDR notation representation of a subnet with mask. +The CIDR must be an IPv4 or IPv6 subnet address with a mask. +Leading zeros in IPv4 address octets are not allowed. +IPv4-mapped IPv6 addresses (e.g. `::ffff:1.2.3.4/24`) are not allowed. + +isCIDR(<string>) <bool> + +Examples: + +isCIDR('192.168.0.0/16') // returns true +isCIDR('::1/128') // returns true +isCIDR('192.168.0.0/33') // returns false +isCIDR('::1/129') // returns false + +#### `containsIP` / `containsCIDR` / `ip` / `masked` / `prefixLength` + + + +- `containsIP`: Returns true if a the CIDR contains the given IP address. +The IP address must be an IPv4 or IPv6 address. +May take either a string or IP address as an argument. + +- `containsCIDR`: Returns true if a the CIDR contains the given CIDR. +The CIDR must be an IPv4 or IPv6 subnet address with a mask. +May take either a string or CIDR as an argument. + +- `ip`: Returns the IP address representation of the CIDR. + +- `masked`: Returns the CIDR representation of the network address with a masked prefix. +This can be used to return the canonical form of the CIDR network. + +- `prefixLength`: Returns the prefix length of the CIDR in bits. +This is the number of bits in the mask. + +Examples: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Examples of CEL expressions using CIDR library functions
CEL ExpressionPurpose
cidr('192.168.0.0/24').containsIP(ip('192.168.0.1'))Checks if a CIDR contains a given IP address (IP object).
cidr('192.168.0.0/24').containsIP(ip('192.168.1.1'))Checks if a CIDR contains a given IP address (IP object).
cidr('192.168.0.0/24').containsIP('192.168.0.1')Checks if a CIDR contains a given IP address (string).
cidr('192.168.0.0/24').containsIP('192.168.1.1')Checks if a CIDR contains a given IP address (string).
cidr('192.168.0.0/16').containsCIDR(cidr('192.168.10.0/24'))Checks if a CIDR contains another given CIDR (CIDR object).
cidr('192.168.1.0/24').containsCIDR(cidr('192.168.2.0/24'))Checks if a CIDR contains another given CIDR (CIDR object).
cidr('192.168.0.0/16').containsCIDR('192.168.10.0/24')Checks if a CIDR contains another given CIDR (string).
cidr('192.168.1.0/24').containsCIDR('192.168.2.0/24')Checks if a CIDR contains another given CIDR (string).
cidr('192.168.0.1/24').ip()Returns the IP address part of a CIDR.
cidr('192.168.0.1/24').ip().family()Returns the family of the IP address part of a CIDR.
cidr('::1/128').ip()Returns the IP address part of an IPv6 CIDR.
cidr('::1/128').ip().family()Returns the family of the IP address part of an IPv6 CIDR.
cidr('192.168.0.0/24').masked()Returns the canonical form of a CIDR network.
cidr('192.168.0.1/24').masked()Returns the canonical form of a CIDR network, masking non-prefix bits.
cidr('192.168.0.0/24') == cidr('192.168.0.0/24').masked()Compares a CIDR to its canonical form (already canonical).
cidr('192.168.0.1/24') == cidr('192.168.0.1/24').masked()Compares a CIDR to its canonical form (not canonical).
cidr('192.168.0.0/16').prefixLength()Returns the prefix length of an IPv4 CIDR.
cidr('::1/128').prefixLength()Returns the prefix length of an IPv6 CIDR.
+ +See the [Kubernetes CIDR library](https://pkg.go.dev/k8s.io/apiserver/pkg/cel/library#CIDR) godoc for more information. + ### Kubernetes authorizer library For CEL expressions in the API where a variable of type `Authorizer` is available, @@ -448,6 +769,109 @@ See the [Kubernetes Authz library](https://pkg.go.dev/k8s.io/apiserver/pkg/cel/l and [Kubernetes AuthzSelectors library](https://pkg.go.dev/k8s.io/apiserver/pkg/cel/library#AuthzSelectors) godoc for more information. +### Kubernetes format library + +The `format` library provides functions for validating common Kubernetes string formats. +This can be useful in the `messageExpression` of validation rules to provide more specific error messages. + +The library provides `format()` functions for each named format, and a generic `format.named()` function. + +- `format.named(string)` → `?Format`: Returns the `Format` object for the given format name, if it exists. Otherwise, returns `optional.none`. +- `format.() -> Format`: Convenience functions for all the named formats are also available. For example, `format.dns1123Label()` returns the `Format` object for DNS-1123 labels. +- `.validate(string) -> list?`: Validates the given string against the format. Returns `optional.none` if the string is valid, otherwise an optional containing a list of validation error strings. + +**Available Formats:** + +The following format names are supported: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Available formats for the format library
Format NameDescription
dns1123LabelValidates if the string is a valid DNS-1123 label.
dns1123SubdomainValidates if the string is a valid DNS-1123 subdomain.
dns1035LabelValidates if the string is a valid DNS-1035 label.
qualifiedNameValidates if the string is a valid qualified name.
dns1123LabelPrefixValidates if the string is a valid DNS-1123 label prefix.
dns1123SubdomainPrefixValidates if the string is a valid DNS-1123 subdomain prefix.
dns1035LabelPrefixValidates if the string is a valid DNS-1035 label prefix.
labelValueValidates if the string is a valid label value.
uriValidates if the string is a valid URI. Uses the same pattern as `isURL`, but returns an error list.
uuidValidates if the string is a valid UUID.
byteValidates if the string is a valid base64 encoded string.
dateValidates if the string is a valid date in `YYYY-MM-DD` format.
datetimeValidates if the string is a valid datetime in RFC3339 format.
+ +**Examples:** + + + + + + + + + + + + + + + + + + + +
Examples of CEL expressions using format library functions
CEL ExpressionPurpose
!format.dns1123Label().validate(self.metadata.name).hasValue()A validation rule that checks if an object's name is a valid DNS-1123 label.
format.dns1123Label().validate(self.metadata.name).orValue([]).join("\\n")A `messageExpression` that returns specific validation errors for a field. If the field is valid, `validate` returns `optional.none`, and `orValue` provides an empty list, resulting in an empty string.
+ +See the [Kubernetes Format library](https://pkg.go.dev/k8s.io/apiserver/pkg/cel/library#Format) godoc for more information. + ### Kubernetes quantity library Kubernetes 1.28 adds support for manipulating quantity strings (ex 1.5G, 512k, 20Mi) @@ -590,6 +1014,97 @@ Examples: +### Kubernetes semver library + +Kubernetes v1.34 adds support for parsing and comparing strings that follow the Semantic Versioning 2.0.0 specification. +Refer to the [semver.org](https://semver.org/) documentation for information on accepted patterns. + +- `isSemver(string)` checks if a string is a valid semantic version. +- `semver(string)` converts a string to a Semver object or results in an error. + +An optional boolean `normalize` argument can be passed to `isSemver` and `semver`. If `true`, normalization removes any "v" prefix, adds a 0 minor and patch numbers to versions with only major or major.minor components specified, and removes any leading 0s. + +Once parsed via the `semver` function, the resulting Semver object has the +following library of member functions: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Available member functions of a Semver object
Member FunctionCEL Return ValueDescription
major()intReturns the major version number.
minor()intReturns the minor version number.
patch()intReturns the patch version number.
isLessThan(<Semver>)boolReturns true if and only if the receiver is less than the operand.
isGreaterThan(<Semver>)boolReturns true if and only if the receiver is greater than the operand.
compareTo(<Semver>)int + Compares receiver to operand and returns 0 if they are equal, + 1 if the receiver is greater, or -1 if the receiver is less than the operand. +
+ +Examples: + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Examples of CEL expressions using semver library functions
CEL ExpressionPurpose
isSemver('1.0.0')Returns true for a valid Semver string.
isSemver('v1.0', true)Returns true for a normalizable Semver string.
semver('1.2.3').major()Returns the major version of a Semver.
semver('1.2.3').compareTo(semver('2.0.0')) < 0Compare two Semver strings.
+ +See the [Kubernetes Semver library](https://pkg.go.dev/k8s.io/apiserver/pkg/cel/library#SemverLib) godoc for more information. + ## Type checking CEL is a [gradually typed language](https://github.com/google/cel-spec/blob/master/doc/langdef.md#gradual-type-checking). diff --git a/content/en/examples/controllers/daemonset.yaml b/content/en/examples/controllers/daemonset.yaml index 1650ecce4ac31..d7e41ffea97a9 100644 --- a/content/en/examples/controllers/daemonset.yaml +++ b/content/en/examples/controllers/daemonset.yaml @@ -25,7 +25,7 @@ spec: effect: NoSchedule containers: - name: fluentd-elasticsearch - image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2 + image: quay.io/fluentd_elasticsearch/fluentd:v5.0.1 resources: limits: memory: 200Mi diff --git a/content/en/examples/controllers/fluentd-daemonset-update.yaml b/content/en/examples/controllers/fluentd-daemonset-update.yaml index 9521e73b00c0c..ead95f55a363e 100644 --- a/content/en/examples/controllers/fluentd-daemonset-update.yaml +++ b/content/en/examples/controllers/fluentd-daemonset-update.yaml @@ -29,7 +29,7 @@ spec: effect: NoSchedule containers: - name: fluentd-elasticsearch - image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2 + image: quay.io/fluentd_elasticsearch/fluentd:v5.0.1 resources: limits: memory: 200Mi diff --git a/content/en/examples/controllers/fluentd-daemonset.yaml b/content/en/examples/controllers/fluentd-daemonset.yaml index 653636fc57458..7f189fcbceec9 100644 --- a/content/en/examples/controllers/fluentd-daemonset.yaml +++ b/content/en/examples/controllers/fluentd-daemonset.yaml @@ -29,7 +29,7 @@ spec: effect: NoSchedule containers: - name: fluentd-elasticsearch - image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2 + image: quay.io/fluentd_elasticsearch/fluentd:v5.0.1 volumeMounts: - name: varlog mountPath: /var/log diff --git a/content/en/examples/deployments/deployment-with-capacity-reservation.yaml b/content/en/examples/deployments/deployment-with-capacity-reservation.yaml index f70bed0111f58..7c88d11aacfb9 100644 --- a/content/en/examples/deployments/deployment-with-capacity-reservation.yaml +++ b/content/en/examples/deployments/deployment-with-capacity-reservation.yaml @@ -20,10 +20,12 @@ spec: # if possible podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - - labelSelector: - matchLabels: - app: placeholder - topologyKey: "kubernetes.io/hostname" + - weight: 100 + podAffinityTerm: + labelSelector: + matchLabels: + app.kubernetes.io/name: capacity-placeholder + topologyKey: topology.kubernetes.io/hostname containers: - name: pause image: registry.k8s.io/pause:3.6 diff --git a/content/hi/docs/tasks/inject-data-application/define-interdependent-environment-variables.md b/content/hi/docs/tasks/inject-data-application/define-interdependent-environment-variables.md new file mode 100644 index 0000000000000..14b93b2b1a248 --- /dev/null +++ b/content/hi/docs/tasks/inject-data-application/define-interdependent-environment-variables.md @@ -0,0 +1,80 @@ +--- +title: निर्भर एनवायरनमेंट वेरिएबल्स परिभाषित करें +content_type: task +weight: 20 +--- + + + +यह पृष्ठ दिखाता है कि कुबेरनेट्स पॉड में किसी कंटेनर के लिए निर्भर एनवायरनमेंट वेरिएबल्स कैसे परिभाषित करें। + +## {{% heading "prerequisites" %}} + +{{< include "task-tutorial-prereqs.md" >}} + + + + +## कंटेनर के लिए एक निर्भर एनवायरनमेंट वेरिएबल परिभाषित करें {#define-an-environment-dependent-variable-for-a-container} + +जब आप एक पॉड बनाते हैं, तो आप उसमें चलने वाले कंटेनरों के लिए निर्भर एनवायरनमेंट वेरिएबल्स सेट कर सकते हैं। निर्भर एनवायरनमेंट वेरिएबल्स सेट करने के लिए, आप कॉन्फ़िगरेशन फ़ाइल में `env` की `value` में $(VAR_NAME) का उपयोग कर सकते हैं। + +इस अभ्यास में, आप एक ऐसा पॉड बनाएंगे जो एक कंटेनर चलाता है। +पॉड के लिए कॉन्फ़िगरेशन फ़ाइल में एक निर्भर एनवायरनमेंट वेरिएबल्स परिभाषित किया गया है, जिसका सामान्य उपयोग निर्धारित किया गया है। +पॉड के लिए कॉन्फ़िगरेशन मैनिफेस्ट इस प्रकार है: + +{{% code_sample file="pods/inject/dependent-envars.yaml" %}} + +1. उस मैनिफेस्ट के आधार पर एक पॉड बनाएँ: + + ```shell + kubectl apply -f https://k8s.io/examples/pods/inject/dependent-envars.yaml + ``` + ``` + pod/dependent-envars-demo created + ``` + +2. चल रहे पॉड्स की सूची देखें: + + ```shell + kubectl get pods dependent-envars-demo + ``` + ``` + NAME READY STATUS RESTARTS AGE + dependent-envars-demo 1/1 Running 0 9s + ``` + +3. अपने पॉड में चल रहे कंटेनर के लॉग्स देखें: + + ```shell + kubectl logs pod/dependent-envars-demo + ``` + ``` + + UNCHANGED_REFERENCE=$(PROTOCOL)://172.17.0.1:80 + SERVICE_ADDRESS=https://172.17.0.1:80 + ESCAPED_REFERENCE=$(PROTOCOL)://172.17.0.1:80 + ``` + +जैसा कि ऊपर दिखाया गया है, आपने `SERVICE_ADDRESS` के लिए एक सही डिपेंडेंसी रेफरेंस, +`UNCHANGED_REFERENCE` के लिए एक गलत डिपेंडेंसी रेफरेंस, और `ESCAPED_REFERENCE` के लिए एक स्किप किया गया रेफरेंस परिभाषित किया है। + +जब कोई एनवायरनमेंट वेरिएबल पहले से परिभाषित होता है और उसका रेफरेंस दिया जाता है, +तो वह रेफरेंस सही तरीके से हल हो सकता है, जैसा कि `SERVICE_ADDRESS` के मामले में हुआ। + +ध्यान दें कि `env` सूची में क्रम महत्वपूर्ण होता है। +अगर कोई वेरिएबल सूची में नीचे परिभाषित है, तो उसे परिभाषित नहीं माना जाता। +इसी कारण से `UNCHANGED_REFERENCE` `$(PROTOCOL)` को हल करने में विफल रहता है। + +जब कोई एनवायरनमेंट वेरिएबल परिभाषित नहीं होता या उसमें कुछ वेरिएबल्स ही शामिल होते हैं, +तो वह वेरिएबल एक सामान्य स्ट्रिंग की तरह माना जाता है, जैसे कि `UNCHANGED_REFERENCE।` +ध्यान दें कि सामान्यतः गलत तरीके से पार्स किए गए एनवायरनमेंट वेरिएबल्स कंटेनर को शुरू होने से नहीं रोकते। + +`$(VAR_NAME)` सिंटैक्स को डबल `$`, जैसे `$$(VAR_NAME)` से एस्केप किया जा सकता है। +एस्केप किए गए रेफरेंस कभी भी विस्तारित नहीं होते, चाहे संबंधित वेरिएबल परिभाषित हो या नहीं। +यह `ESCAPED_REFERENCE` उदाहरण में देखा जा सकता है। + +## {{% heading "whatsnext" %}} + +* [एनवायरनमेंट वेरिएबल्स](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/) के बारे में और जानें। +* [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core) देखें। diff --git a/content/ja/docs/reference/glossary/service-account.md b/content/ja/docs/reference/glossary/service-account.md new file mode 100644 index 0000000000000..243c06cf7cb8e --- /dev/null +++ b/content/ja/docs/reference/glossary/service-account.md @@ -0,0 +1,19 @@ +--- +title: サービスアカウント +id: service-account +date: 2018-04-12 +full_link: /docs/tasks/configure-pod-container/configure-service-account/ +short_description: > + Pod内で動作するプロセスのアイデンティティを提供します。 + +aka: +tags: +- fundamental +- core-object +--- + {{< glossary_tooltip text="Pod" term_id="pod" >}}内で動作するプロセスのアイデンティティを提供します。 + + + +Pod内のプロセスがクラスターへアクセスする際、それらはAPIサーバーによって特定のサービスアカウント(例：`default`)として認証されます。 +Podを作成する際にサービスアカウントを指定しない場合、同じ{{< glossary_tooltip text="Namespace" term_id="namespace" >}}内のデフォルトのサービスアカウントが自動的に割り当てられます。 diff --git a/content/ja/docs/setup/production-environment/container-runtimes.md b/content/ja/docs/setup/production-environment/container-runtimes.md index a19b2a1dad452..4c7d2926ce940 100644 --- a/content/ja/docs/setup/production-environment/container-runtimes.md +++ b/content/ja/docs/setup/production-environment/container-runtimes.md @@ -269,13 +269,13 @@ pause_image="registry.k8s.io/pause:3.6" ### Mirantis Container Runtime {#mcr} -[Mirantis Container Runtime](https://docs.mirantis.com/mcr/20.10/overview.html)(MCR)は、 +[Mirantis Container Runtime](https://docs.mirantis.com/mcr/25.0/overview.html)(MCR)は、 以前はDocker Enterprise Editionとして知られていた、商業的に利用可能なコンテナランタイムです。 MCRに含まれるオープンソースの[`cri-dockerd`](https://github.com/Mirantis/cri-dockerd)コンポーネントを使用することで、 Mirantis Container RuntimeをKubernetesで使用することができます。 -Mirantis Container Runtimeのインストール方法について知るには、[MCRデプロイガイド](https://docs.mirantis.com/mcr/20.10/install.html)を参照してください。 +Mirantis Container Runtimeのインストール方法について知るには、[MCRデプロイガイド](https://docs.mirantis.com/mcr/25.0/install.html)を参照してください。 CRIソケットのパスを見つけるには、systemdの`cri-docker.socket`という名前のユニットを確認してください。 diff --git a/content/ja/docs/tasks/administer-cluster/kubelet-credential-provider.md b/content/ja/docs/tasks/administer-cluster/kubelet-credential-provider.md new file mode 100644 index 0000000000000..36ffa4551eb52 --- /dev/null +++ b/content/ja/docs/tasks/administer-cluster/kubelet-credential-provider.md @@ -0,0 +1,221 @@ +--- +title: kubelet image credential providerの設定 +content_type: task +min-kubernetes-server-version: v1.26 +weight: 120 +--- + +{{< feature-state for_k8s_version="v1.26" state="stable" >}} + + + +Kubernetes v1.20以降、kubeletはexecプラグインを使用してコンテナイメージレジストリへの認証情報を動的に取得できるようになりました。 +kubeletとexecプラグインは、Kubernetesのバージョン管理されたAPIを用いて標準入出力(stdin、stdout、stderr)を通じて通信します。 +これらのプラグインを使用することで、kubeletはディスク上に静的な認証情報を保存する代わりに、コンテナレジストリへの認証情報を動的に要求できるようになります。 +たとえば、プラグインがローカルのメタデータサーバーと通信し、kubeletが取得しようとしているイメージに対する、短期間有効な認証情報を取得することがあります。 + +以下のいずれかに該当する場合、この機能の利用を検討するとよいでしょう: + +* レジストリへの認証情報を取得するために、クラウドプロバイダーのサービスへのAPI呼び出しが必要である。 +* 認証情報の有効期限が短く、頻繁に新しい認証情報の取得が必要である。 +* 認証情報をディスク上やimagePullSecretsに保存することが許容されない。 + +このガイドでは、kubelet image credential providerプラグイン機構の設定方法について説明します。 + +## イメージ取得用のServiceAccountトークン +{{< feature-state feature_gate_name="KubeletServiceAccountTokenForCredentialProviders" >}} + +Kubernetes v1.33以降、kubeletは、イメージの取得を行っているPodにバインドされたサービスアカウントトークンを、credential providerプラグインに送信するように設定できます。 + +これにより、プラグインはそのトークンを使用して、イメージレジストリへのアクセスに必要な認証情報と交換することが可能になります。 + +この機能を有効化するには、kubeletで`KubeletServiceAccountTokenForCredentialProviders`フィーチャーゲートを有効化し、プラグイン用の`CredentialProviderConfig`ファイルで`tokenAttributes`フィールドを設定する必要があります。 + +`tokenAttributes`フィールドには、プラグインに渡されるサービスアカウントトークンに関する情報が含まれており、トークンの対象となるオーディエンスや、プラグインがPodにサービスアカウントを必要とするかどうかといった内容が指定されます。 + +サービスアカウントトークンによる認証情報を用いることで、次のようなユースケースに対応できます: + +* レジストリからイメージを取得するために、kubeletやノードに基づくアイデンティティを必要としないようにする +* 長期間有効なシークレットや永続的なシークレットを使用せずに、ワークロードが自身のランタイムのアイデンティティに基づいてイメージを取得できるようにする + +## {{% heading "prerequisites" %}} + +* kubelet credential providerプラグインをサポートするノードを持つKubernetesクラスターが必要です。このサポートは、Kubernetes {{< skew currentVersion >}}で利用可能です。Kubernetes v1.24およびv1.25で、デフォルトで有効なベータ機能として含まれるようになりました。 +* サービスアカウントトークンを必要とするcredential providerプラグインを設定する場合は、Kubernetes v1.33以降を実行しているノードを持つクラスターと、kubelet上で`KubeletServiceAccountTokenForCredentialProviders`フィーチャーゲートが有効になっている必要があります。 +* credential provider execプラグインの動作する実装。独自にプラグインを作成するか、クラウドプロバイダーが提供するものを使用できます。 + +{{< version-check >}} + + + +## ノードへのプラグインのインストール + +credential providerプラグインは、kubeletによって実行される実行可能バイナリです。 +クラスター内のすべてのノードにこのプラグインバイナリが存在し、既知のディレクトリに配置されていることを確認してください。 +このディレクトリは、後でkubeletのフラグを設定する際に必要です。 + +## kubeletの設定 + +この機能を使用するには、kubeletに次の2つのフラグを設定する必要があります: + +* `--image-credential-provider-config` - credential providerプラグインの設定ファイルへのパス +* `--image-credential-provider-bin-dir` - credential providerプラグインのバイナリが配置されているディレクトリへのパス + +### kubelet credential providerを設定する + +`--image-credential-provider-config`に指定された設定ファイルは、どのコンテナイメージに対してどのexecプラグインを呼び出すかを判断するためにkubeletによって読み込まれます。 +以下は、[ECRベースのプラグイン](https://github.com/kubernetes/cloud-provider-aws/tree/master/cmd/ecr-credential-provider)を使用する場合に利用される可能性がある設定ファイルの例です。 + +```yaml +apiVersion: kubelet.config.k8s.io/v1 +kind: CredentialProviderConfig +# providersは、kubeletによって有効化されるcredential provider補助プラグインのリストです。 +# 単一のイメージに対して複数のプロバイダーが一致する場合、すべてのプロバイダーからの認証情報がkubeletに返されます。 +# 単一のイメージに対して複数のプロバイダーが呼び出されると、結果は結合されます。 +# 認証キーが重複する場合は、このリスト内で先に定義されたプロバイダーの値が使用されます。 +providers: + # nameはcredential providerの名前で必須項目です。kubeletから見えるプロバイダーの実行可能ファイル名と一致している必要があります。 + # 実行可能ファイルは、kubeletのbinディレクトリ(--image-credential-provider-bin-dirフラグで指定)内に存在しなければなりません。 + - name: ecr-credential-provider + # matchImagesは必須の文字列リストで、イメージに対して一致判定を行い、 + # このプロバイダーを呼び出すべきかどうかを判断するために使用されます。 + # 指定された文字列のいずれか1つが、kubeletから要求されたイメージに一致した場合、 + # プラグインが呼び出され、認証情報を提供する機会が与えられます。 + # イメージには、レジストリのドメインおよびURLパスが含まれている必要があります。 + # + # matchImagesの各エントリは、オプションでポートおよびパスを含むことができるパターンです。 + # ドメインにはグロブを使用できますが、ポートやパスには使用できません。 + # グロブは、'*.k8s.io'や'k8s.*.io'のようなサブドメインや、'k8s.*'のようなトップレベルドメインでサポートされています。 + # 'app*.k8s.io'のような部分的なサブドメインの一致もサポートされています。 + # 各グロブはサブドメインの1セグメントのみに一致するため、`*.io`は`*.k8s.io`には**一致しません**。 + # + # イメージとmatchImageが一致すると見なされるのは、以下のすべての条件を満たす場合です: + # - 双方が同じ数のドメインパートを含み、各パートが一致していること + # - matchImagesに指定されたURLパスが、対象のイメージURLパスのプレフィックスであること + # - matchImagesにポートが含まれている場合、そのポートがイメージのポートにも一致すること + # + # matchImagesの値の例: + # - 123456789.dkr.ecr.us-east-1.amazonaws.com + # - *.azurecr.io + # - gcr.io + # - *.*.registry.io + # - registry.io:8080/path + matchImages: + - "*.dkr.ecr.*.amazonaws.com" + - "*.dkr.ecr.*.amazonaws.com.cn" + - "*.dkr.ecr-fips.*.amazonaws.com" + - "*.dkr.ecr.us-iso-east-1.c2s.ic.gov" + - "*.dkr.ecr.us-isob-east-1.sc2s.sgov.gov" + # defaultCacheDurationは、プラグインの応答にキャッシュ期間が指定されていない場合に、 + # プラグインが認証情報をメモリ内でキャッシュするデフォルトの期間です。このフィールドは必須です。 + defaultCacheDuration: "12h" + # exec CredentialProviderRequestの入力に必要なバージョンです。返されるCredentialProviderResponseは、 + # 入力と同じエンコーディングバージョンを使用しなければなりません。現在サポートされている値は以下のとおりです: + # - credentialprovider.kubelet.k8s.io/v1 + apiVersion: credentialprovider.kubelet.k8s.io/v1 + # コマンドを実行する際に渡す引数です。 + # +optional + # args: + # - --example-argument + # envは、プロセスに対して公開する追加の環境変数を定義します。 + # これらはホストの環境変数および、client-goがプラグインに引数を渡すために使用する変数と結合されます。 + # +optional + env: + - name: AWS_PROFILE + value: example_profile + + # tokenAttributesは、プラグインに渡されるサービスアカウントトークンの設定です。 + # このフィールドを設定することで、credential providerはイメージの取得にサービスアカウントトークンを使用するようになります。 + # このフィールドが設定されているにも関わらず、`KubeletServiceAccountTokenForCredentialProviders`フィーチャーゲートが有効になっていない場合、 + # kubeletは無効な設定エラーとして起動に失敗します。 + # +optional + tokenAttributes: + # serviceAccountTokenAudienceは、投影されたサービスアカウントトークンの対象となるオーディエンスです。 + # +required + serviceAccountTokenAudience: "" + # requireServiceAccountは、プラグインがPodにサービスアカウントを必要とするかどうかを示します。 + # trueに設定された場合、kubeletはPodにサービスアカウントがある場合にのみプラグインを呼び出します。 + # falseに設定された場合、Podにサービスアカウントがなくてもkubeletはプラグインを呼び出し、 + # CredentialProviderRequestにはトークンを含めません。これは、サービスアカウントを持たないPod + # (たとえば、Static Pod)に対してイメージを取得するためのプラグインに有用です。 + # +required + requireServiceAccount: true + # requiredServiceAccountAnnotationKeysは、プラグインが対象とし、サービスアカウントに存在する必要があるアノテーションキーのリストです。 + # このリストに定義されたキーは、対応するサービスアカウントから抽出され、CredentialProviderRequestの一部としてプラグインに渡されます。 + # このリストに定義されたキーのいずれかがサービスアカウントに存在しない場合、kubeletはプラグインを呼び出さず、エラーを返します。 + # このフィールドはオプションであり、空であっても構いません。プラグインはこのフィールドを使用して、 + # 認証情報の取得に必要な追加情報を抽出したり、サービスアカウントトークンによるイメージ取得の利用を + # ワークロード側で選択可能にしたりできます。 + # このフィールドが空でない場合、requireServiceAccountはtrueに設定されていなければなりません。 + # このリストに定義されたキーは一意である必要があり、 + # optionalServiceAccountAnnotationKeysリストに定義されたキーと重複してはいけません。 + # +optional + requiredServiceAccountAnnotationKeys: + - "example.com/required-annotation-key-1" + - "example.com/required-annotation-key-2" + # optionalServiceAccountAnnotationKeysは、プラグインが対象とするアノテーションキーのリストで、 + # サービスアカウントに存在していなくてもよいオプションの項目です。 + # このリストに定義されたキーは、対応するサービスアカウントから抽出され、 + # CredentialProviderRequestの一部としてプラグインに渡されます。 + # アノテーションの存在や値の検証はプラグイン側の責任です。 + # このフィールドはオプションであり、空でも構いません。 + # プラグインはこのフィールドを使用して、認証情報の取得に必要な追加情報を抽出できます。 + # このリストに定義されたキーは一意でなければならず、 + # requiredServiceAccountAnnotationKeysリストに定義されたキーと重複してはいけません。 + # +optional + optionalServiceAccountAnnotationKeys: + - "example.com/optional-annotation-key-1" + - "example.com/optional-annotation-key-2" +``` + +`providers`フィールドは、kubeletが使用する有効なプラグインのリストです。 +各エントリには、いくつかの入力必須のフィールドがあります: + +* `name`: プラグインの名前であり、`--image-credential-provider-bin-dir`で指定されたディレクトリ内に存在する実行可能バイナリの名前と一致していなければなりません。 +* `matchImages`: このプロバイダーを呼び出すべきかどうかを判断するために、イメージと照合するための文字列リスト。詳細は後述します。 +* `defaultCacheDuration`: プラグインによってキャッシュ期間が指定されていない場合に、kubeletが認証情報をメモリ内にキャッシュするデフォルトの期間。 +* `apiVersion`: kubeletとexecプラグインが通信時に使用するAPIバージョン。 + +各credential providerには、オプションの引数や環境変数を指定することもできます。 +特定のプラグインで必要となる引数や環境変数のセットについては、プラグインの実装者に確認してください。 + +KubeletServiceAccountTokenForCredentialProvidersフィーチャーゲートを使用し、tokenAttributesフィールドを設定してプラグインにサービスアカウントトークンを使用させる場合、以下のフィールドの設定が必須となります: + +* `serviceAccountTokenAudience`: + 投影されたサービスアカウントトークンの対象となるオーディエンス。 + 空文字列は指定できません。 + +* `requireServiceAccount`: + プラグインがPodにサービスアカウントを必要とするかどうか。 + * `true`に設定すると、Podにサービスアカウントがある場合にのみkubeletはプラグインを呼び出します。 + * `false`に設定すると、Podにサービスアカウントがなくてもkubeletはプラグインを呼び出し、`CredentialProviderRequest`にはトークンを含めません。 + +これは、サービスアカウントを持たないPod(たとえば、Static Pod)に対してイメージを取得するためのプラグインに有用です。 + +#### イメージのマッチングを設定する + +各credential providerの`matchImages`フィールドは、Podが使用する特定のイメージに対してプラグインを呼び出すべきかどうかを、kubeletが判断するために使用されます。 +`matchImages`の各エントリはイメージパターンであり、オプションでポートやパスを含めることができます。 +ドメインにはグロブを使用できますが、ポートやパスには使用できません。 +グロブは、`*.k8s.io`や`k8s.*.io`のようなサブドメインや、`k8s.*`のようなトップレベルドメインで使用可能です。 +`app*.k8s.io`のような部分的なサブドメインの一致もサポートされています。 +ただし、各グロブは1つのサブドメインセグメントにしか一致しないため、`*.io`は`*.k8s.io`には一致しません。 + +イメージ名と`matchImage`エントリが一致すると見なされるのは、以下のすべての条件を満たす場合です: + +* 両者が同じ数のドメインパートを持ち、それぞれのパートが一致していること。 +* イメージの一致条件として指定されたURLパスが、対象のイメージのURLパスのプレフィックスであること。 +* matchImagesにポートが含まれている場合、イメージのポートとも一致すること。 + +`matchImages`パターンの値のいくつかの例: + +* `123456789.dkr.ecr.us-east-1.amazonaws.com` +* `*.azurecr.io` +* `gcr.io` +* `*.*.registry.io` +* `foo.registry.io:8080/path` + +## {{% heading "whatsnext" %}} + +* `CredentialProviderConfig`の詳細については、[kubelet設定API(v1)リファレンス](/docs/reference/config-api/kubelet-config.v1/)を参照してください。 +* [kubelet credential provider APIリファレンス(v1)](/docs/reference/config-api/kubelet-credentialprovider.v1/)を参照してください。 diff --git a/content/ko/docs/tasks/tools/included/optional-kubectl-configs-bash-mac.md b/content/ko/docs/tasks/tools/included/optional-kubectl-configs-bash-mac.md index a9a66a63c8346..7e06e34445809 100644 --- a/content/ko/docs/tasks/tools/included/optional-kubectl-configs-bash-mac.md +++ b/content/ko/docs/tasks/tools/included/optional-kubectl-configs-bash-mac.md @@ -11,7 +11,7 @@ Bash의 kubectl 자동 완성 스크립트는 `kubectl completion bash` 로 생 그러나 kubectl 자동 완성 스크립트는 미리 [**bash-completion**](https://github.com/scop/bash-completion)을 설치해야 동작한다. {{< warning>}} -bash-completion에는 v1과 v2 두 가지 버전이 있다. v1은 Bash 3.2(macOS의 기본 설치 버전) 버전용이고, v2는 Bash 4.1 이상 버전용이다. kubectl 자동 완성 스크립트는 bash-completion v1과 Bash 3.2 버전에서는 **작동하지 않는다**. **bash-completion v2** 와 **Bash 4.1 이상 버전** 이 필요하다. 따라서, macOS에서 kubectl 자동 완성 기능을 올바르게 사용하려면, Bash 4.1 이상을 설치하고 사용해야 한다([*지침*](https://itnext.io/upgrading-bash-on-macos-7138bd1066ba)). 다음의 내용에서는 Bash 4.1 이상(즉, 모든 Bash 버전 4.1 이상)을 사용한다고 가정한다. +bash-completion에는 v1과 v2 두 가지 버전이 있다. v1은 Bash 3.2(macOS의 기본 설치 버전) 버전용이고, v2는 Bash 4.1 이상 버전용이다. kubectl 자동 완성 스크립트는 bash-completion v1과 Bash 3.2 버전에서는 **작동하지 않는다**. **bash-completion v2** 와 **Bash 4.1 이상 버전** 이 필요하다. 따라서, macOS에서 kubectl 자동 완성 기능을 올바르게 사용하려면, Bash 4.1 이상을 설치하고 사용해야 한다([*지침*](https://apple.stackexchange.com/a/292760)). 다음의 내용에서는 Bash 4.1 이상(즉, 모든 Bash 버전 4.1 이상)을 사용한다고 가정한다. {{< /warning >}} ### Bash 업그레이드 diff --git a/content/pl/docs/reference/glossary/kubelet.md b/content/pl/docs/reference/glossary/kubelet.md index 11cc49024d1e3..f8538e974b339 100644 --- a/content/pl/docs/reference/glossary/kubelet.md +++ b/content/pl/docs/reference/glossary/kubelet.md @@ -2,7 +2,7 @@ title: Kubelet id: kubelet date: 2018-04-12 -full_link: /docs/reference/generated/kubelet +full_link: /docs/reference/command-line-tools-reference/kubelet short_description: > Agent, który działa na każdym węźle klastra. Odpowiada za uruchamianie kontenerów w ramach poda. diff --git a/content/pt-br/docs/concepts/windows/intro.md b/content/pt-br/docs/concepts/windows/intro.md index caa5f04f18f39..f819ed3009a2f 100644 --- a/content/pt-br/docs/concepts/windows/intro.md +++ b/content/pt-br/docs/concepts/windows/intro.md @@ -208,7 +208,7 @@ Há uma [limitação conhecida](pt-br/docs/tasks/configure-pod-container/configu ### Mirantis Contêiner Runtime {#mcr} -[Mirantis Container Runtime](https://docs.mirantis.com/mcr/20.10/overview.html) (MCR) está disponível como um agente de execução de contêiner para todas as versões do Windows Server 2019 e posteriores. +[Mirantis Container Runtime](https://docs.mirantis.com/mcr/25.0/overview.html) (MCR) está disponível como um agente de execução de contêiner para todas as versões do Windows Server 2019 e posteriores. Veja [Instalar MCR em servidores Windows](https://docs.mirantis.com/mcr/20.10/install/mcr-windows.html) para mais informações. diff --git a/content/pt-br/docs/tasks/run-application/delete-stateful-set.md b/content/pt-br/docs/tasks/run-application/delete-stateful-set.md new file mode 100644 index 0000000000000..ab3283fd3e567 --- /dev/null +++ b/content/pt-br/docs/tasks/run-application/delete-stateful-set.md @@ -0,0 +1,87 @@ +--- +title: Deletar um StatefulSet +content_type: task +weight: 60 +--- + + + +Esta tarefa mostra como deletar um {{< glossary_tooltip term_id="StatefulSet" >}}. + +## {{% heading "prerequisites" %}} + +- Esta tarefa assume que você tem uma aplicação em execução no seu cluster representada por um StatefulSet. + + + +## Deletando um StatefulSet + +Você pode deletar um StatefulSet da mesma forma que deleta outros recursos no Kubernetes: +use o comando `kubectl delete` e especifique o StatefulSet pelo arquivo ou pelo nome. + +```shell +kubectl delete -f +``` + +```shell +kubectl delete statefulsets +``` + +Pode ser necessário deletar o serviço headless associado separadamente após o próprio StatefulSet ser deletado. + +```shell +kubectl delete service +``` + +Ao deletar um StatefulSet usando o `kubectl`, o StatefulSet é escalonado para 0. +Todos os Pods que fazem parte dessa carga de trabalho também são deletados. +Se você quiser deletar apenas o StatefulSet e não os Pods, use `--cascade=orphan`. Por exemplo: + +```shell +kubectl delete -f --cascade=orphan +``` + +Ao passar `--cascade=orphan` para o `kubectl delete`, os Pods gerenciados pelo StatefulSet permanecem mesmo após o objeto StatefulSet ser deletado. +Se os Pods tiverem o rótulo `app.kubernetes.io/name=MyApp`, você pode deletá-los da seguinte forma: + +```shell +kubectl delete pods -l app.kubernetes.io/name=MyApp +``` + +### Volumes Persistentes + +Deletar os Pods em um StatefulSet não deleta os volumes associados. +Isso garante que você tenha a chance de copiar os dados do volume antes de deletá-lo. +Deletar o PVC após os pods terem sido finalizados pode acionar a exclusão dos Volumes Persistentes de suporte, dependendo da classe de +armazenamento e da política de retenção. +Você nunca deve assumir que será possível acessar um volume após a exclusão da requisição (claim). + +{{< note >}} +Tenha cautela ao deletar um PVC, pois isso pode levar à perda de dados. +{{< /note >}} + +### Exclusão completa de um StatefulSet + +Para deletar tudo em um StatefulSet, incluindo os pods associados, +você pode executar uma série de comandos semelhantes aos seguintes: + +```shell +grace=$(kubectl get pods --template '{{.spec.terminationGracePeriodSeconds}}') +kubectl delete statefulset -l app.kubernetes.io/name=MyApp +sleep $grace +kubectl delete pvc -l app.kubernetes.io/name=MyApp + +``` + +No exemplo acima, os Pods possuem o rótulo `app.kubernetes.io/name=MyApp`; +substitua pelo seu próprio rótulo, conforme apropriado. + +### Forçar a exclusão de pods de um StatefulSet + +Se você perceber que alguns pods no seu StatefulSet estão presos nos estados 'Terminating' ou 'Unknown' por um longo período de tempo, pode ser +necessário intervir manualmente para forçar a exclusão dos pods do servidor de API. +Esta é uma tarefa potencialmente perigosa. Consulte [Forçar a exclusão de pods de um StatefulSet](/docs/tasks/run-application/force-delete-stateful-set-pod/) para mais detalhes. + +## {{% heading "whatsnext" %}} + +Saiba mais sobre [como forçar a exclusão de pods de um StatefulSet](/docs/tasks/run-application/force-delete-stateful-set-pod/). diff --git a/content/vi/docs/tasks/tools/install-kubectl.md b/content/vi/docs/tasks/tools/install-kubectl.md index 60ac29eca99ad..8e5c4eb39628d 100644 --- a/content/vi/docs/tasks/tools/install-kubectl.md +++ b/content/vi/docs/tasks/tools/install-kubectl.md @@ -378,7 +378,7 @@ Kubectl completion script trên Bash được tạo ra bởi `kubectl completion Tuy nhiên, kubectl completion script phụ thuộc vào [**bash-completion**](https://github.com/scop/bash-completion) mà bạn cài trước đó. {{< warning>}} -Có 2 phiên bản của bash-completion là v1 và v2. V1 dành cho Bash 3.2 (Bash mặc định trên macOS), và v2 dành cho Bash 4.1+. Kubectl completion script **không làm việc** phù hợp với bash-completion v1 và Bash 3.2. Nó tương thích với **bash-completion v2** và **Bash 4.1+**. Vì vậy, để sử dụng kubectl completion một cách chính xác trên macOS thì bạn phải cài đặt Bash 4.1+ ([*hướng dẫn*](https://itnext.io/upgrading-bash-on-macos-7138bd1066ba)). Hướng dẫn tiếp theo giả định rằng bạn đang sử dụng Bash 4.1+ (nghĩa là, bất kỳ phiên bản Bash nào từ 4.1 trở lên). +Có 2 phiên bản của bash-completion là v1 và v2. V1 dành cho Bash 3.2 (Bash mặc định trên macOS), và v2 dành cho Bash 4.1+. Kubectl completion script **không làm việc** phù hợp với bash-completion v1 và Bash 3.2. Nó tương thích với **bash-completion v2** và **Bash 4.1+**. Vì vậy, để sử dụng kubectl completion một cách chính xác trên macOS thì bạn phải cài đặt Bash 4.1+ ([*hướng dẫn*](https://apple.stackexchange.com/a/292760)). Hướng dẫn tiếp theo giả định rằng bạn đang sử dụng Bash 4.1+ (nghĩa là, bất kỳ phiên bản Bash nào từ 4.1 trở lên). {{< /warning >}} diff --git a/content/zh-cn/README.md b/content/zh-cn/README.md index 35e827c66ccc4..71fe525bbbbd0 100644 --- a/content/zh-cn/README.md +++ b/content/zh-cn/README.md @@ -1,5 +1,4 @@ # Kubernetes 文档 - @@ -117,17 +116,37 @@ To build the site in a container, run the following: ```bash # 你可以将 $CONTAINER_ENGINE 设置为任何 Docker 类容器工具的名称 + +# 渲染整个网站 make container-serve + +# 仅渲染特定语言（例如英语） +make container-serve segments=en + +# 渲染多种语言（例如英语和韩语） +make container-serve segments=en,ko ``` +**💡 提示：**使用 **Hugo 分段机制**可以加快本地预览构建速度，因为它只渲染选定的语言。 + 如果你看到错误，这可能意味着 Hugo 容器没有足够的可用计算资源。 要解决这个问题，请增加机器（[MacOS](https://docs.docker.com/desktop/settings/mac/) 和 [Windows](https://docs.docker.com/desktop/settings/windows/)）上 @@ -153,10 +172,38 @@ To install dependencies, deploy and test the site locally, run: --> - 对于 macOS 和 Linux + + + ```bash + npm ci + + # 渲染整个网站（默认） + make serve + + # 仅渲染特定语言 + make serve segments=en + + # 渲染多种语言 + make serve segments=en,ko + ``` + + +**💡 提示：** Hugo 分段在 `hugo.toml` 中定义，通过将渲染范围限定为特定语言，可以加快构建速度。 -Kubernetes 会在内部创建一个 Node 对象作为节点的表示。Kubernetes 检查 `kubelet` +Kubernetes 会在内部创建一个 Node 对象作为节点的表示。Kubernetes 检查 kubelet 向 API 服务器注册节点时使用的 `metadata.name` 字段是否匹配。 如果节点是健康的（即所有必要的服务都在运行中），则该节点可以用来运行 Pod。 否则，直到该节点变为健康之前，所有的集群活动都会忽略该节点。 @@ -536,7 +536,7 @@ Kubernetes {{< glossary_tooltip text="调度器" term_id="kube-scheduler" >}} 保证节点上有足够的资源供其上的所有 Pod 使用。 它会检查节点上所有容器的请求的总和不会超过节点的容量。 总的请求包括由 kubelet 启动的所有容器，但不包括由容器运行时直接启动的容器， -也不包括不受 `kubelet` 控制的其他进程。 +也不包括不受 kubelet 控制的其他进程。 {{< note >}} 如果启用了 `TopologyManager` [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)， -`kubelet` 可以在作出资源分配决策时使用拓扑提示。 +kubelet 可以在作出资源分配决策时使用拓扑提示。 参考[控制节点上拓扑管理策略](/zh-cn/docs/tasks/administer-cluster/topology-manager/)了解详细信息。 - -## 交换内存（swap）管理 {#swap-memory} - -{{< feature-state feature_gate_name="NodeSwap" >}} - - -要在节点上启用交换内存，必须启用 kubelet 的 `NodeSwap` 特性门控（默认启用）， -同时使用 `--fail-swap-on` 命令行参数或者将 `failSwapOn` -[配置](/zh-cn/docs/reference/config-api/kubelet-config.v1beta1/)设置为 false。 -为了允许 Pod 使用交换内存，在 kubelet 配置中不应将 `swapBehavior` 设置为 `NoSwap`（默认行为）。 - -{{< warning >}} - -当内存交换功能被启用后，Kubernetes 数据（如写入 tmpfs 的 Secret 对象的内容）可以被交换到磁盘。 -{{< /warning >}} - - -用户还可以选择配置 `memorySwap.swapBehavior` 以指定节点使用交换内存的方式。例如： - -```yaml -memorySwap: - swapBehavior: LimitedSwap -``` - - -- `NoSwap`（默认）：Kubernetes 工作负载不会使用交换内存。 -- `LimitedSwap`：Kubernetes 工作负载对交换内存的使用受到限制。 - 只有具有 Burstable QoS 的 Pod 可以使用交换内存。 - - -如果启用了特性门控但是未指定 `memorySwap` 的配置，默认情况下 kubelet 将使用与 -`NoSwap` 设置相同的行为。 - - -采用 `LimitedSwap` 时，不属于 Burstable QoS 分类的 Pod -（即 `BestEffort`/`Guaranteed` QoS Pod） -被禁止使用交换内存。为了保持上述的安全性和节点健康性保证， -在 `LimitedSwap` 生效时，不允许这些 Pod 使用交换内存。 - - -在详细介绍交换限制的计算之前，有必要定义以下术语： - -* `nodeTotalMemory`：节点上可用的物理内存总量。 -* `totalPodsSwapAvailable`：节点上可供 Pod 使用的交换内存总量 - （一些交换内存可能被保留由系统使用）。 -* `containerMemoryRequest`：容器的内存请求。 - - -交换内存限制被配置为 `(containerMemoryRequest / nodeTotalMemory) * totalPodsSwapAvailable` 的值。 - -需要注意的是，位于 Burstable QoS Pod 中的容器可以通过将内存请求设置为与内存限制相同来选择不使用交换内存。 -以这种方式配置的容器将无法访问交换内存。 - - -只有 **Cgroup v2** 支持交换内存，Cgroup v1 不支持。 - -如需了解更多信息、协助测试和提交反馈，请参阅关于 -[Kubernetes 1.28：NodeSwap 进阶至 Beta1](/zh-cn/blog/2023/08/24/swap-linux-beta/) 的博客文章、 -[KEP-2400](https://github.com/kubernetes/enhancements/issues/4128) -及其[设计提案](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/2400-node-swap/README.md)。 - ## {{% heading "whatsnext" %}} ## 初衷 {#motivation} -**Operator 模式** 旨在记述（正在管理一个或一组服务的）运维人员的关键目标。 +**Operator 模式**旨在记述（正在管理一个或一组服务的）运维人员的关键目标。 这些运维人员负责一些特定的应用和 Service，他们需要清楚地知道系统应该如何运行、如何部署以及出现问题时如何处理。 在 Kubernetes 上运行工作负载的人们都喜欢通过自动化来处理重复的任务。 @@ -61,7 +60,7 @@ controllers for a [Custom Resource](/docs/concepts/extend-kubernetes/api-extensi ## Kubernetes 上的 Operator {#operators-in-kubernetes} Kubernetes 为自动化而生。无需任何修改，你即可以从 Kubernetes 核心中获得许多内置的自动化功能。 -你可以使用 Kubernetes 自动化部署和运行工作负载，**甚至** 可以自动化 Kubernetes 自身。 +你可以使用 Kubernetes 自动化部署和运行工作负载，**甚至**可以自动化 Kubernetes 自身。 Kubernetes 的 {{< glossary_tooltip text="Operator 模式" term_id="operator-pattern" >}}概念允许你在不修改 Kubernetes 自身代码的情况下， @@ -120,7 +119,6 @@ What might an operator look like in more detail? Here's an example: code checks to see if the database is running an old version and, if so, creates Job objects that upgrade it for you. --> - 想要更详细的了解 Operator？下面是一个示例： 1. 有一个名为 SampleDB 的自定义资源，你可以将其配置到集群中。 @@ -196,7 +194,6 @@ want, you can code your own. You also implement an operator (that is, a Controller) using any language / runtime that can act as a [client for the Kubernetes API](/docs/reference/using-api/client-libraries/). --> - 如果生态系统中没有可以实现你目标的 Operator，你可以自己编写代码。 你还可以使用任何支持 @@ -217,22 +214,22 @@ operator. * [Kopf](https://github.com/nolar/kopf) (Kubernetes Operator Pythonic Framework) * [kube-rs](https://kube.rs/) (Rust) * [kubebuilder](https://book.kubebuilder.io/) -* [KubeOps](https://buehler.github.io/dotnet-operator-sdk/) (.NET operator SDK) +* [KubeOps](https://dotnet.github.io/dotnet-operator-sdk/) (.NET operator SDK) * [Mast](https://docs.ansi.services/mast/user_guide/operator/) * [Metacontroller](https://metacontroller.github.io/metacontroller/intro.html) along with WebHooks that you implement yourself * [Operator Framework](https://operatorframework.io) * [shell-operator](https://github.com/flant/shell-operator) --> - * [Charmed Operator Framework](https://juju.is/) * [Java Operator SDK](https://github.com/operator-framework/java-operator-sdk) * [Kopf](https://github.com/nolar/kopf) (Kubernetes Operator Pythonic Framework) * [kube-rs](https://kube.rs/) (Rust) * [kubebuilder](https://book.kubebuilder.io/) -* [KubeOps](https://buehler.github.io/dotnet-operator-sdk/) (.NET operator SDK) +* [KubeOps](https://dotnet.github.io/dotnet-operator-sdk/) (.NET operator SDK) * [Mast](https://docs.ansi.services/mast/user_guide/operator/) -* [Metacontroller](https://metacontroller.github.io/metacontroller/intro.html)，可与 Webhook 结合使用，以实现自己的功能。 +* [Metacontroller](https://metacontroller.github.io/metacontroller/intro.html)，可与 + Webhook 结合使用，以实现自己的功能。 * [Operator Framework](https://operatorframework.io) * [shell-operator](https://github.com/flant/shell-operator) @@ -249,7 +246,6 @@ operator. * Read an [article](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps) from Google Cloud about best practices for building operators --> - * 阅读 {{< glossary_tooltip text="CNCF" term_id="cncf" >}} [Operator 白皮书](https://github.com/cncf/tag-app-delivery/blob/163962c4b1cd70d085107fc579e3e04c2e14d59c/operator-wg/whitepaper/Operator-WhitePaper_v1-0.md)。 * 详细了解[定制资源](/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources/) * 在 [OperatorHub.io](https://operatorhub.io/) 上找到现成的、适合你的 Operator diff --git a/content/zh-cn/docs/concepts/security/linux-security.md b/content/zh-cn/docs/concepts/security/linux-security.md new file mode 100644 index 0000000000000..c468c7c0c0421 --- /dev/null +++ b/content/zh-cn/docs/concepts/security/linux-security.md @@ -0,0 +1,57 @@ +--- +title: Linux 节点的安全性 +content_type: concept +weight: 40 +--- + + + + + +本篇介绍特定于 Linux 操作系统的安全注意事项和最佳实践。 + + + + +## 保护节点上的 Secret 数据 {#protection-for-secret-data-on-nodes} + + +在 Linux 节点上，由内存支持的卷（例如 [`secret`](/zh-cn/docs/concepts/configuration/secret/) +卷挂载，或带有 `medium: Memory` 的 [`emptyDir`](/zh-cn/docs/concepts/storage/volumes/#emptydir)） +使用 `tmpfs` 文件系统实现。 + + +如果你配置了交换分区并且使用较旧的 Linux 内核（或者内核是最新的，但其中某项配置是 Kubernetes 所不支持的）， +**内存**支持的卷可能会将数据写入持久存储。 + + +Linux 内核从 6.3 版本开始正式支持 `noswap` 选项， +因此建议使用 6.3 或更新版本的内核， +或者如果节点上启用了交换分区，确保内核通过补丁向下移植支持 `noswap` 选项。 + + +更多信息参阅[交换内存管理](/zh-cn/docs/concepts/cluster-administration/swap-memory-management/#memory-backed-volumes)。 diff --git a/content/zh-cn/docs/concepts/security/secrets-good-practices.md b/content/zh-cn/docs/concepts/security/secrets-good-practices.md index e822d640c07d0..f7378f6ae36b9 100644 --- a/content/zh-cn/docs/concepts/security/secrets-good-practices.md +++ b/content/zh-cn/docs/concepts/security/secrets-good-practices.md @@ -161,6 +161,17 @@ For a list of supported providers, refer to 有关支持的提供商列表，请参阅 [Secret 存储 CSI 驱动的提供商](https://secrets-store-csi-driver.sigs.k8s.io/concepts.html#provider-for-the-secrets-store-csi-driver)。 + +## 使用交换内存的良好实践 {#good-practices-for-using-swap-memory} + +对于为 Linux 节点设置交换内存的最佳实践， +请参阅[交换内存管理](/zh-cn/docs/concepts/cluster-administration/swap-memory-management/#good-practice-for-using-swap-in-a-kubernetes-cluster)。 + -概括起来，命名空间 _test_ 中的 Pod 可以成功地解析 `data.prod` 或者 +概括起来，命名空间 **test** 中的 Pod 可以成功地解析 `data.prod` 或者 `data.prod.svc.cluster.local`。 #### SRV 记录 {#srv-records} @@ -193,39 +192,49 @@ Kubernetes 根据普通 Service 或无头 Service 中的命名端口创建 SRV Kube-DNS versions, prior to the implementation of the [DNS specification](https://github.com/kubernetes/dns/blob/master/docs/specification.md), had the following DNS resolution: +--> +### A/AAAA 记录 {#a-aaaa-records} + +在实现 [DNS 规范](https://github.com/kubernetes/dns/blob/master/docs/specification.md)之前， +Kube-DNS 版本使用以下 DNS 解析： ``` -pod-ipv4-address.my-namespace.pod.cluster-domain.example +..pod. ``` + +例如，对于一个位于 `default` 命名空间，IP 地址为 172.17.0.3 的 Pod， +如果集群的域名为 `cluster.local`，则 Pod 会对应 DNS 名称： ``` 172-17-0-3.default.pod.cluster.local ``` + +一些集群 DNS 机制（如 [CoreDNS](https://coredns.io/)）还会为以下内容提供 `A` 记录： ``` ...svc. ``` ---> -### A/AAAA 记录 {#a-aaaa-records} - -在实现 [DNS 规范](https://github.com/kubernetes/dns/blob/master/docs/specification.md)之前， -Kube-DNS 版本使用以下 DNS 解析： -`pod-ipv4-address.my-namespace.pod.cluster-domain.example` - -例如，对于一个位于 `default` 命名空间，IP 地址为 172.17.0.3 的 Pod， -如果集群的域名为 `cluster.local`，则 Pod 会对应 DNS 名称： - -`172-17-0-3.default.pod.cluster.local` - -一些集群 DNS 机制（如 [CoreDNS](https://coredns.io/)）还会为以下内容提供 `A` 记录： + +例如，如果 `cafe` 命名空间中的一个 Pod 拥有 IP 地址 +172.17.0.3（是名为 `barista` 的服务的端点）， +并且集群的域名是 `cluster.local`， +那么此 Pod 将拥有这样的服务范围的 DNS A 记录： -`...svc..` +``` +172-17-0-3.barista.cafe.svc.cluster.local +``` ```yaml apiVersion: v1 kind: Service @@ -328,8 +384,8 @@ to `"busybox-subdomain"`, the first Pod will see its own FQDN as 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. --> -鉴于上述服务 `“busybox-subdomain”` 和将 `spec.subdomain` 设置为 `“busybox-subdomain”` 的 Pod， -第一个 Pod 将看到自己的 FQDN 为 `“busybox-1.busybox-subdomain.my-namespace.svc.cluster-domain.example”`。 +鉴于上述 `"busybox-subdomain"` Service 和将 `spec.subdomain` 设置为 `"busybox-subdomain"` 的 Pod， +第一个 Pod 将看到自己的 FQDN 为 `"busybox-1.busybox-subdomain.my-namespace.svc.cluster-domain.example"`。 DNS 会为此名字提供一个 A 记录和/或 AAAA 记录，指向该 Pod 的 IP。 Pod “`busybox1`” 和 “`busybox2`” 都将有自己的地址记录。 @@ -372,7 +428,7 @@ then by default the `hostname` command inside that Pod returns `busybox-1` and t 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. --> -当 Pod 配置为具有全限定域名 (FQDN) 时，其主机名是短主机名。 +当 Pod 配置为具有全限定域名（FQDN）时，其主机名是短主机名。 例如，如果你有一个具有完全限定域名 `busybox-1.busybox-subdomain.my-namespace.svc.cluster-domain.example` 的 Pod， 则默认情况下，该 Pod 内的 `hostname` 命令返回 `busybox-1`，而 `hostname --fqdn` 命令返回 FQDN。 @@ -660,4 +716,4 @@ For guidance on administering DNS configurations, check [Configure DNS Service](/docs/tasks/administer-cluster/dns-custom-nameservers/) --> 有关管理 DNS 配置的指导， -请查看[配置 DNS 服务](/zh-cn/docs/tasks/administer-cluster/dns-custom-nameservers/) +请查看[配置 DNS 服务](/zh-cn/docs/tasks/administer-cluster/dns-custom-nameservers/)。 diff --git a/content/zh-cn/docs/concepts/workloads/controllers/daemonset.md b/content/zh-cn/docs/concepts/workloads/controllers/daemonset.md index 758154f5eeb94..e89eddecd0899 100644 --- a/content/zh-cn/docs/concepts/workloads/controllers/daemonset.md +++ b/content/zh-cn/docs/concepts/workloads/controllers/daemonset.md @@ -9,7 +9,6 @@ content_type: concept weight: 40 hide_summary: true # 在章节索引中单独列出 --- - -## 编写 DaemonSet Spec {#writing-a-daemon-set-spec} +## 编写 DaemonSet 规约 {#writing-a-daemonset-spec} -### 创建 DaemonSet {#create-a-daemon-set} +### 创建 DaemonSet {#create-a-daemonset} 你可以在 YAML 文件中描述 DaemonSet。 -例如，下面的 daemonset.yaml 文件描述了一个运行 fluentd-elasticsearch Docker 镜像的 DaemonSet： +例如，下面的 `daemonset.yaml` 文件描述了一个运行 fluentd-elasticsearch Docker 镜像的 DaemonSet： {{% code_sample file="controllers/daemonset.yaml" %}} @@ -86,7 +85,7 @@ Create a DaemonSet based on the YAML file: --> 基于 YAML 文件创建 DaemonSet： -``` +```shell kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml ``` @@ -114,7 +113,8 @@ section. DaemonSet 对象的名称必须是一个合法的 [DNS 子域名](/zh-cn/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 -DaemonSet 也需要 [`.spec` 部分](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)。 +DaemonSet 也需要 +[`.spec` 部分](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)。 * `matchLabels` - 与 [ReplicationController](/zh-cn/docs/concepts/workloads/controllers/replicationcontroller/) 的 `.spec.selector` 的作用相同。 -* `matchExpressions` - 允许构建更加复杂的选择器，可以通过指定 key、value +* `matchExpressions` - 允许构建更加复杂的选择算符，可以通过指定 key、value 列表以及将 key 和 value 列表关联起来的 Operator。 -## Daemon Pods 是如何被调度的 {#how-daemon-pods-are-scheduled} +## Daemon Pod 是如何被调度的 {#how-daemon-pods-are-scheduled} -### 污点和容忍度 {#taint-and-toleration} +### 污点和容忍度 {#taints-and-tolerations} DaemonSet 控制器会自动将一组容忍度添加到 DaemonSet Pod： @@ -401,7 +401,7 @@ You can modify the Pods that a DaemonSet creates. However, Pods do not allow al fields to be updated. Also, the DaemonSet controller will use the original template the next time a node (even with the same name) is created. --> -## 更新 DaemonSet {#updating-a-daemon-set} +## 更新 DaemonSet {#updating-a-daemonset} 如果节点的标签被修改，DaemonSet 将立刻向新匹配上的节点添加 Pod， 同时删除不匹配的节点上的 Pod。 @@ -429,7 +429,7 @@ You can [perform a rolling update](/docs/tasks/manage-daemon/update-daemon-set/) ### Init scripts --> -## DaemonSet 的替代方案 {#alternatives-to-daemon-set} +## DaemonSet 的替代方案 {#alternatives-to-daemonset} ### init 脚本 {#init-scripts} @@ -479,9 +479,9 @@ in cluster bootstrapping cases. Also, static Pods may be deprecated in the futu --> ### 静态 Pod {#static-pods} -通过在一个指定的、受 `kubelet` 监视的目录下编写文件来创建 Pod 也是可行的。 +通过在一个指定的、受 kubelet 监视的目录下编写文件来创建 Pod 也是可行的。 这类 Pod 被称为[静态 Pod](/zh-cn/docs/tasks/configure-pod-container/static-pod/)。 -不像 DaemonSet，静态 Pod 不受 `kubectl` 和其它 Kubernetes API 客户端管理。 +不像 DaemonSet，静态 Pod 不受 kubectl 和其它 Kubernetes API 客户端管理。 静态 Pod 不依赖于 API 服务器，这使得它们在启动引导新集群的情况下非常有用。 此外，静态 Pod 在将来可能会被废弃。 @@ -501,7 +501,7 @@ For example, [network plugins](/docs/concepts/extend-kubernetes/compute-storage- often include a component that runs as a DaemonSet. The DaemonSet component makes sure that the node where it's running has working cluster networking. --> -### Deployment +### Deployment {#deployments} DaemonSet 与 [Deployment](/zh-cn/docs/concepts/workloads/controllers/deployment/) 非常类似， 它们都能创建 Pod，并且 Pod 中的进程都不希望被终止（例如，Web 服务器、存储服务器）。 @@ -511,10 +511,11 @@ DaemonSet 与 [Deployment](/zh-cn/docs/concepts/workloads/controllers/deployment 当需要 Pod 副本总是运行在全部或特定主机上，并且当该 DaemonSet 提供了节点级别的功能（允许其他 Pod 在该特定节点上正确运行）时， 应该使用 DaemonSet。 -例如，[网络插件](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)通常包含一个以 DaemonSet 运行的组件。 -这个 DaemonSet 组件确保它所在的节点的集群网络正常工作。 +例如，[网络插件](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)通常包含一个以 +DaemonSet 运行的组件。这个 DaemonSet 组件确保它所在的节点的集群网络正常工作。 ## {{% heading "whatsnext" %}} + * 了解 [Pod](/zh-cn/docs/concepts/workloads/pods)。 - * 了解[静态 Pod](#static-pods)，这对运行 Kubernetes {{< glossary_tooltip text="控制面" term_id="control-plane" >}}组件有帮助。 + * 了解[静态 Pod](#static-pods)，这对运行 Kubernetes + {{< glossary_tooltip text="控制面" term_id="control-plane" >}}组件有帮助。 * 了解如何使用 DaemonSet * [对 DaemonSet 执行滚动更新](/zh-cn/docs/tasks/manage-daemon/update-daemon-set/) * [对 DaemonSet 执行回滚](/zh-cn/docs/tasks/manage-daemon/rollback-daemon-set/)（例如：新的版本没有达到你的预期） -* 理解[Kubernetes 如何将 Pod 分配给节点](/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/)。 +* 理解 [Kubernetes 如何将 Pod 分配给节点](/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/)。 * 了解[设备插件](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)和 [扩展（Addons）](/zh-cn/docs/concepts/cluster-administration/addons/)，它们常以 DaemonSet 运行。 * `DaemonSet` 是 Kubernetes REST API 中的顶级资源。阅读 {{< api-reference page="workload-resources/daemon-set-v1" >}} diff --git a/content/zh-cn/docs/reference/access-authn-authz/authentication.md b/content/zh-cn/docs/reference/access-authn-authz/authentication.md index 750cb00801719..001a3772aeaa7 100644 --- a/content/zh-cn/docs/reference/access-authn-authz/authentication.md +++ b/content/zh-cn/docs/reference/access-authn-authz/authentication.md @@ -482,6 +482,34 @@ is included in a request. `id_token`（而非 `access_token`）作为持有者令牌。 关于如何在请求中设置令牌，可参见[前文](#putting-a-bearer-token-in-a-request)。 +> user: 2. Provide access_token,
id_token, and refresh_token + deactivate idp + activate user + user ->> kube: 3. Call kubectl
with --token being the id_token
OR add tokens to .kube/config + deactivate user + activate kube + kube ->> api: 4. Authorization: Bearer... + deactivate kube + activate api + api ->> api: 5. Is JWT signature valid? + api ->> api: 6. Has the JWT expired? (iat+exp) + api ->> api: 7. User authorized? + api -->> kube: 8. Authorized: Perform
action and return result + deactivate api + activate kube + kube --x user: 9. Return result + deactivate kube +--> + {{< mermaid >}} sequenceDiagram participant user as 用户 @@ -722,7 +750,7 @@ jwt: # PEM encoded CA certificates used to validate the connection when fetching # discovery information. If not set, the system verifier will be used. # Same value as the content of the file referenced by the --oidc-ca-file flag. - certificateAuthority: + certificateAuthority: # audiences is the set of acceptable audiences the JWT must be issued to. # At least one of the entries must match the "aud" claim in presented JWTs. audiences: @@ -936,8 +964,8 @@ jwt: `jwt.userValidationRules[i].expression` 表示将由 CEL 计算的表达式。 CEL 表达式可以访问 `userInfo` 的内容，并组织成 `user` CEL 变量。 - 有关 `user` 的架构，请参阅 - [UserInfo](/zh-cn/docs/reference/ generated/kubernetes-api/v{{< skew currentVersion >}}/#userinfo-v1-authentication-k8s-io) API 文档。 + 有关 `user` 的结构，请参阅 + [UserInfo](/zh-cn/docs/reference/generated/kubernetes-api/v{{< skew currentVersion >}}/#userinfo-v1-authentication-k8s-io) API 文档。 - 这将导致用户验证失败，因为用户名以 `system:` 开头。 API 服务器将返回 `401 Unauthorized` 错误。 + 这将导致用户验证失败，因为用户名以 `system:` 开头。API 服务器将返回 `401 Unauthorized` 错误。 {{% /tab %}} {{< /tabs >}} @@ -1264,20 +1291,12 @@ jwt: Kubernetes 并未提供 OpenID Connect 的身份服务。 -你可以使用现有的公共的 OpenID Connect 身份服务 -（例如 Google 或者[其他服务](https://connect2id.com/products/nimbus-oauth-openid-connect-sdk/openid-connect-providers)）。 -或者，你也可以选择自己运行一个身份服务，例如 [dex](https://dexidp.io/)、 -[Keycloak](https://github.com/keycloak/keycloak)、 -CloudFoundry [UAA](https://github.com/cloudfoundry/uaa) 或者 -Tremolo Security 的 [OpenUnison](https://openunison.github.io/)。 +你可以使用现有的公共的 OpenID Connect 身份服务或者运行你自己的 +OpenID Connect 身份服务。 关于上述第三条需求，即要求具备 CA 签名的证书，有一些额外的注意事项。 -如果你部署了自己的身份服务，而不是使用云厂商（如 Google 或 Microsoft）所提供的服务， -你必须对身份服务的 Web 服务器证书进行签名，签名所用证书的 `CA` 标志要设置为 -`TRUE`，即使用的是自签名证书。这是因为 GoLang 的 TLS 客户端实现对证书验证标准方面有非常严格的要求。 -如果你手头没有现成的 CA 证书，可以使用 Dex -团队所开发的[证书生成脚本](https://github.com/dexidp/dex/blob/master/examples/k8s/gencert.sh) -来创建一个简单的 CA 和被签了名的证书与密钥对。 -或者你也可以使用[这个类似的脚本](https://raw.githubusercontent.com/TremoloSecurity/openunison-qs-kubernetes/master/src/main/bash/makessl.sh)， -生成一个合法期更长、密钥尺寸更大的 SHA256 证书。 - - -参阅特定系统的安装指令： - -- [UAA](https://docs.cloudfoundry.org/concepts/architecture/uaa.html) -- [Dex](https://dexidp.io/docs/kubernetes/) -- [OpenUnison](https://www.tremolosecurity.com/orchestra-k8s/) +如果你部署了自己的身份服务，你必须对身份服务的 Web 服务器证书进行签名， +签名所用证书的 `CA` 标志要设置为 `TRUE`，即使用的是自签名证书。 +这是因为 GoLang 的 TLS 客户端实现对证书验证标准方面有非常严格的要求。 +如果你手头没有现成的 CA 证书，可以使用标准证书生成工具来创建一个简单的 +CA 和被签了名的证书与密钥对。 +

+此 API 的版本是 v1。 +

+ -

此 API 的版本是 v1。

- ## 资源类型 {#resource-types} - [WebhookAdmission](#apiserver-config-k8s-io-v1-WebhookAdmission) ## `WebhookAdmission` {#apiserver-config-k8s-io-v1-WebhookAdmission} +

-

WebhookAdmission 为 Webhook 准入控制器提供配置信息。

+WebhookAdmission 为 Webhook 准入控制器提供配置信息。 +

- + - - + - +
字段描述
apiVersion
string		apiserver.config.k8s.io/v1
kind
string		WebhookAdmission
kubeConfigFile [必需]
string 		- -

字段 kubeConfigFile 包含指向 kubeconfig 文件的路径。

+

+ +字段 kubeConfigFile 包含指向 kubeconfig 文件的路径。 +
- diff --git a/content/zh-cn/docs/reference/config-api/kubelet-config.v1.md b/content/zh-cn/docs/reference/config-api/kubelet-config.v1.md index 1e913aebcdc44..365216a2e380a 100644 --- a/content/zh-cn/docs/reference/config-api/kubelet-config.v1.md +++ b/content/zh-cn/docs/reference/config-api/kubelet-config.v1.md @@ -38,19 +38,19 @@ Kubelet 从磁盘上读取这些配置信息，并根据 CredentialProvider 类 []CredentialProvider - -

- providers 是一组凭据提供程序插件，这些插件会被 kubelet 启用。 - 多个提供程序可以匹配到同一镜像上，这时，来自所有提供程序的凭据信息都会返回给 kubelet。 - 如果针对同一镜像调用了多个提供程序，则结果会被组合起来。如果提供程序返回的认证主键有重复， - 列表中先出现的提供程序所返回的值将被首先尝试。 -

+

+ +providers 是一组凭据提供程序插件，这些插件会被 kubelet 启用。 +多个提供程序可以匹配到同一镜像上，这时，来自所有提供程序的凭据信息都会返回给 kubelet。 +如果针对同一镜像调用了多个提供程序，则结果会被组合起来。如果提供程序返回的认证主键有重复， +列表中先出现的提供程序所返回的值将被首先尝试。 +

@@ -80,13 +80,13 @@ CredentialProvider 代表的是要被 kubelet 调用的一个 exec 插件。 string +

-

name 是凭据提供程序的名称（必需）。此名称必须与 kubelet 所看到的提供程序可执行文件的名称匹配。可执行文件必须位于 kubelet 的 bin 目录（通过 --image-credential-provider-bin-dir 设置）下。 @@ -98,6 +98,7 @@ CredentialProvider 代表的是要被 kubelet 调用的一个 exec 插件。 []string +

-

matchImages 是一个必须设置的字符串列表，用来匹配镜像以便确定是否要调用此提供程序。 +matchImages 是一个必须设置的字符串列表，用来匹配镜像以便确定是否要调用此提供程序。 如果字符串之一与 kubelet 所请求的镜像匹配，则此插件会被调用并给予提供凭据的机会。 -镜像应该包含镜像库域名和 URL 路径。

+镜像应该包含镜像库域名和 URL 路径。 +

+

-

matchImages 中的每个条目都是一个模式字符串，其中可以包含端口号和路径。 +matchImages 中的每个条目都是一个模式字符串，其中可以包含端口号和路径。 域名部分可以包含通配符，但端口或路径部分不可以。'*.k8s.io' 或 'k8s.*.io' 等子域名以及 'k8s.*' 这类顶级域名都支持通配符。

对于 'app.k8s.io' 这类部分子域名的匹配也是支持的。 -每个通配符只能用来匹配一个子域名段，所以 *.io 不会匹配 *.k8s.io。

+每个通配符只能用来匹配一个子域名段，所以 *.io 不会匹配 *.k8s.io。 +

+

-

镜像与 matchImages 之间存在匹配时，以下条件都要满足：

+镜像与 matchImages 之间存在匹配时，以下条件都要满足： +

    -

    matchImages 的一些示例如下：

    +matchImages 的一些示例如下： +

    • 123456789.dkr.ecr.us-east-1.amazonaws.com
    • *.azurecr.io
      • @@ -152,11 +160,11 @@ Example values of matchImages: meta/v1.Duration +

      -

      defaultCacheDuration 是插件在内存中缓存凭据的默认时长， 在插件响应中没有给出缓存时长时，使用这里设置的值。此字段是必需的。

      @@ -166,11 +174,11 @@ Example values of matchImages: string +

      -

      要求 exec 插件 CredentialProviderRequest 请求的输入版本。 所返回的 CredentialProviderResponse 必须使用与输入相同的编码版本。当前支持的值有：

      @@ -183,26 +191,28 @@ Example values of matchImages: []string - -

      在执行插件可执行文件时要传递给命令的参数。

      +

      + +在执行插件可执行文件时要传递给命令的参数。 +

      env
      []ExecEnvVar - -

      - env 定义要提供给插件进程的额外的环境变量。 - 这些环境变量会与主机上的其他环境变量以及 client-go 所使用的环境变量组合起来， - 一起传递给插件。 -

      +

      + +env 定义要提供给插件进程的额外的环境变量。 +这些环境变量会与主机上的其他环境变量以及 client-go 所使用的环境变量组合起来， +一起传递给插件。 +

      tokenAttributes
      @@ -307,8 +317,7 @@ ServiceAccountTokenAttributes 是将被传递给插件的服务账号令牌的 - - + diff --git a/content/zh-cn/docs/reference/glossary/cel.md b/content/zh-cn/docs/reference/glossary/cel.md new file mode 100644 index 0000000000000..06f9c7d667a93 --- /dev/null +++ b/content/zh-cn/docs/reference/glossary/cel.md @@ -0,0 +1,47 @@ +--- +title: 通用表达式语言（CEL） +id: cel +date: 2025-06-04 +full_link: https://cel.dev +short_description: > + 一种为安全执行用户代码而设计的表达式语言。 +tags: +- extension +- fundamental +aka: +- CEL +--- + + + +一种通用的表达式语言，其设计目标是快速执行、可移植，并且具备安全性。 + + + + +在 Kubernetes 中，CEL 可用于运行查询并进行细粒度的筛选。例如，你可以将 CEL +表达式用于[动态准入控制](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/)， +以筛选请求中的特定字段；也可以与[动态资源分配（DRA）](/zh-cn/docs/concepts/scheduling-eviction/dynamic-resource-allocation)结合使用， +基于特定属性选择资源。 diff --git a/content/zh-cn/docs/reference/glossary/device.md b/content/zh-cn/docs/reference/glossary/device.md new file mode 100644 index 0000000000000..26847866762d5 --- /dev/null +++ b/content/zh-cn/docs/reference/glossary/device.md @@ -0,0 +1,45 @@ +--- +title: 设备 +id: device +date: 2025-05-13 +short_description: > + 直接或间接挂接到集群节点上的所有资源，例如 GPU 或电路板。 + +tags: +- extension +- fundamental +--- + + + +一个或多个直接或间接挂接到{{< glossary_tooltip text="节点" term_id="node" >}}上的{{< glossary_tooltip text="基础设施资源" term_id="infrastructure-resource" >}}。 + + + + +设备可以是如 GPU 等商业产品，也可以是如 +[ASIC 板卡](https://zh.wikipedia.org/zh-cn/%E7%89%B9%E5%AE%9A%E6%87%89%E7%94%A8%E7%A9%8D%E9%AB%94%E9%9B%BB%E8%B7%AF) +等定制硬件。 +挂接的设备通常需要相应的设备驱动，才能让 Kubernetes 中的 +{{< glossary_tooltip text="Pod" term_id="pod" >}} 访问这些设备。 diff --git a/content/zh-cn/docs/reference/glossary/dra.md b/content/zh-cn/docs/reference/glossary/dra.md new file mode 100644 index 0000000000000..df3d07e47fc91 --- /dev/null +++ b/content/zh-cn/docs/reference/glossary/dra.md @@ -0,0 +1,47 @@ +--- +title: 动态资源分配 +id: dra +date: 2025-05-13 +full_link: /docs/concepts/scheduling-eviction/dynamic-resource-allocation/ +short_description: > + Kubernetes 提供的一项特性，用于在 Pod 之间请求和共享资源，例如硬件加速器。 + +aka: +- DRA +tags: +- extension +--- + + + +Kubernetes 提供的一项特性，允许你在多个 Pod 之间请求和共享资源。 +这些资源通常是挂接的{{< glossary_tooltip text="设备" term_id="device" >}}，例如硬件加速器。 + + + + +借助 DRA，设备驱动和集群管理员可以定义设备的**类别**，这些类别可供工作负载中的 Pod 申领。 +Kubernetes 会将匹配的设备分配给特定的申领，并将相应的 Pod 调度到能够访问这些已分配设备的节点上。 diff --git a/content/zh-cn/docs/reference/glossary/kubelet.md b/content/zh-cn/docs/reference/glossary/kubelet.md index 2550e68dce8bb..101d0fbfd4c4a 100644 --- a/content/zh-cn/docs/reference/glossary/kubelet.md +++ b/content/zh-cn/docs/reference/glossary/kubelet.md @@ -2,7 +2,7 @@ title: Kubelet id: kubelet date: 2018-04-12 -full_link: /docs/reference/generated/kubelet +full_link: /zh-cn/docs/reference/command-line-tools-reference/kubelet short_description: > 一个在集群中每个节点上运行的代理。它保证容器都运行在 Pod 中。 @@ -14,7 +14,7 @@ tags: title: Kubelet id: kubelet date: 2018-04-12 -full_link: /docs/reference/generated/kubelet +full_link: /docs/reference/command-line-tools-reference/kubelet short_description: > An agent that runs on each node in the cluster. It makes sure that containers are running in a pod. diff --git a/content/zh-cn/docs/reference/kubectl/generated/kubectl_top/kubectl_top_node.md b/content/zh-cn/docs/reference/kubectl/generated/kubectl_top/kubectl_top_node.md index 1717ff2638a66..aa2a0d5e58dbf 100644 --- a/content/zh-cn/docs/reference/kubectl/generated/kubectl_top/kubectl_top_node.md +++ b/content/zh-cn/docs/reference/kubectl/generated/kubectl_top/kubectl_top_node.md @@ -62,7 +62,8 @@ kubectl top node NODE_NAME help for node --> node 操作的帮助命令。 -

      +

      + @@ -74,7 +75,8 @@ node 操作的帮助命令。 If present, print output without headers --> 如果存在，则打印没有标头的输出。 -

      +

      + @@ -83,11 +85,13 @@ If present, print output without headers +

      + @@ -99,7 +103,8 @@ Selector (label query) to filter on, supports '=', '==', and '!='.(e.g. -l key1= Print node resources based on Capacity instead of Allocatable(default) of the nodes. --> 基于节点的 Capacity 而不是 Allocatable（默认）打印节点资源。 -

      +

      + @@ -111,7 +116,8 @@ Print node resources based on Capacity instead of Allocatable(default) of the no If non-empty, sort nodes list using specified field. The field can be either 'cpu' or 'memory'. --> 如果非空，则使用指定字段对节点列表进行排序。字段可以是 “cpu” 或 “memory”。 -

      +

      + @@ -123,7 +129,8 @@ If non-empty, sort nodes list using specified field. The field can be either 'cp Enables using protocol-buffers to access Metrics API. --> 启用协议缓冲区（protocol-buffers）以访问 Metrics API。 -

      +

      + @@ -131,7 +138,7 @@ Enables using protocol-buffers to access Metrics API. ## {{% heading "parentoptions" %}} -
      字段描述
      serviceAccountTokenAudience [必需]
      string

      -用来执行过滤的选择算符（标签查询），支持 '='、'==' 和 '!='（例如 -l key1=value1,key2=value2）。 +过滤所用的选择算符（标签查询），支持 '='、'=='、'!='、'in' 和 'notin'。 +（例如 -l key1=value1,key2=value2,key3 in (value3)）。 匹配的对象必须满足所有指定的标签约束。 -
      +
      @@ -147,7 +154,8 @@ Enables using protocol-buffers to access Metrics API. Username to impersonate for the operation. User could be a regular user or a service account in a namespace. --> 操作所用的伪装用户名。用户可以是常规用户或命名空间中的服务账号。 -

      +

      + @@ -159,7 +167,8 @@ Username to impersonate for the operation. User could be a regular user or a ser Group to impersonate for the operation, this flag can be repeated to specify multiple groups. --> 操作所用的伪装用户组，此标志可以被重复设置以指定多个组。 -

      +

      + @@ -171,7 +180,8 @@ Group to impersonate for the operation, this flag can be repeated to specify mul UID to impersonate for the operation. --> 操作所用的伪装 UID。 -

      +

      + @@ -183,7 +193,8 @@ UID to impersonate for the operation. Default cache directory --> 默认缓存目录。 -

      +

      + @@ -195,7 +206,8 @@ Default cache directory Path to a cert file for the certificate authority --> 证书机构的证书文件的路径。 -

      +

      + @@ -207,7 +219,8 @@ Path to a cert file for the certificate authority Path to a client certificate file for TLS --> TLS 客户端证书文件的路径。 -

      +

      + @@ -219,7 +232,8 @@ TLS 客户端证书文件的路径。 Path to a client key file for TLS --> TLS 客户端密钥文件的路径。 -

      +

      + @@ -231,7 +245,8 @@ TLS 客户端密钥文件的路径。 The name of the kubeconfig cluster to use --> 要使用的 kubeconfig 中集群的名称。 -

      +

      + @@ -243,7 +258,8 @@ The name of the kubeconfig cluster to use The name of the kubeconfig context to use --> 要使用的 kubeconfig 上下文的名称。 -

      +

      + @@ -255,7 +271,8 @@ The name of the kubeconfig context to use Indicates the tolerationSeconds of the toleration for notReady:NoExecute that is added by default to every pod that does not already have such a toleration. --> 设置针对 notReady:NoExecute 的容忍度的 tolerationSeconds，默认添加到所有尚未设置此容忍度的 Pod。 -

      +

      + @@ -267,7 +284,8 @@ Indicates the tolerationSeconds of the toleration for notReady:NoExecute that is Indicates the tolerationSeconds of the toleration for unreachable:NoExecute that is added by default to every pod that does not already have such a toleration. --> 设置针对 unreachable:NoExecute 的容忍度的 tolerationSeconds，默认添加到所有尚未设置此容忍度的 Pod。 -

      +

      + @@ -279,7 +297,8 @@ Indicates the tolerationSeconds of the toleration for unreachable:NoExecute that If true, opt-out of response compression for all requests to the server --> 如果为 true，则对服务器所有请求的响应不再压缩。 -

      +

      + @@ -291,7 +310,8 @@ If true, opt-out of response compression for all requests to the server If true, the server's certificate will not be checked for validity. This will make your HTTPS connections insecure --> 如果为 true，则不检查服务器证书的有效性。这将使你的 HTTPS 连接不安全。 -

      +

      + @@ -303,7 +323,8 @@ If true, the server's certificate will not be checked for validity. This will ma Path to the kubeconfig file to use for CLI requests. --> CLI 请求要使用的 kubeconfig 文件的路径。 -

      +

      + @@ -315,7 +336,8 @@ CLI 请求要使用的 kubeconfig 文件的路径。 Require server version to match client version --> 要求服务器版本与客户端版本匹配。 -

      +

      + @@ -327,7 +349,8 @@ Require server version to match client version If present, the namespace scope for this CLI request --> 如果存在，则是此 CLI 请求的命名空间范围。 -

      +

      + @@ -339,7 +362,8 @@ If present, the namespace scope for this CLI request Password for basic authentication to the API server --> 对 API 服务器进行基本身份验证所用的密码。 -

      +

      + @@ -351,7 +375,8 @@ Password for basic authentication to the API server Name of profile to capture. One of (none|cpu|heap|goroutine|threadcreate|block|mutex) --> 要记录的性能分析信息。可选值为（none|cpu|heap|goroutine|threadcreate|block|mutex）。 -

      +

      + @@ -363,7 +388,8 @@ Name of profile to capture. One of (none|cpu|heap|goroutine|threadcreate|block|m Name of the file to write the profile to --> 性能分析信息要写入的目标文件的名称。 -

      +

      + @@ -376,7 +402,8 @@ The length of time to wait before giving up on a single server request. Non-zero --> 在放弃某个服务器请求之前等待的时长。非零值应包含相应的时间单位（例如 1s、2m、3h）。 值为零表示请求不会超时。 -

      +

      + @@ -388,7 +415,8 @@ The length of time to wait before giving up on a single server request. Non-zero The address and port of the Kubernetes API server --> Kubernetes API 服务器的地址和端口。 -

      +

      + @@ -400,7 +428,8 @@ Kubernetes API 服务器的地址和端口。 Writes in the storage driver will be buffered for this duration, and committed to the non memory backends as a single transaction --> 对存储驱动的写入操作将被缓存的时长；缓存的操作会作为一个事务提交给非内存后端。 -

      +

      + @@ -412,7 +441,8 @@ Writes in the storage driver will be buffered for this duration, and committed t database name --> 数据库名称。 -

      +

      + @@ -424,7 +454,8 @@ database name database host:port --> 数据库 host:port -

      +

      + @@ -436,7 +467,8 @@ database host:port database password --> 数据库密码。 -

      +

      + @@ -448,7 +480,8 @@ database password use secure connection with database --> 使用与数据库的安全连接。 -

      +

      + @@ -460,7 +493,8 @@ use secure connection with database table name --> 表名。 -

      +

      + @@ -472,7 +506,8 @@ table name database username --> 数据库用户名。 -

      +

      + @@ -484,7 +519,8 @@ database username Server name to use for server certificate validation. If it is not provided, the hostname used to contact the server is used --> 服务器证书验证所用的服务器名称。如果未提供，则使用与服务器通信所用的主机名。 -

      +

      + @@ -496,7 +532,8 @@ Server name to use for server certificate validation. If it is not provided, the Bearer token for authentication to the API server --> 向 API 服务器进行身份验证的持有者令牌。 -

      +

      + @@ -508,7 +545,8 @@ Bearer token for authentication to the API server The name of the kubeconfig user to use --> 要使用的 kubeconfig 用户的名称。 -

      +

      + @@ -520,7 +558,8 @@ The name of the kubeconfig user to use Username for basic authentication to the API server --> 向 API 服务器进行基本身份验证时所用的用户名。 -

      +

      + @@ -532,7 +571,8 @@ Username for basic authentication to the API server --version, --version=raw prints version information and quits; --version=vX.Y.Z... sets the reported version --> --version, --version=raw 打印版本信息并退出；--version=vX.Y.Z... 设置报告的版本。 -

      +

      + @@ -544,7 +584,8 @@ Username for basic authentication to the API server Treat warnings received from the server as errors and exit with a non-zero exit code --> 将从服务器收到的警告视为错误，并以非零退出码退出。 -

      +

      + diff --git a/content/zh-cn/docs/reference/kubectl/generated/kubectl_uncordon/_index.md b/content/zh-cn/docs/reference/kubectl/generated/kubectl_uncordon/_index.md index b32f1890380bb..0ce33ee1ac142 100644 --- a/content/zh-cn/docs/reference/kubectl/generated/kubectl_uncordon/_index.md +++ b/content/zh-cn/docs/reference/kubectl/generated/kubectl_uncordon/_index.md @@ -19,15 +19,21 @@ Mark node as schedulable. --> 将节点标记为可调度。 -``` +```shell kubectl uncordon NODE ``` ## {{% heading "examples" %}} + +```shell +# 将节点 “foo” 标记为可调度 +kubectl uncordon foo ``` ## {{% heading "options" %}} @@ -75,9 +81,10 @@ help for uncordon 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 c48442669b324..00b0e1d3b48e1 100644 --- a/content/zh-cn/docs/reference/labels-annotations-taints/_index.md +++ b/content/zh-cn/docs/reference/labels-annotations-taints/_index.md @@ -2745,8 +2745,6 @@ Type: Label Example: `service.kubernetes.io/service-proxy-name: "foo-bar"` Used on: Service - -The kube-proxy has this label for custom proxy, which delegates service control to custom proxy. --> ### service.kubernetes.io/service-proxy-name {#servicekubernetesioservice-proxy-name} @@ -2756,7 +2754,17 @@ The kube-proxy has this label for custom proxy, which delegates service control 用于：Service -kube-proxy 自定义代理会使用这个标签，它将服务控制委托给自定义代理。 + +为这个标签设置一个值会告诉 kube-proxy 在执行代理操作时忽略此 Service。 +这一标签使得用户能够为此 Service 使用替代的代理实现（例如，运行管理 nftables 的 DaemonSet）。 +通过此字段，可以同时激活多个替代代理实现，例如，为每个替代代理实现设置唯一值， +以负责各自的 Service。 ### scheduler.alpha.kubernetes.io/tolerationsWhitelist {#schedulerkubernetestolerations-whitelist} @@ -3391,6 +3392,14 @@ The pod is admitted only if the check succeeds. 用于：命名空间 + 此注解只有在启用（Alpha） [PodTolerationRestriction](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#podtolerationrestriction) 控制器时才生效。注解值是一个 JSON 文档，它为它所注解的命名空间定义了一个允许容忍的列表。 @@ -4878,10 +4887,6 @@ Used on: Pod This annotation was only relevant if you were using [PodSecurityPolicy](/docs/concepts/security/pod-security-policy/) objects. Kubernetes v{{< skew currentVersion >}} does not support the PodSecurityPolicy API. - -When the PodSecurityPolicy admission controller admitted a Pod, the admission controller -modified the Pod to have this annotation. -The value of the annotation was the name of the PodSecurityPolicy that was used for validation. --> ### kubernetes.io/psp（已弃用） {#kubernetes-io-psp} @@ -4894,6 +4899,11 @@ The value of the annotation was the name of the PodSecurityPolicy that was used 这个注解只在你使用 [PodSecurityPolicies](/zh-cn/docs/concepts/security/pod-security-policy/) 时才有意义。 Kubernetes v{{< skew currentVersion >}} 不支持 PodSecurityPolicy API。 + 当 PodSecurityPolicy 准入控制器接受一个 Pod 时，会修改该 Pod，并给这个 Pod 添加此注解。 注解的值是用来对 Pod 进行验证检查的 PodSecurityPolicy 的名称。 diff --git a/content/zh-cn/docs/tasks/configure-pod-container/assign-resources/_index.md b/content/zh-cn/docs/tasks/configure-pod-container/assign-resources/_index.md new file mode 100644 index 0000000000000..5c0f05e952caa --- /dev/null +++ b/content/zh-cn/docs/tasks/configure-pod-container/assign-resources/_index.md @@ -0,0 +1,10 @@ +--- +title: "向 Pod 和容器分配设备" +description: 向你的 Kubernetes 工作负载分配基础设施资源。 +weight: 30 +--- + diff --git a/content/zh-cn/docs/tasks/configure-pod-container/assign-resources/allocate-devices-dra.md b/content/zh-cn/docs/tasks/configure-pod-container/assign-resources/allocate-devices-dra.md new file mode 100644 index 0000000000000..a2149ec9bf430 --- /dev/null +++ b/content/zh-cn/docs/tasks/configure-pod-container/assign-resources/allocate-devices-dra.md @@ -0,0 +1,319 @@ +--- +title: 使用 DRA 为工作负载分配设备 +content_type: task +min-kubernetes-server-version: v1.32 +weight: 20 +--- + + +{{< feature-state feature_gate_name="DynamicResourceAllocation" >}} + + + + +本文介绍如何使用**动态资源分配（DRA）**为 Pod 分配设备。 +这些指示说明面向工作负载运维人员。在阅读本文之前，请先了解 DRA 的工作原理以及相关术语，例如 +{{< glossary_tooltip text="ResourceClaims" term_id="resourceclaim" >}} 和 +{{< glossary_tooltip text="ResourceClaimTemplates" term_id="resourceclaimtemplate" >}}。 +更多信息参阅[动态资源分配（DRA）](/zh-cn/docs/concepts/scheduling-eviction/dynamic-resource-allocation/)。 + + + + +## 关于使用 DRA 分配设备 {#about-device-allocation-dra} + +作为工作负载运维人员，你可以通过创建 ResourceClaim 或 ResourceClaimTemplate +来**申领**工作负载所需的设备。当你部署工作负载时，Kubernetes 和设备驱动会找到可用的设备， +将其分配给 Pod，并将 Pod 调度到可访问这些设备的节点上。 + + + +## {{% heading "prerequisites" %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + +* 请确保集群管理员已设置好 DRA，挂接了设备并安装了驱动程序。 + 详情请参见[在集群中设置 DRA](/zh-cn/docs/tasks/configure-pod-container/assign-resources/set-up-dra-cluster)。 + + + + +## 寻找可申领的设备 {#identify-devices} + +你的集群管理员或设备驱动程序会创建定义设备类别的 +{{< glossary_tooltip term_id="deviceclass" text="DeviceClass" >}}。你可以使用 +{{< glossary_tooltip term_id="cel" >}} 表达式筛选特定的设备属性，从而申领设备。 + +获取集群中的 DeviceClass 列表： + +```shell +kubectl get deviceclasses +``` + + +输出类似如下： + +``` +NAME AGE +driver.example.com 16m +``` + + +如果你遇到权限错误，你可能无权获取 DeviceClass。 +请与你的集群管理员或驱动提供商联系，了解可用的设备属性。 + + +## 申领资源 {#claim-resources} + +你可以通过 +{{< glossary_tooltip text="ResourceClaims" term_id="resourceclaim" >}} +请求某个 DeviceClass 的资源。要创建 ResourceClaim，可以采用以下方式之一： + + +* 手动创建 ResourceClaim，如果你希望多个 Pod 共享相同设备，或希望申领在 Pod 生命期结束后仍然存在。 +* 使用 + {{< glossary_tooltip text="ResourceClaimTemplate" term_id="resourceclaimtemplate" >}}， + 让 Kubernetes 为每个 Pod 生成并管理 ResourceClaim。如果你希望每个 Pod + 访问独立的、具有类似配置的设备，你可以创建 ResourceClaimTemplate。例如， + 在使用[并行执行](/zh-cn/docs/concepts/workloads/controllers/job/#parallel-jobs)的 + Job 中，你可能希望多个 Pod 同时访问设备。 + + +如果你在 Pod 中直接引用了特定 ResourceClaim，该 ResourceClaim 必须已存在于集群中。否则， +Pod 会保持在 Pending 状态，直到申领被创建。你可以在 Pod 中引用自动生成的 ResourceClaim， +但不推荐这样做，因为自动生成的 ResourceClaim 的生命期被绑定到了触发生成它的 Pod。 + +要创建申领资源的工作负载，请选择以下选项之一： + +{{< tabs name="claim-resources" >}} +{{% tab name="ResourceClaimTemplate" %}} + + +查看以下示例清单： + +{{% code_sample file="dra/resourceclaimtemplate.yaml" %}} + + +此清单会创建一个 ResourceClaimTemplate，它请求属于 `example-device-class` +DeviceClass、且同时满足以下两个参数的设备： + +* 属性 `driver.example.com/type` 的值为 `gpu` +* 容量为 `64Gi` + +创建 ResourceClaimTemplate 的命令如下： + +```shell +kubectl apply -f https://k8s.io/examples/dra/resourceclaimtemplate.yaml +``` + +{{% /tab %}} +{{% tab name="ResourceClaim" %}} + + +查看以下示例清单： + +{{% code_sample file="dra/resourceclaim.yaml" %}} + + +此清单会创建一个 ResourceClaim，请求属于 `example-device-class` +DeviceClass、且同时满足以下两个参数的设备： + +* 属性 `driver.example.com/type` 的值为 `gpu` +* 容量为 `64Gi` + +创建 ResourceClaim 的命令如下： + +```shell +kubectl apply -f https://k8s.io/examples/dra/resourceclaim.yaml +``` + +{{% /tab %}} +{{< /tabs >}} + + +## 使用 DRA 在工作负载中请求设备 {#request-devices-workloads} + +要请求设备分配，请在 Pod 规约的 `resourceClaims` 字段中指定 ResourceClaim +或 ResourceClaimTemplate，然后在容器的 `resources.claims` 字段中按名称请求具体的资源申领。 +你可以在 `resourceClaims` 中列出多个条目，并在不同容器中使用特定的申领。 + +1. 查看以下 Job 示例： + + {{% code_sample file="dra/dra-example-job.yaml" %}} + + + + 此 Job 中的每个 Pod 具备以下属性： + + * 提供名为 `separate-gpu-claim` 的 ResourceClaimTemplate 和名为 + `shared-gpu-claim` 的 ResourceClaim 给容器使用。 + * 运行以下容器： + + * `container0` 请求 `separate-gpu-claim` ResourceClaimTemplate 中定义的设备。 + * `container1` 和 `container2` 共享对 `shared-gpu-claim` ResourceClaim 中设备的访问。 + + +2. 创建 Job： + + ```shell + kubectl apply -f https://k8s.io/examples/dra/dra-example-job.yaml + ``` + + +## 清理 {#clean-up} + +要删除本任务中创建的 Kubernetes 对象，请按照以下步骤操作： + +1. 删除示例 Job： + + ```shell + kubectl delete -f https://k8s.io/examples/dra/dra-example-job.yaml + ``` + + +2. 运行以下其中一条命令来删除你的资源申领： + + * 删除 ResourceClaimTemplate： + + ```shell + kubectl delete -f https://k8s.io/examples/dra/resourceclaimtemplate.yaml + ``` + + + + * 删除 ResourceClaim： + + ```shell + kubectl delete -f https://k8s.io/examples/dra/resourceclaim.yaml + ``` + +## {{% heading "whatsnext" %}} + + +* [进一步了解 DRA](/zh-cn/docs/concepts/scheduling-eviction/dynamic-resource-allocation) diff --git a/content/zh-cn/docs/tasks/configure-pod-container/assign-resources/set-up-dra-cluster.md b/content/zh-cn/docs/tasks/configure-pod-container/assign-resources/set-up-dra-cluster.md new file mode 100644 index 0000000000000..13e94deed032f --- /dev/null +++ b/content/zh-cn/docs/tasks/configure-pod-container/assign-resources/set-up-dra-cluster.md @@ -0,0 +1,307 @@ +--- +title: "在集群中设置 DRA" +content_type: task +min-kubernetes-server-version: v1.32 +weight: 10 +--- + + +{{< feature-state feature_gate_name="DynamicResourceAllocation" >}} + + + + +本文介绍如何在 Kubernetes 集群中通过启用 API 组并配置设备类别来设置**动态资源分配（DRA）**。 +这些指示说明适用于集群管理员。 + + + + +## 关于 DRA {#about-dra} + +{{< glossary_definition term_id="dra" length="all" >}} + + +确保你已了解 DRA 的工作机制及其术语，例如 +{{< glossary_tooltip text="DeviceClasses" term_id="deviceclass" >}}、 +{{< glossary_tooltip text="ResourceClaims" term_id="resourceclaim" >}}以及 +{{< glossary_tooltip text="ResourceClaimTemplates" term_id="resourceclaimtemplate" >}}。 +更多信息请参见[动态资源分配（DRA）](/zh-cn/docs/concepts/scheduling-eviction/dynamic-resource-allocation/)。 + + + +## {{% heading "prerequisites" %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + +* 将设备直接或间接挂接到你的集群中。为避免驱动相关的问题，请在安装驱动之前先完成 DRA 特性的配置。 + + + + +## 启用 DRA API 组 {#enable-dra} + +若要让 Kubernetes 能够使用 DRA 为你的 Pod 分配资源，需完成以下配置步骤： + +1. 在所有以下组件中启用 `DynamicResourceAllocation` + [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)： + + * `kube-apiserver` + * `kube-controller-manager` + * `kube-scheduler` + * `kubelet` + + +2. 启用以下 {{< glossary_tooltip text="API 组" term_id="api-group" >}}： + + * `resource.k8s.io/v1beta1`：DRA 所必需。 + * `resource.k8s.io/v1beta2`：可选，推荐启用以提升用户体验。 + + 更多信息请参阅[启用或禁用 API 组](/zh-cn/docs/reference/using-api/#enabling-or-disabling)。 + + +## 验证是否启用了 DRA {#verify} + +若要验证集群是否配置正确，可尝试列出 DeviceClass： + +```shell +kubectl get deviceclasses +``` + + +如果组件配置正确，输出类似如下： + +``` +No resources found +``` + + +如果 DRA 未正确配置，则上述命令的输出可能如下： + +``` +error: the server doesn't have a resource type "deviceclasses" +``` + + +你可以尝试以下排查步骤： + +1. 确保 `kube-scheduler` 组件已启用 `DynamicResourceAllocation` 特性门控，并且使用的是 + [v1 配置 API](/zh-cn/docs/reference/config-api/kube-scheduler-config.v1/)。 + 如果你使用自定义配置，你可能还需额外启用 `DynamicResource` 插件。 + +2. 重启 `kube-apiserver` 和 `kube-controller-manager` 组件，以传播 API 组变更。 + + +## 安装设备驱动 {#install-drivers} + +你启用集群的 DRA 特性后，你可以安装所挂接设备的驱动。 +安装方式请参见设备所有者或驱动维护方提供的文档。你安装的驱动必须与 DRA 兼容。 + +若要验证驱动是否正常工作，可列出集群中的 ResourceSlice： + +```shell +kubectl get resourceslices +``` + + +输出示例如下： + +``` +NAME NODE DRIVER POOL AGE +cluster-1-device-pool-1-driver.example.com-lqx8x cluster-1-node-1 driver.example.com cluster-1-device-pool-1-r1gc 7s +cluster-1-device-pool-2-driver.example.com-29t7b cluster-1-node-2 driver.example.com cluster-1-device-pool-2-446z 8s +``` + + +## 创建 DeviceClass {#create-deviceclasses} + +你可以通过创建 +{{< glossary_tooltip text="DeviceClasses" term_id="deviceclass" >}} +定义设备的分类，供应用运维人员在工作负载中申领这些设备。 +某些设备驱动提供方也可能在驱动安装过程中要求你创建 DeviceClass。 + + +你的驱动所发布的 ResourceSlice 中包含了设备的相关信息，例如容量、元数据和属性。你可以使用 +{{< glossary_tooltip term_id="cel" >}} 表达式按 DeviceClass 中的属性进行筛选， +从而帮助工作负载运维人员更轻松地找到合适的设备。 + +1. 若要查看可通过 CEL 表达式在 DeviceClass 中选择的设备属性，你可以查看某个 ResourceSlice 的规约： + + ```shell + kubectl get resourceslice -o yaml + ``` + + + + 输出类似如下： + + + + ```yaml + apiVersion: resource.k8s.io/v1beta1 + kind: ResourceSlice + # 为简洁省略部分内容 + spec: + devices: + - basic: + attributes: + type: + string: gpu + capacity: + memory: + value: 64Gi + name: gpu-0 + - basic: + attributes: + type: + string: gpu + capacity: + memory: + value: 64Gi + name: gpu-1 + driver: driver.example.com + nodeName: cluster-1-node-1 + # 为简洁省略部分内容 + ``` + + + + 你也可以查阅驱动提供商的文档，了解可用的属性和对应值。 + + +2. 查看以下 DeviceClass 示例清单，它选择所有由 `driver.example.com` 设备驱动管理的设备： + + {{% code_sample file="dra/deviceclass.yaml" %}} + + +3. 在集群中创建 DeviceClass： + + ```shell + kubectl apply -f https://k8s.io/examples/dra/deviceclass.yaml + ``` + + +## 清理 {#clean-up} + +要删除本任务中创建的 DeviceClass，运行以下命令： + +```shell +kubectl delete -f https://k8s.io/examples/dra/deviceclass.yaml +``` + +## {{% heading "whatsnext" %}} + + +* [进一步了解 DRA](/zh-cn/docs/concepts/scheduling-eviction/dynamic-resource-allocation) +* [使用 DRA 为工作负载分配设备](/zh-cn/docs/tasks/configure-pod-container/assign-resources/allocate-devices-dra) diff --git a/content/zh-cn/docs/tasks/manage-daemon/update-daemon-set.md b/content/zh-cn/docs/tasks/manage-daemon/update-daemon-set.md index a524c092545c0..5991e70ab80ac 100644 --- a/content/zh-cn/docs/tasks/manage-daemon/update-daemon-set.md +++ b/content/zh-cn/docs/tasks/manage-daemon/update-daemon-set.md @@ -3,7 +3,6 @@ title: 对 DaemonSet 执行滚动更新 content_type: task weight: 10 --- - - * `OnDelete`：使用 `OnDelete` 更新策略时，在更新 DaemonSet 模板后，只有当你手动删除老的 DaemonSet Pod 之后，新的 DaemonSet Pod **才会**被自动创建。跟 Kubernetes 1.6 以前的版本类似。 * `RollingUpdate`：这是默认的更新策略。使用 `RollingUpdate` 更新策略时，在更新 DaemonSet 模板后， @@ -125,7 +123,7 @@ kubectl get ds/fluentd-elasticsearch -o go-template='{{.spec.updateStrategy.type If you haven't created the DaemonSet in the system, check your DaemonSet manifest with the following command instead: --> -如果还没在系统中创建 DaemonSet，请使用以下命令检查 DaemonSet 的清单： +如果你还没在系统中创建 DaemonSet，请使用以下命令检查 DaemonSet 的清单： ```shell kubectl apply -f https://k8s.io/examples/controllers/fluentd-daemonset.yaml --dry-run=client -o go-template='{{.spec.updateStrategy.type}}{{"\n"}}' @@ -272,12 +270,12 @@ make room for new DaemonSet pods. --> 一旦找到这些节点，从节点上删除一些非 DaemonSet Pod，为新的 DaemonSet Pod 腾出空间。 +{{< note >}} -{{< note >}} 当所删除的 Pod 不受任何控制器管理，也不是多副本的 Pod 时，上述操作将导致服务中断。 同时，上述操作也不会考虑 [PodDisruptionBudget](/zh-cn/docs/tasks/run-application/configure-pdb/) @@ -335,4 +333,3 @@ kubectl delete ds fluentd-elasticsearch -n kube-system --> * 查看[在 DaemonSet 上执行回滚](/zh-cn/docs/tasks/manage-daemon/rollback-daemon-set/) * 查看[创建 DaemonSet 以收养现有 DaemonSet Pod](/zh-cn/docs/concepts/workloads/controllers/daemonset/) - diff --git a/content/zh-cn/docs/tutorials/configuration/provision-swap-memory.md b/content/zh-cn/docs/tutorials/configuration/provision-swap-memory.md new file mode 100644 index 0000000000000..40619d38af28b --- /dev/null +++ b/content/zh-cn/docs/tutorials/configuration/provision-swap-memory.md @@ -0,0 +1,246 @@ +--- +title: 在 Kubernetes 节点上配置交换内存 +content_type: tutorial +weight: 35 +min-kubernetes-server-version: "1.33" +--- + + + + + +本文演示了如何使用 kubeadm 在 Kubernetes 节点上制备和启用交换内存。 + + + +## {{% heading "objectives" %}} + + +* 使用 kubeadm 在 Kubernetes 节点上制备交换内存。 +* 学习配置加密和未加密的交换内存。 +* 学习如何在系统启动时启用交换内存。 + +## {{% heading "prerequisites" %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + +你需要在集群中至少有一个运行 Linux 操作系统的工作节点。 +本次演示需要先安装 kubeadm 工具，安装步骤请参考 +[kubeadm 安装指南](/zh-cn/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm)。 + + +在每个需要配置交换内存的工作节点上，你需要以下工具： + +* `fallocate` +* `mkswap` +* `swapon` + +对于加密的交换空间（推荐），你还需要： + +* `cryptsetup` + + + + +## 使用 kubeadm 安装支持交换内存的集群 + +### 创建交换文件并启用交换内存 + +如果当前节点未启用交换内存，则需要先**制备**交换空间。 +本节将展示如何以加密和未加密的方式创建 4GiB 的交换文件。 + + +{{< tabs name="创建交换文件并启用交换内存" >}} + +{{% tab name="设置加密的交换内存" %}} + + +你可以使用如下命令设置加密的交换文件。 +请注意，此示例使用的是 `cryptsetup` 工具（在大多数 Linux 发行版中都可用）： + + +```bash +# 分配存储空间并限制访问权限 +fallocate --length 4GiB /swapfile +chmod 600 /swapfile + +# 基于已分配的存储空间创建加密设备 +cryptsetup --type plain --cipher aes-xts-plain64 --key-size 256 -d /dev/urandom open /swapfile cryptswap + +# 格式化此交换空间 +mkswap /dev/mapper/cryptswap + +# 为换页激活交换空间 +swapon /dev/mapper/cryptswap +``` + +{{% /tab %}} + + +{{% tab name="设置未加密的交换内存" %}} + +未加密的交换文件可以按以下方式配置： + +```bash +# 分配存储空间并限制访问权限 +fallocate --length 4GiB /swapfile +chmod 600 /swapfile + +# 格式化此交换空间 +mkswap /swapfile + +# 为换页激活交换空间 +swapon /swapfile +``` + +{{% /tab %}} + +{{< /tabs >}} + + +#### 验证交换内存是否启用 + +你可以使用 `swapon -s` 命令或 `free` 命令来验证交换内存是否启用。 + +使用 `swapon -s`： + +``` +Filename Type Size Used Priority +/dev/dm-0 partition 4194300 0 -2 +``` + +使用 `free -h`： + + +``` + total used free shared buff/cache available +Mem: 3.8Gi 1.3Gi 249Mi 25Mi 2.5Gi 2.5Gi +Swap: 4.0Gi 0B 4.0Gi +``` + + +#### 引导时启用交换内存 + +在设置好交换内存后，若要在系统引导时启动交换文件，通常有两种做法： +你可以设置一个 systemd 单元来激活（加密的）交换内存，或者在 +`/etc/fstab` 文件中添加类似于 `/swapfile swap swap defaults 0 0` 的行。 + +使用 systemd 激活交换内存，可以确保在交换内存可用之前延迟启动 kubelet（如果你有这个需求）。 +同样，使用 systemd 还可以让服务器在 kubelet（以及通常的容器运行时）关闭之前保持交换内存处于启用状态。 + + +### 配置 kubelet {#set-up-kubelet-configuration} + +在节点上启用交换内存后，需要按如下方式配置 kubelet： + +```yaml +# 此代码片段应添加到 kubelet 的配置文件中 +failSwapOn: false +memorySwap: + swapBehavior: LimitedSwap +``` + +为了使这些配置生效，需重启 kubelet。 diff --git a/content/zh-cn/docs/tutorials/kubernetes-basics/_index.md b/content/zh-cn/docs/tutorials/kubernetes-basics/_index.md index 2a4efce8df82b..4e20eff40b8cc 100644 --- a/content/zh-cn/docs/tutorials/kubernetes-basics/_index.md +++ b/content/zh-cn/docs/tutorials/kubernetes-basics/_index.md @@ -79,7 +79,7 @@ Kubernetes 是一个可用于生产环境的开源平台，基于 Google 在容 title="1. Create a Kubernetes cluster" >}} --> {{< tutorials/module - path="/zh-cn/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro/" + path="/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro/" image="/docs/tutorials/kubernetes-basics/public/images/module_01.svg?v=1469803628347" alt="模块一" title="1. 创建一个 Kubernetes 集群" >}} @@ -92,7 +92,7 @@ Kubernetes 是一个可用于生产环境的开源平台，基于 Google 在容 title="2. Deploy an app" >}} --> {{< tutorials/module - path="/zh-cn/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/" + path="/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/" image="/docs/tutorials/kubernetes-basics/public/images/module_02.svg?v=1469803628347" alt="模块二" title="2. 部署一个应用" >}} @@ -105,7 +105,7 @@ Kubernetes 是一个可用于生产环境的开源平台，基于 Google 在容 title="3. Explore your app" >}} --> {{< tutorials/module - path="/zh-cn/docs/tutorials/kubernetes-basics/explore/explore-intro/" + path="/docs/tutorials/kubernetes-basics/explore/explore-intro/" image="/docs/tutorials/kubernetes-basics/public/images/module_03.svg?v=1469803628347" alt="模块三" title="3. 访问你的应用" >}} @@ -118,7 +118,7 @@ Kubernetes 是一个可用于生产环境的开源平台，基于 Google 在容 title="4. Expose your app publicly" >}} --> {{< tutorials/module - path="/zh-cn/docs/tutorials/kubernetes-basics/expose/expose-intro/" + path="/docs/tutorials/kubernetes-basics/expose/expose-intro/" image="/docs/tutorials/kubernetes-basics/public/images/module_04.svg?v=1469803628347" alt="模块四" title="4. 公开发布你的应用" >}} @@ -131,7 +131,7 @@ Kubernetes 是一个可用于生产环境的开源平台，基于 Google 在容 title="5. Scale up your app" >}} --> {{< tutorials/module - path="/zh-cn/docs/tutorials/kubernetes-basics/scale/scale-intro/" + path="/docs/tutorials/kubernetes-basics/scale/scale-intro/" image="/docs/tutorials/kubernetes-basics/public/images/module_05.svg?v=1469803628347" alt="模块五" title="5. 扩大你的应用规模" >}} @@ -144,7 +144,7 @@ Kubernetes 是一个可用于生产环境的开源平台，基于 Google 在容 title="6. Update your app" >}} --> {{< tutorials/module - path="/zh-cn/docs/tutorials/kubernetes-basics/update/update-intro/" + path="/docs/tutorials/kubernetes-basics/update/update-intro/" image="/docs/tutorials/kubernetes-basics/public/images/module_06.svg?v=1469803628347" alt="模块六" title="6. 更新你的应用" >}} diff --git a/content/zh-cn/examples/controllers/daemonset.yaml b/content/zh-cn/examples/controllers/daemonset.yaml index c5260881f2f53..89298cb79621c 100644 --- a/content/zh-cn/examples/controllers/daemonset.yaml +++ b/content/zh-cn/examples/controllers/daemonset.yaml @@ -25,7 +25,7 @@ spec: effect: NoSchedule containers: - name: fluentd-elasticsearch - image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2 + image: quay.io/fluentd_elasticsearch/fluentd:v5.0.1 resources: limits: memory: 200Mi diff --git a/content/zh-cn/examples/controllers/fluentd-daemonset-update.yaml b/content/zh-cn/examples/controllers/fluentd-daemonset-update.yaml index 5c031f9156407..60befa7da56c9 100644 --- a/content/zh-cn/examples/controllers/fluentd-daemonset-update.yaml +++ b/content/zh-cn/examples/controllers/fluentd-daemonset-update.yaml @@ -29,7 +29,7 @@ spec: effect: NoSchedule containers: - name: fluentd-elasticsearch - image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2 + image: quay.io/fluentd_elasticsearch/fluentd:v5.0.1 resources: limits: memory: 200Mi diff --git a/content/zh-cn/examples/controllers/fluentd-daemonset.yaml b/content/zh-cn/examples/controllers/fluentd-daemonset.yaml index b6dcf64812f53..ad64155b0066d 100644 --- a/content/zh-cn/examples/controllers/fluentd-daemonset.yaml +++ b/content/zh-cn/examples/controllers/fluentd-daemonset.yaml @@ -25,7 +25,7 @@ spec: effect: NoSchedule containers: - name: fluentd-elasticsearch - image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2 + image: quay.io/fluentd_elasticsearch/fluentd:v5.0.1 volumeMounts: - name: varlog mountPath: /var/log diff --git a/content/zh-cn/examples/dra/deviceclass.yaml b/content/zh-cn/examples/dra/deviceclass.yaml new file mode 100644 index 0000000000000..dcad8e488bdfe --- /dev/null +++ b/content/zh-cn/examples/dra/deviceclass.yaml @@ -0,0 +1,9 @@ +apiVersion: resource.k8s.io/v1beta2 +kind: DeviceClass +metadata: + name: example-device-class +spec: + selectors: + - cel: + expression: |- + device.driver == "driver.example.com" diff --git a/content/zh-cn/examples/dra/dra-example-job.yaml b/content/zh-cn/examples/dra/dra-example-job.yaml new file mode 100644 index 0000000000000..4548406277228 --- /dev/null +++ b/content/zh-cn/examples/dra/dra-example-job.yaml @@ -0,0 +1,34 @@ +apiVersion: batch/v1 +kind: Job +metadata: + name: example-dra-job +spec: + completions: 10 + parallelism: 2 + template: + spec: + restartPolicy: Never + containers: + - name: container0 + image: ubuntu:24.04 + command: ["sleep", "9999"] + resources: + claims: + - name: separate-gpu-claim + - name: container1 + image: ubuntu:24.04 + command: ["sleep", "9999"] + resources: + claims: + - name: shared-gpu-claim + - name: container2 + image: ubuntu:24.04 + command: ["sleep", "9999"] + resources: + claims: + - name: shared-gpu-claim + resourceClaims: + - name: separate-gpu-claim + resourceClaimTemplateName: example-resource-claim-template + - name: shared-gpu-claim + resourceClaimName: example-resource-claim diff --git a/content/zh-cn/examples/dra/resourceclaim.yaml b/content/zh-cn/examples/dra/resourceclaim.yaml new file mode 100644 index 0000000000000..88c031d5a0d52 --- /dev/null +++ b/content/zh-cn/examples/dra/resourceclaim.yaml @@ -0,0 +1,16 @@ +apiVersion: resource.k8s.io/v1beta2 +kind: ResourceClaim +metadata: + name: example-resource-claim +spec: + devices: + requests: + - name: single-gpu-claim + exactly: + deviceClassName: example-device-class + allocationMode: All + selectors: + - cel: + expression: |- + device.attributes["driver.example.com"].type == "gpu" && + device.capacity["driver.example.com"].memory == quantity("64Gi") diff --git a/content/zh-cn/examples/dra/resourceclaimtemplate.yaml b/content/zh-cn/examples/dra/resourceclaimtemplate.yaml new file mode 100644 index 0000000000000..83e9c63b1b627 --- /dev/null +++ b/content/zh-cn/examples/dra/resourceclaimtemplate.yaml @@ -0,0 +1,16 @@ +apiVersion: resource.k8s.io/v1beta2 +kind: ResourceClaimTemplate +metadata: + name: example-resource-claim-template +spec: + spec: + devices: + requests: + - name: gpu-claim + exactly: + deviceClassName: example-device-class + selectors: + - cel: + expression: |- + device.attributes["driver.example.com"].type == "gpu" && + device.capacity["driver.example.com"].memory == quantity("64Gi") diff --git a/data/releases/eol.yaml b/data/releases/eol.yaml index 8e39bbbbdb2f9..2b9555bfcc12a 100644 --- a/data/releases/eol.yaml +++ b/data/releases/eol.yaml @@ -4,6 +4,9 @@ # schedule-builder -uc data/releases/schedule.yaml -e data/releases/eol.yaml --- branches: +- endOfLifeDate: "2025-07-15" + finalPatchRelease: 1.30.14 + release: "1.30" - endOfLifeDate: "2025-02-28" finalPatchRelease: 1.29.14 release: "1.29" diff --git a/data/releases/schedule.yaml b/data/releases/schedule.yaml index 722bd68b1e7ae..f23e28ad4dee8 100644 --- a/data/releases/schedule.yaml +++ b/data/releases/schedule.yaml @@ -7,10 +7,13 @@ schedules: - endOfLifeDate: "2026-06-28" maintenanceModeStartDate: "2026-04-28" next: - cherryPickDeadline: "2025-07-11" + cherryPickDeadline: "2025-08-08" + release: 1.33.4 + targetDate: "2025-08-12" + previousPatches: + - cherryPickDeadline: "2025-07-11" release: 1.33.3 targetDate: "2025-07-15" - previousPatches: - cherryPickDeadline: "2025-06-06" release: 1.33.2 targetDate: "2025-06-17" @@ -22,10 +25,13 @@ schedules: - endOfLifeDate: "2026-02-28" maintenanceModeStartDate: "2025-12-28" next: - cherryPickDeadline: "2025-07-11" + cherryPickDeadline: "2025-08-08" + release: 1.32.8 + targetDate: "2025-08-12" + previousPatches: + - cherryPickDeadline: "2025-07-11" release: 1.32.7 targetDate: "2025-07-15" - previousPatches: - cherryPickDeadline: "2025-06-06" release: 1.32.6 targetDate: "2025-06-17" @@ -51,10 +57,13 @@ schedules: - endOfLifeDate: "2025-10-28" maintenanceModeStartDate: "2025-08-28" next: - cherryPickDeadline: "2025-07-11" + cherryPickDeadline: "2025-08-08" + release: 1.31.12 + targetDate: "2025-08-12" + previousPatches: + - cherryPickDeadline: "2025-07-11" release: 1.31.11 targetDate: "2025-07-15" - previousPatches: - cherryPickDeadline: "2025-06-06" release: 1.31.10 targetDate: "2025-06-17" @@ -89,63 +98,10 @@ schedules: targetDate: "2024-08-13" release: "1.31" releaseDate: "2024-08-13" -- endOfLifeDate: "2025-06-28" - maintenanceModeStartDate: "2025-04-28" - next: - cherryPickDeadline: "2025-07-11" - release: 1.30.15 - targetDate: "2025-07-15" - previousPatches: - - cherryPickDeadline: "2025-06-06" - release: 1.30.14 - targetDate: "2025-06-17" - - cherryPickDeadline: "2025-05-09" - release: 1.30.13 - targetDate: "2025-05-15" - - cherryPickDeadline: "2025-04-11" - release: 1.30.12 - targetDate: "2025-04-22" - - cherryPickDeadline: "2025-03-07" - release: 1.30.11 - targetDate: "2025-03-11" - - cherryPickDeadline: "2025-02-07" - release: 1.30.10 - targetDate: "2025-02-11" - - cherryPickDeadline: "2025-01-10" - release: 1.30.9 - targetDate: "2025-01-14" - - cherryPickDeadline: "2024-12-06" - release: 1.30.8 - targetDate: "2024-12-10" - - cherryPickDeadline: "2024-11-15" - release: 1.30.7 - targetDate: "2024-11-19" - - cherryPickDeadline: "2024-10-11" - release: 1.30.6 - targetDate: "2024-10-22" - - cherryPickDeadline: "2024-09-06" - release: 1.30.5 - targetDate: "2024-09-10" - - cherryPickDeadline: "2024-08-09" - release: 1.30.4 - targetDate: "2024-08-14" - - cherryPickDeadline: "2024-07-12" - release: 1.30.3 - targetDate: "2024-07-16" - - cherryPickDeadline: "2024-06-07" - release: 1.30.2 - targetDate: "2024-06-11" - - cherryPickDeadline: "2024-05-10" - release: 1.30.1 - targetDate: "2024-05-15" - - release: 1.30.0 - targetDate: "2024-04-17" - release: "1.30" - releaseDate: "2024-04-17" upcoming_releases: -- cherryPickDeadline: "2025-07-11" - targetDate: "2025-07-15" - cherryPickDeadline: "2025-08-08" targetDate: "2025-08-12" - cherryPickDeadline: "2025-09-05" targetDate: "2025-09-09" +- cherryPickDeadline: "2025-10-10" + targetDate: "2025-10-14" diff --git a/hugo.toml b/hugo.toml index 04ef3e55a53f1..88de0f7b0943f 100644 --- a/hugo.toml +++ b/hugo.toml @@ -568,3 +568,11 @@ target = "i18n" [[module.mounts]] source = "i18n/zh-cn" target = "i18n" + +[segments] + [segments.all] + [[segments.all.includes]] + path = '{/**}' + [segments.en] + [[segments.en.includes]] + lang = 'en' \ No newline at end of file

      -用来过滤的选择算符（标签查询），支持 '='、'==' 和 '!='（例如 -l key1=value1,key2=value2）。 +过滤所用的选择算符（标签查询），支持 '='、'=='、'!='、'in' 和 'notin'。 +（例如 -l key1=value1,key2=value2,key3 in (value3)）。 匹配的对象必须满足所有指定的标签约束。