Merge remote-tracking branch 'upstream/main' into dev-1.24
This commit is contained in:
Nate W
commit
e65201a5b3
|
|
@ -29,7 +29,7 @@ This page lists some of the available add-ons and links to their respective inst
|
|||
* [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin) is OVN based CNI controller plugin to provide cloud native based Service function chaining(SFC), Multiple OVN overlay networking, dynamic subnet creation, dynamic creation of virtual networks, VLAN Provider network, Direct provider network and pluggable with other Multi-network plugins, ideal for edge based cloud native workloads in Multi-cluster networking
|
||||
* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in (NCP) provides integration between VMware NSX-T and container orchestrators such as Kubernetes, as well as integration between NSX-T and container-based CaaS/PaaS platforms such as Pivotal Container Service (PKS) and OpenShift.
|
||||
* [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) is an SDN platform that provides policy-based networking between Kubernetes Pods and non-Kubernetes environments with visibility and security monitoring.
|
||||
* [Romana](https://romana.io) is a Layer 3 networking solution for pod networks that also supports the [NetworkPolicy API](/docs/concepts/services-networking/network-policies/). Kubeadm add-on installation details available [here](https://github.com/romana/romana/tree/master/containerize).
|
||||
* **Romana** is a Layer 3 networking solution for pod networks that also supports the [NetworkPolicy API](/docs/concepts/services-networking/network-policies/). Kubeadm add-on installation details available [here](https://github.com/romana/romana/tree/master/containerize).
|
||||
* [Weave Net](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/) provides networking and network policy, will carry on working on both sides of a network partition, and does not require an external database.
|
||||
|
||||
## Service Discovery
|
||||
|
|
|
|||
|
|
@ -27,6 +27,8 @@ API or the `kube-*` components from the upstream code, see the following instruc
|
|||
- [Golang](https://golang.org/doc/install) version 1.13+
|
||||
- [Docker](https://docs.docker.com/engine/installation/)
|
||||
- [etcd](https://github.com/coreos/etcd/)
|
||||
- [make](https://www.gnu.org/software/make/)
|
||||
- [gcc compiler/linker](https://gcc.gnu.org/)
|
||||
|
||||
- Your `GOPATH` environment variable must be set, and the location of `etcd`
|
||||
must be in your `PATH` environment variable.
|
||||
|
|
@ -142,8 +144,9 @@ Run `git status` to see what was generated.
|
|||
On branch master
|
||||
...
|
||||
modified: api/openapi-spec/swagger.json
|
||||
modified: api/openapi-spec/v3/apis__apps__v1_openapi.json
|
||||
modified: pkg/generated/openapi/zz_generated.openapi.go
|
||||
modified: staging/src/k8s.io/api/apps/v1/generated.proto
|
||||
modified: staging/src/k8s.io/api/apps/v1/types.go
|
||||
modified: staging/src/k8s.io/api/apps/v1/types_swagger_doc_generated.go
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -778,7 +778,7 @@ This admission controller will deny any Pod that attempts to set certain escalat
|
|||
fields, as shown in the
|
||||
[Configure a Security Context for a Pod or Container](/docs/tasks/configure-pod-container/security-context/)
|
||||
task.
|
||||
If you don't use [Pod Security admission]((/docs/concepts/security/pod-security-admission/),
|
||||
If you don't use [Pod Security admission](/docs/concepts/security/pod-security-admission/),
|
||||
[PodSecurityPolicies](/docs/concepts/security/pod-security-policy/), nor any external enforcement mechanism,
|
||||
then you could use this admission controller to restrict the set of values a security context can take.
|
||||
|
||||
|
|
|
|||
|
|
@ -109,14 +109,16 @@ IngressSpec describes the Ingress the user wishes to exist.
|
|||
|
||||
- **rules.http.paths.pathType** (string), required
|
||||
|
||||
PathType determines the interpretation of the Path matching. PathType can be one of the following values: * Exact: Matches the URL path exactly. * Prefix: Matches based on a URL path prefix split by '/'. Matching is
|
||||
PathType determines the interpretation of the Path matching. PathType can be one of the following enum values:
|
||||
- `"Exact"` Matches the URL path exactly.
|
||||
- `"Prefix"` Matches based on a URL path prefix split by '/'. Matching is
|
||||
done on a path element by element basis. A path element refers is the
|
||||
list of labels in the path split by the '/' separator. A request is a
|
||||
match for path p if every p is an element-wise prefix of p of the
|
||||
request path. Note that if the last element of the path is a substring
|
||||
of the last element in request path, it is not a match (e.g. /foo/bar
|
||||
matches /foo/bar/baz, but does not match /foo/barbaz).
|
||||
* ImplementationSpecific: Interpretation of the Path matching is up to
|
||||
- `"ImplementationSpecific"` Interpretation of the Path matching is up to
|
||||
the IngressClass. Implementations can treat this as a separate PathType
|
||||
or treat it identically to Prefix or Exact path types.
|
||||
Implementations are required to support all path types.
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ Kubernetes requires PKI for the following operations:
|
|||
|
||||
* Client certificates for the kubelet to authenticate to the API server
|
||||
* Kubelet [server certificates](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#client-and-serving-certificates)
|
||||
for the the API server to talk to the kubelets
|
||||
for the API server to talk to the kubelets
|
||||
* Server certificate for the API server endpoint
|
||||
* Client certificates for administrators of the cluster to authenticate to the API server
|
||||
* Client certificates for the API server to talk to the kubelets
|
||||
|
|
@ -91,7 +91,7 @@ Required certificates:
|
|||
the load balancer stable IP and/or DNS name, `kubernetes`, `kubernetes.default`, `kubernetes.default.svc`,
|
||||
`kubernetes.default.svc.cluster`, `kubernetes.default.svc.cluster.local`)
|
||||
|
||||
where `kind` maps to one or more of the [x509 key usage](https://godoc.org/k8s.io/api/certificates/v1beta1#KeyUsage) types:
|
||||
where `kind` maps to one or more of the [x509 key usage](https://pkg.go.dev/k8s.io/api/certificates/v1beta1#KeyUsage) types:
|
||||
|
||||
| kind | Key usage |
|
||||
|--------|---------------------------------------------------------------------------------|
|
||||
|
|
|
|||
|
|
@ -24,9 +24,12 @@ you can skip the default CoreDNS deployment and deploy your own variant.
|
|||
For more details on that see [Using init phases with kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm-init/#init-phases).
|
||||
{{< /note >}}
|
||||
|
||||
<!-- body -->
|
||||
{{< note >}}
|
||||
To reconfigure a cluster that has already been created see
|
||||
[Reconfiguring a kubeadm cluster](/docs/tasks/administer-cluster/kubeadm/kubeadm-reconfigure).
|
||||
{{< /note >}}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.12" state="stable" >}}
|
||||
<!-- body -->
|
||||
|
||||
## Customizing the control plane with flags in `ClusterConfiguration`
|
||||
|
||||
|
|
|
|||
|
|
@ -161,6 +161,9 @@ To customize control plane components, including optional IPv6 assignment to liv
|
|||
for control plane components and etcd server, provide extra arguments to each component as documented in
|
||||
[custom arguments](/docs/setup/production-environment/tools/kubeadm/control-plane-flags/).
|
||||
|
||||
To reconfigure a cluster that has already been created see
|
||||
[Reconfiguring a kubeadm cluster](/docs/tasks/administer-cluster/kubeadm/kubeadm-reconfigure).
|
||||
|
||||
To run `kubeadm init` again, you must first [tear down the cluster](#tear-down).
|
||||
|
||||
If you join a node with a different architecture to your cluster, make sure that your deployed DaemonSets
|
||||
|
|
|
|||
|
|
@ -173,7 +173,7 @@ The built-in signer is part of [`kube-controller-manager`](/docs/reference/comma
|
|||
|
||||
To activate the built-in signer, you must pass the `--cluster-signing-cert-file` and `--cluster-signing-key-file` flags.
|
||||
|
||||
If you're creating a new cluster, you can use a kubeadm [configuration file](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta3):
|
||||
If you're creating a new cluster, you can use a kubeadm [configuration file](https://pkg.go.dev/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta3):
|
||||
|
||||
```yaml
|
||||
apiVersion: kubeadm.k8s.io/v1beta3
|
||||
|
|
|
|||
|
|
@ -0,0 +1,281 @@
|
|||
---
|
||||
reviewers:
|
||||
- sig-cluster-lifecycle
|
||||
title: Reconfiguring a kubeadm cluster
|
||||
content_type: task
|
||||
weight: 10
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
kubeadm does not support automated ways of reconfiguring components that
|
||||
were deployed on managed nodes. One way of automating this would be
|
||||
by using a custom [operator](/docs/concepts/extend-kubernetes/operator/).
|
||||
|
||||
To modify the components configuration you must manually edit associated cluster
|
||||
objects and files on disk.
|
||||
|
||||
This guide shows the correct sequence of steps that need to be performed
|
||||
to achieve kubeadm cluster reconfiguration.
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
- You need a cluster that was deployed using kubeadm
|
||||
- Have administrator credentials (`/etc/kubernetes/admin.conf`) and network connectivity
|
||||
to a running kube-apiserver in the cluster from a host that has kubectl installed
|
||||
- Have a text editor installed on all hosts
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Reconfiguring the cluster
|
||||
|
||||
kubeadm writes a set of cluster wide component configuration options in
|
||||
ConfigMaps and other objects. These objects must be manually edited. The command `kubectl edit`
|
||||
can be used for that.
|
||||
|
||||
The `kubectl edit` command will open a text editor where you can edit and save the object directly.
|
||||
|
||||
You can use the environment variables `KUBECONFIG` and `KUBE_EDITOR` to specify the location of
|
||||
the kubectl consumed kubeconfig file and preferred text editor.
|
||||
|
||||
For example:
|
||||
```
|
||||
KUBECONFIG=/etc/kubernetes/admin.conf KUBE_EDITOR=nano kubectl edit <parameters>
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
Upon saving any changes to these cluster objects, components running on nodes may not be
|
||||
automatically updated. The steps below instruct you on how to perform that manually.
|
||||
{{< /note >}}
|
||||
|
||||
{{< warning >}}
|
||||
Component configuration in ConfigMaps is stored as unstructured data (YAML string).
|
||||
This means that validation will not be performed upon updating the contents of a ConfigMap.
|
||||
You have to be careful to follow the documented API format for a particular
|
||||
component configuration and avoid introducing typos and YAML indentation mistakes.
|
||||
{{< /warning >}}
|
||||
|
||||
### Applying cluster configuration changes
|
||||
|
||||
#### Updating the `ClusterConfiguration`
|
||||
|
||||
During cluster creation and upgrade, kubeadm writes its
|
||||
[`ClusterConfiguration`](/docs/reference/config-api/kubeadm-config.v1beta3/)
|
||||
in a ConfigMap called `kubeadm-config` in the `kube-system` namespace.
|
||||
|
||||
To change a particular option in the `ClusterConfiguration` you can edit the ConfigMap with this command:
|
||||
|
||||
```shell
|
||||
kubectl edit cm -n kube-system kubeadm-config
|
||||
```
|
||||
|
||||
The configuration is located under the `data.ClusterConfiguration` key.
|
||||
|
||||
{{< note >}}
|
||||
The `ClusterConfiguration` includes a variety of options that affect the configuration of individual
|
||||
components such as kube-apiserver, kube-scheduler, kube-controller-manager, CoreDNS, etcd and kube-proxy.
|
||||
Changes to the configuration must be reflected on node components manually.
|
||||
{{< /note >}}
|
||||
|
||||
#### Reflecting `ClusterConfiguration` changes on control plane nodes
|
||||
|
||||
kubeadm manages the control plane components as static Pod manifests located in
|
||||
the directory `/etc/kubernetes/manifests`.
|
||||
Any changes to the `ClusterConfiguration` under the `apiServer`, `controllerManager`, `scheduler` or `etcd`
|
||||
keys must be reflected in the associated files in the manifests directory on a control plane node.
|
||||
|
||||
Such changes may include:
|
||||
- `extraArgs` - requires updating the list of flags passed to a component container
|
||||
- `extraMounts` - requires updated the volume mounts for a component container
|
||||
- `*SANs` - requires writing new certificates with updated Subject Alternative Names.
|
||||
|
||||
Before proceeding with these changes, make sure you have backed up the directory `/etc/kubernetes/`.
|
||||
|
||||
To write new certificates you can use:
|
||||
```shell
|
||||
kubeadm init phase certs <component-name> --config <config-file>
|
||||
```
|
||||
|
||||
To write new manifest files in `/etc/kubernetes/manifests` you can use:
|
||||
|
||||
```shell
|
||||
kubeadm init phase control-plane <component-name> --config <config-file>
|
||||
```
|
||||
|
||||
The `<config-file>` contents must match the updated `ClusterConfiguration`.
|
||||
The `<component-name>` value must be the name of the component.
|
||||
|
||||
{{< note >}}
|
||||
Updating a file in `/etc/kubernetes/manifests` will tell the kubelet to restart the static Pod for the corresponding component.
|
||||
Try doing these changes one node at a time to leave the cluster without downtime.
|
||||
{{< /note >}}
|
||||
|
||||
### Applying kubelet configuration changes
|
||||
|
||||
#### Updating the `KubeletConfiguration`
|
||||
|
||||
During cluster creation and upgrade, kubeadm writes its
|
||||
[`KubeletConfiguration`](/docs/reference/config-api/kubelet-config.v1beta1/)
|
||||
in a ConfigMap called `kubelet-config` in the `kube-system` namespace.
|
||||
|
||||
You can edit the ConfigMap with this command:
|
||||
|
||||
```shell
|
||||
kubectl edit cm -n kube-system kubelet-config
|
||||
```
|
||||
|
||||
The configuration is located under the `data.kubelet` key.
|
||||
|
||||
#### Reflecting the kubelet changes
|
||||
|
||||
To reflect the change on kubeadm nodes you must do the following:
|
||||
- Log in to a kubeadm node
|
||||
- Run `kubeadm upgrade node phase kubelet-config` to download the latest `kubelet-config`
|
||||
ConfigMap contents into the local file `/var/lib/kubelet/config.conf`
|
||||
- Edit the file `/var/lib/kubelet/kubeadm-flags.env` to apply additional configuration with
|
||||
flags
|
||||
- Restart the kubelet service with `systemctl restart kubelet`
|
||||
|
||||
{{< note >}}
|
||||
Do these changes one node at a time to allow workloads to be rescheduled properly.
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
During `kubeadm upgrade`, kubeadm downloads the `KubeletConfiguration` from the
|
||||
`kubelet-config` ConfigMap and overwrite the contents of `/var/lib/kubelet/config.conf`.
|
||||
This means that node local configuration must be applied either by flags in
|
||||
`/var/lib/kubelet/kubeadm-flags.env` or by manually updating the contents of
|
||||
`/var/lib/kubelet/config.conf` after `kubeadm upgrade`, and then restarting the kubelet.
|
||||
{{< /note >}}
|
||||
|
||||
### Applying kube-proxy configuration changes
|
||||
|
||||
#### Updating the `KubeProxyConfiguration`
|
||||
|
||||
During cluster creation and upgrade, kubeadm writes its
|
||||
[`KubeProxyConfiguration`](/docs/reference/config-api/kube-proxy-config.v1alpha1/)
|
||||
in a ConfigMap in the `kube-system` namespace called `kube-proxy`.
|
||||
|
||||
This ConfigMap is used by the `kube-proxy` DaemonSet in the `kube-system` namespace.
|
||||
|
||||
To change a particular option in the `KubeProxyConfiguration`, you can edit the ConfigMap with this command:
|
||||
|
||||
```shell
|
||||
kubectl edit cm -n kube-system kube-proxy
|
||||
```
|
||||
|
||||
The configuration is located under the `data.config.conf` key.
|
||||
|
||||
#### Reflecting the kube-proxy changes
|
||||
|
||||
Once the `kube-proxy` ConfigMap is updated, you can restart all kube-proxy Pods:
|
||||
|
||||
Obtain the Pod names:
|
||||
|
||||
```shell
|
||||
kubectl get po -n kube-system | grep kube-proxy
|
||||
```
|
||||
|
||||
Delete a Pod with:
|
||||
|
||||
```shell
|
||||
kubectl delete po -n kube-system <pod-name>
|
||||
```
|
||||
|
||||
New Pods that use the updated ConfigMap will be created.
|
||||
|
||||
{{< note >}}
|
||||
Because kubeadm deploys kube-proxy as a DaemonSet, node specific configuration is unsupported.
|
||||
{{< /note >}}
|
||||
|
||||
### Applying CoreDNS configuration changes
|
||||
|
||||
#### Updating the CoreDNS Deployment and Service
|
||||
|
||||
kubeadm deploys CoreDNS as a Deployment called `coredns` and with a Service `kube-dns`,
|
||||
both in the `kube-system` namespace.
|
||||
|
||||
To update any of the CoreDNS settings, you can edit the Deployment and
|
||||
Service objects:
|
||||
|
||||
```shell
|
||||
kubectl edit deployment -n kube-system coredns
|
||||
kubectl edit service -n kube-system kube-dns
|
||||
```
|
||||
|
||||
#### Reflecting the CoreDNS changes
|
||||
|
||||
Once the CoreDNS changes are applied you can delete the CoreDNS Pods:
|
||||
|
||||
Obtain the Pod names:
|
||||
|
||||
```shell
|
||||
kubectl get po -n kube-system | grep coredns
|
||||
```
|
||||
|
||||
Delete a Pod with:
|
||||
|
||||
```shell
|
||||
kubectl delete po -n kube-system <pod-name>
|
||||
```
|
||||
|
||||
New Pods with the updated CoreDNS configuration will be created.
|
||||
|
||||
{{< note >}}
|
||||
kubeadm does not allow CoreDNS configuration during cluster creation and upgrade.
|
||||
This means that if you execute `kubeadm upgrade apply`, your changes to the CoreDNS
|
||||
objects will be lost and must be reapplied.
|
||||
{{< /note >}}
|
||||
|
||||
## Persisting the reconfiguration
|
||||
|
||||
During the execution of `kubeadm upgrade` on a managed node, kubeadm might overwrite configuration
|
||||
that was applied after the cluster was created (reconfiguration).
|
||||
|
||||
### Persisting Node object reconfiguration
|
||||
|
||||
kubeadm writes Labels, Taints, CRI socket and other information on the Node object for a particular
|
||||
Kubernetes node. To change any of the contents of this Node object you can use:
|
||||
|
||||
```shell
|
||||
kubectl edit no <node-name>
|
||||
```
|
||||
|
||||
During `kubeadm upgrade` the contents of such a Node might get overwritten.
|
||||
If you would like to persist your modifications to the Node object after upgrade,
|
||||
you can prepare a [kubectl patch](/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/)
|
||||
and apply it to the Node object:
|
||||
|
||||
```shell
|
||||
kubectl patch no <node-name> --patch-file <patch-file>
|
||||
```
|
||||
|
||||
#### Persisting control plane component reconfiguration
|
||||
|
||||
The main source of control plane configuration is the `ClusterConfiguration`
|
||||
object stored in the cluster. To extend the static Pod manifests configuration,
|
||||
[patches](/docs/setup/production-environment/tools/kubeadm/control-plane-flags/#patches) can be used.
|
||||
|
||||
These patch files must remain as files on the control plane nodes to ensure that
|
||||
they can be used by the `kubeadm upgrade ... --patches <directory>`.
|
||||
|
||||
If reconfiguration is done to the `ClusterConfiguration` and static Pod manifests on disk,
|
||||
the set of node specific patches must be updated accordingly.
|
||||
|
||||
#### Persisting kubelet reconfiguration
|
||||
|
||||
Any changes to the `KubeletConfiguration` stored in `/var/lib/kubelet/config.conf` will be overwritten on
|
||||
`kubeadm upgrade` by downloading the contents of the cluster wide `kubelet-config` ConfigMap.
|
||||
To persist kubelet node specific configuration either the file `/var/lib/kubelet/config.conf`
|
||||
has to be updated manually post-upgrade or the file `/var/lib/kubelet/kubeadm-flags.env` can include flags.
|
||||
The kubelet flags override the associated `KubeletConfiguration` options, but note that
|
||||
some of the flags are deprecated.
|
||||
|
||||
A kubelet restart will be required after changing `/var/lib/kubelet/config.conf` or
|
||||
`/var/lib/kubelet/kubeadm-flags.env`.
|
||||
|
||||
{{% heading "whatsnext" %}}
|
||||
|
||||
- [Upgrading kubeadm clusters](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade)
|
||||
- [Customizing components with the kubeadm API](/docs/setup/production-environment/tools/kubeadm/control-plane-flags)
|
||||
- [Certificate management with kubeadm](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs)
|
||||
|
|
@ -43,7 +43,12 @@ first drain the node (or nodes) that you are upgrading. In the case of control p
|
|||
they could be running CoreDNS Pods or other critical workloads. For more information see
|
||||
[Draining nodes](/docs/tasks/administer-cluster/safely-drain-node/).
|
||||
- All containers are restarted after upgrade, because the container spec hash value is changed.
|
||||
- To verify that the kubelet service has successfully restarted after the kubelet has been upgraded, you can execute `systemctl status kubelet` or view the service logs with `journalctl -xeu kubelet`.
|
||||
- To verify that the kubelet service has successfully restarted after the kubelet has been upgraded,
|
||||
you can execute `systemctl status kubelet` or view the service logs with `journalctl -xeu kubelet`.
|
||||
- Usage of the `--config` flag of `kubeadm upgrade` with
|
||||
[kubeadm configuration API types](/docs/reference/config-api/kubeadm-config.v1beta3)
|
||||
with the purpose of reconfiguring the cluster is not recommended and can have unexpected results. Follow the steps in
|
||||
[Reconfiguring a kubeadm cluster](/docs/tasks/administer-cluster/kubeadm/kubeadm-reconfigure) instead.
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
|
|
|
|||
|
|
@ -243,7 +243,7 @@ like the `kube-system` namespace, because those pods can gain access to service
|
|||
or run with elevated permissions if those service accounts are granted access to permissive
|
||||
[PodSecurityPolicies](/docs/concepts/security/pod-security-policy/).
|
||||
|
||||
If you use [Pod Security admission]((/docs/concepts/security/pod-security-admission/) and allow
|
||||
If you use [Pod Security admission](/docs/concepts/security/pod-security-admission/) and allow
|
||||
any component to create Pods within a namespace that permits privileged Pods, those Pods may
|
||||
be able to escape their containers and use this widened access to elevate their privileges.
|
||||
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ the direct installation of host services.
|
|||
|
||||
Administrative tasks such as installation of security patches, event
|
||||
log collection, and more can be performed without requiring cluster operators to
|
||||
log onto each Window node. HostProcess containers can run as any user that is
|
||||
log onto each Windows node. HostProcess containers can run as any user that is
|
||||
available on the host or is in the domain of the host machine, allowing administrators
|
||||
to restrict resource access through user permissions. While neither filesystem or process
|
||||
isolation are supported, a new volume is created on the host upon starting the container
|
||||
|
|
|
|||
|
|
@ -47,7 +47,7 @@ some extra application configuration. You will need to add the CA certificate
|
|||
bundle to the list of CA certificates that the TLS client or server trusts. For
|
||||
example, you would do this with a golang TLS config by parsing the certificate
|
||||
chain and adding the parsed certificates to the `RootCAs` field in the
|
||||
[`tls.Config`](https://godoc.org/crypto/tls#Config) struct.
|
||||
[`tls.Config`](https://pkg.go.dev/crypto/tls#Config) struct.
|
||||
|
||||
{{< note >}}
|
||||
Even though the custom CA certificate may be included in the filesystem (in the
|
||||
|
|
|
|||
|
|
@ -152,7 +152,7 @@ sudo yum install -y kubectl
|
|||
|
||||
{{< tabs name="other_kubectl_install" >}}
|
||||
{{% tab name="Snap" %}}
|
||||
If you are on Ubuntu or another Linux distribution that support [snap](https://snapcraft.io/docs/core/install) package manager, kubectl is available as a [snap](https://snapcraft.io/) application.
|
||||
If you are on Ubuntu or another Linux distribution that supports the [snap](https://snapcraft.io/docs/core/install) package manager, kubectl is available as a [snap](https://snapcraft.io/) application.
|
||||
|
||||
```shell
|
||||
snap install kubectl --classic
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
You need to either have a [dynamic PersistentVolume provisioner](/docs/concepts/storage/dynamic-provisioning/) with a default
|
||||
[StorageClass](/docs/concepts/storage/storage-classes/),
|
||||
or [statically provision PersistentVolumes](/docs/user-guide/persistent-volumes/#provisioning)
|
||||
yourself to satisfy the [PersistentVolumeClaims](/docs/user-guide/persistent-volumes/#persistentvolumeclaims)
|
||||
or [statically provision PersistentVolumes](/docs/concepts/storage/persistent-volumes/#provisioning)
|
||||
yourself to satisfy the [PersistentVolumeClaims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)
|
||||
used here.
|
||||
|
||||
|
|
|
|||
|
|
@ -230,8 +230,8 @@ kubeadm contient tout ce qui est nécessaire pour générer les certificats déc
|
|||
|
||||
```sh
|
||||
root@HOST0 $ kubeadm init phase etcd local --config=/tmp/${HOST0}/kubeadmcfg.yaml
|
||||
root@HOST1 $ kubeadm init phase etcd local --config=/tmp/${HOST1}/kubeadmcfg.yaml
|
||||
root@HOST2 $ kubeadm init phase etcd local --config=/tmp/${HOST2}/kubeadmcfg.yaml
|
||||
root@HOST1 $ kubeadm init phase etcd local --config=$HOME/kubeadmcfg.yaml
|
||||
root@HOST2 $ kubeadm init phase etcd local --config=$HOME/kubeadmcfg.yaml
|
||||
```
|
||||
|
||||
1. Facultatif: Vérifiez la santé du cluster
|
||||
|
|
|
|||
|
|
@ -242,8 +242,8 @@ this example.
|
|||
|
||||
```sh
|
||||
root@HOST0 $ kubeadm init phase etcd local --config=/tmp/${HOST0}/kubeadmcfg.yaml
|
||||
root@HOST1 $ kubeadm init phase etcd local --config=/tmp/${HOST1}/kubeadmcfg.yaml
|
||||
root@HOST2 $ kubeadm init phase etcd local --config=/tmp/${HOST2}/kubeadmcfg.yaml
|
||||
root@HOST1 $ kubeadm init phase etcd local --config=$HOME/kubeadmcfg.yaml
|
||||
root@HOST2 $ kubeadm init phase etcd local --config=$HOME/kubeadmcfg.yaml
|
||||
```
|
||||
|
||||
1. Optional: Check the cluster health
|
||||
|
|
|
|||
|
|
@ -0,0 +1,104 @@
|
|||
---
|
||||
title: cgroupドライバーの設定
|
||||
content_type: task
|
||||
weight: 10
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
このページでは、kubeadmクラスターのコンテナランタイムcgroupドライバーに合わせて、kubelet cgroupドライバーを設定する方法について説明します。
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
Kubernetesの[コンテナランタイムの要件](/docs/setup/production-environment/container-runtimes)を熟知している必要があります。
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## コンテナランタイムのcgroupドライバーの設定
|
||||
|
||||
[Container runtimes](/docs/setup/production-environment/container-runtimes)ページでは、kubeadmベースのセットアップでは`cgroupfs`ドライバーではなく、`systemd`ドライバーが推奨されると説明されています。
|
||||
|
||||
このページでは、デフォルトの`systemd`ドライバーを使用して多くの異なるコンテナランタイムをセットアップする方法についての詳細も説明されています。
|
||||
|
||||
## kubelet cgroupドライバーの設定
|
||||
|
||||
kubeadmでは、`kubeadm init`の際に`KubeletConfiguration`構造体を渡すことができます。
|
||||
|
||||
この`KubeletConfiguration`には、kubeletのcgroupドライバーを制御する`cgroupDriver`フィールドを含めることができます。
|
||||
|
||||
{{< note >}}
|
||||
v1.22では、ユーザーが`KubeletConfiguration`の`cgroupDriver`フィールドを設定していない場合、`kubeadm`はデフォルトで`systemd`を設定するようになりました。
|
||||
{{< /note >}}
|
||||
|
||||
フィールドを明示的に設定する最小限の例です:
|
||||
|
||||
```yaml
|
||||
# kubeadm-config.yaml
|
||||
kind: ClusterConfiguration
|
||||
apiVersion: kubeadm.k8s.io/v1beta3
|
||||
kubernetesVersion: v1.21.0
|
||||
---
|
||||
kind: KubeletConfiguration
|
||||
apiVersion: kubelet.config.k8s.io/v1beta1
|
||||
cgroupDriver: systemd
|
||||
```
|
||||
|
||||
このような設定ファイルは、kubeadmコマンドに渡すことができます:
|
||||
|
||||
```shell
|
||||
kubeadm init --config kubeadm-config.yaml
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
Kubeadmはクラスター内の全ノードで同じ`KubeletConfiguration`を使用します。
|
||||
|
||||
`KubeletConfiguration`は`kube-system`名前空間下の[ConfigMap](/docs/concepts/configuration/configmap)オブジェクトに格納されます。
|
||||
|
||||
サブコマンド`init`、`join`、`upgrade`を実行すると、kubeadmが`KubeletConfiguration`を`/var/lib/kubelet/config.yaml`以下にファイルとして書き込み、ローカルノードのkubeletに渡します。
|
||||
{{< /note >}}
|
||||
|
||||
## cgroupfsドライバーの使用
|
||||
|
||||
このガイドで説明するように、`cgroupfs`ドライバーをkubeadmと一緒に使用することは推奨されません。
|
||||
`cgroupfs`を使い続け、`kubeadm upgrade`が既存のセットアップで`KubeletConfiguration` cgroupドライバーを変更しないようにするには、その値を明示的に指定する必要があります。
|
||||
これは、将来のバージョンのkubeadmに`systemd`ドライバーをデフォルトで適用させたくない場合に適用されます。
|
||||
値を明示する方法については、後述の「kubelet ConfigMapの修正」の項を参照してください。
|
||||
`cgroupfs`ドライバーを使用するようにコンテナランタイムを設定したい場合は、選択したコンテナランタイムのドキュメントを参照する必要があります。
|
||||
|
||||
## `systemd`ドライバーへの移行
|
||||
|
||||
既存のkubeadmクラスターのcgroupドライバーを`systemd`にインプレースで変更する場合は、kubeletのアップグレードと同様の手順が必要です。
|
||||
これには、以下に示す両方の手順を含める必要があります。
|
||||
|
||||
{{< note >}}
|
||||
あるいは、クラスター内の古いノードを`systemd`ドライバーを使用する新しいノードに置き換えることも可能です。
|
||||
この場合、新しいノードに参加する前に以下の最初のステップのみを実行し、古いノードを削除する前にワークロードが新しいノードに安全に移動できることを確認する必要があります。
|
||||
{{< /note >}}
|
||||
|
||||
### kubelet ConfigMapの修正
|
||||
|
||||
- `kubectl get cm -n kube-system | grep kubelet-config`で、kubelet ConfigMapの名前を探します。
|
||||
- `kubectl edit cm kubelet-config-x.yy -n kube-system`を呼び出します(`x.yy`はKubernetesのバージョンに置き換えてください)。
|
||||
- 既存の`cgroupDriver`の値を修正するか、以下のような新しいフィールドを追加します。
|
||||
|
||||
``yaml
|
||||
cgroupDriver: systemd
|
||||
```
|
||||
|
||||
このフィールドは、ConfigMapの`kubelet:`セクションの下に存在する必要があります。
|
||||
|
||||
### 全ノードでcgroupドライバーを更新
|
||||
|
||||
クラスター内の各ノードについて:
|
||||
|
||||
- [Drain the node](/docs/tasks/administer-cluster/safely-drain-node)を`kubectl drain <node-name> --ignore-daemonsets`を使ってドレーンします。
|
||||
- `systemctl stop kubelet`を使用して、kubeletを停止します。
|
||||
- コンテナランタイムの停止。
|
||||
- コンテナランタイムのcgroupドライバーを`systemd`に変更します。
|
||||
- `var/lib/kubelet/config.yaml`に`cgroupDriver: systemd`を設定します。
|
||||
- コンテナランタイムの開始。
|
||||
- `systemctl start kubelet`でkubeletを起動します。
|
||||
- [Drain the node](/docs/tasks/administer-cluster/safely-drain-node)を`kubectl uncordon <node-name>`を使って行います。
|
||||
|
||||
ワークロードが異なるノードでスケジュールするための十分な時間を確保するために、これらのステップを1つずつノード上で実行します。
|
||||
プロセスが完了したら、すべてのノードとワークロードが健全であることを確認します。
|
||||
|
|
@ -0,0 +1,18 @@
|
|||
---
|
||||
title: dockershimからの移行
|
||||
weight: 10
|
||||
content_type: task
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
dockershimから他のコンテナランタイムに移行する際に知っておくべき情報を紹介します。
|
||||
|
||||
Kubernetes 1.20で[dockershim deprecation](blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation)が発表されてから、様々なワークロードやKubernetesインストールにどう影響するのかという質問が寄せられています。
|
||||
|
||||
この問題をよりよく理解するために、[Dockershim Deprecation FAQ](/blog/2020/12/02/dockershim-faq/)ブログが役に立つでしょう。
|
||||
|
||||
dockershimから代替のコンテナランタイムに移行することが推奨されます。
|
||||
[コンテナランタイム](/ja/docs/setup/production-environment/container-runtimes/)のセクションをチェックして、どのような選択肢があるかを確認してください。
|
||||
問題が発生した場合は、必ず[問題の報告](https://github.com/kubernetes/kubernetes/issues)をしてください。
|
||||
そうすれば、問題が適時に修正され、クラスターがdockershimの削除に対応できるようになります。
|
||||
|
|
@ -0,0 +1,70 @@
|
|||
---
|
||||
title: dockershimからテレメトリーやセキュリティエージェントを移行する
|
||||
content_type: task
|
||||
weight: 70
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
Kubernetes 1.20でdockershimは非推奨になりました。
|
||||
|
||||
[Dockershim Deprecation FAQ](/blog/2020/12/02/dockershim-faq/)から、ほとんどのアプリがコンテナをホストするランタイムに直接依存しないことは既にご存知かもしれません。
|
||||
しかし、コンテナのメタデータやログ、メトリクスを収集するためにDockerに依存しているテレメトリーやセキュリティエージェントはまだ多く存在します。
|
||||
この文書では、これらの依存関係を検出する方法と、これらのエージェントを汎用ツールまたは代替ランタイムに移行する方法に関するリンクを集約しています。
|
||||
|
||||
## テレメトリーとセキュリティエージェント
|
||||
|
||||
Kubernetesクラスター上でエージェントを実行するには、いくつかの方法があります。エージェントはノード上で直接、またはDaemonSetとして実行することができます。
|
||||
|
||||
### テレメトリーエージェントがDockerに依存する理由とは？
|
||||
|
||||
歴史的には、KubernetesはDockerの上に構築されていました。
|
||||
Kubernetesはネットワークとスケジューリングを管理し、Dockerはコンテナをノードに配置して操作していました。
|
||||
そのため、KubernetesからはPod名などのスケジューリング関連のメタデータを、Dockerからはコンテナの状態情報を取得することができます。
|
||||
時が経つにつれ、コンテナを管理するためのランタイムも増えてきました。
|
||||
また、多くのランタイムにまたがるコンテナ状態情報の抽出を一般化するプロジェクトやKubernetesの機能もあります。
|
||||
|
||||
いくつかのエージェントはDockerツールに関連しています。
|
||||
エージェントは[`docker ps`](https://docs.docker.com/engine/reference/commandline/ps/)や[`docker top`](https://docs.docker.com/engine/reference/commandline/top/)といったコマンドを実行し、コンテナやプロセスの一覧を表示します。
|
||||
または[docker logs](https://docs.docker.com/engine/reference/commandline/logs/)を使えば、dockerログを購読することができます。
|
||||
|
||||
Dockerがコンテナランタイムとして非推奨になったため、これらのコマンドはもう使えません。
|
||||
|
||||
### Dockerに依存するDaemonSetの特定 {#identify-docker-dependency}
|
||||
|
||||
Podがノード上で動作している`dockerd`を呼び出したい場合、Podは以下のいずれかを行う必要があります。
|
||||
|
||||
- Dockerデーモンの特権ソケットがあるファイルシステムを{{< glossary_tooltip text="volume" term_id="volume" >}}のようにマウントする。
|
||||
|
||||
- Dockerデーモンの特権ソケットの特定のパスを直接ボリュームとしてマウントします。
|
||||
|
||||
例: COSイメージでは、DockerはそのUnixドメインソケットを`/var/run/docker.sock`に公開します。
|
||||
つまり、Pod仕様には`/var/run/docker.sock`の`hostPath`ボリュームマウントが含まれることになります。
|
||||
|
||||
以下は、Dockerソケットを直接マッピングしたマウントを持つPodを探すためのシェルスクリプトのサンプルです。
|
||||
|
||||
このスクリプトは、Podの名前空間と名前を出力します。
|
||||
|
||||
`grep '/var/run/docker.sock'`を削除して、他のマウントを確認することもできます。
|
||||
|
||||
```bash
|
||||
kubectl get pods --all-namespaces \
|
||||
-o=jsonpath='{range .items[*]}{"\n"}{.metadata.namespace}{":\t"}{.metadata.name}{":\t"}{range .spec.volumes[*]}{.hostPath.path}{", "}{end}{end}' \
|
||||
| sort \
|
||||
| grep '/var/run/docker.sock'
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
Podがホスト上のDockerにアクセスするための代替方法があります。
|
||||
例えば、フルパスの代わりに親ディレクトリ`/var/run`をマウントすることができます([この例](https://gist.github.com/itaysk/7bc3e56d69c4d72a549286d98fd557dd) のように)。
|
||||
上記のスクリプトは、最も一般的な使用方法のみを検出します。
|
||||
{{< /note >}}
|
||||
|
||||
### ノードエージェントからDockerの依存性を検出する
|
||||
|
||||
クラスターノードをカスタマイズし、セキュリティやテレメトリーのエージェントをノードに追加インストールする場合、エージェントのベンダーにDockerへの依存性があるかどうかを必ず確認してください。
|
||||
|
||||
### テレメトリーとセキュリティエージェントのベンダー
|
||||
|
||||
様々なテレメトリーおよびセキュリティエージェントベンダーのための移行指示の作業中バージョンを[Google doc](https://docs.google.com/document/d/1ZFi4uKit63ga5sxEiZblfb-c23lFhvy6RXVPikS8wf0/edit#)に保管しています。
|
||||
dockershimからの移行に関する最新の手順については、各ベンダーにお問い合わせください。
|
||||
|
|
@ -39,7 +39,7 @@ Add-ons 扩展了 Kubernetes 的功能。
|
|||
* [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin) is OVN based CNI controller plugin to provide cloud native based Service function chaining(SFC), Multiple OVN overlay networking, dynamic subnet creation, dynamic creation of virtual networks, VLAN Provider network, Direct provider network and pluggable with other Multi-network plugins, ideal for edge based cloud native workloads in Multi-cluster networking
|
||||
* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in (NCP) provides integration between VMware NSX-T and container orchestrators such as Kubernetes, as well as integration between NSX-T and container-based CaaS/PaaS platforms such as Pivotal Container Service (PKS) and OpenShift.
|
||||
* [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) is an SDN platform that provides policy-based networking between Kubernetes Pods and non-Kubernetes environments with visibility and security monitoring.
|
||||
* [Romana](http://romana.io) is a Layer 3 networking solution for pod networks that also supports the [NetworkPolicy API](/docs/concepts/services-networking/network-policies/). Kubeadm add-on installation details available [here](https://github.com/romana/romana/tree/master/containerize).
|
||||
* **Romana** is a Layer 3 networking solution for pod networks that also supports the [NetworkPolicy API](/docs/concepts/services-networking/network-policies/). Kubeadm add-on installation details available [here](https://github.com/romana/romana/tree/master/containerize).
|
||||
* [Weave Net](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/) provides networking and network policy, will carry on working on both sides of a network partition, and does not require an external database.
|
||||
-->
|
||||
## 网络和网络策略
|
||||
|
|
@ -79,8 +79,8 @@ Add-ons 扩展了 Kubernetes 的功能。
|
|||
CaaS / PaaS 平台（例如关键容器服务（PKS）和 OpenShift）之间的集成。
|
||||
* [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst)
|
||||
是一个 SDN 平台，可在 Kubernetes Pods 和非 Kubernetes 环境之间提供基于策略的联网，并具有可视化和安全监控。
|
||||
* [Romana](https://romana.io) 是一个 pod 网络的第三层解决方案，并支持[
|
||||
NetworkPolicy API](/zh/docs/concepts/services-networking/network-policies/)。
|
||||
* Romana 是一个 pod 网络的第三层解决方案，并支持
|
||||
[NetworkPolicy API](/zh/docs/concepts/services-networking/network-policies/)。
|
||||
Kubeadm add-on 安装细节可以在[这里](https://github.com/romana/romana/tree/master/containerize)找到。
|
||||
* [Weave Net](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/)
|
||||
提供在网络分组两端参与工作的网络和网络策略，并且不需要额外的数据库。
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load Diff
|
|
@ -69,7 +69,7 @@ resources `intel.com/foo` and `intel.com/bar`.
|
|||
`intel.com/foo` 和 `intel.com/bar` 的装箱行为
|
||||
|
||||
```yaml
|
||||
apiVersion: kubescheduler.config.k8s.io/v1beta1
|
||||
apiVersion: kubescheduler.config.k8s.io/v1beta3
|
||||
kind: KubeSchedulerConfiguration
|
||||
profiles:
|
||||
# ...
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ content_type: concept
|
|||
weight: 50
|
||||
---
|
||||
|
||||
<!--
|
||||
<!--
|
||||
title: Network Policies
|
||||
content_type: concept
|
||||
weight: 50
|
||||
|
|
@ -41,7 +41,7 @@ When defining a pod- or namespace- based NetworkPolicy, you use a {{< glossary_t
|
|||
|
||||
Meanwhile, when IP based NetworkPolicies are created, we define policies based on IP blocks (CIDR ranges).
|
||||
-->
|
||||
在定义基于 Pod 或名字空间的 NetworkPolicy 时，你会使用
|
||||
在定义基于 Pod 或名字空间的 NetworkPolicy 时，你会使用
|
||||
{{< glossary_tooltip text="选择算符" term_id="selector">}} 来设定哪些流量
|
||||
可以进入或离开与该算符匹配的 Pod。
|
||||
|
||||
|
|
@ -62,33 +62,50 @@ Network policies are implemented by the [network plugin](/docs/concepts/extend-k
|
|||
创建一个 NetworkPolicy 资源对象而没有控制器来使它生效的话，是没有任何作用的。
|
||||
|
||||
<!--
|
||||
## Isolated and Non-isolated Pods
|
||||
## The Two Sorts of Pod Isolation
|
||||
|
||||
By default, pods are non-isolated; they accept traffic from any source.
|
||||
|
||||
Pods become isolated by having a NetworkPolicy that selects them. Once there is any NetworkPolicy in a namespace selecting a particular pod, that pod will reject any connections that are not allowed by any NetworkPolicy. (Other pods in the namespace that are not selected by any NetworkPolicy will continue to accept all traffic.)
|
||||
|
||||
Network policies do not conflict; they are additive. If any policy or policies select a pod, the pod is restricted to what is allowed by the union of those policies' ingress/egress rules. Thus, order of evaluation does not affect the policy result.
|
||||
|
||||
For a network flow between two pods to be allowed, both the egress policy on the source pod and the ingress policy on the destination pod need to allow the traffic. If either the egress policy on the source, or the ingress policy on the destination denies the traffic, the traffic will be denied.
|
||||
There are two sorts of isolation for a pod: isolation for egress, and isolation for ingress. They concern what connections may be established. "Isolation" here is not absolute, rather it means "some restrictions apply". The alternative, "non-isolated for $direction", means that no restrictions apply in the stated direction. The two sorts of isolation (or not) are declared independently, and are both relevant for a connection from one pod to another.
|
||||
-->
|
||||
## 隔离和非隔离的 Pod {#isolated-and-non-isolated-pods}
|
||||
|
||||
默认情况下，Pod 是非隔离的，它们接受任何来源的流量。
|
||||
## Pod 隔离的两种类型
|
||||
|
||||
Pod 在被某 NetworkPolicy 选中时进入被隔离状态。
|
||||
一旦名字空间中有 NetworkPolicy 选择了特定的 Pod，该 Pod 会拒绝该 NetworkPolicy
|
||||
所不允许的连接。
|
||||
（名字空间下其他未被 NetworkPolicy 所选择的 Pod 会继续接受所有的流量）
|
||||
Pod 有两种隔离: 出口的隔离和入口的隔离。它们涉及到可以建立哪些连接。
|
||||
这里的“隔离”不是绝对的，而是意味着“有一些限制”。
|
||||
另外的，“非隔离方向”意味着在所述方向上没有限制。这两种隔离（或不隔离）是独立声明的，
|
||||
并且都与从一个 Pod 到另一个 Pod 的连接有关。
|
||||
|
||||
网络策略不会冲突，它们是累积的。
|
||||
如果任何一个或多个策略选择了一个 Pod, 则该 Pod 受限于这些策略的
|
||||
入站（Ingress）/出站（Egress）规则的并集。因此评估的顺序并不会影响策略的结果。
|
||||
<!--
|
||||
By default, a pod is non-isolated for egress; all outbound connections are allowed. A pod is isolated for egress if there is any NetworkPolicy that both selects the pod and has "Egress" in its `policyTypes`; we say that such a policy applies to the pod for egress. When a pod is isolated for egress, the only allowed connections from the pod are those allowed by the `egress` list of some NetworkPolicy that applies to the pod for egress. The effects of those `egress` lists combine additively.
|
||||
-->
|
||||
|
||||
为了允许两个 Pods 之间的网络数据流，源端 Pod 上的出站（Egress）规则和
|
||||
目标端 Pod 上的入站（Ingress）规则都需要允许该流量。
|
||||
如果源端的出站（Egress）规则或目标端的入站（Ingress）规则拒绝该流量，
|
||||
则流量将被拒绝。
|
||||
默认情况下，一个 Pod 的出口是非隔离的，即所有外向连接都是被允许的。如果有任何的 NetworkPolicy
|
||||
选择该 Pod 并在其 `policyTypes` 中包含 “Egress”，则该 Pod 是出口隔离的，
|
||||
我们称这样的策略适用于该 Pod 的出口。当一个 Pod 的出口被隔离时，
|
||||
唯一允许的来自 Pod 的连接是适用于出口的 Pod 的某个 NetworkPolicy 的 `egress` 列表所允许的连接。
|
||||
这些 `egress` 列表的效果是相加的。
|
||||
|
||||
<!--
|
||||
By default, a pod is non-isolated for ingress; all inbound connections are allowed. A pod is isolated for ingress if there is any NetworkPolicy that both selects the pod and has "Ingress" in its `policyTypes`; we say that such a policy applies to the pod for ingress. When a pod is isolated for ingress, the only allowed connections into the pod are those from the pod's node and those allowed by the `ingress` list of some NetworkPolicy that applies to the pod for ingress. The effects of those `ingress` lists combine additively.
|
||||
-->
|
||||
|
||||
默认情况下，一个 Pod 对入口是非隔离的，即所有入站连接都是被允许的。如果有任何的 NetworkPolicy
|
||||
选择该 Pod 并在其 `policyTypes` 中包含 “Ingress”，则该 Pod 被隔离入口，
|
||||
我们称这种策略适用于该 Pod 的入口。 当一个 Pod 的入口被隔离时，唯一允许进入该 Pod
|
||||
的连接是来自该 Pod 节点的连接和适用于入口的 Pod 的某个 NetworkPolicy 的 `ingress`
|
||||
列表所允许的连接。这些 `ingress` 列表的效果是相加的。
|
||||
|
||||
<!--
|
||||
Network policies do not conflict; they are additive. If any policy or policies apply to a given pod for a given direction, the connections allowed in that direction from that pod is the union of what the applicable policies allow. Thus, order of evaluation does not affect the policy result.
|
||||
|
||||
For a connection from a source pod to a destination pod to be allowed, both the egress policy on the source pod and the ingress policy on the destination pod need to allow the connection. If either side does not allow the connection, it will not happen.
|
||||
-->
|
||||
|
||||
网络策略是相加的，所以不会产生冲突。如果策略适用于 Pod 某一特定方向的流量，
|
||||
Pod 在对应方向所允许的连接是适用的网络策略所允许的集合。
|
||||
因此，评估的顺序不影响策略的结果。
|
||||
|
||||
要允许从源 Pod 到目的 Pod 的连接，源 Pod 的出口策略和目的 Pod 的入口策略都需要允许连接。
|
||||
如果任何一方不允许连接，建立连接将会失败。
|
||||
|
||||
<!--
|
||||
## The NetworkPolicy resource {#networkpolicy-resource}
|
||||
|
|
@ -141,7 +158,7 @@ spec:
|
|||
port: 5978
|
||||
```
|
||||
|
||||
<!--
|
||||
<!--
|
||||
POSTing this to the API server for your cluster will have no effect unless your chosen networking solution supports network policy.
|
||||
-->
|
||||
{{< note >}}
|
||||
|
|
@ -262,7 +279,7 @@ __namespaceSelector__ *和* __podSelector__： 一个指定 `namespaceSelector`
|
|||
...
|
||||
```
|
||||
|
||||
<!--
|
||||
<!--
|
||||
contains a single `from` element allowing connections from Pods with the label `role=client` in namespaces with the label `user=alice`. But *this* policy:
|
||||
-->
|
||||
在 `from` 数组中仅包含一个元素，只允许来自标有 `role=client` 的 Pod 且
|
||||
|
|
@ -339,8 +356,8 @@ You can create a "default" isolation policy for a namespace by creating a Networ
|
|||
-->
|
||||
### 默认拒绝所有入站流量
|
||||
|
||||
你可以通过创建选择所有容器但不允许任何进入这些容器的入站流量的 NetworkPolicy
|
||||
来为名字空间创建 "default" 隔离策略。
|
||||
你可以通过创建选择所有容器但不允许任何进入这些容器的入站流量的 NetworkPolicy
|
||||
来为名字空间创建 “default” 隔离策略。
|
||||
|
||||
{{< codenew file="service/networking/network-policy-default-deny-ingress.yaml" >}}
|
||||
|
||||
|
|
@ -369,8 +386,8 @@ You can create a "default" egress isolation policy for a namespace by creating a
|
|||
-->
|
||||
### 默认拒绝所有出站流量
|
||||
|
||||
你可以通过创建选择所有容器但不允许来自这些容器的任何出站流量的 NetworkPolicy
|
||||
来为名字空间创建 "default" egress 隔离策略。
|
||||
你可以通过创建选择所有容器但不允许来自这些容器的任何出站流量的 NetworkPolicy
|
||||
来为名字空间创建 “default” 隔离策略。
|
||||
|
||||
{{< codenew file="service/networking/network-policy-default-deny-egress.yaml" >}}
|
||||
|
||||
|
|
@ -429,7 +446,7 @@ When the feature gate is enabled, you can set the `protocol` field of a NetworkP
|
|||
启用该特性门控后，用户可以将 NetworkPolicy 的 `protocol` 字段设置为 `SCTP`。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
<!--
|
||||
You must be using a {{< glossary_tooltip text="CNI" term_id="cni" >}} plugin that supports SCTP protocol NetworkPolicies.
|
||||
-->
|
||||
你必须使用支持 SCTP 协议网络策略的 {{< glossary_tooltip text="CNI" term_id="cni" >}} 插件。
|
||||
|
|
@ -474,17 +491,17 @@ spec:
|
|||
```
|
||||
|
||||
<!--
|
||||
The above rule allows any Pod with label `db` on the namespace `default` to communicate
|
||||
with any IP within the range `10.0.0.0/24` over TCP, provided that the target
|
||||
The above rule allows any Pod with label `role=db` on the namespace `default` to communicate
|
||||
with any IP within the range `10.0.0.0/24` over TCP, provided that the target
|
||||
port is between the range 32000 and 32768.
|
||||
-->
|
||||
上面的规则允许名字空间 `default` 中所有带有标签 `db` 的 Pod 使用 TCP 协议
|
||||
上面的规则允许名字空间 `default` 中所有带有标签 `role=db` 的 Pod 使用 TCP 协议
|
||||
与 `10.0.0.0/24` 范围内的 IP 通信，只要目标端口介于 32000 和 32768 之间就可以。
|
||||
|
||||
<!--
|
||||
The following restrictions apply when using this field:
|
||||
* As a beta feature, this is enabled by default. To disable the `endPort` field at a cluster level, you (or your cluster administrator) need to disable the `NetworkPolicyEndPort` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for the API server with `-feature-gates=NetworkPolicyEndPort=false,…`.
|
||||
* The `endPort` field must be equal than or greater to the `port` field.
|
||||
* The `endPort` field must be equal to or greater than the `port` field.
|
||||
* `endPort` can only be defined if `port` is also defined.
|
||||
* Both ports must be numeric.
|
||||
-->
|
||||
|
|
@ -493,7 +510,7 @@ The following restrictions apply when using this field:
|
|||
* 作为一种 Beta 阶段的特性，端口范围设定默认是被启用的。要在整个集群
|
||||
范围内禁止使用 `endPort` 字段，你（或者你的集群管理员）需要为 API
|
||||
服务器设置 `-feature-gates=NetworkPolicyEndPort=false,...` 以禁用
|
||||
`NetworkPolicyEndPort`
|
||||
`NetworkPolicyEndPort`
|
||||
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。
|
||||
* `endPort` 字段必须等于或者大于 `port` 字段的值。
|
||||
* 两个字段的设置值都只能是数字。
|
||||
|
|
@ -502,7 +519,7 @@ The following restrictions apply when using this field:
|
|||
<!--
|
||||
Your cluster must be using a {{< glossary_tooltip text="CNI" term_id="cni" >}} plugin that
|
||||
supports the `endPort` field in NetworkPolicy specifications.
|
||||
If your [network plugin](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
|
||||
If your [network plugin](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
|
||||
does not support the `endPort` field and you specify a NetworkPolicy with that,
|
||||
the policy will be applied only for the single `port` field.
|
||||
-->
|
||||
|
|
@ -518,7 +535,7 @@ the policy will be applied only for the single `port` field.
|
|||
-->
|
||||
## 基于名字指向某名字空间 {#targeting-a-namespace-by-its-name}
|
||||
|
||||
{{< feature-state state="beta" for_k8s_version="1.21" >}}
|
||||
{{< feature-state for_k8s_version="1.22" state="stable" >}}
|
||||
|
||||
<!--
|
||||
The Kubernetes control plane sets an immutable label `kubernetes.io/metadata.name` on all
|
||||
|
|
@ -592,4 +609,3 @@ As of Kubernetes {{< skew latestVersion >}}, the following functionality does no
|
|||
演练了解更多示例；
|
||||
- 有关 NetworkPolicy 资源所支持的常见场景的更多信息，请参见
|
||||
[此指南](https://github.com/ahmetb/kubernetes-network-policy-recipes)。
|
||||
|
||||
|
|
|
|||
|
|
@ -268,11 +268,22 @@ Kubernetes 网站使用 Hugo 作为其 Web 框架。网站的 Hugo 配置位于
|
|||
[languages.de]
|
||||
title = "Kubernetes"
|
||||
description = "Produktionsreife Container-Verwaltung"
|
||||
languageName = "Deutsch"
|
||||
languageName = "Deutsch (German)"
|
||||
languageNameLatinScript = "German"
|
||||
contentDir = "content/de"
|
||||
weight = 3
|
||||
weight = 8
|
||||
```
|
||||
|
||||
<!--
|
||||
The value for `languageName` will be listed in language selection bar. Assign "language name in native script (language name in latin script)" to `languageName`, for example, `languageName = "한국어 (Korean)"`. `languageNameLatinScript` can be used to access the language name in latin script and use it in the theme. Assign "language name in latin script" to `languageNameLatinScript`, for example, `languageNameLatinScript ="Korean"`.
|
||||
-->
|
||||
`languageName` 的值将列在语言选择栏中。
|
||||
将 `languageName` 赋值为“本地脚本中的语言名称（拉丁脚本中的语言名称）”。
|
||||
例如，`languageName = "한국어 (Korean)"`。
|
||||
`languageNameLatinScript` 可用于访问拉丁脚本中的语言名称并在主题中使用。
|
||||
将 `languageNameLatinScript` 赋值为“拉丁脚本中的语言名称”。
|
||||
例如，`languageNameLatinScript ="Korean"`。
|
||||
|
||||
<!--
|
||||
When assigning a `weight` parameter for your block, find the language block with the highest weight and add 1 to that value.
|
||||
|
||||
|
|
|
|||
|
|
@ -1333,7 +1333,7 @@ This admission controller will deny any Pod that attempts to set certain escalat
|
|||
fields, as shown in the
|
||||
[Configure a Security Context for a Pod or Container](/docs/tasks/configure-pod-container/security-context/)
|
||||
task.
|
||||
If you don't use [Pod Security admission]((/docs/concepts/security/pod-security-admission/),
|
||||
If you don't use [Pod Security admission](/docs/concepts/security/pod-security-admission/),
|
||||
[PodSecurityPolicies](/docs/concepts/security/pod-security-policy/), nor any external enforcement mechanism,
|
||||
then you could use this admission controller to restrict the set of values a security context can take.
|
||||
|
||||
|
|
|
|||
|
|
@ -2097,6 +2097,7 @@ This is not a recommended policy.
|
|||
下面的策略允许 **所有** 服务帐户充当集群管理员。
|
||||
容器中运行的所有应用程序都会自动收到服务帐户的凭据，可以对 API 执行任何操作，
|
||||
包括查看 Secrets 和修改权限。这一策略是不被推荐的。
|
||||
{{< /warning >}}
|
||||
|
||||
```shell
|
||||
kubectl create clusterrolebinding permissive-binding \
|
||||
|
|
@ -2105,12 +2106,10 @@ kubectl create clusterrolebinding permissive-binding \
|
|||
--user=kubelet \
|
||||
--group=system:serviceaccounts
|
||||
```
|
||||
{{< /warning >}}
|
||||
|
||||
<!--
|
||||
After you have transitioned to use RBAC, you should adjust the access controls
|
||||
for your cluster to ensure that these meet your information security needs.
|
||||
-->
|
||||
在你完成到 RBAC 的迁移后，应该调整集群的访问控制，确保相关的策略满足你的
|
||||
信息安全需求。
|
||||
在你完成到 RBAC 的迁移后，应该调整集群的访问控制，确保相关的策略满足你的信息安全需求。
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: 保护集群安全
|
||||
title: 保护集群
|
||||
content_type: task
|
||||
---
|
||||
<!--
|
||||
|
|
@ -104,10 +104,11 @@ Kubernetes 提供了一组可直接使用的角色，这些角色根据客户可
|
|||
<!--
|
||||
As with authentication, simple and broad roles may be appropriate for smaller clusters, but as
|
||||
more users interact with the cluster, it may become necessary to separate teams into separate
|
||||
namespaces with more limited roles.
|
||||
{{< glossary_tooltip text="namespaces" term_id="namespace" >}} with more limited roles.
|
||||
-->
|
||||
与身份验证一样，简单而广泛的角色可能适合于较小的集群，但是随着更多的用户与集群交互，
|
||||
可能需要将团队划分到有更多角色限制的、单独的名字空间中去。
|
||||
可能需要将团队划分到有更多角色限制的、
|
||||
单独的{{< glossary_tooltip text="名字空间" term_id="namespace" >}}中去。
|
||||
|
||||
<!--
|
||||
With authorization, it is important to understand how updates on one object may cause actions in
|
||||
|
|
@ -188,30 +189,37 @@ reserved resources like memory, or to provide default limits when none are speci
|
|||
A pod definition contains a [security context](/docs/tasks/configure-pod-container/security-context/)
|
||||
that allows it to request access to run as a specific Linux user on a node (like root),
|
||||
access to run privileged or access the host network, and other controls that would otherwise
|
||||
allow it to run unfettered on a hosting node. [Pod security policies](/docs/concepts/policy/pod-security-policy/)
|
||||
can limit which users or service accounts can provide dangerous security context settings. For example, pod security policies can limit volume mounts, especially `hostPath`, which are aspects of a pod that should be controlled.
|
||||
allow it to run unfettered on a hosting node.
|
||||
|
||||
You can configure [Pod security admission](/docs/concepts/security/pod-security-admission/)
|
||||
to enforce use of a particular [Pod Security Standard](/docs/concepts/security/pod-security-standards/)
|
||||
in a {{< glossary_tooltip text="namespace" term_id="namespace" >}}, or to detect breaches.
|
||||
-->
|
||||
### 控制容器运行的特权
|
||||
|
||||
Pod 定义包含了一个[安全上下文](/zh/docs/tasks/configure-pod-container/security-context/)，
|
||||
用于描述一些访问请求，如以某个节点上的特定 Linux 用户（如 root）身份运行，
|
||||
以特权形式运行，访问主机网络，以及一些在宿主节点上不受约束地运行的其它控制权限等等。
|
||||
[Pod 安全策略](/zh/docs/concepts/policy/pod-security-policy/)
|
||||
可以限制哪些用户或服务帐户可以提供危险的安全上下文设置。
|
||||
例如，Pod 的安全策略可以限制卷挂载，尤其是 `hostpath`，这些都是 Pod 应该被控制的一些方面。
|
||||
|
||||
你可以配置 [Pod 安全准入](/zh/docs/concepts/security/pod-security-admission/)来在某个
|
||||
{{< glossary_tooltip text="名字空间" term_id="namespace" >}}中
|
||||
强制实施特定的
|
||||
[Pod 安全标准（Pod Security Standard）](/zh/docs/concepts/security/pod-security-standards/)，
|
||||
或者检查安全上的缺陷。
|
||||
|
||||
<!--
|
||||
Generally, most application workloads need limited access to host resources so they can
|
||||
successfully run as a root process (uid 0) without access to host information. However,
|
||||
considering the privileges associated with the root user, you should write application
|
||||
containers to run as a non-root user. Similarly, administrators who wish to prevent
|
||||
client applications from escaping their containers should use a restrictive pod security
|
||||
policy.
|
||||
client applications from escaping their containers should apply the **Baseline**
|
||||
or **Restricted** Pod Security Standard.
|
||||
-->
|
||||
一般来说，大多数应用程序需要对主机资源的有限制的访问，
|
||||
这样它们可以在不访问主机信息的情况下，成功地以 root 账号（UID 0）运行。
|
||||
但是，考虑到与 root 用户相关的特权，在编写应用程序容器时，你应该使用非 root 用户运行。
|
||||
类似地，希望阻止客户端应用程序从其容器中逃逸的管理员，应该使用限制性较强的 Pod 安全策略。
|
||||
类似地，希望阻止客户端应用程序从其容器中逃逸的管理员，应该应用 **Baseline**
|
||||
或 **Restricted** Pod 安全标准。
|
||||
|
||||
<!--
|
||||
### Restricting network access
|
||||
|
|
@ -388,7 +396,7 @@ restrict the integration to functioning in a single namespace if possible.
|
|||
Components that create pods may also be unexpectedly powerful if they can do so inside namespaces
|
||||
like the `kube-system` namespace, because those pods can gain access to service account secrets
|
||||
or run with elevated permissions if those service accounts are granted access to permissive
|
||||
[pod security policies](/docs/concepts/policy/pod-security-policy/).
|
||||
[PodSecurityPolicies](/docs/concepts/security/pod-security-policy/).
|
||||
-->
|
||||
### 在启用第三方集成之前，请先审查它们
|
||||
|
||||
|
|
@ -400,9 +408,27 @@ or run with elevated permissions if those service accounts are granted access to
|
|||
|
||||
如果执行 Pod 创建操作的组件能够在 `kube-system` 这类名字空间中创建 Pod，
|
||||
则这类组件也可能获得意外的权限，因为这些 Pod 可以访问服务账户的 Secret，
|
||||
或者，如果对应服务帐户被授权访问宽松的 [Pod 安全策略](/zh/docs/concepts/policy/pod-security-policy/)，
|
||||
或者，如果对应服务帐户被授权访问宽松的
|
||||
[PodSecurityPolicy](/zh/docs/concepts/policy/pod-security-policy/)，
|
||||
它们就能以较高的权限运行。
|
||||
|
||||
<!--
|
||||
If you use [Pod Security admission](/docs/concepts/security/pod-security-admission/) and allow
|
||||
any component to create Pods within a namespace that permits privileged Pods, those Pods may
|
||||
be able to escape their containers and use this widened access to elevate their privileges.
|
||||
-->
|
||||
如果你使用 [Pod 安全准入](/zh/docs/concepts/security/pod-security-admission/)，
|
||||
并且允许任何组件在一个允许执行特权 Pod 的名字空间中创建 Pod，这些 Pod
|
||||
就可能从所在的容器中逃逸，利用被拓宽的访问权限来实现特权提升。
|
||||
|
||||
<!--
|
||||
You should not allow untrusted components to create Pods in any system namespace (those with
|
||||
names that start with `kube-`) nor in any namespace where that access grant allows the possibility
|
||||
of privilege escalation.
|
||||
-->
|
||||
你不应该允许不可信的组件在任何系统名字空间（名字以 `kube-` 开头）中创建 Pod，
|
||||
也不允许它们在访问权限授权可被利用来提升特权的名字空间中创建 Pod。
|
||||
|
||||
<!--
|
||||
### Encrypt secrets at rest
|
||||
|
||||
|
|
|
|||
|
|
@ -11,11 +11,12 @@ content_type: task
|
|||
<!--overview-->
|
||||
|
||||
<!--
|
||||
This page shows you how to specify the type of [cascading deletion](/docs/concepts/workloads/controllers/garbage-collection/#cascading-deletion)
|
||||
This page shows you how to specify the type of
|
||||
[cascading deletion](/docs/concepts/architecture/garbage-collection/#cascading-deletion)
|
||||
to use in your cluster during {{<glossary_tooltip text="garbage collection" term_id="garbage-collection">}}.
|
||||
-->
|
||||
本页面向你展示如何设置在你的集群执行{{<glossary_tooltip text="垃圾收集" term_id="garbage-collection">}}
|
||||
时要使用的[级联删除](/zh/docs/concepts/workloads/controllers/garbage-collection/#cascading-deletion)
|
||||
时要使用的[级联删除](/zh/docs/concepts/architecture/garbage-collection/#cascading-deletion)
|
||||
类型。
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
|
@ -64,14 +65,14 @@ apiVersion: v1
|
|||
<!--
|
||||
## Use foreground cascading deletion {#use-foreground-cascading-deletion}
|
||||
|
||||
By default, Kubernetes uses [background cascading deletion](/docs/concepts/workloads/controllers/garbage-collection/#background-deletion)
|
||||
By default, Kubernetes uses [background cascading deletion](/docs/concepts/architecture/garbage-collection/#background-deletion)
|
||||
to delete dependents of an object. You can switch to foreground cascading deletion
|
||||
using either `kubectl` or the Kubernetes API, depending on the Kubernetes
|
||||
version your cluster runs. {{<version-check>}}
|
||||
-->
|
||||
## 使用前台级联删除 {#use-foreground-cascading-deletion}
|
||||
|
||||
默认情况下，Kubernetes 使用[后台级联删除](/zh/docs/concepts/workloads/controllers/garbage-collection/#background-deletion)
|
||||
默认情况下，Kubernetes 使用[后台级联删除](/zh/docs/concepts/architecture/garbage-collection/#background-deletion)
|
||||
以删除依赖某对象的其他对象。取决于你的集群所运行的 Kubernetes 版本，
|
||||
你可以使用 `kubectl` 或者 Kubernetes API 来切换到前台级联删除。
|
||||
{{<version-check>}}
|
||||
|
|
@ -188,7 +189,7 @@ For details, read the [documentation for your Kubernetes version](/docs/home/sup
|
|||
输出中包含 `foregroundDeletion` {{<glossary_tooltip text="finalizer" term_id="finalizer">}}，
|
||||
类似这样：
|
||||
|
||||
```none
|
||||
```
|
||||
"kind": "Deployment",
|
||||
"apiVersion": "apps/v1",
|
||||
"metadata": {
|
||||
|
|
@ -528,5 +529,5 @@ kubectl get pods -l app=nginx
|
|||
-->
|
||||
* 了解 Kubernetes 中的[属主与依赖](/zh/docs/concepts/overview/working-with-objects/owners-dependents/)
|
||||
* 了解 Kubernetes [finalizers](/zh/docs/concepts/overview/working-with-objects/finalizers/)
|
||||
* 了解[垃圾收集](/zh/docs/concepts/workloads/controllers/garbage-collection/).
|
||||
* 了解[垃圾收集](/zh/docs/concepts/architecture/garbage-collection/).
|
||||
|
||||
|
|
|
|||
|
|
@ -14,12 +14,12 @@ where an application is running, but unable to make progress. Restarting a
|
|||
container in such a state can help to make the application more available
|
||||
despite bugs.
|
||||
-->
|
||||
这篇文章介绍如何给容器配置存活、就绪和启动探测器。
|
||||
这篇文章介绍如何给容器配置活跃（Liveness）、就绪（Readiness）和启动（Startup）探测器。
|
||||
|
||||
[kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/)
|
||||
使用存活探测器来知道什么时候要重启容器。
|
||||
例如，存活探测器可以捕捉到死锁（应用程序在运行，但是无法继续执行后面的步骤）。
|
||||
这样的情况下重启容器有助于让应用程序在有问题的情况下更可用。
|
||||
使用存活探测器来确定什么时候要重启容器。
|
||||
例如，存活探测器可以探测到应用死锁（应用程序在运行，但是无法继续执行后面的步骤）情况。
|
||||
重启这种状态下的容器有助于提高应用的可用性，即使其中存在缺陷。
|
||||
|
||||
<!--
|
||||
The kubelet uses readiness probes to know when a container is ready to start
|
||||
|
|
@ -33,15 +33,15 @@ it succeeds, making sure those probes don't interfere with the application start
|
|||
This can be used to adopt liveness checks on slow starting containers, avoiding them
|
||||
getting killed by the kubelet before they are up and running.
|
||||
-->
|
||||
kubelet 使用就绪探测器可以知道容器什么时候准备好了并可以开始接受请求流量， 当一个 Pod
|
||||
内的所有容器都准备好了，才能把这个 Pod 看作就绪了。
|
||||
kubelet 使用就绪探测器可以知道容器何时准备好接受请求流量，当一个 Pod
|
||||
内的所有容器都就绪时，才能认为该 Pod 就绪。
|
||||
这种信号的一个用途就是控制哪个 Pod 作为 Service 的后端。
|
||||
在 Pod 还没有准备好的时候，会从 Service 的负载均衡器中被剔除的。
|
||||
若 Pod 尚未就绪，会被从 Service 的负载均衡器中剔除。
|
||||
|
||||
kubelet 使用启动探测器可以知道应用程序容器什么时候启动了。
|
||||
如果配置了这类探测器，就可以控制容器在启动成功后再进行存活性和就绪检查，
|
||||
确保这些存活、就绪探测器不会影响应用程序的启动。
|
||||
这可以用于对慢启动容器进行存活性检测，避免它们在启动运行之前就被杀掉。
|
||||
kubelet 使用启动探测器来了解应用容器何时启动。
|
||||
如果配置了这类探测器，你就可以控制容器在启动成功后再进行存活性和就绪态检查，
|
||||
确保这些存活、就绪探测器不会影响应用的启动。
|
||||
启动探测器可以用于对慢启动容器进行存活性检测，避免它们在启动运行之前就被杀掉。
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
|
@ -61,10 +61,10 @@ In this exercise, you create a Pod that runs a container based on the
|
|||
-->
|
||||
## 定义存活命令 {#define-a-liveness-command}
|
||||
|
||||
许多长时间运行的应用程序最终会过渡到断开的状态，除非重新启动，否则无法恢复。
|
||||
Kubernetes 提供了存活探测器来发现并补救这种情况。
|
||||
许多长时间运行的应用最终会进入损坏状态，除非重新启动，否则无法被恢复。
|
||||
Kubernetes 提供了存活探测器来发现并处理这种情况。
|
||||
|
||||
在这篇练习中，你会创建一个 Pod，其中运行一个基于 `k8s.gcr.io/busybox` 镜像的容器。
|
||||
在本练习中，你会创建一个 Pod，其中运行一个基于 `k8s.gcr.io/busybox` 镜像的容器。
|
||||
下面是这个 Pod 的配置文件。
|
||||
|
||||
{{< codenew file="pods/probe/exec-liveness.yaml" >}}
|
||||
|
|
@ -81,7 +81,7 @@ and restarts it.
|
|||
|
||||
When the container starts, it executes this command:
|
||||
-->
|
||||
在这个配置文件中，可以看到 Pod 中只有一个容器。
|
||||
在这个配置文件中，可以看到 Pod 中只有一个 `Container`。
|
||||
`periodSeconds` 字段指定了 kubelet 应该每 5 秒执行一次存活探测。
|
||||
`initialDelaySeconds` 字段告诉 kubelet 在执行第一次探测前应该等待 5 秒。
|
||||
kubelet 在容器内执行命令 `cat /tmp/healthy` 来进行探测。
|
||||
|
|
@ -101,7 +101,7 @@ code. After 30 seconds, `cat /tmp/healthy` returns a failure code.
|
|||
|
||||
Create the Pod:
|
||||
-->
|
||||
这个容器生命的前 30 秒， `/tmp/healthy` 文件是存在的。
|
||||
这个容器生命的前 30 秒，`/tmp/healthy` 文件是存在的。
|
||||
所以在这最开始的 30 秒内，执行命令 `cat /tmp/healthy` 会返回成功代码。
|
||||
30 秒之后，执行命令 `cat /tmp/healthy` 就会返回失败代码。
|
||||
|
||||
|
|
@ -164,7 +164,7 @@ FirstSeen LastSeen Count From SubobjectPath Type
|
|||
<!--
|
||||
Wait another 30 seconds, and verify that the Container has been restarted:
|
||||
-->
|
||||
再等另外 30 秒，检查看这个容器被重启了：
|
||||
再等 30 秒，确认这个容器被重启了：
|
||||
|
||||
```shell
|
||||
kubectl get pod liveness-exec
|
||||
|
|
@ -205,12 +205,12 @@ returns a success code, the kubelet considers the container to be alive and
|
|||
healthy. If the handler returns a failure code, the kubelet kills the container
|
||||
and restarts it.
|
||||
-->
|
||||
在这个配置文件中，可以看到 Pod 也只有一个容器。
|
||||
在这个配置文件中，你可以看到 Pod 也只有一个容器。
|
||||
`periodSeconds` 字段指定了 kubelet 每隔 3 秒执行一次存活探测。
|
||||
`initialDelaySeconds` 字段告诉 kubelet 在执行第一次探测前应该等待 3 秒。
|
||||
kubelet 会向容器内运行的服务（服务会监听 8080 端口）发送一个 HTTP GET 请求来执行探测。
|
||||
kubelet 会向容器内运行的服务（服务在监听 8080 端口）发送一个 HTTP GET 请求来执行探测。
|
||||
如果服务器上 `/healthz` 路径下的处理程序返回成功代码，则 kubelet 认为容器是健康存活的。
|
||||
如果处理程序返回失败代码，则 kubelet 会杀死这个容器并且重新启动它。
|
||||
如果处理程序返回失败代码，则 kubelet 会杀死这个容器并将其重启。
|
||||
|
||||
<!--
|
||||
Any code greater than or equal to 200 and less than 400 indicates success. Any
|
||||
|
|
@ -222,11 +222,12 @@ You can see the source code for the server in
|
|||
For the first 10 seconds that the container is alive, the `/healthz` handler
|
||||
returns a status of 200. After that, the handler returns a status of 500.
|
||||
-->
|
||||
任何大于或等于 200 并且小于 400 的返回代码标示成功，其它返回代码都标示失败。
|
||||
返回大于或等于 200 并且小于 400 的任何代码都标示成功，其它返回代码都标示失败。
|
||||
|
||||
可以在这里看服务的源码 [server.go](https://github.com/kubernetes/kubernetes/blob/master/test/images/agnhost/liveness/server.go)。
|
||||
|
||||
容器存活的最开始 10 秒中，`/healthz` 处理程序返回一个 200 的状态码。之后处理程序返回 500 的状态码。
|
||||
你可以访问 [server.go](https://github.com/kubernetes/kubernetes/blob/master/test/images/agnhost/liveness/server.go)。
|
||||
阅读服务的源码。
|
||||
容器存活期间的最开始 10 秒中，`/healthz` 处理程序返回 200 的状态码。
|
||||
之后处理程序返回 500 的状态码。
|
||||
|
||||
```go
|
||||
http.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) {
|
||||
|
|
@ -261,7 +262,7 @@ kubectl apply -f https://k8s.io/examples/pods/probe/http-liveness.yaml
|
|||
After 10 seconds, view Pod events to verify that liveness probes have failed and
|
||||
the container has been restarted:
|
||||
-->
|
||||
10 秒之后，通过看 Pod 事件来检测存活探测器已经失败了并且容器被重新启动了。
|
||||
10 秒之后，通过查看 Pod 事件来确认活跃探测器已经失败，并且容器被重新启动了。
|
||||
|
||||
```shell
|
||||
kubectl describe pod liveness-http
|
||||
|
|
@ -274,7 +275,7 @@ the HTTP liveness probe uses that proxy.
|
|||
In releases after v1.13, local HTTP proxy environment variable settings do not
|
||||
affect the HTTP liveness probe.
|
||||
-->
|
||||
在 1.13（包括 1.13版本）之前的版本中，如果在 Pod 运行的节点上设置了环境变量
|
||||
在 1.13 之前（包括 1.13）的版本中，如果在 Pod 运行的节点上设置了环境变量
|
||||
`http_proxy`（或者 `HTTP_PROXY`），HTTP 的存活探测会使用这个代理。
|
||||
在 1.13 之后的版本中，设置本地的 HTTP 代理环境变量不会影响 HTTP 的存活探测。
|
||||
|
||||
|
|
@ -289,7 +290,7 @@ can't it is considered a failure.
|
|||
## 定义 TCP 的存活探测 {#define-a-TCP-liveness-probe}
|
||||
|
||||
第三种类型的存活探测是使用 TCP 套接字。
|
||||
通过配置，kubelet 会尝试在指定端口和容器建立套接字链接。
|
||||
使用这种配置时，kubelet 会尝试在指定端口和容器建立套接字链接。
|
||||
如果能建立连接，这个容器就被看作是健康的，如果不能则这个容器就被看作是有问题的。
|
||||
|
||||
{{< codenew file="pods/probe/tcp-liveness-readiness.yaml" >}}
|
||||
|
|
@ -312,13 +313,13 @@ To try the TCP liveness check, create a Pod:
|
|||
-->
|
||||
如你所见，TCP 检测的配置和 HTTP 检测非常相似。
|
||||
下面这个例子同时使用就绪和存活探测器。kubelet 会在容器启动 5 秒后发送第一个就绪探测。
|
||||
这会尝试连接 `goproxy` 容器的 8080 端口。
|
||||
探测器会尝试连接 `goproxy` 容器的 8080 端口。
|
||||
如果探测成功，这个 Pod 会被标记为就绪状态，kubelet 将继续每隔 10 秒运行一次检测。
|
||||
|
||||
除了就绪探测，这个配置包括了一个存活探测。
|
||||
kubelet 会在容器启动 15 秒后进行第一次存活探测。
|
||||
与就绪探测类似，会尝试连接 `goproxy` 容器的 8080 端口。
|
||||
如果存活探测失败，这个容器会被重新启动。
|
||||
与就绪探测类似，活跃探测器会尝试连接 `goproxy` 容器的 8080 端口。
|
||||
如果存活探测失败，容器会被重新启动。
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/pods/probe/tcp-liveness-readiness.yaml
|
||||
|
|
@ -333,6 +334,98 @@ After 15 seconds, view Pod events to verify that liveness probes:
|
|||
kubectl describe pod goproxy
|
||||
```
|
||||
|
||||
<!--
|
||||
## Define a gRPC liveness probe
|
||||
-->
|
||||
## 定义 gRPC 活跃探测器
|
||||
|
||||
{{< feature-state for_k8s_version="v1.23" state="alpha" >}}
|
||||
|
||||
<!--
|
||||
If your application implements [gRPC Health Checking Protocol](https://github.com/grpc/grpc/blob/master/doc/health-checking.md),
|
||||
kubelet can be configured to use it for application liveness checks.
|
||||
You must enable the `GRPCContainerProbe`
|
||||
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
in order to configure checks that rely on gRPC.
|
||||
|
||||
Here is an example manifest:
|
||||
-->
|
||||
如果你的应用实现了 [gRPC 健康检查协议](https://github.com/grpc/grpc/blob/master/doc/health-checking.md)，
|
||||
kubelet 可以配置为使用该协议来执行应用活跃性检查。
|
||||
你必须启用 `GRPCContainerProbe`
|
||||
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
才能配置依赖于 gRPC 的检查机制。
|
||||
|
||||
下面是一个示例清单：
|
||||
|
||||
{{< codenew file="pods/probe/grpc-liveness.yaml">}}
|
||||
|
||||
<!--
|
||||
To use a gRPC probe, `port` must be configured. If the health endpoint is configured
|
||||
on a non-default service, you must also specify the `service`.
|
||||
-->
|
||||
要使用 gRPC 探测器，必须配置 `port` 属性。如果健康状态端点配置在非默认服务之上，
|
||||
你还必须设置 `service` 属性。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
Unlike HTTP and TCP probes, named ports cannot be used and custom host cannot be configured.
|
||||
-->
|
||||
与 HTTP 和 TCP 探测器不同，gRPC 探测不能使用命名端口或定制主机。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
Configuration problems (for example: incorrect port and service, unimplemented health checking protocol)
|
||||
are considered a probe failure, similar to HTTP and TCP probes.
|
||||
|
||||
To try the gRPC liveness check, create a Pod using the command below.
|
||||
In the example below, the etcd pod is configured to use gRPC liveness probe.
|
||||
-->
|
||||
配置问题（例如：错误的 `port` 和 `service`、未实现健康检查协议）
|
||||
都被认作是探测失败，这一点与 HTTP 和 TCP 探测器类似。
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/pods/probe/grpc-liveness.yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
After 15 seconds, view Pod events to verify that the liveness check has not failed:
|
||||
-->
|
||||
15 秒钟之后，查看 Pod 事件确认活跃性检查并未失败：
|
||||
|
||||
```shell
|
||||
kubectl describe pod etcd-with-grpc
|
||||
```
|
||||
|
||||
<!--
|
||||
Before Kubernetes 1.23, gRPC health probes were often implemented using [grpc-health-probe](https://github.com/grpc-ecosystem/grpc-health-probe/),
|
||||
as described in the blog post [Health checking gRPC servers on Kubernetes](/blog/2018/10/01/health-checking-grpc-servers-on-kubernetes/).
|
||||
The built-in gRPC probes behavior is similar to one implemented by grpc-health-probe.
|
||||
When migrating from grpc-health-probe to built-in probes, remember the following differences:
|
||||
-->
|
||||
在 Kubernetes 1.23 之前，gRPC 健康探测通常使用
|
||||
[grpc-health-probe](https://github.com/grpc-ecosystem/grpc-health-probe/)
|
||||
来实现，如博客 [Health checking gRPC servers on Kubernetes（对 Kubernetes 上的 gRPC 服务器执行健康检查）](/blog/2018/10/01/health-checking-grpc-servers-on-kubernetes/)所描述。
|
||||
内置的 gRPC 探测器行为与 `grpc-health-probe` 所实现的行为类似。
|
||||
从 `grpc-health-probe` 迁移到内置探测器时，请注意以下差异：
|
||||
|
||||
<!--
|
||||
- Built-in probes run against the pod IP address, unlike grpc-health-probe that often runs against `127.0.0.1`.
|
||||
Be sure to configure your gRPC endpoint to listen on the Pod's IP address.
|
||||
- Built-in probes do not support any authentication parameters (like `-tls`).
|
||||
- There are no error codes for built-in probes. All errors are considered as probe failures.
|
||||
- If `ExecProbeTimeout` feature gate is set to `false`, grpc-health-probe does **not** respect the `timeoutSeconds` setting (which defaults to 1s),
|
||||
while built-in probe would fail on timeout.
|
||||
-->
|
||||
- 内置探测器运行时针对的是 Pod 的 IP 地址，不像 `grpc-health-probe`
|
||||
那样通常针对 `127.0.0.1` 执行探测；
|
||||
请一定配置你的 gRPC 端点使之监听于 Pod 的 IP 地址之上。
|
||||
- 内置探测器不支持任何身份认证参数（例如 `tls`）。
|
||||
- 对于内置的探测器而言，不存在错误代码。所有错误都被视作探测失败。
|
||||
- 如果 `ExecProbeTimeout` 特性门控被设置为 `false`，则 `grpc-health-probe`
|
||||
不会考虑 `timeoutSeconds` 设置状态（默认值为 1s），
|
||||
而内置探测器则会在超时时返回失败。
|
||||
|
||||
<!--
|
||||
## Use a named port
|
||||
|
||||
|
|
@ -372,12 +465,12 @@ So, the previous example would become:
|
|||
-->
|
||||
## 使用启动探测器保护慢启动容器 {#define-startup-probes}
|
||||
|
||||
有时候，会有一些现有的应用程序在启动时需要较多的初始化时间。
|
||||
要不影响对引起探测死锁的快速响应，这种情况下，设置存活探测参数是要技巧的。
|
||||
技巧就是使用一个命令来设置启动探测，针对HTTP 或者 TCP 检测，可以通过设置
|
||||
`failureThreshold * periodSeconds` 参数来保证有足够长的时间应对糟糕情况下的启动时间。
|
||||
有时候，会有一些现有的应用在启动时需要较长的初始化时间。
|
||||
要这种情况下，若要不影响对死锁作出快速响应的探测，设置存活探测参数是要技巧的。
|
||||
技巧就是使用相同的命令来设置启动探测，针对 HTTP 或 TCP 检测，可以通过将
|
||||
`failureThreshold * periodSeconds` 参数设置为足够长的时间来应对糟糕情况下的启动时间。
|
||||
|
||||
所以，前面的例子就变成了：
|
||||
这样，前面的例子就变成了：
|
||||
|
||||
```yaml
|
||||
ports:
|
||||
|
|
@ -408,9 +501,10 @@ provide a fast response to container deadlocks.
|
|||
If the startup probe never succeeds, the container is killed after 300s and
|
||||
subject to the pod's `restartPolicy`.
|
||||
-->
|
||||
幸亏有启动探测，应用程序将会有最多 5 分钟(30 * 10 = 300s) 的时间来完成它的启动。
|
||||
一旦启动探测成功一次，存活探测任务就会接管对容器的探测，对容器死锁可以快速响应。
|
||||
如果启动探测一直没有成功，容器会在 300 秒后被杀死，并且根据 `restartPolicy` 来设置 Pod 状态。
|
||||
幸亏有启动探测，应用程序将会有最多 5 分钟（30 * 10 = 300s）的时间来完成其启动过程。
|
||||
一旦启动探测成功一次，存活探测任务就会接管对容器的探测，对容器死锁作出快速响应。
|
||||
如果启动探测一直没有成功，容器会在 300 秒后被杀死，并且根据 `restartPolicy` 来
|
||||
执行进一步处置。
|
||||
|
||||
<!--
|
||||
## Define readiness probes
|
||||
|
|
@ -426,9 +520,9 @@ Services.
|
|||
-->
|
||||
## 定义就绪探测器 {#define-readiness-probes}
|
||||
|
||||
有时候，应用程序会暂时性的不能提供通信服务。
|
||||
例如，应用程序在启动时可能需要加载很大的数据或配置文件，或是启动后要依赖等待外部服务。
|
||||
在这种情况下，既不想杀死应用程序，也不想给它发送请求。
|
||||
有时候，应用会暂时性地无法为请求提供服务。
|
||||
例如，应用在启动时可能需要加载大量的数据或配置文件，或是启动后要依赖等待外部服务。
|
||||
在这种情况下，既不想杀死应用，也不想给它发送请求。
|
||||
Kubernetes 提供了就绪探测器来发现并缓解这些情况。
|
||||
容器所在 Pod 上报还未就绪的信息，并且不接受通过 Kubernetes Service 的流量。
|
||||
|
||||
|
|
@ -443,8 +537,8 @@ Readiness probes runs on the container during its whole lifecycle.
|
|||
Liveness probes *do not* wait for readiness probes to succeed. If you want to wait before executing a liveness probe you should use initialDelaySeconds or a startupProbe.
|
||||
-->
|
||||
{{< caution >}}
|
||||
活跃性探测器 *不等待* 就绪性探测器成功。
|
||||
如果要在执行活跃性探测器之前等待，应该使用 initialDelaySeconds 或 startupProbe。
|
||||
活跃探测器 **不等待** 就绪性探测器成功。
|
||||
如果要在执行活跃探测器之前等待，应该使用 `initialDelaySeconds` 或 `startupProbe`。
|
||||
{{< /caution >}}
|
||||
|
||||
<!--
|
||||
|
|
@ -463,6 +557,7 @@ readinessProbe:
|
|||
initialDelaySeconds: 5
|
||||
periodSeconds: 5
|
||||
```
|
||||
|
||||
<!--
|
||||
Configuration for HTTP and TCP readiness probes also remains identical to
|
||||
liveness probes.
|
||||
|
|
@ -471,10 +566,10 @@ Readiness and liveness probes can be used in parallel for the same container.
|
|||
Using both can ensure that traffic does not reach a container that is not ready
|
||||
for it, and that containers are restarted when they fail.
|
||||
-->
|
||||
HTTP 和 TCP 的就绪探测器配置也和存活探测器的配置一样的。
|
||||
HTTP 和 TCP 的就绪探测器配置也和存活探测器的配置完全相同。
|
||||
|
||||
就绪和存活探测可以在同一个容器上并行使用。
|
||||
两者都用可以确保流量不会发给还没有准备好的容器，并且容器会在它们失败的时候被重新启动。
|
||||
两者都可以确保流量不会发给还未就绪的容器，当这些探测失败时容器会被重新启动。
|
||||
|
||||
<!--
|
||||
## Configure Probes
|
||||
|
|
@ -494,7 +589,7 @@ you can use to more precisely control the behavior of liveness and readiness
|
|||
checks:
|
||||
-->
|
||||
[Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core)
|
||||
有很多配置字段，可以使用这些字段精确的控制存活和就绪检测的行为：
|
||||
有很多配置字段，可以使用这些字段精确地控制活跃和就绪检测的行为：
|
||||
|
||||
<!--
|
||||
* `initialDelaySeconds`: Number of seconds after the container has started
|
||||
|
|
@ -510,14 +605,15 @@ and startup Probes. Minimum value is 1.
|
|||
try `failureThreshold` times before giving up. Giving up in case of liveness probe means restarting the container. In case of readiness probe the Pod will be marked Unready.
|
||||
Defaults to 3. Minimum value is 1.
|
||||
-->
|
||||
* `initialDelaySeconds`：容器启动后要等待多少秒后存活和就绪探测器才被初始化，默认是 0 秒，最小值是 0。
|
||||
* `initialDelaySeconds`：容器启动后要等待多少秒后才启动存活和就绪探测器，
|
||||
默认是 0 秒，最小值是 0。
|
||||
* `periodSeconds`：执行探测的时间间隔（单位是秒）。默认是 10 秒。最小值是 1。
|
||||
* `timeoutSeconds`：探测的超时后等待多少秒。默认值是 1 秒。最小值是 1。
|
||||
* `successThreshold`：探测器在失败后，被视为成功的最小连续成功数。默认值是 1。
|
||||
存活和启动探测的这个值必须是 1。最小值是 1。
|
||||
* `failureThreshold`：当探测失败时，Kubernetes 的重试次数。
|
||||
存活探测情况下的放弃就意味着重新启动容器。
|
||||
就绪探测情况下的放弃 Pod 会被打上未就绪的标签。默认值是 3。最小值是 1。
|
||||
对存活探测而言，放弃就意味着重新启动容器。
|
||||
对就绪探测而言，放弃意味着 Pod 会被打上未就绪的标签。默认值是 3。最小值是 1。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
|
|
@ -525,8 +621,8 @@ Before Kubernetes 1.20, the field `timeoutSeconds` was not respected for exec pr
|
|||
probes continued running indefinitely, even past their configured deadline,
|
||||
until a result was returned.
|
||||
-->
|
||||
在 Kubernetes 1.20 版本之前，exec 探针会忽略 `timeoutSeconds`：探针会无限期地
|
||||
持续运行，甚至可能超过所配置的限期，直到返回结果为止。
|
||||
在 Kubernetes 1.20 版本之前，`exec` 探针会忽略 `timeoutSeconds`：
|
||||
探针会无限期地持续运行，甚至可能超过所配置的限期，直到返回结果为止。
|
||||
|
||||
<!--
|
||||
This defect was corrected in Kubernetes v1.20. You may have been relying on the previous behavior,
|
||||
|
|
@ -539,13 +635,13 @@ you should update their probe timeout so that you're ready for the
|
|||
eventual removal of that feature gate.
|
||||
-->
|
||||
这一缺陷在 Kubernetes v1.20 版本中得到修复。你可能一直依赖于之前错误的探测行为，
|
||||
甚至你都没有觉察到这一问题的存在，因为默认的超时值是 1 秒钟。
|
||||
甚至都没有觉察到这一问题的存在，因为默认的超时值是 1 秒钟。
|
||||
作为集群管理员，你可以在所有的 kubelet 上禁用 `ExecProbeTimeout`
|
||||
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
（将其设置为 `false`），从而恢复之前版本中的运行行为，之后当集群中所有的
|
||||
（将其设置为 `false`），从而恢复之前版本中的运行行为。之后当集群中所有的
|
||||
exec 探针都设置了 `timeoutSeconds` 参数后，移除此标志重载。
|
||||
如果你有 Pods 受到此默认 1 秒钟超时值的影响，你应该更新 Pod 对应的探针的
|
||||
超时值，这样才能为最终去除该特性门控做好准备。
|
||||
如果你有 Pod 受到此默认 1 秒钟超时值的影响，你应该更新这些 Pod 对应的探针的超时值，
|
||||
这样才能为最终去除该特性门控做好准备。
|
||||
|
||||
<!--
|
||||
With the fix of the defect, for exec probes, on Kubernetes `1.20+` with the `dockershim` container runtime,
|
||||
|
|
@ -555,6 +651,7 @@ the process inside the container may keep running even after probe returned fail
|
|||
版本中，对于 exec 探针而言，容器中的进程可能会因为超时值的设置保持持续运行，
|
||||
即使探针返回了失败状态。
|
||||
{{< /note >}}
|
||||
|
||||
{{< caution >}}
|
||||
<!--
|
||||
Incorrect implementation of readiness probes may result in an ever growing number
|
||||
|
|
@ -581,13 +678,13 @@ in the range 1 to 65535.
|
|||
### HTTP 探测 {#http-probes}
|
||||
|
||||
[HTTP Probes](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core)
|
||||
可以在 `httpGet` 上配置额外的字段：
|
||||
允许针对 `httpGet` 配置额外的字段：
|
||||
|
||||
* `host`：连接使用的主机名，默认是 Pod 的 IP。也可以在 HTTP 头中设置 “Host” 来代替。
|
||||
* `scheme` ：用于设置连接主机的方式（HTTP 还是 HTTPS）。默认是 HTTP。
|
||||
* `scheme` ：用于设置连接主机的方式（HTTP 还是 HTTPS）。默认是 "HTTP"。
|
||||
* `path`：访问 HTTP 服务的路径。默认值为 "/"。
|
||||
* `httpHeaders`：请求中自定义的 HTTP 头。HTTP 头字段允许重复。
|
||||
* `port`：访问容器的端口号或者端口名。如果数字必须在 1 ～ 65535 之间。
|
||||
* `port`：访问容器的端口号或者端口名。如果数字必须在 1～65535 之间。
|
||||
|
||||
<!--
|
||||
For an HTTP probe, the kubelet sends an HTTP request to the specified path and
|
||||
|
|
@ -664,16 +761,28 @@ to resolve it.
|
|||
-->
|
||||
### TCP 探测 {#tcp-probes}
|
||||
|
||||
对于一次 TCP 探测，kubelet 在节点上（不是在 Pod 里面）建立探测连接，
|
||||
对于 TCP 探测而言，kubelet 在节点上（不是在 Pod 里面）发起探测连接，
|
||||
这意味着你不能在 `host` 参数上配置服务名称，因为 kubelet 不能解析服务名称。
|
||||
|
||||
<!--
|
||||
### Probe-level `terminationGracePeriodSeconds`
|
||||
-->
|
||||
### 探测器级别 `terminationGracePeriodSeconds`
|
||||
### 探测器层面的 `terminationGracePeriodSeconds`
|
||||
|
||||
{{< feature-state for_k8s_version="v1.22" state="beta" >}}
|
||||
|
||||
<!--
|
||||
Prior to release 1.21, the pod-level `terminationGracePeriodSeconds` was used
|
||||
for terminating a container that failed its liveness or startup probe. This
|
||||
coupling was unintended and may have resulted in failed containers taking an
|
||||
unusually long time to restart when a pod-level `terminationGracePeriodSeconds`
|
||||
was set.
|
||||
-->
|
||||
在 1.21 发行版之前，Pod 层面的 `terminationGracePeriodSeconds`
|
||||
被用来终止活跃探测或启动探测失败的容器。
|
||||
这一行为上的关联不是我们想要的，可能导致 Pod 层面设置了 `terminationGracePeriodSeconds`
|
||||
时容器要花非常长的时间才能重新启动。
|
||||
|
||||
<!--
|
||||
In 1.21 and beyond, when the feature gate `ProbeTerminationGracePeriod` is
|
||||
enabled, users can specify a probe-level `terminationGracePeriodSeconds` as
|
||||
|
|
@ -681,29 +790,27 @@ part of the probe specification. When the feature gate is enabled, and both a
|
|||
pod- and probe-level `terminationGracePeriodSeconds` are set, the kubelet will
|
||||
use the probe-level value.
|
||||
-->
|
||||
在 1.21 及更高版本中，当特性门控 `ProbeTerminationGracePeriod` 为
|
||||
启用状态时，用户可以指定一个探测级别的 `terminationGracePeriodSeconds` 作为
|
||||
探针规格的一部分。当特性门控被启用时，并且
|
||||
Pod 级和探针级的 `terminationGracePeriodSeconds` 都已设置，kubelet 将
|
||||
使用探针级设置的值。
|
||||
在 1.21 及更高版本中，当特性门控 `ProbeTerminationGracePeriod` 被启用时，
|
||||
用户可以指定一个探测器层面的 `terminationGracePeriodSeconds` 作为探测器规约的一部分。
|
||||
当该特性门控被启用，并且 Pod 层面和探测器层面的 `terminationGracePeriodSeconds`
|
||||
都已设置，kubelet 将使用探测器层面设置的值。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
As of Kubernetes 1.22, the `ProbeTerminationGracePeriod` feature gate is only
|
||||
available on the API Server. The kubelet always honors the probe-level
|
||||
`terminationGracePeriodSeconds` field if it is present on a Pod.
|
||||
-->
|
||||
从 Kubernetes 1.22 开始，`ProbeTerminationGracePeriod` 特性门控只
|
||||
在 API 服务器上可用。 kubelet 始终遵守探针级别
|
||||
`terminationGracePeriodSeconds` 字段（如果它存在于 Pod 上）。
|
||||
在 Kubernetes 1.22 中，`ProbeTerminationGracePeriod` 特性门控只能用在 API 服务器上。
|
||||
kubelet 始终遵守探针级别 `terminationGracePeriodSeconds` 字段
|
||||
（如果它存在于 Pod 上）。
|
||||
|
||||
<!--
|
||||
If you have existing Pods where the `terminationGracePeriodSeconds` field is set and
|
||||
you no longer wish to use per-probe termination grace periods, you must delete
|
||||
those existing Pods.
|
||||
-->
|
||||
如果你已经为现有 Pod 设置了 “terminationGracePeriodSeconds” 字段并且
|
||||
不再希望使用针对每个探针的终止宽限期，则必须删除那些现有的 Pod。
|
||||
如果你已经为现有 Pod 设置了 `terminationGracePeriodSeconds`
|
||||
字段并且不再希望使用针对每个探针的终止宽限期，则必须删除现有的这类 Pod。
|
||||
|
||||
<!--
|
||||
When you (or the control plane, or some other component) create replacement
|
||||
|
|
@ -711,11 +818,9 @@ Pods, and the feature gate `ProbeTerminationGracePeriod` is disabled, then the
|
|||
API server ignores the Pod-level `terminationGracePeriodSeconds` field, even if
|
||||
a Pod or pod template specifies it.
|
||||
-->
|
||||
当你（或控制平面或某些其他组件）创建替换
|
||||
Pods，并且特性门控 “ProbeTerminationGracePeriod” 被禁用，那么
|
||||
API 服务器会忽略 Pod 级别的 `terminationGracePeriodSeconds` 字段，即使
|
||||
Pod 或 Pod 模板指定了它。
|
||||
{{< /note >}}
|
||||
当你（或控制平面或某些其他组件）创建替换 Pod，并且特性门控 `ProbeTerminationGracePeriod`
|
||||
被禁用时，API 服务器会忽略 Pod 级别的 `terminationGracePeriodSeconds` 字段设置，
|
||||
即使 Pod 或 Pod 模板指定了它。
|
||||
|
||||
例如:
|
||||
|
||||
|
|
@ -745,8 +850,8 @@ spec:
|
|||
Probe-level `terminationGracePeriodSeconds` cannot be set for readiness probes.
|
||||
It will be rejected by the API server.
|
||||
-->
|
||||
探测器级别的 `terminationGracePeriodSeconds` 不能用于设置就绪态探针。
|
||||
它将被 API 服务器拒绝。
|
||||
探测器层面的 `terminationGracePeriodSeconds` 不能用于就绪态探针。
|
||||
这一设置将被 API 服务器拒绝。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
|
|
|||
|
|
@ -13,56 +13,249 @@ content_type: concept
|
|||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
Resource usage metrics, such as container CPU and memory usage,
|
||||
are available in Kubernetes through the Metrics API. These metrics can be accessed either directly
|
||||
by the user with the `kubectl top` command, or by a controller in the cluster, for example
|
||||
Horizontal Pod Autoscaler, to make decisions.
|
||||
For Kubernetes, the _Metrics API_ offers a basic set of metrics to support automatic scaling and
|
||||
similar use cases. This API makes information available about resource usage for node and pod,
|
||||
including metrics for CPU and memory. If you deploy the Metrics API into your cluster, clients of
|
||||
the Kubernetes API can then query for this information, and you can use Kubernetes' access control
|
||||
mechanisms to manage permissions to do so.
|
||||
|
||||
The [HorizontalPodAutoscaler](/docs/tasks/run-application/horizontal-pod-autoscale/) (HPA) and
|
||||
[VerticalPodAutoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#readme) (VPA)
|
||||
use data from the metrics API to adjust workload replicas and resources to meet customer demand.
|
||||
|
||||
You can also view the resource metrics using the
|
||||
[`kubectl top`](/docs/reference/generated/kubectl/kubectl-commands#top)
|
||||
command.
|
||||
-->
|
||||
资源使用指标，例如容器 CPU 和内存使用率，可通过 Metrics API 在 Kubernetes 中获得。
|
||||
这些指标可以直接被用户访问，比如使用 `kubectl top` 命令行，或者被集群中的控制器
|
||||
（例如 Horizontal Pod Autoscalers) 使用来做决策。
|
||||
|
||||
对于 Kubernetes，_Metrics API_ 提供了一组基本的指标，以支持自动伸缩和类似的用例。
|
||||
该 API 提供有关节点和 Pod 的资源使用情况的信息，
|
||||
包括 CPU 和内存的指标。如果将 Metrics API 部署到集群中，
|
||||
那么 Kubernetes API 的客户端就可以查询这些信息，并且可以使用 Kubernetes 的访问控制机制来管理权限。
|
||||
|
||||
[HorizontalPodAutoscaler](/zh/docs/tasks/run-application/horizontal-pod-autoscale/) (HPA) 和
|
||||
[VerticalPodAutoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#readme) (VPA)
|
||||
使用 metrics API 中的数据调整工作负载副本和资源，以满足客户需求。
|
||||
|
||||
你也可以通过 [`kubectl top`](/zh/docs/reference/generated/kubectl/kubectl-commands#top) 命令来查看资源指标。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
The Metrics API, and the metrics pipeline that it enables, only offers the minimum
|
||||
CPU and memory metrics to enable automatic scaling using HPA and / or VPA.
|
||||
If you would like to provide a more complete set of metrics, you can complement
|
||||
the simpler Metrics API by deploying a second
|
||||
[metrics pipeline](/docs/tasks/debug-application-cluster/resource-usage-monitoring/#full-metrics-pipeline)
|
||||
that uses the _Custom Metrics API_.
|
||||
-->
|
||||
Metrics API 及其启用的指标管道仅提供最少的 CPU 和内存指标，以启用使用 HPA 和/或 VPA 的自动扩展。
|
||||
如果你想提供更完整的指标集，你可以通过部署使用 _Custom Metrics API_ 的第二个
|
||||
[指标管道](/zh/docs/tasks/debug-application-cluster/resource-usage-monitoring/#full-metrics-pipeline) 来作为简单的 Metrics API 的补充。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
Figure 1 illustrates the architecture of the resource metrics pipeline.
|
||||
-->
|
||||
图 1 说明了资源指标管道的架构。
|
||||
|
||||
{{< mermaid >}}
|
||||
flowchart RL
|
||||
subgraph cluster[Cluster]
|
||||
direction RL
|
||||
S[ <br><br> ]
|
||||
A[Metrics-<br>Server]
|
||||
subgraph B[Nodes]
|
||||
direction TB
|
||||
D[cAdvisor] --> C[kubelet]
|
||||
E[Container<br>runtime] --> D
|
||||
E1[Container<br>runtime] --> D
|
||||
P[pod data] -.- C
|
||||
end
|
||||
L[API<br>server]
|
||||
W[HPA]
|
||||
C ---->|Summary<br>API| A -->|metrics<br>API| L --> W
|
||||
end
|
||||
L ---> K[kubectl<br>top]
|
||||
classDef box fill:#fff,stroke:#000,stroke-width:1px,color:#000;
|
||||
class W,B,P,K,cluster,D,E,E1 box
|
||||
classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000
|
||||
class S spacewhite
|
||||
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:1px,color:#fff;
|
||||
class A,L,C k8s
|
||||
{{< /mermaid >}}
|
||||
|
||||
<!--
|
||||
Figure 1. Resource Metrics Pipeline
|
||||
|
||||
The architecture components, from right to left in the figure, consist of the following:
|
||||
|
||||
* [cAdvisor](https://github.com/google/cadvisor): Daemon for collecting, aggregating and exposing
|
||||
container metrics included in Kubelet.
|
||||
* [kubelet](/docs/concepts/overview/components/#kubelet): Node agent for managing container
|
||||
resources. Resource metrics are accessible using the `/metrics/resource` and `/stats` kubelet
|
||||
API endpoints.
|
||||
* [Summary API](#summary-api-source): API provided by the kubelet for discovering and retrieving
|
||||
per-node summarized stats available through the `/stats` endpoint.
|
||||
* [metrics-server](#metrics-server): Cluster addon component that collects and aggregates resource
|
||||
metrics pulled from each kubelet. The API server serves Metrics API for use by HPA, VPA, and by
|
||||
the `kubectl top` command. Metrics Server is a reference implementation of the Metrics API.
|
||||
* [Metrics API](#metrics-api): Kubernetes API supporting access to CPU and memory used for
|
||||
workload autoscaling. To make this work in your cluster, you need an API extension server that
|
||||
provides the Metrics API.
|
||||
-->
|
||||
图 1. 资源指标管道
|
||||
|
||||
图中从右到左的架构组件包括以下内容：
|
||||
|
||||
* [cAdvisor](https://github.com/google/cadvisor): 用于收集、聚合和公开 Kubelet 中包含的容器指标的守护程序。
|
||||
* [kubelet](/zh/docs/concepts/overview/components/#kubelet): 用于管理容器资源的节点代理。
|
||||
可以使用 `/metrics/resource` 和 `/stats` kubelet API 端点访问资源指标。
|
||||
* [Summary API](#summary-api-source): kubelet 提供的 API，用于发现和检索可通过 `/stats` 端点获得的每个节点的汇总统计信息。
|
||||
* [metrics-server](#metrics-server): 集群插件组件，用于收集和聚合从每个 kubelet 中提取的资源指标。
|
||||
API 服务器提供 Metrics API 以供 HPA、VPA 和 `kubectl top` 命令使用。 Metrics Server 是 Metrics API 的参考实现。
|
||||
* [Metrics API](#metrics-api): Kubernetes API 支持访问用于工作负载自动缩放的 CPU 和内存。
|
||||
要在你的集群中进行这项工作，你需要一个提供 Metrics API 的 API 扩展服务器。
|
||||
|
||||
<!--
|
||||
cAdvisor supports reading metrics from cgroups, which works with typical container runtimes on Linux.
|
||||
If you use a container runtime that uses another resource isolation mechanism, for example
|
||||
virtualization, then that container runtime must support
|
||||
[CRI Container Metrics](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/cri-container-stats.md)
|
||||
in order for metrics to be available to the kubelet.
|
||||
-->
|
||||
{{< note >}}
|
||||
cAdvisor 支持从 cgroups 读取指标，它适用于 Linux 上的典型容器运行时。
|
||||
如果你使用基于其他资源隔离机制的容器运行时，例如虚拟化，那么该容器运行时必须支持
|
||||
[CRI 容器指标](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/cri-container-stats.md)
|
||||
以便 kubelet 可以使用指标。
|
||||
{{< /note >}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
## The Metrics API
|
||||
## Metrics API
|
||||
|
||||
The metrics-server implements the Metrics API. This API allows you to access CPU and memory usage
|
||||
for the nodes and pods in your cluster. Its primary role is to feed resource usage metrics to K8s
|
||||
autoscaler components.
|
||||
|
||||
Here is an example of the Metrics API request for a `minikube` node piped through `jq` for easier
|
||||
reading:
|
||||
|
||||
Through the Metrics API, you can get the amount of resource currently used
|
||||
by a given node or a given pod. This API doesn't store the metric values,
|
||||
so it's not possible, for example, to get the amount of resources used by a
|
||||
given node 10 minutes ago.
|
||||
-->
|
||||
## Metrics API {#the-metrics-api}
|
||||
|
||||
通过 Metrics API，你可以获得指定节点或 Pod 当前使用的资源量。
|
||||
此 API 不存储指标值，因此想要获取某个指定节点 10 分钟前的
|
||||
资源使用量是不可能的。
|
||||
{{< feature-state for_k8s_version="1.8" state="beta" >}}
|
||||
|
||||
metrics-server 实现了 Metrics API。此 API 允许你访问集群中节点和 Pod 的 CPU 和内存使用情况。
|
||||
它的主要作用是将资源使用指标提供给 K8s 自动缩放器组件。
|
||||
|
||||
下面是一个 `minikube` 节点的 Metrics API 请求示例，通过 `jq` 管道处理以便于阅读：
|
||||
|
||||
```shell
|
||||
kubectl get --raw "/apis/metrics.k8s.io/v1beta1/nodes/minikube" | jq '.'
|
||||
```
|
||||
|
||||
<!-- Here is the same API call using `curl`: -->
|
||||
这是使用 `curl` 来执行的相同 API 调用：
|
||||
|
||||
```shell
|
||||
curl http://localhost:8080/apis/metrics.k8s.io/v1beta1/nodes/minikube
|
||||
```
|
||||
|
||||
<!-- Sample response: -->
|
||||
响应示例：
|
||||
|
||||
```json
|
||||
{
|
||||
"kind": "NodeMetrics",
|
||||
"apiVersion": "metrics.k8s.io/v1beta1",
|
||||
"metadata": {
|
||||
"name": "minikube",
|
||||
"selfLink": "/apis/metrics.k8s.io/v1beta1/nodes/minikube",
|
||||
"creationTimestamp": "2022-01-27T18:48:43Z"
|
||||
},
|
||||
"timestamp": "2022-01-27T18:48:33Z",
|
||||
"window": "30s",
|
||||
"usage": {
|
||||
"cpu": "487558164n",
|
||||
"memory": "732212Ki"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<!--
|
||||
The API is no different from any other API:
|
||||
Here is an example of the Metrics API request for a `kube-scheduler-minikube` pod contained in the
|
||||
`kube-system` namespace and piped through `jq` for easier reading:
|
||||
-->
|
||||
此 API 与其他 API 没有区别：
|
||||
|
||||
下面是一个 `kube-system` 命名空间中的 `kube-scheduler-minikube` Pod 的 Metrics API 请求示例，
|
||||
通过 `jq` 管道处理以便于阅读：
|
||||
|
||||
```shell
|
||||
kubectl get --raw "/apis/metrics.k8s.io/v1beta1/namespaces/kube-system/pods/kube-scheduler-minikube" | jq '.'
|
||||
```
|
||||
|
||||
<!-- Here is the same API call using `curl`: -->
|
||||
这是使用 `curl` 来完成的相同 API 调用：
|
||||
|
||||
```shell
|
||||
curl http://localhost:8080/apis/metrics.k8s.io/v1beta1/namespaces/kube-system/pods/kube-scheduler-minikube
|
||||
```
|
||||
|
||||
<!-- Sample response: -->
|
||||
响应示例：
|
||||
|
||||
```json
|
||||
{
|
||||
"kind": "PodMetrics",
|
||||
"apiVersion": "metrics.k8s.io/v1beta1",
|
||||
"metadata": {
|
||||
"name": "kube-scheduler-minikube",
|
||||
"namespace": "kube-system",
|
||||
"selfLink": "/apis/metrics.k8s.io/v1beta1/namespaces/kube-system/pods/kube-scheduler-minikube",
|
||||
"creationTimestamp": "2022-01-27T19:25:00Z"
|
||||
},
|
||||
"timestamp": "2022-01-27T19:24:31Z",
|
||||
"window": "30s",
|
||||
"containers": [
|
||||
{
|
||||
"name": "kube-scheduler",
|
||||
"usage": {
|
||||
"cpu": "9559630n",
|
||||
"memory": "22244Ki"
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
<!--
|
||||
- it is discoverable through the same endpoint as the other Kubernetes APIs under the path: `/apis/metrics.k8s.io/`
|
||||
- it offers the same security, scalability, and reliability guarantees
|
||||
The Metrics API is defined in the [k8s.io/metrics](https://github.com/kubernetes/metrics)
|
||||
repository. You must enable the [API aggregation layer](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)
|
||||
and register an [APIService](/docs/reference/kubernetes-api/cluster-resources/api-service-v1/)
|
||||
for the `metrics.k8s.io` API.
|
||||
|
||||
To learn more about the Metrics API, see [resource metrics API design](https://github.com/kubernetes/design-proposals-archive/blob/main/instrumentation/resource-metrics-api.md),
|
||||
the [metrics-server repository](https://github.com/kubernetes-sigs/metrics-server) and the
|
||||
[resource metrics API](https://github.com/kubernetes/metrics#resource-metrics-api).
|
||||
-->
|
||||
- 此 API 和其它 Kubernetes API 一起位于同一端点（endpoint）之下且可发现，
|
||||
路径为 `/apis/metrics.k8s.io/`
|
||||
- 它具有相同的安全性、可扩展性和可靠性保证
|
||||
|
||||
Metrics API 在 [k8s.io/metrics](https://github.com/kubernetes/metrics) 代码库中定义。
|
||||
你必须启用 [API 聚合层](/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer/)并为
|
||||
`metrics.k8s.io` API 注册一个 [APIService](/zh/docs/reference/kubernetes-api/cluster-resources/api-service-v1/)。
|
||||
|
||||
要了解有关 Metrics API 的更多信息，
|
||||
请参阅资源 [Resource Metrics API Design](https://github.com/kubernetes/design-proposals-archive/blob/main/instrumentation/resource-metrics-api.md)、
|
||||
[metrics-server 代码库](https://github.com/kubernetes-sigs/metrics-server) 和
|
||||
[Resource Metrics API](https://github.com/kubernetes/metrics#resource-metrics-api)。
|
||||
|
||||
<!--
|
||||
The API is defined in [k8s.io/metrics](https://github.com/kubernetes/metrics/blob/master/pkg/apis/metrics/v1beta1/types.go)
|
||||
repository. You can find more information about the API there.
|
||||
-->
|
||||
Metrics API 在 [k8s.io/metrics](https://github.com/kubernetes/metrics/blob/master/pkg/apis/metrics/v1beta1/types.go)
|
||||
仓库中定义。你可以在那里找到有关 Metrics API 的更多信息。
|
||||
|
||||
<!--
|
||||
The API requires metrics server to be deployed in the cluster. Otherwise it will be not available.
|
||||
You must deploy the metrics-server or alternative adapter that serves the Metrics API to be able
|
||||
to access it.
|
||||
-->
|
||||
{{< note >}}
|
||||
Metrics API 需要在集群中部署 Metrics Server。否则它将不可用。
|
||||
你必须部署提供 Metrics API 服务的 metrics-server 或其他适配器才能访问它。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
|
|
@ -70,75 +263,119 @@ Metrics API 需要在集群中部署 Metrics Server。否则它将不可用。
|
|||
|
||||
### CPU
|
||||
|
||||
CPU is reported as the average usage, in
|
||||
[CPU cores](/docs/concepts/configuration/manage-resources-containers/#meaning-of-cpu),
|
||||
over a period of time. This value is derived by taking a rate over a cumulative CPU counter
|
||||
provided by the kernel (in both Linux and Windows kernels).
|
||||
The kubelet chooses the window for the rate calculation.
|
||||
CPU is reported as the average core usage measured in cpu units. One cpu, in Kubernetes, is
|
||||
equivalent to 1 vCPU/Core for cloud providers, and 1 hyper-thread on bare-metal Intel processors.
|
||||
|
||||
This value is derived by taking a rate over a cumulative CPU counter provided by the kernel (in
|
||||
both Linux and Windows kernels). The time window used to calculate CPU is shown under window field
|
||||
in Metrics API.
|
||||
|
||||
To learn more about how Kubernetes allocates and measures CPU resources, see
|
||||
[meaning of CPU](/docs/concepts/configuration/manage-resources-container/#meaning-of-cpu).
|
||||
-->
|
||||
## 度量资源用量 {#measuring-resource-usage}
|
||||
|
||||
### CPU
|
||||
|
||||
CPU 用量按其一段时间内的平均值统计，单位为
|
||||
[CPU 核](/zh/docs/concepts/configuration/manage-resources-containers/#meaning-of-cpu)。
|
||||
此度量值通过在内核（包括 Linux 和 Windows）提供的累积 CPU 计数器乘以一个系数得到。
|
||||
`kubelet` 组件负责选择计算系数所使用的窗口大小。
|
||||
CPU 报告为以 cpu 为单位测量的平均核心使用率。在 Kubernetes 中，
|
||||
一个 cpu 相当于云提供商的 1 个 vCPU/Core，以及裸机 Intel 处理器上的 1 个超线程。
|
||||
|
||||
该值是通过对内核提供的累积 CPU 计数器（在 Linux 和 Windows 内核中）取一个速率得出的。
|
||||
用于计算 CPU 的时间窗口显示在 Metrics API 的窗口字段下。
|
||||
|
||||
要了解更多关于 Kubernetes 如何分配和测量 CPU 资源的信息，请参阅
|
||||
[CPU 的含义](/zh/docs/concepts/configuration/manage-resources-container/#meaning-of-cpu)。
|
||||
|
||||
<!--
|
||||
### Memory
|
||||
|
||||
Memory is reported as the working set, in bytes, at the instant the metric was collected.
|
||||
In an ideal world, the "working set" is the amount of memory in-use that cannot be freed under memory pressure.
|
||||
However, calculation of the working set varies by host OS, and generally makes heavy use of heuristics to produce an estimate.
|
||||
It includes all anonymous (non-file-backed) memory since Kubernetes does not support swap.
|
||||
The metric typically also includes some cached (file-backed) memory, because the host OS cannot always reclaim such pages.
|
||||
Memory is reported as the working set, measured in bytes, at the instant the metric was collected.
|
||||
|
||||
In an ideal world, the "working set" is the amount of memory in-use that cannot be freed under
|
||||
memory pressure. However, calculation of the working set varies by host OS, and generally makes
|
||||
heavy use of heuristics to produce an estimate.
|
||||
|
||||
The Kubernetes model for a container's working set expects that the container runtime counts
|
||||
anonymous memory associated with the container in question. The working set metric typically also
|
||||
includes some cached (file-backed) memory, because the host OS cannot always reclaim pages.
|
||||
|
||||
To learn more about how Kubernetes allocates and measures memory resources, see
|
||||
[meaning of memory](/docs/concepts/configuration/manage-resources-container/#meaning-of-memory).
|
||||
-->
|
||||
### 内存 {#memory}
|
||||
|
||||
内存用量按工作集（Working Set）的大小字节数统计，其数值为收集度量值的那一刻的内存用量。
|
||||
如果一切都很理想化，“工作集” 是任务在使用的内存总量，该内存是不可以在内存压力较大
|
||||
的情况下被释放的。
|
||||
不过，具体的工作集计算方式取决于宿主 OS，有很大不同，且通常都大量使用启发式
|
||||
规则来给出一个估计值。
|
||||
其中包含所有匿名内存使用（没有后台文件提供存储者），因为 Kubernetes 不支持交换分区。
|
||||
度量值通常包含一些高速缓存（有后台文件提供存储）内存，因为宿主操作系统并不是总能
|
||||
回收这些页面。
|
||||
内存报告为在收集度量标准的那一刻的工作集大小，以字节为单位。
|
||||
|
||||
在理想情况下，“工作集”是在内存压力下无法释放的正在使用的内存量。
|
||||
然而，工作集的计算因主机操作系统而异，并且通常大量使用启发式算法来产生估计。
|
||||
|
||||
Kubernetes 模型中，容器工作集是由容器运行时计算的与相关容器关联的匿名内存。
|
||||
工作集指标通常还包括一些缓存（文件支持）内存，因为主机操作系统不能总是回收页面。
|
||||
|
||||
要了解有关 Kubernetes 如何分配和测量内存资源的更多信息，
|
||||
请参阅[内存的含义](/zh/docs/concepts/configuration/manage-resources-container/#meaning-of-memory)。
|
||||
|
||||
<!--
|
||||
## Metrics Server
|
||||
|
||||
[Metrics Server](https://github.com/kubernetes-sigs/metrics-server) is a cluster-wide aggregator of resource usage data.
|
||||
By default, it is deployed in clusters created by `kube-up.sh` script
|
||||
as a Deployment object. If you use a different Kubernetes setup mechanism you can deploy it using the provided
|
||||
[deployment components.yaml](https://github.com/kubernetes-sigs/metrics-server/releases) file.
|
||||
The metrics-server fetches resource metrics from the kubelets and exposes them in the Kubernetes
|
||||
API server through the Metrics API for use by the HPA and VPA. You can also view these metrics
|
||||
using the `kubectl top` command.
|
||||
|
||||
The metrics-server uses the Kubernetes API to track nodes and pods in your cluster. The
|
||||
metrics-server queries each node over HTTP to fetch metrics. The metrics-server also builds an
|
||||
internal view of pod metadata, and keeps a cache of pod health. That cached pod health information
|
||||
is available via the extension API that the metrics-server makes available.
|
||||
|
||||
For example with an HPA query, the metrics-server needs to identify which pods fulfill the label
|
||||
selectors in the deployment.
|
||||
-->
|
||||
## Metrics 服务器 {#metrics-server}
|
||||
|
||||
[Metrics 服务器](https://github.com/kubernetes-sigs/metrics-server)
|
||||
是集群范围资源用量数据的聚合器。
|
||||
默认情况下，在由 `kube-up.sh` 脚本创建的集群中会以 Deployment 的形式被部署。
|
||||
如果你使用其他 Kubernetes 安装方法，则可以使用提供的
|
||||
[部署组件 components.yaml](https://github.com/kubernetes-sigs/metrics-server/releases)
|
||||
来部署。
|
||||
metrics-server 从 kubelet 中获取资源指标，并通过 Metrics API 在 Kubernetes API 服务器中公开它们，以供 HPA 和 VPA 使用。
|
||||
你还可以使用 `kubectl top` 命令查看这些指标。
|
||||
|
||||
metrics-server 使用 Kubernetes API 来跟踪集群中的节点和 Pod。metrics-server 服务器通过 HTTP 查询每个节点以获取指标。
|
||||
metrics-server 还构建了 Pod 元数据的内部视图，并维护 Pod 健康状况的缓存。
|
||||
缓存的 Pod 健康信息可通过 metrics-server 提供的扩展 API 获得。
|
||||
|
||||
例如，对于 HPA 查询，metrics-server 需要确定哪些 Pod 满足 Deployment 中的标签选择器。
|
||||
|
||||
<!--
|
||||
Metric server collects metrics from the Summary API, exposed by
|
||||
[Kubelet](/docs/reference/command-line-tools-reference/kubelet/) on each node, and is registered with the main API server via
|
||||
[Kubernetes aggregator](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/).
|
||||
The metrics-server calls the [kubelet](/docs/reference/command-line-tools-reference/kubelet/) API
|
||||
to collect metrics from each node. Depending on the metrics-server version it uses:
|
||||
|
||||
* Metrics resource endpoint `/metrics/resource` in version v0.6.0+ or
|
||||
* Summary API endpoint `/stats/summary` in older versions
|
||||
-->
|
||||
Metric 服务器从每个节点上的 [kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/)
|
||||
公开的 Summary API 中采集指标信息。
|
||||
该 API 通过
|
||||
[Kubernetes 聚合器](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)
|
||||
注册到主 API 服务器上。
|
||||
metrics-server 调用 [kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) API
|
||||
从每个节点收集指标。根据它使用的度量服务器版本：
|
||||
|
||||
* 版本 v0.6.0+ 中，使用指标资源端点 `/metrics/resource`
|
||||
* 旧版本中使用 Summary API 端点 `/stats/summary`
|
||||
|
||||
<!--
|
||||
Learn more about the metrics server in
|
||||
[the design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md).
|
||||
To learn more about the metrics-server, see the
|
||||
[metrics-server repository](https://github.com/kubernetes-sigs/metrics-server).
|
||||
|
||||
You can also check out the following:
|
||||
|
||||
* [metrics-server design](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md)
|
||||
* [metrics-server FAQ](https://github.com/kubernetes-sigs/metrics-server/blob/master/FAQ.md)
|
||||
* [metrics-server known issues](https://github.com/kubernetes-sigs/metrics-server/blob/master/KNOWN_ISSUES.md)
|
||||
* [metrics-server releases](https://github.com/kubernetes-sigs/metrics-server/releases)
|
||||
* [Horizontal Pod Autoscaling](/docs/tasks/run-application/horizontal-pod-autoscale/)
|
||||
-->
|
||||
在[设计文档](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md)
|
||||
中可以了解到有关 Metrics 服务器的更多信息。
|
||||
|
||||
了解更多 metrics-server，参阅 [metrics-server 代码库](https://github.com/kubernetes-sigs/metrics-server)。
|
||||
|
||||
你还可以查看以下内容：
|
||||
|
||||
* [metrics-server 设计](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md)
|
||||
* [metrics-server FAQ](https://github.com/kubernetes-sigs/metrics-server/blob/master/FAQ.md)
|
||||
* [metrics-server known issues](https://github.com/kubernetes-sigs/metrics-server/blob/master/KNOWN_ISSUES.md)
|
||||
* [metrics-server releases](https://github.com/kubernetes-sigs/metrics-server/releases)
|
||||
* [Horizontal Pod Autoscaling](/zh/docs/tasks/run-application/horizontal-pod-autoscale/)
|
||||
|
||||
<!--
|
||||
### Summary API Source
|
||||
|
|
@ -148,19 +385,33 @@ them in the [Summary API](https://github.com/kubernetes/kubernetes/blob/7d309e01
|
|||
for consumers to read.
|
||||
-->
|
||||
|
||||
### 摘要 API 来源
|
||||
### Summary API 来源
|
||||
|
||||
[Kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) 在节点、卷、pod 和容器级别收集统计信息，
|
||||
并在[摘要API](https://github.com/kubernetes/kubernetes/blob/7d309e0104fedb57280b261e5677d919cb2a0e2d/staging/src/k8s.io/kubelet/pkg/apis/stats/v1alpha1/types.go)
|
||||
[Kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) 在节点、卷、Pod 和容器级别收集统计信息，
|
||||
并在[Summary API](https://github.com/kubernetes/kubernetes/blob/7d309e0104fedb57280b261e5677d919cb2a0e2d/staging/src/k8s.io/kubelet/pkg/apis/stats/v1alpha1/types.go)
|
||||
中提供它们的统计信息供消费者阅读。
|
||||
|
||||
<!--
|
||||
Pre-1.23, these resources have been primarily gathered from [cAdvisor](https://github.com/google/cadvisor). However, in 1.23 with the
|
||||
introduction of the `PodAndContainerStatsFromCRI` FeatureGate, container and pod level stats can be gathered by the CRI implementation.
|
||||
Note: this also requires support from the CRI implementations (containerd >= 1.6.0, CRI-O >= 1.23.0).
|
||||
Here is an example of a Summary API request for a `minikube` node:
|
||||
-->
|
||||
|
||||
在 1.23 版本前，这些资源主要来自 [cAdvisor](https://github.com/google/cadvisor)。但在 1.23 版本中
|
||||
引入了 `PodAndContainerStatsFromCRI` FeatureGate，
|
||||
CRI 实现了可以收集容器和 pod 级别的统计信息。
|
||||
注意：这需要 CRI 实现的支持（containerd >= 1.6.0，CRI-O >= 1.23.0）。
|
||||
下面是一个 `minikube` 节点的 Summary API 请求示例：
|
||||
|
||||
```shell
|
||||
kubectl get --raw "/api/v1/nodes/minikube/proxy/stats/summary"
|
||||
```
|
||||
|
||||
<!-- Here is the same API call using `curl`: -->
|
||||
这是使用 `curl` 来执行的相同 API 调用：
|
||||
|
||||
```shell
|
||||
curl http://localhost:8080/api/v1/nodes/minikube/proxy/stats/summary
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
The summary API `/stats/summary` endpoint will be replaced by the `/metrics/resource` endpoint
|
||||
beginning with metrics-server 0.6.x.
|
||||
-->
|
||||
从 metrics-server 0.6.x 开始，Summary API `/stats/summary` 端点被 `/metrics/resource` 端点替换。
|
||||
{{< /note >}}
|
||||
|
|
|
|||
|
|
@ -19,18 +19,20 @@ Cassandra, a database, needs persistent storage to provide data durability (appl
|
|||
In this example, a custom Cassandra seed provider lets the database discover new Cassandra instances as they join the Cassandra cluster.
|
||||
-->
|
||||
本教程描述拉如何在 Kubernetes 上运行 [Apache Cassandra](https://cassandra.apache.org/)。
|
||||
数据库 Cassandra 需要永久性存储提供数据持久性（应用 _状态_）。
|
||||
在此示例中，自定义 Cassandra seed provider 使数据库在加入 Cassandra 集群时发现新的 Cassandra 实例。
|
||||
数据库 Cassandra 需要永久性存储提供数据持久性（应用“状态”）。
|
||||
在此示例中，自定义 Cassandra seed provider 使数据库在加入 Cassandra
|
||||
集群时发现新的 Cassandra 实例。
|
||||
|
||||
<!--
|
||||
*StatefulSets* make it easier to deploy stateful applications into your Kubernetes cluster.
|
||||
For more information on the features used in this tutorial, see
|
||||
[StatefulSet](/docs/concepts/workloads/controllers/statefulset/).
|
||||
-->
|
||||
使用 *StatefulSets* 可以更轻松地将有状态的应用程序部署到你的 Kubernetes 集群中。
|
||||
使用"StatefulSets"可以更轻松地将有状态的应用程序部署到你的 Kubernetes 集群中。
|
||||
有关本教程中使用的功能的更多信息，
|
||||
参阅 [StatefulSet](/zh/docs/concepts/workloads/controllers/statefulset/)。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
Cassandra and Kubernetes both use the term _node_ to mean a member of a cluster. In this
|
||||
tutorial, the Pods that belong to the StatefulSet are Cassandra nodes and are members
|
||||
|
|
@ -38,9 +40,8 @@ of the Cassandra cluster (called a _ring_). When those Pods run in your Kubernet
|
|||
the Kubernetes control plane schedules those Pods onto Kubernetes
|
||||
{{< glossary_tooltip text="Nodes" term_id="node" >}}.
|
||||
-->
|
||||
{{< note >}}
|
||||
Cassandra 和 Kubernetes 都使用术语 _node_ 来表示集群的成员。
|
||||
在本教程中，属于 StatefulSet 的 Pod 是 Cassandra 节点，并且是 Cassandra 集群的成员（称为 _ring_）。
|
||||
Cassandra 和 Kubernetes 都使用术语“节点（node）”来表示集群的成员。
|
||||
在本教程中，属于 StatefulSet 的 Pod 是 Cassandra 节点，并且是 Cassandra 集群的成员（称为 “ring”）。
|
||||
当这些 Pod 在你的 Kubernetes 集群中运行时，Kubernetes 控制平面会将这些 Pod 调度到 Kubernetes 的
|
||||
{{< glossary_tooltip text="节点" term_id="node" >}}上。
|
||||
|
||||
|
|
@ -51,7 +52,8 @@ This tutorial deploys a custom Cassandra seed provider that lets the database di
|
|||
new Cassandra Pods as they appear inside your Kubernetes cluster.
|
||||
-->
|
||||
当 Cassandra 节点启动时，使用 _seed列表_ 来引导发现 ring 中其他节点。
|
||||
本教程部署了一个自定义的 Cassandra seed provider，使数据库可以发现新的 Cassandra Pod 出现在 Kubernetes 集群中。
|
||||
本教程部署了一个自定义的 Cassandra seed provider，使数据库可以发现新的 Cassandra Pod
|
||||
出现在 Kubernetes 集群中。
|
||||
{{< /note >}}
|
||||
|
||||
## {{% heading "objectives" %}}
|
||||
|
|
@ -69,7 +71,6 @@ new Cassandra Pods as they appear inside your Kubernetes cluster.
|
|||
* 修改 StatefulSet。
|
||||
* 删除 StatefulSet 及其 {{< glossary_tooltip text="Pod" term_id="pod" >}}.
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}}
|
||||
|
|
@ -81,7 +82,8 @@ To complete this tutorial, you should already have a basic familiarity with
|
|||
{{< glossary_tooltip text="StatefulSets" term_id="StatefulSet" >}}.
|
||||
-->
|
||||
要完成本教程，你应该已经熟悉 {{< glossary_tooltip text="Pod" term_id="pod" >}}，
|
||||
{{< glossary_tooltip text="Service" term_id="service" >}}和 {{< glossary_tooltip text="StatefulSet" term_id="StatefulSet" >}}。
|
||||
{{< glossary_tooltip text="Service" term_id="service" >}} 和
|
||||
{{< glossary_tooltip text="StatefulSet" term_id="StatefulSet" >}}。
|
||||
|
||||
<!--
|
||||
### Additional Minikube setup instructions
|
||||
|
|
@ -158,7 +160,7 @@ If you don't see a Service named `cassandra`, that means creation failed. Read
|
|||
for help troubleshooting common issues.
|
||||
-->
|
||||
如果没有看到名为 `cassandra` 的服务，则表示创建失败。
|
||||
请阅读[Debug Services](/zh/docs/tasks/debug-application-cluster/debug-service/)，以解决常见问题。
|
||||
请阅读[调试服务](/zh/docs/tasks/debug-application-cluster/debug-service/)，以解决常见问题。
|
||||
|
||||
<!--
|
||||
## Using a StatefulSet to create a Cassandra ring
|
||||
|
|
@ -212,83 +214,85 @@ kubectl apply -f cassandra-statefulset.yaml
|
|||
-->
|
||||
## 验证 Cassandra StatefulSet
|
||||
|
||||
1.获取 Cassandra StatefulSet:
|
||||
1. 获取 Cassandra StatefulSet:
|
||||
|
||||
```shell
|
||||
kubectl get statefulset cassandra
|
||||
```
|
||||
```shell
|
||||
kubectl get statefulset cassandra
|
||||
```
|
||||
|
||||
<!--
|
||||
<!--
|
||||
The response should be similar to:
|
||||
-->
|
||||
-->
|
||||
响应应该与此类似：
|
||||
|
||||
```
|
||||
NAME DESIRED CURRENT AGE
|
||||
cassandra 3 0 13s
|
||||
```
|
||||
```
|
||||
NAME DESIRED CURRENT AGE
|
||||
cassandra 3 0 13s
|
||||
```
|
||||
|
||||
<!--
|
||||
<!--
|
||||
The `StatefulSet` resource deploys Pods sequentially.
|
||||
|
||||
1. Get the Pods to see the ordered creation status:
|
||||
-->
|
||||
-->
|
||||
`StatefulSet` 资源会按顺序部署 Pod。
|
||||
|
||||
2.获取 Pod 查看已排序的创建状态：
|
||||
|
||||
```shell
|
||||
kubectl get pods -l="app=cassandra"
|
||||
```
|
||||
|
||||
<!--
|
||||
The response should be similar to:
|
||||
1. Get the Pods to see the ordered creation status:
|
||||
-->
|
||||
2. 获取 Pod 查看已排序的创建状态：
|
||||
|
||||
```shell
|
||||
kubectl get pods -l="app=cassandra"
|
||||
```
|
||||
|
||||
<!--
|
||||
The response should be similar to:
|
||||
-->
|
||||
响应应该与此类似：
|
||||
|
||||
```shell
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
cassandra-0 1/1 Running 0 1m
|
||||
cassandra-1 0/1 ContainerCreating 0 8s
|
||||
```
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
cassandra-0 1/1 Running 0 1m
|
||||
cassandra-1 0/1 ContainerCreating 0 8s
|
||||
```
|
||||
|
||||
<!--
|
||||
<!--
|
||||
It can take several minutes for all three Pods to deploy. Once they are deployed, the same command
|
||||
returns output similar to:
|
||||
-->
|
||||
-->
|
||||
这三个 Pod 要花几分钟的时间才能部署。部署之后，相同的命令将返回类似于以下的输出：
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
cassandra-0 1/1 Running 0 10m
|
||||
cassandra-1 1/1 Running 0 9m
|
||||
cassandra-2 1/1 Running 0 8m
|
||||
```
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
cassandra-0 1/1 Running 0 10m
|
||||
cassandra-1 1/1 Running 0 9m
|
||||
cassandra-2 1/1 Running 0 8m
|
||||
```
|
||||
<!--
|
||||
3. Run the Cassandra [nodetool](https://cwiki.apache.org/confluence/display/CASSANDRA2/NodeTool) inside the first Pod, to
|
||||
display the status of the ring.
|
||||
-->
|
||||
3.运行第一个 Pod 中的 Cassandra [nodetool](https://cwiki.apache.org/confluence/display/CASSANDRA2/NodeTool)，以显示 ring 的状态。
|
||||
3. 运行第一个 Pod 中的 Cassandra [nodetool](https://cwiki.apache.org/confluence/display/CASSANDRA2/NodeTool)，
|
||||
以显示 ring 的状态。
|
||||
|
||||
```shell
|
||||
kubectl exec -it cassandra-0 -- nodetool status
|
||||
```
|
||||
```shell
|
||||
kubectl exec -it cassandra-0 -- nodetool status
|
||||
```
|
||||
|
||||
<!--
|
||||
<!--
|
||||
The response should be similar to:
|
||||
-->
|
||||
-->
|
||||
响应应该与此类似：
|
||||
|
||||
```
|
||||
Datacenter: DC1-K8Demo
|
||||
======================
|
||||
Status=Up/Down
|
||||
|/ State=Normal/Leaving/Joining/Moving
|
||||
-- Address Load Tokens Owns (effective) Host ID Rack
|
||||
UN 172.17.0.5 83.57 KiB 32 74.0% e2dd09e6-d9d3-477e-96c5-45094c08db0f Rack1-K8Demo
|
||||
UN 172.17.0.4 101.04 KiB 32 58.8% f89d6835-3a42-4419-92b3-0e62cae1479c Rack1-K8Demo
|
||||
UN 172.17.0.6 84.74 KiB 32 67.1% a6a1e8c2-3dc5-4417-b1a0-26507af2aaad Rack1-K8Demo
|
||||
```
|
||||
```
|
||||
Datacenter: DC1-K8Demo
|
||||
======================
|
||||
Status=Up/Down
|
||||
|/ State=Normal/Leaving/Joining/Moving
|
||||
-- Address Load Tokens Owns (effective) Host ID Rack
|
||||
UN 172.17.0.5 83.57 KiB 32 74.0% e2dd09e6-d9d3-477e-96c5-45094c08db0f Rack1-K8Demo
|
||||
UN 172.17.0.4 101.04 KiB 32 58.8% f89d6835-3a42-4419-92b3-0e62cae1479c Rack1-K8Demo
|
||||
UN 172.17.0.6 84.74 KiB 32 67.1% a6a1e8c2-3dc5-4417-b1a0-26507af2aaad Rack1-K8Demo
|
||||
```
|
||||
|
||||
<!--
|
||||
## Modifying the Cassandra StatefulSet
|
||||
|
|
@ -301,16 +305,16 @@ Use `kubectl edit` to modify the size of a Cassandra StatefulSet.
|
|||
|
||||
使用 `kubectl edit` 修改 Cassandra StatefulSet 的大小。
|
||||
|
||||
1.运行以下命令：
|
||||
1. 运行以下命令：
|
||||
|
||||
```shell
|
||||
kubectl edit statefulset cassandra
|
||||
```
|
||||
```shell
|
||||
kubectl edit statefulset cassandra
|
||||
```
|
||||
|
||||
<!--
|
||||
<!--
|
||||
This command opens an editor in your terminal. The line you need to change is the `replicas` field.
|
||||
The following sample is an excerpt of the StatefulSet file:
|
||||
-->
|
||||
-->
|
||||
此命令你的终端中打开一个编辑器。需要更改的是 `replicas` 字段。下面是 StatefulSet 文件的片段示例：
|
||||
|
||||
```yaml
|
||||
|
|
@ -340,65 +344,65 @@ Use `kubectl edit` to modify the size of a Cassandra StatefulSet.
|
|||
|
||||
1. Get the Cassandra StatefulSet to verify your change:
|
||||
-->
|
||||
2.将副本数 (replicas) 更改为 4，然后保存清单。
|
||||
2. 将副本数（replicas）更改为 4，然后保存清单。
|
||||
|
||||
StatefulSet 现在可以扩展到运行 4 个 Pod。
|
||||
|
||||
3.获取 Cassandra StatefulSet 验证更改：
|
||||
3. 获取 Cassandra StatefulSet 验证更改：
|
||||
|
||||
```shell
|
||||
kubectl get statefulset cassandra
|
||||
```
|
||||
```shell
|
||||
kubectl get statefulset cassandra
|
||||
```
|
||||
|
||||
<!--
|
||||
<!--
|
||||
The response should be similar to:
|
||||
-->
|
||||
-->
|
||||
响应应该与此类似：
|
||||
|
||||
```
|
||||
NAME DESIRED CURRENT AGE
|
||||
cassandra 4 4 36m
|
||||
```
|
||||
```
|
||||
NAME DESIRED CURRENT AGE
|
||||
cassandra 4 4 36m
|
||||
```
|
||||
|
||||
## {{% heading "cleanup" %}}
|
||||
|
||||
<!--
|
||||
Deleting or scaling a StatefulSet down does not delete the volumes associated with the StatefulSet.
|
||||
This setting is for your safety because your data is more valuable than automatically purging all related StatefulSet resources.
|
||||
|
||||
{{< warning >}}
|
||||
Depending on the storage class and reclaim policy, deleting the *PersistentVolumeClaims* may cause the associated volumes
|
||||
to also be deleted. Never assume you'll be able to access data if its volume claims are deleted.
|
||||
{{< /warning >}}
|
||||
|
||||
1. Run the following commands (chained together into a single command) to delete everything in the Cassandra StatefulSet:
|
||||
-->
|
||||
删除或缩小 StatefulSet 不会删除与 StatefulSet 关联的卷。
|
||||
这个设置是出于安全考虑，因为你的数据比自动清除所有相关的 StatefulSet 资源更有价值。
|
||||
|
||||
{{< warning >}}
|
||||
<!--
|
||||
Depending on the storage class and reclaim policy, deleting the *PersistentVolumeClaims* may cause the associated volumes
|
||||
to also be deleted. Never assume you'll be able to access data if its volume claims are deleted.
|
||||
-->
|
||||
根据存储类和回收策略，删除 *PersistentVolumeClaims* 可能导致关联的卷也被删除。
|
||||
千万不要认为其容量声明被删除，你就能访问数据。
|
||||
{{< /warning >}}
|
||||
|
||||
1.运行以下命令（连在一起成为一个单独的命令）删除 Cassandra StatefulSet 中的所有内容：
|
||||
<!--
|
||||
1. Run the following commands (chained together into a single command) to delete everything in the Cassandra StatefulSet:
|
||||
-->
|
||||
1. 运行以下命令（连在一起成为一个单独的命令）删除 Cassandra StatefulSet 中的所有内容：
|
||||
|
||||
```shell
|
||||
grace=$(kubectl get pod cassandra-0 -o=jsonpath='{.spec.terminationGracePeriodSeconds}') \
|
||||
&& kubectl delete statefulset -l app=cassandra \
|
||||
&& echo "Sleeping ${grace} seconds" 1>&2 \
|
||||
&& sleep $grace \
|
||||
&& kubectl delete persistentvolumeclaim -l app=cassandra
|
||||
```
|
||||
```shell
|
||||
grace=$(kubectl get pod cassandra-0 -o=jsonpath='{.spec.terminationGracePeriodSeconds}') \
|
||||
&& kubectl delete statefulset -l app=cassandra \
|
||||
&& echo "Sleeping ${grace} seconds" 1>&2 \
|
||||
&& sleep $grace \
|
||||
&& kubectl delete persistentvolumeclaim -l app=cassandra
|
||||
```
|
||||
|
||||
<!--
|
||||
1. Run the following command to delete the Service you set up for Cassandra:
|
||||
-->
|
||||
2.运行以下命令，删除你为 Cassandra 设置的 Service：
|
||||
2. 运行以下命令，删除你为 Cassandra 设置的 Service：
|
||||
|
||||
```shell
|
||||
kubectl delete service -l app=cassandra
|
||||
```
|
||||
```shell
|
||||
kubectl delete service -l app=cassandra
|
||||
```
|
||||
|
||||
<!--
|
||||
## Cassandra container environment variables
|
||||
|
|
@ -412,21 +416,21 @@ This image includes a standard Cassandra installation from the Apache Debian rep
|
|||
By using environment variables you can change values that are inserted into `cassandra.yaml`.
|
||||
-->
|
||||
## Cassandra 容器环境变量
|
||||
本教程中的 Pod 使用来自 Google [container registry](https://cloud.google.com/container-registry/docs/)
|
||||
的 [`gcr.io/google-samples/cassandra:v13`](https://github.com/kubernetes/examples/blob/master/cassandra/image/Dockerfile) 镜像。
|
||||
上面的 Docker 镜像基于 [debian-base](https://github.com/kubernetes/release/tree/master/images/build/debian-base)，并且包含 OpenJDK 8。
|
||||
|
||||
本教程中的 Pod 使用来自 Google [容器镜像库](https://cloud.google.com/container-registry/docs/)
|
||||
的 [`gcr.io/google-samples/cassandra:v13`](https://github.com/kubernetes/examples/blob/master/cassandra/image/Dockerfile)
|
||||
镜像。上面的 Docker 镜像基于 [debian-base](https://github.com/kubernetes/release/tree/master/images/build/debian-base)，
|
||||
并且包含 OpenJDK 8。
|
||||
|
||||
该映像包括来自 Apache Debian 存储库的标准 Cassandra 安装。
|
||||
通过使用环境变量，您可以更改插入到 `cassandra.yaml` 中的值。
|
||||
|
||||
| Environment variable | Default value |
|
||||
| 环境变量 | 默认值 |
|
||||
| ------------------------ |:---------------: |
|
||||
| `CASSANDRA_CLUSTER_NAME` | `'Test Cluster'` |
|
||||
| `CASSANDRA_NUM_TOKENS` | `32` |
|
||||
| `CASSANDRA_RPC_ADDRESS` | `0.0.0.0` |
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
<!--
|
||||
|
|
@ -437,3 +441,4 @@ By using environment variables you can change values that are inserted into `cas
|
|||
* 了解如何[扩缩 StatefulSet](/docs/tasks/run-application/scale-stateful-set/)。
|
||||
* 了解有关 [*KubernetesSeedProvider*](https://github.com/kubernetes/examples/blob/master/cassandra/java/src/main/java/io/k8s/cassandra/KubernetesSeedProvider.java) 的更多信息
|
||||
* 查看更多自定义 [Seed Provider Configurations](https://git.k8s.io/examples/cassandra/java/README.md)
|
||||
|
||||
|
|
|
|||
|
|
@ -23,13 +23,13 @@ spec:
|
|||
mountPath: /var/log
|
||||
- name: count-log-1
|
||||
image: busybox:1.28
|
||||
args: [/bin/sh, -c, 'tail -n+1 -f /var/log/1.log']
|
||||
args: [/bin/sh, -c, 'tail -n+1 -F /var/log/1.log']
|
||||
volumeMounts:
|
||||
- name: varlog
|
||||
mountPath: /var/log
|
||||
- name: count-log-2
|
||||
image: busybox:1.28
|
||||
args: [/bin/sh, -c, 'tail -n+1 -f /var/log/2.log']
|
||||
args: [/bin/sh, -c, 'tail -n+1 -F /var/log/2.log']
|
||||
volumeMounts:
|
||||
- name: varlog
|
||||
mountPath: /var/log
|
||||
|
|
|
|||
|
|
@ -0,0 +1,15 @@
|
|||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: etcd-with-grpc
|
||||
spec:
|
||||
containers:
|
||||
- name: etcd
|
||||
image: k8s.gcr.io/etcd:3.5.1-0
|
||||
command: [ "/usr/local/bin/etcd", "--data-dir", "/var/lib/etcd", "--listen-client-urls", "http://0.0.0.0:2379", "--advertise-client-urls", "http://127.0.0.1:2379", "--log-level", "debug"]
|
||||
ports:
|
||||
- containerPort: 2379
|
||||
livenessProbe:
|
||||
grpc:
|
||||
port: 2379
|
||||
initialDelaySeconds: 10
|
||||
Loading…
Reference in New Issue