Merge pull request #40595 from mickeyboxell/merged-main-dev-1.27
Merged main dev 1.27pull/40599/head
Kubernetes Prow Robot
GitHub
commit
b03edfa3fd
|
|
@ -0,0 +1,77 @@
|
|||
---
|
||||
layout: blog
|
||||
title: "Keeping Kubernetes Secure with Updated Go Versions"
|
||||
date: 2023-04-06
|
||||
slug: keeping-kubernetes-secure-with-updated-go-versions
|
||||
---
|
||||
|
||||
**Author**: [Jordan Liggitt](https://github.com/liggitt) (Google)
|
||||
|
||||
### The problem
|
||||
|
||||
Since v1.19 (released in 2020), the Kubernetes project provides 12-14 months of patch releases for each minor version.
|
||||
This enables users to qualify and adopt Kubernetes versions in an annual upgrade cycle and receive security fixes for a year.
|
||||
|
||||
The [Go project](https://github.com/golang/go/wiki/Go-Release-Cycle#release-maintenance) releases new minor versions twice a year,
|
||||
and provides security fixes for the last two minor versions, resulting in about a year of support for each Go version.
|
||||
Even though each new Kubernetes minor version is built with a supported Go version when it is first released,
|
||||
that Go version falls out of support before the Kubernetes minor version does,
|
||||
and the lengthened Kubernetes patch support since v1.19 only widened that gap.
|
||||
|
||||
At the time this was written, just over half of all [Go patch releases](https://go.dev/doc/devel/release) (88/171) have contained fixes for issues with possible security implications.
|
||||
Even though many of these issues were not relevant to Kubernetes, some were, so it remained important to use supported Go versions that received those fixes.
|
||||
|
||||
An obvious solution would be to simply update Kubernetes release branches to new minor versions of Go.
|
||||
However, Kubernetes avoids [destabilizing changes in patch releases](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-release/cherry-picks.md#what-kind-of-prs-are-good-for-cherry-picks),
|
||||
and historically, this prevented updating existing release branches to new minor versions of Go, due to changes that were considered prohibitively complex, risky, or breaking to include in a patch release.
|
||||
Examples include:
|
||||
|
||||
* Go 1.6: enabling http/2 by default
|
||||
* Go 1.14: EINTR handling issues
|
||||
* Go 1.17: dropping x509 CN support, ParseIP changes
|
||||
* Go 1.18: disabling x509 SHA-1 certificate support by default
|
||||
* Go 1.19: dropping current-dir LookPath behavior
|
||||
|
||||
Some of these changes could be easily mitigated in Kubernetes code,
|
||||
some could only be opted out of via a user-specified `GODEBUG` envvar,
|
||||
and others required invasive code changes or could not be avoided at all.
|
||||
Because of this inconsistency, Kubernetes release branches have typically remained on a single Go minor version,
|
||||
and risked being unable to pick up relevant Go security fixes for the last several months of each Kubernetes minor version's support lifetime.
|
||||
|
||||
When a relevant Go security fix was only available in newer Kubernetes minor versions,
|
||||
users would have to upgrade away from older Kubernetes minor versions before their 12-14 month support period ended, just to pick up those fixes.
|
||||
If a user was not prepared to do that upgrade, it could result in vulnerable Kubernetes clusters.
|
||||
Even if a user could accommodate the unexpected upgrade, the uncertainty made Kubernetes' annual support less reliable for planning.
|
||||
|
||||
### The solution
|
||||
|
||||
We're happy to announce that the gap between supported Kubernetes versions and supported Go versions has been resolved as of January 2023.
|
||||
|
||||
We worked closely with the Go team over the past year to address the difficulties adopting new Go versions.
|
||||
This prompted a [discussion](https://github.com/golang/go/discussions/55090), [proposal](https://github.com/golang/go/issues/56986),
|
||||
[talk at GopherCon](https://www.youtube.com/watch?v=v24wrd3RwGo), and a [design](https://go.dev/design/56986-godebug) for improving backward compatibility in Go,
|
||||
ensuring new Go versions can maintain compatible runtime behavior with previous Go versions for a minimum of two years (four Go releases).
|
||||
This allows projects like Kubernetes to update release branches to supported Go versions without exposing users to behavior changes.
|
||||
|
||||
The proposed improvements are on track to be [included in Go 1.21](https://tip.golang.org/doc/godebug), and the Go team already delivered targeted compatibility improvements in a Go 1.19 patch release in late 2022.
|
||||
Those changes enabled Kubernetes 1.23+ to update to Go 1.19 in January of 2023, while avoiding any user-facing configuration or behavior changes.
|
||||
All supported Kubernetes release branches now use supported Go versions, and can pick up new Go patch releases with available security fixes.
|
||||
|
||||
Going forward, Kubernetes maintainers remain committed to making Kubernetes patch releases as safe and non-disruptive as possible,
|
||||
so there are several requirements a new Go minor version must meet before existing Kubernetes release branches will update to use it:
|
||||
|
||||
1. The new Go version must be available for at least 3 months.
|
||||
This gives time for adoption by the Go community, and for reports of issues or regressions.
|
||||
2. The new Go version must be used in a new Kubernetes minor release for at least 1 month.
|
||||
This ensures all Kubernetes release-blocking tests pass on the new Go version,
|
||||
and gives time for feedback from the Kubernetes community on release candidates and early adoption of the new minor release.
|
||||
3. There must be no regressions from the previous Go version known to impact Kubernetes.
|
||||
4. Runtime behavior must be preserved by default, without requiring any action by Kubernetes users / administrators.
|
||||
5. Kubernetes libraries like `k8s.io/client-go` must remain compatible with the original Go version used for each minor release,
|
||||
so consumers won't *have* to update Go versions to pick up a library patch release (though they are encouraged to build with supported Go versions,
|
||||
which is made even easier with the [compatibility improvements](https://go.dev/design/56986-godebug) planned in Go 1.21).
|
||||
|
||||
The goal of all of this work is to unobtrusively make Kubernetes patch releases safer and more secure,
|
||||
and to make Kubernetes minor versions safe to use for the entire duration of their support lifetime.
|
||||
|
||||
Many thanks to the Go team, especially Russ Cox, for helping drive these improvements in ways that will benefit all Go users, not just Kubernetes.
|
||||
|
|
@ -180,4 +180,4 @@ configure garbage collection:
|
|||
|
||||
* Learn more about [ownership of Kubernetes objects](/docs/concepts/overview/working-with-objects/owners-dependents/).
|
||||
* Learn more about Kubernetes [finalizers](/docs/concepts/overview/working-with-objects/finalizers/).
|
||||
* Learn about the [TTL controller](/docs/concepts/workloads/controllers/ttlafterfinished/) (beta) that cleans up finished Jobs.
|
||||
* Learn about the [TTL controller](/docs/concepts/workloads/controllers/ttlafterfinished/) that cleans up finished Jobs.
|
||||
|
|
|
|||
|
|
@ -214,14 +214,14 @@ a replacement.
|
|||
There are two reasons for this restriction:
|
||||
|
||||
1. Making `roleRef` immutable allows granting someone `update` permission on an existing binding
|
||||
object, so that they can manage the list of subjects, without being able to change
|
||||
the role that is granted to those subjects.
|
||||
object, so that they can manage the list of subjects, without being able to change
|
||||
the role that is granted to those subjects.
|
||||
1. A binding to a different role is a fundamentally different binding.
|
||||
Requiring a binding to be deleted/recreated in order to change the `roleRef`
|
||||
ensures the full list of subjects in the binding is intended to be granted
|
||||
the new role (as opposed to enabling or accidentally modifying only the roleRef
|
||||
without verifying all of the existing subjects should be given the new role's
|
||||
permissions).
|
||||
Requiring a binding to be deleted/recreated in order to change the `roleRef`
|
||||
ensures the full list of subjects in the binding is intended to be granted
|
||||
the new role (as opposed to enabling or accidentally modifying only the roleRef
|
||||
without verifying all of the existing subjects should be given the new role's
|
||||
permissions).
|
||||
|
||||
The `kubectl auth reconcile` command-line utility creates or updates a manifest file containing RBAC objects,
|
||||
and handles deleting and recreating binding objects if required to change the role they refer to.
|
||||
|
|
@ -261,7 +261,6 @@ When specified, requests can be restricted to individual instances of a resource
|
|||
Here is an example that restricts its subject to only `get` or `update` a
|
||||
{{< glossary_tooltip term_id="ConfigMap" >}} named `my-configmap`:
|
||||
|
||||
|
||||
```yaml
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: Role
|
||||
|
|
@ -285,16 +284,20 @@ If you restrict `list` or `watch` by resourceName, clients must include a `metad
|
|||
For example, `kubectl get configmaps --field-selector=metadata.name=my-configmap`
|
||||
{{< /note >}}
|
||||
|
||||
Rather than referring to individual `resources` and `verbs` you can use the wildcard `*` symbol to refer to all such objects.
|
||||
For `nonResourceURLs` you can use the wildcard `*` symbol as a suffix glob match and for `apiGroups` and `resourceNames` an empty set means that everything is allowed.
|
||||
Here is an example that allows access to perform any current and future action on all current and future resources (note, this is similar to the built-in `cluster-admin` role).
|
||||
Rather than referring to individual `resources`、`apiGroups`, and `verbs`,
|
||||
you can use the wildcard `*` symbol to refer to all such objects.
|
||||
For `nonResourceURLs`, you can use the wildcard `*` as a suffix glob match.
|
||||
For `resourceNames`, an empty set means that everything is allowed.
|
||||
Here is an example that allows access to perform any current and future action on
|
||||
all current and future resources in the `example.com` API group.
|
||||
This is similar to the built-in `cluster-admin` role.
|
||||
|
||||
```yaml
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: Role
|
||||
metadata:
|
||||
namespace: default
|
||||
name: example.com-superuser # DO NOT USE THIS ROLE, IT IS JUST AN EXAMPLE
|
||||
name: example.com-superuser # DO NOT USE THIS ROLE, IT IS JUST AN EXAMPLE
|
||||
rules:
|
||||
- apiGroups: ["example.com"]
|
||||
resources: ["*"]
|
||||
|
|
@ -302,12 +305,15 @@ rules:
|
|||
```
|
||||
|
||||
{{< caution >}}
|
||||
Using wildcards in resource and verb entries could result in overly permissive access being granted to sensitive resources.
|
||||
For instance, if a new resource type is added, or a new subresource is added, or a new custom verb is checked, the wildcard entry automatically grants access, which may be undesirable.
|
||||
The [principle of least privilege](/docs/concepts/security/rbac-good-practices/#least-privilege) should be employed, using specific resources and verbs to ensure only the permissions required for the workload to function correctly are applied.
|
||||
Using wildcards in resource and verb entries could result in overly permissive access being granted
|
||||
to sensitive resources.
|
||||
For instance, if a new resource type is added, or a new subresource is added,
|
||||
or a new custom verb is checked, the wildcard entry automatically grants access, which may be undesirable.
|
||||
The [principle of least privilege](/docs/concepts/security/rbac-good-practices/#least-privilege)
|
||||
should be employed, using specific resources and verbs to ensure only the permissions required for the
|
||||
workload to function correctly are applied.
|
||||
{{< /caution >}}
|
||||
|
||||
|
||||
### Aggregated ClusterRoles
|
||||
|
||||
You can _aggregate_ several ClusterRoles into one combined ClusterRole.
|
||||
|
|
@ -489,7 +495,7 @@ Subjects can be groups, users or
|
|||
|
||||
Kubernetes represents usernames as strings.
|
||||
These can be: plain names, such as "alice"; email-style names, like "bob@example.com";
|
||||
or numeric user IDs represented as a string. It is up to you as a cluster administrator
|
||||
or numeric user IDs represented as a string. It is up to you as a cluster administrator
|
||||
to configure the [authentication modules](/docs/reference/access-authn-authz/authentication/)
|
||||
so that authentication produces usernames in the format you want.
|
||||
|
||||
|
|
@ -621,7 +627,10 @@ Auto-reconciliation is enabled by default if the RBAC authorizer is active.
|
|||
|
||||
### API discovery roles {#discovery-roles}
|
||||
|
||||
Default role bindings authorize unauthenticated and authenticated users to read API information that is deemed safe to be publicly accessible (including CustomResourceDefinitions). To disable anonymous unauthenticated access, add `--anonymous-auth=false` to the API server configuration.
|
||||
Default role bindings authorize unauthenticated and authenticated users to read API information
|
||||
that is deemed safe to be publicly accessible (including CustomResourceDefinitions).
|
||||
To disable anonymous unauthenticated access, add `--anonymous-auth=false` to
|
||||
the API server configuration.
|
||||
|
||||
To view the configuration of these roles via `kubectl` run:
|
||||
|
||||
|
|
@ -896,16 +905,20 @@ Because this is enforced at the API level, it applies even when the RBAC authori
|
|||
You can only create/update a role if at least one of the following things is true:
|
||||
|
||||
1. You already have all the permissions contained in the role, at the same scope as the object being modified
|
||||
(cluster-wide for a ClusterRole, within the same namespace or cluster-wide for a Role).
|
||||
2. You are granted explicit permission to perform the `escalate` verb on the `roles` or `clusterroles` resource in the `rbac.authorization.k8s.io` API group.
|
||||
(cluster-wide for a ClusterRole, within the same namespace or cluster-wide for a Role).
|
||||
2. You are granted explicit permission to perform the `escalate` verb on the `roles` or
|
||||
`clusterroles` resource in the `rbac.authorization.k8s.io` API group.
|
||||
|
||||
For example, if `user-1` does not have the ability to list Secrets cluster-wide, they cannot create a ClusterRole
|
||||
containing that permission. To allow a user to create/update roles:
|
||||
|
||||
1. Grant them a role that allows them to create/update Role or ClusterRole objects, as desired.
|
||||
2. Grant them permission to include specific permissions in the roles they create/update:
|
||||
* implicitly, by giving them those permissions (if they attempt to create or modify a Role or ClusterRole with permissions they themselves have not been granted, the API request will be forbidden)
|
||||
* or explicitly allow specifying any permission in a `Role` or `ClusterRole` by giving them permission to perform the `escalate` verb on `roles` or `clusterroles` resources in the `rbac.authorization.k8s.io` API group
|
||||
* implicitly, by giving them those permissions (if they attempt to create or modify a Role or
|
||||
ClusterRole with permissions they themselves have not been granted, the API request will be forbidden)
|
||||
* or explicitly allow specifying any permission in a `Role` or `ClusterRole` by giving them
|
||||
permission to perform the `escalate` verb on `roles` or `clusterroles` resources in the
|
||||
`rbac.authorization.k8s.io` API group
|
||||
|
||||
### Restrictions on role binding creation or update
|
||||
|
||||
|
|
@ -916,8 +929,8 @@ to a role that grants that permission. To allow a user to create/update role bin
|
|||
|
||||
1. Grant them a role that allows them to create/update RoleBinding or ClusterRoleBinding objects, as desired.
|
||||
2. Grant them permissions needed to bind a particular role:
|
||||
* implicitly, by giving them the permissions contained in the role.
|
||||
* explicitly, by giving them permission to perform the `bind` verb on the particular Role (or ClusterRole).
|
||||
* implicitly, by giving them the permissions contained in the role.
|
||||
* explicitly, by giving them permission to perform the `bind` verb on the particular Role (or ClusterRole).
|
||||
|
||||
For example, this ClusterRole and RoleBinding would allow `user-1` to grant other users the `admin`, `edit`, and `view` roles in the namespace `user-1-namespace`:
|
||||
|
||||
|
|
@ -964,33 +977,33 @@ Creates a Role object defining permissions within a single namespace. Examples:
|
|||
|
||||
* Create a Role named "pod-reader" that allows users to perform `get`, `watch` and `list` on pods:
|
||||
|
||||
```shell
|
||||
kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=pods
|
||||
```
|
||||
```shell
|
||||
kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=pods
|
||||
```
|
||||
|
||||
* Create a Role named "pod-reader" with resourceNames specified:
|
||||
|
||||
```shell
|
||||
kubectl create role pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod
|
||||
```
|
||||
```shell
|
||||
kubectl create role pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod
|
||||
```
|
||||
|
||||
* Create a Role named "foo" with apiGroups specified:
|
||||
|
||||
```shell
|
||||
kubectl create role foo --verb=get,list,watch --resource=replicasets.apps
|
||||
```
|
||||
```shell
|
||||
kubectl create role foo --verb=get,list,watch --resource=replicasets.apps
|
||||
```
|
||||
|
||||
* Create a Role named "foo" with subresource permissions:
|
||||
|
||||
```shell
|
||||
kubectl create role foo --verb=get,list,watch --resource=pods,pods/status
|
||||
```
|
||||
```shell
|
||||
kubectl create role foo --verb=get,list,watch --resource=pods,pods/status
|
||||
```
|
||||
|
||||
* Create a Role named "my-component-lease-holder" with permissions to get/update a resource with a specific name:
|
||||
|
||||
```shell
|
||||
kubectl create role my-component-lease-holder --verb=get,list,watch,update --resource=lease --resource-name=my-component
|
||||
```
|
||||
```shell
|
||||
kubectl create role my-component-lease-holder --verb=get,list,watch,update --resource=lease --resource-name=my-component
|
||||
```
|
||||
|
||||
### `kubectl create clusterrole`
|
||||
|
||||
|
|
@ -998,39 +1011,39 @@ Creates a ClusterRole. Examples:
|
|||
|
||||
* Create a ClusterRole named "pod-reader" that allows user to perform `get`, `watch` and `list` on pods:
|
||||
|
||||
```shell
|
||||
kubectl create clusterrole pod-reader --verb=get,list,watch --resource=pods
|
||||
```
|
||||
```shell
|
||||
kubectl create clusterrole pod-reader --verb=get,list,watch --resource=pods
|
||||
```
|
||||
|
||||
* Create a ClusterRole named "pod-reader" with resourceNames specified:
|
||||
|
||||
```shell
|
||||
kubectl create clusterrole pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod
|
||||
```
|
||||
```shell
|
||||
kubectl create clusterrole pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod
|
||||
```
|
||||
|
||||
* Create a ClusterRole named "foo" with apiGroups specified:
|
||||
|
||||
```shell
|
||||
kubectl create clusterrole foo --verb=get,list,watch --resource=replicasets.apps
|
||||
```
|
||||
```shell
|
||||
kubectl create clusterrole foo --verb=get,list,watch --resource=replicasets.apps
|
||||
```
|
||||
|
||||
* Create a ClusterRole named "foo" with subresource permissions:
|
||||
|
||||
```shell
|
||||
kubectl create clusterrole foo --verb=get,list,watch --resource=pods,pods/status
|
||||
```
|
||||
```shell
|
||||
kubectl create clusterrole foo --verb=get,list,watch --resource=pods,pods/status
|
||||
```
|
||||
|
||||
* Create a ClusterRole named "foo" with nonResourceURL specified:
|
||||
|
||||
```shell
|
||||
kubectl create clusterrole "foo" --verb=get --non-resource-url=/logs/*
|
||||
```
|
||||
```shell
|
||||
kubectl create clusterrole "foo" --verb=get --non-resource-url=/logs/*
|
||||
```
|
||||
|
||||
* Create a ClusterRole named "monitoring" with an aggregationRule specified:
|
||||
|
||||
```shell
|
||||
kubectl create clusterrole monitoring --aggregation-rule="rbac.example.com/aggregate-to-monitoring=true"
|
||||
```
|
||||
```shell
|
||||
kubectl create clusterrole monitoring --aggregation-rule="rbac.example.com/aggregate-to-monitoring=true"
|
||||
```
|
||||
|
||||
### `kubectl create rolebinding`
|
||||
|
||||
|
|
@ -1038,21 +1051,21 @@ Grants a Role or ClusterRole within a specific namespace. Examples:
|
|||
|
||||
* Within the namespace "acme", grant the permissions in the "admin" ClusterRole to a user named "bob":
|
||||
|
||||
```shell
|
||||
kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=acme
|
||||
```
|
||||
```shell
|
||||
kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=acme
|
||||
```
|
||||
|
||||
* Within the namespace "acme", grant the permissions in the "view" ClusterRole to the service account in the namespace "acme" named "myapp":
|
||||
|
||||
```shell
|
||||
kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=acme
|
||||
```
|
||||
```shell
|
||||
kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=acme
|
||||
```
|
||||
|
||||
* Within the namespace "acme", grant the permissions in the "view" ClusterRole to a service account in the namespace "myappnamespace" named "myapp":
|
||||
|
||||
```shell
|
||||
kubectl create rolebinding myappnamespace-myapp-view-binding --clusterrole=view --serviceaccount=myappnamespace:myapp --namespace=acme
|
||||
```
|
||||
```shell
|
||||
kubectl create rolebinding myappnamespace-myapp-view-binding --clusterrole=view --serviceaccount=myappnamespace:myapp --namespace=acme
|
||||
```
|
||||
|
||||
### `kubectl create clusterrolebinding`
|
||||
|
||||
|
|
@ -1060,21 +1073,21 @@ Grants a ClusterRole across the entire cluster (all namespaces). Examples:
|
|||
|
||||
* Across the entire cluster, grant the permissions in the "cluster-admin" ClusterRole to a user named "root":
|
||||
|
||||
```shell
|
||||
kubectl create clusterrolebinding root-cluster-admin-binding --clusterrole=cluster-admin --user=root
|
||||
```
|
||||
```shell
|
||||
kubectl create clusterrolebinding root-cluster-admin-binding --clusterrole=cluster-admin --user=root
|
||||
```
|
||||
|
||||
* Across the entire cluster, grant the permissions in the "system:node-proxier" ClusterRole to a user named "system:kube-proxy":
|
||||
|
||||
```shell
|
||||
kubectl create clusterrolebinding kube-proxy-binding --clusterrole=system:node-proxier --user=system:kube-proxy
|
||||
```
|
||||
```shell
|
||||
kubectl create clusterrolebinding kube-proxy-binding --clusterrole=system:node-proxier --user=system:kube-proxy
|
||||
```
|
||||
|
||||
* Across the entire cluster, grant the permissions in the "view" ClusterRole to a service account named "myapp" in the namespace "acme":
|
||||
|
||||
```shell
|
||||
kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp
|
||||
```
|
||||
```shell
|
||||
kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp
|
||||
```
|
||||
|
||||
### `kubectl auth reconcile` {#kubectl-auth-reconcile}
|
||||
|
||||
|
|
@ -1092,21 +1105,21 @@ Examples:
|
|||
|
||||
* Test applying a manifest file of RBAC objects, displaying changes that would be made:
|
||||
|
||||
```
|
||||
kubectl auth reconcile -f my-rbac-rules.yaml --dry-run=client
|
||||
```
|
||||
```shell
|
||||
kubectl auth reconcile -f my-rbac-rules.yaml --dry-run=client
|
||||
```
|
||||
|
||||
* Apply a manifest file of RBAC objects, preserving any extra permissions (in roles) and any extra subjects (in bindings):
|
||||
|
||||
```shell
|
||||
kubectl auth reconcile -f my-rbac-rules.yaml
|
||||
```
|
||||
```shell
|
||||
kubectl auth reconcile -f my-rbac-rules.yaml
|
||||
```
|
||||
|
||||
* Apply a manifest file of RBAC objects, removing any extra permissions (in roles) and any extra subjects (in bindings):
|
||||
|
||||
```shell
|
||||
kubectl auth reconcile -f my-rbac-rules.yaml --remove-extra-subjects --remove-extra-permissions
|
||||
```
|
||||
```shell
|
||||
kubectl auth reconcile -f my-rbac-rules.yaml --remove-extra-subjects --remove-extra-permissions
|
||||
```
|
||||
|
||||
## ServiceAccount permissions {#service-account-permissions}
|
||||
|
||||
|
|
@ -1123,93 +1136,93 @@ In order from most secure to least secure, the approaches are:
|
|||
|
||||
1. Grant a role to an application-specific service account (best practice)
|
||||
|
||||
This requires the application to specify a `serviceAccountName` in its pod spec,
|
||||
and for the service account to be created (via the API, application manifest, `kubectl create serviceaccount`, etc.).
|
||||
This requires the application to specify a `serviceAccountName` in its pod spec,
|
||||
and for the service account to be created (via the API, application manifest, `kubectl create serviceaccount`, etc.).
|
||||
|
||||
For example, grant read-only permission within "my-namespace" to the "my-sa" service account:
|
||||
For example, grant read-only permission within "my-namespace" to the "my-sa" service account:
|
||||
|
||||
```shell
|
||||
kubectl create rolebinding my-sa-view \
|
||||
--clusterrole=view \
|
||||
--serviceaccount=my-namespace:my-sa \
|
||||
--namespace=my-namespace
|
||||
```
|
||||
```shell
|
||||
kubectl create rolebinding my-sa-view \
|
||||
--clusterrole=view \
|
||||
--serviceaccount=my-namespace:my-sa \
|
||||
--namespace=my-namespace
|
||||
```
|
||||
|
||||
2. Grant a role to the "default" service account in a namespace
|
||||
|
||||
If an application does not specify a `serviceAccountName`, it uses the "default" service account.
|
||||
If an application does not specify a `serviceAccountName`, it uses the "default" service account.
|
||||
|
||||
{{< note >}}
|
||||
Permissions given to the "default" service account are available to any pod
|
||||
in the namespace that does not specify a `serviceAccountName`.
|
||||
{{< /note >}}
|
||||
{{< note >}}
|
||||
Permissions given to the "default" service account are available to any pod
|
||||
in the namespace that does not specify a `serviceAccountName`.
|
||||
{{< /note >}}
|
||||
|
||||
For example, grant read-only permission within "my-namespace" to the "default" service account:
|
||||
For example, grant read-only permission within "my-namespace" to the "default" service account:
|
||||
|
||||
```shell
|
||||
kubectl create rolebinding default-view \
|
||||
--clusterrole=view \
|
||||
--serviceaccount=my-namespace:default \
|
||||
--namespace=my-namespace
|
||||
```
|
||||
```shell
|
||||
kubectl create rolebinding default-view \
|
||||
--clusterrole=view \
|
||||
--serviceaccount=my-namespace:default \
|
||||
--namespace=my-namespace
|
||||
```
|
||||
|
||||
Many [add-ons](/docs/concepts/cluster-administration/addons/) run as the
|
||||
"default" service account in the `kube-system` namespace.
|
||||
To allow those add-ons to run with super-user access, grant cluster-admin
|
||||
permissions to the "default" service account in the `kube-system` namespace.
|
||||
Many [add-ons](/docs/concepts/cluster-administration/addons/) run as the
|
||||
"default" service account in the `kube-system` namespace.
|
||||
To allow those add-ons to run with super-user access, grant cluster-admin
|
||||
permissions to the "default" service account in the `kube-system` namespace.
|
||||
|
||||
{{< caution >}}
|
||||
Enabling this means the `kube-system` namespace contains Secrets
|
||||
that grant super-user access to your cluster's API.
|
||||
{{< /caution >}}
|
||||
{{< caution >}}
|
||||
Enabling this means the `kube-system` namespace contains Secrets
|
||||
that grant super-user access to your cluster's API.
|
||||
{{< /caution >}}
|
||||
|
||||
```shell
|
||||
kubectl create clusterrolebinding add-on-cluster-admin \
|
||||
--clusterrole=cluster-admin \
|
||||
--serviceaccount=kube-system:default
|
||||
```
|
||||
```shell
|
||||
kubectl create clusterrolebinding add-on-cluster-admin \
|
||||
--clusterrole=cluster-admin \
|
||||
--serviceaccount=kube-system:default
|
||||
```
|
||||
|
||||
3. Grant a role to all service accounts in a namespace
|
||||
|
||||
If you want all applications in a namespace to have a role, no matter what service account they use,
|
||||
you can grant a role to the service account group for that namespace.
|
||||
If you want all applications in a namespace to have a role, no matter what service account they use,
|
||||
you can grant a role to the service account group for that namespace.
|
||||
|
||||
For example, grant read-only permission within "my-namespace" to all service accounts in that namespace:
|
||||
For example, grant read-only permission within "my-namespace" to all service accounts in that namespace:
|
||||
|
||||
```shell
|
||||
kubectl create rolebinding serviceaccounts-view \
|
||||
--clusterrole=view \
|
||||
--group=system:serviceaccounts:my-namespace \
|
||||
--namespace=my-namespace
|
||||
```
|
||||
```shell
|
||||
kubectl create rolebinding serviceaccounts-view \
|
||||
--clusterrole=view \
|
||||
--group=system:serviceaccounts:my-namespace \
|
||||
--namespace=my-namespace
|
||||
```
|
||||
|
||||
4. Grant a limited role to all service accounts cluster-wide (discouraged)
|
||||
|
||||
If you don't want to manage permissions per-namespace, you can grant a cluster-wide role to all service accounts.
|
||||
If you don't want to manage permissions per-namespace, you can grant a cluster-wide role to all service accounts.
|
||||
|
||||
For example, grant read-only permission across all namespaces to all service accounts in the cluster:
|
||||
For example, grant read-only permission across all namespaces to all service accounts in the cluster:
|
||||
|
||||
```shell
|
||||
kubectl create clusterrolebinding serviceaccounts-view \
|
||||
--clusterrole=view \
|
||||
--group=system:serviceaccounts
|
||||
```
|
||||
```shell
|
||||
kubectl create clusterrolebinding serviceaccounts-view \
|
||||
--clusterrole=view \
|
||||
--group=system:serviceaccounts
|
||||
```
|
||||
|
||||
5. Grant super-user access to all service accounts cluster-wide (strongly discouraged)
|
||||
|
||||
If you don't care about partitioning permissions at all, you can grant super-user access to all service accounts.
|
||||
If you don't care about partitioning permissions at all, you can grant super-user access to all service accounts.
|
||||
|
||||
{{< warning >}}
|
||||
This allows any application full access to your cluster, and also grants
|
||||
any user with read access to Secrets (or the ability to create any pod)
|
||||
full access to your cluster.
|
||||
{{< /warning >}}
|
||||
{{< warning >}}
|
||||
This allows any application full access to your cluster, and also grants
|
||||
any user with read access to Secrets (or the ability to create any pod)
|
||||
full access to your cluster.
|
||||
{{< /warning >}}
|
||||
|
||||
```shell
|
||||
kubectl create clusterrolebinding serviceaccounts-cluster-admin \
|
||||
--clusterrole=cluster-admin \
|
||||
--group=system:serviceaccounts
|
||||
```
|
||||
```shell
|
||||
kubectl create clusterrolebinding serviceaccounts-cluster-admin \
|
||||
--clusterrole=cluster-admin \
|
||||
--group=system:serviceaccounts
|
||||
```
|
||||
|
||||
## Write access for EndpointSlices and Endpoints {#write-access-for-endpoints}
|
||||
|
||||
|
|
@ -1247,7 +1260,7 @@ Here are two approaches for managing this transition:
|
|||
Run both the RBAC and ABAC authorizers, and specify a policy file that contains
|
||||
the [legacy ABAC policy](/docs/reference/access-authn-authz/abac/#policy-file-format):
|
||||
|
||||
```
|
||||
```shell
|
||||
--authorization-mode=...,RBAC,ABAC --authorization-policy-file=mypolicy.json
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -22,9 +22,11 @@ For a stable output in a script:
|
|||
|
||||
## Subresources
|
||||
|
||||
* You can use the `--subresource` alpha flag for kubectl commands like `get`, `patch`,
|
||||
* You can use the `--subresource` beta flag for kubectl commands like `get`, `patch`,
|
||||
`edit` and `replace` to fetch and update subresources for all resources that
|
||||
support them. Currently, only the `status` and `scale` subresources are supported.
|
||||
* For `kubectl edit`, the `scale` subresource is not supported. If you use `--subresource` with
|
||||
`kubectl edit` and specify `scale` as the subresource, the command will error out.
|
||||
* The API contract against a subresource is identical to a full resource. While updating the
|
||||
`status` subresource to a new value, keep in mind that the subresource could be potentially
|
||||
reconciled by a controller to a different value.
|
||||
|
|
|
|||
|
|
@ -81,7 +81,7 @@ kubectl get pods --namespace kube-system -o jsonpath="{.items[*].spec.containers
|
|||
|
||||
## List Container images using a go-template instead of jsonpath
|
||||
|
||||
As an alternative to jsonpath, Kubectl supports using [go-templates](https://golang.org/pkg/text/template/)
|
||||
As an alternative to jsonpath, Kubectl supports using [go-templates](https://pkg.go.dev/text/template)
|
||||
for formatting the output:
|
||||
|
||||
```shell
|
||||
|
|
@ -93,5 +93,4 @@ kubectl get pods --all-namespaces -o go-template --template="{{range .items}}{{r
|
|||
### Reference
|
||||
|
||||
* [Jsonpath](/docs/reference/kubectl/jsonpath/) reference guide
|
||||
* [Go template](https://golang.org/pkg/text/template/) reference guide
|
||||
|
||||
* [Go template](https://pkg.go.dev/text/template) reference guide
|
||||
|
|
|
|||
|
|
@ -128,4 +128,4 @@ is empty and the container exited with an error. The log output is limited to
|
|||
* See the `terminationMessagePath` field in
|
||||
[Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core).
|
||||
* Learn about [retrieving logs](/docs/concepts/cluster-administration/logging/).
|
||||
* Learn about [Go templates](https://golang.org/pkg/text/template/).
|
||||
* Learn about [Go templates](https://pkg.go.dev/text/template).
|
||||
|
|
|
|||
|
|
@ -21,6 +21,22 @@ When you create a Pod, you can set environment variables for the containers
|
|||
that run in the Pod. To set environment variables, include the `env` or
|
||||
`envFrom` field in the configuration file.
|
||||
|
||||
The `env` and `envFrom` fields have different effects.
|
||||
|
||||
`env`
|
||||
: allows you to set environment variables for a container, specifying a value directly for each variable that you name.
|
||||
|
||||
`envFrom`
|
||||
: allows you to set environment variables for a container by referencing either a ConfigMap or a Secret.
|
||||
When you use `envFrom`, all the key-value pairs in the referenced ConfigMap or Secret
|
||||
are set as environment variables for the container.
|
||||
You can also specify a common prefix string.
|
||||
|
||||
You can read more about [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/#configure-all-key-value-pairs-in-a-configmap-as-container-environment-variables)
|
||||
and [Secret](/docs/tasks/inject-data-application/distribute-credentials-secure/#configure-all-key-value-pairs-in-a-secret-as-container-environment-variables).
|
||||
|
||||
This page explains how to use `env`.
|
||||
|
||||
In this exercise, you create a Pod that runs one container. The configuration
|
||||
file for the Pod defines an environment variable with name `DEMO_GREETING` and
|
||||
value `"Hello from the environment"`. Here is the configuration manifest for the
|
||||
|
|
|
|||
|
|
@ -11,20 +11,31 @@ card:
|
|||
---
|
||||
|
||||
<!-- overview -->
|
||||
This tutorial shows you how to deploy a WordPress site and a MySQL database using Minikube. Both applications use PersistentVolumes and PersistentVolumeClaims to store data.
|
||||
This tutorial shows you how to deploy a WordPress site and a MySQL database using
|
||||
Minikube. Both applications use PersistentVolumes and PersistentVolumeClaims to store data.
|
||||
|
||||
A [PersistentVolume](/docs/concepts/storage/persistent-volumes/) (PV) is a piece of storage in the cluster that has been manually provisioned by an administrator, or dynamically provisioned by Kubernetes using a [StorageClass](/docs/concepts/storage/storage-classes). A [PersistentVolumeClaim](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) (PVC) is a request for storage by a user that can be fulfilled by a PV. PersistentVolumes and PersistentVolumeClaims are independent from Pod lifecycles and preserve data through restarting, rescheduling, and even deleting Pods.
|
||||
A [PersistentVolume](/docs/concepts/storage/persistent-volumes/) (PV) is a piece
|
||||
of storage in the cluster that has been manually provisioned by an administrator,
|
||||
or dynamically provisioned by Kubernetes using a [StorageClass](/docs/concepts/storage/storage-classes).
|
||||
A [PersistentVolumeClaim](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) (PVC)
|
||||
is a request for storage by a user that can be fulfilled by a PV. PersistentVolumes and
|
||||
PersistentVolumeClaims are independent from Pod lifecycles and preserve data through
|
||||
restarting, rescheduling, and even deleting Pods.
|
||||
|
||||
{{< warning >}}
|
||||
This deployment is not suitable for production use cases, as it uses single instance WordPress and MySQL Pods. Consider using [WordPress Helm Chart](https://github.com/bitnami/charts/tree/master/bitnami/wordpress) to deploy WordPress in production.
|
||||
This deployment is not suitable for production use cases, as it uses single instance
|
||||
WordPress and MySQL Pods. Consider using
|
||||
[WordPress Helm Chart](https://github.com/bitnami/charts/tree/master/bitnami/wordpress)
|
||||
to deploy WordPress in production.
|
||||
{{< /warning >}}
|
||||
|
||||
{{< note >}}
|
||||
The files provided in this tutorial are using GA Deployment APIs and are specific to kubernetes version 1.9 and later. If you wish to use this tutorial with an earlier version of Kubernetes, please update the API version appropriately, or reference earlier versions of this tutorial.
|
||||
The files provided in this tutorial are using GA Deployment APIs and are specific
|
||||
to kubernetes version 1.9 and later. If you wish to use this tutorial with an earlier
|
||||
version of Kubernetes, please update the API version appropriately, or reference
|
||||
earlier versions of this tutorial.
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
|
||||
## {{% heading "objectives" %}}
|
||||
|
||||
* Create PersistentVolumeClaims and PersistentVolumes
|
||||
|
|
@ -35,12 +46,10 @@ The files provided in this tutorial are using GA Deployment APIs and are specifi
|
|||
* Apply the kustomization directory by `kubectl apply -k ./`
|
||||
* Clean up
|
||||
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
The example shown on this page works with `kubectl` 1.14 and above.
|
||||
|
||||
Download the following configuration files:
|
||||
|
|
@ -49,36 +58,49 @@ Download the following configuration files:
|
|||
|
||||
1. [wordpress-deployment.yaml](/examples/application/wordpress/wordpress-deployment.yaml)
|
||||
|
||||
|
||||
|
||||
<!-- lessoncontent -->
|
||||
<!-- lessoncontent -->
|
||||
|
||||
## Create PersistentVolumeClaims and PersistentVolumes
|
||||
|
||||
MySQL and Wordpress each require a PersistentVolume to store data. Their PersistentVolumeClaims will be created at the deployment step.
|
||||
MySQL and Wordpress each require a PersistentVolume to store data.
|
||||
Their PersistentVolumeClaims will be created at the deployment step.
|
||||
|
||||
Many cluster environments have a default StorageClass installed. When a StorageClass is not specified in the PersistentVolumeClaim, the cluster's default StorageClass is used instead.
|
||||
Many cluster environments have a default StorageClass installed.
|
||||
When a StorageClass is not specified in the PersistentVolumeClaim,
|
||||
the cluster's default StorageClass is used instead.
|
||||
|
||||
When a PersistentVolumeClaim is created, a PersistentVolume is dynamically provisioned based on the StorageClass configuration.
|
||||
When a PersistentVolumeClaim is created, a PersistentVolume is dynamically
|
||||
provisioned based on the StorageClass configuration.
|
||||
|
||||
{{< warning >}}
|
||||
In local clusters, the default StorageClass uses the `hostPath` provisioner. `hostPath` volumes are only suitable for development and testing. With `hostPath` volumes, your data lives in `/tmp` on the node the Pod is scheduled onto and does not move between nodes. If a Pod dies and gets scheduled to another node in the cluster, or the node is rebooted, the data is lost.
|
||||
In local clusters, the default StorageClass uses the `hostPath` provisioner.
|
||||
`hostPath` volumes are only suitable for development and testing. With `hostPath`
|
||||
volumes, your data lives in `/tmp` on the node the Pod is scheduled onto and does
|
||||
not move between nodes. If a Pod dies and gets scheduled to another node in the
|
||||
cluster, or the node is rebooted, the data is lost.
|
||||
{{< /warning >}}
|
||||
|
||||
{{< note >}}
|
||||
If you are bringing up a cluster that needs to use the `hostPath` provisioner, the `--enable-hostpath-provisioner` flag must be set in the `controller-manager` component.
|
||||
If you are bringing up a cluster that needs to use the `hostPath` provisioner,
|
||||
the `--enable-hostpath-provisioner` flag must be set in the `controller-manager` component.
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
If you have a Kubernetes cluster running on Google Kubernetes Engine, please follow [this guide](https://cloud.google.com/kubernetes-engine/docs/tutorials/persistent-disk).
|
||||
If you have a Kubernetes cluster running on Google Kubernetes Engine, please
|
||||
follow [this guide](https://cloud.google.com/kubernetes-engine/docs/tutorials/persistent-disk).
|
||||
{{< /note >}}
|
||||
|
||||
## Create a kustomization.yaml
|
||||
|
||||
### Add a Secret generator
|
||||
A [Secret](/docs/concepts/configuration/secret/) is an object that stores a piece of sensitive data like a password or key. Since 1.14, `kubectl` supports the management of Kubernetes objects using a kustomization file. You can create a Secret by generators in `kustomization.yaml`.
|
||||
|
||||
Add a Secret generator in `kustomization.yaml` from the following command. You will need to replace `YOUR_PASSWORD` with the password you want to use.
|
||||
A [Secret](/docs/concepts/configuration/secret/) is an object that stores a piece
|
||||
of sensitive data like a password or key. Since 1.14, `kubectl` supports the
|
||||
management of Kubernetes objects using a kustomization file. You can create a Secret
|
||||
by generators in `kustomization.yaml`.
|
||||
|
||||
Add a Secret generator in `kustomization.yaml` from the following command.
|
||||
You will need to replace `YOUR_PASSWORD` with the password you want to use.
|
||||
|
||||
```shell
|
||||
cat <<EOF >./kustomization.yaml
|
||||
|
|
@ -91,42 +113,46 @@ EOF
|
|||
|
||||
## Add resource configs for MySQL and WordPress
|
||||
|
||||
The following manifest describes a single-instance MySQL Deployment. The MySQL container mounts the PersistentVolume at /var/lib/mysql. The `MYSQL_ROOT_PASSWORD` environment variable sets the database password from the Secret.
|
||||
The following manifest describes a single-instance MySQL Deployment. The MySQL
|
||||
container mounts the PersistentVolume at /var/lib/mysql. The `MYSQL_ROOT_PASSWORD`
|
||||
environment variable sets the database password from the Secret.
|
||||
|
||||
{{< codenew file="application/wordpress/mysql-deployment.yaml" >}}
|
||||
|
||||
The following manifest describes a single-instance WordPress Deployment. The WordPress container mounts the
|
||||
PersistentVolume at `/var/www/html` for website data files. The `WORDPRESS_DB_HOST` environment variable sets
|
||||
the name of the MySQL Service defined above, and WordPress will access the database by Service. The
|
||||
`WORDPRESS_DB_PASSWORD` environment variable sets the database password from the Secret kustomize generated.
|
||||
`WORDPRESS_DB_PASSWORD` environment variable sets the database password from the Secret kustomize generated.
|
||||
|
||||
{{< codenew file="application/wordpress/wordpress-deployment.yaml" >}}
|
||||
|
||||
1. Download the MySQL deployment configuration file.
|
||||
|
||||
```shell
|
||||
curl -LO https://k8s.io/examples/application/wordpress/mysql-deployment.yaml
|
||||
```
|
||||
|
||||
```shell
|
||||
curl -LO https://k8s.io/examples/application/wordpress/mysql-deployment.yaml
|
||||
```
|
||||
|
||||
2. Download the WordPress configuration file.
|
||||
|
||||
```shell
|
||||
curl -LO https://k8s.io/examples/application/wordpress/wordpress-deployment.yaml
|
||||
```
|
||||
|
||||
```shell
|
||||
curl -LO https://k8s.io/examples/application/wordpress/wordpress-deployment.yaml
|
||||
```
|
||||
|
||||
3. Add them to `kustomization.yaml` file.
|
||||
|
||||
```shell
|
||||
cat <<EOF >>./kustomization.yaml
|
||||
resources:
|
||||
- mysql-deployment.yaml
|
||||
- wordpress-deployment.yaml
|
||||
EOF
|
||||
```
|
||||
```shell
|
||||
cat <<EOF >>./kustomization.yaml
|
||||
resources:
|
||||
- mysql-deployment.yaml
|
||||
- wordpress-deployment.yaml
|
||||
EOF
|
||||
```
|
||||
|
||||
## Apply and Verify
|
||||
The `kustomization.yaml` contains all the resources for deploying a WordPress site and a
|
||||
|
||||
The `kustomization.yaml` contains all the resources for deploying a WordPress site and a
|
||||
MySQL database. You can apply the directory by
|
||||
|
||||
```shell
|
||||
kubectl apply -k ./
|
||||
```
|
||||
|
|
@ -135,80 +161,80 @@ Now you can verify that all objects exist.
|
|||
|
||||
1. Verify that the Secret exists by running the following command:
|
||||
|
||||
```shell
|
||||
kubectl get secrets
|
||||
```
|
||||
```shell
|
||||
kubectl get secrets
|
||||
```
|
||||
|
||||
The response should be like this:
|
||||
The response should be like this:
|
||||
|
||||
```shell
|
||||
NAME TYPE DATA AGE
|
||||
mysql-pass-c57bb4t7mf Opaque 1 9s
|
||||
```
|
||||
```
|
||||
NAME TYPE DATA AGE
|
||||
mysql-pass-c57bb4t7mf Opaque 1 9s
|
||||
```
|
||||
|
||||
2. Verify that a PersistentVolume got dynamically provisioned.
|
||||
|
||||
```shell
|
||||
kubectl get pvc
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
It can take up to a few minutes for the PVs to be provisioned and bound.
|
||||
{{< /note >}}
|
||||
|
||||
The response should be like this:
|
||||
```shell
|
||||
kubectl get pvc
|
||||
```
|
||||
|
||||
```shell
|
||||
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
|
||||
mysql-pv-claim Bound pvc-8cbd7b2e-4044-11e9-b2bb-42010a800002 20Gi RWO standard 77s
|
||||
wp-pv-claim Bound pvc-8cd0df54-4044-11e9-b2bb-42010a800002 20Gi RWO standard 77s
|
||||
```
|
||||
{{< note >}}
|
||||
It can take up to a few minutes for the PVs to be provisioned and bound.
|
||||
{{< /note >}}
|
||||
|
||||
The response should be like this:
|
||||
|
||||
```
|
||||
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
|
||||
mysql-pv-claim Bound pvc-8cbd7b2e-4044-11e9-b2bb-42010a800002 20Gi RWO standard 77s
|
||||
wp-pv-claim Bound pvc-8cd0df54-4044-11e9-b2bb-42010a800002 20Gi RWO standard 77s
|
||||
```
|
||||
|
||||
3. Verify that the Pod is running by running the following command:
|
||||
|
||||
```shell
|
||||
kubectl get pods
|
||||
```
|
||||
```shell
|
||||
kubectl get pods
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
It can take up to a few minutes for the Pod's Status to be `RUNNING`.
|
||||
{{< /note >}}
|
||||
{{< note >}}
|
||||
It can take up to a few minutes for the Pod's Status to be `RUNNING`.
|
||||
{{< /note >}}
|
||||
|
||||
The response should be like this:
|
||||
The response should be like this:
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
wordpress-mysql-1894417608-x5dzt 1/1 Running 0 40s
|
||||
```
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
wordpress-mysql-1894417608-x5dzt 1/1 Running 0 40s
|
||||
```
|
||||
|
||||
4. Verify that the Service is running by running the following command:
|
||||
|
||||
```shell
|
||||
kubectl get services wordpress
|
||||
```
|
||||
```shell
|
||||
kubectl get services wordpress
|
||||
```
|
||||
|
||||
The response should be like this:
|
||||
The response should be like this:
|
||||
|
||||
```
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
wordpress LoadBalancer 10.0.0.89 <pending> 80:32406/TCP 4m
|
||||
```
|
||||
```
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
wordpress LoadBalancer 10.0.0.89 <pending> 80:32406/TCP 4m
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
Minikube can only expose Services through `NodePort`. The EXTERNAL-IP is always pending.
|
||||
{{< /note >}}
|
||||
{{< note >}}
|
||||
Minikube can only expose Services through `NodePort`. The EXTERNAL-IP is always pending.
|
||||
{{< /note >}}
|
||||
|
||||
5. Run the following command to get the IP Address for the WordPress Service:
|
||||
|
||||
```shell
|
||||
minikube service wordpress --url
|
||||
```
|
||||
```shell
|
||||
minikube service wordpress --url
|
||||
```
|
||||
|
||||
The response should be like this:
|
||||
The response should be like this:
|
||||
|
||||
```
|
||||
http://1.2.3.4:32406
|
||||
```
|
||||
```
|
||||
http://1.2.3.4:32406
|
||||
```
|
||||
|
||||
6. Copy the IP address, and load the page in your browser to view your site.
|
||||
|
||||
|
|
@ -216,30 +242,23 @@ Now you can verify that all objects exist.
|
|||
|
||||
|
||||
|
||||
{{< warning >}}
|
||||
Do not leave your WordPress installation on this page. If another user finds it, they can set up a website on your instance and use it to serve malicious content. <br/><br/>Either install WordPress by creating a username and password or delete your instance.
|
||||
{{< /warning >}}
|
||||
|
||||
|
||||
{{< warning >}}
|
||||
Do not leave your WordPress installation on this page. If another user finds it,
|
||||
they can set up a website on your instance and use it to serve malicious content.<br/><br/>
|
||||
Either install WordPress by creating a username and password or delete your instance.
|
||||
{{< /warning >}}
|
||||
|
||||
## {{% heading "cleanup" %}}
|
||||
|
||||
|
||||
1. Run the following command to delete your Secret, Deployments, Services and PersistentVolumeClaims:
|
||||
|
||||
```shell
|
||||
kubectl delete -k ./
|
||||
```
|
||||
|
||||
|
||||
```shell
|
||||
kubectl delete -k ./
|
||||
```
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* Learn more about [Introspection and Debugging](/docs/tasks/debug/debug-application/debug-running-pod/)
|
||||
* Learn more about [Jobs](/docs/concepts/workloads/controllers/job/)
|
||||
* Learn more about [Port Forwarding](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)
|
||||
* Learn how to [Get a Shell to a Container](/docs/tasks/debug/debug-application/get-shell-running-container/)
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ spec:
|
|||
- key: "CriticalAddonsOnly"
|
||||
operator: "Exists"
|
||||
containers:
|
||||
- image: us.gcr.io/k8s-artifacts-prod/kas-network-proxy/proxy-agent:v0.0.16
|
||||
- image: us.gcr.io/k8s-artifacts-prod/kas-network-proxy/proxy-agent:v0.0.37
|
||||
name: konnectivity-agent
|
||||
command: ["/proxy-agent"]
|
||||
args: [
|
||||
|
|
|
|||
|
|
@ -8,12 +8,13 @@ spec:
|
|||
hostNetwork: true
|
||||
containers:
|
||||
- name: konnectivity-server-container
|
||||
image: registry.k8s.io/kas-network-proxy/proxy-server:v0.0.32
|
||||
image: registry.k8s.io/kas-network-proxy/proxy-server:v0.0.37
|
||||
command: ["/proxy-server"]
|
||||
args: [
|
||||
"--logtostderr=true",
|
||||
# This needs to be consistent with the value set in egressSelectorConfiguration.
|
||||
"--uds-name=/etc/kubernetes/konnectivity-server/konnectivity-server.socket",
|
||||
"--delete-existing-uds-file",
|
||||
# The following two lines assume the Konnectivity server is
|
||||
# deployed on the same machine as the apiserver, and the certs and
|
||||
# key of the API Server are at the specified location.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
apiVersion: flowcontrol.apiserver.k8s.io/v1beta2
|
||||
apiVersion: flowcontrol.apiserver.k8s.io/v1beta3
|
||||
kind: FlowSchema
|
||||
metadata:
|
||||
name: health-for-strangers
|
||||
|
|
|
|||
|
|
@ -94,7 +94,7 @@ spec:
|
|||
Comme pour toutes les autres ressources Kubernetes, un Ingress (une entrée) a besoin des champs `apiVersion`, `kind` et `metadata`.
|
||||
Pour des informations générales sur l'utilisation des fichiers de configuration, voir [déployer des applications](/docs/tasks/run-application/run-stateless-application-deployment/), [configurer des conteneurs](/docs/tasks/configure-pod-container/configure-pod-configmap/), [gestion des ressources](/docs/concepts/cluster-administration/manage-deployment/).
|
||||
Ingress utilise fréquemment des annotations pour configurer certaines options en fonction du contrôleur Ingress, dont un exemple
|
||||
est l'annotation [rewrite-target](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md).
|
||||
est l'annotation [rewrite-target](https://github.com/kubernetes/ingress-nginx/blob/main/docs/examples/rewrite/README.md).
|
||||
Différents [Ingress controller](/docs/concepts/services-networking/ingress-controllers) prennent en charge différentes annotations. Consultez la documentation du contrôleur Ingress de votre choix pour savoir quelles annotations sont prises en charge.
|
||||
|
||||
La [spécification de la ressource Ingress](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) dispose de toutes les informations nécessaires pour configurer un loadbalancer ou un serveur proxy. Plus important encore, il
|
||||
|
|
|
|||
|
|
@ -93,8 +93,12 @@ Labels: run=my-nginx
|
|||
Annotations: <none>
|
||||
Selector: run=my-nginx
|
||||
Type: ClusterIP
|
||||
IP Family Policy: SingleStack
|
||||
IP Families: IPv4
|
||||
IP: 10.0.162.149
|
||||
IPs: 10.0.162.149
|
||||
Port: <unset> 80/TCP
|
||||
TargetPort: 80/TCP
|
||||
Endpoints: 10.244.2.5:80,10.244.3.4:80
|
||||
Session Affinity: None
|
||||
Events: <none>
|
||||
|
|
|
|||
|
|
@ -91,7 +91,7 @@ spec:
|
|||
Seperti layaknya *resource* Kubernetes yang lain, sebuah Ingress membutuhkan *field* `apiVersion`, `kind`, dan `metadata`.
|
||||
Untuk informasi umum soal bagaimana cara bekerja dengan menggunakan berkas konfigurasi, silahkan merujuk pada [melakukan deploy aplikasi](/docs/tasks/run-application/run-stateless-application-deployment/), [konfigurasi kontainer](/id/docs/tasks/configure-pod-container/configure-pod-configmap/), [mengatur *resource*](/id/docs/concepts/cluster-administration/manage-deployment/).
|
||||
Ingress seringkali menggunakan anotasi untuk melakukan konfigurasi beberapa opsi yang ada bergantung pada kontroler Ingress yang digunakan, sebagai contohnya
|
||||
adalah [anotasi rewrite-target](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md).
|
||||
adalah [anotasi rewrite-target](https://github.com/kubernetes/ingress-nginx/blob/main/docs/examples/rewrite/README.md).
|
||||
[Kontroler Ingress](/id/docs/concepts/services-networking/ingress-controllers) yang berbeda memiliki jenis anotasi yang berbeda. Pastikan kamu sudah terlebih dahulu memahami dokumentasi
|
||||
kontroler Ingress yang akan kamu pakai untuk mengetahui jenis anotasi apa sajakah yang disediakan.
|
||||
|
||||
|
|
|
|||
|
|
@ -100,7 +100,7 @@ kubectl get pods --namespace kube-system -o jsonpath="{.items[*].spec.containers
|
|||
|
||||
## Membuat daftar _image_ Container dengan menggunakan go-template sebagai alternatif dari jsonpath
|
||||
|
||||
Sebagai alternatif untuk `jsonpath`, kubectl mendukung penggunaan [go-template](https://golang.org/pkg/text/template/)
|
||||
Sebagai alternatif untuk `jsonpath`, kubectl mendukung penggunaan [go-template](https://pkg.go.dev/text/template)
|
||||
untuk memformat keluaran seperti berikut:
|
||||
|
||||
|
||||
|
|
@ -122,7 +122,7 @@ kubectl get pods --all-namespaces -o go-template --template="{{range .items}}{{r
|
|||
### Referensi
|
||||
|
||||
* Referensi panduan [Jsonpath](/docs/user-guide/jsonpath/).
|
||||
* Referensi panduan [Go template](https://golang.org/pkg/text/template/).
|
||||
* Referensi panduan [Go template](https://pkg.go.dev/text/template).
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ Kubernetesはv1.20より新しいバージョンで、コンテナランタイ
|
|||
|
||||
概要: ランタイムとしてのDockerは、Kubernetesのために開発された[Container Runtime Interface(CRI)](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/)を利用しているランタイムを選んだ結果としてサポートされなくなります。しかし、Dockerによって生成されたイメージはこれからも、今までもそうだったように、みなさんのクラスターで使用可能です。
|
||||
|
||||
もし、あなたがKubernetesのエンドユーザーであるならば、多くの変化はないでしょう。これはDockerの死を意味するものではありませんし、開発ツールとして今後Dockerを使用するべきでない、使用することは出来ないと言っているのでもありません。Dockerはコンテナを作成するのに便利なツールですし、docker buildコマンドで作成されたイメージはKubernetesクラスタ上でこれからも動作可能なのです。
|
||||
もし、あなたがKubernetesのエンドユーザーであるならば、多くの変化はないでしょう。これはDockerの死を意味するものではありませんし、開発ツールとして今後Dockerを使用するべきでない、使用することは出来ないと言っているのでもありません。Dockerはコンテナを作成するのに便利なツールですし、docker buildコマンドで作成されたイメージはKubernetesクラスター上でこれからも動作可能なのです。
|
||||
|
||||
もし、GKE、EKS、AKSといったマネージドKubernetesサービス(それらはデフォルトで[containerdを使用しています](https://github.com/Azure/AKS/releases/tag/2020-11-16))を使っているのなら、ワーカーノードがサポート対象のランタイムを使用しているか、Dockerのサポートが将来のK8sバージョンで切れる前に確認しておく必要があるでしょう。
|
||||
もし、ノードをカスタマイズしているのなら、環境やRuntimeの仕様に合わせて更新する必要があるでしょう。サービスプロバイダーと確認し、アップグレードのための適切なテストと計画を立ててください。
|
||||
|
|
@ -24,7 +24,7 @@ Kubernetesはv1.20より新しいバージョンで、コンテナランタイ
|
|||
ここで議論になっているのは2つの異なる場面についてであり、それが混乱の原因になっています。Kubernetesクラスターの内部では、Container runtimeと呼ばれるものがあり、それはImageをPullし起動する役目を持っています。Dockerはその選択肢として人気があります(他にはcontainerdやCRI-Oが挙げられます)が、しかしDockerはそれ自体がKubernetesの一部として設計されているわけではありません。これが問題の原因となっています。
|
||||
|
||||
お分かりかと思いますが、ここで”Docker”と呼んでいるものは、ある1つのものではなく、その技術的な体系の全体であり、その一部には"containerd"と呼ばれるものもあり、これはそれ自体がハイレベルなContainer runtimeとなっています。Dockerは素晴らしいもので、便利です。なぜなら、多くのUXの改善がされており、それは人間が開発を行うための操作を簡単にしているのです。しかし、それらはKubernetesに必要なものではありません。Kubernetesは人間ではないからです。
|
||||
このhuman-friendlyな抽象化レイヤが作られてために、結果としてはKubernetesクラスタはDockershimと呼ばれるほかのツールを使い、本当に必要な機能つまりcontainerdを利用してきました。これは素晴らしいとは言えません。なぜなら、我々がメンテする必要のあるものが増えますし、それは問題が発生する要因ともなります。今回の変更で実際に行われることというのは、Dockershimを最も早い場合でv1.23のリリースでkubeletから除外することです。その結果として、Dockerのサポートがなくなるということなのです。
|
||||
このhuman-friendlyな抽象化レイヤが作られてために、結果としてはKubernetesクラスターはDockershimと呼ばれるほかのツールを使い、本当に必要な機能つまりcontainerdを利用してきました。これは素晴らしいとは言えません。なぜなら、我々がメンテする必要のあるものが増えますし、それは問題が発生する要因ともなります。今回の変更で実際に行われることというのは、Dockershimを最も早い場合でv1.23のリリースでkubeletから除外することです。その結果として、Dockerのサポートがなくなるということなのです。
|
||||
ここで、containerdがDockerに含まれているなら、なぜDockershimが必要なのかと疑問に思われる方もいるでしょう。
|
||||
|
||||
DockerはCRI([Container Runtime Interface](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/))に準拠していません。もしそうであればshimは必要ないのですが、現実はそうでありません。
|
||||
|
|
@ -35,7 +35,7 @@ DockerはCRI([Container Runtime Interface](https://kubernetes.io/blog/2016/12/co
|
|||
## では開発者にとって、この変更は何を意味するのか。これからもDockerfileを使ってよいのか。これからもDockerでビルドを行ってよいのか。
|
||||
|
||||
この変更は、Dockerを直接操作している多くのみなさんとは別の場面に影響を与えるでしょう。
|
||||
みなさんが開発を行う際に使用しているDockerと、Kubernetesクラスタの内部で使われているDocker runtimeは関係ありません。これがわかりにくいことは理解しています。開発者にとって、Dockerはこれからも便利なものであり、このアナウンスがあった前と変わらないでしょう。DockerでビルドされたImageは、決してDockerでだけ動作するというわけではありません。それはOCI([Open Container Initiative](https://opencontainers.org/)) Imageと呼ばれるものです。あらゆるOCI準拠のImageは、それを何のツールでビルドしたかによらず、Kubernetesから見れば同じものなのです。[containerd](https://containerd.io/)も[CRI-O](https://cri-o.io/)も、そのようなImageをPullし、起動することが出来ます。
|
||||
みなさんが開発を行う際に使用しているDockerと、Kubernetesクラスターの内部で使われているDocker runtimeは関係ありません。これがわかりにくいことは理解しています。開発者にとって、Dockerはこれからも便利なものであり、このアナウンスがあった前と変わらないでしょう。DockerでビルドされたImageは、決してDockerでだけ動作するというわけではありません。それはOCI([Open Container Initiative](https://opencontainers.org/)) Imageと呼ばれるものです。あらゆるOCI準拠のImageは、それを何のツールでビルドしたかによらず、Kubernetesから見れば同じものなのです。[containerd](https://containerd.io/)も[CRI-O](https://cri-o.io/)も、そのようなImageをPullし、起動することが出来ます。
|
||||
これがコンテナの仕様について、共通の仕様を策定している理由なのです。
|
||||
|
||||
さて、この変更は決定しています。いくつかの問題は発生するかもしてませんが、決して壊滅的なものではなく、ほとんどの場合は良い変化となるでしょう。Kubernetesをどのように使用しているかによりますが、この変更が特に何の影響も及ぼさない人もいるでしょうし、影響がとても少ない場合もあります。長期的に見れば、物事を簡単にするのに役立つものです。
|
||||
|
|
|
|||
|
|
@ -65,10 +65,10 @@ case_study_details:
|
|||
<p>Nordstrom Technologyの場合、クラウドネイティブへの移行によって、開発と運用の効率が大幅に向上しています。Kubernetesを利用する開発者はより迅速にデプロイでき、アプリケーションの価値の構築に専念できます。こうしたノウハウを取り入れるために、1つのチームにおいてクラウド上に仮想マシンを構築し、マージからデプロイまでに25分かかるところからスタートしました。Kubernetesへの切り替えにより、プロセスが5倍高速化され、マージからデプロイまでの時間が5分に改善しました。</p>
|
||||
|
||||
{{< case-studies/quote >}}
|
||||
「Kubernetesを使用することで、クラスタの効率化を図ることもなく、現在のCPU使用率は40%、つまり10倍になりました。直接クラウドに移行した場合には2600台以上のVMになるところが、同数の顧客用Podで済むようになりました。これらのPodを40台のVMで実行しているため、運用上のオーバーヘッドが大幅に削減されました。」
|
||||
「Kubernetesを使用することで、クラスターの効率化を図ることもなく、現在のCPU使用率は40%、つまり10倍になりました。直接クラウドに移行した場合には2600台以上のVMになるところが、同数の顧客用Podで済むようになりました。これらのPodを40台のVMで実行しているため、運用上のオーバーヘッドが大幅に削減されました。」
|
||||
{{< /case-studies/quote >}}
|
||||
|
||||
<p>スピードは素晴らしく、簡単に実証できますが、より大きな影響はおそらくその運用効率にあります。「AWSで何千ものVMを実行する場合、全体的な平均CPU使用率は約4%です。」とPatel氏は言います。「Kubernetesを使用することで、クラスタの効率化を図ることもなく、現在のCPU使用率は40%、つまり10倍になりました。直接クラウドに移行した場合には2600台以上のVMになるところが、同数の顧客用Podで済むようになりました。これらのPodを40台のVMで実行しているため、運用上のオーバーヘッドが大幅に削減されました。」</p>
|
||||
<p>スピードは素晴らしく、簡単に実証できますが、より大きな影響はおそらくその運用効率にあります。「AWSで何千ものVMを実行する場合、全体的な平均CPU使用率は約4%です。」とPatel氏は言います。「Kubernetesを使用することで、クラスターの効率化を図ることもなく、現在のCPU使用率は40%、つまり10倍になりました。直接クラウドに移行した場合には2600台以上のVMになるところが、同数の顧客用Podで済むようになりました。これらのPodを40台のVMで実行しているため、運用上のオーバーヘッドが大幅に削減されました。」</p>
|
||||
|
||||
<p>Nordstrom TechnologyはオンプレミスのベアメタルでKubernetesを実行することも検討しています。Patel氏は言います。「オンプレミスのKubernetesクラスターを構築できれば、クラウドの力を活用してオンプレミスでリソースを迅速にプロビジョニングできます。次に、開発者にとってのインターフェースはKubernetesです。Kubernetesのみと連携しているため、自社のサービスがオンプレミスにデプロイされていることに気付かないこともあります。」</p>
|
||||
|
||||
|
|
|
|||
|
|
@ -46,7 +46,7 @@ cloud-controller-managerは、プラグイン機構を用い、異なるクラ
|
|||
|
||||
#### ルートコントローラー
|
||||
|
||||
ルートコントローラーは、クラスタ内の異なるノード上で稼働しているコンテナが相互に通信できるように、クラウド内のルートを適切に設定する責務を持ちます。
|
||||
ルートコントローラーは、クラスター内の異なるノード上で稼働しているコンテナが相互に通信できるように、クラウド内のルートを適切に設定する責務を持ちます。
|
||||
|
||||
クラウドプロバイダーによっては、ルートコントローラーはPodネットワークのIPアドレスのブロックを割り当てることもあります。
|
||||
|
||||
|
|
|
|||
|
|
@ -217,7 +217,7 @@ kubeletが`NodeStatus`とLeaseオブジェクトの作成および更新を担
|
|||
|
||||
ノードを複数のアベイラビリティゾーンに分散させる主な理由は、1つのゾーン全体が停止したときにワークロードを正常なゾーンに移動できることです。
|
||||
したがって、ゾーン内のすべてのノードが異常である場合、ノードコントローラーは通常のレート `--node-eviction-rate`で退役します。
|
||||
コーナーケースは、すべてのゾーンが完全にUnhealthyである（すなわち、クラスタ内にHealthyなノードがない）場合です。
|
||||
コーナーケースは、すべてのゾーンが完全にUnhealthyである（すなわち、クラスター内にHealthyなノードがない）場合です。
|
||||
このような場合、ノードコントローラーはマスター接続に問題があると見なし、接続が回復するまですべての退役を停止します。
|
||||
|
||||
ノードコントローラーは、Podがtaintを許容しない場合、 `NoExecute`のtaintを持つノード上で実行されているPodを排除する責務もあります。
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ weight: 120
|
|||
|
||||
## インフラストラクチャ {#infrastructure}
|
||||
|
||||
* [KubeVirt](https://kubevirt.io/user-guide/#/installation/installation)は仮想マシンをKubernetes上で実行するためのアドオンです。通常、ベアメタルのクラスタで実行します。
|
||||
* [KubeVirt](https://kubevirt.io/user-guide/#/installation/installation)は仮想マシンをKubernetes上で実行するためのアドオンです。通常、ベアメタルのクラスターで実行します。
|
||||
* [node problem detector](https://github.com/kubernetes/node-problem-detector)はLinuxノード上で動作し、システムの問題を[Event](/docs/reference/kubernetes-api/cluster-resources/event-v1/)または[ノードのCondition](/ja/docs/concepts/architecture/nodes/#condition)として報告します。
|
||||
|
||||
## レガシーなアドオン {#legacy-add-ons}
|
||||
|
|
|
|||
|
|
@ -378,10 +378,10 @@ Kubernetesが使用しないようにする必要があります。
|
|||
## 拡張リソース {#extended-resources}
|
||||
|
||||
拡張リソースは`kubernetes.io`ドメインの外で完全に修飾されたリソース名です。
|
||||
これにより、クラスタオペレーターはKubernetesに組み込まれていないリソースをアドバタイズし、ユーザはそれを利用することができるようになります。
|
||||
これにより、クラスターオペレーターはKubernetesに組み込まれていないリソースをアドバタイズし、ユーザはそれを利用することができるようになります。
|
||||
|
||||
拡張リソースを使用するためには、2つのステップが必要です。
|
||||
第一に、クラスタオペレーターは拡張リソースをアドバタイズする必要があります。
|
||||
第一に、クラスターオペレーターは拡張リソースをアドバタイズする必要があります。
|
||||
第二に、ユーザーはPodで拡張リソースを要求する必要があります。
|
||||
|
||||
### 拡張リソースの管理 {#managing-extended-resources}
|
||||
|
|
@ -394,7 +394,7 @@ Nodeレベルの拡張リソースはNodeに関連付けられています。
|
|||
各Nodeにデバイスプラグインで管理されているリソースをアドバタイズする方法については、[デバイスプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)を参照してください。
|
||||
|
||||
##### その他のリソース {#other-resources}
|
||||
新しいNodeレベルの拡張リソースをアドバタイズするには、クラスタオペレーターはAPIサーバに`PATCH`HTTPリクエストを送信し、クラスタ内のNodeの`status.capacity`に利用可能な量を指定します。
|
||||
新しいNodeレベルの拡張リソースをアドバタイズするには、クラスターオペレーターはAPIサーバに`PATCH`HTTPリクエストを送信し、クラスター内のNodeの`status.capacity`に利用可能な量を指定します。
|
||||
この操作の後、ノードの`status.capacity`には新しいリソースが含まれます。
|
||||
`status.allocatable`フィールドは、kubeletによって非同期的に新しいリソースで自動的に更新されます。
|
||||
スケジューラはPodの適合性を評価する際にNodeの`status.allocatable`値を使用するため、Nodeの容量に新しいリソースを追加してから、そのNodeでリソースのスケジューリングを要求する最初のPodが現れるまでには、短い遅延が生じる可能性があることに注意してください。
|
||||
|
|
@ -513,7 +513,7 @@ Events:
|
|||
同様のエラーメッセージは、メモリー不足による失敗を示唆することもあります(PodExceedsFreeMemory)。
|
||||
一般的に、このタイプのメッセージでPodが保留されている場合は、いくつか試すべきことがあります。
|
||||
|
||||
- クラスタにNodeを追加します。
|
||||
- クラスターにNodeを追加します。
|
||||
- 不要なポッドを終了して、保留中のPodのためのスペースを空けます。
|
||||
- PodがすべてのNodeよりも大きくないことを確認してください。
|
||||
例えば、すべてのNodeが`cpu: 1`の容量を持っている場合、`cpu: 1.1`を要求するPodは決してスケジューリングされません。
|
||||
|
|
|
|||
|
|
@ -44,7 +44,7 @@ weight: 10
|
|||
|
||||
*これは順序付けの必要性を意味します* - `Pod`がアクセスしたい`Service`は`Pod`自身の前に作らなければならず、そうしないと環境変数は注入されません。DNSにはこの制限はありません。
|
||||
|
||||
- （強くお勧めしますが）[クラスターアドオン](/ja/docs/concepts/cluster-administration/addons/)の1つの選択肢はDNSサーバーです。DNSサーバーは、新しい`Service`についてKubernetes APIを監視し、それぞれに対して一連のDNSレコードを作成します。クラスタ全体でDNSが有効になっている場合は、すべての`Pod`が自動的に`Services`の名前解決を行えるはずです。
|
||||
- （強くお勧めしますが）[クラスターアドオン](/ja/docs/concepts/cluster-administration/addons/)の1つの選択肢はDNSサーバーです。DNSサーバーは、新しい`Service`についてKubernetes APIを監視し、それぞれに対して一連のDNSレコードを作成します。クラスター全体でDNSが有効になっている場合は、すべての`Pod`が自動的に`Services`の名前解決を行えるはずです。
|
||||
|
||||
- どうしても必要な場合以外は、Podに`hostPort`を指定しないでください。Podを`hostPort`にバインドすると、Podがスケジュールできる場所の数を制限します、それぞれの<`hostIP`、 `hostPort`、`protocol`>の組み合わせはユニークでなければならないからです。`hostIP`と`protocol`を明示的に指定しないと、Kubernetesはデフォルトの`hostIP`として`0.0.0.0`を、デフォルトの `protocol`として`TCP`を使います。
|
||||
|
||||
|
|
|
|||
|
|
@ -50,7 +50,7 @@ metadata:
|
|||
|
||||
## アプリケーションとアプリケーションのインスタンス
|
||||
|
||||
単一のアプリケーションは、Kubernetesクラスタ内で、いくつかのケースでは同一の名前空間に対して1回または複数回インストールされることがあります。
|
||||
単一のアプリケーションは、Kubernetesクラスター内で、いくつかのケースでは同一の名前空間に対して1回または複数回インストールされることがあります。
|
||||
例えば、WordPressは複数のウェブサイトがあれば、それぞれ別のWordPressが複数回インストールされることがあります。
|
||||
|
||||
アプリケーション名と、アプリケーションのインスタンス名はそれぞれ別に記録されます。
|
||||
|
|
|
|||
|
|
@ -52,7 +52,7 @@ kubectl create deployment nginx --image nginx
|
|||
オブジェクト設定手法に対する長所:
|
||||
|
||||
- コマンドは簡潔、簡単に学ぶことができ、そして覚えやすいです
|
||||
- コマンドではクラスタの設定を変えるのに、わずか1ステップしか必要としません
|
||||
- コマンドではクラスターの設定を変えるのに、わずか1ステップしか必要としません
|
||||
|
||||
オブジェクト設定手法に対する短所:
|
||||
|
||||
|
|
|
|||
|
|
@ -46,7 +46,7 @@ kubectl get pods -n kube-system | grep kube-scheduler
|
|||
|
||||
### デフォルトの閾値
|
||||
|
||||
閾値を指定しない場合、Kubernetesは100ノードのクラスタでは50%、5000ノードのクラスタでは10%になる線形方程式を使用して数値を計算します。自動計算の下限は5%です。
|
||||
閾値を指定しない場合、Kubernetesは100ノードのクラスターでは50%、5000ノードのクラスターでは10%になる線形方程式を使用して数値を計算します。自動計算の下限は5%です。
|
||||
|
||||
つまり、明示的に`percentageOfNodesToScore`を5未満の値を設定しない限り、クラスターの規模に関係なく、kube-schedulerは常に少なくともクラスターの5%のノードに対してスコア付けをします。
|
||||
|
||||
|
|
@ -72,9 +72,9 @@ percentageOfNodesToScore: 50
|
|||
`percentageOfNodesToScore`は1から100の間の範囲である必要があり、デフォルト値はクラスターのサイズに基づいて計算されます。また、クラスターのサイズの最小値は50ノードとハードコードされています。
|
||||
|
||||
{{< note >}}
|
||||
割り当て可能なノードが50以下のクラスタでは、スケジューラの検索を早期に停止するのに十分な割り当て可能なノードがないため、スケジューラはすべてのノードをチェックします。
|
||||
割り当て可能なノードが50以下のクラスターでは、スケジューラの検索を早期に停止するのに十分な割り当て可能なノードがないため、スケジューラはすべてのノードをチェックします。
|
||||
|
||||
小規模クラスタでは、`percentageOfNodesToScore`に低い値を設定したとしても、同様の理由で変更による影響は全くないか、ほとんどありません。
|
||||
小規模クラスターでは、`percentageOfNodesToScore`に低い値を設定したとしても、同様の理由で変更による影響は全くないか、ほとんどありません。
|
||||
|
||||
クラスターのノード数が数百以下の場合は、この設定オプションをデフォルト値のままにします。変更してもスケジューラの性能を大幅に改善する可能性はほとんどありません。
|
||||
{{< /note >}}
|
||||
|
|
|
|||
|
|
@ -9,4 +9,4 @@ Kubernetesのネットワーキングは4つの懸念事項に対処します。
|
|||
- Pod内のコンテナは、ネットワーキングを利用してループバック経由の通信を行います。
|
||||
- クラスターネットワーキングは、異なるPod間の通信を提供します。
|
||||
- Serviceリソースは、Pod内で動作しているアプリケーションへクラスターの外部から到達可能なように露出を許可します。
|
||||
- Serviceを利用して、クラスタ内部のみで使用するServiceの公開も可能です。
|
||||
- Serviceを利用して、クラスター内部のみで使用するServiceの公開も可能です。
|
||||
|
|
|
|||
|
|
@ -139,7 +139,7 @@ Service IPは完全に仮想的なもので、ホスト側のネットワーク
|
|||
## Serviceにアクセスする
|
||||
|
||||
Kubernetesは、環境変数とDNSの2つの主要なService検索モードをサポートしています。
|
||||
前者はそのまま使用でき、後者は[CoreDNSクラスタアドオン](https://releases.k8s.io/{{< param "fullversion" >}}/cluster/addons/dns/coredns)を必要とします。
|
||||
前者はそのまま使用でき、後者は[CoreDNSクラスターアドオン](https://releases.k8s.io/{{< param "fullversion" >}}/cluster/addons/dns/coredns)を必要とします。
|
||||
{{< note >}}
|
||||
サービス環境変数が望ましくない場合(予想されるプログラム変数と衝突する可能性がある、処理する変数が多すぎる、DNSのみを使用するなど)、[Pod仕様](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)で`enableServiceLinks`フラグを`false`に設定することでこのモードを無効にできます。
|
||||
{{< /note >}}
|
||||
|
|
|
|||
|
|
@ -83,7 +83,7 @@ CSIエフェメラルボリュームを使用すると、ユーザーはPod仕
|
|||
通常は管理者に制限されている`volumeAttributes`を許可するCSIドライバーは、インラインエフェメラルボリュームでの使用には適していません。
|
||||
たとえば、通常StorageClassで定義されるパラメーターは、インラインエフェメラルボリュームを使用してユーザーに公開しないでください。
|
||||
|
||||
Pod仕様内でインラインボリュームとして使用できるCSIドライバーを制限する必要があるクラスタ管理者は、次の方法で行うことができます。
|
||||
Pod仕様内でインラインボリュームとして使用できるCSIドライバーを制限する必要があるクラスター管理者は、次の方法で行うことができます。
|
||||
|
||||
- CSIドライバー仕様の`volumeLifecycleModes`から`Ephemeral`を削除します。これにより、ドライバーをインラインエフェメラルボリュームとして使用できなくなります。
|
||||
- [admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/)を使用して、このドライバーの使用方法を制限します。
|
||||
|
|
|
|||
|
|
@ -386,7 +386,7 @@ PersistentVolumeは、リソースプロバイダーがサポートする方法
|
|||
: ボリュームは多数のNodeで読み取り/書き込みとしてマウントできます
|
||||
|
||||
`ReadWriteOncePod`
|
||||
: ボリュームは、単一のPodで読み取り/書き込みとしてマウントできます。クラスタ全体で1つのPodのみがそのPVCの読み取りまたは書き込みを行えるようにする場合は、ReadWriteOncePodアクセスモードを使用します。これは、CSIボリュームとKubernetesバージョン1.22以降でのみサポートされます。
|
||||
: ボリュームは、単一のPodで読み取り/書き込みとしてマウントできます。クラスター全体で1つのPodのみがそのPVCの読み取りまたは書き込みを行えるようにする場合は、ReadWriteOncePodアクセスモードを使用します。これは、CSIボリュームとKubernetesバージョン1.22以降でのみサポートされます。
|
||||
|
||||
これについてはブログ[Introducing Single Pod Access Mode for PersistentVolumes](/blog/2021/09/13/read-write-once-pod-access-mode-alpha/)に詳細が記載されています。
|
||||
|
||||
|
|
|
|||
|
|
@ -159,7 +159,7 @@ spec:
|
|||
|
||||
### 許可されたトポロジー {#allowed-topologies}
|
||||
|
||||
クラスタオペレーターが`WaitForFirstConsumer`ボリュームバインディングモードを指定すると、ほとんどの状況でプロビジョニングを特定のトポロジに制限する必要がなくなります。ただし、それでも必要な場合は、`allowedTopologies`を指定できます。
|
||||
クラスターオペレーターが`WaitForFirstConsumer`ボリュームバインディングモードを指定すると、ほとんどの状況でプロビジョニングを特定のトポロジに制限する必要がなくなります。ただし、それでも必要な場合は、`allowedTopologies`を指定できます。
|
||||
|
||||
この例は、プロビジョニングされたボリュームのトポロジを特定のゾーンに制限する方法を示しており、サポートされているプラグインの`zone`および`zones`パラメーターの代わりとして使用する必要があります。
|
||||
|
||||
|
|
@ -274,7 +274,7 @@ parameters:
|
|||
|
||||
シークレットの例は[glusterfs-provisioning-secret.yaml](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/glusterfs/glusterfs-secret.yaml)にあります。
|
||||
|
||||
* `clusterid`:`630372ccdc720a92c681fb928f27b53f`は、ボリュームのプロビジョニング時にHeketiによって使用されるクラスターのIDです。また、クラスタIDのリストにすることもできます。これはオプションのパラメーターです。
|
||||
* `clusterid`:`630372ccdc720a92c681fb928f27b53f`は、ボリュームのプロビジョニング時にHeketiによって使用されるクラスターのIDです。また、クラスターIDのリストにすることもできます。これはオプションのパラメーターです。
|
||||
* `gidMin`、`gidMax`:StorageClassのGID範囲の最小値と最大値。この範囲内の一意の値(GID)(gidMin-gidMax)が、動的にプロビジョニングされたボリュームに使用されます。これらはオプションの値です。指定しない場合、ボリュームは、それぞれgidMinとgidMaxのデフォルトである2000から2147483647の間の値でプロビジョニングされます。
|
||||
* `volumetype`:ボリュームタイプとそのパラメーターは、このオプションの値で構成できます。ボリュームタイプが記載されていない場合、プロビジョニング担当者がボリュームタイプを決定します。
|
||||
例えば、
|
||||
|
|
@ -492,7 +492,7 @@ parameters:
|
|||
* `secretName`:Azureストレージアカウント名とキーを含むシークレットの名前。デフォルトは`azure-storage-account-<accountName>-secret`です
|
||||
* `readOnly`:ストレージが読み取り専用としてマウントされるかどうかを示すフラグ。デフォルトはfalseで、読み取り/書き込みマウントを意味します。この設定は、VolumeMountsの`ReadOnly`設定にも影響します。
|
||||
|
||||
ストレージのプロビジョニング中に、`secretName`という名前のシークレットがマウント資格証明用に作成されます。クラスタで[RBAC](/ja/docs/reference/access-authn-authz/rbac/)と[Controller Roles](/ja/docs/reference/access-authn-authz/rbac/#controller-roles)の両方が有効になっている場合は、追加します。clusterrole`system:controller:persistent-volume-binder`に対するリソース`secret`の`create`パーミッション。
|
||||
ストレージのプロビジョニング中に、`secretName`という名前のシークレットがマウント資格証明用に作成されます。クラスターで[RBAC](/ja/docs/reference/access-authn-authz/rbac/)と[Controller Roles](/ja/docs/reference/access-authn-authz/rbac/#controller-roles)の両方が有効になっている場合は、追加します。clusterrole`system:controller:persistent-volume-binder`に対するリソース`secret`の`create`パーミッション。
|
||||
|
||||
マルチテナンシーコンテキストでは、`secretNamespace`の値を明示的に設定することを強くお勧めします。そうしないと、ストレージアカウントの資格情報が他のユーザーに読み取られる可能性があります。
|
||||
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ weight: 80
|
|||
このページでは、特別な種類のコンテナであるエフェメラルコンテナの概要を説明します。エフェメラルコンテナは、トラブルシューティングなどのユーザーが開始するアクションを実行するために、すでに存在する{{< glossary_tooltip term_id="pod" >}}内で一時的に実行するコンテナです。エフェメラルコンテナは、アプリケーションの構築ではなく、serviceの調査のために利用します。
|
||||
|
||||
{{< warning >}}
|
||||
エフェメラルコンテナは初期のアルファ状態であり、本番クラスタには適しません。[Kubernetesの非推奨ポリシー](/docs/reference/using-api/deprecation-policy/)に従って、このアルファ機能は、将来大きく変更されたり、完全に削除される可能性があります。
|
||||
エフェメラルコンテナは初期のアルファ状態であり、本番クラスターには適しません。[Kubernetesの非推奨ポリシー](/docs/reference/using-api/deprecation-policy/)に従って、このアルファ機能は、将来大きく変更されたり、完全に削除される可能性があります。
|
||||
{{< /warning >}}
|
||||
|
||||
<!-- body -->
|
||||
|
|
|
|||
|
|
@ -55,7 +55,7 @@ Podの各フェーズの値と意味は厳重に守られています。ここ
|
|||
Podの削除中に、kubectlコマンドには`Terminating`が出力されることがあります。この`Terminating`ステータスは、Podのフェーズではありません。Podには、正常に終了するための期間を与えられており、デフォルトは30秒です。`--force`フラグを使用して、[Podを強制的に削除する](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination-forced)ことができます。
|
||||
{{< /note >}}
|
||||
|
||||
Nodeが停止するか、クラスタの残りの部分から切断された場合、Kubernetesは失われたNode上のすべてのPodの`Phase`をFailedに設定するためのポリシーを適用します。
|
||||
Nodeが停止するか、クラスターの残りの部分から切断された場合、Kubernetesは失われたNode上のすべてのPodの`Phase`をFailedに設定するためのポリシーを適用します。
|
||||
|
||||
## コンテナのステータス {#container-states}
|
||||
|
||||
|
|
@ -310,7 +310,7 @@ Podは、クラスター内のNodeで実行中のプロセスを表すため、
|
|||
|
||||
{{< caution >}}
|
||||
即時削除では、実行中のリソースの終了を待ちません。
|
||||
リソースはクラスタ上で無期限に実行し続ける可能性があります。
|
||||
リソースはクラスター上で無期限に実行し続ける可能性があります。
|
||||
{{< /caution >}}
|
||||
|
||||
StatefulSetのPodについては、[StatefulSetからPodを削除するためのタスクのドキュメント](/ja/docs/tasks/run-application/force-delete-stateful-set-pod/)を参照してください。
|
||||
|
|
|
|||
|
|
@ -91,7 +91,7 @@ Authorization: Bearer 31ada4fd-adec-460c-809a-9e56ceb75269
|
|||
|
||||
{{< feature-state for_k8s_version="v1.18" state="stable" >}}
|
||||
|
||||
新しいクラスタの効率的なブートストラップを可能にするために、Kubernetesには*ブートストラップトークン*と呼ばれる動的に管理されたBearerトークンタイプが含まれています。これらのトークンは、`kube-system`名前空間にSecretsとして格納され、動的に管理したり作成したりすることができます。コントローラーマネージャーには、TokenCleanerコントローラーが含まれており、ブートストラップトークンの有効期限が切れると削除します。
|
||||
新しいクラスターの効率的なブートストラップを可能にするために、Kubernetesには*ブートストラップトークン*と呼ばれる動的に管理されたBearerトークンタイプが含まれています。これらのトークンは、`kube-system`名前空間にSecretsとして格納され、動的に管理したり作成したりすることができます。コントローラーマネージャーには、TokenCleanerコントローラーが含まれており、ブートストラップトークンの有効期限が切れると削除します。
|
||||
|
||||
トークンの形式は`[a-z0-9]{6}.[a-z0-9]{16}`です。最初のコンポーネントはトークンIDであり、第2のコンポーネントはToken Secretです。以下のように、トークンをHTTPヘッダーに指定します。
|
||||
|
||||
|
|
@ -101,7 +101,7 @@ Authorization: Bearer 781292.db7bc3a58fc5f07e
|
|||
|
||||
APIサーバーの`--enable-bootstrap-token-auth`フラグで、Bootstrap Token Authenticatorを有効にする必要があります。TokenCleanerコントローラーを有効にするには、コントローラーマネージャーの`--controllers`フラグを使います。`--controllers=*,tokencleaner`のようにして行います。クラスターをブートストラップするために`kubeadm`を使用している場合は、`kubeadm`がこれを代行してくれます。
|
||||
|
||||
認証機能は`system:bootstrap:<Token ID>`という名前で認証します。これは`system:bootstrappers`グループに含まれます。名前とグループは意図的に制限されており、ユーザーがブートストラップ後にこれらのトークンを使わないようにしています。ユーザー名とグループは、クラスタのブートストラップをサポートする適切な認可ポリシーを作成するために使用され、`kubeadm`によって使用されます。
|
||||
認証機能は`system:bootstrap:<Token ID>`という名前で認証します。これは`system:bootstrappers`グループに含まれます。名前とグループは意図的に制限されており、ユーザーがブートストラップ後にこれらのトークンを使わないようにしています。ユーザー名とグループは、クラスターのブートストラップをサポートする適切な認可ポリシーを作成するために使用され、`kubeadm`によって使用されます。
|
||||
|
||||
ブートストラップトークンの認証機能やコントローラーについての詳細な説明、`kubeadm`でこれらのトークンを管理する方法については、[ブートストラップトークン](/docs/reference/access-authn-authz/bootstrap-tokens/)を参照してください。
|
||||
|
||||
|
|
@ -184,7 +184,7 @@ type: kubernetes.io/service-account-token
|
|||
Secretは常にbase64でエンコードされるため、これらの値もbase64でエンコードされています。
|
||||
{{< /note >}}
|
||||
|
||||
署名されたJWTは、与えられたサービスアカウントとして認証するためのBearerトークンとして使用できます。トークンをリクエストに含める方法については、[リクエストにBearerトークンを含める](#putting-a-bearer-token-in-a-request)を参照してください。通常、これらのSecretはAPIサーバーへのクラスタ内アクセス用にPodにマウントされますが、クラスター外からも使用することができます。
|
||||
署名されたJWTは、与えられたサービスアカウントとして認証するためのBearerトークンとして使用できます。トークンをリクエストに含める方法については、[リクエストにBearerトークンを含める](#putting-a-bearer-token-in-a-request)を参照してください。通常、これらのSecretはAPIサーバーへのクラスター内アクセス用にPodにマウントされますが、クラスター外からも使用することができます。
|
||||
|
||||
サービスアカウントは、ユーザー名`system:serviceaccount:(NAMESPACE):(SERVICEACCOUNT)`で認証され、グループ`system:serviceaccounts`と`system:serviceaccounts:(NAMESPACE)`に割り当てられます。
|
||||
|
||||
|
|
|
|||
|
|
@ -508,7 +508,7 @@ APIサーバーは、デフォルトのClusterRoleオブジェクトとClusterRo
|
|||
|
||||
起動するたびに、APIサーバーはデフォルトのClusterRoleを不足している権限で更新し、
|
||||
デフォルトのClusterRoleBindingを不足しているsubjectsで更新します。
|
||||
これにより、誤った変更をクラスタが修復できるようになり、新しいKubernetesリリースで権限とsubjectsが変更されても、
|
||||
これにより、誤った変更をクラスターが修復できるようになり、新しいKubernetesリリースで権限とsubjectsが変更されても、
|
||||
RoleとRoleBindingを最新の状態に保つことができます。
|
||||
|
||||
この調整を無効化するには`rbac.authorization.kubernetes.io/autoupdate`をデフォルトのClusterRoleまたはRoleBindingのアノテーションを`false`に設定します。
|
||||
|
|
@ -557,7 +557,7 @@ ClusterRoleを編集すると、変更が[自動調整](#自動調整)によるA
|
|||
|
||||
### ユーザー向けRole
|
||||
|
||||
一部のデフォルトClusterRolesにはプレフィックス`system:`が付いていません。これらは、ユーザー向けのroleを想定しています。それらは、スーパーユーザのRole(`cluster-admin`)、ClusterRoleBindingsを使用してクラスタ全体に付与されることを意図しているRole、そしてRoleBindings(`admin`, `edit`, `view`)を使用して、特定のNamespace内に付与されることを意図しているRoleを含んでいます。
|
||||
一部のデフォルトClusterRolesにはプレフィックス`system:`が付いていません。これらは、ユーザー向けのroleを想定しています。それらは、スーパーユーザのRole(`cluster-admin`)、ClusterRoleBindingsを使用してクラスター全体に付与されることを意図しているRole、そしてRoleBindings(`admin`, `edit`, `view`)を使用して、特定のNamespace内に付与されることを意図しているRoleを含んでいます。
|
||||
|
||||
ユーザー向けのClusterRolesは[ClusterRoleの集約](#集約clusterrole)を使用して、管理者がこれらのClusterRolesにカスタムリソースのルールを含めることができるようにします。ルールを`admin`、`edit`、または`view` Roleに追加するには、次のラベルの一つ以上でClusterRoleを作成します。
|
||||
|
||||
|
|
@ -907,7 +907,7 @@ subjects:
|
|||
|
||||
### `kubectl create clusterrolebinding`
|
||||
|
||||
以下に、クラスタ全体(すべてのNamespace)にClusterRoleをいくつか例として付与します。
|
||||
以下に、クラスター全体(すべてのNamespace)にClusterRoleをいくつか例として付与します。
|
||||
|
||||
* クラスター全体で、ClusterRole「cluster-admin」へのアクセス許可を「root」という名前のユーザーに付与します。
|
||||
|
||||
|
|
|
|||
|
|
@ -441,7 +441,7 @@ GAになってからさらなる変更を加えることは現実的ではない
|
|||
- `ServiceAppProtocol`: サービスとエンドポイントで`AppProtocol`フィールドを有効にします。
|
||||
- `ServiceLoadBalancerFinalizer`: サービスロードバランサーのファイナライザー保護を有効にします。
|
||||
- `ServiceNodeExclusion`: クラウドプロバイダーによって作成されたロードバランサーからのノードの除外を有効にします。"`alpha.service-controller.kubernetes.io/exclude-balancer`"キーまたは`node.kubernetes.io/exclude-from-external-load-balancers`でラベル付けされている場合ノードは除外の対象となります。
|
||||
- `ServiceTopology`: クラスタのノードトポロジーに基づいてトラフィックをルーティングするサービスを有効にします。詳細については、[Serviceトポロジー](/ja/docs/concepts/services-networking/service-topology/)を参照してください。
|
||||
- `ServiceTopology`: クラスターのノードトポロジーに基づいてトラフィックをルーティングするサービスを有効にします。詳細については、[Serviceトポロジー](/ja/docs/concepts/services-networking/service-topology/)を参照してください。
|
||||
- `StartupProbe`: kubeletで[startup](/ja/docs/concepts/workloads/pods/pod-lifecycle/#when-should-you-use-a-startup-probe)プローブを有効にします。
|
||||
- `StorageObjectInUseProtection`: PersistentVolumeまたはPersistentVolumeClaimオブジェクトがまだ使用されている場合、それらの削除を延期します。
|
||||
- `StorageVersionHash`: apiserversがディスカバリーでストレージのバージョンハッシュを公開できるようにします。
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ tags:
|
|||
- architecture
|
||||
- operation
|
||||
---
|
||||
クラウド特有の制御ロジックを組み込むKubernetesの{{< glossary_tooltip text="control plane" term_id="control-plane" >}}コンポーネントです。クラウドコントロールマネージャーは、クラスターをクラウドプロバイダーAPIをリンクし、クラスタのみで相互作用するコンポーネントからクラウドプラットフォームで相互作用するコンポーネントを分離します。
|
||||
クラウド特有の制御ロジックを組み込むKubernetesの{{< glossary_tooltip text="control plane" term_id="control-plane" >}}コンポーネントです。クラウドコントロールマネージャーは、クラスターをクラウドプロバイダーAPIをリンクし、クラスターのみで相互作用するコンポーネントからクラウドプラットフォームで相互作用するコンポーネントを分離します。
|
||||
|
||||
<!--more-->
|
||||
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ tags:
|
|||
|
||||
<!--more-->
|
||||
|
||||
CSIはベンダーがKubernetesリポジトリにコードを追加することなく(Kubernetesリポジトリツリー外のプラグインとして)独自のストレージプラグインを作成することを可能にします。CSIドライバをストレージプロバイダから利用するには、はじめに[クラスタにCSIプラグインをデプロイする](https://kubernetes-csi.github.io/docs/deploying.html)必要があります。その後のCSIドライバーを使用するための{{< glossary_tooltip text="StorageClass" term_id="storage-class" >}}を作成することができます。
|
||||
CSIはベンダーがKubernetesリポジトリにコードを追加することなく(Kubernetesリポジトリツリー外のプラグインとして)独自のストレージプラグインを作成することを可能にします。CSIドライバをストレージプロバイダから利用するには、はじめに[クラスターにCSIプラグインをデプロイする](https://kubernetes-csi.github.io/docs/deploying.html)必要があります。その後のCSIドライバーを使用するための{{< glossary_tooltip text="StorageClass" term_id="storage-class" >}}を作成することができます。
|
||||
|
||||
* [KubernetesにおけるCSIのドキュメント](/docs/concepts/storage/volumes/#csi)
|
||||
* [利用可能なCSIドライバの一覧](https://kubernetes-csi.github.io/docs/drivers.html)
|
||||
|
|
|
|||
|
|
@ -134,7 +134,7 @@ kubectl config set-context --current --namespace=<namespace-name>
|
|||
`proxy` | `kubectl proxy [--port=PORT] [--www=static-dir] [--www-prefix=prefix] [--api-prefix=prefix] [flags]` | Kubernetes APIサーバーへのプロキシーを実行します。
|
||||
`replace` | `kubectl replace -f FILENAME` | ファイルや標準出力から、リソースを置き換えます。
|
||||
`rollout` | `kubectl rollout SUBCOMMAND [options]` | リソースのロールアウトを管理します。有効なリソースには、Deployment、DaemonSetとStatefulSetが含まれます。
|
||||
`run` | <code>kubectl run NAME --image=image [--env="key=value"] [--port=port] [--dry-run=server|client|none] [--overrides=inline-json] [flags]</code> | 指定したイメージを、クラスタ上で実行します。
|
||||
`run` | <code>kubectl run NAME --image=image [--env="key=value"] [--port=port] [--dry-run=server|client|none] [--overrides=inline-json] [flags]</code> | 指定したイメージを、クラスター上で実行します。
|
||||
`scale` | <code>kubectl scale (-f FILENAME | TYPE NAME | TYPE/NAME) --replicas=COUNT [--resource-version=version] [--current-replicas=count] [flags]</code> | 指定したReplicationControllerのサイズを更新します。
|
||||
`set` | `kubectl set SUBCOMMAND [options]` | アプリケーションリソースを設定します。
|
||||
`taint` | `kubectl taint NODE NAME KEY_1=VAL_1:TAINT_EFFECT_1 ... KEY_N=VAL_N:TAINT_EFFECT_N [options]` | 1つ以上のNodeのtaintを更新します。
|
||||
|
|
@ -415,7 +415,7 @@ kubectl logs <pod-name>
|
|||
kubectl logs -f <pod-name>
|
||||
```
|
||||
|
||||
`kubectl diff` - 提案されたクラスタに対する更新の差分を表示します。
|
||||
`kubectl diff` - 提案されたクラスターに対する更新の差分を表示します。
|
||||
|
||||
```shell
|
||||
# pod.jsonに含まれるリソースの差分を表示します。
|
||||
|
|
|
|||
|
|
@ -11,13 +11,13 @@ Kubernetesには、Kubernetesシステムの操作に役立ついくつかの組
|
|||
[`kubectl`](/ja/docs/tasks/tools/install-kubectl/)は、Kubernetesのためのコマンドラインツールです。このコマンドはKubernetes cluster managerを操作します。
|
||||
|
||||
## Kubeadm
|
||||
[`kubeadm`](/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm/)は、物理サーバやクラウドサーバ、仮想マシン上にKubernetesクラスタを容易にプロビジョニングするためのコマンドラインツールです(現在はアルファ版です)。
|
||||
[`kubeadm`](/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm/)は、物理サーバやクラウドサーバ、仮想マシン上にKubernetesクラスターを容易にプロビジョニングするためのコマンドラインツールです(現在はアルファ版です)。
|
||||
|
||||
## Minikube
|
||||
[`minikube`](https://minikube.sigs.k8s.io/docs/)は、開発やテストのためにワークステーション上でシングルノードのKubernetesクラスタをローカルで実行するツールです。
|
||||
[`minikube`](https://minikube.sigs.k8s.io/docs/)は、開発やテストのためにワークステーション上でシングルノードのKubernetesクラスターをローカルで実行するツールです。
|
||||
|
||||
## Dashboard
|
||||
[`Dashboard`](/ja/docs/tasks/access-application-cluster/web-ui-dashboard/)は、KubernetesのWebベースのユーザインタフェースで、コンテナ化されたアプリケーションをKubernetesクラスタにデプロイしたり、トラブルシューティングしたり、クラスタとそのリソース自体を管理したりすることが出来ます。
|
||||
[`Dashboard`](/ja/docs/tasks/access-application-cluster/web-ui-dashboard/)は、KubernetesのWebベースのユーザインタフェースで、コンテナ化されたアプリケーションをKubernetesクラスターにデプロイしたり、トラブルシューティングしたり、クラスターとそのリソース自体を管理したりすることが出来ます。
|
||||
|
||||
## Helm
|
||||
[`Kubernetes Helm`](https://github.com/helm/helm)は、事前に設定されたKubernetesリソースのパッケージ、別名Kubernetes chartsを管理するためのツールです。
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ card:
|
|||
Kubernetesをインストールする際には、メンテナンスの容易さ、セキュリティ、制御、利用可能なリソース、クラスターの運用及び管理に必要な専門知識に基づいてインストレーションタイプを選んでください。
|
||||
|
||||
|
||||
Kubernetesクラスタはローカルマシン、クラウド、オンプレのデータセンターにデプロイすることもできますし、マネージドのKubernetesクラスターを選択することもできます。複数のクラウドプロバイダーやベアメタルの環境に跨ったカスタムソリューションもあります。
|
||||
Kubernetesクラスターはローカルマシン、クラウド、オンプレのデータセンターにデプロイすることもできますし、マネージドのKubernetesクラスターを選択することもできます。複数のクラウドプロバイダーやベアメタルの環境に跨ったカスタムソリューションもあります。
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ Kubernetesでは、TLS認証のためにPKI証明書が必要です。
|
|||
|
||||
<!-- body -->
|
||||
|
||||
## クラスタではどのように証明書が使われているのか
|
||||
## クラスターではどのように証明書が使われているのか
|
||||
|
||||
Kubernetesは下記の用途でPKIを必要とします：
|
||||
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ weight: 30
|
|||
|
||||
## ノード適合テスト
|
||||
|
||||
*ノード適合テスト* は、システムの検証とノードに対する機能テストを提供するコンテナ型のテストフレームワークです。このテストは、ノードがKubernetesの最小要件を満たしているかどうかを検証するもので、テストに合格したノードはKubernetesクラスタに参加する資格があることになります。
|
||||
*ノード適合テスト* は、システムの検証とノードに対する機能テストを提供するコンテナ型のテストフレームワークです。このテストは、ノードがKubernetesの最小要件を満たしているかどうかを検証するもので、テストに合格したノードはKubernetesクラスターに参加する資格があることになります。
|
||||
|
||||
## ノードの前提条件
|
||||
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ content_type: concept
|
|||
|
||||
<!-- overview -->
|
||||
|
||||
Minikubeはローカル環境でKubernetesを簡単に実行するためのツールです。Kubernetesを試したり日々の開発への使用を検討するユーザー向けに、PC上のVM内でシングルノードのKubernetesクラスタを実行することができます。
|
||||
Minikubeはローカル環境でKubernetesを簡単に実行するためのツールです。Kubernetesを試したり日々の開発への使用を検討するユーザー向けに、PC上のVM内でシングルノードのKubernetesクラスターを実行することができます。
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ kops is an automated provisioning system:
|
|||
|
||||
<!-- steps -->
|
||||
|
||||
## クラスタの作成
|
||||
## クラスターの作成
|
||||
|
||||
### (1/5) kopsのインストール
|
||||
|
||||
|
|
@ -122,7 +122,7 @@ brew update && brew install kops
|
|||
{{< /tabs >}}
|
||||
|
||||
|
||||
### (2/5) クラスタ用のroute53ドメインの作成
|
||||
### (2/5) クラスター用のroute53ドメインの作成
|
||||
|
||||
kops uses DNS for discovery, both inside the cluster and outside, so that you can reach the kubernetes API server
|
||||
from clients.
|
||||
|
|
@ -154,7 +154,7 @@ your cluster is configured correctly if you have the dig tool by running:
|
|||
|
||||
You should see the 4 NS records that Route53 assigned your hosted zone.
|
||||
|
||||
### (3/5) クラスタの状態を保存するS3バケットの作成
|
||||
### (3/5) クラスターの状態を保存するS3バケットの作成
|
||||
|
||||
kops lets you manage your clusters even after installation. To do this, it must keep track of the clusters
|
||||
that you have created, along with their configuration, the keys they are using etc. This information is stored
|
||||
|
|
@ -179,7 +179,7 @@ the S3 bucket name.
|
|||
We suggest putting this in your bash profile or similar.
|
||||
|
||||
|
||||
### (4/5) クラスタ設定の構築
|
||||
### (4/5) クラスター設定の構築
|
||||
|
||||
Run `kops create cluster` to create your cluster configuration:
|
||||
|
||||
|
|
@ -202,7 +202,7 @@ You can have several instance groups, for example if you wanted nodes that are a
|
|||
GPU and non-GPU instances.
|
||||
|
||||
|
||||
### (5/5) AWSにクラスタを作成
|
||||
### (5/5) AWSにクラスターを作成
|
||||
|
||||
Run "kops update cluster" to create your cluster in AWS:
|
||||
|
||||
|
|
|
|||
|
|
@ -64,7 +64,7 @@ ComponentConfigの詳細については、[このセクション](#configure-kub
|
|||
|
||||
### `kubeadm init`実行時の流れ
|
||||
|
||||
`kubeadm init`を実行した場合、kubeletの設定は`/var/lib/kubelet/config.yaml`に格納され、クラスターのConfigMapにもアップロードされます。ConfigMapは`kubelet-config-1.X`という名前で、`X`は初期化するKubernetesのマイナーバージョンを表します。またこの設定ファイルは、クラスタ内の全てのkubeletのために、クラスター全体設定の基準と共に`/etc/kubernetes/kubelet.conf`にも書き込まれます。この設定ファイルは、kubeletがAPIサーバと通信するためのクライアント証明書を指し示します。これは、[各kubeletにクラスターレベルの設定を配布](#propagating-cluster-level-configuration-to-each-kubelet)することの必要性を示しています。
|
||||
`kubeadm init`を実行した場合、kubeletの設定は`/var/lib/kubelet/config.yaml`に格納され、クラスターのConfigMapにもアップロードされます。ConfigMapは`kubelet-config-1.X`という名前で、`X`は初期化するKubernetesのマイナーバージョンを表します。またこの設定ファイルは、クラスター内の全てのkubeletのために、クラスター全体設定の基準と共に`/etc/kubernetes/kubelet.conf`にも書き込まれます。この設定ファイルは、kubeletがAPIサーバと通信するためのクライアント証明書を指し示します。これは、[各kubeletにクラスターレベルの設定を配布](#propagating-cluster-level-configuration-to-each-kubelet)することの必要性を示しています。
|
||||
|
||||
二つ目のパターンである、[インスタンス固有の設定内容を適用](#providing-instance-specific-configuration-details)するために、kubeadmは環境ファイルを`/var/lib/kubelet/kubeadm-flags.env`へ書き出します。このファイルは以下のように、kubelet起動時に渡されるフラグのリストを含んでいます。
|
||||
|
||||
|
|
|
|||
|
|
@ -18,10 +18,10 @@ weight: 20
|
|||
|
||||
<!-- body -->
|
||||
|
||||
## RBACがないため、v1.18ノードをv1.17クラスタに結合できない
|
||||
v1.18では、同名のノードが既に存在する場合にクラスタ内のノードに参加しないようにする機能を追加しました。これには、ブートストラップトークンユーザがNodeオブジェクトをGETできるようにRBACを追加する必要がありました。
|
||||
## RBACがないため、v1.18ノードをv1.17クラスターに結合できない
|
||||
v1.18では、同名のノードが既に存在する場合にクラスター内のノードに参加しないようにする機能を追加しました。これには、ブートストラップトークンユーザがNodeオブジェクトをGETできるようにRBACを追加する必要がありました。
|
||||
|
||||
しかし、これによりv1.18の`kubeadm join`がkubeadm v1.17で作成したクラスタに参加できないという問題が発生します。
|
||||
しかし、これによりv1.18の`kubeadm join`がkubeadm v1.17で作成したクラスターに参加できないという問題が発生します。
|
||||
|
||||
この問題を回避するには、次の2つの方法があります。
|
||||
- kubeadm v1.18を用いて、コントロールプレーンノード上で`kubeadm init phase bootstrap-token`を実行します。
|
||||
|
|
@ -240,7 +240,7 @@ kubectl -n kube-system get deployment coredns -o yaml | \
|
|||
CoreDNSに`CrashLoopBackOff`が発生する別の原因は、KubernetesにデプロイされたCoreDNS Podがループを検出したときに発生します。CoreDNSがループを検出して終了するたびに、KubernetesがCoreDNS Podを再起動しようとするのを避けるために、[いくつかの回避策](https://github.com/coredns/coredns/tree/master/plugin/loop#troubleshooting-loops-in-kubernetes-clusters)が用意されています。
|
||||
|
||||
{{< warning >}}
|
||||
SELinuxを無効にするか`allowPrivilegeEscalation`を`true`に設定すると、クラスタのセキュリティが損なわれる可能性があります。
|
||||
SELinuxを無効にするか`allowPrivilegeEscalation`を`true`に設定すると、クラスターのセキュリティが損なわれる可能性があります。
|
||||
{{< /warning >}}
|
||||
|
||||
## etcdのpodが継続的に再起動する
|
||||
|
|
@ -343,6 +343,6 @@ nodeRegistration:
|
|||
あるいは、`/usr`マウントを書き込み可能にするために `/etc/fstab`を変更することもできますが、これはLinuxディストリビューションの設計原理を変更していることに注意してください。
|
||||
|
||||
## `kubeadm upgrade plan`が`context deadline exceeded`エラーメッセージを表示する
|
||||
このエラーメッセージは、外部etcdを実行している場合に`kubeadm`でKubernetesクラスタをアップグレードする際に表示されます。これは致命的なバグではなく、古いバージョンのkubeadmが外部etcdクラスタのバージョンチェックを行うために発生します。`kubeadm upgrade apply ...`で進めることができます。
|
||||
このエラーメッセージは、外部etcdを実行している場合に`kubeadm`でKubernetesクラスターをアップグレードする際に表示されます。これは致命的なバグではなく、古いバージョンのkubeadmが外部etcdクラスターのバージョンチェックを行うために発生します。`kubeadm upgrade apply ...`で進めることができます。
|
||||
|
||||
この問題はバージョン1.19で修正されます。
|
||||
|
|
|
|||
|
|
@ -195,7 +195,7 @@ Windowsでは、次のIPAMオプションがサポートされています。
|
|||
|
||||
#### コントロールプレーン
|
||||
|
||||
Windowsは、Kubernetesアーキテクチャとコンポーネントマトリックスのワーカーノードとしてのみサポートされています。つまり、Kubernetesクラスタには常にLinuxマスターノード、0以上のLinuxワーカーノード、0以上のWindowsワーカーノードが含まれている必要があります。
|
||||
Windowsは、Kubernetesアーキテクチャとコンポーネントマトリックスのワーカーノードとしてのみサポートされています。つまり、Kubernetesクラスターには常にLinuxマスターノード、0以上のLinuxワーカーノード、0以上のWindowsワーカーノードが含まれている必要があります。
|
||||
|
||||
#### コンピュート
|
||||
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ weight: 60
|
|||
|
||||
{{< codenew file="service/access/hello-application.yaml" >}}
|
||||
|
||||
1. クラスタでHello Worldアプリケーションを稼働させます:
|
||||
1. クラスターでHello Worldアプリケーションを稼働させます:
|
||||
上記のファイルを使用し、アプリケーションのDeploymentを作成します:
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/service/access/hello-application.yaml
|
||||
|
|
|
|||
|
|
@ -89,7 +89,7 @@ Kubeconfigの認証方法は、外部IDプロバイダーやx509証明書ベー
|
|||
- **Container image** (必須): 任意のレジストリ上の公開Docker[コンテナイメージ](/docs/concepts/containers/images/)、またはプライベートイメージ(一般的にはGoogle Container RegistryやDocker Hub上でホストされている)のURLです。
|
||||
コンテナイメージの指定はコロンで終わらせる必要があります。
|
||||
|
||||
クラスタ全体で必要な数のPodを維持するために、[Deployment](/ja/docs/concepts/workloads/controllers/deployment/)が作成されます。
|
||||
クラスター全体で必要な数のPodを維持するために、[Deployment](/ja/docs/concepts/workloads/controllers/deployment/)が作成されます。
|
||||
|
||||
- **Service** (任意): アプリケーションのいくつかの部分(たとえばフロントエンド)では、
|
||||
[Service](/ja/docs/concepts/services-networking/service/)をクラスター外の外部、おそらくパブリックIPアドレス(外部サービス)に公開したいと思うかもしれません。
|
||||
|
|
@ -124,7 +124,7 @@ Kubeconfigの認証方法は、外部IDプロバイダーやx509証明書ベー
|
|||
```
|
||||
|
||||
- **Namespace**: Kubernetesは、同じ物理クラスターを基盤とする複数の仮想クラスターをサポートしています。
|
||||
これらの仮想クラスタは[名前空間](/docs/tasks/administer-cluster/namespaces/) と呼ばれます。
|
||||
これらの仮想クラスターは[名前空間](/docs/tasks/administer-cluster/namespaces/) と呼ばれます。
|
||||
これにより、リソースを論理的に名前のついたグループに分割することができます。
|
||||
|
||||
ダッシュボードでは、利用可能なすべての名前空間がドロップダウンリストに表示され、新しい名前空間を作成することができます。
|
||||
|
|
|
|||
|
|
@ -217,7 +217,7 @@ LimitRangeによってNamespaceに課される最大および最小のメモリ
|
|||
|
||||
例:
|
||||
|
||||
* クラスター内の各ノードは2GBのメモリーを持っています。クラスタ内のどのノードもその要求をサポートできないため、2GB以上のメモリーを要求するPodは受け入れたくありません。
|
||||
* クラスター内の各ノードは2GBのメモリーを持っています。クラスター内のどのノードもその要求をサポートできないため、2GB以上のメモリーを要求するPodは受け入れたくありません。
|
||||
|
||||
|
||||
* クラスターは運用部門と開発部門で共有されています。 本番用のワークロードでは最大8GBのメモリーを消費しますが、開発用のワークロードでは512MBに制限したいとします。本番用と開発用に別々のNamespaceを作成し、それぞれのNamespaceにメモリー制限を適用します。
|
||||
|
|
|
|||
|
|
@ -46,7 +46,7 @@ NodeLocal DNSキャッシュは、クラスターノード上でDNSキャッシ
|
|||
{{< figure src="/images/docs/nodelocaldns.svg" alt="NodeLocal DNSCache flow" title="Nodelocal DNSCacheのフロー" caption="この図は、NodeLocal DNSキャッシュがDNSクエリーをどう扱うかを表したものです。" >}}
|
||||
|
||||
## 設定
|
||||
{{< note >}} NodeLocal DNSキャッシュのローカルリッスン用のIPアドレスは、クラスタ内の既存のIPと衝突しないことが保証できるものであれば、どのようなアドレスでもかまいません。例えば、IPv4のリンクローカル範囲169.254.0.0/16やIPv6のユニークローカルアドレス範囲fd00::/8から、ローカルスコープのアドレスを使用することが推奨されています。
|
||||
{{< note >}} NodeLocal DNSキャッシュのローカルリッスン用のIPアドレスは、クラスター内の既存のIPと衝突しないことが保証できるものであれば、どのようなアドレスでもかまいません。例えば、IPv4のリンクローカル範囲169.254.0.0/16やIPv6のユニークローカルアドレス範囲fd00::/8から、ローカルスコープのアドレスを使用することが推奨されています。
|
||||
{{< /note >}}
|
||||
|
||||
この機能は、下記の手順により有効化できます。
|
||||
|
|
|
|||
|
|
@ -74,7 +74,7 @@ Kubeletsは、ノードやコンテナの強力な制御を可能にするHTTPS
|
|||
|
||||
Kubernetesにおける権限付与は、意図的にハイレベルであり、リソースに対する粗いアクションに焦点を当てています。
|
||||
|
||||
より強力なコントロールは**policies**として存在し、それらのオブジェクトがクラスタや自身、その他のリソースにどのように作用するかをユースケースによって制限します。
|
||||
より強力なコントロールは**policies**として存在し、それらのオブジェクトがクラスターや自身、その他のリソースにどのように作用するかをユースケースによって制限します。
|
||||
|
||||
### クラスターのリソース使用量の制限
|
||||
|
||||
|
|
@ -106,7 +106,7 @@ Linuxカーネルは、ハードウェアが接続されたときやファイル
|
|||
# DCCPは必要性が低く、複数の深刻な脆弱性があり、保守も十分ではありません。
|
||||
blacklist dccp
|
||||
|
||||
# SCTPはほとんどのKubernetesクラスタでは使用されておらず、また過去には脆弱性がありました。
|
||||
# SCTPはほとんどのKubernetesクラスターでは使用されておらず、また過去には脆弱性がありました。
|
||||
blacklist sctp
|
||||
```
|
||||
|
||||
|
|
@ -120,7 +120,7 @@ blacklist sctp
|
|||
|
||||
サポートされている[Kubernetes networking providers](/ja/docs/concepts/cluster-administration/networking/)の多くは、ネットワークポリシーを尊重するようになりました。
|
||||
クォータやリミットの範囲は、ユーザーがノードポートや負荷分散サービスを要求するかどうかを制御するためにも使用でき、多くのクラスターでは、ユーザーのアプリケーションがクラスターの外で見えるかどうかを制御できます。
|
||||
ノードごとのファイアウォール、クロストークを防ぐための物理的なクラスタノードの分離、高度なネットワークポリシーなど、プラグインや環境ごとにネットワークルールを制御する追加の保護機能が利用できる場合もあります。
|
||||
ノードごとのファイアウォール、クロストークを防ぐための物理的なクラスターノードの分離、高度なネットワークポリシーなど、プラグインや環境ごとにネットワークルールを制御する追加の保護機能が利用できる場合もあります。
|
||||
|
||||
### クラウドメタデータのAPIアクセスを制限
|
||||
|
||||
|
|
@ -145,7 +145,7 @@ Kubernetesは、エンドユーザーが利用できる[Node上へのPodのス
|
|||
|
||||
### etcdへのアクセスの制限
|
||||
|
||||
API用のetcdバックエンドへの書き込みアクセスは、クラスタ全体のrootを取得するのと同等であり、読み取りアクセスはかなり迅速にエスカレートするために使用できます。
|
||||
API用のetcdバックエンドへの書き込みアクセスは、クラスター全体のrootを取得するのと同等であり、読み取りアクセスはかなり迅速にエスカレートするために使用できます。
|
||||
管理者は、TLSクライアント証明書による相互認証など、APIサーバーからetcdサーバーへの強力な認証情報を常に使用すべきであり、API サーバーのみがアクセスできるファイアウォールの後ろにetcdサーバーを隔離することがしばしば推奨されます。
|
||||
|
||||
{{< caution >}}
|
||||
|
|
|
|||
|
|
@ -139,7 +139,7 @@ kubectl delete deployment nginx-deployment --cascade=background
|
|||
|
||||
## オーナーオブジェクトの削除と従属オブジェクトの孤立 {#set-orphan-deletion-policy}
|
||||
|
||||
デフォルトでは、Kubernetesにオブジェクトの削除を指示すると、{{<glossary_tooltip text="コントローラー" term_id="controller">}}は従属オブジェクトも削除します。クラスタが動作しているKubernetesのバージョンに応じて、`kubectl`またはKubernetes APIを使用して、これらの従属オブジェクトをKubernetesで*orphan*にすることができます。{{<version-check>}}
|
||||
デフォルトでは、Kubernetesにオブジェクトの削除を指示すると、{{<glossary_tooltip text="コントローラー" term_id="controller">}}は従属オブジェクトも削除します。クラスターが動作しているKubernetesのバージョンに応じて、`kubectl`またはKubernetes APIを使用して、これらの従属オブジェクトをKubernetesで*orphan*にすることができます。{{<version-check>}}
|
||||
|
||||
**kubectlを使用する**
|
||||
|
||||
|
|
|
|||
|
|
@ -230,7 +230,7 @@ crictl logs --tail=1 87d3992f84f74
|
|||
### Podサンドボックスの実行
|
||||
|
||||
`crictl`を使ってPodサンドボックスを実行することは、コンテナのランタイムをデバッグするのに便利です。
|
||||
稼働中のKubernetesクラスタでは、サンドボックスは最終的にKubeletによって停止され、削除されます。
|
||||
稼働中のKubernetesクラスターでは、サンドボックスは最終的にKubeletによって停止され、削除されます。
|
||||
|
||||
1. 以下のようなJSONファイルを作成します:
|
||||
|
||||
|
|
@ -259,7 +259,7 @@ crictl logs --tail=1 87d3992f84f74
|
|||
### コンテナの作成
|
||||
|
||||
コンテナの作成に`crictl`を使うと、コンテナのランタイムをデバッグするのに便利です。
|
||||
稼働中のKubernetesクラスタでは、サンドボックスは最終的にKubeletによって停止され、削除されます。
|
||||
稼働中のKubernetesクラスターでは、サンドボックスは最終的にKubeletによって停止され、削除されます。
|
||||
|
||||
1. busyboxイメージをプルします:
|
||||
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ Kubernetesアプリケーションは通常、複数の独立したサービス
|
|||
`telepresence`は、リモートKubernetesクラスターにサービスをプロキシーしながら、ローカルでサービスを開発・デバッグするプロセスを容易にするためのツールです。
|
||||
`telepresence` を使用すると、デバッガーやIDEなどのカスタムツールをローカルサービスで使用でき、ConfigMapやsecret、リモートクラスター上で動作しているサービスへのフルアクセスをサービスに提供します。
|
||||
|
||||
このドキュメントでは、リモートクラスタ上で動作しているサービスをローカルで開発・デバッグするために`telepresence`を使用する方法を説明します。
|
||||
このドキュメントでは、リモートクラスター上で動作しているサービスをローカルで開発・デバッグするために`telepresence`を使用する方法を説明します。
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
|
|
|||
|
|
@ -79,10 +79,10 @@ kubectl apply -f https://k8s.io/examples/application/mysql/mysql-services.yaml
|
|||
|
||||
ヘッドレスサービスは、StatefulSetコントローラーが
|
||||
StatefulSetの一部であるPodごとに作成するDNSエントリーのベースエントリーを提供します。
|
||||
この例ではヘッドレスサービスの名前は`mysql`なので、同じKubernetesクラスタの
|
||||
この例ではヘッドレスサービスの名前は`mysql`なので、同じKubernetesクラスターの
|
||||
同じ名前空間内の他のPodは、`<pod-name>.mysql`を名前解決することでPodにアクセスできます。
|
||||
|
||||
`mysql-read`と呼ばれるクライアントサービスは、独自のクラスタIPを持つ通常のServiceであり、
|
||||
`mysql-read`と呼ばれるクライアントサービスは、独自のクラスターIPを持つ通常のServiceであり、
|
||||
Ready状態のすべてのMySQL Podに接続を分散します。
|
||||
Serviceのエンドポイントには、MySQLマスターとすべてのスレーブが含まれる可能性があります。
|
||||
|
||||
|
|
@ -313,7 +313,7 @@ StatefulSetコントローラーは`mysql-2` Podがもう存在しないこと
|
|||
|
||||
### ノードをdrainする
|
||||
|
||||
Kubernetesクラスタに複数のノードがある場合は、
|
||||
Kubernetesクラスターに複数のノードがある場合は、
|
||||
[drain](/docs/reference/generated/kubectl/kubectl-commands/#drain)を発行して
|
||||
ノードのダウンタイム(例えばノードのアップグレード時など)をシミュレートできます。
|
||||
|
||||
|
|
@ -335,7 +335,7 @@ mysql-2 2/2 Running 0 15m 10.244.5.27 kubernetes-mini
|
|||
`<node-name>`は前のステップで確認したノードの名前に置き換えてください。
|
||||
|
||||
この操作はノード上の他のアプリケーションに影響を与える可能性があるため、
|
||||
**テストクラスタでのみこの操作を実行**するのが最善です。
|
||||
**テストクラスターでのみこの操作を実行**するのが最善です。
|
||||
|
||||
```shell
|
||||
kubectl drain <node-name> --force --delete-local-data --ignore-daemonsets
|
||||
|
|
|
|||
|
|
@ -70,7 +70,7 @@ spec.replicas > 1の場合、Kubernetesは不健康なPodの理由を判断で
|
|||
|
||||
永続的な障害が原因でPodが正常でない場合、障害を修正せずにスケーリングすると、StatefulSetメンバーシップが正しく機能するために必要な特定の最小レプリカ数を下回る状態になる可能性があります。これにより、StatefulSetが利用できなくなる可能性があります。
|
||||
|
||||
一時的な障害によってPodが正常でなくなり、Podが再び使用可能になる可能性がある場合は、一時的なエラーがスケールアップまたはスケールダウン操作の妨げになる可能性があります。一部の分散データベースでは、ノードが同時に参加および脱退するときに問題があります。このような場合は、アプリケーションレベルでスケーリング操作を考えることをお勧めします。また、ステートフルアプリケーションクラスタが完全に健全であることが確実な場合にのみスケーリングを実行してください。
|
||||
一時的な障害によってPodが正常でなくなり、Podが再び使用可能になる可能性がある場合は、一時的なエラーがスケールアップまたはスケールダウン操作の妨げになる可能性があります。一部の分散データベースでは、ノードが同時に参加および脱退するときに問題があります。このような場合は、アプリケーションレベルでスケーリング操作を考えることをお勧めします。また、ステートフルアプリケーションクラスターが完全に健全であることが確実な場合にのみスケーリングを実行してください。
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -289,7 +289,7 @@ PodのステータスはPendingとなり、`Pod Cannot enforce AppArmor: profile
|
|||
|
||||
### PodSecurityPolicyを使用したプロファイルの制限
|
||||
|
||||
PodSecurityPolicy extensionが有効になっている場合、クラスタ全体でAppArmorn制限が適用されます。PodSecurityPolicyを有効にするには、`apiserver`上で次のフラグを設定する必要があります。
|
||||
PodSecurityPolicy extensionが有効になっている場合、クラスター全体でAppArmorn制限が適用されます。PodSecurityPolicyを有効にするには、`apiserver`上で次のフラグを設定する必要があります。
|
||||
|
||||
```
|
||||
--enable-admission-plugins=PodSecurityPolicy[,others...]
|
||||
|
|
@ -306,7 +306,7 @@ defaultProfileNameオプションには、何も指定されなかった場合
|
|||
|
||||
### AppArmorの無効化
|
||||
|
||||
クラスタ上でAppArmorを利用可能にしたくない場合、次のコマンドラインフラグで無効化できます。
|
||||
クラスター上でAppArmorを利用可能にしたくない場合、次のコマンドラインフラグで無効化できます。
|
||||
|
||||
```
|
||||
--feature-gates=AppArmor=false
|
||||
|
|
@ -316,7 +316,7 @@ defaultProfileNameオプションには、何も指定されなかった場合
|
|||
|
||||
### AppArmorを使用するKubernetes v1.4にアップグレードする
|
||||
|
||||
クラスタをv1.4にアップグレードするために、AppArmorに関する操作は必要ありません。ただし、既存のPodがAppArmorのアノテーションを持っている場合、検証(またはPodSecurityPolicy admission)は行われません。もしpermissiveなプロファイルがノードに読み込まれていた場合、悪意のあるユーザーがPodの権限を上述のdocker-defaultより昇格させるために、permissiveなプロファイルを再適用する恐れがあります。これが問題となる場合、`apparmor.security.beta.kubernetes.io`のアノテーションを含むすべてのPodのクラスターをクリーンアップすることを推奨します。
|
||||
クラスターをv1.4にアップグレードするために、AppArmorに関する操作は必要ありません。ただし、既存のPodがAppArmorのアノテーションを持っている場合、検証(またはPodSecurityPolicy admission)は行われません。もしpermissiveなプロファイルがノードに読み込まれていた場合、悪意のあるユーザーがPodの権限を上述のdocker-defaultより昇格させるために、permissiveなプロファイルを再適用する恐れがあります。これが問題となる場合、`apparmor.security.beta.kubernetes.io`のアノテーションを含むすべてのPodのクラスターをクリーンアップすることを推奨します。
|
||||
|
||||
### 一般利用可能(General Availability)への更新パス {#upgrade-path-to-general-availability}
|
||||
|
||||
|
|
|
|||
|
|
@ -55,7 +55,7 @@ card:
|
|||
|
||||
MySQLとWordpressはそれぞれ、データを保存するためのPersistentVolumeを必要とします。各PersistentVolumeClaimはデプロイの段階で作成されます。
|
||||
|
||||
多くのクラスタ環境では、デフォルトのStorageClassがインストールされています。StorageClassがPersistentVolumeClaim中で指定されていなかった場合、クラスターのデフォルトのStorageClassが代わりに使われます。
|
||||
多くのクラスター環境では、デフォルトのStorageClassがインストールされています。StorageClassがPersistentVolumeClaim中で指定されていなかった場合、クラスターのデフォルトのStorageClassが代わりに使われます。
|
||||
|
||||
PersistentVolumeClaimが作成されるとき、StorageClassの設定に基づいてPersistentVolumeが動的にプロビジョニングされます。
|
||||
|
||||
|
|
|
|||
|
|
@ -62,12 +62,12 @@ Kubernetes - проект з відкритим вихідним кодом. В
|
|||
<button id="desktopShowVideoButton" onclick="kub.showVideo()">Переглянути відео</button>
|
||||
<br>
|
||||
<br>
|
||||
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/" button id="desktopKCButton">Відвідайте KubeCon у Північній Америці, 24-28 жовтня 2022 року</a>
|
||||
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/" button id="desktopKCButton">Відвідайте KubeCon + CloudNativeCon в Європі, 18-21 квітня 2023 року</a>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/" button id="desktopKCButton">Відвідайте KubeCon в Європі, 17-21 квітня 2023 року</a>
|
||||
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/" button id="desktopKCButton">Відвідайте KubeCon + CloudNativeCon у Північній Америці, 6-9 листопада 2023 року</a>
|
||||
|
||||
</div>
|
||||
<div id="videoPlayer">
|
||||
|
|
|
|||
|
|
@ -57,7 +57,7 @@ Prow 根据文件路径自动添加语言标签。感谢 SIG Docs 贡献者 [Jun
|
|||
```
|
||||
|
||||
|
||||
<!-- These repo labels let reviewers filter for PRs and issues by language. For example, you can now filter the k/website dashboard for [PRs with Chinese content](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+label%3Alanguage%2Fzh). -->
|
||||
<!-- These repo labels let reviewers filter for PRs and issues by language. For example, you can now filter the kubernetes/website dashboard for [PRs with Chinese content](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+label%3Alanguage%2Fzh). -->
|
||||
这些存储库标签允许审阅者按语言过滤 PR 和 issue。例如，您现在可以过滤 kubernetes/website 面板中[具有中文内容的 PR](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+label%3Alanguage%2Fzh)。
|
||||
|
||||
<!-- ### Team review -->
|
||||
|
|
|
|||
|
|
@ -0,0 +1,177 @@
|
|||
---
|
||||
layout: blog
|
||||
title: “使用更新后的 Go 版本保持 Kubernetes 安全”
|
||||
date: 2023-04-06
|
||||
slug: keeping-kubernetes-secure-with-updated-go-versions
|
||||
---
|
||||
<!--
|
||||
layout: blog
|
||||
title: "Keeping Kubernetes Secure with Updated Go Versions"
|
||||
date: 2023-04-06
|
||||
slug: keeping-kubernetes-secure-with-updated-go-versions
|
||||
-->
|
||||
|
||||
<!--
|
||||
**Author**: [Jordan Liggitt](https://github.com/liggitt) (Google)
|
||||
-->
|
||||
|
||||
**作者**：[Jordan Liggitt](https://github.com/liggitt) (Google)
|
||||
|
||||
**译者**：顾欣 (ICBC)
|
||||
|
||||
### 问题 {#the-problem}
|
||||
|
||||
<!--
|
||||
Since v1.19 (released in 2020), the Kubernetes project provides 12-14 months of patch releases for each minor version.
|
||||
This enables users to qualify and adopt Kubernetes versions in an annual upgrade cycle and receive security fixes for a year.
|
||||
-->
|
||||
从 2020 年发布的 v1.19 版本以来，Kubernetes 项目为每个次要版本提供 12-14 个月的补丁维护期。
|
||||
这使得用户可以按照年度升级周期来评估和选用 Kubernetes 版本，并持续一年获得安全修复。
|
||||
|
||||
<!--
|
||||
The [Go project](https://github.com/golang/go/wiki/Go-Release-Cycle#release-maintenance) releases new minor versions twice a year,
|
||||
and provides security fixes for the last two minor versions, resulting in about a year of support for each Go version.
|
||||
Even though each new Kubernetes minor version is built with a supported Go version when it is first released,
|
||||
that Go version falls out of support before the Kubernetes minor version does,
|
||||
and the lengthened Kubernetes patch support since v1.19 only widened that gap.
|
||||
-->
|
||||
[Go 项目](https://github.com/golang/go/wiki/Go-Release-Cycle#release-maintenance)每年发布两个新的次要版本，
|
||||
并为最近的两个版本提供安全修复，每个 Go 版本的维护期约为一年。
|
||||
尽管每个新的 Kubernetes 次要版本在最初发布时都是使用受支持的 Go 版本编译构建的，
|
||||
但在这一 Kubernetes 次要版本被停止支持之前，对应的 Go 版本就已经不被支持，
|
||||
并且由于 Kubernetes 从 v1.19 开始延长了补丁支持期，这个差距被进一步扩大。
|
||||
|
||||
<!--
|
||||
At the time this was written, just over half of all [Go patch releases](https://go.dev/doc/devel/release) (88/171) have contained fixes for issues with possible security implications.
|
||||
Even though many of these issues were not relevant to Kubernetes, some were, so it remained important to use supported Go versions that received those fixes.
|
||||
-->
|
||||
在编写本文时，包含了可能对安全产生影响的问题修复的 [Go 补丁发布版本](https://go.dev/doc/devel/release)
|
||||
刚刚过半（88/171）。尽管这些问题中很多都与 Kubernetes 无关，但有些确实相关，
|
||||
因此使用受支持的、已包含了这类修复的 Go 版本是非常重要的。
|
||||
|
||||
<!--
|
||||
An obvious solution would be to simply update Kubernetes release branches to new minor versions of Go.
|
||||
However, Kubernetes avoids [destabilizing changes in patch releases](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-release/cherry-picks.md#what-kind-of-prs-are-good-for-cherry-picks),
|
||||
and historically, this prevented updating existing release branches to new minor versions of Go, due to changes that were considered prohibitively complex, risky, or breaking to include in a patch release.
|
||||
Examples include:
|
||||
-->
|
||||
显而易见的解决方案之一是直接更新 Kubernetes 的发布分支，使用 Go 的新次要版本。
|
||||
然而，Kubernetes 避免在[补丁发布中引入破坏稳定性的变更](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-release/cherry-picks.md#what-kind-of-prs-are-good-for-cherry-picks)，
|
||||
过去，因为这些变更被认为包含过高的复杂性、风险或破坏性，不适合包含在补丁发布中，
|
||||
所以不能将现有发布分支更新到 Go 的新次要版本。
|
||||
示例包括：
|
||||
|
||||
<!--
|
||||
* Go 1.6: enabling http/2 by default
|
||||
* Go 1.14: EINTR handling issues
|
||||
* Go 1.17: dropping x509 CN support, ParseIP changes
|
||||
* Go 1.18: disabling x509 SHA-1 certificate support by default
|
||||
* Go 1.19: dropping current-dir LookPath behavior
|
||||
-->
|
||||
* Go 1.6: 默认支持 http/2
|
||||
* Go 1.14: EINTR 问题处理
|
||||
* Go 1.17: 取消 x509 CN 支持, ParseIP 更改
|
||||
* Go 1.18: 默认禁用 x509 SHA-1 证书支持
|
||||
* Go 1.19: 取消当前目录 LookPath 行为
|
||||
|
||||
<!--
|
||||
Some of these changes could be easily mitigated in Kubernetes code,
|
||||
some could only be opted out of via a user-specified `GODEBUG` envvar,
|
||||
and others required invasive code changes or could not be avoided at all.
|
||||
Because of this inconsistency, Kubernetes release branches have typically remained on a single Go minor version,
|
||||
and risked being unable to pick up relevant Go security fixes for the last several months of each Kubernetes minor version's support lifetime.
|
||||
-->
|
||||
其中一些更改可以基本不会影响 Kubernetes 代码，
|
||||
有些只能通过用户指定的 `GODEBUG` 环境变量来选择放弃更新，
|
||||
而其他变更则需要侵入式的代码变更或完全无法避免。
|
||||
由于这种不一致性，Kubernetes 的发布分支通常保持使用某个固定的 Go 次要版本，
|
||||
并在每个 Kubernetes 次要版本支持生命周期的最后几个月内，面临无法得到重要的 Go 安全修复的风险。
|
||||
|
||||
<!--
|
||||
When a relevant Go security fix was only available in newer Kubernetes minor versions,
|
||||
users would have to upgrade away from older Kubernetes minor versions before their 12-14 month support period ended, just to pick up those fixes.
|
||||
If a user was not prepared to do that upgrade, it could result in vulnerable Kubernetes clusters.
|
||||
Even if a user could accommodate the unexpected upgrade, the uncertainty made Kubernetes' annual support less reliable for planning.
|
||||
-->
|
||||
当某项重要的 Go 安全修复仅出现在较新的 Kubernetes 次要版本时，
|
||||
用户必须在旧的 Kubernetes 次要版本的 12-14 个月支持期结束之前完成升级，以获取这些修复。
|
||||
如果用户没有准备好升级，可能导致 Kubernetes 集群的安全漏洞。
|
||||
即使用户可以接受这种意外升级，这种不确定性也使得 Kubernetes 在年度支持从规划角度看变得不太可靠。
|
||||
|
||||
### 解决方案 {#the-solution}
|
||||
|
||||
<!--
|
||||
We're happy to announce that the gap between supported Kubernetes versions and supported Go versions has been resolved as of January 2023.
|
||||
-->
|
||||
我们很高兴地宣布，自2023年1月起，受支持的 Kubernetes 版本与受支持的 Go 版本之间的差距已得到解决。
|
||||
|
||||
<!--
|
||||
We worked closely with the Go team over the past year to address the difficulties adopting new Go versions.
|
||||
This prompted a [discussion](https://github.com/golang/go/discussions/55090), [proposal](https://github.com/golang/go/issues/56986),
|
||||
[talk at GopherCon](https://www.youtube.com/watch?v=v24wrd3RwGo), and a [design](https://go.dev/design/56986-godebug) for improving backward compatibility in Go,
|
||||
ensuring new Go versions can maintain compatible runtime behavior with previous Go versions for a minimum of two years (four Go releases).
|
||||
This allows projects like Kubernetes to update release branches to supported Go versions without exposing users to behavior changes.
|
||||
-->
|
||||
在过去的一年里，我们与 Go 团队密切合作，以解决采用新的 Go 版本的困难。
|
||||
这些工作推动了一场[讨论](https://github.com/golang/go/discussions/55090)、
|
||||
[提案](https://github.com/golang/go/issues/56986)、
|
||||
[GopherCon 演讲](https://www.youtube.com/watch?v=v24wrd3RwGo)和[设计](https://go.dev/design/56986-godebug)，
|
||||
以提高 Go 的向后兼容性，
|
||||
确保新的 Go 版本至少在两年（四个 Go 版本）内能够与之前的 Go 版本保持兼容的运行时行为。
|
||||
这使得像 Kubernetes 这样的项目能够将发布分支更新到受支持的 Go 版本，
|
||||
而不是将行为上的变更暴露给用户。
|
||||
|
||||
<!--
|
||||
The proposed improvements are on track to be [included in Go 1.21](https://tip.golang.org/doc/godebug), and the Go team already delivered targeted compatibility improvements in a Go 1.19 patch release in late 2022.
|
||||
Those changes enabled Kubernetes 1.23+ to update to Go 1.19 in January of 2023, while avoiding any user-facing configuration or behavior changes.
|
||||
All supported Kubernetes release branches now use supported Go versions, and can pick up new Go patch releases with available security fixes.
|
||||
-->
|
||||
所提议的改进正按计划[包含在 Go 1.21 中](https://tip.golang.org/doc/godebug)，
|
||||
而且 Go 团队已经在 2022 年底的 Go 1.19 补丁发布中提供了针对兼容性的改进。
|
||||
这些更改使 Kubernetes 1.23+ 在 2023 年 1 月升级到 Go 1.19，并避免了任何用户可见的配置或行为变化。
|
||||
现在所有受支持的 Kubernetes 发布分支都使用受支持的 Go 版本，
|
||||
并且可以使用包含可用的安全修复的、新的 Go 补丁发布。
|
||||
|
||||
<!--
|
||||
Going forward, Kubernetes maintainers remain committed to making Kubernetes patch releases as safe and non-disruptive as possible,
|
||||
so there are several requirements a new Go minor version must meet before existing Kubernetes release branches will update to use it:
|
||||
-->
|
||||
展望未来，Kubernetes 维护者仍致力于使 Kubernetes 补丁发布尽可能安全且不会造成破坏，
|
||||
因此在现有的 Kubernetes 发布分支更新使用新的 Go 次要版本之前，新的 Go 次要版本必须满足几个要求：
|
||||
|
||||
<!--
|
||||
1. The new Go version must be available for at least 3 months.
|
||||
This gives time for adoption by the Go community, and for reports of issues or regressions.
|
||||
2. The new Go version must be used in a new Kubernetes minor release for at least 1 month.
|
||||
This ensures all Kubernetes release-blocking tests pass on the new Go version,
|
||||
and gives time for feedback from the Kubernetes community on release candidates and early adoption of the new minor release.
|
||||
3. There must be no regressions from the previous Go version known to impact Kubernetes.
|
||||
4. Runtime behavior must be preserved by default, without requiring any action by Kubernetes users / administrators.
|
||||
5. Kubernetes libraries like `k8s.io/client-go` must remain compatible with the original Go version used for each minor release,
|
||||
so consumers won't *have* to update Go versions to pick up a library patch release (though they are encouraged to build with supported Go versions,
|
||||
which is made even easier with the [compatibility improvements](https://go.dev/design/56986-godebug) planned in Go 1.21).
|
||||
-->
|
||||
1. 新的 Go 版本必须至少已经推出 3 个月。
|
||||
这给了 Go 社区足够的时间进行报告并解决问题。
|
||||
2. 新的 Go 版本在新的 Kubernetes 次要版本中至少已经使用了 1 个月。
|
||||
这确保 Kubernetes 所有可能阻塞发布的测试都需要能在新的 Go 版本下通过，
|
||||
并在早期为 Kubernetes 社区对发布候选版本和新次要版本提供反馈时间。
|
||||
3. 与先前的 Go 版本相比，不能出现新的已知会影响 Kubernetes 的问题。
|
||||
4. 默认情况下必须保持运行时行为，而无需 Kubernetes 用户/管理员采取任何操作。
|
||||
5. Kubernetes 库，如 `k8s.io/client-go` 必须与每个次要版本最初使用的 Go 版本保持兼容，
|
||||
以便在获取库补丁时，用户不必更新 Go 版本（不过还是鼓励他们使用受支持的 Go 版本构建，
|
||||
因为 Go 1.21 计划中的[兼容性改进](https://go.dev/design/56986-godebug)会使得这一操作变简单）。
|
||||
|
||||
<!--
|
||||
The goal of all of this work is to unobtrusively make Kubernetes patch releases safer and more secure,
|
||||
and to make Kubernetes minor versions safe to use for the entire duration of their support lifetime.
|
||||
-->
|
||||
所有这些工作的目标是在不引人注意的情况下使 Kubernetes 补丁发布更加安全可靠，
|
||||
并确保在整个支持周期内 Kubernetes 次要版本用起来都是安全的。
|
||||
|
||||
<!--
|
||||
Many thanks to the Go team, especially Russ Cox, for helping drive these improvements in ways that will benefit all Go users, not just Kubernetes.
|
||||
-->
|
||||
非常感谢 Go 团队，尤其是 Russ Cox，他们推动了这些改进，
|
||||
使所有 Go 用户受益，而不仅仅是 Kubernetes。
|
||||
|
||||
|
|
@ -351,9 +351,9 @@ configure garbage collection:
|
|||
<!--
|
||||
* Learn more about [ownership of Kubernetes objects](/docs/concepts/overview/working-with-objects/owners-dependents/).
|
||||
* Learn more about Kubernetes [finalizers](/docs/concepts/overview/working-with-objects/finalizers/).
|
||||
* Learn about the [TTL controller](/docs/concepts/workloads/controllers/ttlafterfinished/) (beta) that cleans up finished Jobs.
|
||||
* Learn about the [TTL controller](/docs/concepts/workloads/controllers/ttlafterfinished/) that cleans up finished Jobs.
|
||||
-->
|
||||
* 进一步了解 [Kubernetes 对象的属主关系](/zh-cn/docs/concepts/overview/working-with-objects/owners-dependents/)。
|
||||
* 进一步了解 Kubernetes [finalizers](/zh-cn/docs/concepts/overview/working-with-objects/finalizers/)。
|
||||
* 进一步了解 [TTL 控制器](/zh-cn/docs/concepts/workloads/controllers/ttlafterfinished/) (Beta)，
|
||||
* 进一步了解 [TTL 控制器](/zh-cn/docs/concepts/workloads/controllers/ttlafterfinished/)，
|
||||
该控制器负责清理已完成的 Job。
|
||||
|
|
|
|||
|
|
@ -26,10 +26,10 @@ As part of this role, the API server has several key built-in security controls,
|
|||
audit logging and {{< glossary_tooltip text="admission controllers" term_id="admission-controller" >}}.
|
||||
However, there are ways to modify the configuration
|
||||
or content of the cluster that bypass these controls.
|
||||
-->
|
||||
作为此角色的一部分，API 服务器有几个关键的内置安全控制，
|
||||
-->
|
||||
API 服务器作为交互的主要入口，还提供了几种关键的内置安全控制，
|
||||
例如审计日志和{{< glossary_tooltip text="准入控制器" term_id="admission-controller" >}}。
|
||||
但是，有一些方法可以绕过这些安全控制从而修改集群的配置或内容。
|
||||
但有一些方式可以绕过这些安全控制从而修改集群的配置或内容。
|
||||
|
||||
<!--
|
||||
This page describes the ways in which the security controls built into the
|
||||
|
|
|
|||
|
|
@ -353,7 +353,8 @@ AppArmor 配置文件是通过注解的方式，以容器为粒度强制执行
|
|||
AppArmor is only available on Linux nodes, and enabled in
|
||||
[some Linux distributions](https://gitlab.com/apparmor/apparmor/-/wikis/home#distributions-and-ports).
|
||||
-->
|
||||
AppArmor 仅在 Linux 节点上可用，在[一些 Linux 发行版](https://gitlab.com/apparmor/apparmor/-/wikis/home#distributions-and-ports)中已启用。
|
||||
AppArmor 仅在 Linux 节点上可用，
|
||||
在[一些 Linux 发行版](https://gitlab.com/apparmor/apparmor/-/wikis/home#distributions-and-ports)中已启用。
|
||||
{{< /note >}}
|
||||
|
||||
#### SELinux
|
||||
|
|
@ -374,9 +375,47 @@ SELinux 标签可以[通过 `securityContext` 节](/zh-cn/docs/tasks/configure-p
|
|||
SELinux is only available on Linux nodes, and enabled in
|
||||
[some Linux distributions](https://en.wikipedia.org/wiki/Security-Enhanced_Linux#Implementations).
|
||||
-->
|
||||
SELinux 仅在 Linux 节点上可用，在[一些 Linux 发行版](https://en.wikipedia.org/wiki/Security-Enhanced_Linux#Implementations)中已启用。
|
||||
SELinux 仅在 Linux 节点上可用，
|
||||
在[一些 Linux 发行版](https://en.wikipedia.org/wiki/Security-Enhanced_Linux#Implementations)中已启用。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
## Logs and auditing
|
||||
|
||||
- [ ] Audit logs, if enabled, are protected from general access.
|
||||
- [ ] The `/logs` API is disabled (you are running kube-apiserver with
|
||||
`--enable-logs-handler=false`).
|
||||
-->
|
||||
## 日志和审计 {#logs-and-auditing}
|
||||
|
||||
- [ ] 审计日志（如果启用）将受到保护以防止常规访问。
|
||||
- [ ] `/logs` API 被禁用（你所运行的 kube-apiserver 设置了 `--enable-logs-handler=false`）。
|
||||
|
||||
<!--
|
||||
Kubernetes includes a `/logs` API endpoint, enabled by default,
|
||||
that lets users request the contents of the API server's `/var/log` directory over HTTP. Accessing
|
||||
that endpoint requires authentication.
|
||||
-->
|
||||
Kubernetes 包含一个 `/logs` API 端点，默认启用。
|
||||
这个端点允许用户通过 HTTP 来请求 API 服务器的 `/var/log` 目录的内容。
|
||||
访问此端点需要身份验证。
|
||||
|
||||
<!--
|
||||
Allowing broad access to Kubernetes logs can make security information
|
||||
available to a potential attacker.
|
||||
|
||||
As a good practice, set up a separate means to collect and aggregate
|
||||
control plane logs, and do not use the `/logs` API endpoint.
|
||||
Alternatively, if you run your control plane with the `/logs` API endpoint
|
||||
and limit the content of `/var/log` (within the host or container where the API server is running) to
|
||||
Kubernetes API server logs only.
|
||||
-->
|
||||
允许大范围访问 Kubernetes 日志可能会令安全信息被潜在的攻击者利用。
|
||||
|
||||
一个好的做法是设置一个单独的方式来收集和聚合控制平面日志，
|
||||
并且不要使用 `/logs` API 端点。另一个使用场景是你运行控制平面时启用了 `/logs` API 端点并
|
||||
（在运行 API 服务器的主机或容器内）将 `/var/log` 的内容限制为仅保存 Kubernetes API 服务器日志。
|
||||
|
||||
<!--
|
||||
## Pod placement
|
||||
|
||||
|
|
@ -414,8 +453,8 @@ admission controller.
|
|||
-->
|
||||
[节点选择器（Node Selector）](/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/)
|
||||
: 作为 Pod 规约的一部分来设置的键值对，指定 Pod 可部署到哪些节点。
|
||||
通过 [PodNodeSelector](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#podnodeselector)
|
||||
准入控制器可以在名字空间和集群级别强制实施节点选择。
|
||||
通过 [PodNodeSelector](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#podnodeselector)
|
||||
准入控制器可以在名字空间和集群级别强制实施节点选择。
|
||||
|
||||
<!--
|
||||
[PodTolerationRestriction](/docs/reference/access-authn-authz/admission-controllers/#podtolerationrestriction)
|
||||
|
|
@ -427,8 +466,8 @@ tolerations.
|
|||
-->
|
||||
[PodTolerationRestriction](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#podtolerationrestriction)
|
||||
: [容忍度](/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration/)准入控制器，
|
||||
允许管理员设置在名字空间内允许使用的容忍度。
|
||||
名字空间中的 Pod 只能使用名字空间对象的注解键上所指定的容忍度，这些键提供默认和允许的容忍度集合。
|
||||
允许管理员设置在名字空间内允许使用的容忍度。
|
||||
名字空间中的 Pod 只能使用名字空间对象的注解键上所指定的容忍度，这些键提供默认和允许的容忍度集合。
|
||||
|
||||
<!--
|
||||
[RuntimeClass](/docs/concepts/containers/runtime-class/)
|
||||
|
|
@ -439,7 +478,7 @@ overhead.
|
|||
-->
|
||||
[RuntimeClass](/zh-cn/docs/concepts/containers/runtime-class/)
|
||||
: RuntimeClass 是一个用于选择容器运行时配置的特性，容器运行时配置用于运行 Pod 中的容器，
|
||||
并以性能开销为代价提供或多或少的主机隔离能力。
|
||||
并以性能开销为代价提供或多或少的主机隔离能力。
|
||||
|
||||
## Secrets {#secrets}
|
||||
|
||||
|
|
@ -482,7 +521,7 @@ permission mechanism on files.
|
|||
需要 Secret 的 Pod 应该通过卷自动挂载这些信息，
|
||||
最好使用 [`emptyDir.medium` 选项](/zh-cn/docs/concepts/storage/volumes/#emptydir)存储在内存中。
|
||||
该机制还可以用于从第三方存储中注入 Secret 作为卷，如 [Secret Store CSI 驱动](https://secrets-store-csi-driver.sigs.k8s.io/)。
|
||||
与通过 RBAC 来允许 Pod 服务帐户访问 Secret 相比，应该优先使用上述机制。这种机制允许将 Secret 作为环境变量或文件添加到 Pod 中。
|
||||
与通过 RBAC 来允许 Pod 服务账号访问 Secret 相比，应该优先使用上述机制。这种机制允许将 Secret 作为环境变量或文件添加到 Pod 中。
|
||||
请注意，与带访问权限控制的文件相比，由于日志的崩溃转储，以及 Linux 的环境变量的非机密性，环境变量方法可能更容易发生泄漏。
|
||||
|
||||
<!--
|
||||
|
|
@ -493,13 +532,11 @@ or specifically for a pod. For Kubernetes v1.22 and above, use
|
|||
[Bound Service Accounts](/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-account-token-volume)
|
||||
for time-bound service account credentials.
|
||||
-->
|
||||
不应该将服务账号令牌挂载到不需要它们的 Pod 中。
|
||||
这可以通过在服务帐号内将
|
||||
不应该将服务账号令牌挂载到不需要它们的 Pod 中。这可以通过在服务账号内将
|
||||
[`automountServiceAccountToken`](/zh-cn/docs/tasks/configure-pod-container/configure-service-account/#use-the-default-service-account-to-access-the-api-server)
|
||||
设置为 `false` 来完成整个名字空间范围的配置，
|
||||
或者也可以单独在 Pod 层面定制。
|
||||
设置为 `false` 来完成整个名字空间范围的配置，或者也可以单独在 Pod 层面定制。
|
||||
对于 Kubernetes v1.22 及更高版本，
|
||||
请使用[绑定服务账号](/zh-cn/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-account-token-volume)作为有时间限制的服务帐号凭证。
|
||||
请使用[绑定服务账号](/zh-cn/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-account-token-volume)作为有时间限制的服务账号凭证。
|
||||
|
||||
<!--
|
||||
## Images
|
||||
|
|
@ -696,7 +733,8 @@ availability state and recommended to improve your security posture:
|
|||
-->
|
||||
[`DenyServiceExternalIPs`](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#denyserviceexternalips)
|
||||
: 拒绝使用 `Service.spec.externalIPs` 字段，已有的 Service 不受影响，新增或者变更时不允许使用。
|
||||
这是 [CVE-2020-8554：中间人使用 LoadBalancer 或 ExternalIP](https://github.com/kubernetes/kubernetes/issues/97076) 的缓解措施。
|
||||
这是 [CVE-2020-8554：中间人使用 LoadBalancer 或 ExternalIP](https://github.com/kubernetes/kubernetes/issues/97076)
|
||||
的缓解措施。
|
||||
|
||||
<!--
|
||||
[`NodeRestriction`](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)
|
||||
|
|
@ -708,8 +746,8 @@ placement to the controlled node.
|
|||
-->
|
||||
[`NodeRestriction`](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#noderestriction)
|
||||
: 将 kubelet 的权限限制为只能修改其拥有的 Pod API 资源或代表其自身的节点 API 资源。
|
||||
此插件还可以防止 kubelet 使用 `node-restriction.kubernetes.io/` 注解，
|
||||
攻击者可以使用该注解来访问 kubelet 的凭证，从而影响所控制的节点上的 Pod 布局。
|
||||
此插件还可以防止 kubelet 使用 `node-restriction.kubernetes.io/` 注解，
|
||||
攻击者可以使用该注解来访问 kubelet 的凭证，从而影响所控制的节点上的 Pod 布局。
|
||||
|
||||
<!--
|
||||
The third group includes plugins that are not enabled by default but could be
|
||||
|
|
|
|||
|
|
@ -0,0 +1,213 @@
|
|||
---
|
||||
title: Pod QoS 类
|
||||
content_type: concept
|
||||
weight: 85
|
||||
---
|
||||
<!--
|
||||
title: Pod Quality of Service Classes
|
||||
content_type: concept
|
||||
weight: 85
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
This page introduces _Quality of Service (QoS) classes_ in Kubernetes, and explains
|
||||
how Kubernetes assigns a QoS class to each Pods as a consequence of the resource
|
||||
constraints that you specify for the containers in that Pod. Kubernetes relies on this
|
||||
classification to make decisions about which Pods to evict when there are not enough
|
||||
available resources on a Node.
|
||||
-->
|
||||
本页介绍 Kubernetes 中的 **服务质量（Quality of Service，QoS）** 类，
|
||||
阐述 Kubernetes 如何根据为 Pod 中的容器指定的资源约束为每个 Pod 设置 QoS 类。
|
||||
Kubernetes 依赖这种分类来决定当 Node 上没有足够可用资源时要驱逐哪些 Pod。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
## Quality of Service classes
|
||||
-->
|
||||
## QoS 类 {#qos-class}
|
||||
|
||||
<!--
|
||||
Kubernetes classifies the Pods that you run and allocates each Pod into a specific
|
||||
_quality of service (QoS) class_. Kubernetes uses that classification to influence how different
|
||||
pods are handled. Kubernetes does this classification based on the
|
||||
[resource requests](/docs/concepts/configuration/manage-resources-containers/)
|
||||
of the {{< glossary_tooltip text="Containers" term_id="container" >}} in that Pod, along with
|
||||
how those requests relate to resource limits.
|
||||
This is known as {{< glossary_tooltip text="Quality of Service" term_id="qos-class" >}}
|
||||
(QoS) class. Kubernetes assigns every Pod a QoS class based on the resource requests
|
||||
and limits of its component Containers. QoS classes are used by Kubernetes to decide
|
||||
which Pods to evict from a Node experiencing
|
||||
[Node Pressure](/docs/concepts/scheduling-eviction/node-pressure-eviction/). The possible
|
||||
QoS classes are `Guaranteed`, `Burstable`, and `BestEffort`. When a Node runs out of resources,
|
||||
Kubernetes will first evict `BestEffort` Pods running on that Node, followed by `Burstable` and
|
||||
finally `Guaranteed` Pods. When this eviction is due to resource pressure, only Pods exceeding
|
||||
resource requests are candidates for eviction.
|
||||
-->
|
||||
Kubernetes 对你运行的 Pod 进行分类，并将每个 Pod 分配到特定的 **QoS 类**中。
|
||||
Kubernetes 使用这种分类来影响不同 Pod 被处理的方式。Kubernetes 基于 Pod
|
||||
中{{< glossary_tooltip text="容器" term_id="container" >}}的[资源请求](/zh-cn/docs/concepts/configuration/manage-resources-containers/)进行分类，
|
||||
同时确定这些请求如何与资源限制相关。
|
||||
这称为{{< glossary_tooltip text="服务质量" term_id="qos-class" >}} (QoS) 类。
|
||||
Kubernetes 基于每个 Pod 中容器的资源请求和限制为 Pod 设置 QoS 类。Kubernetes 使用 QoS
|
||||
类来决定从遇到[节点压力](/zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction/)的
|
||||
Node 中驱逐哪些 Pod。可选的 QoS 类有 `Guaranteed`、`Burstable` 和 `BestEffort`。
|
||||
当一个 Node 耗尽资源时，Kubernetes 将首先驱逐在该 Node 上运行的 `BestEffort` Pod，
|
||||
然后是 `Burstable` Pod，最后是 `Guaranteed` Pod。当这种驱逐是由于资源压力时，
|
||||
只有超出资源请求的 Pod 才是被驱逐的候选对象。
|
||||
|
||||
### Guaranteed
|
||||
|
||||
<!--
|
||||
Pods that are `Guaranteed` have the strictest resource limits and are least likely
|
||||
to face eviction. They are guaranteed not to be killed until they exceed their limits
|
||||
or there are no lower-priority Pods that can be preempted from the Node. They may
|
||||
not acquire resources beyond their specified limits. These Pods can also make
|
||||
use of exclusive CPUs using the
|
||||
[`static`](/docs/tasks/administer-cluster/cpu-management-policies/#static-policy) CPU management policy.
|
||||
-->
|
||||
`Guaranteed` Pod 具有最严格的资源限制，并且最不可能面临驱逐。
|
||||
在这些 Pod 超过其自身的限制或者从 Node 上没有可以抢占的低优先级 Pod 之前，
|
||||
这些 Pod 保证不会被杀死。这些 Pod 不可以获得超出其指定 limit 的资源。这些 Pod 也可以使用
|
||||
[`static`](/zh-cn/docs/tasks/administer-cluster/cpu-management-policies/#static-policy)
|
||||
CPU 管理策略来使用独占的 CPU。
|
||||
|
||||
<!--
|
||||
#### Criteria
|
||||
|
||||
For a Pod to be given a QoS class of `Guaranteed`:
|
||||
-->
|
||||
#### 判据
|
||||
|
||||
Pod 被赋予 `Guaranteed` QoS 类的几个判据：
|
||||
|
||||
<!--
|
||||
* Every Container in the Pod must have a memory limit and a memory request.
|
||||
* For every Container in the Pod, the memory limit must equal the memory request.
|
||||
* Every Container in the Pod must have a CPU limit and a CPU request.
|
||||
* For every Container in the Pod, the CPU limit must equal the CPU request.
|
||||
-->
|
||||
* Pod 中的每个容器必须有内存 limit 和内存 request。
|
||||
* 对于 Pod 中的每个容器，内存 limit 必须等于内存 request。
|
||||
* Pod 中的每个容器必须有 CPU limit 和 CPU request。
|
||||
* 对于 Pod 中的每个容器，CPU limit 必须等于 CPU request。
|
||||
|
||||
### Burstable
|
||||
|
||||
<!--
|
||||
Pods that are `Burstable` have some lower-bound resource guarantees based on the request, but
|
||||
do not require a specific limit. If a limit is not specified, it defaults to a
|
||||
limit equivalent to the capacity of the Node, which allows the Pods to flexibly increase
|
||||
their resources if resources are available. In the event of Pod eviction due to Node
|
||||
resource pressure, these Pods are evicted only after all `BestEffort` Pods are evicted.
|
||||
Because a `Burstable` Pod can include a Container that has no resource limits or requests, a Pod
|
||||
that is `Burstable` can try to use any amount of node resources.
|
||||
-->
|
||||
`Burstable` Pod 有一些基于 request 的资源下限保证，但不需要特定的 limit。
|
||||
如果未指定 limit，则默认为其 limit 等于 Node 容量，这允许 Pod 在资源可用时灵活地增加其资源。
|
||||
在由于 Node 资源压力导致 Pod 被驱逐的情况下，只有在所有 `BestEffort` Pod 被驱逐后
|
||||
这些 Pod 才会被驱逐。因为 `Burstable` Pod 可以包括没有资源 limit 或资源 request 的容器，
|
||||
所以 `Burstable` Pod 可以尝试使用任意数量的节点资源。
|
||||
|
||||
<!--
|
||||
#### Criteria
|
||||
|
||||
A Pod is given a QoS class of `Burstable` if:
|
||||
|
||||
* The Pod does not meet the criteria for QoS class `Guaranteed`.
|
||||
* At least one Container in the Pod has a memory or CPU request or limit.
|
||||
-->
|
||||
#### 判据
|
||||
|
||||
Pod 被赋予 `Burstable` QoS 类的几个判据：
|
||||
|
||||
* Pod 不满足针对 QoS 类 `Guaranteed` 的判据。
|
||||
* Pod 中至少一个容器有内存或 CPU request 或 limit。
|
||||
|
||||
### BestEffort
|
||||
|
||||
<!--
|
||||
Pods in the `BestEffort` QoS class can use node resources that aren't specifically assigned
|
||||
to Pods in other QoS classes. For example, if you have a node with 16 CPU cores available to the
|
||||
kubelet, and you assign 4 CPU cores to a `Guaranteed` Pod, then a Pod in the `BestEffort`
|
||||
QoS class can try to use any amount of the remaining 12 CPU cores.
|
||||
|
||||
The kubelet prefers to evict `BestEffort` Pods if the node comes under resource pressure.
|
||||
-->
|
||||
`BestEffort` QoS 类中的 Pod 可以使用未专门分配给其他 QoS 类中的 Pod 的节点资源。
|
||||
例如若你有一个节点有 16 核 CPU 可供 kubelet 使用，并且你将 4 核 CPU 分配给一个 `Guaranteed` Pod，
|
||||
那么 `BestEffort` QoS 类中的 Pod 可以尝试任意使用剩余的 12 核 CPU。
|
||||
|
||||
如果节点遇到资源压力，kubelet 将优先驱逐 `BestEffort` Pod。
|
||||
|
||||
<!--
|
||||
#### Criteria
|
||||
|
||||
A Pod has a QoS class of `BestEffort` if it doesn't meet the criteria for either `Guaranteed`
|
||||
or `Burstable`. In other words, a Pod is `BestEffort` only if none of the Containers in the Pod have a
|
||||
memory limit or a memory request, and none of the Containers in the Pod have a
|
||||
CPU limit or a CPU request.
|
||||
Containers in a Pod can request other resources (not CPU or memory) and still be classified as
|
||||
`BestEffort`.
|
||||
-->
|
||||
#### 判据
|
||||
|
||||
如果 Pod 不满足 `Guaranteed` 或 `Burstable` 的判据，则它的 QoS 类为 `BestEffort`。
|
||||
换言之，只有当 Pod 中的所有容器没有内存 limit 或内存 request，也没有 CPU limit 或
|
||||
CPU request 时，Pod 才是 `BestEffort`。Pod 中的容器可以请求（除 CPU 或内存之外的）
|
||||
其他资源并且仍然被归类为 `BestEffort`。
|
||||
|
||||
<!--
|
||||
## Some behavior is independent of QoS class {#class-independent-behavior}
|
||||
|
||||
Certain behavior is independent of the QoS class assigned by Kubernetes. For example:
|
||||
-->
|
||||
## 某些行为独立于 QoS 类 {#class-independent-behavior}
|
||||
|
||||
某些行为独立于 Kubernetes 分配的 QoS 类。例如：
|
||||
|
||||
<!--
|
||||
* Any Container exceeding a resource limit will be killed and restarted by the kubelet without
|
||||
affecting other Containers in that Pod.
|
||||
* If a Container exceeds its resource request and the node it runs on faces
|
||||
resource pressure, the Pod it is in becomes a candidate for [eviction](/docs/concepts/scheduling-eviction/node-pressure-eviction/).
|
||||
If this occurs, all Containers in the Pod will be terminated. Kubernetes may create a
|
||||
replacement Pod, usually on a different node.
|
||||
-->
|
||||
* 所有超过资源 limit 的容器都将被 kubelet 杀死并重启，而不会影响该 Pod 中的其他容器。
|
||||
* 如果一个容器超出了自身的资源 request，且该容器运行的节点面临资源压力，则该容器所在的 Pod
|
||||
就会成为被[驱逐](/zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction/)的候选对象。
|
||||
如果出现这种情况，Pod 中的所有容器都将被终止。Kubernetes 通常会在不同的节点上创建一个替代的 Pod。
|
||||
<!--
|
||||
* The resource request of a Pod is equal to the sum of the resource requests of
|
||||
its component Containers, and the resource limit of a Pod is equal to the sum of
|
||||
the resource limits of its component Containers.
|
||||
* The kube-scheduler does not consider QoS class when selecting which Pods to
|
||||
[preempt](/docs/concepts/scheduling-eviction/pod-priority-preemption/#preemption).
|
||||
Preemption can occur when a cluster does not have enough resources to run all the Pods
|
||||
you defined.
|
||||
-->
|
||||
* Pod 的资源 request 等于其成员容器的资源 request 之和，Pod 的资源 limit 等于其组成容器的资源 limit 之和。
|
||||
* kube-scheduler 在选择要[抢占](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/#preemption)的
|
||||
Pod 时不考虑 QoS 类。当集群没有足够的资源来运行你所定义的所有 Pod 时，就会发生抢占。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
<!--
|
||||
* Learn about [resource management for Pods and Containers](/docs/concepts/configuration/manage-resources-containers/).
|
||||
* Learn about [Node-pressure eviction](/docs/concepts/scheduling-eviction/node-pressure-eviction/).
|
||||
* Learn about [Pod priority and preemption](/docs/concepts/scheduling-eviction/pod-priority-preemption/).
|
||||
* Learn about [Pod disruptions](/docs/concepts/workload/pods/disruptions/).
|
||||
* Learn how to [assign memory resources to containers and pods](/docs/tasks/configure-pod-container/assign-memory-resource/).
|
||||
* Learn how to [assign CPU resources to containers and pods](/docs/tasks/configure-pod-container/assign-cpu-resource/).
|
||||
* Learn how to [configure Quality of Service for Pods](/docs/tasks/configure-pod-container/quality-service-pod/).
|
||||
-->
|
||||
* 进一步了解[为 Pod 和容器管理资源](/zh-cn/docs/concepts/configuration/manage-resources-containers/)。
|
||||
* 进一步了解[节点压力驱逐](/zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction/)。
|
||||
* 进一步了解 [Pod 优先级和抢占](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/)。
|
||||
* 进一步了解 [Pod 干扰](/zh-cn/docs/concepts/workloads/pods/disruptions/)。
|
||||
* 进一步了解如何[为容器和 Pod 分配内存资源](/zh-cn/docs/tasks/configure-pod-container/assign-memory-resource/)。
|
||||
* 进一步了解如何[为容器和 Pod 分配 CPU 资源](/zh-cn/docs/tasks/configure-pod-container/assign-cpu-resource/)。
|
||||
* 进一步了解如何[配置 Pod 的服务质量](/zh-cn/docs/tasks/configure-pod-container/quality-service-pod/)。
|
||||
|
|
@ -123,7 +123,7 @@ end
|
|||
subgraph second[评审]
|
||||
direction TB
|
||||
T[ ] -.-
|
||||
D[仔细查看<br>K8s/website<br>仓库] --- E[下载安装 Hugo<br>静态站点<br>生成器]
|
||||
D[仔细查看<br>kubernetes/website<br>仓库] --- E[下载安装 Hugo<br>静态站点<br>生成器]
|
||||
E --- F[了解基本的<br>GitHub 命令]
|
||||
F --- G[评审待处理的 PR<br>并遵从变更审查<br>流程]
|
||||
end
|
||||
|
|
@ -190,7 +190,7 @@ flowchart LR
|
|||
direction TB
|
||||
S[ ] -.-
|
||||
G[查阅其他 K8s<br>成员发起的 PR] -->
|
||||
A[检索 K8s/website<br>问题列表是否有<br>good first 一类的 PR] --> B[发起一个 PR!!]
|
||||
A[检索 kubernetes/website<br>问题列表是否有<br>good first 一类的 PR] --> B[发起一个 PR!!]
|
||||
end
|
||||
subgraph first[建议的准备工作]
|
||||
direction TB
|
||||
|
|
|
|||
|
|
@ -155,7 +155,7 @@ repository, you can submit them in a [pull request](/docs/contribute/start/)
|
|||
to `<web-base>`.
|
||||
-->
|
||||
当所生成的文件已经被放到 `<web-base>` 目录下，你就可以将其提交到你的派生副本中，
|
||||
并基于所作提交发起[拉取请求（PR）](/docs/contribute/start/)到 k/website 仓库。
|
||||
并基于所作提交发起[拉取请求（PR）](/docs/contribute/start/)到 kubernetes/website 仓库。
|
||||
|
||||
<!--
|
||||
## Configuration file format
|
||||
|
|
|
|||
|
|
@ -66,7 +66,7 @@ opening a pull request. Figure 1 outlines the steps and the details follow.
|
|||
|
||||
{{< mermaid >}}
|
||||
flowchart LR
|
||||
A([fa:fa-user 新的<br>贡献者]) --- id1[(K8s/Website<br>GitHub)]
|
||||
A([fa:fa-user 新的<br>贡献者]) --- id1[(kubernetes/website<br>GitHub)]
|
||||
subgraph tasks[使用 GitHub 提交变更]
|
||||
direction TB
|
||||
0[ ] -.-
|
||||
|
|
@ -227,7 +227,7 @@ Figure 2 shows the steps to follow when you work from a local fork. The details
|
|||
|
||||
{{< mermaid >}}
|
||||
flowchart LR
|
||||
1[派生 K8s/website<br>仓库] --> 2[创建本地克隆副本<br>并指定 upstream 仓库]
|
||||
1[派生 kubernetes/website<br>仓库] --> 2[创建本地克隆副本<br>并指定 upstream 仓库]
|
||||
subgraph changes[你的变更]
|
||||
direction TB
|
||||
S[ ] -.-
|
||||
|
|
@ -592,9 +592,9 @@ Alternately, install and use the `hugo` command on your computer:
|
|||
### 从你的克隆副本向 kubernetes/website 发起拉取请求（PR） {#open-a-pr}
|
||||
|
||||
<!--
|
||||
Figure 3 shows the steps to open a PR from your fork to the K8s/website. The details follow.
|
||||
Figure 3 shows the steps to open a PR from your fork to the kubernetes/website. The details follow.
|
||||
-->
|
||||
图 3 显示了从你的克隆副本向 K8s/website 发起 PR 的步骤。
|
||||
图 3 显示了从你的克隆副本向 kubernetes/website 发起 PR 的步骤。
|
||||
详细信息如下。
|
||||
|
||||
<!-- See https://github.com/kubernetes/website/issues/28808 for live-editor URL to this figure -->
|
||||
|
|
@ -604,7 +604,7 @@ Figure 3 shows the steps to open a PR from your fork to the K8s/website. The det
|
|||
flowchart LR
|
||||
subgraph first[ ]
|
||||
direction TB
|
||||
1[1. 前往 K8s/website 仓库] --> 2[2. 选择 New Pull Request]
|
||||
1[1. 前往 kubernetes/website 仓库] --> 2[2. 选择 New Pull Request]
|
||||
2 --> 3[3. 选择 compare across forks]
|
||||
3 --> 4[4. 从 head repository 下拉菜单<br>选择你的克隆副本]
|
||||
end
|
||||
|
|
@ -624,9 +624,9 @@ class first,second white
|
|||
{{</ mermaid >}}
|
||||
|
||||
<!--
|
||||
Figure 3. Steps to open a PR from your fork to the K8s/website.
|
||||
Figure 3. Steps to open a PR from your fork to the kubernetes/website.
|
||||
-->
|
||||
图 3. 从你的克隆副本向 K8s/website 发起一个 PR 的步骤。
|
||||
图 3. 从你的克隆副本向 kubernetes/website 发起一个 PR 的步骤。
|
||||
|
||||
<!--
|
||||
1. In a web browser, go to the [`kubernetes/website`](https://github.com/kubernetes/website/) repository.
|
||||
|
|
|
|||
|
|
@ -420,7 +420,7 @@ and Netlify previews to verify the diagram is properly rendered.
|
|||
|
||||
{{< caution >}}
|
||||
<!--
|
||||
The Mermaid live editor feature set may not support the K8s/website Mermaid feature set.
|
||||
The Mermaid live editor feature set may not support the kubernetes/website Mermaid feature set.
|
||||
You might see a syntax error or a blank screen after the Hugo build.
|
||||
If that is the case, consider using the Mermaid+SVG method.
|
||||
-->
|
||||
|
|
@ -548,7 +548,7 @@ The following lists advantages of the Mermaid+SVG method:
|
|||
|
||||
* Live editor tool.
|
||||
* Live editor tool supports the most current Mermaid feature set.
|
||||
* Employ existing K8s/website methods for handling `.svg` image files.
|
||||
* Employ existing kubernetes/website methods for handling `.svg` image files.
|
||||
* Environment doesn't require Mermaid support.
|
||||
-->
|
||||
使用 Mermaid+SVG 方法的好处有：
|
||||
|
|
|
|||
|
|
@ -85,7 +85,7 @@ client libraries:
|
|||
* [kubectl](/zh-cn/docs/reference/kubectl/) —— 主要的 CLI 工具，用于运行命令和管理 Kubernetes 集群。
|
||||
* [JSONPath](/zh-cn/docs/reference/kubectl/jsonpath/) —— 通过 kubectl 使用
|
||||
[JSONPath 表达式](https://goessner.net/articles/JsonPath/)的语法指南。
|
||||
* [kubeadm](/zh-cn/docs/reference/setup-tools/kubeadm/) - 此 CLI 工具可轻松配置安全的 Kubernetes 集群。
|
||||
* [kubeadm](/zh-cn/docs/reference/setup-tools/kubeadm/) —— 此 CLI 工具可轻松配置安全的 Kubernetes 集群。
|
||||
|
||||
<!--
|
||||
## Components
|
||||
|
|
@ -139,6 +139,7 @@ operator to use or manage a cluster.
|
|||
* [kubeconfig (v1)](/docs/reference/config-api/kubeconfig.v1/)
|
||||
* [kube-apiserver admission (v1)](/docs/reference/config-api/apiserver-admission.v1/)
|
||||
* [kube-apiserver configuration (v1alpha1)](/docs/reference/config-api/apiserver-config.v1alpha1/) and
|
||||
[kube-apiserver configuration (v1beta1)](/docs/reference/config-api/apiserver-config.v1beta1/) and
|
||||
[kube-apiserver configuration (v1)](/docs/reference/config-api/apiserver-config.v1/)
|
||||
* [kube-apiserver encryption (v1)](/docs/reference/config-api/apiserver-encryption.v1/)
|
||||
* [kube-apiserver event rate limit (v1alpha1)](/docs/reference/config-api/apiserver-eventratelimit.v1alpha1/)
|
||||
|
|
@ -168,6 +169,7 @@ operator to use or manage a cluster.
|
|||
* [kubeconfig (v1)](/zh-cn/docs/reference/config-api/kubeconfig.v1/)
|
||||
* [kube-apiserver 准入 (v1)](/zh-cn/docs/reference/config-api/apiserver-admission.v1/)
|
||||
* [kube-apiserver 配置 (v1alpha1)](/zh-cn/docs/reference/config-api/apiserver-config.v1alpha1/) 和
|
||||
[kube-apiserver 配置 (v1beta1)](/zh-cn/docs/reference/config-api/apiserver-config.v1beta1/) 和
|
||||
[kube-apiserver 配置 (v1)](/zh-cn/docs/reference/config-api/apiserver-config.v1/)
|
||||
* [kube-apiserver 加密 (v1)](/zh-cn/docs/reference/config-api/apiserver-encryption.v1/)
|
||||
* [kube-apiserver 事件速率限制 (v1alpha1)](/zh-cn/docs/reference/config-api/apiserver-eventratelimit.v1alpha1/)
|
||||
|
|
@ -209,6 +211,6 @@ An archive of the design docs for Kubernetes functionality. Good starting points
|
|||
## 设计文档 {#design-docs}
|
||||
|
||||
Kubernetes 功能的设计文档归档，不妨考虑从
|
||||
[Kubernetes 架构](https://git.k8s.io/design-proposals-archive/architecture/architecture.md) 和
|
||||
[Kubernetes 架构](https://git.k8s.io/design-proposals-archive/architecture/architecture.md)和
|
||||
[Kubernetes 设计概述](https://git.k8s.io/design-proposals-archive)开始阅读。
|
||||
|
||||
|
|
|
|||
|
|
@ -431,19 +431,19 @@ There are two reasons for this restriction:
|
|||
|
||||
<!--
|
||||
1. Making `roleRef` immutable allows granting someone `update` permission on an existing binding
|
||||
object, so that they can manage the list of subjects, without being able to change
|
||||
the role that is granted to those subjects.
|
||||
object, so that they can manage the list of subjects, without being able to change
|
||||
the role that is granted to those subjects.
|
||||
-->
|
||||
1. 将 `roleRef` 设置为不可以改变，这使得可以为用户授予对现有绑定对象的 `update` 权限，
|
||||
这样可以让他们管理主体列表，同时不能更改被授予这些主体的角色。
|
||||
|
||||
<!--
|
||||
1. A binding to a different role is a fundamentally different binding.
|
||||
Requiring a binding to be deleted/recreated in order to change the `roleRef`
|
||||
ensures the full list of subjects in the binding is intended to be granted
|
||||
the new role (as opposed to enabling or accidentally modifying only the roleRef
|
||||
without verifying all of the existing subjects should be given the new role's
|
||||
permissions).
|
||||
Requiring a binding to be deleted/recreated in order to change the `roleRef`
|
||||
ensures the full list of subjects in the binding is intended to be granted
|
||||
the new role (as opposed to enabling or accidentally modifying only the roleRef
|
||||
without verifying all of the existing subjects should be given the new role's
|
||||
permissions).
|
||||
-->
|
||||
2. 针对不同角色的绑定是完全不一样的绑定。要求通过删除/重建绑定来更改 `roleRef`，
|
||||
这样可以确保要赋予绑定的所有主体会被授予新的角色（而不是在允许或者不小心修改了
|
||||
|
|
@ -559,17 +559,19 @@ For example, `kubectl get configmaps --field-selector=metadata.name=my-configmap
|
|||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
Rather than referring to individual `resources` and `verbs`
|
||||
you can use the wildcard `*` symbol to refer to all such objects.
|
||||
For `nonResourceURLs` you can use the wildcard `*` symbol as a suffix glob match and
|
||||
for `apiGroups` and `resourceNames` an empty set means that everything is allowed.
|
||||
Rather than referring to individual `resources`、`apiGroups`, and `verbs`,
|
||||
you can use the wildcard `*` symbol to refer to all such objects.
|
||||
For `nonResourceURLs`, you can use the wildcard `*` as a suffix glob match.
|
||||
For `resourceNames`, an empty set means that everything is allowed.
|
||||
Here is an example that allows access to perform any current and future action on
|
||||
all current and future resources (note, this is similar to the built-in `cluster-admin` role).
|
||||
all current and future resources in the `example.com` API group.
|
||||
This is similar to the built-in `cluster-admin` role.
|
||||
-->
|
||||
使用通配符 `*` 可以批量引用所有的 `resources` 和 `verbs` 对象，无需逐一引用。
|
||||
对于 `nonResourceURLs`，可以将通配符 `*` 作为后缀实现全局通配，
|
||||
对于 `apiGroups` 和 `resourceNames`，空集表示没有任何限制。
|
||||
下面的示例允许对所有当前和未来资源执行所有动作（注意，这类似于内置的 `cluster-admin`）。
|
||||
你可愈使用通配符 `*` 可以批量引用所有的 `resources`、`apiGroups` 和 `verbs` 对象， 无需逐一引用。
|
||||
对于 `nonResourceURLs`，你可以将通配符 `*` 作为后缀实现全局通配，
|
||||
对于 `resourceNames`，空集表示没有任何限制。
|
||||
下面的示例对 `example.com` API 组中所有当前和未来资源执行所有动作。
|
||||
这类似于内置的 `cluster-admin`。
|
||||
|
||||
```yaml
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
|
|
@ -585,14 +587,13 @@ rules:
|
|||
|
||||
{{< caution >}}
|
||||
<!--
|
||||
Using wildcards in resource and verb entries could result in
|
||||
overly permissive access being granted to sensitive resources.
|
||||
Using wildcards in resource and verb entries could result in overly permissive access being granted
|
||||
to sensitive resources.
|
||||
For instance, if a new resource type is added, or a new subresource is added,
|
||||
or a new custom verb is checked, the wildcard entry automatically grants access,
|
||||
which may be undesirable.
|
||||
or a new custom verb is checked, the wildcard entry automatically grants access, which may be undesirable.
|
||||
The [principle of least privilege](/docs/concepts/security/rbac-good-practices/#least-privilege)
|
||||
should be employed, using specific resources and verbs to ensure
|
||||
only the permissions required for the workload to function correctly are applied.
|
||||
should be employed, using specific resources and verbs to ensure only the permissions required for the
|
||||
workload to function correctly are applied.
|
||||
-->
|
||||
在 resources 和 verbs 条目中使用通配符会为敏感资源授予过多的访问权限。
|
||||
例如，如果添加了新的资源类型、新的子资源或新的自定义动词，
|
||||
|
|
@ -953,7 +954,7 @@ Subjects can be groups, users or
|
|||
|
||||
Kubernetes represents usernames as strings.
|
||||
These can be: plain names, such as "alice"; email-style names, like "bob@example.com";
|
||||
or numeric user IDs represented as a string. It is up to you as a cluster administrator
|
||||
or numeric user IDs represented as a string. It is up to you as a cluster administrator
|
||||
to configure the [authentication modules](/docs/reference/access-authn-authz/authentication/)
|
||||
so that authentication produces usernames in the format you want.
|
||||
-->
|
||||
|
|
@ -1168,7 +1169,10 @@ Auto-reconciliation is enabled by default if the RBAC authorizer is active.
|
|||
<!--
|
||||
### API discovery roles {#discovery-roles}
|
||||
|
||||
Default role bindings authorize unauthenticated and authenticated users to read API information that is deemed safe to be publicly accessible (including CustomResourceDefinitions). To disable anonymous unauthenticated access, add `--anonymous-auth=false` to the API server configuration.
|
||||
Default role bindings authorize unauthenticated and authenticated users to read API information
|
||||
that is deemed safe to be publicly accessible (including CustomResourceDefinitions).
|
||||
To disable anonymous unauthenticated access, add `--anonymous-auth=false` to
|
||||
the API server configuration.
|
||||
|
||||
To view the configuration of these roles via `kubectl` run:
|
||||
-->
|
||||
|
|
@ -1717,8 +1721,9 @@ RBAC API 会阻止用户通过编辑角色或者角色绑定来提升权限。
|
|||
You can only create/update a role if at least one of the following things is true:
|
||||
|
||||
1. You already have all the permissions contained in the role, at the same scope as the object being modified
|
||||
(cluster-wide for a ClusterRole, within the same namespace or cluster-wide for a Role).
|
||||
2. You are granted explicit permission to perform the `escalate` verb on the `roles` or `clusterroles` resource in the `rbac.authorization.k8s.io` API group.
|
||||
(cluster-wide for a ClusterRole, within the same namespace or cluster-wide for a Role).
|
||||
2. You are granted explicit permission to perform the `escalate` verb on the `roles` or
|
||||
`clusterroles` resource in the `rbac.authorization.k8s.io` API group.
|
||||
-->
|
||||
### 对角色创建或更新的限制 {#restrictions-on-role-creation-or-update}
|
||||
|
||||
|
|
@ -1735,8 +1740,11 @@ containing that permission. To allow a user to create/update roles:
|
|||
|
||||
1. Grant them a role that allows them to create/update Role or ClusterRole objects, as desired.
|
||||
2. Grant them permission to include specific permissions in the roles they create/update:
|
||||
* implicitly, by giving them those permissions (if they attempt to create or modify a Role or ClusterRole with permissions they themselves have not been granted, the API request will be forbidden)
|
||||
* or explicitly allow specifying any permission in a `Role` or `ClusterRole` by giving them permission to perform the `escalate` verb on `roles` or `clusterroles` resources in the `rbac.authorization.k8s.io` API group
|
||||
* implicitly, by giving them those permissions (if they attempt to create or modify a Role or
|
||||
ClusterRole with permissions they themselves have not been granted, the API request will be forbidden)
|
||||
* or explicitly allow specifying any permission in a `Role` or `ClusterRole` by giving them
|
||||
permission to perform the `escalate` verb on `roles` or `clusterroles` resources in the
|
||||
`rbac.authorization.k8s.io` API group
|
||||
-->
|
||||
例如，如果 `user-1` 没有列举集群范围所有 Secret 的权限，他将不能创建包含该权限的 ClusterRole。
|
||||
若要允许用户创建/更新角色：
|
||||
|
|
|
|||
|
|
@ -0,0 +1,270 @@
|
|||
---
|
||||
title: Kubelet CredentialProvider (v1)
|
||||
content_type: tool-reference
|
||||
package: credentialprovider.kubelet.k8s.io/v1
|
||||
---
|
||||
<!--
|
||||
title: Kubelet CredentialProvider (v1)
|
||||
content_type: tool-reference
|
||||
package: credentialprovider.kubelet.k8s.io/v1
|
||||
auto_generated: true
|
||||
-->
|
||||
|
||||
<!--
|
||||
## Resource Types
|
||||
-->
|
||||
## 资源类型 {#resource-types}
|
||||
|
||||
- [CredentialProviderRequest](#credentialprovider-kubelet-k8s-io-v1-CredentialProviderRequest)
|
||||
- [CredentialProviderResponse](#credentialprovider-kubelet-k8s-io-v1-CredentialProviderResponse)
|
||||
|
||||
## `CredentialProviderRequest` {#credentialprovider-kubelet-k8s-io-v1-CredentialProviderRequest}
|
||||
|
||||
<!--
|
||||
CredentialProviderRequest includes the image that the kubelet requires authentication for.
|
||||
Kubelet will pass this request object to the plugin via stdin. In general, plugins should
|
||||
prefer responding with the same apiVersion they were sent.
|
||||
-->
|
||||
<p>
|
||||
CredentialProviderRequest 包含 kubelet 需要通过身份验证才能访问的镜像。
|
||||
kubelet 将此请求对象通过 stdin 传递到插件。
|
||||
通常，插件应优先使用所收到的 apiVersion 作出响应。
|
||||
</p>
|
||||
|
||||
<table class="table">
|
||||
<thead><tr><th width="30%"><!--Field-->字段</th><th><!--Description-->描述</th></tr></thead>
|
||||
<tbody>
|
||||
|
||||
<tr><td><code>apiVersion</code><br/>string</td><td><code>credentialprovider.kubelet.k8s.io/v1</code></td></tr>
|
||||
<tr><td><code>kind</code><br/>string</td><td><code>CredentialProviderRequest</code></td></tr>
|
||||
|
||||
|
||||
<tr><td><code>image</code> <B><!--[Required]-->[必需]</B><br/>
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
<!--
|
||||
image is the container image that is being pulled as part of the
|
||||
credential provider plugin request. Plugins may optionally parse the image
|
||||
to extract any information required to fetch credentials.
|
||||
-->
|
||||
<p>
|
||||
image 是作为凭据提供程序插件请求的一部分所拉取的容器镜像。
|
||||
这些插件可以选择解析镜像以提取获取凭据所需的任何信息。
|
||||
</p>
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
## `CredentialProviderResponse` {#credentialprovider-kubelet-k8s-io-v1-CredentialProviderResponse}
|
||||
|
||||
<!--
|
||||
CredentialProviderResponse holds credentials that the kubelet should use for the specified
|
||||
image provided in the original request. Kubelet will read the response from the plugin via stdout.
|
||||
This response should be set to the same apiVersion as CredentialProviderRequest.
|
||||
-->
|
||||
<p>
|
||||
CredentialProviderResponse 中包含 kubelet 应针对原始请求中所给镜像来使用的凭据。
|
||||
kubelet 将通过 stdout 读取来自插件的响应。
|
||||
此响应应被设置为与 CredentialProviderRequest 相同的 apiVersion。
|
||||
</p>
|
||||
|
||||
<table class="table">
|
||||
<thead><tr><th width="30%"><!--Field-->字段</th><th><!--Description-->描述</th></tr></thead>
|
||||
<tbody>
|
||||
|
||||
<tr><td><code>apiVersion</code><br/>string</td><td><code>credentialprovider.kubelet.k8s.io/v1</code></td></tr>
|
||||
<tr><td><code>kind</code><br/>string</td><td><code>CredentialProviderResponse</code></td></tr>
|
||||
|
||||
|
||||
<tr><td><code>cacheKeyType</code> <B><!--[Required]-->[必需]</B><br/>
|
||||
<a href="#credentialprovider-kubelet-k8s-io-v1-PluginCacheKeyType"><code>PluginCacheKeyType</code></a>
|
||||
</td>
|
||||
<td>
|
||||
<!--
|
||||
cacheKeyType indiciates the type of caching key to use based on the image provided
|
||||
in the request. There are three valid values for the cache key type: Image, Registry, and
|
||||
Global. If an invalid value is specified, the response will NOT be used by the kubelet.
|
||||
-->
|
||||
<p>
|
||||
cacheKeyType 标示了基于请求中提供的镜像要使用的缓存键的类型。
|
||||
缓存键类型有三个有效值：Image、Registry 和 Global。
|
||||
如果所指定的值无效，则此响应不会被 kubelet 使用。
|
||||
</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>cacheDuration</code><br/>
|
||||
<a href="https://pkg.go.dev/k8s.io/apimachinery/pkg/apis/meta/v1#Duration"><code>meta/v1.Duration</code></a>
|
||||
</td>
|
||||
<td>
|
||||
<!--
|
||||
cacheDuration indicates the duration the provided credentials should be cached for.
|
||||
The kubelet will use this field to set the in-memory cache duration for credentials
|
||||
in the AuthConfig. If null, the kubelet will use defaultCacheDuration provided in
|
||||
CredentialProviderConfig. If set to 0, the kubelet will not cache the provided AuthConfig.
|
||||
-->
|
||||
<p>
|
||||
cacheDuration 标示所提供的凭据可被缓存的持续期。
|
||||
kubelet 将使用此字段为 AuthConfig 中的凭据设置内存中缓存持续期。
|
||||
如果为空，kubelet 将使用 CredentialProviderConfig 中提供的 defaultCacheDuration。
|
||||
如果设置为 0，kubelet 将不再缓存提供的 AuthConfig。
|
||||
</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>auth</code><br/>
|
||||
<a href="#credentialprovider-kubelet-k8s-io-v1-AuthConfig"><code>map[string]k8s.io/kubelet/pkg/apis/credentialprovider/v1.AuthConfig</code></a>
|
||||
</td>
|
||||
<td>
|
||||
<!--
|
||||
auth is a map containing authentication information passed into the kubelet.
|
||||
Each key is a match image string (more on this below). The corresponding authConfig value
|
||||
should be valid for all images that match against this key. A plugin should set
|
||||
this field to null if no valid credentials can be returned for the requested image.
|
||||
-->
|
||||
<p>
|
||||
auth 是一个映射，包含传递给 kubelet 的身份验证信息。
|
||||
映射中每个键都是一个匹配镜像字符串（更多内容见下文）。
|
||||
相应的 authConfig 值应该对匹配此键的所有镜像有效。
|
||||
如果无法为请求的镜像返回有效凭据，则插件应将此字段设置为空。
|
||||
</p>
|
||||
<!--
|
||||
Each key in the map is a pattern which can optionally contain a port and a path.
|
||||
Globs can be used in the domain, but not in the port or the path. Globs are supported
|
||||
as subdomains like '<em>.k8s.io' or 'k8s.</em>.io', and top-level-domains such as 'k8s.<em>'.
|
||||
Matching partial subdomains like 'app</em>.k8s.io' is also supported. Each glob can only match
|
||||
a single subdomain segment, so *.io does not match *.k8s.io.
|
||||
-->
|
||||
<p>
|
||||
映射中的每个主键都可以包含端口和路径。
|
||||
域名中可以使用 Glob 通配，但不能在端口或路径中使用 Glob。
|
||||
Glob 支持类似 “\*.k8s.io” 或 “k8s.\*.io” 这类子域以及 “k8s.\*” 这类顶级域。
|
||||
也支持匹配的部分子域，例如 “app\*.k8s.io”。
|
||||
每个 Glob 只能匹配一个子域段，因此 *.io 与 *.k8s.io 不匹配。
|
||||
</p>
|
||||
<!--
|
||||
The kubelet will match images against the key when all of the below are true:
|
||||
-->
|
||||
<p>
|
||||
当满足以下所有条件时，kubelet 将根据主键来匹配镜像：
|
||||
</p>
|
||||
<ul>
|
||||
<!--
|
||||
Both contain the same number of domain parts and each part matches.
|
||||
-->
|
||||
<li>两者都包含相同数量的域名部分，并且每个部分都匹配。</li>
|
||||
<!--
|
||||
The URL path of an imageMatch must be a prefix of the target image URL path.
|
||||
-->
|
||||
<li>imageMatch 的 URL 路径必须是目标镜像 URL 路径的前缀。</li>
|
||||
<!--
|
||||
If the imageMatch contains a port, then the port must match in the image as well.
|
||||
-->
|
||||
<li>如果 imageMatch 包含端口，则此端口也必须在镜像中匹配。</li>
|
||||
</ul>
|
||||
<!--
|
||||
When multiple keys are returned, the kubelet will traverse all keys in reverse order so that:
|
||||
-->
|
||||
<p>
|
||||
当返回多个主键时，kubelet 将以相反的顺序遍历所有主键，以便：
|
||||
</p>
|
||||
<ul>
|
||||
<!--
|
||||
longer keys come before shorter keys with the same prefix
|
||||
-->
|
||||
<li>较长键出现在具有相同前缀的较短键前面。</li>
|
||||
<!--
|
||||
non-wildcard keys come before wildcard keys with the same prefix.
|
||||
-->
|
||||
<li>非通配符键出现在具有相同前缀的通配符键之前。</li>
|
||||
</ul>
|
||||
<!--
|
||||
For any given match, the kubelet will attempt an image pull with the provided credentials,
|
||||
stopping after the first successfully authenticated pull.
|
||||
-->
|
||||
<p>对于任一给定的匹配项，kubelet 将尝试用提供的凭据拉取镜像，并在第一次成功通过身份验证的拉取之后停止。</p>
|
||||
<!--
|
||||
Example keys:
|
||||
-->
|
||||
<p>示例键：</p>
|
||||
<ul>
|
||||
<li>123456789.dkr.ecr.us-east-1.amazonaws.com</li>
|
||||
<li>*.azurecr.io</li>
|
||||
<li>gcr.io</li>
|
||||
<li>*.registry.io</li>
|
||||
<li>registry.io:8080/path</li>
|
||||
</ul>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
## `AuthConfig` {#credentialprovider-kubelet-k8s-io-v1-AuthConfig}
|
||||
|
||||
<!--
|
||||
**Appears in:**
|
||||
-->
|
||||
**出现在：**
|
||||
|
||||
- [CredentialProviderResponse](#credentialprovider-kubelet-k8s-io-v1-CredentialProviderResponse)
|
||||
|
||||
<!--
|
||||
AuthConfig contains authentication information for a container registry.
|
||||
Only username/password based authentication is supported today, but more authentication
|
||||
mechanisms may be added in the future.
|
||||
-->
|
||||
<p>
|
||||
AuthConfig 包含针对容器镜像仓库的身份验证信息。
|
||||
目前仅支持基于用户名/密码的身份验证，但未来可能添加更多的身份验证机制。
|
||||
</p>
|
||||
|
||||
<table class="table">
|
||||
<thead><tr><th width="30%"><!--Field-->字段</th><th><!--Description-->描述</th></tr></thead>
|
||||
<tbody>
|
||||
|
||||
<tr><td><code>username</code> <B><!--[Required]-->[必需]</B><br/>
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
<!--
|
||||
username is the username used for authenticating to the container registry
|
||||
An empty username is valid.
|
||||
-->
|
||||
<p>
|
||||
username 是对容器镜像仓库身份验证所用的用户名。
|
||||
空白用户名是有效的。
|
||||
</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr><td><code>password</code> <B><!--[Required]-->[必需]</B><br/>
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
<!--
|
||||
password is the password used for authenticating to the container registry
|
||||
An empty password is valid.
|
||||
-->
|
||||
<p>
|
||||
password 是对容器镜像仓库身份验证所用的密码。
|
||||
空白密码是有效的。
|
||||
</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
## `PluginCacheKeyType` {#credentialprovider-kubelet-k8s-io-v1-PluginCacheKeyType}
|
||||
|
||||
<!--
|
||||
(Alias of `string`)
|
||||
-->
|
||||
（`string` 的别名）
|
||||
|
||||
<!--
|
||||
**Appears in:**
|
||||
-->
|
||||
**出现在：**
|
||||
|
||||
- [CredentialProviderResponse](#credentialprovider-kubelet-k8s-io-v1-CredentialProviderResponse)
|
||||
|
||||
|
|
@ -14,13 +14,12 @@ tags:
|
|||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
title: StatefulSet
|
||||
id: statefulset
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/workloads/controllers/statefulset/
|
||||
short_description: >
|
||||
Manages deployment and scaling of a set of Pods, with durable storage and persistent identifiers for each Pod.
|
||||
A StatefulSet manages deployment and scaling of a set of Pods, with durable storage and persistent identifiers for each Pod.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
|
|
@ -28,7 +27,6 @@ tags:
|
|||
- core-object
|
||||
- workload
|
||||
- storage
|
||||
---
|
||||
-->
|
||||
|
||||
<!--
|
||||
|
|
@ -39,7 +37,7 @@ StatefulSet 用来管理某 {{< glossary_tooltip text="Pod" term_id="pod" >}}
|
|||
<!--more-->
|
||||
|
||||
<!--
|
||||
Like a {{< glossary_tooltip term_id="deployment" >}}, a StatefulSet manages Pods that are based on an identical container spec. Unlike a Deployment, a StatefulSet maintains a sticky identity for each of their Pods. These pods are created from the same spec, but are not interchangeable: each has a persistent identifier that it maintains across any rescheduling.
|
||||
Like a {{< glossary_tooltip term_id="deployment" >}}, a StatefulSet manages Pods that are based on an identical container spec. Unlike a Deployment, a StatefulSet maintains a sticky identity for each of its Pods. These pods are created from the same spec, but are not interchangeable: each has a persistent identifier that it maintains across any rescheduling.
|
||||
-->
|
||||
|
||||
和 {{< glossary_tooltip text="Deployment" term_id="deployment" >}} 类似，
|
||||
|
|
|
|||
|
|
@ -0,0 +1,67 @@
|
|||
---
|
||||
title: CRI Pod 和容器指标
|
||||
content_type: reference
|
||||
weight: 50
|
||||
description: >-
|
||||
通过 CRI 收集 Pod 和容器指标
|
||||
---
|
||||
<!--
|
||||
title: CRI Pod & Container Metrics
|
||||
content_type: reference
|
||||
weight: 50
|
||||
description: >-
|
||||
Collection of Pod & Container metrics via the CRI.
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
{{< feature-state for_k8s_version="v1.23" state="alpha" >}}
|
||||
<!--
|
||||
The [kubelet](/docs/reference/command-line-tools-reference/kubelet/) collects pod and
|
||||
container metrics via [cAdvisor](https://github.com/google/cadvisor). As an alpha feature,
|
||||
Kubernetes lets you configure the collection of pod and container
|
||||
metrics via the {{< glossary_tooltip term_id="cri" text="Container Runtime Interface">}} (CRI). You
|
||||
must enable the `PodAndContainerStatsFromCRI` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) and
|
||||
use a compatible CRI implementation (containerd >= 1.6.0, CRI-O >= 1.23.0) to
|
||||
use the CRI based collection mechanism.
|
||||
-->
|
||||
[kubelet](/zh-cn/docs/reference/command-line-tools-reference/kubelet/) 通过
|
||||
[cAdvisor](https://github.com/google/cadvisor) 收集 Pod 和容器指标。作为一个 Alpha 特性，
|
||||
Kubernetes 允许你通过{{< glossary_tooltip term_id="cri" text="容器运行时接口">}}（CRI）
|
||||
配置收集 Pod 和容器指标。要使用基于 CRI 的收集机制，你必须启用 `PodAndContainerStatsFromCRI`
|
||||
[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
并使用兼容的 CRI 实现（containerd >= 1.6.0, CRI-O >= 1.23.0）。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
## CRI Pod & Container Metrics
|
||||
|
||||
With `PodAndContainerStatsFromCRI` enabled, the kubelet polls the underlying container
|
||||
runtime for pod and container stats instead of inspecting the host system directly using cAdvisor.
|
||||
The benefits of relying on the container runtime for this information as opposed to direct
|
||||
collection with cAdvisor include:
|
||||
-->
|
||||
## CRI Pod 和容器指标 {#cri-pod-container-metrics}
|
||||
|
||||
当启用 `PodAndContainerStatsFromCRI` 时，Kubelet 轮询底层容器运行时以获取
|
||||
Pod 和容器统计信息，而不是直接使用 cAdvisor 检查主机系统。同直接使用 cAdvisor
|
||||
收集信息相比，依靠容器运行时获取这些信息的好处包括：
|
||||
|
||||
<!--
|
||||
- Potential improved performance if the container runtime already collects this information
|
||||
during normal operations. In this case, the data can be re-used instead of being aggregated
|
||||
again by the kubelet.
|
||||
-->
|
||||
- 潜在的性能改善，如果容器运行时在正常操作中已经收集了这些信息。
|
||||
在这种情况下，这些数据可以被重用，而不是由 Kubelet 再次进行聚合。
|
||||
|
||||
<!--
|
||||
- It further decouples the kubelet and the container runtime allowing collection of metrics for
|
||||
container runtimes that don't run processes directly on the host with kubelet where they are
|
||||
observable by cAdvisor (for example: container runtimes that use virtualization).
|
||||
-->
|
||||
- 这种做法进一步解耦了 Kubelet 和容器运行时。
|
||||
对于使用 Kubelet 来在主机上运行进程的容器运行时，其行为可用 cAdvisor 观测；
|
||||
对于其他运行时（例如，使用虚拟化的容器运行时）而言，
|
||||
这种做法提供了允许收集容器运行时指标的可能性。
|
||||
|
|
@ -46,16 +46,20 @@ For a stable output in a script:
|
|||
## 子资源 {#subresources}
|
||||
|
||||
<!--
|
||||
* You can use the `--subresource` alpha flag for kubectl commands like `get`, `patch`,
|
||||
* You can use the `--subresource` beta flag for kubectl commands like `get`, `patch`,
|
||||
`edit` and `replace` to fetch and update subresources for all resources that
|
||||
support them. Currently, only the `status` and `scale` subresources are supported.
|
||||
* For `kubectl edit`, the `scale` subresource is not supported. If you use `--subresource` with
|
||||
`kubectl edit` and specify `scale` as the subresource, the command will error out.
|
||||
* The API contract against a subresource is identical to a full resource. While updating the
|
||||
`status` subresource to a new value, keep in mind that the subresource could be potentially
|
||||
reconciled by a controller to a different value.
|
||||
-->
|
||||
|
||||
* 你可以将 `--subresource` alpha 标志用于 kubectl 命令，例如 `get`、`patch`、`edit` 和 `replace`
|
||||
* 你可以将 `--subresource` Beta 标志用于 kubectl 命令，例如 `get`、`patch`、`edit` 和 `replace`
|
||||
来获取和更新所有支持子资源的资源的子资源。目前，仅支持 `status` 和 `scale` 子资源。
|
||||
* 对于 `kubectl edit`，不支持 `scale` 子资源。如果将 `--subresource` 与 `kubectl edit` 一起使用，
|
||||
并指定 `scale` 作为子资源，则命令将会报错。
|
||||
* 针对子资源的 API 协定与完整资源相同。在更新 `status` 子资源为一个新值时，请记住，
|
||||
子资源可能是潜在的由控制器调和为不同的值。
|
||||
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ In this exercise, you create a Pod that runs two Containers. The two containers
|
|||
share a Volume that they can use to communicate. Here is the configuration file
|
||||
for the Pod:
|
||||
-->
|
||||
## 创建一个包含两个容器的 Pod
|
||||
## 创建一个包含两个容器的 Pod {#creating-a-pod-that-runs-two-containers}
|
||||
|
||||
在这个练习中，你会创建一个包含两个容器的 Pod。两个容器共享一个卷用于他们之间的通信。
|
||||
Pod 的配置文件如下：
|
||||
|
|
@ -184,7 +184,7 @@ Typically this is done through a shared filesystem, as shown in this exercise,
|
|||
or through the loopback network interface, localhost. An example of this pattern is a
|
||||
web server along with a helper program that polls a Git repository for new updates.
|
||||
-->
|
||||
## 讨论
|
||||
## 讨论 {#discussion}
|
||||
|
||||
Pod 能有多个容器的主要原因是为了支持辅助应用（helper applications），以协助主应用（primary application）。
|
||||
辅助应用的典型例子是数据抽取，数据推送和代理。辅助应用和主应用经常需要相互通信。
|
||||
|
|
|
|||
|
|
@ -61,7 +61,7 @@ require a supported environment. If your environment does not support this, you
|
|||
The backend is a simple hello greeter microservice. Here is the configuration
|
||||
file for the backend Deployment:
|
||||
-->
|
||||
### 使用部署对象（Deployment）创建后端
|
||||
### 使用部署对象（Deployment）创建后端 {#creating-the-backend-using-a-deployment}
|
||||
|
||||
后端是一个简单的 hello 欢迎微服务应用。这是后端应用的 Deployment 配置文件：
|
||||
|
||||
|
|
@ -136,7 +136,7 @@ the Pods that it routes traffic to.
|
|||
|
||||
First, explore the Service configuration file:
|
||||
-->
|
||||
### 创建 `hello` Service 对象
|
||||
### 创建 `hello` Service 对象 {#creating-the-hello-service-object}
|
||||
|
||||
将请求从前端发送到后端的关键是后端 Service。Service 创建一个固定 IP 和 DNS 解析名入口，
|
||||
使得后端微服务总是可达。Service 使用
|
||||
|
|
@ -185,7 +185,7 @@ configuration file.
|
|||
The Pods in the frontend Deployment run a nginx image that is configured
|
||||
to proxy requests to the `hello` backend Service. Here is the nginx configuration file:
|
||||
-->
|
||||
### 创建前端应用
|
||||
### 创建前端 {#creating-the-frontend}
|
||||
|
||||
现在你已经有了运行中的后端应用，你可以创建一个可在集群外部访问的前端，并通过代理
|
||||
前端的请求连接到后端。
|
||||
|
|
@ -299,7 +299,7 @@ cluster.
|
|||
The frontend and backend are now connected. You can hit the endpoint
|
||||
by using the curl command on the external IP of your frontend Service.
|
||||
-->
|
||||
### 通过前端发送流量
|
||||
### 通过前端发送流量 {#send-traffic-through-the-frontend}
|
||||
|
||||
前端和后端已经完成连接了。你可以使用 curl 命令通过你的前端 Service 的外部
|
||||
IP 访问服务端点。
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ of Containers for each.
|
|||
- Use `sort` to sort the results
|
||||
- Use `uniq` to aggregate image counts
|
||||
-->
|
||||
## 列出所有命名空间下的所有容器镜像
|
||||
## 列出所有命名空间下的所有容器镜像 {#list-all-container-images-in-all-namespaces}
|
||||
|
||||
- 使用 `kubectl get pods --all-namespaces` 获取所有命名空间下的所有 Pod
|
||||
- 使用 `-o jsonpath={.items[*].spec.containers[*].image}` 来格式化输出，以仅包含容器镜像名称。
|
||||
|
|
@ -95,7 +95,7 @@ Pod is returned instead of a list of items.
|
|||
The formatting can be controlled further by using the `range` operation to
|
||||
iterate over elements individually.
|
||||
-->
|
||||
## 按 Pod 列出容器镜像
|
||||
## 按 Pod 列出容器镜像 {#list-container-images-by-pod}
|
||||
|
||||
可以使用 `range` 操作进一步控制格式化，以单独操作每个元素。
|
||||
|
||||
|
|
@ -110,7 +110,7 @@ sort
|
|||
To target only Pods matching a specific label, use the -l flag. The
|
||||
following matches only Pods with labels matching `app=nginx`.
|
||||
-->
|
||||
## 列出以标签过滤后的 Pod 的所有容器镜像
|
||||
## 列出以标签过滤后的 Pod 的所有容器镜像 {#list-container-images-filtering-by-pod-label}
|
||||
|
||||
要获取匹配特定标签的 Pod，请使用 -l 参数。以下匹配仅与标签 `app=nginx` 相符的 Pod。
|
||||
|
||||
|
|
@ -124,7 +124,7 @@ kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].ima
|
|||
To target only pods in a specific namespace, use the namespace flag. The
|
||||
following matches only Pods in the `kube-system` namespace.
|
||||
-->
|
||||
## 列出以命名空间过滤后的 Pod 的所有容器镜像
|
||||
## 列出以命名空间过滤后的 Pod 的所有容器镜像 {#list-container-images-filtering-by-pod-namespace}
|
||||
|
||||
要获取匹配特定命名空间的 Pod，请使用 namespace 参数。以下仅匹配 `kube-system` 命名空间下的 Pod。
|
||||
|
||||
|
|
@ -135,12 +135,12 @@ kubectl get pods --namespace kube-system -o jsonpath="{.items[*].spec.containers
|
|||
<!--
|
||||
## List Container images using a go-template instead of jsonpath
|
||||
|
||||
As an alternative to jsonpath, Kubectl supports using [go-templates](https://golang.org/pkg/text/template/)
|
||||
As an alternative to jsonpath, Kubectl supports using [go-templates](https://pkg.go.dev/text/template)
|
||||
for formatting the output:
|
||||
-->
|
||||
## 使用 go-template 代替 jsonpath 来获取容器镜像
|
||||
## 使用 go-template 代替 jsonpath 来获取容器镜像 {#list-container-images-using-a-go-template-instead-of-jsonpath}
|
||||
|
||||
作为 jsonpath 的替代，Kubectl 支持使用 [go-templates](https://golang.org/pkg/text/template/) 来格式化输出：
|
||||
作为 jsonpath 的替代，Kubectl 支持使用 [go-templates](https://pkg.go.dev/text/template) 来格式化输出：
|
||||
|
||||
```shell
|
||||
kubectl get pods --all-namespaces -o go-template --template="{{range .items}}{{range .spec.containers}}{{.image}} {{end}}{{end}}"
|
||||
|
|
@ -152,10 +152,10 @@ kubectl get pods --all-namespaces -o go-template --template="{{range .items}}{{r
|
|||
### Reference
|
||||
|
||||
* [Jsonpath](/docs/reference/kubectl/jsonpath/) reference guide
|
||||
* [Go template](https://golang.org/pkg/text/template/) reference guide
|
||||
* [Go template](https://pkg.go.dev/text/template) reference guide
|
||||
-->
|
||||
### 参考
|
||||
### 参考 {#reference}
|
||||
|
||||
* [Jsonpath](/zh-cn/docs/reference/kubectl/jsonpath/) 参考指南
|
||||
* [Go template](https://golang.org/pkg/text/template/) 参考指南
|
||||
* [Go template](https://pkg.go.dev/text/template) 参考指南
|
||||
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ for database debugging.
|
|||
|
||||
1. Create a Deployment that runs MongoDB:
|
||||
-->
|
||||
## 创建 MongoDB Deployment 和服务
|
||||
## 创建 MongoDB Deployment 和服务 {#creating-mongodb-deployment-and-service}
|
||||
|
||||
1. 创建一个运行 MongoDB 的 Deployment：
|
||||
|
||||
|
|
@ -183,7 +183,7 @@ for database debugging.
|
|||
|
||||
1. `kubectl port-forward` allows using resource name, such as a pod name, to select a matching pod to port forward to.
|
||||
-->
|
||||
## 转发一个本地端口到 Pod 端口
|
||||
## 转发一个本地端口到 Pod 端口 {#forward-a-local-port-to-a-port-on-the-pod}
|
||||
|
||||
1. `kubectl port-forward` 允许使用资源名称
|
||||
（例如 Pod 名称）来选择匹配的 Pod 来进行端口转发。
|
||||
|
|
@ -237,7 +237,7 @@ for database debugging.
|
|||
```
|
||||
Forwarding from 127.0.0.1:28015 -> 27017
|
||||
Forwarding from [::1]:28015 -> 27017
|
||||
```
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
|
|
@ -257,7 +257,7 @@ for database debugging.
|
|||
```
|
||||
|
||||
<!--
|
||||
3. At the MongoDB command line prompt, enter the `ping` command:
|
||||
3. At the MongoDB command line prompt, enter the `ping` command:
|
||||
-->
|
||||
3. 在 MongoDB 命令行提示符下，输入 `ping` 命令：
|
||||
|
||||
|
|
|
|||
|
|
@ -56,7 +56,7 @@ Dashboard 同时展示了 Kubernetes 集群中的资源状态信息和所有报
|
|||
|
||||
The Dashboard UI is not deployed by default. To deploy it, run the following command:
|
||||
-->
|
||||
## 部署 Dashboard UI
|
||||
## 部署 Dashboard UI {#deploying-the-dashboard-ui}
|
||||
默认情况下不会部署 Dashboard。可以通过以下命令部署：
|
||||
|
||||
```
|
||||
|
|
@ -71,7 +71,7 @@ Currently, Dashboard only supports logging in with a Bearer Token.
|
|||
To create a token for this demo, you can follow our guide on
|
||||
[creating a sample user](https://github.com/kubernetes/dashboard/blob/master/docs/user/access-control/creating-sample-user.md).
|
||||
-->
|
||||
## 访问 Dashboard 用户界面
|
||||
## 访问 Dashboard 用户界面 {#accessing-the-dashboard-ui}
|
||||
|
||||
为了保护你的集群数据，默认情况下，Dashboard 会使用最少的 RBAC 配置进行部署。
|
||||
当前，Dashboard 仅支持使用 Bearer 令牌登录。
|
||||
|
|
@ -92,7 +92,7 @@ The sample user created in the tutorial will have administrative privileges and
|
|||
You can enable access to the Dashboard using the `kubectl` command-line tool,
|
||||
by running the following command:
|
||||
-->
|
||||
### 命令行代理
|
||||
### 命令行代理 {#command-line-proxy}
|
||||
|
||||
你可以使用 `kubectl` 命令行工具来启用 Dashboard 访问，命令如下：
|
||||
|
||||
|
|
@ -121,7 +121,7 @@ Kubeconfig 身份验证方法**不**支持外部身份提供程序或基于 x509
|
|||
<!--
|
||||
## Welcome view
|
||||
-->
|
||||
## 欢迎界面
|
||||
## 欢迎界面 {#welcome-view}
|
||||
|
||||
<!--
|
||||
When you access Dashboard on an empty cluster, you'll see the welcome page.
|
||||
|
|
@ -145,7 +145,7 @@ In addition, you can view which system applications are running by default in th
|
|||
Dashboard lets you create and deploy a containerized application as a Deployment and optional Service with a simple wizard.
|
||||
You can either manually specify application details, or upload a YAML or JSON _manifest_ file containing application configuration.
|
||||
-->
|
||||
## 部署容器化应用
|
||||
## 部署容器化应用 {#deploying-containerized-applications}
|
||||
|
||||
通过一个简单的部署向导，你可以使用 Dashboard 将容器化应用作为一个 Deployment 和可选的
|
||||
Service 进行创建和部署。你可以手工指定应用的详细配置，或者上传一个包含应用配置的 YAML
|
||||
|
|
@ -161,7 +161,7 @@ Click the **CREATE** button in the upper right corner of any page to begin.
|
|||
|
||||
The deploy wizard expects that you provide the following information:
|
||||
-->
|
||||
### 指定应用的详细配置
|
||||
### 指定应用的详细配置 {#specifying-application-details}
|
||||
|
||||
部署向导需要你提供以下信息：
|
||||
|
||||
|
|
@ -380,7 +380,7 @@ Kubernetes supports declarative configuration.
|
|||
In this style, all configuration is stored in manifests (YAML or JSON configuration files).
|
||||
The manifests use Kubernetes [API](/docs/concepts/overview/kubernetes-api/) resource schemas.
|
||||
-->
|
||||
### 上传 YAML 或者 JSON 文件
|
||||
### 上传 YAML 或者 JSON 文件 {#uploading-a-yaml-or-json-file}
|
||||
|
||||
Kubernetes 支持声明式配置。所有的配置都存储在清单文件
|
||||
（YAML 或者 JSON 配置文件）中。这些
|
||||
|
|
@ -398,7 +398,7 @@ Dashboard 上传文件。
|
|||
|
||||
Following sections describe views of the Kubernetes Dashboard UI; what they provide and how can they be used.
|
||||
-->
|
||||
## 使用 Dashboard
|
||||
## 使用 Dashboard {#using-dashboard}
|
||||
|
||||
以下各节描述了 Kubernetes Dashboard UI 视图；包括它们提供的内容，以及怎么使用它们。
|
||||
|
||||
|
|
@ -409,7 +409,7 @@ When there are Kubernetes objects defined in the cluster, Dashboard shows them i
|
|||
By default only objects from the _default_ namespace are shown and
|
||||
this can be changed using the namespace selector located in the navigation menu.
|
||||
-->
|
||||
### 导航
|
||||
### 导航 {#navigation}
|
||||
|
||||
当在集群中定义 Kubernetes 对象时，Dashboard 会在初始视图中显示它们。
|
||||
默认情况下只会显示 _默认_ 名字空间中的对象，可以通过更改导航栏菜单中的名字空间筛选器进行改变。
|
||||
|
|
@ -427,7 +427,7 @@ Node list view contains CPU and memory usage metrics aggregated across all Nodes
|
|||
The details view shows the metrics for a Node, its specification, status,
|
||||
allocated resources, events and pods running on the node.
|
||||
-->
|
||||
#### 管理概述
|
||||
#### 管理概述 {#admin-overview}
|
||||
|
||||
集群和名字空间管理的视图，Dashboard 会列出节点、名字空间和持久卷，并且有它们的详细视图。
|
||||
节点列表视图包含从所有节点聚合的 CPU 和内存使用的度量值。
|
||||
|
|
@ -442,7 +442,7 @@ Each workload kind can be viewed separately.
|
|||
The lists summarize actionable information about the workloads,
|
||||
such as the number of ready pods for a ReplicaSet or current memory usage for a Pod.
|
||||
-->
|
||||
#### 负载
|
||||
#### 负载 {#workloads}
|
||||
|
||||
显示选中的名字空间中所有运行的应用。
|
||||
视图按照负载类型（例如：Deployment、ReplicaSet、StatefulSet）罗列应用，并且每种负载都可以单独查看。
|
||||
|
|
@ -465,7 +465,7 @@ discovering them within a cluster.
|
|||
For that reason, Service and Ingress views show Pods targeted by them,
|
||||
internal endpoints for cluster connections and external endpoints for external users.
|
||||
-->
|
||||
#### 服务
|
||||
#### 服务 {#services}
|
||||
|
||||
展示允许暴露给外网服务和允许集群内部发现的 Kubernetes 资源。
|
||||
因此，Service 和 Ingress 视图展示他们关联的 Pod、给集群连接使用的内部端点和给外部用户使用的外部端点。
|
||||
|
|
@ -475,7 +475,7 @@ internal endpoints for cluster connections and external endpoints for external u
|
|||
|
||||
Storage view shows PersistentVolumeClaim resources which are used by applications for storing data.
|
||||
-->
|
||||
#### 存储
|
||||
#### 存储 {#storage}
|
||||
|
||||
存储视图展示持久卷申领（PVC）资源，这些资源被应用程序用来存储数据。
|
||||
|
||||
|
|
@ -496,7 +496,7 @@ The view allows for editing and managing config objects and displays secrets hid
|
|||
Pod lists and detail pages link to a logs viewer that is built into Dashboard.
|
||||
The viewer allows for drilling down logs from containers belonging to a single Pod.
|
||||
-->
|
||||
#### 日志查看器
|
||||
#### 日志查看器 {#logs-viewer}
|
||||
|
||||
Pod 列表和详细信息页面可以链接到 Dashboard 内置的日志查看器。
|
||||
查看器可以深入查看属于同一个 Pod 的不同容器的日志。
|
||||
|
|
|
|||
|
|
@ -4,6 +4,15 @@ content_type: task
|
|||
min-kubernetes-server-version: v1.6
|
||||
weight: 170
|
||||
---
|
||||
<!--
|
||||
reviewers:
|
||||
- bowei
|
||||
- zihongz
|
||||
title: Debugging DNS Resolution
|
||||
content_type: task
|
||||
min-kubernetes-server-version: v1.6
|
||||
weight: 170
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
<!--
|
||||
|
|
@ -11,8 +20,6 @@ This page provides hints on diagnosing DNS problems.
|
|||
-->
|
||||
这篇文章提供了一些关于 DNS 问题诊断的方法。
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}}
|
||||
|
|
@ -28,6 +35,8 @@ kube-dns.
|
|||
|
||||
{{< version-check >}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
<!--
|
||||
### Create a simple Pod to use as a test environment
|
||||
|
||||
|
|
@ -40,17 +49,8 @@ services depends on the namespace of the pod. For more information, review
|
|||
{{< /note >}}
|
||||
|
||||
Use that manifest to create a Pod:
|
||||
|
||||
```shell
|
||||
kubectl create -f https://k8s.io/examples/admin/dns/busybox.yaml
|
||||
pod/busybox created
|
||||
|
||||
kubectl get pods busybox
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
busybox 1/1 Running 0 <some-time>
|
||||
```
|
||||
-->
|
||||
### 创建一个简单的 Pod 作为测试环境
|
||||
### 创建一个简单的 Pod 作为测试环境 {#create-a-simple-pod-to-use-as-a-test-environment}
|
||||
|
||||
{{< codenew file="admin/dns/dnsutils.yaml" >}}
|
||||
|
||||
|
|
@ -117,7 +117,7 @@ Take a look inside the resolv.conf file.
|
|||
(See [Customizing DNS Service](/docs/tasks/administer-cluster/dns-custom-nameservers) and
|
||||
[Known issues](#known-issues) below for more information)
|
||||
-->
|
||||
### 先检查本地的 DNS 配置
|
||||
### 先检查本地的 DNS 配置 {#check-the-local-dns-configuration-first}
|
||||
|
||||
查看 resolv.conf 文件的内容
|
||||
（阅读[定制 DNS 服务](/zh-cn/docs/tasks/administer-cluster/dns-custom-nameservers/) 和
|
||||
|
|
@ -405,7 +405,7 @@ term_id="endpoint" >}} related resources to properly resolve service names.
|
|||
|
||||
Sample error message:
|
||||
-->
|
||||
### CoreDNS 是否有足够的权限？
|
||||
### CoreDNS 是否有足够的权限？ {#does-coredns-have-sufficient-permissions}
|
||||
|
||||
CoreDNS 必须能够列出 {{< glossary_tooltip text="service" term_id="service" >}} 和
|
||||
{{< glossary_tooltip text="endpoint" term_id="endpoint" >}} 相关的资源来正确解析服务名称。
|
||||
|
|
@ -476,7 +476,7 @@ the namespace of the service.
|
|||
|
||||
This query is limited to the pod's namespace:
|
||||
-->
|
||||
### 你的服务在正确的名字空间中吗？
|
||||
### 你的服务在正确的名字空间中吗？ {#are-you-in-the-right-namespace-for-the-service}
|
||||
|
||||
未指定名字空间的 DNS 查询仅作用于 Pod 所在的名字空间。
|
||||
|
||||
|
|
|
|||
|
|
@ -203,11 +203,11 @@ is empty and the container exited with an error. The log output is limited to
|
|||
* See the `terminationMessagePath` field in
|
||||
[Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core).
|
||||
* Learn about [retrieving logs](/docs/concepts/cluster-administration/logging/).
|
||||
* Learn about [Go templates](https://golang.org/pkg/text/template/).
|
||||
* Learn about [Go templates](https://pkg.go.dev/text/template).
|
||||
-->
|
||||
|
||||
* 参考 [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
|
||||
资源的 `terminationMessagePath` 字段。
|
||||
* 了解[检索日志](/zh-cn/docs/concepts/cluster-administration/logging/)。
|
||||
* 了解 [Go 模板](https://golang.org/pkg/text/template/)。
|
||||
* 了解 [Go 模板](https://pkg.go.dev/text/template)。
|
||||
|
||||
|
|
|
|||
|
|
@ -36,6 +36,41 @@ that run in the Pod. To set environment variables, include the `env` or
|
|||
-->
|
||||
创建 Pod 时，可以为其下的容器设置环境变量。通过配置文件的 `env` 或者 `envFrom` 字段来设置环境变量。
|
||||
|
||||
<!--
|
||||
The `env` and `envFrom` fields have different effects.
|
||||
|
||||
`env`
|
||||
: allows you to set environment variables for a container, specifying a value directly for each variable that you name.
|
||||
-->
|
||||
`env` 和 `envFrom` 字段具有不同的效果。
|
||||
|
||||
`env`
|
||||
：可以为容器设置环境变量，直接为你所给的每个变量指定一个值。
|
||||
|
||||
<!--
|
||||
`envFrom`
|
||||
: allows you to set environment variables for a container by referencing either a ConfigMap or a Secret.
|
||||
When you use `envFrom`, all the key-value pairs in the referenced ConfigMap or Secret
|
||||
are set as environment variables for the container.
|
||||
You can also specify a common prefix string.
|
||||
-->
|
||||
`envFrom`
|
||||
：你可以通过引用 ConfigMap 或 Secret 来设置容器的环境变量。
|
||||
使用 `envFrom` 时，引用的 ConfigMap 或 Secret 中的所有键值对都被设置为容器的环境变量。
|
||||
你也可以指定一个通用的前缀字符串。
|
||||
|
||||
<!--
|
||||
You can read more about [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/#configure-all-key-value-pairs-in-a-configmap-as-container-environment-variables)
|
||||
and [Secret](/docs/tasks/inject-data-application/distribute-credentials-secure/#configure-all-key-value-pairs-in-a-secret-as-container-environment-variables).
|
||||
|
||||
This page explains how to use `env`.
|
||||
-->
|
||||
你可以阅读有关 [ConfigMap](/zh-cn/docs/tasks/configure-pod-container/configure-pod-configmap/#configure-all-key-value-pairs-in-a-configmap-as-container-environment-variables)
|
||||
和 [Secret](/zh-cn/docs/tasks/inject-data-application/distribute-credentials-secure/#configure-all-key-value-pairs-in-a-secret-as-container-environment-variables)
|
||||
的更多信息。
|
||||
|
||||
本页介绍如何使用 `env`。
|
||||
|
||||
<!--
|
||||
In this exercise, you create a Pod that runs one container. The configuration
|
||||
file for the Pod defines an environment variable with name `DEMO_GREETING` and
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ reviewers:
|
|||
- ahmetb
|
||||
content_type: tutorial
|
||||
weight: 20
|
||||
card:
|
||||
card:
|
||||
name: tutorials
|
||||
weight: 40
|
||||
title: "Stateful Example: Wordpress with Persistent Volumes"
|
||||
|
|
@ -21,13 +21,20 @@ card:
|
|||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
This tutorial shows you how to deploy a WordPress site and a MySQL database using Minikube. Both applications use PersistentVolumes and PersistentVolumeClaims to store data.
|
||||
This tutorial shows you how to deploy a WordPress site and a MySQL database using
|
||||
Minikube. Both applications use PersistentVolumes and PersistentVolumeClaims to store data.
|
||||
-->
|
||||
本示例描述了如何通过 Minikube 在 Kubernetes 上安装 WordPress 和 MySQL。
|
||||
这两个应用都使用 PersistentVolumes 和 PersistentVolumeClaims 保存数据。
|
||||
|
||||
<!--
|
||||
A [PersistentVolume](/docs/concepts/storage/persistent-volumes/)(PV)is a piece of storage in the cluster that has been manually provisioned by an administrator, or dynamically provisioned by Kubernetes using a [StorageClass](/docs/concepts/storage/storage-classes). A [PersistentVolumeClaim](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)(PVC)is a request for storage by a user that can be fulfilled by a PV. PersistentVolumes and PersistentVolumeClaims are independent from Pod lifecycles and preserve data through restarting, rescheduling, and even deleting Pods.
|
||||
A [PersistentVolume](/docs/concepts/storage/persistent-volumes/) (PV) is a piece
|
||||
of storage in the cluster that has been manually provisioned by an administrator,
|
||||
or dynamically provisioned by Kubernetes using a [StorageClass](/docs/concepts/storage/storage-classes).
|
||||
A [PersistentVolumeClaim](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) (PVC)
|
||||
is a request for storage by a user that can be fulfilled by a PV. PersistentVolumes and
|
||||
PersistentVolumeClaims are independent from Pod lifecycles and preserve data through
|
||||
restarting, rescheduling, and even deleting Pods.
|
||||
-->
|
||||
[PersistentVolume](/zh-cn/docs/concepts/storage/persistent-volumes/)（PV）是在集群里由管理员手动制备或
|
||||
Kubernetes 通过 [StorageClass](/zh-cn/docs/concepts/storage/storage-classes) 动态制备的一块存储。
|
||||
|
|
@ -38,7 +45,10 @@ PersistentVolumes 和 PersistentVolumeClaims 独立于 Pod 生命周期而存在
|
|||
|
||||
{{< warning >}}
|
||||
<!--
|
||||
This deployment is not suitable for production use cases, as it uses single instance WordPress and MySQL Pods. Consider using [WordPress Helm Chart](https://github.com/bitnami/charts/tree/master/bitnami/wordpress) to deploy WordPress in production.
|
||||
This deployment is not suitable for production use cases, as it uses single instance
|
||||
WordPress and MySQL Pods. Consider using
|
||||
[WordPress Helm Chart](https://github.com/bitnami/charts/tree/master/bitnami/wordpress)
|
||||
to deploy WordPress in production.
|
||||
-->
|
||||
这种部署并不适合生产场景，因为它使用的是单实例 WordPress 和 MySQL Pod。
|
||||
在生产场景中，请考虑使用 [WordPress Helm Chart](https://github.com/bitnami/charts/tree/master/bitnami/wordpress)
|
||||
|
|
@ -47,7 +57,10 @@ This deployment is not suitable for production use cases, as it uses single inst
|
|||
|
||||
{{< note >}}
|
||||
<!--
|
||||
The files provided in this tutorial are using GA Deployment APIs and are specific to kubernetes version 1.9 and later. If you wish to use this tutorial with an earlier version of Kubernetes, please update the API version appropriately, or reference earlier versions of this tutorial.
|
||||
The files provided in this tutorial are using GA Deployment APIs and are specific
|
||||
to kubernetes version 1.9 and later. If you wish to use this tutorial with an earlier
|
||||
version of Kubernetes, please update the API version appropriately, or reference
|
||||
earlier versions of this tutorial.
|
||||
-->
|
||||
本教程中提供的文件使用 GA Deployment API，并且特定于 kubernetes 1.9 或更高版本。
|
||||
如果你希望将本教程与 Kubernetes 的早期版本一起使用，请相应地更新 API 版本，或参考本教程的早期版本。
|
||||
|
|
@ -100,11 +113,16 @@ Download the following configuration files:
|
|||
-->
|
||||
## 创建 PersistentVolumeClaims 和 PersistentVolumes
|
||||
|
||||
<!-- MySQL and Wordpress each require a PersistentVolume to store data. Their PersistentVolumeClaims will be created at the deployment step.
|
||||
<!--
|
||||
MySQL and Wordpress each require a PersistentVolume to store data.
|
||||
Their PersistentVolumeClaims will be created at the deployment step.
|
||||
|
||||
Many cluster environments have a default StorageClass installed. When a StorageClass is not specified in the PersistentVolumeClaim, the cluster's default StorageClass is used instead.
|
||||
Many cluster environments have a default StorageClass installed.
|
||||
When a StorageClass is not specified in the PersistentVolumeClaim,
|
||||
the cluster's default StorageClass is used instead.
|
||||
|
||||
When a PersistentVolumeClaim is created, a PersistentVolume is dynamically provisioned based on the StorageClass configuration.
|
||||
When a PersistentVolumeClaim is created, a PersistentVolume is dynamically
|
||||
provisioned based on the StorageClass configuration.
|
||||
-->
|
||||
MySQL 和 Wordpress 都需要一个 PersistentVolume 来存储数据。
|
||||
它们的 PersistentVolumeClaims 将在部署步骤中创建。
|
||||
|
|
@ -116,7 +134,11 @@ MySQL 和 Wordpress 都需要一个 PersistentVolume 来存储数据。
|
|||
|
||||
{{< warning >}}
|
||||
<!--
|
||||
In local clusters, the default StorageClass uses the `hostPath` provisioner. `hostPath` volumes are only suitable for development and testing. With `hostPath` volumes, your data lives in `/tmp` on the node the Pod is scheduled onto and does not move between nodes. If a Pod dies and gets scheduled to another node in the cluster, or the node is rebooted, the data is lost.
|
||||
In local clusters, the default StorageClass uses the `hostPath` provisioner.
|
||||
`hostPath` volumes are only suitable for development and testing. With `hostPath`
|
||||
volumes, your data lives in `/tmp` on the node the Pod is scheduled onto and does
|
||||
not move between nodes. If a Pod dies and gets scheduled to another node in the
|
||||
cluster, or the node is rebooted, the data is lost.
|
||||
-->
|
||||
在本地集群中，默认的 StorageClass 使用 `hostPath` 制备程序。`hostPath` 卷仅适用于开发和测试。
|
||||
使用 `hostPath` 卷时，你的数据位于 Pod 调度到的节点上的 `/tmp` 中，并且不会在节点之间移动。
|
||||
|
|
@ -125,7 +147,8 @@ In local clusters, the default StorageClass uses the `hostPath` provisioner. `h
|
|||
|
||||
{{< note >}}
|
||||
<!--
|
||||
If you are bringing up a cluster that needs to use the `hostPath` provisioner, the `--enable-hostpath-provisioner` flag must be set in the `controller-manager` component.
|
||||
If you are bringing up a cluster that needs to use the `hostPath` provisioner,
|
||||
the `--enable-hostpath-provisioner` flag must be set in the `controller-manager` component.
|
||||
-->
|
||||
如果要建立需要使用 `hostPath` 制备程序的集群，
|
||||
则必须在 `controller-manager` 组件中设置 `--enable-hostpath-provisioner` 标志。
|
||||
|
|
@ -133,7 +156,8 @@ If you are bringing up a cluster that needs to use the `hostPath` provisioner, t
|
|||
|
||||
{{< note >}}
|
||||
<!--
|
||||
If you have a Kubernetes cluster running on Google Kubernetes Engine, please follow [this guide](https://cloud.google.com/kubernetes-engine/docs/tutorials/persistent-disk).
|
||||
If you have a Kubernetes cluster running on Google Kubernetes Engine, please
|
||||
follow [this guide](https://cloud.google.com/kubernetes-engine/docs/tutorials/persistent-disk).
|
||||
-->
|
||||
如果你已经有运行在 Google Kubernetes Engine 的集群，
|
||||
请参考[此指南](https://cloud.google.com/kubernetes-engine/docs/tutorials/persistent-disk)。
|
||||
|
|
@ -150,9 +174,13 @@ If you have a Kubernetes cluster running on Google Kubernetes Engine, please fol
|
|||
### 创建 Secret 生成器
|
||||
|
||||
<!--
|
||||
A [Secret](/docs/concepts/configuration/secret/) is an object that stores a piece of sensitive data like a password or key. Since 1.14, `kubectl` supports the management of Kubernetes objects using a kustomization file. You can create a Secret by generators in `kustomization.yaml`.
|
||||
A [Secret](/docs/concepts/configuration/secret/) is an object that stores a piece
|
||||
of sensitive data like a password or key. Since 1.14, `kubectl` supports the
|
||||
management of Kubernetes objects using a kustomization file. You can create a Secret
|
||||
by generators in `kustomization.yaml`.
|
||||
|
||||
Add a Secret generator in `kustomization.yaml` from the following command. You will need to replace `YOUR_PASSWORD` with the password you want to use.
|
||||
Add a Secret generator in `kustomization.yaml` from the following command.
|
||||
You will need to replace `YOUR_PASSWORD` with the password you want to use.
|
||||
-->
|
||||
[Secret](/zh-cn/docs/concepts/configuration/secret/) 是存储诸如密码或密钥之类敏感数据的对象。
|
||||
从 1.14 开始，`kubectl` 支持使用一个 kustomization 文件来管理 Kubernetes 对象。
|
||||
|
|
@ -176,7 +204,9 @@ EOF
|
|||
## 补充 MySQL 和 WordPress 的资源配置
|
||||
|
||||
<!--
|
||||
The following manifest describes a single-instance MySQL Deployment. The MySQL container mounts the PersistentVolume at /var/lib/mysql. The `MYSQL_ROOT_PASSWORD` environment variable sets the database password from the Secret.
|
||||
The following manifest describes a single-instance MySQL Deployment. The MySQL
|
||||
container mounts the PersistentVolume at /var/lib/mysql. The `MYSQL_ROOT_PASSWORD`
|
||||
environment variable sets the database password from the Secret.
|
||||
-->
|
||||
以下清单文件描述的是一个单实例的 MySQL Deployment。MySQL 容器将 PersistentVolume 挂载在 `/var/lib/mysql`。
|
||||
`MYSQL_ROOT_PASSWORD` 环境变量根据 Secret 设置数据库密码。
|
||||
|
|
@ -193,6 +223,7 @@ the name of the MySQL Service defined above, and WordPress will access the datab
|
|||
挂载到 `/var/www/html`，用于保存网站数据文件。
|
||||
`WORDPRESS_DB_HOST` 环境变量设置上面定义的 MySQL Service 的名称，WordPress 将通过 Service 访问数据库。
|
||||
`WORDPRESS_DB_PASSWORD` 环境变量根据使用 kustomize 生成的 Secret 设置数据库密码。
|
||||
|
||||
{{< codenew file="application/wordpress/wordpress-deployment.yaml" >}}
|
||||
|
||||
<!--
|
||||
|
|
@ -200,31 +231,31 @@ the name of the MySQL Service defined above, and WordPress will access the datab
|
|||
-->
|
||||
1. 下载 MySQL Deployment 配置文件。
|
||||
|
||||
```shell
|
||||
curl -LO https://k8s.io/examples/application/wordpress/mysql-deployment.yaml
|
||||
```
|
||||
```shell
|
||||
curl -LO https://k8s.io/examples/application/wordpress/mysql-deployment.yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
2. Download the WordPress configuration file.
|
||||
-->
|
||||
2. 下载 WordPress 配置文件。
|
||||
|
||||
```shell
|
||||
curl -LO https://k8s.io/examples/application/wordpress/wordpress-deployment.yaml
|
||||
```
|
||||
```shell
|
||||
curl -LO https://k8s.io/examples/application/wordpress/wordpress-deployment.yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
3. Add them to `kustomization.yaml` file.
|
||||
-->
|
||||
3. 将上述内容追加到 `kustomization.yaml` 文件。
|
||||
|
||||
```
|
||||
cat <<EOF >>./kustomization.yaml
|
||||
resources:
|
||||
- mysql-deployment.yaml
|
||||
- wordpress-deployment.yaml
|
||||
EOF
|
||||
```
|
||||
```shell
|
||||
cat <<EOF >>./kustomization.yaml
|
||||
resources:
|
||||
- mysql-deployment.yaml
|
||||
- wordpress-deployment.yaml
|
||||
EOF
|
||||
```
|
||||
|
||||
<!--
|
||||
## Apply and Verify
|
||||
|
|
@ -233,7 +264,7 @@ the name of the MySQL Service defined above, and WordPress will access the datab
|
|||
|
||||
<!--
|
||||
The `kustomization.yaml` contains all the resources for deploying a WordPress site and a
|
||||
MySQL database. You can apply the directory by:
|
||||
MySQL database. You can apply the directory by
|
||||
-->
|
||||
`kustomization.yaml` 包含用于部署 WordPress 网站以及 MySQL 数据库的所有资源。你可以通过以下方式应用目录：
|
||||
|
||||
|
|
@ -260,7 +291,7 @@ Now you can verify that all objects exist.
|
|||
|
||||
响应应如下所示：
|
||||
|
||||
```shell
|
||||
```
|
||||
NAME TYPE DATA AGE
|
||||
mysql-pass-c57bb4t7mf Opaque 1 9s
|
||||
```
|
||||
|
|
@ -285,10 +316,10 @@ Now you can verify that all objects exist.
|
|||
<!--
|
||||
The response should be like this:
|
||||
-->
|
||||
|
||||
|
||||
响应应如下所示：
|
||||
|
||||
```shell
|
||||
```
|
||||
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
|
||||
mysql-pv-claim Bound pvc-8cbd7b2e-4044-11e9-b2bb-42010a800002 20Gi RWO standard 77s
|
||||
wp-pv-claim Bound pvc-8cd0df54-4044-11e9-b2bb-42010a800002 20Gi RWO standard 77s
|
||||
|
|
@ -338,8 +369,8 @@ Now you can verify that all objects exist.
|
|||
响应应如下所示：
|
||||
|
||||
```
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
wordpress ClusterIP 10.0.0.89 <pending> 80:32406/TCP 4m
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
wordpress LoadBalancer 10.0.0.89 <pending> 80:32406/TCP 4m
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
|
|
@ -379,12 +410,15 @@ Now you can verify that all objects exist.
|
|||
|
||||
|
||||
|
||||
{{< warning >}}
|
||||
<!--
|
||||
Do not leave your WordPress installation on this page. If another user finds it, they can set up a website on your instance and use it to serve malicious content. <br/><br/>Either install WordPress by creating a username and password or delete your instance.
|
||||
-->
|
||||
不要在此页面上保留 WordPress 安装。如果其他用户找到了它，他们可以在你的实例上建立一个网站并使用它来提供恶意内容。<br/><br/>通过创建用户名和密码来安装 WordPress 或删除你的实例。
|
||||
{{< /warning >}}
|
||||
{{< warning >}}
|
||||
<!--
|
||||
Do not leave your WordPress installation on this page. If another user finds it,
|
||||
they can set up a website on your instance and use it to serve malicious content.<br/><br/>
|
||||
Either install WordPress by creating a username and password or delete your instance.
|
||||
-->
|
||||
不要在此页面上保留 WordPress 安装。如果其他用户找到了它，他们可以在你的实例上建立一个网站并使用它来提供恶意内容。<br/><br/>
|
||||
通过创建用户名和密码来安装 WordPress 或删除你的实例。
|
||||
{{< /warning >}}
|
||||
|
||||
## {{% heading "cleanup" %}}
|
||||
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ spec:
|
|||
- key: "CriticalAddonsOnly"
|
||||
operator: "Exists"
|
||||
containers:
|
||||
- image: us.gcr.io/k8s-artifacts-prod/kas-network-proxy/proxy-agent:v0.0.16
|
||||
- image: us.gcr.io/k8s-artifacts-prod/kas-network-proxy/proxy-agent:v0.0.37
|
||||
name: konnectivity-agent
|
||||
command: ["/proxy-agent"]
|
||||
args: [
|
||||
|
|
|
|||
|
|
@ -8,12 +8,13 @@ spec:
|
|||
hostNetwork: true
|
||||
containers:
|
||||
- name: konnectivity-server-container
|
||||
image: registry.k8s.io/kas-network-proxy/proxy-server:v0.0.32
|
||||
image: registry.k8s.io/kas-network-proxy/proxy-server:v0.0.37
|
||||
command: ["/proxy-server"]
|
||||
args: [
|
||||
"--logtostderr=true",
|
||||
# 下一行需与 egressSelectorConfiguration 中设置的值一致。
|
||||
"--uds-name=/etc/kubernetes/konnectivity-server/konnectivity-server.socket",
|
||||
"--delete-existing-uds-file",
|
||||
# 下面两行假定 Konnectivity 服务器被部署在与 apiserver 相同的机器上，
|
||||
# 并且该 API 服务器的证书和密钥位于指定的位置。
|
||||
"--cluster-cert=/etc/kubernetes/pki/apiserver.crt",
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ type: docs
|
|||
auto_generated: true
|
||||
-->
|
||||
|
||||
<!-- THIS CONTENT IS AUTO-GENERATED via ./scripts/releng/update-release-info.sh in k/website -->
|
||||
<!-- THIS CONTENT IS AUTO-GENERATED via ./scripts/releng/update-release-info.sh in kubernetes/website -->
|
||||
|
||||
{{< warning >}}
|
||||
<!--
|
||||
|
|
|
|||
|
|
@ -79,7 +79,7 @@ other = "Kubernetes Features"
|
|||
other = """Wir sind ein <a href="https://cncf.io/">CNCF</a> Abschlussprojekt</p>"""
|
||||
|
||||
[main_kubeweekly_baseline]
|
||||
other = "Möchten Sie die neuesten Nachrichten von Kubernetes erhalten? Melden Sie sich für KubeWeekly an."
|
||||
other = "Möchtest du die neuesten Nachrichten von Kubernetes erhalten? Melde dich für KubeWeekly an."
|
||||
|
||||
[main_kubernetes_past_link]
|
||||
other = "Frühere Newsletter anzeigen"
|
||||
|
|
|
|||
Loading…
Reference in New Issue