diff --git a/.github/OWNERS b/.github/OWNERS new file mode 100644 index 0000000000..594352be83 --- /dev/null +++ b/.github/OWNERS @@ -0,0 +1,7 @@ +# See the OWNERS docs at https://go.k8s.io/owners + +reviewers: +- sig-docs-en-reviews # Defined in OWNERS_ALIASES + +approvers: +- sig-docs-en-owners # Defined in OWNERS_ALIASES diff --git a/.github/workflows/OWNERS b/.github/workflows/OWNERS new file mode 100644 index 0000000000..404875fc2e --- /dev/null +++ b/.github/workflows/OWNERS @@ -0,0 +1,11 @@ +# See the OWNERS docs at https://go.k8s.io/owners + +# When modifying this file, consider the security implications of +# allowing listed reviewers / approvals to modify or remove any +# configured GitHub Actions. + +reviewers: +- sig-docs-leads + +approvers: +- sig-docs-leads diff --git a/config.toml b/config.toml index 227afab894..35c539a966 100644 --- a/config.toml +++ b/config.toml @@ -157,7 +157,7 @@ github_repo = "https://github.com/kubernetes/website" # param for displaying an announcement block on every page. # See /i18n/en.toml for message text and title. announcement = true -announcement_bg = "#3f0374" # choose a dark color – text is white +announcement_bg = "#3d4cb7" # choose a dark color – text is white #Searching k8s_search = true diff --git a/content/en/_index.html b/content/en/_index.html index b738a915ef..13a3c069be 100644 --- a/content/en/_index.html +++ b/content/en/_index.html @@ -8,7 +8,7 @@ sitemap: {{< blocks/section id="oceanNodes" >}} {{% blocks/feature image="flower" %}} -[Kubernetes (K8s)]({{< relref "/docs/concepts/overview/what-is-kubernetes" >}}) is an open-source system for automating deployment, scaling, and management of containerized applications. +[Kubernetes]({{< relref "/docs/concepts/overview/what-is-kubernetes" >}}), also known as K8s, is an open-source system for automating deployment, scaling, and management of containerized applications. It groups containers that make up an application into logical units for easy management and discovery. Kubernetes builds upon [15 years of experience of running production workloads at Google](http://queue.acm.org/detail.cfm?id=2898444), combined with best-of-breed ideas and practices from the community. {{% /blocks/feature %}} @@ -28,7 +28,7 @@ Whether testing locally or running a global enterprise, Kubernetes flexibility g {{% /blocks/feature %}} {{% blocks/feature image="suitcase" %}} -#### Run Anywhere +#### Run K8s Anywhere Kubernetes is open source giving you the freedom to take advantage of on-premises, hybrid, or public cloud infrastructure, letting you effortlessly move workloads to where it matters to you. diff --git a/content/en/blog/_posts/2020-11-18-cloud-native-security-for-your-cluster/cloud-native-app-lifecycle-phases.svg b/content/en/blog/_posts/2020-11-18-cloud-native-security-for-your-cluster/cloud-native-app-lifecycle-phases.svg new file mode 100644 index 0000000000..8ae1c26c57 --- /dev/null +++ b/content/en/blog/_posts/2020-11-18-cloud-native-security-for-your-cluster/cloud-native-app-lifecycle-phases.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/content/en/blog/_posts/2020-11-18-cloud-native-security-for-your-cluster/index.md b/content/en/blog/_posts/2020-11-18-cloud-native-security-for-your-cluster/index.md new file mode 100644 index 0000000000..900f8b07ee --- /dev/null +++ b/content/en/blog/_posts/2020-11-18-cloud-native-security-for-your-cluster/index.md @@ -0,0 +1,57 @@ +--- +layout: blog +title: "Cloud native security for your clusters" +date: 2020-11-18 +slug: cloud-native-security-for-your-clusters +--- + +**Author**: [Pushkar Joglekar](https://twitter.com/pudijoglekar) + +Over the last few years a small, security focused community has been working diligently to deepen our understanding of security, given the evolving cloud native infrastructure and corresponding iterative deployment practices. To enable sharing of this knowledge with the rest of the community, members of [CNCF SIG Security](https://github.com/cncf/sig-security) (a group which reports into [CNCF TOC](https://github.com/cncf/toc#sigs) and who are friends with [Kubernetes SIG Security](https://github.com/kubernetes/community/tree/master/sig-security)) led by Emily Fox, collaborated on a whitepaper outlining holistic cloud native security concerns and best practices. After over 1200 comments, changes, and discussions from 35 members across the world, we are proud to share [cloud native security whitepaper v1.0](https://www.cncf.io/blog/2020/11/18/announcing-the-cloud-native-security-white-paper) that serves as essential reading for security leadership in enterprises, financial and healthcare industries, academia, government, and non-profit organizations. + +The paper attempts to _not_ focus on any specific [cloud native project](https://www.cncf.io/projects/). Instead, the intent is to model and inject security into four logical phases of cloud native application lifecycle: _Develop, Distribute, Deploy, and Runtime_. + +Cloud native application lifecycle phases + + +## Kubernetes native security controls +When using Kubernetes as a workload orchestrator, some of the security controls this version of the whitepaper recommends are: +* [Pod Security Policies](/docs/concepts/policy/pod-security-policy/): Implement a single source of truth for “least privilege” workloads across the entire cluster +* [Resource requests and limits](/docs/concepts/configuration/manage-resources-containers/#requests-and-limits): Apply requests (soft constraint) and limits (hard constraint) for shared resources such as memory and CPU +* [Audit log analysis](/docs/tasks/debug-application-cluster/audit/): Enable Kubernetes API auditing and filtering for security relevant events +* [Control plane authentication and certificate root of trust](/docs/concepts/architecture/control-plane-node-communication/): Enable mutual TLS authentication with a trusted CA for communication within the cluster +* [Secrets management](/docs/concepts/configuration/secret/): Integrate with a built-in or external secrets store + +## Cloud native complementary security controls + +Kubernetes has direct involvement in the _deploy_ phase and to a lesser extent in the _runtime_ phase. Ensuring the artifacts are securely _developed_ and _distributed_ is necessary for, enabling workloads in Kubernetes to run “secure by default”. Throughout all phases of the Cloud native application life cycle, several complementary security controls exist for Kubernetes orchestrated workloads, which includes but are not limited to: +* Develop: + - Image signing and verification + - Image vulnerability scanners +* Distribute: + - Pre-deployment checks for detecting excessive privileges + - Enabling observability and logging +* Deploy: + - Using a service mesh for workload authentication and authorization + - Enforcing “default deny” network policies for inter-workload communication via [network plugins](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) +* Runtime: + - Deploying security monitoring agents for workloads + - Isolating applications that run on the same node using SELinux, AppArmor, etc. + - Scanning configuration against recognized secure baselines for node, workload and orchestrator + +## Understand first, secure next +The cloud native way, including containers, provides great security benefits for its users: immutability, modularity, faster upgrades and consistent state across the environment. Realizing this fundamental change in “the way things are done”, motivates us to look at security with a cloud native lens. One of the things that was evident for all the authors of the paper was the fact that it’s tough to make smarter decisions on how and what to secure in a cloud native ecosystem if you do not understand the tools, patterns, and frameworks at hand (in addition to knowing your own critical assets). Hence, for all the security practitioners out there who want to be partners rather than a gatekeeper for your friends in Operations, Product Development, and Compliance, let’s make an attempt to _learn more so we can secure better_. + +We recommend following this **7 step R.U.N.T.I.M.E. path** to get started on cloud native security: +1. Read the paper and any linked material in it +2. Understand challenges and constraints for your environment +3. Note the content and controls that apply to your environment +4. Talk about your observations with your peers +5. Involve your leadership and ask for help +6. Make a risk profile based on existing and missing security controls +7. Expend time, money, and resources that improve security posture and reduce risk where appropriate. + +## Acknowledgements +Huge shout out to _Emily Fox, Tim Bannister (The Scale Factory), Chase Pettet (Mirantis), and Wayne Haber (GitLab)_ for contributing with their wonderful suggestions for this blog post. diff --git a/content/en/docs/concepts/configuration/configmap.md b/content/en/docs/concepts/configuration/configmap.md index d6abd186b9..d9889604ce 100644 --- a/content/en/docs/concepts/configuration/configmap.md +++ b/content/en/docs/concepts/configuration/configmap.md @@ -31,7 +31,7 @@ This lets you fetch a container image running in the cloud and debug the exact same code locally if needed. A ConfigMap is not designed to hold large chunks of data. The data stored in a -ConfigMap cannot exeed 1 MiB. If you need to store settings that are +ConfigMap cannot exceed 1 MiB. If you need to store settings that are larger than this limit, you may want to consider mounting a volume or use a separate database or file service. @@ -88,7 +88,7 @@ data: There are four different ways that you can use a ConfigMap to configure a container inside a Pod: -1. Command line arguments to the entrypoint of a container +1. Inside a container command and args 1. Environment variables for a container 1. Add a file in read-only volume, for the application to read 1. Write code to run inside the Pod that uses the Kubernetes API to read a ConfigMap diff --git a/content/en/docs/concepts/services-networking/ingress-controllers.md b/content/en/docs/concepts/services-networking/ingress-controllers.md index 917f3412e3..54f11beeff 100644 --- a/content/en/docs/concepts/services-networking/ingress-controllers.md +++ b/content/en/docs/concepts/services-networking/ingress-controllers.md @@ -22,6 +22,8 @@ Kubernetes as a project currently supports and maintains [GCE](https://git.k8s.i ## Additional controllers +{{% thirdparty-content %}} + * [AKS Application Gateway Ingress Controller](https://github.com/Azure/application-gateway-kubernetes-ingress) is an ingress controller that enables ingress to [AKS clusters](https://docs.microsoft.com/azure/aks/kubernetes-walkthrough-portal) using the [Azure Application Gateway](https://docs.microsoft.com/azure/application-gateway/overview). * [Ambassador](https://www.getambassador.io/) API Gateway is an [Envoy](https://www.envoyproxy.io) based ingress controller with [community](https://www.getambassador.io/docs) or diff --git a/content/en/docs/concepts/storage/storage-classes.md b/content/en/docs/concepts/storage/storage-classes.md index 587cc8a501..e6846c7ea4 100644 --- a/content/en/docs/concepts/storage/storage-classes.md +++ b/content/en/docs/concepts/storage/storage-classes.md @@ -94,7 +94,7 @@ run, what volume plugin it uses (including Flex), etc. The repository [kubernetes-sigs/sig-storage-lib-external-provisioner](https://github.com/kubernetes-sigs/sig-storage-lib-external-provisioner) houses a library for writing external provisioners that implements the bulk of the specification. Some external provisioners are listed under the repository -[kubernetes-sigs/external-storage](https://github.com/kubernetes-sigs/external-dns). +[kubernetes-sigs/sig-storage-lib-external-provisioner](https://github.com/kubernetes-sigs/sig-storage-lib-external-provisioner). For example, NFS doesn't provide an internal provisioner, but an external provisioner can be used. There are also cases when 3rd party storage diff --git a/content/en/docs/concepts/workloads/controllers/statefulset.md b/content/en/docs/concepts/workloads/controllers/statefulset.md index 64cef43470..acdb681652 100644 --- a/content/en/docs/concepts/workloads/controllers/statefulset.md +++ b/content/en/docs/concepts/workloads/controllers/statefulset.md @@ -150,7 +150,7 @@ remembered and reused, even after the Pod is running, for at least a few seconds If you need to discover Pods promptly after they are created, you have a few options: - Query the Kubernetes API directly (for example, using a watch) rather than relying on DNS lookups. -- Decrease the time of caching in your Kubernetes DNS provider (tpyically this means editing the config map for CoreDNS, which currently caches for 30 seconds). +- Decrease the time of caching in your Kubernetes DNS provider (typically this means editing the config map for CoreDNS, which currently caches for 30 seconds). As mentioned in the [limitations](#limitations) section, you are responsible for diff --git a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md index 2269a15293..81822a7f17 100644 --- a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md @@ -142,7 +142,7 @@ The `restartPolicy` applies to all containers in the Pod. `restartPolicy` only refers to restarts of the containers by the kubelet on the same node. After containers in a Pod exit, the kubelet restarts them with an exponential back-off delay (10s, 20s, 40s, …), that is capped at five minutes. Once a container has executed for 10 minutes -without any problems, the kubelet resets the restart backoff timer forthat container. +without any problems, the kubelet resets the restart backoff timer for that container. ## Pod conditions diff --git a/content/en/docs/contribute/_index.md b/content/en/docs/contribute/_index.md index fb068856b6..1db65ec56d 100644 --- a/content/en/docs/contribute/_index.md +++ b/content/en/docs/contribute/_index.md @@ -1,6 +1,6 @@ --- content_type: concept -title: Contribute to Kubernetes docs +title: Contribute to K8s docs linktitle: Contribute main_menu: true no_list: true @@ -8,7 +8,7 @@ weight: 80 card: name: contribute weight: 10 - title: Start contributing + title: Start contributing to K8s --- diff --git a/content/en/docs/contribute/new-content/overview.md b/content/en/docs/contribute/new-content/overview.md index b1f7e4f20a..a7c6ab083e 100644 --- a/content/en/docs/contribute/new-content/overview.md +++ b/content/en/docs/contribute/new-content/overview.md @@ -43,7 +43,7 @@ When opening a pull request, you need to know in advance which branch to base yo Scenario | Branch :---------|:------------ Existing or new English language content for the current release | `master` -Content for a feature change release | The branch which corresponds to the major and minor version the feature change is in, using the pattern `dev-release-`. For example, if a feature changes in the `{{< latest-version >}}` release, then add documentation changes to the ``dev-{{< release-branch >}}`` branch. +Content for a feature change release | The branch which corresponds to the major and minor version the feature change is in, using the pattern `dev-`. For example, if a feature changes in the `v{{< skew nextMinorVersion >}}` release, then add documentation changes to the ``dev-{{< skew nextMinorVersion >}}`` branch. Content in other languages (localizations) | Use the localization's convention. See the [Localization branching strategy](/docs/contribute/localization/#branching-strategy) for more information. diff --git a/content/en/docs/home/_index.md b/content/en/docs/home/_index.md index 7ee48721f2..68f4bfd3c9 100644 --- a/content/en/docs/home/_index.md +++ b/content/en/docs/home/_index.md @@ -32,7 +32,7 @@ cards: button: "View Tutorials" button_path: "/docs/tutorials" - name: setup - title: "Set up a cluster" + title: "Set up a K8s cluster" description: "Get Kubernetes running based on your resources and needs." button: "Set up Kubernetes" button_path: "/docs/setup" @@ -57,7 +57,7 @@ cards: button: Contribute to the docs button_path: /docs/contribute - name: release-notes - title: Release Notes + title: K8s Release Notes description: If you are installing Kubernetes or upgrading to the newest version, refer to the current release notes. button: "Download Kubernetes" button_path: "/docs/setup/release/notes" diff --git a/content/en/docs/reference/command-line-tools-reference/feature-gates.md b/content/en/docs/reference/command-line-tools-reference/feature-gates.md index 894e972658..41029fa64c 100644 --- a/content/en/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/en/docs/reference/command-line-tools-reference/feature-gates.md @@ -143,13 +143,15 @@ different Kubernetes components. | `RotateKubeletServerCertificate` | `false` | Alpha | 1.7 | 1.11 | | `RotateKubeletServerCertificate` | `true` | Beta | 1.12 | | | `RunAsGroup` | `true` | Beta | 1.14 | | -| `ServiceAppProtocol` | `false` | Alpha | 1.18 | 1.18 | -| `ServiceAppProtocol` | `true` | Beta | 1.19 | | +| `RuntimeClass` | `false` | Alpha | 1.12 | 1.13 | +| `RuntimeClass` | `true` | Beta | 1.14 | | +| `SCTPSupport` | `false` | Alpha | 1.12 | 1.18 | +| `SCTPSupport` | `true` | Beta | 1.19 | | | `ServerSideApply` | `false` | Alpha | 1.14 | 1.15 | | `ServerSideApply` | `true` | Beta | 1.16 | | -| `ServiceAccountIssuerDiscovery` | `false` | Alpha | 1.18 | 1.19 | -| `ServiceAccountIssuerDiscovery` | `true` | Beta | 1.20 | | -| `ServiceAppProtocol` | `false` | Alpha | 1.18 | | +| `ServiceAccountIssuerDiscovery` | `false` | Alpha | 1.18 | | +| `ServiceAppProtocol` | `false` | Alpha | 1.18 | 1.18 | +| `ServiceAppProtocol` | `true` | Beta | 1.19 | | | `ServiceNodeExclusion` | `false` | Alpha | 1.8 | 1.18 | | `ServiceNodeExclusion` | `true` | Beta | 1.19 | | | `ServiceTopology` | `false` | Alpha | 1.17 | | diff --git a/content/en/docs/reference/using-api/health-checks.md b/content/en/docs/reference/using-api/health-checks.md index e0afae8aa8..2c315505db 100644 --- a/content/en/docs/reference/using-api/health-checks.md +++ b/content/en/docs/reference/using-api/health-checks.md @@ -27,15 +27,15 @@ The following examples will show how you can interact with the health API endpoi For all endpoints you can use the `verbose` parameter to print out the checks and their status. This can be useful for a human operator to debug the current status of the Api server, it is not intended to be consumed by a machine: - ```shell - curl -k https://localhost:6443/livez?verbose - ``` +```shell +curl -k https://localhost:6443/livez?verbose +``` or from a remote host with authentication: - ```shell - kubectl get --raw='/readyz?verbose' - ``` +```shell +kubectl get --raw='/readyz?verbose' +``` The output will look like this: @@ -62,9 +62,9 @@ The output will look like this: The Kubernetes API server also supports to exclude specific checks. The query parameters can also be combined like in this example: - ```shell - curl -k 'https://localhost:6443/readyz?verbose&exclude=etcd' - ``` +```shell +curl -k 'https://localhost:6443/readyz?verbose&exclude=etcd' +``` The output show that the `etcd` check is excluded: @@ -98,6 +98,6 @@ The schema for the individual health checks is `/livez/` where The `` path can be discovered using the `verbose` flag from above and take the path between `[+]` and `ok`. These individual health checks should not be consumed by machines but can be helpful for a human operator to debug a system: - ```shell - curl -k https://localhost:6443/livez/etcd - ``` +```shell +curl -k https://localhost:6443/livez/etcd +``` diff --git a/content/en/docs/setup/best-practices/node-conformance.md b/content/en/docs/setup/best-practices/node-conformance.md index af02a7a903..6a3822ef70 100644 --- a/content/en/docs/setup/best-practices/node-conformance.md +++ b/content/en/docs/setup/best-practices/node-conformance.md @@ -25,10 +25,11 @@ daemons installed: ## Running Node Conformance Test To run the node conformance test, perform the following steps: - -1. Point your Kubelet to localhost `--api-servers="http://localhost:8080"`, -because the test framework starts a local master to test Kubelet. There are some -other Kubelet flags you may care: +1. Work out the value of the `--kubeconfig` option for the kubelet; for example: + `--kubeconfig=/var/lib/kubelet/config.yaml`. + Because the test framework starts a local control plane to test the kubelet, + use `http://localhost:8080` as the URL of the API server. + There are some other kubelet command line parameters you may want to use: * `--pod-cidr`: If you are using `kubenet`, you should specify an arbitrary CIDR to Kubelet, for example `--pod-cidr=10.180.0.0/24`. * `--cloud-provider`: If you are using `--cloud-provider=gce`, you should diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md index 69c96ca08f..6f62a051ad 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md @@ -50,7 +50,7 @@ this example. 1. Configure the kubelet to be a service manager for etcd. - + {{< note >}}You must do this on every host where etcd should be running.{{< /note >}} Since etcd was created first, you must override the service priority by creating a new unit file that has higher precedence than the kubeadm-provided kubelet unit file. @@ -68,6 +68,12 @@ this example. systemctl restart kubelet ``` + Check the kubelet status to ensure it is running. + + ```sh + systemctl status kubelet + ``` + 1. Create configuration files for kubeadm. Generate one kubeadm configuration file for each host that will have an etcd diff --git a/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md b/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md index c3498fce61..ed498b1319 100644 --- a/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md +++ b/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md @@ -140,7 +140,7 @@ curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/dow ### Joining a Windows worker node {{< note >}} You must install the `Containers` feature and install Docker. Instructions -to do so are available at [Install Docker Engine - Enterprise on Windows Servers](https://docs.mirantis.com/docker-enterprise/v3.1/dockeree-products/docker-engine-enterprise/dee-windows.html). +to do so are available at [Install Docker Engine - Enterprise on Windows Servers](https://hub.docker.com/editions/enterprise/docker-ee-server-windows). {{< /note >}} {{< note >}} diff --git a/content/en/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/en/docs/tasks/configure-pod-container/configure-pod-configmap.md index 42eff59db0..2824cce642 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/en/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -532,7 +532,7 @@ This functionality is available in Kubernetes v1.6 and later. ## Use ConfigMap-defined environment variables in Pod commands -You can use ConfigMap-defined environment variables in the `command` section of the Pod specification using the `$(VAR_NAME)` Kubernetes substitution syntax. +You can use ConfigMap-defined environment variables in the `command` and `args` of a container using the `$(VAR_NAME)` Kubernetes substitution syntax. For example, the following Pod specification diff --git a/content/en/docs/tasks/extend-kubernetes/setup-konnectivity.md b/content/en/docs/tasks/extend-kubernetes/setup-konnectivity.md index da9dabb135..82eecc9c38 100644 --- a/content/en/docs/tasks/extend-kubernetes/setup-konnectivity.md +++ b/content/en/docs/tasks/extend-kubernetes/setup-konnectivity.md @@ -24,10 +24,35 @@ The following steps require an egress configuration, for example: You need to configure the API Server to use the Konnectivity service and direct the network traffic to the cluster nodes: +1. Make sure that +the `ServiceAccountTokenVolumeProjection` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) +is enabled. You can enable +[service account token volume protection](/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection) +by providing the following flags to the kube-apiserver: + ``` + --service-account-issuer=api + --service-account-signing-key-file=/etc/kubernetes/pki/sa.key + --api-audiences=system:konnectivity-server + ``` 1. Create an egress configuration file such as `admin/konnectivity/egress-selector-configuration.yaml`. 1. Set the `--egress-selector-config-file` flag of the API Server to the path of your API Server egress configuration file. +Generate or obtain a certificate and kubeconfig for konnectivity-server. +For example, you can use the OpenSSL command line tool to issue a X.509 certificate, +using the cluster CA certificate `/etc/kubernetes/pki/ca.crt` from a control-plane host. + +```bash +openssl req -subj "/CN=system:konnectivity-server" -new -newkey rsa:2048 -nodes -out konnectivity.csr -keyout konnectivity.key -out konnectivity.csr +openssl x509 -req -in konnectivity.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out konnectivity.crt -days 375 -sha256 +SERVER=$(kubectl config view -o jsonpath='{.clusters..server}') +kubectl --kubeconfig /etc/kubernetes/konnectivity-server.conf config set-credentials system:konnectivity-server --client-certificate konnectivity.crt --client-key konnectivity.key --embed-certs=true +kubectl --kubeconfig /etc/kubernetes/konnectivity-server.conf config set-cluster kubernetes --server "$SERVER" --certificate-authority /etc/kubernetes/pki/ca.crt --embed-certs=true +kubectl --kubeconfig /etc/kubernetes/konnectivity-server.conf config set-context system:konnectivity-server@kubernetes --cluster kubernetes --user system:konnectivity-server +kubectl --kubeconfig /etc/kubernetes/konnectivity-server.conf config use-context system:konnectivity-server@kubernetes +rm -f konnectivity.crt konnectivity.key konnectivity.csr +``` + Next, you need to deploy the Konnectivity server and agents. [kubernetes-sigs/apiserver-network-proxy](https://github.com/kubernetes-sigs/apiserver-network-proxy) is a reference implementation. diff --git a/content/en/docs/tutorials/stateful-application/zookeeper.md b/content/en/docs/tutorials/stateful-application/zookeeper.md index 9c93671b34..c044532e5f 100644 --- a/content/en/docs/tutorials/stateful-application/zookeeper.md +++ b/content/en/docs/tutorials/stateful-application/zookeeper.md @@ -46,7 +46,7 @@ tutorial. After this tutorial, you will know the following. - How to deploy a ZooKeeper ensemble using StatefulSet. -- How to consistently configure the ensemble using ConfigMaps. +- How to consistently configure the ensemble. - How to spread the deployment of ZooKeeper servers in the ensemble. - How to use PodDisruptionBudgets to ensure service availability during planned maintenance. @@ -770,7 +770,7 @@ In one terminal window, use the following command to watch the Pods in the `zk` kubectl get pod -w -l app=zk ``` -In another window, using the following command to delete the `zkOk.sh` script from the file system of Pod `zk-0`. +In another window, using the following command to delete the `zookeeper-ready` script from the file system of Pod `zk-0`. ```shell kubectl exec zk-0 -- rm /usr/bin/zookeeper-ready diff --git a/content/en/examples/admin/konnectivity/egress-selector-configuration.yaml b/content/en/examples/admin/konnectivity/egress-selector-configuration.yaml index 6659ff3fbb..c85f25ea51 100644 --- a/content/en/examples/admin/konnectivity/egress-selector-configuration.yaml +++ b/content/en/examples/admin/konnectivity/egress-selector-configuration.yaml @@ -18,4 +18,4 @@ egressSelections: # The other supported transport is "tcp". You will need to set up TLS # config to secure the TCP transport. uds: - udsName: /etc/srv/kubernetes/konnectivity-server/konnectivity-server.socket + udsName: /etc/kubernetes/konnectivity-server/konnectivity-server.socket diff --git a/content/en/examples/admin/konnectivity/konnectivity-agent.yaml b/content/en/examples/admin/konnectivity/konnectivity-agent.yaml index c3dc71040b..3c71999427 100644 --- a/content/en/examples/admin/konnectivity/konnectivity-agent.yaml +++ b/content/en/examples/admin/konnectivity/konnectivity-agent.yaml @@ -22,7 +22,7 @@ spec: - key: "CriticalAddonsOnly" operator: "Exists" containers: - - image: us.gcr.io/k8s-artifacts-prod/kas-network-proxy/proxy-agent:v0.0.8 + - image: us.gcr.io/k8s-artifacts-prod/kas-network-proxy/proxy-agent:v0.0.12 name: konnectivity-agent command: ["/proxy-agent"] args: [ @@ -32,6 +32,8 @@ spec: # this is the IP address of the master machine. "--proxy-server-host=35.225.206.7", "--proxy-server-port=8132", + "--admin-server-port=8133", + "--health-server-port=8134", "--service-account-token-path=/var/run/secrets/tokens/konnectivity-agent-token" ] volumeMounts: @@ -39,7 +41,7 @@ spec: name: konnectivity-agent-token livenessProbe: httpGet: - port: 8093 + port: 8134 path: /healthz initialDelaySeconds: 15 timeoutSeconds: 15 diff --git a/content/en/examples/admin/konnectivity/konnectivity-server.yaml b/content/en/examples/admin/konnectivity/konnectivity-server.yaml index 730c26c66a..a0f45af5ff 100644 --- a/content/en/examples/admin/konnectivity/konnectivity-server.yaml +++ b/content/en/examples/admin/konnectivity/konnectivity-server.yaml @@ -8,34 +8,33 @@ spec: hostNetwork: true containers: - name: konnectivity-server-container - image: us.gcr.io/k8s-artifacts-prod/kas-network-proxy/proxy-server:v0.0.8 + image: us.gcr.io/k8s-artifacts-prod/kas-network-proxy/proxy-server:v0.0.12 command: ["/proxy-server"] args: [ - "--log-file=/var/log/konnectivity-server.log", - "--logtostderr=false", - "--log-file-max-size=0", + "--logtostderr=true", # This needs to be consistent with the value set in egressSelectorConfiguration. - "--uds-name=/etc/srv/kubernetes/konnectivity-server/konnectivity-server.socket", + "--uds-name=/etc/kubernetes/konnectivity-server/konnectivity-server.socket", # The following two lines assume the Konnectivity server is # deployed on the same machine as the apiserver, and the certs and # key of the API Server are at the specified location. - "--cluster-cert=/etc/srv/kubernetes/pki/apiserver.crt", - "--cluster-key=/etc/srv/kubernetes/pki/apiserver.key", + "--cluster-cert=/etc/kubernetes/pki/apiserver.crt", + "--cluster-key=/etc/kubernetes/pki/apiserver.key", # This needs to be consistent with the value set in egressSelectorConfiguration. "--mode=grpc", "--server-port=0", "--agent-port=8132", "--admin-port=8133", + "--health-port=8134", "--agent-namespace=kube-system", "--agent-service-account=konnectivity-agent", - "--kubeconfig=/etc/srv/kubernetes/konnectivity-server/kubeconfig", + "--kubeconfig=/etc/kubernetes/konnectivity-server.conf", "--authentication-audience=system:konnectivity-server" ] livenessProbe: httpGet: scheme: HTTP host: 127.0.0.1 - port: 8133 + port: 8134 path: /healthz initialDelaySeconds: 30 timeoutSeconds: 60 @@ -46,25 +45,28 @@ spec: - name: adminport containerPort: 8133 hostPort: 8133 + - name: healthport + containerPort: 8134 + hostPort: 8134 volumeMounts: - - name: varlogkonnectivityserver - mountPath: /var/log/konnectivity-server.log - readOnly: false - - name: pki - mountPath: /etc/srv/kubernetes/pki + - name: k8s-certs + mountPath: /etc/kubernetes/pki + readOnly: true + - name: kubeconfig + mountPath: /etc/kubernetes/konnectivity-server.conf readOnly: true - name: konnectivity-uds - mountPath: /etc/srv/kubernetes/konnectivity-server + mountPath: /etc/kubernetes/konnectivity-server readOnly: false volumes: - - name: varlogkonnectivityserver + - name: k8s-certs hostPath: - path: /var/log/konnectivity-server.log + path: /etc/kubernetes/pki + - name: kubeconfig + hostPath: + path: /etc/kubernetes/konnectivity-server.conf type: FileOrCreate - - name: pki - hostPath: - path: /etc/srv/kubernetes/pki - name: konnectivity-uds hostPath: - path: /etc/srv/kubernetes/konnectivity-server + path: /etc/kubernetes/konnectivity-server type: DirectoryOrCreate diff --git a/content/en/examples/pods/pod-configmap-env-var-valueFrom.yaml b/content/en/examples/pods/pod-configmap-env-var-valueFrom.yaml index a72b4335ce..00827ec98a 100644 --- a/content/en/examples/pods/pod-configmap-env-var-valueFrom.yaml +++ b/content/en/examples/pods/pod-configmap-env-var-valueFrom.yaml @@ -6,7 +6,7 @@ spec: containers: - name: test-container image: k8s.gcr.io/busybox - command: [ "/bin/sh", "-c", "echo $(SPECIAL_LEVEL_KEY) $(SPECIAL_TYPE_KEY)" ] + command: [ "/bin/echo", "$(SPECIAL_LEVEL_KEY) $(SPECIAL_TYPE_KEY)" ] env: - name: SPECIAL_LEVEL_KEY valueFrom: diff --git a/content/en/training/_index.html b/content/en/training/_index.html index d7437a45de..5b94d73bac 100644 --- a/content/en/training/_index.html +++ b/content/en/training/_index.html @@ -10,16 +10,19 @@ class: training
-
- -
-
- -

Build your cloud native career

Kubernetes is at the core of the cloud native movement. Training and certifications from the Linux Foundation and our training partners lets you invest in your career, learn Kubernetes, and make your cloud native projects successful.

+
+ +
+
+ +
+
+ +
@@ -74,31 +77,36 @@ class: training -
+
-
-

Get Kubernetes Certified

-
+

Get Kubernetes Certified

-
Certified Kubernetes Application Developer (CKAD)

The Certified Kubernetes Application Developer exam certifies that users can design, build, configure, and expose cloud native applications for Kubernetes.

+

A CKAD can define application resources and use core primitives to build, monitor, and troubleshoot scalable applications and tools in Kubernetes.


Go to Certification -
-
Certified Kubernetes Administrator (CKA)

The Certified Kubernetes Administrator (CKA) program provides assurance that CKAs have the skills, knowledge, and competency to perform the responsibilities of Kubernetes administrators.

+

A certified Kubernetes administrator has demonstrated the ability to do basic installation as well as configuring and managing production-grade Kubernetes clusters.


Go to Certification -
+
+
+
+ Certified Kubernetes Security Specialist (CKS) +
+

The Certified Kubernetes Security Specialist program provides assurance that the holder is comfortable and competent with a broad range of best practices. CKS certification covers skills for securing container-based applications and Kubernetes platforms during build, deployment and runtime.

+

Candidates for CKS must hold a current Certified Kubernetes Administrator (CKA) certification to demonstrate they possess sufficient Kubernetes expertise before sitting for the CKS.

+
+ Go to Certification
diff --git a/content/es/docs/concepts/workloads/controllers/replicaset.md b/content/es/docs/concepts/workloads/controllers/replicaset.md index 38bbf847c6..70ba5ac832 100644 --- a/content/es/docs/concepts/workloads/controllers/replicaset.md +++ b/content/es/docs/concepts/workloads/controllers/replicaset.md @@ -34,7 +34,7 @@ este será inmediatamente adquirido por dicho ReplicaSet. ## Cuándo usar un ReplicaSet -Un ReplicaSet garantiza que un número específico de réplicas de un pod se está ejeuctando en todo momento. +Un ReplicaSet garantiza que un número específico de réplicas de un pod se está ejecutando en todo momento. Sin embargo, un Deployment es un concepto de más alto nivel que gestiona ReplicaSets y proporciona actualizaciones de forma declarativa de los Pods junto con muchas otras características útiles. Por lo tanto, se recomienda el uso de Deployments en vez del uso directo de ReplicaSets, a no ser diff --git a/content/fr/docs/concepts/configuration/secret.md b/content/fr/docs/concepts/configuration/secret.md index 79b9e2e533..1b7cd5314b 100644 --- a/content/fr/docs/concepts/configuration/secret.md +++ b/content/fr/docs/concepts/configuration/secret.md @@ -217,7 +217,7 @@ type: Opaque data: username: YWRtaW4= stringData: - username: administrator + username: administrateur ``` Donnera le secret suivant: @@ -233,10 +233,10 @@ metadata: uid: 91460ecb-e917-11e8-98f2-025000000001 type: Opaque data: - username: YWRtaW5pc3RyYXRvcg== + username: YWRtaW5pc3RyYXRldXI= ``` -Où `YWRtaW5pc3RyYXRvcg ==` décode en `administrateur`. +Où `YWRtaW5pc3RyYXRldXI=` décode en `administrateur`. Les clés de `data` et `stringData` doivent être composées de caractères alphanumériques, '-', '_' ou '.'. diff --git a/content/id/docs/concepts/workloads/pods/pod.md b/content/id/docs/concepts/workloads/pods/pod.md index e25a3a9104..63ee548459 100644 --- a/content/id/docs/concepts/workloads/pods/pod.md +++ b/content/id/docs/concepts/workloads/pods/pod.md @@ -109,7 +109,7 @@ Pod dapat digunakan untuk menjalankan beberapa aplikasi yang terintegrasi secara vertikal (misalnya LAMP), namun motivasi utamanya adalah untuk mendukung berlokasi bersama, mengelola program pembantu, diantaranya adalah: -* sistem pengelolaan konten, pemuat file dan data, manajer _cache_ lokal, dll. +* sistem pengelolaan konten, pemuat berkas dan data, manajer _cache_ lokal, dll. * catatan dan _checkpoint_ cadangan, kompresi, rotasi, dll. * pengamat perubahan data, pengintip catatan, adapter pencatatan dan pemantauan, penerbit peristiwa, dll. diff --git a/content/ja/docs/concepts/security/pod-security-standards.md b/content/ja/docs/concepts/security/pod-security-standards.md new file mode 100644 index 0000000000..7b0f16dff1 --- /dev/null +++ b/content/ja/docs/concepts/security/pod-security-standards.md @@ -0,0 +1,297 @@ +--- +title: Podセキュリティの標準 +content_type: concept +weight: 10 +--- + + + +Podに対するセキュリティの設定は通常[Security Context](/docs/tasks/configure-pod-container/security-context/)を使用して適用されます。Security ContextはPod単位での特権やアクセスコントロールの定義を実現します。 + +クラスターにおけるSecurity Contextの強制やポリシーベースの定義は[Pod Security Policy](/docs/concepts/policy/pod-security-policy/)によって実現されてきました。 +_Pod Security Policy_ はクラスターレベルのリソースで、Pod定義のセキュリティに関する設定を制御します。 + +しかし、PodSecurityPolicyを拡張したり代替する、ポリシーを強制するための多くの方法が生まれてきました。 +このページの意図は、推奨されるPodのセキュリティプロファイルを特定の実装から切り離して詳しく説明することです。 + + + + + +## ポリシーの種別 + +まず、幅広いセキュリティの範囲をカバーできる、基礎となるポリシーの定義が必要です。 +それらは強く制限をかけるものから自由度の高いものまでをカバーすべきです。 + +- **_特権_** - 制限のかかっていないポリシーで、可能な限り幅広い権限を提供します。このポリシーは既知の特権昇格を認めます。 +- **_ベースライン、デフォルト_** - 制限は最小限にされたポリシーですが、既知の特権昇格を防止します。デフォルト（最小の指定）のPod設定を許容します。 +- **_制限_** - 厳しく制限されたポリシーで、Podを強化するための現在のベストプラクティスに沿っています。 + +## ポリシー + +### 特権 + +特権ポリシーは意図的に開放されていて、完全に制限がかけられていません。この種のポリシーは通常、特権ユーザーまたは信頼されたユーザーが管理する、システムまたはインフラレベルのワークロードに対して適用されることを意図しています。 + +特権ポリシーは制限がないことと定義されます。gatekeeperのようにデフォルトで許可される仕組みでは、特権プロファイルはポリシーを設定せず、何も制限を適用しないことにあたります。 +一方で、Pod Security Policyのようにデフォルトで拒否される仕組みでは、特権ポリシーでは全ての制限を無効化してコントロールできるようにする必要があります。 + +### ベースライン、デフォルト + +ベースライン、デフォルトのプロファイルは一般的なコンテナ化されたランタイムに適用しやすく、かつ既知の特権昇格を防ぐことを意図しています。 +このポリシーはクリティカルではないアプリケーションの運用者または開発者を対象にしています。 +次の項目は強制、または無効化すべきです。 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ベースラインポリシーの定義
項目ポリシー
ホストのネームスペース + ホストのネームスペースの共有は無効化すべきです。
+
制限されるフィールド:
+ spec.hostNetwork
+ spec.hostPID
+ spec.hostIPC
+
認められる値: false
+
特権コンテナ + 特権を持つPodはほとんどのセキュリティ機構を無効化できるので、禁止すべきです。
+
制限されるフィールド:
+ spec.containers[*].securityContext.privileged
+ spec.initContainers[*].securityContext.privileged
+
認められる値: false, undefined/nil
+
ケーパビリティー + デフォルトよりも多くのケーパビリティーを与えることは禁止すべきです。
+
制限されるフィールド:
+ spec.containers[*].securityContext.capabilities.add
+ spec.initContainers[*].securityContext.capabilities.add
+
認められる値: 空 (または既知のリストに限定)
+
HostPathボリューム + HostPathボリュームは禁止すべきです。
+
制限されるフィールド:
+ spec.volumes[*].hostPath
+
認められる値: undefined/nil
+
ホストのポート + HostPortは禁止するか、最小限の既知のリストに限定すべきです。
+
制限されるフィールド:
+ spec.containers[*].ports[*].hostPort
+ spec.initContainers[*].ports[*].hostPort
+
認められる値: 0, undefined (または既知のリストに限定)
+
AppArmor (任意) + サポートされるホストでは、AppArmorの'runtime/default'プロファイルがデフォルトで適用されます。デフォルトのポリシーはポリシーの上書きや無効化を防ぎ、許可されたポリシーのセットを上書きできないよう制限すべきです。
+
制限されるフィールド:
+ metadata.annotations['container.apparmor.security.beta.kubernetes.io/*']
+
認められる値: 'runtime/default', undefined
+
SELinux (任意) + SELinuxのオプションをカスタムで設定することは禁止すべきです。
+
制限されるフィールド:
+ spec.securityContext.seLinuxOptions
+ spec.containers[*].securityContext.seLinuxOptions
+ spec.initContainers[*].securityContext.seLinuxOptions
+
認められる値: undefined/nil
+
/procマウントタイプ + 攻撃対象を縮小するため/procのマスクを設定し、必須とすべきです。
+
制限されるフィールド:
+ spec.containers[*].securityContext.procMount
+ spec.initContainers[*].securityContext.procMount
+
認められる値: undefined/nil, 'Default'
+
Sysctl + Sysctlはセキュリティ機構を無効化したり、ホストの全てのコンテナに影響を与えたりすることが可能なので、「安全」なサブネットを除いては禁止すべきです。 + コンテナまたはPodの中にsysctlがありネームスペースが分離されていて、同じノードの別のPodやプロセスから分離されている場合はsysctlは安全だと考えられます。
+
制限されるフィールド:
+ spec.securityContext.sysctls
+
認められる値:
+ kernel.shm_rmid_forced
+ net.ipv4.ip_local_port_range
+ net.ipv4.tcp_syncookies
+ net.ipv4.ping_group_range
+ undefined/空文字列
+
+ +### 制限 + +制限ポリシーはいくらかの互換性を犠牲にして、Podを強化するためのベストプラクティスを強制することを意図しています。 +セキュリティ上クリティカルなアプリケーションの運用者や開発者、また信頼度の低いユーザーも対象にしています。 +下記の項目を強制、無効化すべきです。 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
制限ポリシーの定義
項目ポリシー
デフォルトプロファイルにある項目全て
Volumeタイプ + HostPathボリュームの制限に加え、制限プロファイルではコアでない種類のボリュームの利用をPersistentVolumeにより定義されたものに限定します。
+
制限されるフィールド:
+ spec.volumes[*].hostPath
+ spec.volumes[*].gcePersistentDisk
+ spec.volumes[*].awsElasticBlockStore
+ spec.volumes[*].gitRepo
+ spec.volumes[*].nfs
+ spec.volumes[*].iscsi
+ spec.volumes[*].glusterfs
+ spec.volumes[*].rbd
+ spec.volumes[*].flexVolume
+ spec.volumes[*].cinder
+ spec.volumes[*].cephFS
+ spec.volumes[*].flocker
+ spec.volumes[*].fc
+ spec.volumes[*].azureFile
+ spec.volumes[*].vsphereVolume
+ spec.volumes[*].quobyte
+ spec.volumes[*].azureDisk
+ spec.volumes[*].portworxVolume
+ spec.volumes[*].scaleIO
+ spec.volumes[*].storageos
+ spec.volumes[*].csi
+
認められる値: undefined/nil
+
特権昇格 + 特権昇格(ファイルモードのset-user-IDまたはset-group-IDのような方法による)は禁止すべきです。
+
制限されるフィールド:
+ spec.containers[*].securityContext.allowPrivilegeEscalation
+ spec.initContainers[*].securityContext.allowPrivilegeEscalation
+
認められる値: false
+
root以外での実行 + コンテナはroot以外のユーザーで実行する必要があります。
+
制限されるフィールド:
+ spec.securityContext.runAsNonRoot
+ spec.containers[*].securityContext.runAsNonRoot
+ spec.initContainers[*].securityContext.runAsNonRoot
+
認められる値: true
+
root以外のグループ (任意) + コンテナをrootのプライマリまたは補助GIDで実行することを禁止すべきです。
+
制限されるフィールド:
+ spec.securityContext.runAsGroup
+ spec.securityContext.supplementalGroups[*]
+ spec.securityContext.fsGroup
+ spec.containers[*].securityContext.runAsGroup
+ spec.initContainers[*].securityContext.runAsGroup
+
認められる値:
+ 0以外
+ undefined / nil (`*.runAsGroup`を除く)
+
Seccomp + SeccompのRuntimeDefaultを必須とする、または特定の追加プロファイルを許可することが必要です。
+
制限されるフィールド:
+ spec.securityContext.seccompProfile.type
+ spec.containers[*].securityContext.seccompProfile
+ spec.initContainers[*].securityContext.seccompProfile
+
認められる値:
+ 'runtime/default'
+ undefined / nil
+
+ +## ポリシーの実例 + +ポリシーの定義とポリシーの実装を切り離すことによって、ポリシーを強制する機構とは独立して、汎用的な理解や複数のクラスターにわたる共通言語とすることができます。 + +機構が成熟してきたら、ポリシーごとに下記に定義されます。それぞれのポリシーを強制する方法についてはここでは定義しません。 + +[**PodSecurityPolicy**](/docs/concepts/policy/pod-security-policy/) + +- [特権](https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/policy/privileged-psp.yaml) +- [ベースライン](https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/policy/baseline-psp.yaml) +- [制限](https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/policy/restricted-psp.yaml) + +## FAQ + +### 特権とデフォルトの間のプロファイルがないのはどうしてですか? + +ここで定義されている3つのプロファイルは最も安全(制限)から最も安全ではない(特権)まで、直線的に段階が設定されており、幅広いワークロードをカバーしています。 +ベースラインを超える特権が必要な場合、その多くはアプリケーションに特化しているため、その限られた要求に対して標準的なプロファイルを提供することはできません。 +これは、このような場合に必ず特権プロファイルを使用すべきだという意味ではなく、場合に応じてポリシーを定義する必要があります。 + +将来、他のプロファイルの必要性が明らかになった場合、SIG Authはこの方針について再考する可能性があります。 + +### セキュリティポリシーとセキュリティコンテキストの違いは何ですか? + +[Security Context](/docs/tasks/configure-pod-container/security-context/)は実行時のコンテナやPodを設定するものです。 +Security ContextはPodのマニフェストの中でPodやコンテナの仕様の一部として定義され、コンテナランタイムへ渡されるパラメータを示します。 + +セキュリティポリシーはコントロールプレーンの機構で、Security Contextとそれ以外も含め、特定の設定を強制するものです。 +2020年2月時点では、ネイティブにサポートされているポリシー強制の機構は[Pod Security +Policy](/docs/concepts/policy/pod-security-policy/)です。これはクラスター全体にわたってセキュリティポリシーを中央集権的に強制するものです。 +セキュリティポリシーを強制する他の手段もKubernetesのエコシステムでは開発が進められています。例えば[OPA +Gatekeeper](https://github.com/open-policy-agent/gatekeeper)があります。 + +### WindowsのPodにはどのプロファイルを適用すればよいですか? + +Kubernetesでは、Linuxベースのワークロードと比べてWindowsの使用は制限や差異があります。 +特に、PodのSecurityContextフィールドは[Windows環境では効果がありません](/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#v1-podsecuritycontext)。 +したがって、現段階では標準化されたセキュリティポリシーは存在しません。 + +### サンドボックス化されたPodはどのように扱えばよいでしょうか? + +現在のところ、Podがサンドボックス化されていると見なされるかどうかを制御できるAPI標準はありません。 +サンドボックス化されたPodはサンドボックス化されたランタイム（例えばgVisorやKata Containers）の使用により特定することは可能ですが、サンドボックス化されたランタイムの標準的な定義は存在しません。 + +サンドボックス化されたランタイムに対して必要な保護は、それ以外に対するものとは異なります。 +例えば、ワークロードがその基になるカーネルと分離されている場合、特権を制限する必要性は小さくなります。 +これにより、強い権限を必要とするワークロードが隔離された状態を維持できます。 + +加えて、サンドボックス化されたワークロードの保護はサンドボックス化の実装に強く依存します。 +したがって、全てのサンドボックス化されたワークロードに推奨される単一のポリシーは存在しません。 diff --git a/content/ja/docs/reference/kubectl/cheatsheet.md b/content/ja/docs/reference/kubectl/cheatsheet.md index 47a9c157c9..caf2fc783c 100644 --- a/content/ja/docs/reference/kubectl/cheatsheet.md +++ b/content/ja/docs/reference/kubectl/cheatsheet.md @@ -214,10 +214,6 @@ kubectl get pods -o json | jq -c 'path(..)|[.[]|tostring]|join(".")' ## リソースのアップデート -<<<<<<< HEAD -======= - ->>>>>>> 8d357bf1e (finished translating cheartsheet.md) ```bash kubectl set image deployment/frontend www=image:v2 # frontend Deploymentのwwwコンテナイメージをv2にローリングアップデートします kubectl rollout history deployment/frontend # frontend Deploymentの改訂履歴を確認します diff --git a/content/vi/docs/tutorials/kubernetes-basics/_index.html b/content/vi/docs/tutorials/kubernetes-basics/_index.html new file mode 100644 index 0000000000..2440ca5e67 --- /dev/null +++ b/content/vi/docs/tutorials/kubernetes-basics/_index.html @@ -0,0 +1,116 @@ +--- +title: Học kiến thức cơ bản về Kubernetes +linkTitle: Học kiến thức cơ bản về Kubernetes +weight: 10 +card: + name: Các hướng dẫn + weight: 20 + title: Hướng dẫn những điều cơ bản +--- + + + + + + + + + +
+ +
+ +
+
+

Kiến thức cơ bản về Kubernetes

+

Hướng dẫn này cung cấp những kiến thức cơ bản về một cụm Kubernetes. Mỗi mô-đun chứa một số thông tin cơ bản về các tính năng cũng như khái niệm chính của Kubernetes, đồng thời bao gồm một hướng dẫn tương tác trực tuyến. Các hướng dẫn tương tác này giúp bạn quản lý một cluster đơn giản và các ứng dụng được đóng gói của bạn.

+

Bằng các hướng dẫn tương tác, bạn có thể học cách:

+
    +
  • Triển khai một ứng dụng container trong một cluster.
    • +
  • Thay đổi quy mô triển khai.
    • +
  • Cập nhật ứng dụng container.
    • +
  • Debug ứng dụng container.
    • +
+

Những hướng dẫn này dùng Katacoda để chạy một terminal ảo trên trình duyệt web của bạn chạy Minikube. Không cần phải cài đặt và cấu hình bất kỳ phần mềm nào; mỗi hướng dẫn tương tác chạy trực tiếp từ trình duyệt web của bạn.

+
+
+ +
+ +
+
+

Kubernetes có thế làm những gì?

+

Với các dịch vụ web hiện đại, người dùng mong muốn các ứng dụng luôn sẵn sàng hoạt động 24/7 và các lập trình viên muốn triển khai các phiên bản của ứng dụng đó nhiều lần trong ngày. Việc đóng gói ứng dụng vào container giúp giải quyết mục tiêu này, cho phép các ứng dụng được phát hành và cập nhật một cách dễ dàng, nhanh chóng mà không có downtime. Kubernetes giúp bạn đảm bảo các ứng dụng container chạy ở bất kì đâu và bất kì lúc nào bạn muốn, đồng thời giúp chúng tìm thấy các tài nguyên và công cụ cần thiết để chạy. Kubernetes là nền tảng mã nguồn mở, chạy được trong môi trường production, được thiết kế và phát triển bởi Google, kết hợp với những ý tưởng tốt nhất từ cộng đồng.

+
+
+ +
+ +
+

Những mô-đun Kubernetes cơ bản

+
+
+
+
+
+ +
+
1. Tạo mới một cụm Kubernetes
 +
+
+
+
+
+ +
+
2. Triển khai ứng dụng
 +
+
+
+
+
+ +
+
3. Khám phá ứng dụng
 +
+
+
+
+
+
+
+
+
+ +
+
4. Đưa ứng dụng ra public
 +
+
+
+
+
+ +
+
5. Scale ứng dụng
 +
+
+
+
+
+ +
+
6. Cập nhật ứng dụng
 +
+
+
+
+
+
+
+ +
+ +
+ + + diff --git a/content/zh/docs/concepts/architecture/cloud-controller.md b/content/zh/docs/concepts/architecture/cloud-controller.md index b25b48ced0..47043364b8 100644 --- a/content/zh/docs/concepts/architecture/cloud-controller.md +++ b/content/zh/docs/concepts/architecture/cloud-controller.md @@ -19,7 +19,7 @@ Cloud infrastructure technologies let you run Kubernetes on public, private, and Kubernetes believes in automated, API-driven infrastructure without tight coupling between components. --> -使用云基础设施技术，你可以在共有云、私有云或者混合云环境中运行 Kubernetes。 +使用云基础设施技术，你可以在公有云、私有云或者混合云环境中运行 Kubernetes。 Kubernetes 的信条是基于自动化的、API 驱动的基础设施，同时避免组件间紧密耦合。 {{< glossary_definition term_id="cloud-controller-manager" length="all" prepend="组件 cloud-controller-manager 是">}} diff --git a/content/zh/docs/concepts/cluster-administration/_index.md b/content/zh/docs/concepts/cluster-administration/_index.md index fa4b1f6f71..91ef1b5cc8 100644 --- a/content/zh/docs/concepts/cluster-administration/_index.md +++ b/content/zh/docs/concepts/cluster-administration/_index.md @@ -102,7 +102,7 @@ Before choosing a guide, here are some considerations: * [证书](/zh/docs/concepts/cluster-administration/certificates/)节描述了使用不同的工具链生成证书的步骤。 * [Kubernetes 容器环境](/zh/docs/concepts/containers/container-environment/)描述了 Kubernetes 节点上由 Kubelet 管理的容器的环境。 -* [控制到 Kubernetes API 的访问](/zh/docs/reference/access-authn-authz/controlling-access/)描述了如何为用户和 service accounts 建立权限许可。 +* [控制到 Kubernetes API 的访问](/zh/docs/concepts/security/controlling-access/)描述了如何为用户和 service accounts 建立权限许可。 * [认证](/docs/reference/access-authn-authz/authentication/)节阐述了 Kubernetes 中的身份认证功能，包括许多认证选项。 * [鉴权](/zh/docs/reference/access-authn-authz/authorization/)从认证中分离出来，用于控制如何处理 HTTP 请求。 * [使用准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers) 阐述了在认证和授权之后拦截到 Kubernetes API 服务的请求的插件。 diff --git a/content/zh/docs/concepts/cluster-administration/addons.md b/content/zh/docs/concepts/cluster-administration/addons.md index 77316222b3..aaed1402d0 100644 --- a/content/zh/docs/concepts/cluster-administration/addons.md +++ b/content/zh/docs/concepts/cluster-administration/addons.md @@ -5,6 +5,8 @@ content_type: concept +{{% thirdparty-content %}} + 针对每个优先级别，输出中还包含一条虚拟记录，对应豁免限制。 @@ -881,4 +881,4 @@ You can make suggestions and feature requests via --> 有关API优先级和公平性的设计细节的背景信息， 请参阅[增强建议](https://github.com/kubernetes/enhancements/blob/master/keps/sig-api-machinery/20190228-priority-and-fairness.md)。 -你可以通过 [SIG APIMachinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery) 提出建议和特性请求。 \ No newline at end of file +你可以通过 [SIG APIMachinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery) 提出建议和特性请求。 diff --git a/content/zh/docs/concepts/cluster-administration/logging.md b/content/zh/docs/concepts/cluster-administration/logging.md index ad44bbc5cb..762fc1c050 100644 --- a/content/zh/docs/concepts/cluster-administration/logging.md +++ b/content/zh/docs/concepts/cluster-administration/logging.md @@ -14,9 +14,9 @@ weight: 60 -应用和系统日志可以让你了解集群内部的运行状况。日志对调试问题和监控集群活动非常有用。 +应用日志可以让你了解应用内部的运行状况。日志对调试问题和监控集群活动非常有用。 大部分现代化应用都有某种日志记录机制；同样地，大多数容器引擎也被设计成支持某种日志记录机制。 针对容器化应用，最简单且受欢迎的日志记录方式就是写入标准输出和标准错误流。 @@ -45,14 +45,13 @@ the description of how logs are stored and handled on the node to be useful. In this section, you can see an example of basic logging in Kubernetes that outputs data to the standard output stream. This demonstration uses -a [pod specification](/examples/debug/counter-pod.yaml) with -a container that writes some text to standard output once per second. +a pod specification with a container that writes some text to standard output +once per second. --> ## Kubernetes 中的基本日志记录 本节，你会看到一个kubernetes 中生成基本日志的例子，该例子中数据被写入到标准输出。 -这里通过一个特定的 [Pod 规约](/examples/debug/counter-pod.yaml) 演示创建一个容器， -并令该容器每秒钟向标准输出写入数据。 +这里的示例为包含一个容器的 Pod 规约，该容器每秒钟向标准输出写入数据。 {{< codenew file="debug/counter-pod.yaml" >}} diff --git a/content/zh/docs/concepts/cluster-administration/networking.md b/content/zh/docs/concepts/cluster-administration/networking.md index fdc5efd0a0..06ff565cff 100644 --- a/content/zh/docs/concepts/cluster-administration/networking.md +++ b/content/zh/docs/concepts/cluster-administration/networking.md @@ -140,6 +140,8 @@ imply any preferential status. 接下来的网络技术是按照首字母排序，顺序本身并无其他意义。 +{{% thirdparty-content %}} + +### Calico + +[Calico](https://docs.projectcalico.org/) 是一个开源的联网及网络安全方案， +用于基于容器、虚拟机和本地主机的工作负载。 +Calico 支持多个数据面，包括：纯 Linux eBPF 的数据面、标准的 Linux 联网数据面 +以及 Windwos HNS 数据面。Calico 在提供完整的联网堆栈的同时，还可与 +[云驱动 CNIs](https://docs.projectcalico.org/networking/determine-best-networking#calico-compatible-cni-plugins-and-cloud-provider-integrations) 联合使用，以保证网络策略实施。 + -### Calico 项目 {#project-calico} - -[Calico 项目](https://docs.projectcalico.org/) 是一个开源的容器网络提供者和网络策略引擎。 - -Calico 提供了高度可扩展的网络和网络解决方案，使用基于与 Internet 相同的 IP 网络原理来连接 Kubernetes Pod， -适用于 Linux （开放源代码）和 Windows（专有-可从 [Tigera](https://www.tigera.io/essentials/) 获得。 -可以无需封装或覆盖即可部署 Calico，以提供高性能，高可扩的数据中心网络。 -Calico 还通过其分布式防火墙为 Kubernetes Pod 提供了基于意图的细粒度网络安全策略。 - -Calico 还可以和其他的网络解决方案（比如 Flannel、[canal](https://github.com/tigera/canal) -或原生 GCE、AWS、Azure 网络等）一起以策略实施模式运行。 - ## 禁用加速器指标 @@ -185,7 +185,9 @@ kubelet 在驱动程序上保持打开状态。这意味着为了执行基础结 现在，收集加速器指标的责任属于供应商，而不是 kubelet。供应商必须提供一个收集指标的容器， 并将其公开给指标服务（例如 Prometheus）。 -[`DisableAcceleratorUsageMetrics` 特性门控](/zh/docs/references/command-line-tools-reference/feature-gate.md#feature-gates-for-alpha-or-beta-features:~:text= DisableAcceleratorUsageMetrics,-false)禁止由 kubelet 收集的指标，并[带有一条时间线，默认情况下会启用此功能](https://github.com/kubernetes/enhancements/tree/411e51027db842355bd489691af897afc1a41a5e/keps/sig-node/1867-disable-accelerator-usage-metrics#graduation-criteria)。 +[`DisableAcceleratorUsageMetrics` 特性门控](/zh/docs/references/command-line-tools-reference/feature-gate.md#feature-gates-for-alpha-or-beta-features:~:text= DisableAcceleratorUsageMetrics,-false) +禁止由 kubelet 收集的指标。 +关于[何时会在默认情况下启用此功能也有一定规划](https://github.com/kubernetes/enhancements/tree/411e51027db842355bd489691af897afc1a41a5e/keps/sig-node/1867-disable-accelerator-usage-metrics#graduation-criteria)。 * 阅读有关指标的 [Prometheus 文本格式](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-based-format) * 查看 [Kubernetes 稳定指标](https://github.com/kubernetes/kubernetes/blob/master/test/instrumentation/testdata/stable-metrics-list.yaml)的列表 -* 阅读有关 [Kubernetes 弃用策略](/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior) \ No newline at end of file +* 阅读有关 [Kubernetes 弃用策略](/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior) diff --git a/content/zh/docs/concepts/overview/_index.md b/content/zh/docs/concepts/overview/_index.md index b255293d26..8c8aff7531 100644 --- a/content/zh/docs/concepts/overview/_index.md +++ b/content/zh/docs/concepts/overview/_index.md @@ -2,4 +2,6 @@ title: 概述 weight: 20 description: 获得 Kubernetes 及其构件的高层次概要。 +sitemap: + priority: 0.9 --- diff --git a/content/zh/docs/concepts/overview/components.md b/content/zh/docs/concepts/overview/components.md index 433ef8476a..2a862f781a 100644 --- a/content/zh/docs/concepts/overview/components.md +++ b/content/zh/docs/concepts/overview/components.md @@ -24,7 +24,7 @@ card: ### Web 界面（仪表盘） -[Dashboard](/zh/docs/tasks/access-application-cluster/web-ui-dashboard/) 是K -ubernetes 集群的通用的、基于 Web 的用户界面。 +[Dashboard](/zh/docs/tasks/access-application-cluster/web-ui-dashboard/) 是Kubernetes 集群的通用的、基于 Web 的用户界面。 它使用户可以管理集群中运行的应用程序以及集群本身并进行故障排除。 Kubernetes {{< glossary_tooltip text="控制面" term_id="control-plane" >}} 的核心是 {{< glossary_tooltip text="API 服务器" term_id="kube-apiserver" >}}。 @@ -29,38 +35,18 @@ API 服务器负责提供 HTTP API，以供用户、集群中的不同部分和 Kubernetes API 使你可以查询和操纵 Kubernetes API 中对象（例如：Pod、Namespace、ConfigMap 和 Event）的状态。 -API 末端、资源类型以及示例都在[API 参考](/zh/docs/reference/kubernetes-api/)中描述。 - - +大部分操作都可以通过 [kubectl](/zh/docs/reference/kubectl/overview/) 命令行接口或 +类似 [kubeadm](/zh/docs/reference/setup-tools/kubeadm/) 这类命令行工具来执行， +这些工具在背后也是调用 API。不过，你也可以使用 REST 调用来访问这些 API。 -## API 变更 {#api-changes} +如果你正在编写程序来访问 Kubernetes API，可以考虑使用 +[客户端库](/zh/docs/reference/using-api/client-libraries/)之一。 -任何成功的系统都要随着新的使用案例的出现和现有案例的变化来成长和变化。 -为此，Kubernetes 的功能特性设计考虑了让 Kubernetes API 能够持续变更和成长的因素。 -Kubernetes 项目的目标是 _不要_ 引发现有客户端的兼容性问题，并在一定的时期内 -维持这种兼容性，以便其他项目有机会作出适应性变更。 - -一般而言，新的 API 资源和新的资源字段可以被频繁地添加进来。 -删除资源或者字段则要遵从 -[API 废弃策略](/docs/reference/using-api/deprecation-policy/)。 - -关于什么是兼容性的变更，如何变更 API 等详细信息，可参考 -[API 变更](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme)。 + - ## OpenAPI 规范 {#api-specification} 完整的 API 细节是用 [OpenAPI](https://www.openapis.org/) 来表述的。 @@ -142,204 +127,137 @@ Kubernetes API 服务器通过 `/openapi/v2` 末端提供 OpenAPI 规范。 -Kubernetes 为 API 实现了一种基于 Protobuf 的序列化格式，主要用于集群内部的通信。 -相关文档位于[设计提案](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md)。 -每种 Schema 对应的 IDL 位于定义 API 对象的 Go 包中。 +Kubernetes 为 API 实现了一种基于 Protobuf 的序列化格式，主要用于集群内部通信。 +关于此格式的详细信息，可参考 +[Kubernetes Protobuf 序列化](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md) +设计提案。每种模式对应的接口描述语言（IDL）位于定义 API 对象的 Go 包中。 -## API 版本 {#api-versioning} +## API 变更 {#api-changes} + +任何成功的系统都要随着新的使用案例的出现和现有案例的变化来成长和变化。 +为此，Kubernetes 的功能特性设计考虑了让 Kubernetes API 能够持续变更和成长的因素。 +Kubernetes 项目的目标是 _不要_ 引发现有客户端的兼容性问题，并在一定的时期内 +维持这种兼容性，以便其他项目有机会作出适应性变更。 + +一般而言，新的 API 资源和新的资源字段可以被频繁地添加进来。 +删除资源或者字段则要遵从 +[API 废弃策略](/zh/docs/reference/using-api/deprecation-policy/)。 + +关于什么是兼容性的变更、如何变更 API 等详细信息，可参考 +[API 变更](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme)。 + + +## API 组和版本 {#api-groups-and-versioning} 为了简化删除字段或者重构资源表示等工作，Kubernetes 支持多个 API 版本， 每一个版本都在不同 API 路径下，例如 `/api/v1` 或 `/apis/rbac.authorization.k8s.io/v1alpha1`。 版本化是在 API 级别而不是在资源或字段级别进行的，目的是为了确保 API 为系统资源和行为提供清晰、一致的视图，并能够控制对已废止的和/或实验性 API 的访问。 -JSON 和 Protobuf 序列化模式遵循 schema 更改的相同准则 - 下面的所有描述都同时适用于这两种格式。 + +为了便于演化和扩展其 API，Kubernetes 实现了 +可被[启用或禁用](/zh/docs/reference/using-api/#enabling-or-disabling)的 +[API 组](/docs/reference/using-api/#api-groups)。 -请注意，API 版本控制和软件版本控制只有间接相关性。 -[Kubernetes 发行版本提案](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md) -中描述了 API 版本与软件版本之间的关系。 - -不同的 API 版本名称意味着不同级别的软件稳定性和支持程度。 -每个级别的判定标准在 -[API 变更文档](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions) -中有更详细的描述。 -这些标准主要概括如下： +API 资源之间靠 API 组、资源类型、名字空间（对于名字空间作用域的资源而言）和 +名字来相互区分。API 服务器可能通过多个 API 版本来向外提供相同的下层数据， +并透明地完成不同 API 版本之间的转换。所有这些不同的版本实际上都是同一资源 +的（不同）表现形式。例如，假定同一资源有 `v1` 和 `v1beta1` 版本， +使用 `v1beta1` 创建的对象则可以使用 `v1beta1` 或者 `v1` 版本来读取、更改 +或者删除。 -- Alpha 级别： - - 版本名称包含 `alpha`（例如：`v1alpha1`） - - API 可能是有缺陷的。启用该功能可能会带来问题，默认情况是禁用的 - - 对相关功能的支持可能在没有通知的情况下随时终止 - - API 可能在将来的软件发布中出现不兼容性的变更，此类变更不会另行通知 - - 由于缺陷风险较高且缺乏长期支持，推荐仅在短暂的集群测试中使用 +关于 API 版本级别的详细定义，请参阅 +[API 版本参考](/zh/docs/reference/using-api/#api-versioning)。 -- Beta 级别： - - 版本名称包含 `beta`（例如：`v2beta3`） - - 代码已经充分测试过。启用该功能被认为是安全的，功能默认已启用。 - - 所支持的功能作为一个整体不会被删除，尽管细节可能会发生变更。 - - 对象的模式和/或语义可能会在后续的 beta 发行版或稳定版中以不兼容的方式进行更改。 - 发生这种情况时，我们将提供如何迁移到新版本的说明。 - 迁移操作可能需要删除、编辑和重新创建 API 对象。 - 执行编辑操作时可能需要动些脑筋。 - 迁移过程中可能需要停用依赖该功能的应用程序。 - - 建议仅用于非业务关键性用途，因为后续版本中可能存在不兼容的更改。 - 如果你有多个可以独立升级的集群，则可以放宽此限制。 - - **请尝试我们的 beta 版本功能并且给出反馈！一旦它们结束 beta 阶段，进一步变更可能就不太现实了。** - -- 稳定级别： - - 版本名称是 `vX`，其中 `X` 是整数。 - - 功能的稳定版本将出现在许多后续版本的发行软件中。 +## API 扩展 {#api-extension} + +有两种途径来扩展 Kubernetes API： -## API 组 {#api-groups} - -为了更容易地扩展 Kubernetes API，Kubernetes 实现了 -[*`API组`*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)。 -API 组在 REST 路径和序列化对象的 `apiVersion` 字段中指定。 - - -集群中存在若干 API 组： - -1. *核心（Core）*组，通常被称为 *遗留（Legacy）* 组，位于 REST 路径 `/api/v1`， - 使用 `apiVersion: v1`。 - -1. *命名（Named）* 组 REST 路径 `/apis/$GROUP_NAME/$VERSION`，使用 - `apiVersion: $GROUP_NAME/$VERSION`（例如 `apiVersion: batch/v1`）。 - [Kubernetes API 参考](/zh/docs/reference/kubernetes-api/)中枚举了可用的 API 组的完整列表。 - - -有两种途径来扩展 Kubernetes API 以支持 -[自定义资源](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)： - -1. 使用 [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)， - 你可以用声明式方式来定义 API 如何提供你所选择的资源 API。 - -1. 你也可以选择[实现自己的扩展 API 服务器](/zh/docs/tasks/extend-kubernetes/setup-extension-api-server/) - 并使用[聚合器](/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer/) - 为客户提供无缝的服务。 - - -## 启用或禁用 API 组 {#enabling-or-disabling-api-groups} - -某些资源和 API 组默认情况下处于启用状态。可以通过为 `kube-apiserver` -设置 `--runtime-config` 命令行选项来启用或禁用它们。 -`--runtime-config` 接受逗号分隔的值。 -例如：要禁用 `batch/v1`，设置 `--runtime-config=batch/v1=false`； -要启用 `batch/v2alpha1`，设置`--runtime-config=batch/v2alpha1`。 -该标志接受逗号分隔的一组"key=value"键值对，用以描述 API 服务器的运行时配置。 - -{{< note >}} -启用或禁用组或资源需要重新启动 `kube-apiserver` 和 `kube-controller-manager` -来使得 `--runtime-config` 更改生效。 -{{< /note >}} - - -## 持久性 {#persistence} - -Kubernetes 也将其 API 资源的序列化状态保存起来，写入到 {{< glossary_tooltip term_id="etcd" >}}。 +1. 你可以使用[自定义资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/) + 来以声明式方式定义 API 服务器如何提供你所选择的资源 API。 +1. 你也可以选择实现自己的 + [聚合层](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) + 来扩展 Kubernetes API。 ## {{% heading "whatsnext" %}} -* [控制 API 访问](/zh/docs/reference/access-authn-authz/controlling-access/) - 描述了集群如何为 API 访问管理身份认证和权限判定； -* 总体的 API 约定描述位于 [API 约定](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md)中； -* API 末端、资源类型和示例等均在 [API 参考文档](/zh/docs/reference/kubernetes-api/)中描述 - +- 了解如何通过添加你自己的 + [CustomResourceDefinition](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/) + 来扩展 Kubernetes API。 +- [控制 Kubernetes API 访问](/zh/docs/concepts/security/controlling-access/) + 页面描述了集群如何针对 API 访问管理身份认证和鉴权。 +- 通过阅读 [API 参考](/zh/docs/reference/kubernetes-api/) + 了解 API 端点、资源类型以及示例。 diff --git a/content/zh/docs/concepts/overview/what-is-kubernetes.md b/content/zh/docs/concepts/overview/what-is-kubernetes.md index 4aab8132f1..3fa58f5da0 100644 --- a/content/zh/docs/concepts/overview/what-is-kubernetes.md +++ b/content/zh/docs/concepts/overview/what-is-kubernetes.md @@ -9,7 +9,6 @@ card: weight: 10 --- @@ -33,18 +31,22 @@ This page is an overview of Kubernetes. -Kubernetes 是一个可移植的、可扩展的开源平台，用于管理容器化的工作负载和服务，可促进声明式配置和自动化。Kubernetes 拥有一个庞大且快速增长的生态系统。Kubernetes 的服务、支持和工具广泛可用。 +Kubernetes 是一个可移植的、可扩展的开源平台，用于管理容器化的工作负载和服务，可促进声明式配置和自动化。 +Kubernetes 拥有一个庞大且快速增长的生态系统。Kubernetes 的服务、支持和工具广泛可用。 -名称 **Kubernetes** 源于希腊语，意为 "舵手" 或 "飞行员"。Google 在 2014 年开源了 Kubernetes 项目。Kubernetes 建立在 [Google 在大规模运行生产工作负载方面拥有十几年的经验](https://research.google/pubs/pub43438)的基础上，结合了社区中最好的想法和实践。 +名称 **Kubernetes** 源于希腊语，意为“舵手”或“飞行员”。Google 在 2014 年开源了 Kubernetes 项目。 +Kubernetes 建立在 [Google 在大规模运行生产工作负载方面拥有十几年的经验](https://research.google/pubs/pub43438) +的基础上，结合了社区中最好的想法和实践。 -## 言归正传 +## 时光回溯 + 让我们回顾一下为什么 Kubernetes 如此有用。 **传统部署时代：** -早期，组织在物理服务器上运行应用程序。无法为物理服务器中的应用程序定义资源边界，这会导致资源分配问题。例如，如果在物理服务器上运行多个应用程序，则可能会出现一个应用程序占用大部分资源的情况，结果可能导致其他应用程序的性能下降。一种解决方案是在不同的物理服务器上运行每个应用程序，但是由于资源利用不足而无法扩展，并且组织维护许多物理服务器的成本很高。 + +早期，组织在物理服务器上运行应用程序。无法为物理服务器中的应用程序定义资源边界，这会导致资源分配问题。 +例如，如果在物理服务器上运行多个应用程序，则可能会出现一个应用程序占用大部分资源的情况， +结果可能导致其他应用程序的性能下降。 +一种解决方案是在不同的物理服务器上运行每个应用程序，但是由于资源利用不足而无法扩展， +并且组织维护许多物理服务器的成本很高。 **虚拟化部署时代：** -作为解决方案，引入了虚拟化功能，它允许您在单个物理服务器的 CPU 上运行多个虚拟机（VM）。虚拟化功能允许应用程序在 VM 之间隔离，并提供安全级别，因为一个应用程序的信息不能被另一应用程序自由地访问。 + +作为解决方案，引入了虚拟化。虚拟化技术允许你在单个物理服务器的 CPU 上运行多个虚拟机（VM）。 +虚拟化允许应用程序在 VM 之间隔离，并提供一定程度的安全，因为一个应用程序的信息 +不能被另一应用程序随意访问。 -因为虚拟化可以轻松地添加或更新应用程序、降低硬件成本等等，所以虚拟化可以更好地利用物理服务器中的资源，并可以实现更好的可伸缩性。 +虚拟化技术能够更好地利用物理服务器上的资源，并且因为可轻松地添加或更新应用程序 +而可以实现更好的可伸缩性，降低硬件成本等等。 每个 VM 是一台完整的计算机，在虚拟化硬件之上运行所有组件，包括其自己的操作系统。 @@ -80,12 +92,15 @@ Each VM is a full machine running all the components, including its own operatin Containers are similar to VMs, but they have relaxed isolation properties to share the Operating System (OS) among the applications. Therefore, containers are considered lightweight. Similar to a VM, a container has its own filesystem, CPU, memory, process space, and more. As they are decoupled from the underlying infrastructure, they are portable across clouds and OS distributions. --> **容器部署时代：** -容器类似于 VM，但是它们具有轻量级的隔离属性，可以在应用程序之间共享操作系统（OS）。因此，容器被认为是轻量级的。容器与 VM 类似，具有自己的文件系统、CPU、内存、进程空间等。由于它们与基础架构分离，因此可以跨云和 OS 分发进行移植。 + +容器类似于 VM，但是它们具有被放宽的隔离属性，可以在应用程序之间共享操作系统（OS）。 +因此，容器被认为是轻量级的。容器与 VM 类似，具有自己的文件系统、CPU、内存、进程空间等。 +由于它们与基础架构分离，因此可以跨云和 OS 发行版本进行移植。 -容器因具有许多优势而变得流行起来。下面列出了容器的一些好处： +容器因具有许多优势而变得流行起来。下面列出的是容器的一些好处： * 敏捷应用程序的创建和部署：与使用 VM 镜像相比，提高了容器镜像创建的简便性和效率。 -* 持续开发、集成和部署：通过快速简单的回滚(由于镜像不可变性)，提供可靠且频繁的容器镜像构建和部署。 -* 关注开发与运维的分离：在构建/发布时而不是在部署时创建应用程序容器镜像，从而将应用程序与基础架构分离。 +* 持续开发、集成和部署：通过快速简单的回滚（由于镜像不可变性），支持可靠且频繁的 + 容器镜像构建和部署。 +* 关注开发与运维的分离：在构建/发布时而不是在部署时创建应用程序容器镜像， + 从而将应用程序与基础架构分离。 * 可观察性不仅可以显示操作系统级别的信息和指标，还可以显示应用程序的运行状况和其他指标信号。 * 跨开发、测试和生产的环境一致性：在便携式计算机上与在云中相同地运行。 -* 云和操作系统分发的可移植性：可在 Ubuntu、RHEL、CoreOS、本地、Google Kubernetes Engine 和其他任何地方运行。 -* 以应用程序为中心的管理：提高抽象级别，从在虚拟硬件上运行 OS 到使用逻辑资源在 OS 上运行应用程序。 -* 松散耦合、分布式、弹性、解放的微服务：应用程序被分解成较小的独立部分，并且可以动态部署和管理 - 而不是在一台大型单机上整体运行。 +* 跨云和操作系统发行版本的可移植性：可在 Ubuntu、RHEL、CoreOS、本地、 + Google Kubernetes Engine 和其他任何地方运行。 +* 以应用程序为中心的管理：提高抽象级别，从在虚拟硬件上运行 OS 到使用逻辑资源在 + OS 上运行应用程序。 +* 松散耦合、分布式、弹性、解放的微服务：应用程序被分解成较小的独立部分， + 并且可以动态部署和管理 - 而不是在一台大型单机上整体运行。 * 资源隔离：可预测的应用程序性能。 * 资源利用：高效率和高密度。 @@ -118,59 +138,75 @@ Containers are becoming popular because they have many benefits. Some of the con -容器是打包和运行应用程序的好方式。在生产环境中，您需要管理运行应用程序的容器，并确保不会停机。例如，如果一个容器发生故障，则需要启动另一个容器。如果系统处理此行为，会不会更容易？ +容器是打包和运行应用程序的好方式。在生产环境中，你需要管理运行应用程序的容器，并确保不会停机。 +例如，如果一个容器发生故障，则需要启动另一个容器。如果系统处理此行为，会不会更容易？ -这就是 Kubernetes 的救援方法！Kubernetes 为您提供了一个可弹性运行分布式系统的框架。Kubernetes 会满足您的扩展要求、故障转移、部署模式等。例如，Kubernetes 可以轻松管理系统的 Canary 部署。 +这就是 Kubernetes 来解决这些问题的方法！ +Kubernetes 为你提供了一个可弹性运行分布式系统的框架。 +Kubernetes 会满足你的扩展要求、故障转移、部署模式等。 +例如，Kubernetes 可以轻松管理系统的 Canary 部署。 -Kubernetes 为您提供： +Kubernetes 为你提供： -* **服务发现和负载均衡** -Kubernetes 可以使用 DNS 名称或自己的 IP 地址公开容器，如果到容器的流量很大，Kubernetes 可以负载均衡并分配网络流量，从而使部署稳定。 +* **服务发现和负载均衡** + + Kubernetes 可以使用 DNS 名称或自己的 IP 地址公开容器，如果进入容器的流量很大， + Kubernetes 可以负载均衡并分配网络流量，从而使部署稳定。 -* **存储编排** -Kubernetes 允许您自动挂载您选择的存储系统，例如本地存储、公共云提供商等。 +* **存储编排** + + Kubernetes 允许你自动挂载你选择的存储系统，例如本地存储、公共云提供商等。 -* **自动部署和回滚** -您可以使用 Kubernetes 描述已部署容器的所需状态，它可以以受控的速率将实际状态更改为所需状态。例如，您可以自动化 Kubernetes 来为您的部署创建新容器，删除现有容器并将它们的所有资源用于新容器。 +* **自动部署和回滚** + + 你可以使用 Kubernetes 描述已部署容器的所需状态，它可以以受控的速率将实际状态 + 更改为期望状态。例如，你可以自动化 Kubernetes 来为你的部署创建新容器， + 删除现有容器并将它们的所有资源用于新容器。 -* **自动二进制打包** -Kubernetes 允许您指定每个容器所需 CPU 和内存（RAM）。当容器指定了资源请求时，Kubernetes 可以做出更好的决策来管理容器的资源。 +* **自动完成装箱计算** + + Kubernetes 允许你指定每个容器所需 CPU 和内存（RAM）。 + 当容器指定了资源请求时，Kubernetes 可以做出更好的决策来管理容器的资源。 -* **自我修复** -Kubernetes 重新启动失败的容器、替换容器、杀死不响应用户定义的运行状况检查的容器，并且在准备好服务之前不将其通告给客户端。 +* **自我修复** + + Kubernetes 重新启动失败的容器、替换容器、杀死不响应用户定义的 + 运行状况检查的容器，并且在准备好服务之前不将其通告给客户端。 -* **密钥与配置管理** -Kubernetes 允许您存储和管理敏感信息，例如密码、OAuth 令牌和 ssh 密钥。您可以在不重建容器镜像的情况下部署和更新密钥和应用程序配置，也无需在堆栈配置中暴露密钥。 +* **密钥与配置管理** + + Kubernetes 允许你存储和管理敏感信息，例如密码、OAuth 令牌和 ssh 密钥。 + 你可以在不重建容器镜像的情况下部署和更新密钥和应用程序配置，也无需在堆栈配置中暴露密钥。 -Kubernetes 不是传统的、包罗万象的 PaaS（平台即服务）系统。由于 Kubernetes 在容器级别而不是在硬件级别运行，因此它提供了 PaaS 产品共有的一些普遍适用的功能，例如部署、扩展、负载均衡、日志记录和监视。但是，Kubernetes 不是单一的，默认解决方案是可选和可插拔的。Kubernetes 提供了构建开发人员平台的基础，但是在重要的地方保留了用户的选择和灵活性。 +Kubernetes 不是传统的、包罗万象的 PaaS（平台即服务）系统。 +由于 Kubernetes 在容器级别而不是在硬件级别运行，它提供了 PaaS 产品共有的一些普遍适用的功能， +例如部署、扩展、负载均衡、日志记录和监视。 +但是，Kubernetes 不是单体系统，默认解决方案都是可选和可插拔的。 +Kubernetes 提供了构建开发人员平台的基础，但是在重要的地方保留了用户的选择和灵活性。 -* Kubernetes 不限制支持的应用程序类型。Kubernetes 旨在支持极其多种多样的工作负载，包括无状态、有状态和数据处理工作负载。如果应用程序可以在容器中运行，那么它应该可以在 Kubernetes 上很好地运行。 -* Kubernetes 不部署源代码，也不构建您的应用程序。持续集成(CI)、交付和部署（CI/CD）工作流取决于组织的文化和偏好以及技术要求。 -* Kubernetes 不提供应用程序级别的服务作为内置服务，例如中间件（例如，消息中间件）、数据处理框架（例如，Spark）、数据库（例如，mysql）、缓存、集群存储系统（例如，Ceph）。这样的组件可以在 Kubernetes 上运行，并且/或者可以由运行在 Kubernetes 上的应用程序通过可移植机制（例如，[开放服务代理](https://openservicebrokerapi.org/)）来访问。 - +* 不限制支持的应用程序类型。 + Kubernetes 旨在支持极其多种多样的工作负载，包括无状态、有状态和数据处理工作负载。 + 如果应用程序可以在容器中运行，那么它应该可以在 Kubernetes 上很好地运行。 +* 不部署源代码，也不构建你的应用程序。 + 持续集成(CI)、交付和部署（CI/CD）工作流取决于组织的文化和偏好以及技术要求。 +* 不提供应用程序级别的服务作为内置服务，例如中间件（例如，消息中间件）、 + 数据处理框架（例如，Spark）、数据库（例如，mysql）、缓存、集群存储系统 + （例如，Ceph）。这样的组件可以在 Kubernetes 上运行，并且/或者可以由运行在 + Kubernetes 上的应用程序通过可移植机制（例如， + [开放服务代理](https://openservicebrokerapi.org/)）来访问。 -* Kubernetes 不指定日志记录、监视或警报解决方案。它提供了一些集成作为概念证明，并提供了收集和导出指标的机制。 -* Kubernetes 不提供或不要求配置语言/系统（例如 jsonnet），它提供了声明性 API，该声明性 API 可以由任意形式的声明性规范所构成。 -* Kubernetes 不提供也不采用任何全面的机器配置、维护、管理或自我修复系统。 -* 此外，Kubernetes 不仅仅是一个编排系统，实际上它消除了编排的需要。编排的技术定义是执行已定义的工作流程：首先执行 A，然后执行 B，再执行 C。相比之下，Kubernetes 包含一组独立的、可组合的控制过程，这些过程连续地将当前状态驱动到所提供的所需状态。从 A 到 C 的方式无关紧要，也不需要集中控制，这使得系统更易于使用且功能更强大、健壮、弹性和可扩展性。 - - +* 不要求日志记录、监视或警报解决方案。 + 它提供了一些集成作为概念证明，并提供了收集和导出指标的机制。 +* 不提供或不要求配置语言/系统（例如 jsonnet），它提供了声明性 API， + 该声明性 API 可以由任意形式的声明性规范所构成。 +* 不提供也不采用任何全面的机器配置、维护、管理或自我修复系统。 +* 此外，Kubernetes 不仅仅是一个编排系统，实际上它消除了编排的需要。 + 编排的技术定义是执行已定义的工作流程：首先执行 A，然后执行 B，再执行 C。 + 相比之下，Kubernetes 包含一组独立的、可组合的控制过程， + 这些过程连续地将当前状态驱动到所提供的所需状态。 + 如何从 A 到 C 的方式无关紧要，也不需要集中控制，这使得系统更易于使用 + 且功能更强大、系统更健壮、更为弹性和可扩展。 ## {{% heading "whatsnext" %}} @@ -215,5 +266,5 @@ Kubernetes： * Take a look at the [Kubernetes Components](/docs/concepts/overview/components/) * Ready to [Get Started](/docs/setup/)? --> -* 查阅 [Kubernetes 组件](/zh/docs/concepts/overview/components/) -* 开始 [Kubernetes 入门](/zh/docs/setup/)? +* 查阅 [Kubernetes 组件](/zh/docs/concepts/overview/components/) +* 开始 [Kubernetes 入门](/zh/docs/setup/)? diff --git a/content/zh/docs/concepts/overview/working-with-objects/annotations.md b/content/zh/docs/concepts/overview/working-with-objects/annotations.md index f342a92113..5239861124 100644 --- a/content/zh/docs/concepts/overview/working-with-objects/annotations.md +++ b/content/zh/docs/concepts/overview/working-with-objects/annotations.md @@ -121,18 +121,18 @@ _注解（Annotations）_ 存储的形式是键/值对。有效的注解键分 并允许使用破折号（`-`），下划线（`_`），点（`.`）和字母数字。 前缀是可选的。如果指定，则前缀必须是DNS子域：一系列由点（`.`）分隔的DNS标签， 总计不超过253个字符，后跟斜杠（`/`）。 -如果省略前缀，则假定注释键对用户是私有的。 由系统组件添加的注释 +如果省略前缀，则假定注解键对用户是私有的。 由系统组件添加的注解 （例如，`kube-scheduler`，`kube-controller-manager`，`kube-apiserver`，`kubectl` -或其他第三方组件），必须为终端用户添加注释前缀。 +或其他第三方组件），必须为终端用户添加注解前缀。 `kubernetes.io/` 和 `k8s.io/` 前缀是为Kubernetes核心组件保留的。 -例如，这是Pod的配置文件，其注释为 `imageregistry: https://hub.docker.com/`： +例如，下面是一个 Pod 的配置文件，其注解中包含 `imageregistry: https://hub.docker.com/`： ```yaml apiVersion: v1 diff --git a/content/zh/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/zh/docs/concepts/overview/working-with-objects/kubernetes-objects.md index f5843e2573..96a863cfa0 100644 --- a/content/zh/docs/concepts/overview/working-with-objects/kubernetes-objects.md +++ b/content/zh/docs/concepts/overview/working-with-objects/kubernetes-objects.md @@ -191,11 +191,11 @@ and the `spec` format for a `Deployment` can be found ## {{% heading "whatsnext" %}} -* [Kubernetes API 总览](/zh/docs/reference/using-api/api-overview/) 提供关于 API 概念的进一步阐述 -* 了解最重要的 Kubernetes 基本对象，例如 [Pod](/zh/docs/concepts/workloads/pods/) -* 了解 Kubernetes 中的[控制器](/zh/docs/concepts/architecture/controller/) +* 了解最重要的 Kubernetes 基本对象，例如 [Pod](/zh/docs/concepts/workloads/pods/)。 +* 了解 Kubernetes 中的[控制器](/zh/docs/concepts/architecture/controller/)。 +* [使用 Kubernetes API](/zh/docs/reference/using-api/) 一节解释了一些 API 概念。 diff --git a/content/zh/docs/concepts/overview/working-with-objects/labels.md b/content/zh/docs/concepts/overview/working-with-objects/labels.md index 8e30177cee..88f189287e 100644 --- a/content/zh/docs/concepts/overview/working-with-objects/labels.md +++ b/content/zh/docs/concepts/overview/working-with-objects/labels.md @@ -307,7 +307,7 @@ and [`replicationcontrollers`](/docs/concepts/workloads/controllers/replicationc also use label selectors to specify sets of other resources, such as [pods](/docs/concepts/workloads/pods/). --> -### 在 API 对象上设置引用 +### 在 API 对象中设置引用 一些 Kubernetes 对象，例如 [`services`](/zh/docs/concepts/services-networking/service/) 和 [`replicationcontrollers`](/zh/docs/concepts/workloads/controllers/replicationcontroller/) ， @@ -323,9 +323,11 @@ Labels selectors for both objects are defined in `json` or `yaml` files using ma --> #### Service 和 ReplicationController -一个 `Service` 指向的一组 pods 是由标签选择算符定义的。同样，一个 `ReplicationController` 应该管理的 pods 的数量也是由标签选择算符定义的。 +一个 `Service` 指向的一组 Pods 是由标签选择算符定义的。同样，一个 `ReplicationController` +应该管理的 pods 的数量也是由标签选择算符定义的。 -两个对象的标签选择算符都是在 `json` 或者 `yaml` 文件中使用映射定义的，并且只支持 _基于等值_ 需求的选择算符： +两个对象的标签选择算符都是在 `json` 或者 `yaml` 文件中使用映射定义的，并且只支持 +_基于等值_ 需求的选择算符： ```json "selector": { diff --git a/content/zh/docs/concepts/policy/resource-quotas.md b/content/zh/docs/concepts/policy/resource-quotas.md index 60e9dcacc4..be1cf5765d 100644 --- a/content/zh/docs/concepts/policy/resource-quotas.md +++ b/content/zh/docs/concepts/policy/resource-quotas.md @@ -140,8 +140,7 @@ The following resource types are supported: | `limits.memory` | Across all pods in a non-terminal state, the sum of memory limits cannot exceed this value. | | `requests.cpu` | Across all pods in a non-terminal state, the sum of CPU requests cannot exceed this value. | | `requests.memory` | Across all pods in a non-terminal state, the sum of memory requests cannot exceed this value. | -| `hugepages-` | Across all pods in a non-terminal state, the number of -huge page requests of the specified size cannot exceed this value. | +| `hugepages-` | Across all pods in a non-terminal state, the number of huge page requests of the specified size cannot exceed this value. | | `cpu` | Same as `requests.cpu` | | `memory` | Same as `requests.memory` | --> diff --git a/content/zh/docs/concepts/configuration/pod-overhead.md b/content/zh/docs/concepts/scheduling-eviction/pod-overhead.md similarity index 95% rename from content/zh/docs/concepts/configuration/pod-overhead.md rename to content/zh/docs/concepts/scheduling-eviction/pod-overhead.md index 4f785b152e..98febf6328 100644 --- a/content/zh/docs/concepts/configuration/pod-overhead.md +++ b/content/zh/docs/concepts/scheduling-eviction/pod-overhead.md @@ -1,306 +1,306 @@ ---- -title: Pod 开销 -content_type: concept -weight: 20 ---- - - - -{{< feature-state for_k8s_version="v1.18" state="beta" >}} - - - -在节点上运行 Pod 时，Pod 本身占用大量系统资源。这些资源是运行 Pod 内容器所需资源的附加资源。 -_POD 开销_ 是一个特性，用于计算 Pod 基础设施在容器请求和限制之上消耗的资源。 - - - - - -## Pod 开销 - - - -在 Kubernetes 中，Pod 的开销是根据与 Pod 的 [RuntimeClass](/zh/docs/concepts/containers/runtime-class/) 相关联的开销在 -[准入](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks) 时设置的。 - - -当启用 Pod 开销时，在调度 Pod 时，除了考虑容器资源请求的总和外，还要考虑 Pod 开销。类似地，Kubelet 将在确定 Pod cgroup 的大小和执行 Pod 驱逐排序时包含 Pod 开销。 - - -## 启用 Pod 开销 {#set-up} - - -您需要确保在集群中启用了 `PodOverhead` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) -（在 1.18 默认是开启的），以及一个用于定义 `overhead` 字段的 `RuntimeClass`。 - - -## 使用示例 - - -要使用 PodOverhead 特性，需要一个定义 `overhead` 字段的 RuntimeClass。 -作为例子，可以在虚拟机和寄宿操作系统中通过一个虚拟化容器运行时来定义 -RuntimeClass 如下，其中每个 Pod 大约使用 120MiB: - -```yaml ---- -kind: RuntimeClass -apiVersion: node.k8s.io/v1beta1 -metadata: - name: kata-fc -handler: kata-fc -overhead: - podFixed: - memory: "120Mi" - cpu: "250m" -``` - - -通过指定 `kata-fc` RuntimeClass 处理程序创建的工作负载会将内存和 cpu 开销计入资源配额计算、节点调度以及 Pod cgroup 分级。 - -假设我们运行下面给出的工作负载示例 test-pod: - -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: test-pod -spec: - runtimeClassName: kata-fc - containers: - - name: busybox-ctr - image: busybox - stdin: true - tty: true - resources: - limits: - cpu: 500m - memory: 100Mi - - name: nginx-ctr - image: nginx - resources: - limits: - cpu: 1500m - memory: 100Mi -``` - - -在准入阶段 RuntimeClass [准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/) 更新工作负载的 PodSpec 以包含 - RuntimeClass 中定义的 `overhead`. 如果 PodSpec 中该字段已定义，该 Pod 将会被拒绝。 -在这个例子中，由于只指定了 RuntimeClass 名称，所以准入控制器更新了 Pod, 包含了一个 `overhead`. - - -在 RuntimeClass 准入控制器之后，可以检验一下已更新的 PodSpec: - -```bash -kubectl get pod test-pod -o jsonpath='{.spec.overhead}' -``` - - -输出： -``` -map[cpu:250m memory:120Mi] -``` - - -如果定义了 ResourceQuata, 则容器请求的总量以及 `overhead` 字段都将计算在内。 - - -当 kube-scheduler 决定在哪一个节点调度运行新的 Pod 时，调度器会兼顾该 Pod 的 `overhead` 以及该 Pod 的容器请求总量。在这个示例中，调度器将资源请求和开销相加，然后寻找具备 2.25 CPU 和 320 MiB 内存可用的节点。 - - -一旦 Pod 调度到了某个节点， 该节点上的 kubelet 将为该 Pod 新建一个 {{< glossary_tooltip text="cgroup" term_id="cgroup" >}}. 底层容器运行时将在这个 pod 中创建容器。 - - -如果该资源对每一个容器都定义了一个限制（定义了受限的 Guaranteed QoS 或者 Bustrable QoS），kubelet 会为与该资源（CPU 的 cpu.cfs_quota_us 以及内存的 memory.limit_in_bytes） -相关的 pod cgroup 设定一个上限。该上限基于容器限制总量与 PodSpec 中定义的 `overhead` 之和。 - - -对于 CPU, 如果 Pod 的 QoS 是 Guaranteed 或者 Burstable, kubelet 会基于容器请求总量与 PodSpec 中定义的 `overhead` 之和设置 `cpu.shares`. - - -请看这个例子，验证工作负载的容器请求： -```bash -kubectl get pod test-pod -o jsonpath='{.spec.containers[*].resources.limits}' -``` - - -容器请求总计 2000m CPU 和 200MiB 内存： -``` -map[cpu: 500m memory:100Mi] map[cpu:1500m memory:100Mi] -``` - - -对照从节点观察到的情况来检查一下： -```bash -kubectl describe node | grep test-pod -B2 -``` - - -该输出显示请求了 2250m CPU 以及 320MiB 内存，包含了 PodOverhead 在内： -``` - Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits AGE - --------- ---- ------------ ---------- --------------- ------------- --- - default test-pod 2250m (56%) 2250m (56%) 320Mi (1%) 320Mi (1%) 36m -``` - - -## 验证 Pod cgroup 限制 - - -在工作负载所运行的节点上检查 Pod 的内存 cgroups. 在接下来的例子中，将在该节点上使用具备 CRI 兼容的容器运行时命令行工具 [`crictl`](https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md). -这是一个展示 PodOverhead 行为的进阶示例，用户并不需要直接在该节点上检查 cgroups. - -首先在特定的节点上确定该 Pod 的标识符：ying - - -```bash -# 在该 Pod 调度的节点上执行如下命令： -POD_ID="$(sudo crictl pods --name test-pod -q)" -``` - - -可以依此判断该 Pod 的 cgroup 路径： - - -```bash -# 在该 Pod 调度的节点上执行如下命令： -sudo crictl inspectp -o=json $POD_ID | grep cgroupsPath -``` - - -执行结果的 cgroup 路径中包含了该 Pod 的 `pause` 容器。Pod 级别的 cgroup 即上面的一个目录。 -``` - "cgroupsPath": "/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/7ccf55aee35dd16aca4189c952d83487297f3cd760f1bbf09620e206e7d0c27a" -``` - - -在这个例子中，该 pod 的 cgroup 路径是 `kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2`。验证内存的 Pod 级别 cgroup 设置： - - -```bash -# 在该 Pod 调度的节点上执行这个命令。 -# 另外，修改 cgroup 的名称以匹配为该 pod 分配的 cgroup。 - cat /sys/fs/cgroup/memory/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/memory.limit_in_bytes -``` - - -和预期的一样是 320 MiB -``` -335544320 -``` - - -### 可观察性 - - -在 [kube-state-metrics](https://github.com/kubernetes/kube-state-metrics) 中可以通过 `kube_pod_overhead` 指标来协助确定何时使用 PodOverhead 以及协助观察以一个既定开销运行的工作负载的稳定性。 -该特性在 kube-state-metrics 的 1.9 发行版本中不可用，不过预计将在后续版本中发布。在此之前，用户需要从源代码构建 kube-state-metrics. - -## {{% heading "whatsnext" %}} - -* [RuntimeClass](/zh/docs/concepts/containers/runtime-class/) -* [PodOverhead 设计](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md) - +--- +title: Pod 开销 +content_type: concept +weight: 20 +--- + + + +{{< feature-state for_k8s_version="v1.18" state="beta" >}} + + + +在节点上运行 Pod 时，Pod 本身占用大量系统资源。这些资源是运行 Pod 内容器所需资源的附加资源。 +_POD 开销_ 是一个特性，用于计算 Pod 基础设施在容器请求和限制之上消耗的资源。 + + + + + +## Pod 开销 + + + +在 Kubernetes 中，Pod 的开销是根据与 Pod 的 [RuntimeClass](/zh/docs/concepts/containers/runtime-class/) 相关联的开销在 +[准入](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks) 时设置的。 + + +当启用 Pod 开销时，在调度 Pod 时，除了考虑容器资源请求的总和外，还要考虑 Pod 开销。类似地，Kubelet 将在确定 Pod cgroup 的大小和执行 Pod 驱逐排序时包含 Pod 开销。 + + +## 启用 Pod 开销 {#set-up} + + +您需要确保在集群中启用了 `PodOverhead` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) +（在 1.18 默认是开启的），以及一个用于定义 `overhead` 字段的 `RuntimeClass`。 + + +## 使用示例 + + +要使用 PodOverhead 特性，需要一个定义 `overhead` 字段的 RuntimeClass。 +作为例子，可以在虚拟机和寄宿操作系统中通过一个虚拟化容器运行时来定义 +RuntimeClass 如下，其中每个 Pod 大约使用 120MiB: + +```yaml +--- +kind: RuntimeClass +apiVersion: node.k8s.io/v1beta1 +metadata: + name: kata-fc +handler: kata-fc +overhead: + podFixed: + memory: "120Mi" + cpu: "250m" +``` + + +通过指定 `kata-fc` RuntimeClass 处理程序创建的工作负载会将内存和 cpu 开销计入资源配额计算、节点调度以及 Pod cgroup 分级。 + +假设我们运行下面给出的工作负载示例 test-pod: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-pod +spec: + runtimeClassName: kata-fc + containers: + - name: busybox-ctr + image: busybox + stdin: true + tty: true + resources: + limits: + cpu: 500m + memory: 100Mi + - name: nginx-ctr + image: nginx + resources: + limits: + cpu: 1500m + memory: 100Mi +``` + + +在准入阶段 RuntimeClass [准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/) 更新工作负载的 PodSpec 以包含 + RuntimeClass 中定义的 `overhead`. 如果 PodSpec 中该字段已定义，该 Pod 将会被拒绝。 +在这个例子中，由于只指定了 RuntimeClass 名称，所以准入控制器更新了 Pod, 包含了一个 `overhead`. + + +在 RuntimeClass 准入控制器之后，可以检验一下已更新的 PodSpec: + +```bash +kubectl get pod test-pod -o jsonpath='{.spec.overhead}' +``` + + +输出： +``` +map[cpu:250m memory:120Mi] +``` + + +如果定义了 ResourceQuata, 则容器请求的总量以及 `overhead` 字段都将计算在内。 + + +当 kube-scheduler 决定在哪一个节点调度运行新的 Pod 时，调度器会兼顾该 Pod 的 `overhead` 以及该 Pod 的容器请求总量。在这个示例中，调度器将资源请求和开销相加，然后寻找具备 2.25 CPU 和 320 MiB 内存可用的节点。 + + +一旦 Pod 调度到了某个节点， 该节点上的 kubelet 将为该 Pod 新建一个 {{< glossary_tooltip text="cgroup" term_id="cgroup" >}}. 底层容器运行时将在这个 pod 中创建容器。 + + +如果该资源对每一个容器都定义了一个限制（定义了受限的 Guaranteed QoS 或者 Bustrable QoS），kubelet 会为与该资源（CPU 的 cpu.cfs_quota_us 以及内存的 memory.limit_in_bytes） +相关的 pod cgroup 设定一个上限。该上限基于容器限制总量与 PodSpec 中定义的 `overhead` 之和。 + + +对于 CPU, 如果 Pod 的 QoS 是 Guaranteed 或者 Burstable, kubelet 会基于容器请求总量与 PodSpec 中定义的 `overhead` 之和设置 `cpu.shares`. + + +请看这个例子，验证工作负载的容器请求： +```bash +kubectl get pod test-pod -o jsonpath='{.spec.containers[*].resources.limits}' +``` + + +容器请求总计 2000m CPU 和 200MiB 内存： +``` +map[cpu: 500m memory:100Mi] map[cpu:1500m memory:100Mi] +``` + + +对照从节点观察到的情况来检查一下： +```bash +kubectl describe node | grep test-pod -B2 +``` + + +该输出显示请求了 2250m CPU 以及 320MiB 内存，包含了 PodOverhead 在内： +``` + Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits AGE + --------- ---- ------------ ---------- --------------- ------------- --- + default test-pod 2250m (56%) 2250m (56%) 320Mi (1%) 320Mi (1%) 36m +``` + + +## 验证 Pod cgroup 限制 + + +在工作负载所运行的节点上检查 Pod 的内存 cgroups. 在接下来的例子中，将在该节点上使用具备 CRI 兼容的容器运行时命令行工具 [`crictl`](https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md). +这是一个展示 PodOverhead 行为的进阶示例，用户并不需要直接在该节点上检查 cgroups. + +首先在特定的节点上确定该 Pod 的标识符： + + +```bash +# 在该 Pod 调度的节点上执行如下命令： +POD_ID="$(sudo crictl pods --name test-pod -q)" +``` + + +可以依此判断该 Pod 的 cgroup 路径： + + +```bash +# 在该 Pod 调度的节点上执行如下命令： +sudo crictl inspectp -o=json $POD_ID | grep cgroupsPath +``` + + +执行结果的 cgroup 路径中包含了该 Pod 的 `pause` 容器。Pod 级别的 cgroup 即上面的一个目录。 +``` + "cgroupsPath": "/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/7ccf55aee35dd16aca4189c952d83487297f3cd760f1bbf09620e206e7d0c27a" +``` + + +在这个例子中，该 pod 的 cgroup 路径是 `kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2`。验证内存的 Pod 级别 cgroup 设置： + + +```bash +# 在该 Pod 调度的节点上执行这个命令。 +# 另外，修改 cgroup 的名称以匹配为该 pod 分配的 cgroup。 + cat /sys/fs/cgroup/memory/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/memory.limit_in_bytes +``` + + +和预期的一样是 320 MiB +``` +335544320 +``` + + +### 可观察性 + + +在 [kube-state-metrics](https://github.com/kubernetes/kube-state-metrics) 中可以通过 `kube_pod_overhead` 指标来协助确定何时使用 PodOverhead 以及协助观察以一个既定开销运行的工作负载的稳定性。 +该特性在 kube-state-metrics 的 1.9 发行版本中不可用，不过预计将在后续版本中发布。在此之前，用户需要从源代码构建 kube-state-metrics. + +## {{% heading "whatsnext" %}} + +* [RuntimeClass](/zh/docs/concepts/containers/runtime-class/) +* [PodOverhead 设计](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md) + diff --git a/content/zh/docs/concepts/security/controlling-access.md b/content/zh/docs/concepts/security/controlling-access.md new file mode 100644 index 0000000000..137d44c364 --- /dev/null +++ b/content/zh/docs/concepts/security/controlling-access.md @@ -0,0 +1,333 @@ +--- +title: Kubernetes API 访问控制 +content_type: concept +--- + + + + + +本页面概述了对 Kubernetes API 的访问控制。 + + + +用户使用 `kubectl`、客户端库或构造 REST 请求访问来 [Kubernetes API](/zh/docs/concepts/overview/kubernetes-api/)。 +人类用户和 [Kubernetes 服务账户](/zh/docs/tasks/configure-pod-container/configure-service-account/)都可以被鉴权访问 API。 +当请求到达 API 时，它会经历多个阶段，如下图所示： + +![Kubernetes API 请求处理步骤示意图](/images/docs/admin/access-control-overview.svg) + + +## 传输安全 {#transport-security} + + +在典型的 Kubernetes 集群中，API 服务器在 443 端口上提供服务，受 TLS 保护。 +API 服务器出示证书。 +该证书可以使用私有证书颁发机构（CA）签名，也可以基于链接到公认的 CA 的公钥基础架构签名。 + + +如果你的集群使用私有证书颁发机构，你需要在客户端的 `~/.kube/config` 文件中提供该 CA 证书的副本， +以便你可以信任该连接并确认该连接没有被拦截。 + +你的客户端可以在此阶段出示 TLS 客户端证书。 + + +## 认证 {#authentication} + + +如上图步骤 **1** 所示，建立 TLS 后， HTTP 请求将进入认证（Authentication）步骤。 +集群创建脚本或者集群管理员配置 API 服务器，使之运行一个或多个身份认证组件。 +身份认证组件在[认证](/zh/docs/reference/access-authn-authz/authentication/)节中有更详细的描述。 + + +认证步骤的输入整个 HTTP 请求；但是，通常组件只检查头部或/和客户端证书。 + +认证模块包含客户端证书、密码、普通令牌、引导令牌和 JSON Web 令牌（JWT，用于服务账户）。 + +可以指定多个认证模块，在这种情况下，服务器依次尝试每个验证模块，直到其中一个成功。 + + +如果请求认证不通过，服务器将以 HTTP 状态码 401 拒绝该请求。 +反之，该用户被认证为特定的 `username`，并且该用户名可用于后续步骤以在其决策中使用。 +部分验证器还提供用户的组成员身份，其他则不提供。 + + +## 鉴权 {#authorization} + + +如上图的步骤 **2** 所示，将请求验证为来自特定的用户后，请求必须被鉴权。 + +请求必须包含请求者的用户名、请求的行为以及受该操作影响的对象。 +如果现有策略声明用户有权完成请求的操作，那么该请求被鉴权通过。 + +例如，如果 Bob 有以下策略，那么他只能在 `projectCaribou` 名称空间中读取 Pod。 + +```json +{ + "apiVersion": "abac.authorization.kubernetes.io/v1beta1", + "kind": "Policy", + "spec": { + "user": "bob", + "namespace": "projectCaribou", + "resource": "pods", + "readonly": true + } +} +``` + +如果 Bob 执行以下请求，那么请求会被鉴权，因为允许他读取 `projectCaribou` 名称空间中的对象。 + +```json +{ + "apiVersion": "authorization.k8s.io/v1beta1", + "kind": "SubjectAccessReview", + "spec": { + "resourceAttributes": { + "namespace": "projectCaribou", + "verb": "get", + "group": "unicorn.example.org", + "resource": "pods" + } + } +} +``` + +如果 Bob 在 `projectCaribou` 名字空间中请求写（`create` 或 `update`）对象，其鉴权请求将被拒绝。 +如果 Bob 在诸如 `projectFish` 这类其它名字空间中请求读取（`get`）对象，其鉴权也会被拒绝。 + +Kubernetes 鉴权要求使用公共 REST 属性与现有的组织范围或云提供商范围的访问控制系统进行交互。 +使用 REST 格式很重要，因为这些控制系统可能会与 Kubernetes API 之外的 API 交互。 + + +Kubernetes 支持多种鉴权模块，例如 ABAC 模式、RBAC 模式和 Webhook 模式等。 +管理员创建集群时，他们配置应在 API 服务器中使用的鉴权模块。 +如果配置了多个鉴权模块，则 Kubernetes 会检查每个模块，任意一个模块鉴权该请求，请求即可继续； +如果所有模块拒绝了该请求，请求将会被拒绝（HTTP 状态码 403）。 + +要了解更多有关 Kubernetes 鉴权的更多信息，包括有关使用支持鉴权模块创建策略的详细信息， +请参阅[鉴权](/zh/docs/reference/access-authn-authz/authorization/)。 + + +## 准入控制 {#admission-control} + + +准入控制模块是可以修改或拒绝请求的软件模块。 +除鉴权模块可用的属性外，准入控制模块还可以访问正在创建或修改的对象的内容。 + +准入控制器对创建、修改、删除或（通过代理）连接对象的请求进行操作。 +准入控制器不会对仅读取对象的请求起作用。 +有多个准入控制器被配置时，服务器将依次调用它们。 + + +这一操作如上图的步骤 **3** 所示。 + +与身份认证和鉴权模块不同，如果任何准入控制器模块拒绝某请求，则该请求将立即被拒绝。 + +除了拒绝对象之外，准入控制器还可以为字段设置复杂的默认值。 + +可用的准入控制模块在[准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/)中进行了描述。 + +请求通过所有准入控制器后，将使用检验例程检查对应的 API 对象，然后将其写入对象存储（如步骤 **4** 所示）。 + + +## API 服务器端口和 IP {#api-server-ports-and-ips} + + +前面的讨论适用于发送到 API 服务器的安全端口的请求（典型情况）。 API 服务器实际上可以在 2 个端口上提供服务： + +默认情况下，Kubernetes API 服务器在 2 个端口上提供 HTTP 服务： + + + 1. `localhost` 端口: + + - 用于测试和引导，以及主控节点上的其他组件（调度器，控制器管理器）与 API 通信 + - 没有 TLS + - 默认为端口 8080，使用 `--insecure-port` 进行更改 + - 默认 IP 为 localhost，使用 `--insecure-bind-address` 进行更改 + - 请求 **绕过** 身份认证和鉴权模块 + - 由准入控制模块处理的请求 + - 受需要访问主机的保护 + + 2. “安全端口”： + + - 尽可能使用 + - 使用 TLS。 用 `--tls-cert-file` 设置证书，用 `--tls-private-key-file` 设置密钥 + - 默认端口 6443，使用 `--secure-port` 更改 + - 默认 IP 是第一个非本地网络接口，使用 `--bind-address` 更改 + - 请求须经身份认证和鉴权组件处理 + - 请求须经准入控制模块处理 + - 身份认证和鉴权模块运行 + + +## {{% heading "whatsnext" %}} + + +阅读更多有关身份认证、鉴权和 API 访问控制的文档： + +- [认证](/zh/docs/reference/access-authn-authz/authentication/) + - [使用 Bootstrap 令牌进行身份认证](/zh/docs/reference/access-authn-authz/bootstrap-tokens/) +- [准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/) + - [动态准入控制](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/) +- [鉴权](/zh/docs/reference/access-authn-authz/authorization/) + - [基于角色的访问控制](/zh/docs/reference/access-authn-authz/rbac/) + - [基于属性的访问控制](/zh/docs/reference/access-authn-authz/abac/) + - [节点鉴权](/zh/docs/reference/access-authn-authz/node/) + - [Webhook 鉴权](/zh/docs/reference/access-authn-authz/webhook/) +- [证书签名请求](/zh/docs/reference/access-authn-authz/certificate-signing-requests/) + - 包括 [CSR 认证](/zh/docs/reference/access-authn-authz/certificate-signing-requests/#approval-rejection) + 和[证书签名](/zh/docs/reference/access-authn-authz/certificate-signing-requests/#signing) +- 服务账户 + - [开发者指导](/zh/docs/tasks/configure-pod-container/configure-service-account/) + - [管理](/zh/docs/reference/access-authn-authz/service-accounts-admin/) + +你可以了解 +- Pod 如何使用 + [Secrets](/zh/docs/concepts/configuration/secret/#service-accounts-automatically-create-and-attach-secrets-with-api-credentials) + 获取 API 凭证. \ No newline at end of file diff --git a/content/zh/docs/concepts/services-networking/network-policies.md b/content/zh/docs/concepts/services-networking/network-policies.md index 784455922a..6ea89e28f4 100644 --- a/content/zh/docs/concepts/services-networking/network-policies.md +++ b/content/zh/docs/concepts/services-networking/network-policies.md @@ -10,19 +10,43 @@ content_type: concept weight: 50 --> -{{< toc >}} - +如果你希望在 IP 地址或端口层面（OSI 第 3 层或第 4 层）控制网络流量， +则你可以考虑为集群中特定应用使用 Kubernetes 网络策略（NetworkPolicy）。 +NetworkPolicy 是一种以应用为中心的结构，允许你设置如何允许 +{{< glossary_tooltip text="Pod" term_id="pod">}} 与网络上的各类网络“实体” +（我们这里使用实体以避免过度使用诸如“端点”和“服务”这类常用术语， +这些术语在 Kubernetes 中有特定含义）通信。 -网络策略（NetworkPolicy）是一种关于 {{< glossary_tooltip text="Pod" term_id="pod">}} 间及与其他网络端点间所允许的通信规则的规范。 + +Pod 可以通信的 Pod 是通过如下三个标识符的组合来辩识的： + +1. 其他被允许的 Pods（例外：Pod 无法阻塞对自身的访问） +2. 被允许的名字空间 +3. IP 组块（例外：与 Pod 运行所在的节点的通信总是被允许的， + 无论 Pod 或节点的 IP 地址） + + +在定义基于 Pod 或名字空间的 NetworkPolicy 时，你会使用 +{{< glossary_tooltip text="选择算符" term_id="selector">}} 来设定哪些流量 +可以进入或离开与该算符匹配的 Pod。 + +同时，当基于 IP 的 NetworkPolicy 被创建时，我们基于 IP 组块（CIDR 范围） +来定义策略。 @@ -31,12 +55,11 @@ NetworkPolicy 资源使用 {{< glossary_tooltip text="标签" term_id="label">}} Network policies are implemented by the [network plugin](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/). To use network policies, you must be using a networking solution which supports NetworkPolicy. Creating a NetworkPolicy resource without a controller that implements it will have no effect. --> - -## 前提 +## 前置条件 {#prerequisites} 网络策略通过[网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) -来实现。要使用网络策略，用户必须使用支持 NetworkPolicy 的网络解决方案。 -创建一个资源对象，而没有控制器来使它生效的话，是没有任何作用的。 +来实现。要使用网络策略，你必须使用支持 NetworkPolicy 的网络解决方案。 +创建一个 NetworkPolicy 资源对象而没有控制器来使它生效的话，是没有任何作用的。 -## 隔离和非隔离的 Pod +## 隔离和非隔离的 Pod {#isolated-and-non-isolated-pods} 默认情况下，Pod 是非隔离的，它们接受任何来源的流量。 -Pod 可以通过相关的网络策略进行隔离。一旦命名空间中有网络策略选择了特定的 Pod， -该 Pod 会拒绝网络策略所不允许的连接。 -（命名空间下其他未被网络策略所选择的 Pod 会继续接收所有的流量） +Pod 在被某 NetworkPolicy 选中时进入被隔离状态。 +一旦名字空间中有 NetworkPolicy 选择了特定的 Pod，该 Pod 会拒绝该 NetworkPolicy +所不允许的连接。 +（名字空间下其他未被 NetworkPolicy 所选择的 Pod 会继续接受所有的流量） 网络策略不会冲突，它们是累积的。 如果任何一个或多个策略选择了一个 Pod, 则该 Pod 受限于这些策略的 -ingress/egress 规则的并集。因此评估的顺序并不会影响策略的结果。 +入站（Ingress）/出站（Egress）规则的并集。因此评估的顺序并不会影响策略的结果。 - ## NetworkPolicy 资源 {#networkpolicy-resource} -查看 [NetworkPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#networkpolicy-v1-networking-k8s-io) 来了解完整的资源定义。 +参阅 [NetworkPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#networkpolicy-v1-networking-k8s-io) +来了解资源的完整定义。 下面是一个 NetworkPolicy 的示例: @@ -127,27 +151,41 @@ and [Object Management](/docs/concepts/overview/working-with-objects/object-mana __spec__: NetworkPolicy [spec](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) has all the information needed to define a particular network policy in the given namespace. __podSelector__: Each NetworkPolicy includes a `podSelector` which selects the grouping of pods to which the policy applies. The example policy selects pods with the label "role=db". An empty `podSelector` selects all pods in the namespace. +--> +__必需字段__：与所有其他的 Kubernetes 配置一样，NetworkPolicy 需要 `apiVersion`、 +`kind` 和 `metadata` 字段。关于配置文件操作的一般信息，请参考 +[使用 ConfigMap 配置容器](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/), +和[对象管理](/zh/docs/concepts/overview/working-with-objects/object-management)。 +__spec__：NetworkPolicy [规约](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) +中包含了在一个名字空间中定义特定网络策略所需的所有信息。 + +__podSelector__：每个 NetworkPolicy 都包括一个 `podSelector`，它对该策略所 +适用的一组 Pod 进行选择。示例中的策略选择带有 "role=db" 标签的 Pod。 +空的 `podSelector` 选择名字空间下的所有 Pod。 + + -__必填字段__: 与所有其他的 Kubernetes 配置一样，NetworkPolicy 需要 `apiVersion`、`kind` 和 `metadata` 字段。 - 关于配置文件操作的一般信息，请参考 [使用 ConfigMap 配置容器](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/), - 和[对象管理](/zh/docs/concepts/overview/working-with-objects/object-management)。 +__policyTypes__: 每个 NetworkPolicy 都包含一个 `policyTypes` 列表，其中包含 +`Ingress` 或 `Egress` 或两者兼具。`policyTypes` 字段表示给定的策略是应用于 +进入所选 Pod 的入站流量还是来自所选 Pod 的出站流量，或两者兼有。 +如果 NetworkPolicy 未指定 `policyTypes` 则默认情况下始终设置 `Ingress`； +如果 NetworkPolicy 有任何出口规则的话则设置 `Egress`。 -__spec__: NetworkPolicy [规约](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) 中包含了在一个命名空间中定义特定网络策略所需的所有信息。 +__ingress__: 每个 NetworkPolicy 可包含一个 `ingress` 规则的白名单列表。 +每个规则都允许同时匹配 `from` 和 `ports` 部分的流量。示例策略中包含一条 +简单的规则： 它匹配某个特定端口，来自三个来源中的一个，第一个通过 `ipBlock` +指定，第二个通过 `namespaceSelector` 指定，第三个通过 `podSelector` 指定。 -__podSelector__: 每个 NetworkPolicy 都包括一个 `podSelector` ，它对该策略所应用的一组 Pod 进行选择。示例中的策略选择带有 "role=db" 标签的 Pod。空的 `podSelector` 选择命名空间下的所有 Pod。 - -__policyTypes__: 每个 NetworkPolicy 都包含一个 `policyTypes` 列表，其中包含 `Ingress` 或 `Egress` 或两者兼具。`policyTypes` 字段表示给定的策略是否应用于进入所选 Pod 的入口流量或者来自所选 Pod 的出口流量，或两者兼有。如果 NetworkPolicy 未指定 `policyTypes` 则默认情况下始终设置 `Ingress`，如果 NetworkPolicy 有任何出口规则的话则设置 `Egress`。 - -__ingress__: 每个 NetworkPolicy 可包含一个 `ingress` 规则的白名单列表。每个规则都允许同时匹配 `from` 和 `ports` 部分的流量。示例策略中包含一条简单的规则： 它匹配一个单一的端口，来自三个来源中的一个， 第一个通过 `ipBlock` 指定，第二个通过 `namespaceSelector` 指定，第三个通过 `podSelector` 指定。 - -__egress__: 每个 NetworkPolicy 可包含一个 `egress` 规则的白名单列表。每个规则都允许匹配 `to` 和 `port` 部分的流量。该示例策略包含一条规则，该规则将单个端口上的流量匹配到 `10.0.0.0/24` 中的任何目的地。 +__egress__: 每个 NetworkPolicy 可包含一个 `egress` 规则的白名单列表。 +每个规则都允许匹配 `to` 和 `port` 部分的流量。该示例策略包含一条规则， +该规则将指定端口上的流量匹配到 `10.0.0.0/24` 中的任何目的地。 - 所以，该网络策略示例: -1. 隔离 "default" 命名空间下 "role=db" 的 Pod (如果它们不是已经被隔离的话)。 -2. （Ingress 规则）允许以下 Pod 连接到 "default" 命名空间下的带有 “role=db” 标签的所有 Pod 的 6379 TCP 端口： +1. 隔离 "default" 名字空间下 "role=db" 的 Pod （如果它们不是已经被隔离的话）。 +2. （Ingress 规则）允许以下 Pod 连接到 "default" 名字空间下的带有 "role=db" + 标签的所有 Pod 的 6379 TCP 端口： - * "default" 命名空间下任意带有 "role=frontend" 标签的 Pod - * 带有 "project=myproject" 标签的任意命名空间中的 Pod - * IP 地址范围为 172.17.0.0–172.17.0.255 和 172.17.2.0–172.17.255.255（即，除了 172.17.1.0/24 之外的所有 172.17.0.0/16） -3. （Egress 规则）允许从带有 "role=db" 标签的命名空间下的任何 Pod 到 CIDR 10.0.0.0/24 下 5978 TCP 端口的连接。 + * "default" 名字空间下带有 "role=frontend" 标签的所有 Pod + * 带有 "project=myproject" 标签的所有名字空间中的 Pod + * IP 地址范围为 172.17.0.0–172.17.0.255 和 172.17.2.0–172.17.255.255 + （即，除了 172.17.1.0/24 之外的所有 172.17.0.0/16） -查看[声明网络策略](/zh/docs/tasks/administer-cluster/declare-network-policy/) 来进行更多的示例演练。 +3. （Egress 规则）允许从带有 "role=db" 标签的名字空间下的任何 Pod 到 CIDR + 10.0.0.0/24 下 5978 TCP 端口的连接。 + +参阅[声明网络策略](/zh/docs/tasks/administer-cluster/declare-network-policy/)演练 +了解更多示例。 +## 选择器 `to` 和 `from` 的行为 {#behavior-of-to-and-from-selectors} -## 选择器 `to` 和 `from` 的行为 +可以在 `ingress` 的 `from` 部分或 `egress` 的 `to` 部分中指定四种选择器： -可以在 `ingress` `from` 部分或 `egress` `to` 部分中指定四种选择器： +__podSelector__: 此选择器将在与 NetworkPolicy 相同的名字空间中选择特定的 +Pod，应将其允许作为入站流量来源或出站流量目的地。 -__podSelector__: 这将在与 NetworkPolicy 相同的命名空间中选择特定的 Pod，应将其允许作为入口源或出口目的地。 +__namespaceSelector__：此选择器将选择特定的名字空间，应将所有 Pod 用作其 +入站流量来源或出站流量目的地。 -__namespaceSelector__: 这将选择特定的命名空间，应将所有 Pod 用作其输入源或输出目的地。 - -__namespaceSelector__ *和* __podSelector__: 一个指定 `namespaceSelector` 和 `podSelector` 的 `to`/`from` 条目选择特定命名空间中的特定 Pod。注意使用正确的 YAML 语法；这项策略： +__namespaceSelector__ *和* __podSelector__： 一个指定 `namespaceSelector` +和 `podSelector` 的 `to`/`from` 条目选择特定名字空间中的特定 Pod。 +注意使用正确的 YAML 语法；下面的策略： ```yaml ... @@ -213,7 +258,8 @@ __namespaceSelector__ *和* __podSelector__: 一个指定 `namespaceSelector` -在 `from` 数组中仅包含一个元素，只允许来自标有 `role=client` 的 Pod 且该 Pod 所在的命名空间中标有 `user=alice` 的连接。但是 *这项* 策略： +在 `from` 数组中仅包含一个元素，只允许来自标有 `role=client` 的 Pod 且 +该 Pod 所在的名字空间中标有 `user=alice` 的连接。但是 *这项* 策略： ```yaml ... @@ -230,7 +276,11 @@ contains a single `from` element allowing connections from Pods with the label ` +在 `from` 数组中包含两个元素，允许来自本地名字空间中标有 `role=client` 的 +Pod 的连接，*或* 来自任何名字空间中标有 `user=alice` 的任何 Pod 的连接。 + - -在 `from` 数组中包含两个元素，允许来自本地命名空间中标有 `role=client` 的 Pod 的连接，*或* 来自任何命名空间中标有 `user = alice` 的任何 Pod 的连接。 - 如有疑问，请使用 `kubectl describe` 查看 Kubernetes 如何解释该策略。 -__ipBlock__: 这将选择特定的 IP CIDR 范围以用作入口源或出口目的地。 这些应该是群集外部 IP，因为 Pod IP 存在时间短暂的且随机产生。 +__ipBlock__: 此选择器将选择特定的 IP CIDR 范围以用作入站流量来源或出站流量目的地。 +这些应该是集群外部 IP，因为 Pod IP 存在时间短暂的且随机产生。 -群集的入口和出口机制通常需要重写数据包的源 IP 或目标 IP。在发生这种情况的情况下，不确定在 NetworkPolicy 处理之前还是之后发生，并且对于网络插件，云提供商，`Service` 实现等的不同组合，其行为可能会有所不同。 +集群的入站和出站机制通常需要重写数据包的源 IP 或目标 IP。 +在发生这种情况时，不确定在 NetworkPolicy 处理之前还是之后发生， +并且对于网络插件、云提供商、`Service` 实现等的不同组合，其行为可能会有所不同。 -在进入的情况下，这意味着在某些情况下，您可以根据实际的原始源 IP 过滤传入的数据包，而在其他情况下，NetworkPolicy 所作用的 `源IP` 则可能是 `LoadBalancer` 或 Pod 的节点等。 +对入站流量而言，这意味着在某些情况下，你可以根据实际的原始源 IP 过滤传入的数据包， +而在其他情况下，NetworkPolicy 所作用的 `源IP` 则可能是 `LoadBalancer` 或 +Pod 的节点等。 -对于出口，这意味着从 Pod 到被重写为集群外部 IP 的 `Service` IP 的连接可能会或可能不会受到基于 `ipBlock` 的策略的约束。 +对于出站流量而言，这意味着从 Pod 到被重写为集群外部 IP 的 `Service` IP +的连接可能会或可能不会受到基于 `ipBlock` 的策略的约束。 +## 默认策略 {#default-policies} -## 默认策略 - -默认情况下，如果命名空间中不存在任何策略，则所有进出该命名空间中的 Pod 的流量都被允许。以下示例使您可以更改该命名空间中的默认行为。 +默认情况下，如果名字空间中不存在任何策略，则所有进出该名字空间中 Pod 的流量都被允许。 +以下示例使你可以更改该名字空间中的默认行为。 +### 默认拒绝所有入站流量 -### 默认拒绝所有入口流量 - -您可以通过创建选择所有容器但不允许任何进入这些容器的入口流量的 NetworkPolicy 来为命名空间创建 "default" 隔离策略。 +你可以通过创建选择所有容器但不允许任何进入这些容器的入站流量的 NetworkPolicy +来为名字空间创建 "default" 隔离策略。 {{< codenew file="service/networking/network-policy-default-deny-ingress.yaml" >}} -这样可以确保即使容器没有选择其他任何 NetworkPolicy，也仍然可以被隔离。此策略不会更改默认的出口隔离行为。 +这样可以确保即使容器没有选择其他任何 NetworkPolicy，也仍然可以被隔离。 +此策略不会更改默认的出口隔离行为。 +### 默认允许所有入站流量 -### 默认允许所有入口流量 - -如果要允许所有流量进入某个命名空间中的所有 Pod（即使添加了导致某些 Pod 被视为“隔离”的策略），则可以创建一个策略来明确允许该命名空间中的所有流量。 +如果要允许所有流量进入某个名字空间中的所有 Pod（即使添加了导致某些 Pod 被视为 +“隔离”的策略），则可以创建一个策略来明确允许该名字空间中的所有流量。 {{< codenew file="service/networking/network-policy-allow-all-ingress.yaml" >}} @@ -305,10 +359,10 @@ If you want to allow all traffic to all pods in a namespace (even if policies ar You can create a "default" egress isolation policy for a namespace by creating a NetworkPolicy that selects all pods but does not allow any egress traffic from those pods. --> +### 默认拒绝所有出站流量 -### 默认拒绝所有出口流量 - -您可以通过创建选择所有容器但不允许来自这些容器的任何出口流量的 NetworkPolicy 来为命名空间创建 "default" egress 隔离策略。 +你可以通过创建选择所有容器但不允许来自这些容器的任何出站流量的 NetworkPolicy +来为名字空间创建 "default" egress 隔离策略。 {{< codenew file="service/networking/network-policy-default-deny-egress.yaml" >}} @@ -316,18 +370,18 @@ You can create a "default" egress isolation policy for a namespace by creating a This ensures that even pods that aren't selected by any other NetworkPolicy will not be allowed egress traffic. This policy does not change the default ingress isolation behavior. --> - -这样可以确保即使没有被其他任何 NetworkPolicy 选择的 Pod 也不会被允许流出流量。此策略不会更改默认的 ingress 隔离行为。 +此策略可以确保即使没有被其他任何 NetworkPolicy 选择的 Pod 也不会被允许流出流量。 +此策略不会更改默认的入站流量隔离行为。 +### 默认允许所有出站流量 -### 默认允许所有出口流量 - -如果要允许来自命名空间中所有 Pod 的所有流量（即使添加了导致某些 Pod 被视为“隔离”的策略），则可以创建一个策略，该策略明确允许该命名空间中的所有出口流量。 +如果要允许来自名字空间中所有 Pod 的所有流量（即使添加了导致某些 Pod 被视为“隔离”的策略）， +则可以创建一个策略，该策略明确允许该名字空间中的所有出站流量。 {{< codenew file="service/networking/network-policy-allow-all-egress.yaml" >}} @@ -336,41 +390,91 @@ If you want to allow all traffic from all pods in a namespace (even if policies You can create a "default" policy for a namespace which prevents all ingress AND egress traffic by creating the following NetworkPolicy in that namespace. --> +### 默认拒绝所有入口和所有出站流量 -### 默认拒绝所有入口和所有出口流量 - -您可以为命名空间创建 "default" 策略，以通过在该命名空间中创建以下 NetworkPolicy 来阻止所有入站和出站流量。 +你可以为名字空间创建“默认”策略，以通过在该名字空间中创建以下 NetworkPolicy +来阻止所有入站和出站流量。 {{< codenew file="service/networking/network-policy-default-deny-all.yaml" >}} - -这样可以确保即使没有被其他任何 NetworkPolicy 选择的 Pod 也不会被允许进入或流出流量。 +此策略可以确保即使没有被其他任何 NetworkPolicy 选择的 Pod 也不会被 +允许入站或出站流量。 ## SCTP 支持 -{{< feature-state for_k8s_version="v1.12" state="alpha" >}} +{{< feature-state for_k8s_version="v1.19" state="beta" >}} -要启用此特性，你（或你的集群管理员）需要通过为 API server 指定 `--feature-gates=SCTPSupport=true,…` -来启用 `SCTPSupport` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。 -启用该特性开关后，用户可以将 NetworkPolicy 的 `protocol` 字段设置为 `SCTP`。 +作为一个 Beta 特性，SCTP 支持默认是被启用的。 +要在集群层面禁用 SCTP，你（或你的集群管理员）需要为 API 服务器指定 +`--feature-gates=SCTPSupport=false,...` +来禁用 `SCTPSupport` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。 +启用该特性门控后，用户可以将 NetworkPolicy 的 `protocol` 字段设置为 `SCTP`。 {{< note >}} -必须使用支持 SCTP 协议网络策略的 {{< glossary_tooltip text="CNI" term_id="cni" >}} 插件。 +你必须使用支持 SCTP 协议网络策略的 {{< glossary_tooltip text="CNI" term_id="cni" >}} 插件。 {{< /note >}} + +## 你通过网络策略（至少目前还）无法完成的工作 + +到 Kubernetes v1.20 为止，NetworkPolicy API 还不支持以下功能，不过 +你可能可以使用操作系统组件（如 SELinux、OpenVSwitch、IPTables 等等） +或者第七层技术（Ingress 控制器、服务网格实现）或准入控制器来实现一些 +替代方案。 +如果你对 Kubernetes 中的网络安全性还不太了解，了解使用 NetworkPolicy API +还无法实现下面的用户场景是很值得的。 +对这些用户场景中的一部分（而非全部）的讨论扔在进行，或许在将来 NetworkPolicy +API 中会给出一定支持。 + + +- 强制集群内部流量经过某公用网关（这种场景最好通过服务网格或其他代理来实现）； +- 与 TLS 相关的场景（考虑使用服务网格或者 Ingress 控制器）； +- 特定于节点的策略（你可以使用 CIDR 来表达这一需求不过你无法使用节点在 + Kubernetes 中的其他标识信息来辩识目标节点）； +- 基于名字来选择名字空间或者服务（不过，你可以使用 {{< glossary_tooltip text="标签" term_id="label" >}} + 来选择目标 Pod 或名字空间，这也通常是一种可靠的替代方案）； +- 创建或管理由第三方来实际完成的“策略请求”； + +- 实现适用于所有名字空间或 Pods 的默认策略（某些第三方 Kubernetes 发行版本 + 或项目可以做到这点）； +- 高级的策略查询或者可达性相关工具； +- 在同一策略声明中选择目标端口范围的能力； +- 生成网络安全事件日志的能力（例如，被阻塞或接收的连接请求）； +- 显式地拒绝策略的能力（目前，NetworkPolicy 的模型默认采用拒绝操作， + 其唯一的能力是添加允许策略）； +- 禁止本地回路或指向宿主的网络流量（Pod 目前无法阻塞 localhost 访问， + 它们也无法禁止来自所在节点的访问请求）。 + ## {{% heading "whatsnext" %}} - -- 查看 [声明网络策略](/zh/docs/tasks/administer-cluster/declare-network-policy/) - 来进行更多的示例演练 -- 有关 NetworkPolicy 资源启用的常见场景的更多信息，请参见 +- 参阅[声明网络策略](/zh/docs/tasks/administer-cluster/declare-network-policy/) + 演练了解更多示例； +- 有关 NetworkPolicy 资源所支持的常见场景的更多信息，请参见 [此指南](https://github.com/ahmetb/kubernetes-network-policy-recipes)。 diff --git a/content/zh/docs/concepts/services-networking/service.md b/content/zh/docs/concepts/services-networking/service.md index 6da8bf54ee..af746c8b98 100644 --- a/content/zh/docs/concepts/services-networking/service.md +++ b/content/zh/docs/concepts/services-networking/service.md @@ -864,7 +864,7 @@ Kubernetes `ServiceTypes` 允许指定一个需要的类型的 Service，默认 * [`NodePort`](#nodeport)：通过每个 Node 上的 IP 和静态端口（`NodePort`）暴露服务。 `NodePort` 服务会路由到 `ClusterIP` 服务，这个 `ClusterIP` 服务会自动创建。 通过请求 `:`，可以从集群的外部访问一个 `NodePort` 服务。 - * [`LoadBalancer`](#loadbalancer)：使用云提供商的负载局衡器，可以向外部暴露服务。 + * [`LoadBalancer`](#loadbalancer)：使用云提供商的负载均衡器，可以向外部暴露服务。 外部的负载均衡器可以路由到 `NodePort` 服务和 `ClusterIP` 服务。 * [`ExternalName`](#externalname)：通过返回 `CNAME` 和它的值，可以将服务映射到 `externalName` 字段的内容（例如， `foo.bar.example.com`）。 diff --git a/content/zh/docs/concepts/workloads/_index.md b/content/zh/docs/concepts/workloads/_index.md index 525fab9044..911e8e0343 100644 --- a/content/zh/docs/concepts/workloads/_index.md +++ b/content/zh/docs/concepts/workloads/_index.md @@ -3,3 +3,116 @@ title: "工作负载" weight: 50 description: 理解 Pods，Kubernetes 中可部署的最小计算对象，以及辅助它运行它们的高层抽象对象。 --- + + + +{{< glossary_definition term_id="workload" length="short" >}} + + +无论你的负载是单一组件还是由多个一同工作的组件构成，在 Kubernetes 中你 +可以在一组 [Pods](/zh/docs/concepts/workloads/pods) 中运行它。 +在 Kubernetes 中，Pod 代表的是集群上处于运行状态的一组 +{{< glossary_tooltip text="容器" term_id="container" >}}。 + +Pod 有确定的生命周期。例如，一旦某 Pod 在你的集群中运行，Pod 运行所在的 +{{< glossary_tooltip text="节点" term_id="node" >}} 出现致命错误时， +所有该节点上的 Pods 都会失败。Kubernetes 将这类失败视为最终状态： +即使节点后来恢复正常运行，你也需要创建新的 Pod。 + + +不过，为了让用户的日子略微好过一些，你并不需要直接管理每个 Pod。 +相反，你可以使用 _负载资源_ 来替你管理一组 Pods。 +这些资源配置 {{< glossary_tooltip term_id="controller" text="控制器" >}} +来确保合适类型的、处于运行状态的 Pod 个数是正确的，与你所指定的状态相一致。 + +这些工作负载资源包括： + + +* [Deployment](/zh/docs/concepts/workloads/controllers/deployment/) 和 + [ReplicaSet](/zh/docs/concepts/workloads/controllers/replicaset/) + （替换原来的资源 {{< glossary_tooltip text="ReplicationController" term_id="replication-controller" >}}）； +* [StatefulSet](/zh/docs/concepts/workloads/controllers/statefulset/); +* 用来运行提供节点本地支撑设施（如存储驱动或网络插件）的 Pods 的 + [DaemonSet](/zh/docs/concepts/workloads/controllers/daemonset/)； +* 用来执行运行到结束为止的 + [Job](/zh/docs/concepts/workloads/controllers/job/) 和 + [CronJob](/zh/docs/concepts/workloads/controllers/cron-jobs/)。 + + +你可能发现还有两种支撑概念很有用： + +* [垃圾收集](/zh/docs/concepts/workloads/controllers/garbage-collection/)机制负责在 + 对象的 _属主资源_ 被删除时在集群中清理这些对象。 +* [_结束后存在时间_ 控制器](/zh/docs/concepts/workloads/controllers/ttlafterfinished/) + 会在 Job 结束之后的指定时间间隔之后删除它们。 + +## {{% heading "whatsnext" %}} + + +除了阅读了解每类资源外，你还可以了解与这些资源相关的任务： + +* [使用 Deployment 运行一个无状态的应用](/zh/docs/tasks/run-application/run-stateless-application-deployment/) +* 以[单实例](/zh/docs/tasks/run-application/run-single-instance-stateful-application/) + 或者[多副本集合](/zh/docs/tasks/run-application/run-replicated-stateful-application/) + 的形式运行有状态的应用； +* [使用 CronJob 运行自动化的任务](/zh/docs/tasks/job/automated-tasks-with-cron-jobs/) + + +一旦你的应用处于运行状态，你就可能想要 +以[服务](/zh/docs/concepts/services-networking/service/) +使之在互联网上可访问；或者对于 Web 应用而言，使用 +[Ingress](/docs/concepts/services-networking/ingress) 资源将其暴露到互联网上。 + diff --git a/content/zh/docs/contribute/new-content/overview.md b/content/zh/docs/contribute/new-content/overview.md index 0deead5b8d..51cf482b7b 100644 --- a/content/zh/docs/contribute/new-content/overview.md +++ b/content/zh/docs/contribute/new-content/overview.md @@ -87,7 +87,7 @@ If you're still not sure which branch to choose, ask in `#sig-docs` on Slack. 场景 | 分支 :---------|:------------ 针对当前发行版本的，对现有英文内容的修改或新的英文内容 | `master` -针对功能特性变更的内容 | 功能特性所对应的版本所对应的分支，分支名字模式为 `dev-release-`。例如，如果某功能特性在 `{{< latest-version >}}` 版本发生变化，则对应的文档变化要添加到 `dev-{{< release-branch >}}` 分支。 +针对功能特性变更的内容 | 功能特性所对应的版本所对应的分支，分支名字模式为 `dev-`。例如，如果某功能特性在 `v{{< skew nextMinorVersion >}}` 版本发生变化，则对应的文档变化要添加到 ``dev-{{< skew nextMinorVersion >}}`` 分支。 其他语言的内容（本地化）| 基于本地化团队的约定。参见[本地化分支策略](/zh/docs/contribute/localization/#branching-strategy)了解更多信息。 如果你仍不能确定要选择哪个分支，请在 `#sig-docs` Slack 频道上提问。 diff --git a/content/zh/docs/reference/glossary/object.md b/content/zh/docs/reference/glossary/object.md new file mode 100755 index 0000000000..31998e9a7a --- /dev/null +++ b/content/zh/docs/reference/glossary/object.md @@ -0,0 +1,42 @@ +--- +title: 对象 +id: object +date: 2020-10-12 +full_link: https://kubernetes.io/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects +short_description: > + Kubernetes 系统中的实体, 代表了集群的部分状态。 +aka: +tags: +- fundamental +--- + + +Kubernetes 系统中的实体。Kubernetes API 用这些实体表示集群的状态。 + + + +Kubernetes 对象通常是一个“目标记录”-一旦你创建了一个对象，Kubernetes +{{< glossary_tooltip text="控制平面" term_id="control-plane" >}} +不断工作，以确保它代表的项目确实存在。 +创建一个对象相当于告知 Kubernetes 系统：你期望这部分集群负载看起来像什么；这也就是你集群的期望状态。 \ No newline at end of file diff --git a/content/zh/docs/reference/setup-tools/kubeadm/_index.md b/content/zh/docs/reference/setup-tools/kubeadm/_index.md index 02e5561dba..60204dfa6d 100644 --- a/content/zh/docs/reference/setup-tools/kubeadm/_index.md +++ b/content/zh/docs/reference/setup-tools/kubeadm/_index.md @@ -9,6 +9,7 @@ card: --- + @@ -24,7 +25,7 @@ kubeadm 通过执行必要的操作来启动和运行最小可用集群。按照 -相反，我们希望在 Kubeadm 之上构建更高级别以及更加合规的工具，理想情况下，使用 kubeadm 作为所有部署工作的基准将会更加易于创建一致性集群。 +相反，我们希望在 kubeadm 之上构建更高级别以及更加合规的工具，理想情况下，使用 kubeadm 作为所有部署工作的基准将会更加易于创建一致性集群。 -要安装 kubeadm, 请查阅[安装指南](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/). +要安装 kubeadm, 请查阅[安装指南](/zh/docs/setup/production-environment/tools/kubeadm/install-kubeadm/). ## {{% heading "whatsnext" %}} @@ -48,11 +49,11 @@ To install kubeadm, see the [installation guide](/docs/setup/production-environm * [kubeadm version](/docs/reference/setup-tools/kubeadm/kubeadm-version) to print the kubeadm version * [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha) to preview a set of features made available for gathering feedback from the community --> -* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init) 用于搭建控制平面节点 -* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join) 用于搭建工作节点并将其加入到集群中 -* [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade) 用于升级 Kubernetes 集群到新版本 -* [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config) 如果你使用了 v1.7.x 或更低版本的 kubeadm 版本初始化你的集群，则使用 `kubeadm upgrade` 来配置你的集群 -* [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token) 用于管理 `kubeadm join` 使用的令牌 -* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset) 用于恢复通过 `kubeadm init` 或者 `kubeadm join` 命令对节点进行的任何变更 -* [kubeadm version](/docs/reference/setup-tools/kubeadm/kubeadm-version) 用于打印 kubeadm 的版本信息 -* [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha) 用于预览一组可用于收集社区反馈的特性 +* [kubeadm init](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init) 用于搭建控制平面节点 +* [kubeadm join](/zh/docs/reference/setup-tools/kubeadm/kubeadm-join) 用于搭建工作节点并将其加入到集群中 +* [kubeadm upgrade](/zh/docs/reference/setup-tools/kubeadm/kubeadm-upgrade) 用于升级 Kubernetes 集群到新版本 +* [kubeadm config](/zh/docs/reference/setup-tools/kubeadm/kubeadm-config) 如果你使用了 v1.7.x 或更低版本的 kubeadm 版本初始化你的集群，则使用 `kubeadm upgrade` 来配置你的集群 +* [kubeadm token](/zh/docs/reference/setup-tools/kubeadm/kubeadm-token) 用于管理 `kubeadm join` 使用的令牌 +* [kubeadm reset](/zh/docs/reference/setup-tools/kubeadm/kubeadm-reset) 用于恢复通过 `kubeadm init` 或者 `kubeadm join` 命令对节点进行的任何变更 +* [kubeadm version](/zh/docs/reference/setup-tools/kubeadm/kubeadm-version) 用于打印 kubeadm 的版本信息 +* [kubeadm alpha](/zh/docs/reference/setup-tools/kubeadm/kubeadm-alpha) 用于预览一组可用于收集社区反馈的特性 diff --git a/content/zh/docs/setup/production-environment/tools/kubespray.md b/content/zh/docs/setup/production-environment/tools/kubespray.md new file mode 100644 index 0000000000..126d1a1305 --- /dev/null +++ b/content/zh/docs/setup/production-environment/tools/kubespray.md @@ -0,0 +1,256 @@ +--- +title: 使用 Kubespray 安装 Kubernetes +content_type: concept +weight: 30 +--- + + + + + +此快速入门有助于使用 [Kubespray](https://github.com/kubernetes-sigs) 安装在 GCE、Azure、OpenStack、AWS、vSphere、Packet（裸机）、Oracle Cloud Infrastructure（实验性）或 Baremetal 上托管的 Kubernetes 集群。 + + +Kubespray 是一个由 [Ansible](https://docs.ansible.com/) playbooks、[清单（inventory）](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/ansible.md)、供应工具和通用 OS/Kubernetes 集群配置管理任务的领域知识组成的。 Kubespray 提供： + + +* 高可用性集群 +* 可组合属性 +* 支持大多数流行的 Linux 发行版 + * Ubuntu 16.04、18.04、20.04 + * CentOS / RHEL / Oracle Linux 7、8 + * Debian Buster，Jessie，Stretch，Wheezy + * Fedora 31、32 + * Fedora CoreOS + * openSUSE Leap 15 + * Kinvolk 的 Flatcar Container Linux +* 持续集成测试 + + +要选择最适合你的用例的工具，请阅读[此比较](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md)以 + [kubeadm](/zh/docs/reference/setup-tools/kubeadm/kubeadm/) 和 [kops](/zh/docs/setup/production-environment/tools/kops/) 。 + + + + +## 创建集群 + +### （1/5）满足下层设施要求 + + +按以下[要求](https://github.com/kubernetes-sigs/kubespray#requirements)来配置服务器： + + +* 在将运行 Ansible 命令的计算机上安装 Ansible v2.9 和 python-netaddr +* **运行 Ansible Playbook 需要 Jinja 2.11（或更高版本）** +* 目标服务器必须有权访问 Internet 才能拉取 Docker 镜像。否则，需要其他配置（[请参见离线环境](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/offline-environment.md)） +* 目标服务器配置为允许 IPv4 转发 +* **你的 SSH 密钥必须复制**到清单中的所有服务器部分 +* 防火墙不受管理，你将需要按照以前的方式实施自己的规则。为了避免在部署过程中出现任何问题，你应该禁用防火墙 +* 如果从非 root 用户帐户运行 kubespray，则应在目标服务器中配置正确的特权升级方法。然后应指定“ansible_become” 标志或命令参数 “--become” 或 “-b” + + +Kubespray 提供以下实用程序来帮助你设置环境： + +* 为以下云驱动提供的 [Terraform](https://www.terraform.io/) 脚本： +* [AWS](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/aws) +* [OpenStack](http://sitebeskuethree/contrigetbernform/contribeskubernform/contribeskupernform/https/sitebesku/master/) +* [Packet](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/packet) + + +### （2/5）编写清单文件 + +设置服务器后，请创建一个 [Ansible 的清单文件](https://docs.ansible.com/ansible/intro_inventory.html)。你可以手动执行此操作，也可以通过动态清单脚本执行此操作。有关更多信息，请参阅“[建立你自己的清单](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory)”。 + +### （3/5）规划集群部署 + +Kubespray 能够自定义部署的许多方面： + + +* 选择部署模式： kubeadm 或非 kubeadm +* CNI（网络）插件 +* DNS 配置 +* 控制平面的选择：本机/可执行文件或容器化 +* 组件版本 +* Calico 路由反射器 +* 组件运行时选项 + * {{< glossary_tooltip term_id="docker" >}} + * {{< glossary_tooltip term_id="containerd" >}} + * {{< glossary_tooltip term_id="cri-o" >}} +* 证书生成方式 + + + +可以修改[变量文件](https://docs.ansible.com/ansible/playbooks_variables.html)以进行 Kubespray 定制。 +如果你刚刚开始使用 Kubespray，请考虑使用 Kubespray 默认设置来部署你的集群并探索 Kubernetes 。 + + +### （4/5）部署集群 + +接下来，部署你的集群： + +使用 [ansible-playbook](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#starting-custom-deployment) 进行j集群部署。 + +```shell +ansible-playbook -i your/inventory/inventory.ini cluster.yml -b -v \ + --private-key=~/.ssh/private_key +``` + +大型部署（超过 100 个节点）可能需要[特定的调整](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/large-deployments.md)，以获得最佳效果。 + + +### （5/5）验证部署 + +Kubespray 提供了一种使用 [Netchecker](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/netcheck.md) +验证 Pod 间连接和 DNS 解析的方法。 +Netchecker 确保 netchecker-agents pod 可以解析。 +DNS 请求并在默认名称空间内对每个请求执行 ping 操作。 +这些 Pods 模仿其余工作负载的类似行为，并用作集群运行状况指示器。 + +## 集群操作 + +Kubespray 提供了其他 Playbooks 来管理集群： _scale_ 和 _upgrade_。 + +### 扩展集群 + +你可以通过运行 scale playbook 向集群中添加工作节点。有关更多信息， +请参见 “[添加节点](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#adding-nodes)”。 +你可以通过运行 remove-node playbook 来从集群中删除工作节点。有关更多信息， +请参见 “[删除节点](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#remove-nodes)”。 + +### 升级集群 + +你可以通过运行 upgrade-cluster Playbook 来升级集群。有关更多信息，请参见 +“[升级](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/upgrades.md)”。 + +## 清理 + +你可以通过 [reset](https://github.com/kubernetes-sigs/kubespray/blob/master/reset.yml) Playbook +重置节点并清除所有与 Kubespray 一起安装的组件。 + +{{< caution >}} +运行 reset playbook 时，请确保不要意外地将生产集群作为目标！ +{{< /caution >}} + + +## 反馈 + +* Slack 频道：[#kubespray](https://kubernetes.slack.com/messages/kubespray/)（你可以在[此处](https://slack.k8s.io/)获得邀请） +* [GitHub 问题](https://github.com/kubernetes-sigs/kubespray/issues) + + +## {{％heading“ whatsnext”％}} + + +查看有关 Kubespray 的[路线图](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/roadmap.md)的计划工作。 diff --git a/content/zh/docs/setup/production-environment/turnkey-solutions.md b/content/zh/docs/setup/production-environment/turnkey-solutions.md new file mode 100644 index 0000000000..b8a4f55661 --- /dev/null +++ b/content/zh/docs/setup/production-environment/turnkey-solutions.md @@ -0,0 +1,25 @@ +--- +title: Turnkey 云解决方案 +content_type: concept +weight: 30 +--- + + + + +本页列示 Kubernetes 认证解决方案供应商。 +在每一个供应商分页，你可以学习如何安装和设置生产就绪的集群。 + + + +{{< cncf-landscape helpers=true category="certified-kubernetes-hosted" >}} diff --git a/content/zh/docs/setup/production-environment/turnkey/_index.md b/content/zh/docs/setup/production-environment/turnkey/_index.md deleted file mode 100644 index 5faa0f682c..0000000000 --- a/content/zh/docs/setup/production-environment/turnkey/_index.md +++ /dev/null @@ -1,4 +0,0 @@ ---- -title: Turnkey 云解决方案 -weight: 30 ---- diff --git a/content/zh/docs/setup/production-environment/turnkey/alibaba-cloud.md b/content/zh/docs/setup/production-environment/turnkey/alibaba-cloud.md deleted file mode 100644 index 055d1c41c3..0000000000 --- a/content/zh/docs/setup/production-environment/turnkey/alibaba-cloud.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -reviewers: -- colemickens -- brendandburns -title: 在阿里云上运行 Kubernetes ---- - - - -## 阿里云容器服务 - -[阿里云容器服务](https://www.alibabacloud.com/product/container-service)使您可以在阿里云 ECS 实例集群上运行和管理 Docker 应用程序。它支持流行的开源容器编排引擎：Docker Swarm 和 Kubernetes。 - -为了简化集群的部署和管理，请使用 [容器服务 Kubernetes 版](https://www.alibabacloud.com/product/kubernetes)。您可以按照 [Kubernetes 演练](https://www.alibabacloud.com/help/doc-detail/86737.htm)快速入门，其中有一些使用中文书写的[容器服务 Kubernetes 版教程](https://yq.aliyun.com/teams/11/type_blog-cid_200-page_1)。 - -要使用自定义二进制文件或开源版本的 Kubernetes，请按照以下说明进行操作。 - - -## 自定义部署 - -[阿里云 Kubernetes Cloud Provider 实现](https://github.com/AliyunContainerService/kubernetes) 的源代码是开源的，可在 GitHub 上获得。 - -有关更多信息，请参阅中文版本[快速部署 Kubernetes - 阿里云上的VPC环境](https://yq.aliyun.com/articles/66474)和[英文版本](https://www.alibabacloud.com/forum/read-830)。 \ No newline at end of file diff --git a/content/zh/docs/setup/production-environment/turnkey/aws.md b/content/zh/docs/setup/production-environment/turnkey/aws.md deleted file mode 100644 index 3b97c77bb7..0000000000 --- a/content/zh/docs/setup/production-environment/turnkey/aws.md +++ /dev/null @@ -1,166 +0,0 @@ ---- -title: 在 AWS EC2 上运行 Kubernetes -content_type: task ---- - - - - - -本页面介绍了如何在 AWS 上安装 Kubernetes 集群。 - -## {{% heading "prerequisites" %}} - - -在 AWS 上创建 Kubernetes 集群，你将需要 AWS 的 Access Key ID 和 Secret Access Key。 - - -### 支持的生产级别工具 - - -* [conjure-up](/zh/docs/setup/) 是 Kubernetes 的开源安装程序，可在 Ubuntu 上创建与原生 AWS 集成的 Kubernetes 集群。 - - -* [Kubernetes Operations](https://github.com/kubernetes/kops) - 生产级 K8s 的安装、升级和管理。支持在 AWS 运行 Debian、Ubuntu、CentOS 和 RHEL。 - - -* [kube-aws](https://github.com/kubernetes-incubator/kube-aws) 使用 [Flatcar Linux](https://www.flatcar-linux.org/) 节点创建和管理 Kubernetes 集群，它使用了 AWS 工具：EC2、CloudFormation 和 Autoscaling。 - - -* [KubeOne](https://github.com/kubermatic/kubeone) 是一个开源集群生命周期管理工具，它可用于创建，升级和管理高可用 Kubernetes 集群。 - - - - - - -## 集群入门 - - -### 命令行管理工具：kubectl - - -集群启动脚本将在你的工作站上为你提供一个 `kubernetes` 目录。 -或者，你可以从[此页面](https://github.com/kubernetes/kubernetes/releases)下载最新的 Kubernetes 版本。 - -接下来，将适当的二进制文件夹添加到你的 `PATH` 以访问 kubectl： - -```shell -# macOS -export PATH=/platforms/darwin/amd64:$PATH - -# Linux -export PATH=/platforms/linux/amd64:$PATH -``` - - -此工具的最新文档页面位于此处：[kubectl 手册](/zh/docs/reference/kubectl/kubectl/) - -默认情况下，`kubectl` 将使用在集群启动期间生成的 `kubeconfig` 文件对 API 进行身份验证。 -有关更多信息，请阅读 [kubeconfig 文件](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)。 - - -### 示例 - -请参阅[一个简单的 nginx 示例](/zh/docs/tasks/run-application/run-stateless-application-deployment/)试用你的新集群。 - -“Guestbook” 应用程序是另一个入门 Kubernetes 的流行示例：[guestbook 示例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/)。 - -有关更完整的应用程序，请查看[示例目录](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/)。 - - -## 集群伸缩 - -不支持通过 `kubectl` 添加和删除节点。你仍然可以通过调整在安装过程中创建的 -[Auto Scaling Group](https://docs.aws.amazon.com/autoscaling/latest/userguide/as-manual-scaling.html) -中的 “Desired” 和 “Max” 属性来手动伸缩节点数量。 - - -## 集群拆除 - -确保你用于配置集群的环境变量已被导出，然后在运行如下在 Kubernetes 目录的脚本： - -```shell -cluster/kube-down.sh -``` - - -## 支持等级 - -IaaS 提供商 | 配置管理 | 操作系统 | 网络 | 文档 | 符合率 | 支持等级 --------------------- | ------------ | ------------- | ---------- | --------------------------------------------- | ---------| ---------------------------- -AWS | kops | Debian | k8s (VPC) | [docs](https://github.com/kubernetes/kops) | | Community ([@justinsb](https://github.com/justinsb)) -AWS | CoreOS | CoreOS | flannel | [docs](/zh/docs/setup/) | | Community -AWS | Juju | Ubuntu | flannel, calico, canal | [docs](/zh/docs/setup/) | 100% | Commercial, Community -AWS | KubeOne | Ubuntu, CoreOS, CentOS | canal, weavenet | [docs](https://github.com/kubermatic/kubeone) | 100% | Commercial, Community - - -## 进一步阅读 - -请参阅 [Kubernetes 文档](/zh/docs/)了解有关管理和使用 Kubernetes 集群的更多详细信息。 - diff --git a/content/zh/docs/setup/production-environment/turnkey/azure.md b/content/zh/docs/setup/production-environment/turnkey/azure.md deleted file mode 100644 index a6db01d27a..0000000000 --- a/content/zh/docs/setup/production-environment/turnkey/azure.md +++ /dev/null @@ -1,76 +0,0 @@ ---- -reviewers: -- colemickens -- brendandburns -title: 在 Azure 上运行 Kubernetes ---- - - - - - -## Azure Kubernetes 服务 (AKS) - -[Azure Kubernetes 服务](https://azure.microsoft.com/zh-cn/services/kubernetes-service/)提供了简单的 -Kubernetes 集群部署方式。 - -有关通过 Azure Kubernetes 服务将 Kubernetes 集群部署到 Azure 的示例： - -**[微软 Azure Kubernetes 服务](https://docs.microsoft.com/en-us/azure/aks/intro-kubernetes)** - - -## 定制部署：AKS 引擎 - -Azure Kubernetes 服务的核心是**开源**，并且可以在 GitHub 上让社区使用和参与贡献：**[AKS 引擎](https://github.com/Azure/aks-engine)**。旧版 [ACS 引擎](https://github.com/Azure/acs-engine) 代码库已被弃用，以支持AKS-engine。 - -如果您需要在 Azure Kubernetes 服务正式支持的范围之外对部署进行自定义，则 AKS 引擎是一个不错的选择。这些自定义包括部署到现有虚拟网络中，利用多个代理程序池等。一些社区对 AKS 引擎的贡献甚至可能成为 Azure Kubernetes 服务的特性。 - -AKS 引擎的输入是一个描述 Kubernetes 集群的 apimodel JSON 文件。它和用于直接通过 Azure Kubernetes 服务部署集群的 Azure 资源管理器（ARM）模板语法相似。产生的输出是一个 ARM 模板，可以将其签入源代码管理，并使用它将 Kubernetes 集群部署到 Azure。 - -您可以按照 **[AKS 引擎 Kubernetes 教程](https://github.com/Azure/aks-engine/blob/master/docs/tutorials/README.md)**开始使用。 - - -## 适用于 Azure 的 CoreOS Tectonic - -适用于 Azure 的 CoreOS Tectonic Installer 是**开源的**，它可以让社区在 GitHub 上使用和参与贡献：**[Tectonic Installer](https://github.com/coreos/tectonic-installer)**。 - -当您需要进行自定义集群时，Tectonic Installer是一个不错的选择，因为它是基于 [Hashicorp 的 Terraform](https://www.terraform.io/docs/providers/azurerm/)，Azure资源管理器（ARM）提供程序构建的。这使用户可以使用熟悉的 Terraform 工具进行自定义或集成。 - -您可以开始使用 [在 Azure 上安装 Tectonic 指南](https://coreos.com/tectonic/docs/latest/install/azure/azure-terraform.html)。 \ No newline at end of file diff --git a/content/zh/docs/setup/production-environment/turnkey/gce.md b/content/zh/docs/setup/production-environment/turnkey/gce.md deleted file mode 100644 index 63ed0c916b..0000000000 --- a/content/zh/docs/setup/production-environment/turnkey/gce.md +++ /dev/null @@ -1,398 +0,0 @@ ---- -title: 在谷歌计算引擎上运行 Kubernetes -content_type: task ---- - - - - - - -下面的示例创建了一个 Kubernetes 集群，其中包含 3 个工作节点虚拟机和 1 个主虚拟机（即集群中有 4 个虚拟机）。 -这个集群是在你的工作站（或你认为方便的任何地方）设置和控制的。 - - -## {{% heading "prerequisites" %}} - - -如果你想要一个简化的入门体验和 GUI 来管理集群， -请考虑尝试[谷歌 Kubernetes 引擎](https://cloud.google.com/kubernetes-engine/)来安装和管理托管集群。 - - -有一个简单的方式可以使用 Kubernetes 开发环境进行实验， -就是点击下面的按钮，打开 Google Cloud Shell，其中包含了 Kubernetes 源仓库自动克隆的副本。 - - -[![在 Cloud Shell 中打卡](https://gstatic.com/cloudssh/images/open-btn.png)](https://console.cloud.google.com/cloudshell/open?git_repo=https://github.com/kubernetes/kubernetes&page=editor&open_in_editor=README.md) - - -如果你想要使用定制的二进制或者纯开源的 Kubernetes，请继续阅读下面的指导。 - - -### 前提条件 {#prerequisites} - - -1. 你需要一个启用了计费的谷歌云平台账号。 - 更多细节请访问[谷歌开发者控制台](https://console.cloud.google.com)。 -1. 根据需要安装 `gcloud`。 - `gcloud` 可作为[谷歌云 SDK](https://cloud.google.com/sdk/) 的一部分安装。 -1. 在[谷歌云开发者控制台](https://console.developers.google.com/apis/library) - 启用[计算引擎实例组管理器 API](https://console.developers.google.com/apis/api/replicapool.googleapis.com/overview) -1. 确保将 gcloud 设置成使用你想要的谷歌云平台项目。 - 你可以使用 `gcloud config list project` 检查当前项目， - 并通过 `gcloud config set project ` 修改它。 -1. 通过运行 `gcloud auth login`，确保你拥有 GCloud 的凭据。 -1. （可选）如果需要调用 GCE 的 API，你也必须运行 `gcloud auth application-default login`。 -1. 确保你能通过命令行启动 GCE 虚拟机。 - 至少确保你可以完成 GCE 快速入门的[创建实例](https://cloud.google.com/compute/docs/instances/#startinstancegcloud)部分。 -1. 确保你在没有交互式提示的情况下 SSH 到虚拟机。 - 查看 GCE 快速入门的[登录实例](https://cloud.google.com/compute/docs/instances/#sshing)部分。 - - - - - -## 启动集群 - - -你可以安装一个客户端，并使用这些命令的其中之一来启动集群（我们列出的两种情况，因为你的机器可能只安装了二者之一）： - -```shell -curl -sS https://get.k8s.io | bash -``` - -或 - -```shell -wget -q -O - https://get.k8s.io | bash -``` - - -这条命令结完成后，你将会有 1 个主虚拟机和 4 个工作虚拟机，它们一起作为 Kubernetes 集群运行。 - - -默认情况下，有一些容器已经在你的集群上运行。 -像 `fluentd` 这样的容器提供[日志记录](/zh/docs/concepts/cluster-administration/logging/)， -而 `heapster` 提供[监控](https://releases.k8s.io/master/cluster/addons/cluster-monitoring/README.md)服务。 - - -由上述命令运行的脚本创建了一个名称/前缀为“kubernetes”的集群。 -它定义了一个特定的集群配置，所以此脚本只能运行一次。 - - -或者，你可以通过[这个页面](https://github.com/kubernetes/kubernetes/releases)下载和安装最新版本的 Kubernetes， -然后运行 `/cluster/kube-up.sh` 脚本启动集群： - -```shell -cd kubernetes -cluster/kube-up.sh -``` - - -如果你希望在项目中运行多个集群，希望使用一个不同名称，或者不同数量工作节点的集群， -请查看 `/cluster/gce/config-default.sh` 文件，以便在启动集群之前进行更细粒度的配置。 - - - -如果你遇到了问题，请参阅[错误排查](#troubleshooting)一节， -发布到 [Kubernetes 论坛](https://discuss.kubernetes.io)，或者来 `#gke` Slack 频道中提问。 - - -接下来的几个步骤会告诉你: - - -1. 如何在你的工作站设置命令行客户端来管理集群 -2. 如何使用集群的示例 -3. 如何删除集群 -4. 如果以非默认选项启动集群（如规模较大的集群） - - -## 在你的工作站安装 Kubernetes 命令行工具 - - -集群启动脚本将在你的工作站上留下一个正在运行的集群和一个 `kubernetes` 目录。 - - -[kubectl](/zh/docs/reference/kubectl/kubectl/) 工具控制 Kubernetes 集群管理器。 -它允许你检查集群资源，创建、删除和更新组件等等。 -你将使用它来查看新集群并启动示例应用程序。 - - -你可以使用 `gcloud` 在工作站上安装 `kubectl` 命令行工具: - -```shell -gcloud components install kubectl -``` - -{{< note >}} - -与 `gcloud` 绑定的 kubectl 版本可能比 get.k8s.io 安装脚本所下载的更老。。 -查看[安装 kubectl](/zh/docs/tasks/tools/install-kubectl/) 文档，了解如何在工作站上设置最新的 `kubectl`。 -{{< /note >}} - - -## 开始使用你的集群 - - -### 检查你的集群 - - -一旦 `kubectl` 存在于你的路径中，你就可以使用它来查看集群，例如，运行： - -``` -kubectl get --all-namespaces services -``` - - -应该显示 [services](/zh/docs/concepts/services-networking/service/) 集合，看起来像这样： - -``` -NAMESPACE NAME TYPE CLUSTER_IP EXTERNAL_IP PORT(S) AGE -default kubernetes ClusterIP 10.0.0.1 443/TCP 1d -kube-system kube-dns ClusterIP 10.0.0.2 53/TCP,53/UDP 1d -kube-system kube-ui ClusterIP 10.0.0.3 80/TCP 1d -... -``` - - -类似的，你可以查看在集群启动时创建的 [pods](/zh/docs/concepts/workloads/pods/) 的集合。 -你可以通过命令： - -``` -kubectl get --all-namespaces pods -``` - - -你将会看到 Pod 的列表，看起来像这样（名称和细节会有所不同）： - -``` -NAMESPACE NAME READY STATUS RESTARTS AGE -kube-system coredns-5f4fbb68df-mc8z8 1/1 Running 0 15m -kube-system fluentd-cloud-logging-kubernetes-minion-63uo 1/1 Running 0 14m -kube-system fluentd-cloud-logging-kubernetes-minion-c1n9 1/1 Running 0 14m -kube-system fluentd-cloud-logging-kubernetes-minion-c4og 1/1 Running 0 14m -kube-system fluentd-cloud-logging-kubernetes-minion-ngua 1/1 Running 0 14m -kube-system kube-ui-v1-curt1 1/1 Running 0 15m -kube-system monitoring-heapster-v5-ex4u3 1/1 Running 1 15m -kube-system monitoring-influx-grafana-v1-piled 2/2 Running 0 15m -``` - - -一些 Pod 启动可能需要几秒钟（在此期间它们会显示 `Pending`）， -但是在短时间后请检查它们是否都显示为 `Running`。 - - -### 运行示例 - - -那么，看[一个简单的 nginx 示例](/zh/docs/tasks/run-application/run-stateless-application-deployment/)来试试你的新集群。 - - -要获得完整的应用，请查看 [examples 目录](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/)。 -[guestbook 示例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) -是一个很好的“入门”演练。 - - -## 拆除集群 - - -要移除/删除/拆除集群，请使用 `kube-down.sh` 脚本。 - -```shell -cd kubernetes -cluster/kube-down.sh -``` - - -同样地，同一目录下的 `kube-up.sh` 脚本会让集群重新运行起来。 -你不需要再次运行 `curl` 或 `wget` 命令：现在 Kubernetes 集群所需的一切都在你的工作站上。 - - -## 定制 - - -上面的脚本依赖于谷歌存储来保存 Kubernetes 发行版本。 -该脚本然后（默认情况下）会启动 1 个主虚拟机和 3 个工作虚拟机。 -你可以通过编辑 `kubernetes/cluster/gce/config-default.sh` 来调整这些参数。 -你可以在[这里](https://gist.github.com/satnam6502/fc689d1b46db9772adea)查看成功创建集群的记录。 - - -## 故障排除 {#troubleshooting} - - -### 项目设置 - - -你需要启用 Google Cloud Storage API 和 Google Cloud Storage JSON API。 -默认情况下，对新项目都是激活的。 -如果未激活，可以在谷歌云控制台设置。 -更多细节，请查看[谷歌云存储 JSON API 概览](https://cloud.google.com/storage/docs/json_api/)。 - - -也要确保——正如在[前提条件](#prerequisites)中列出的那样—— -你已经启用了 `Compute Engine Instance Group Manager API`， -并且可以像 [GCE 快速入门](https://cloud.google.com/compute/docs/quickstart)指导那样从命令行启动 GCE 虚拟机。 - - -### 集群初始化过程停滞 - - -如果 Kubernetes 启动脚本停滞，等待 API 可达， -你可以 SSH 登录到主虚拟机和工作虚拟机， -通过查看 `/var/log/startupscript.log` 日志来排除故障。 - - -**一旦解决了这个问题，你应该在部分集群创建之后运行 `kube-down.sh` 来进行清理**，然后再运行 `kube-up.sh` 重试。 - -### SSH - - -如果在 SSH 登录实例时遇到困难，确保 GCE 防火墙没有阻塞你虚拟机的 22 端口。 -默认情况下应该可用，但是如果你编辑了防火墙规则或者创建了一个新的非默认网络， -你需要公开它：`gcloud compute firewall-rules create default-ssh --network= --description "SSH allowed from anywhere" --allow tcp:22` - - -此外，你的 GCE SSH 密钥不能有密码，否则你需要使用 `ssh-agent`。 - - -### 网络 - - -虚拟机实例必须能够使用它们的私有 IP 彼此连接。 -该脚本使用 "default" 网络，此网络应该有一个名为 "default-allow-internal" 的防火墙规则， -此规则允许通过私有 IP 上的任何端口进行通信。 -如果默认网络中缺少此规则，或者更改了 `cluster/config-default.sh` 中使用的网络， -用以下字段值创建一个新规则: - - -* 源范围：`10.0.0.0/8` -* 允许的协议和端口：`tcp:1-65535;udp:1-65535;icmp` - - -## 支持等级 - - -IaaS 提供商 | 配置管理 | 操作系统 | 网络 | 文档 | 符合率 | 支持等级 ----------- | --------- | ------ | ---- | --------------------------------------------------------- | ----- | ------- -GCE | Saltstack | Debian | GCE | [docs](/zh/docs/setup/production-environment/turnkey/gce/) | | Project diff --git a/content/zh/docs/setup/production-environment/turnkey/icp.md b/content/zh/docs/setup/production-environment/turnkey/icp.md deleted file mode 100644 index 25ed57cd6c..0000000000 --- a/content/zh/docs/setup/production-environment/turnkey/icp.md +++ /dev/null @@ -1,162 +0,0 @@ ---- -reviewers: -- bradtopol -title: 使用 IBM Cloud Private 在多个云上运行 Kubernetes ---- - - - - -IBM® Cloud Private 是一个 一站式云解决方案并且是一个本地的一站式云解决方案。 IBM Cloud Private 提供纯上游 Kubernetes，以及运行实际企业工作负载所需的典型管理组件。这些工作负载包括健康管理、日志管理、审计跟踪以及用于跟踪平台上工作负载使用情况的计量。 - - -IBM Cloud Private 提供了社区版和全支持的企业版。可从 [Docker Hub](https://hub.docker.com/r/ibmcom/icp-inception/) 免费获得社区版本。企业版支持高可用性拓扑，并包括 IBM 对 Kubernetes 和 IBM Cloud Private 管理平台的商业支持。如果您想尝试 IBM Cloud Private，您可以使用托管试用版、教程或自我指导演示。您也可以尝试免费的社区版。有关详细信息，请参阅 [IBM Cloud Private 入门](https://www.ibm.com/cloud/private/get-started)。 - - -有关更多信息，请浏览以下资源： - -* [IBM Cloud Private](https://www.ibm.com/cloud/private) -* [IBM Cloud Private 参考架构](https://github.com/ibm-cloud-architecture/refarch-privatecloud) -* [IBM Cloud Private 文档](https://www.ibm.com/support/knowledgecenter/SSBS6K/product_welcome_cloud_private.html) - - -## IBM Cloud Private 和 Terraform - -您可以利用一下模块使用 Terraform 部署 IBM Cloud Private： - -* AWS：[将 IBM Cloud Private 部署到 AWS](https://github.com/ibm-cloud-architecture/terraform-icp-aws) -* Azure：[将 IBM Cloud Private 部署到 Azure](https://github.com/ibm-cloud-architecture/terraform-icp-azure) -* IBM Cloud：[将 IBM Cloud Private 集群部署到 IBM Cloud](https://github.com/ibm-cloud-architecture/terraform-icp-ibmcloud) -* OpenStack：[将IBM Cloud Private 部署到 OpenStack](https://github.com/ibm-cloud-architecture/terraform-icp-openstack) -* Terraform 模块：[在任何支持的基础架构供应商上部署 IBM Cloud Private](https://github.com/ibm-cloud-architecture/terraform-module-icp-deploy) -* VMware：[将 IBM Cloud Private 部署到 VMware](https://github.com/ibm-cloud-architecture/terraform-icp-vmware) - - - -## AWS 上的 IBM Cloud Private - - -您可以使用 AWS CloudFormation 或 Terraform 在 Amazon Web Services（AWS）上部署 IBM Cloud Private 集群。 - - -IBM Cloud Private 快速入门可以自动将 IBM Cloud Private 部署到 AWS Cloud 上的新虚拟私有云（VPC）中。常规部署大约需要60分钟，而高可用性（HA）部署大约需要75分钟。快速入门包括 AWS CloudFormation 模板和部署指南。 - - -这个快速入门适用于希望探索应用程序现代化并希望通过使用 IBM Cloud Private 和 IBM 工具加速实现其数字化转换目标的用户。快速入门可帮助用户在 AWS 上快速部署高可用性（HA）、生产级的 IBM Cloud Private 参考架构。有关所有详细信息和部署指南，请参阅 [IBM Cloud Private 在 AWS 上的快速入门 ](https://aws.amazon.com/quickstart/architecture/ibm-cloud-private/)。 - - -IBM Cloud Private 也可以通过使用 Terraform 在 AWS 云平台上运行。要在 AWS EC2 环境中部署 IBM Cloud Private，请参阅[在 AWS 上安装 IBM Cloud Private](https://github.com/ibm-cloud-architecture/refarch-privatecloud/blob/master/Installing_ICp_on_aws.md)。 - - -## Azure 上的 IBM Cloud Private - -您可以启用 Microsoft Azure 作为 IBM Cloud Private 部署的云提供者，并利用 Azure 公共云上的所有 IBM Cloud Private 功能。有关更多信息，请参阅 [Azure 上的 IBM Cloud Private](https://www.ibm.com/support/knowledgecenter/SSBS6K_3.2.0/supported_environments/azure_overview.html)。 - - -## 带有 Red Hat OpenShift 的 IBM Cloud Private - - -您可以将在 IBM Cloud Private 上运行的 IBM 认证的软件容器部署到 Red Hat OpenShift 上。 - - -整合能力： - -* 在仅脱机安装模式下支持 Linux®64 位平台 -* 单主控节点配置 -* 集成的 IBM Cloud Private 集群管理控制台和目录 -* 集成的核心平台服务，例如监控、计量和日志 -* IBM Cloud Private 使用 OpenShift 镜像仓库 - - -有关更多信息，请参阅 [OpenShift 上的 IBM Cloud Private](https://www.ibm.com/support/knowledgecenter/SSBS6K_3.2.0/supported_environments/openshift/overview.html)。 - - -## VirtualBox 上的 IBM Cloud Private - -要将 IBM Cloud Private 安装到 VirtualBox 环境，请参阅[在 VirtualBox 上安装 IBM Cloud Private](https://github.com/ibm-cloud-architecture/refarch-privatecloud-virtualbox)。 - - -## VMware 上的 IBM Cloud Private - - -您可以使用 Ubuntu 或 RHEL 镜像在 VMware 上安装 IBM Cloud Private。有关详细信息，请参见以下项目： - - -* [使用 Ubuntu 安装IBM Cloud Private](https://github.com/ibm-cloud-architecture/refarch-privatecloud/blob/master/Installing_ICp_on_prem_ubuntu.md) -* [使用 Red Hat Enterprise 安装 IBM Cloud Private](https://github.com/ibm-cloud-architecture/refarch-privatecloud/tree/master/icp-on-rhel) - - -IBM Cloud Private Hosted 服务会自动在您的 VMware vCenter Server 实例上部署 IBM Cloud Private Hosted。此服务将微服务和容器的功能带到 IBM Cloud上的VMware 环境中。使用此服务，您可以将同样熟悉的 VMware 和 IBM Cloud Private 操作模型和工具从本地扩展到 IBM Cloud。 - - -有关更多信息，请参阅 [IBM Cloud Private Hosted 服务](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-icp_overview)。 diff --git a/content/zh/docs/setup/production-environment/turnkey/tencent.md b/content/zh/docs/setup/production-environment/turnkey/tencent.md deleted file mode 100644 index 5a684987e7..0000000000 --- a/content/zh/docs/setup/production-environment/turnkey/tencent.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: 在腾讯云容器服务上运行 Kubernetes ---- - - - - -## 腾讯云容器服务 - -[腾讯云容器服务（TKE）](https://intl.cloud.tencent.com/product/tke)提供本地 Kubernetes 容器管理服务。您只需几个步骤即可使用 TKE 部署和管理 Kubernetes 集群。有关详细说明，请参阅[部署腾讯云容器服务](https://intl.cloud.tencent.com/document/product/457/11741)。 - - TKE 是[认证的 Kubernetes 产品](https://www.cncf.io/certification/software-conformance/)。它与原生 Kubernetes API 完全兼容。 - - -## 定制部署 - -腾讯 Kubernetes Engine 的核心是开源的，并且可以在 [GitHub](https://github.com/TencentCloud/tencentcloud-cloud-controller-manager/) 上使用。 - -使用 TKE 创建 Kubernetes 集群时，可以选择托管模式或独立部署模式。另外，您可以根据需要自定义部署。例如，您可以选择现有的 Cloud Virtual Machine 实例来创建集群，也可以在 IPVS 模式下启用 Kube-proxy。 - - -## 下一步 - - 要了解更多信息，请参阅 [TKE 文档](https://intl.cloud.tencent.com/document/product/457)。 \ No newline at end of file diff --git a/content/zh/docs/tasks/configure-pod-container/quality-service-pod.md b/content/zh/docs/tasks/configure-pod-container/quality-service-pod.md index 9808a3b9cb..d2ae4a6b2f 100644 --- a/content/zh/docs/tasks/configure-pod-container/quality-service-pod.md +++ b/content/zh/docs/tasks/configure-pod-container/quality-service-pod.md @@ -59,8 +59,8 @@ kubectl create namespace qos-example For a Pod to be given a QoS class of Guaranteed: -* Every Container in the Pod must have a memory limit and a memory request, and they must be the same. -* Every Container in the Pod must have a CPU limit and a CPU request, and they must be the same. +* Every Container, including init containers, in the Pod must have a memory limit and a memory request, and they must be the same. +* Every Container, including init containers, in the Pod must have a CPU limit and a CPU request, and they must be the same. Here is the configuration file for a Pod that has one Container. The Container has a memory limit and a memory request, both equal to 200 MiB. The Container has a CPU limit and a CPU request, both equal to 700 milliCPU: @@ -69,8 +69,8 @@ memory request, both equal to 200 MiB. The Container has a CPU limit and a CPU r 对于 QoS 类为 Guaranteed 的 Pod： -* Pod 中的每个容器必须指定内存请求和内存限制，并且两者要相等。 -* Pod 中的每个容器必须指定 CPU 请求和 CPU 限制，并且两者要相等。 +* Pod 中的每个容器，包含初始化容器，必须指定内存请求和内存限制，并且两者要相等。 +* Pod 中的每个容器，包含初始化容器，必须指定 CPU 请求和 CPU 限制，并且两者要相等。 下面是包含一个容器的 Pod 配置文件。 容器设置了内存请求和内存限制，值都是 200 MiB。 diff --git a/content/zh/docs/tasks/configure-pod-container/static-pod.md b/content/zh/docs/tasks/configure-pod-container/static-pod.md index 064313cc6a..8ed0c78338 100644 --- a/content/zh/docs/tasks/configure-pod-container/static-pod.md +++ b/content/zh/docs/tasks/configure-pod-container/static-pod.md @@ -201,7 +201,7 @@ JSON/YAML 格式的 Pod 定义文件。 -1. 创建一个 YAML 文件，并保存在保存在 web 服务上，为 kubelet 生成一个 URL。 +1. 创建一个 YAML 文件，并保存在 web 服务上，为 kubelet 生成一个 URL。 ```yaml apiVersion: v1 diff --git a/content/zh/docs/tasks/run-application/horizontal-pod-autoscale.md b/content/zh/docs/tasks/run-application/horizontal-pod-autoscale.md index 91226eaa7c..37315df914 100644 --- a/content/zh/docs/tasks/run-application/horizontal-pod-autoscale.md +++ b/content/zh/docs/tasks/run-application/horizontal-pod-autoscale.md @@ -3,7 +3,7 @@ title: Pod 水平自动扩缩 feature: title: 水平扩缩 description: > - 使用一个简单的命令、一个UI或基于CPU使用情况自动对应用程序进行扩缩。 + 使用一个简单的命令、一个 UI 或基于 CPU 使用情况自动对应用程序进行扩缩。 content_type: concept weight: 90 @@ -12,14 +12,14 @@ weight: 90 Pod 水平自动扩缩（Horizontal Pod Autoscaler） -可以基于 CPU 利用率自动扩缩 ReplicationController、Deployment 和 ReplicaSet 中的 Pod 数量。 +可以基于 CPU 利用率自动扩缩 ReplicationController、Deployment、ReplicaSet 和 StatefulSet 中的 Pod 数量。 除了 CPU 利用率，也可以基于其他应程序提供的[自定义度量指标](https://git.k8s.io/community/contributors/design-proposals/instrumentation/custom-metrics-api.md) 来执行自动扩缩。 Pod 自动扩缩不适用于无法扩缩的对象，比如 DaemonSet。 @@ -61,12 +61,12 @@ or the custom metrics API (for all other metrics). * 对于按 Pod 统计的资源指标（如 CPU），控制器从资源指标 API 中获取每一个 @@ -76,8 +76,8 @@ or the custom metrics API (for all other metrics). 接下来，控制器根据平均的资源使用率或原始值计算出扩缩的比例，进而计算出目标副本数。 -* 如果pod 使用对象指标和外部指标（每个指标描述一个对象信息）。 +* 如果 Pod 使用对象指标和外部指标（每个指标描述一个对象信息）。 这个指标将直接根据目标设定值相比较，并生成一个上面提到的扩缩比例。 - 在 `autoscaling/v2beta2` 版本API中，这个指标也可以根据 Pod 数量平分后再计算。 + 在 `autoscaling/v2beta2` 版本 API 中，这个指标也可以根据 Pod 数量平分后再计算。 自动扩缩控制器使用 scale 子资源访问相应可支持扩缩的控制器（如副本控制器、 -Deployments 和 ReplicaSet）。 +Deployment 和 ReplicaSet）。 `scale` 是一个可以动态设定副本数量和检查当前状态的接口。 关于 scale 子资源的更多信息，请参考[这里](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#scale-subresource). @@ -182,7 +182,7 @@ metric across all Pods in the HorizontalPodAutoscaler's scale target. Before checking the tolerance and deciding on the final values, we take pod readiness and missing metrics into consideration, however. --> -如果 HorizontalPodAutoscaler 指定的是`targetAverageValue` 或 `targetAverageUtilization`， +如果 HorizontalPodAutoscaler 指定的是 `targetAverageValue` 或 `targetAverageUtilization`， 那么将会把指定 Pod 度量值的平均值做为 `currentMetricValue`。 然而，在检查容忍度和决定最终扩缩值前，我们仍然会把那些无法获取指标的 Pod 统计进去。 @@ -193,7 +193,7 @@ shut down) and all failed Pods are discarded. If a particular Pod is missing metrics, it is set aside for later; Pods with missing metrics will be used to adjust the final scaling amount. --> -所有被标记了删除时间戳（Pod 正在关闭过程中）的 Pod 和 失败的 Pod 都会被忽略。 +所有被标记了删除时间戳（Pod 正在关闭过程中）的 Pod 和失败的 Pod 都会被忽略。 如果某个 Pod 缺失度量值，它将会被搁置，只在最终确定扩缩数量时再考虑。 @@ -229,7 +229,7 @@ default is 5 minutes. The `currentMetricValue / desiredMetricValue` base scale ratio is then calculated using the remaining pods not set aside or discarded from above. --> -在排除掉被搁置的 Pod 后，扩缩比例就会根据`currentMetricValue/desiredMetricValue` +在排除掉被搁置的 Pod 后，扩缩比例就会根据 `currentMetricValue/desiredMetricValue` 计算出来。 如果创建 HorizontalPodAutoscaler 时指定了多个指标， -那么会按照每个指标分别计算扩缩副本数，取最大的进行扩缩。 -如果任何一个指标无法顺利的计算出扩缩副本数（比如，通过 API 获取指标时出错）， -那么本次扩缩会被跳过。 +那么会按照每个指标分别计算扩缩副本数，取最大值进行扩缩。 +如果任何一个指标无法顺利地计算出扩缩副本数（比如，通过 API 获取指标时出错）， +并且可获取的指标建议缩容，那么本次扩缩会被跳过。 +这表示，如果一个或多个指标给出的 `desiredReplicas` 值大于当前值，HPA 仍然能实现扩容。 @@ -321,13 +324,13 @@ API 的 beta 版本（`autoscaling/v2beta2`）引入了基于内存和自定义 创建 HorizontalPodAutoscaler 对象时，需要确保所给的名称是一个合法的 [DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 -有关 API 对象的更多信息，请查阅[HorizontalPodAutoscaler 对象设计文档](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#horizontalpodautoscaler-object)。 +有关 API 对象的更多信息，请查阅 +[HorizontalPodAutoscaler 对象设计文档](/zh/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#horizontalpodautoscaler-v1-autoscaling)。 -## 滚动升级时扩缩 {#autoscaling-during-roling-update} +## 滚动升级时扩缩 {#autoscaling-during-rolling-update} 目前在 Kubernetes 中，可以针对 ReplicationController 或 Deployment 执行 滚动更新，它们会为你管理底层副本数。 @@ -375,13 +377,12 @@ HPA 设置副本数量时，Deployment 会设置底层副本数。 通过直接操控副本控制器执行滚动升级时，HPA 不能工作， -也就是说你不能将 HPA 绑定到某个 RC 再执行滚动升级 -（例如使用 `kubectl rolling-update` 命令）。 +也就是说你不能将 HPA 绑定到某个 RC 再执行滚动升级。 HPA 不能工作的原因是它无法绑定到滚动更新时所新创建的副本控制器。 * 启用了 [API 聚合层](/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer/) + * 相应的 API 已注册： * 对于资源指标，将使用 `metrics.k8s.io` API，一般由 [metrics-server](https://github.com/kubernetes-incubator/metrics-server) 提供。 它可以做为集群插件启动。 - * 对于自定义指标，将使用 `custom.metrics.k8s.io` API。 + + * 对于自定义指标，将使用 `custom.metrics.k8s.io` API。 它由其他度量指标方案厂商的“适配器（Adapter）” API 服务器提供。 确认你的指标流水线，或者查看[已知方案列表](https://github.com/kubernetes/metrics/blob/master/IMPLEMENTATIONS.md#custom-metrics-api)。 + 如果你想自己编写，请从 [boilerplate](https://github.com/kubernetes-sigs/custommetrics-apiserver)开始。 + * 对于外部指标，将使用 `external.metrics.k8s.io` API。可能由上面的自定义指标适配器提供。 + * `--horizontal-pod-autoscaler-use-rest-clients` 参数设置为 `true` 或者不设置。 如果设置为 false，则会切换到基于 Heapster 的自动扩缩，这个特性已经被弃用了。 @@ -533,6 +544,236 @@ and [the walkthrough for using external metrics](/docs/tasks/run-application/hor [使用自定义指标的教程](/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-multiple-metrics-and-custom-metrics) 和[使用外部指标的教程](/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-metrics-not-related-to-kubernetes-objects)。 + +## 支持可配置的扩缩 {#support-for-configurable-scaling-behaviour} + +从 [v1.18](https://github.com/kubernetes/enhancements/blob/master/keps/sig-autoscaling/20190307-configurable-scale-velocity-for-hpa.md) +开始，`v2beta2` API 允许通过 HPA 的 `behavior` 字段配置扩缩行为。 +在 `behavior` 字段中的 `scaleUp` 和 `scaleDown` 分别指定扩容和缩容行为。 +可以两个方向指定一个稳定窗口，以防止扩缩目标中副本数量的波动。 +类似地，指定扩缩策略可以控制扩缩时副本数的变化率。 + + +### 扩缩策略 {#scaling-policies} +在 spec 字段的 `behavior` 部分可以指定一个或多个扩缩策略。 +当指定多个策略时，默认选择允许更改最多的策略。 +下面的例子展示了缩容时的行为: + +```yaml +behavior: + scaleDown: + policies: + - type: Pods + value: 4 + periodSeconds: 60 + - type: Percent + value: 10 + periodSeconds: 60 +``` + + +当 Pod 数量超过 40 个时，第二个策略将用于缩容。 +例如，如果有 80 个副本，并且目标必须缩小到 10 个副本，那么在第一步中将减少 8 个副本。 +在下一轮迭代中，当副本的数量为 72 时，10% 的 Pod 数为 7.2，但是这个数字向上取整为 8。 +在 autoscaler 控制器的每个循环中，将根据当前副本的数量重新计算要更改的 Pod 数量。 +当副本数量低于 40 时，应用第一个策略 _（Pods）_ ，一次减少 4 个副本。 + + +`periodSeconds` 表示策略的时间长度必须保证有效。 +第一个策略允许在一分钟内最多缩小 4 个副本。 +第二个策略最多允许在一分钟内缩小当前副本的 10%。 + + +可以指定扩缩方向的 `selectPolicy` 字段来更改策略选择。 +通过设置 `Min` 的值，它将选择副本数变化最小的策略。 +将该值设置为 `Disabled` 将完全禁用该方向的缩放。 + + +### 稳定窗口 {#stabilization-window} + +当用于扩缩的指标持续抖动时，使用稳定窗口来限制副本数上下振动。 +自动扩缩算法使用稳定窗口来考虑过去计算的期望状态，以防止扩缩。 +在下面的例子中，稳定化窗口被指定为 `scaleDown`。 + +```yaml +scaleDown: + stabilizationWindowSeconds: 300 +``` + + +当指标显示目标应该缩容时，自动扩缩算法查看之前计算的期望状态，并使用指定时间间隔内的最大值。 +在上面的例子中，过去 5 分钟的所有期望状态都会被考虑。 + + +### 默认行为 {#default-behavior} + +要使用自定义扩缩，不必指定所有字段。 +只有需要自定义的字段才需要指定。 +这些自定义值与默认值合并。 +默认值与 HPA 算法中的现有行为匹配。 + +```yaml +behavior: + scaleDown: + stabilizationWindowSeconds: 300 + policies: + - type: Percent + value: 100 + periodSeconds: 15 + scaleUp: + stabilizationWindowSeconds: 0 + policies: + - type: Percent + value: 100 + periodSeconds: 15 + - type: Pods + value: 4 + periodSeconds: 15 + selectPolicy: Max +``` + + +用于缩小稳定窗口的时间为 _300_ 秒(或是 `--horizontal-pod-autoscaler-downscale-stabilization` 参数设定值)。 +只有一种缩容的策略，允许 100% 删除当前运行的副本，这意味着扩缩目标可以缩小到允许的最小副本数。 +对于扩容，没有稳定窗口。当指标显示目标应该扩容时，目标会立即扩容。 +这里有两种策略，每 15 秒添加 4 个 Pod 或 100% 当前运行的副本数，直到 HPA 达到稳定状态。 + + +### 示例：更改缩容稳定窗口 + +将下面的 behavior 配置添加到 HPA 中，可提供一个 1 分钟的自定义缩容稳定窗口： + +```yaml +behavior: + scaleDown: + stabilizationWindowSeconds: 60 +``` + + +### 示例：限制缩容速率 + +将下面的 behavior 配置添加到 HPA 中，可限制 Pod 被 HPA 删除速率为每分钟 10%： + +```yaml +behavior: + scaleDown: + policies: + - type: Percent + value: 10 + periodSeconds: 60 +``` + + +为了确保每分钟删除的 Pod 数不超过 5 个，可以添加第二个缩容策略，大小固定为 5，并将 `selectPolicy` 设置为最小值。 +将 `selectPolicy` 设置为 `Min` 意味着 autoscaler 会选择影响 Pod 数量最小的策略: + +```yaml +behavior: + scaleDown: + policies: + - type: Percent + value: 10 + periodSeconds: 60 + - type: Pods + value: 5 + periodSeconds: 60 + selectPolicy: Min +``` + + + +### 示例：禁用缩容 + +`selectPolicy` 的值 `Disabled` 会关闭对给定方向的缩容。 +因此使用以下策略，将会阻止缩容： + +```yaml +behavior: + scaleDown: + selectPolicy: Disabled +``` + + + ## {{% heading "whatsnext" %}} + + +本页面服务于两个目的： + +- 展示 Kubernetes 中文版文档中应如何使用 Markdown +- 提供一个测试用文档，用来测试可能影响所有文档的 HTML、CSS 和模板变更 + + +## 标题级别 + +上面的标题是 H2 级别。页面标题（Title）会渲染为 H1。以下各节分别展示 H3-H6 +的渲染结果。 + +### H3 + +此处为 H3 节内容。 + +#### H4 + +此处为 H4 节内容。 + +##### H5 + +此处为 H5 节内容。 + +###### H6 + +此处为 H6 节内容。 + + +## 内联元素（Inline elements） + +内联元素显示在段落文字、列表条目、提醒信息或者块级别元素之内。 + +Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor +incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis +nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. +Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu +fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in +culpa qui officia deserunt mollit anim id est laborum. + +### 内联文本风格 + + +- **粗体字** +- _斜体字_ +- ***粗斜体字*** +- ~~删除线~~ +- 下划线 +- _带下划线的斜体_ +- ***带下划线的粗斜体*** +- `monospace text` <- 等宽字体 +- **`monospace bold`** <- 粗等宽字体 + +## 列表 + + +Markdown 在如何处理列表方面没有严格的规则。在我们从 Jekyll 迁移到 Hugo 时， +我们遇到了一些问题。为了处理这些问题，请注意以下几点： + +- 确保你将子列表的条目缩进**四个空格**而不是你可能熟悉的两个空格。 + 有一点是不那么直观的，你需要将列表中的块级别内容多缩进四个空格。 + +- 要结束一个列表并开始一个新的列表，你需要在两个列表之间添加加一个 HTML 注释块， + 并将其置于独立的一行，左边顶边对齐。否则前一个列表不会结束，无论你在它与 + 第二个列表之间放多少个空行。 + + +### 项目符号列表 + +- 此为列表条目 +* 此为另一列表条目，位于同一列表中 +- 你可以将 `-` 和 `*` 混合使用 + - 要开始子列表，缩进两个 TAB （四个空格）。**Jekyll 和 Markdown + 在这点上有所不同**。 + - 这是另一个子子条目。进一步多缩进两个空格。 + - 另一个子条目 + + + + +- 这是一个新的列表。使用 Hugo 时，你需要用一行 HTML 注释将两个紧挨着的列表分开。 + **这里的 HTML 注释需要按左侧顶边对齐。** +- 项目符号列表可以中包含文字段落或块元素。 + + 段落内容与第一行文字左侧对齐。 + **此段文字和下面的代码段都与前一行中的“项”字对齐。** + + ```bash + ls -l + ``` + + - 在块级内容之后还可以有子列表内容。 + + +- 项目符号列表条目中还可以包含编号列表。 + 1. 编号子列表条目一 + 1. 编号子列表条目二 + +- 项目符号列表条目中包含编号列表的另一种形式（推荐形式）。让子列表的编号数字 + 与项目符号列表文字左对齐。 + + 1. 编号子列表条目一，左侧编号与前一行的“项”字左对齐。 + 1. 编号子列表条目二，条目文字与数字之间多了一个空格。 + + +### 编号列表 + +1. 此为列表条目 +1. 此为列表中的第二个条目。在 Markdown 源码中所给的编号数字与最终输出的数字 + 可能不同。建议在紧凑列表中编号都使用 1。如果条目之间有其他内容（比如注释 + 掉的英文）存在，则需要显式给出编号。 +2. {{}} + 对于单个数字的编号列表，在句点（`.`）后面加两个空格。这样有助于将列表的 + 内容更好地对齐。 + {{}} + + + + + +1. 这是一个新的列表。 使用 Hugo 时，你需要用 HTML 注释将两个紧挨着的列表分开。 + **HTML 注释需要按左边顶边对齐。** +2. 编号列表条目中也可以包含额外的段落或者块元素。 + + 后续段落应该按编号列表文字的第一行左侧对齐。 + **此段落及下面的代码段都与本条目中的第一个字“编”对齐。** + + ```bash + ls -l + ``` + + - 编号列表条目中可以在块级内容之后有子列表。子列表的符号项要与上层列表条目 + 文字左侧对齐。 + +### 中文译文的编号列表格式 1 + + +1. 译文条目一 + + +2. 译文条目二，由于前述原因，条目 2 与 1 之间存在注释行，如果此条目不显式给出 + 起始编号，会被 Hugo 当做两个独立的列表。 + +### 中文译文的编号列表格式 2 + + +1. 译文条目一 + + + 中文译文段落。 + + + 带注释的代码段（**注意以上英文注释 `` 的缩进空格数**）。 + + ```shell + # 列举服务 + kubectl get svc + ``` + + +2. 译文条目二，由于前述原因，条目 2 与 1 之间存在注释行，如果此条目不显式给出 + 起始编号，会被 Hugo 当做两个独立的列表。 + + +### 标签列表 + +标签列表可以用来有条件地显式内容，例如，当有多种选项可供选择时，每个选项 +可能需要完全不同的指令或者上下文。 + + +{{< tabs name="tab_lists_example" >}} +{{% tab name="请选择..." %}} +请选择一个选项。 +{{% /tab %}} + + +{{% tab name="在标签页中格式化列表" %}} + + +标签页中也可以包含嵌套的排版风格，其中的英文注释处理也同正文中 +的处理基本一致。 + +1. 编号列表 +1. （或者没有编号的） +1. 列表 + +```bash +echo '标签页里面也可以有代码段!' +``` + +{{% /tab %}} + +{{% tab name="嵌套的子标题" %}} + + +### 在标签页中的子标题 + +标签页中也可以包含嵌套的子标题。 + + +{{< warning >}} +标签页中的子标题不会在目录中出现。 +{{< /warning >}} + +{{% /tab %}} +{{< /tabs >}} + + +### 检查项列表 （Checklists） + +检查项列表本质上也是一种项目符号列表，只是这里的项目符号部分被 CSS 压制了。 + +- [ ] 此为第一个检查项 +- [x] 此为被选中的检查项 + + +## 代码段 + +你可以用两种方式来创建代码块。一种方式是将在代码块之前和之后分别加上包含三个 +反引号的独立行。**反引号应该仅用于代码段。** +用这种方式标记代码段时，你还可以指定所包含的代码的编程语言，从而启用语法加亮。 +这种方式也比使用空格缩进的方式可预测性更好。 + + +``` +这是用反引号创建的代码段 +``` + + +反引号标记代码段的方式有以下优点： + +- 这种方式几乎总是能正确工作 +- 在查看源代码时，内容相对紧凑 +- 允许你指定代码块的编程语言，以便启用语法加亮 +- 代码段的结束位置有明确标记。有时候，采用缩进空格的方式会使得一些对空格 + 很敏感的语言（如 Python、YAML）很难处理。 + + +要为代码段指定编程语言，可以在第一组反引号之后加上编程语言名称： + +```bash +ls -l +``` + + +Kubernetes 文档中代码块常用语言包括： + +- `bash` / `shell` （二者几乎完全相同） +- `go` +- `json` +- `yaml` +- `xml` +- `none` （禁止对代码块执行语法加亮） + + +### 包含 Hugo 短代码的代码块 + +如果要像上面的例子一样显示 Hugo 短代码（Shortcode），不希望 Hugo 将其当做短代码来处理， +可以在 `<` 和 `>` 之间使用 C 语言风格的注释。 +下面的示例展示如何实现这点（查看本页的 Markdown 源码）： + +```none +{{}} +``` + + +## 链接 + +要格式化链接，将链接显示文本放在方括号中，后接用圆括号括起来的链接目标。 +[指向 Kubernetes.io 的连接](https://kubernetes.io/) 或 +[到 Kubernetes.io 的相对链接](/)。 + +你也可以使用 HTML，但这种方式不是推荐的方式。 +到 Kubernetes.io 的链接。 + +### 中文链接 + +中文版本文档中的链接要注意以下两点： + +- 指向 Kubernetes 文档的站内链接，需要在英文链接之前添加前缀 `/zh`。 + 例如，原链接目标为 `/docs/foo/bar` 时，译文中的链接目标应为 + `/zh/docs/foo/bar`。例如： + + - 英文版本链接 [Kubernetes Components](/docs/concepts/overview/components/) + - 对应中文链接 [Kubernetes 组件](/zh/docs/concepts/overview/components/) + +- 英文页面子标题会生成对应锚点（Anchor），例如子标题 `## Using object` 会生成 + 对应标签 `#using-objects`。在翻译为中文之后，对应锚点可能会失效。对此，有 + 两种方法处理。假定译文中存在以下子标题： + + ``` + + ## 清理现场 + + 你可以这样 ... + ``` + + 并且在本页或其他页面有指向 `#clean-up` 的链接如下： + + ``` + ..., please refer to the [clean up](#clean-up) section. + ``` + + 第一种处理方法是将链接改为中文锚点，即将引用该子标题的文字全部改为中文锚点。 + 例如： + + ``` + ..., 请参考[清理工作](#清理现场)一节。 + ``` + + 第二种方式（也是推荐的方式）是将原来可能生成的锚点（尽管在英文原文中未明确 + 给出）显式标记在译文的子标题上。 + + ``` + + ## 清理现场 {#clean-up} + + 你可以这样 ... + ``` + + 之所以优选第二种方式是因为可以避免文档站点中其他引用此子标题的链接失效。 + + +## 图片 + +要显示图片，可以使用与链接类似的语法（`[links](#links)`），不过要在整个链接 +之前添加一个感叹号（`!`）。方括号中给出的是图片的替代文本。 +请坚持为图片设定替代文本，这样使用屏幕阅读器的人也能够了解图片中包含的是什么。 + +![pencil icon](/images/pencil.png) + + +要设置扩展的属性，例如 width、title、caption 等等，可以使用 +figure +短代码，而不是使用 HTML 的 `` 标签。 +此外，如果你需要让图片本身变成超链接，可以使用短代码的 `link` 属性，而不是 +将整个图片放到 Markdown 的链接语法之内。下面是一个例子： + + +{{< figure src="/images/pencil.png" title="铅笔图标" caption="用来展示 figure 短代码的图片" width="200px" >}} + + +即使你不想使用 figure 短代码，图片也可以展示为链接。这里，铅笔图标指向 +Kubernetes 网站。外层的方括号将整个 image 标签封装起来，链接目标在 +末尾的圆括号之间给出。 + +[![pencil icon](/images/pencil.png)](https://kubernetes.io) + +你也可以使用 HTML 来嵌入图片，不过这种方式是不推荐的。 + +铅笔图标 + + +## 表格 + +简单的表格可能每行只有一个独立的数据行，各个列之间用 `|` 隔开。 +表格的标题行与表格内容之间用独立的一行隔开，在这一行中每个单元格的内容 +只有 `-` 字符，且至少三个。出于方便维护考虑，请尝试将各个单元格间的 +分割线对齐，尽管这样意味着你需要多输入几个空格。 + + +| 标题单元格 1 | 标题单元格 2 | +|----------------|----------------| +| 内容单元格 1 | 内容单元格 2 | + + + +标题行是可选的。所有用 `|` 隔开的内容都会被渲染成表格。 + + +Markdown 表格在处理块级元素方面还很笨拙。例如在单元格中嵌入列表条目、代码段、 +或者在其中划分多个段落方面的能力都比较差。对于复杂的或者很宽的表格，可以使用 +HTML。 + + + + + + + + + + + + + + + + + + +
标题单元格 1标题单元格 2
内容单元格 1内容单元格 2
+ + +## 使用 Mermaid 来可视化 + +你可以使用 [Mermaid JS](https://mermaidjs.github.io) 来进行可视化展示。 +Mermaid JS 版本在 [/layouts/partials/head.html](https://github.com/kubernetes/website/blob/master/layouts/partials/head.html) +中设置。 + + + +``` +{{}} +graph TD; + 甲-->乙; + 甲-->丙; + 乙-->丁; + 丙-->丁; +{{}} +``` + + +会产生： + + + +{{< mermaid >}} +graph TD; + 甲-->乙; + 甲-->丙; + 乙-->丁; + 丙-->丁; +{{}} + + + + +``` +{{}} +sequenceDiagram + 张三 ->> 李四: 李四，锄禾日当午？ + 李四-->>王五: 王五，锄禾日当午？ + 李四--x 张三: 汗滴禾下土！ + 李四-x 王五: 汗滴禾下土！ + Note right of 王五: 李四想啊想啊
一直想啊想，太阳
都下山了，他还没想出来
，文本框都放不下了。 + + 李四-->张三: 跑去问王五... + 张三->王五: 好吧... 王五，白日依山尽？ +{{}} +``` + + +产生： + + + +{{< mermaid >}} +sequenceDiagram + 张三 ->> 李四: 李四，锄禾日当午？ + 李四-->>王五: 王五，锄禾日当午？ + 李四--x 张三: 汗滴禾下土！ + 李四-x 王五: 汗滴禾下土！ + Note right of 王五: 李四想啊想啊一直想，
想到太阳都下山了，
他还没想出来，
文本框都放不下了。 + + 李四-->张三: 跑去问王五... + 张三->王五: 好吧... 王五，白日依山尽？ +{{}} + + +
在官方网站上有更多的[示例](https://mermaid-js.github.io/mermaid/#/examples)。 + + +## 侧边栏和提醒框 + +侧边栏和提醒框可以为文本提供直观的重要性强调效果，可以偶尔一用。 + + +### 侧边栏（Sidebar） + +侧边栏可以将文字横向平移，只是其显示效果可能不像[提醒](#admonitions)那么明显。 + + + +> 此为侧边栏。 +> +> 你可以在侧边栏内排版段落和块级元素。 +> +> 你甚至可以在其中包含代码块。 +> +> ```bash +> sudo dmesg +> ``` + +### 提醒框 {#admonitions} + +提醒框（说明、警告等等）都是用 Hugo 短代码的形式展现。 + + +{{< note >}} +说明信息用来引起读者的注意，但不过分强调其紧迫性。 + +你可以在提醒框内包含多个段落和块级元素。 + +| 甚至 | 包含 | 表格 | +{{< /note >}} + + +{{< caution >}} +读者继续此操作时要格外小心。 +{{< /caution >}} + + +{{< warning >}} +警告信息试图为读者指出一些不应忽略的、可能引发问题的事情。 +{{< /warning >}} + +注意，在较老的 Hugo 版本中，直接将 `note`、`warning` 或 `caution` 短代码 +括入 HTML 注释当中是有问题的。这些短代码仍然会起作用。目前，在 0.70.0 +以上版本中似乎已经修复了这一问题。 + + +## 包含其他页面 + +要包含其他页面，可使用短代码。 + +{{< note >}} +{{< include "task-tutorial-prereqs.md" >}} +{{< /note >}} + + +## 嵌入的 Katacoda 环境 + +{{< kat-button >}} + diff --git a/content/zh/docs/tutorials/configuration/configure-java-microservice/_index.md b/content/zh/docs/tutorials/configuration/configure-java-microservice/_index.md new file mode 100755 index 0000000000..b94fbbb97f --- /dev/null +++ b/content/zh/docs/tutorials/configuration/configure-java-microservice/_index.md @@ -0,0 +1,10 @@ +--- +title: "示例：配置 java 微服务" +weight: 10 +--- + \ No newline at end of file diff --git a/content/zh/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice-interactive.html b/content/zh/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice-interactive.html new file mode 100644 index 0000000000..f453fc75cb --- /dev/null +++ b/content/zh/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice-interactive.html @@ -0,0 +1,37 @@ +--- +title: "互动教程 - 配置 java 微服务" +weight: 20 +--- + + + + + + + + + + + + +
+ +
+
+
+ + 如需要与终端交互，请使用台式机/平板电脑版 +
+
+
+
+ +
+ + + diff --git a/content/zh/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice.md b/content/zh/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice.md new file mode 100644 index 0000000000..b6357ed284 --- /dev/null +++ b/content/zh/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice.md @@ -0,0 +1,93 @@ +--- +title: "使用 MicroProfile、ConfigMaps、Secrets 实现外部化应用配置" +content_type: tutorial +weight: 10 +--- + + + + + +在本教程中，你会学到如何以及为什么要实现外部化微服务应用配置。 +具体来说，你将学习如何使用 Kubernetes ConfigMaps 和 Secrets 设置环境变量， +然后在 MicroProfile config 中使用它们。 + +## {{% heading "prerequisites" %}} + + +### 创建 Kubernetes ConfigMaps 和 Secrets {#creating-kubernetes-configmaps-secrets} +在 Kubernetes 中，为 docker 容器设置环境变量有几种不同的方式，比如： +Dockerfile、kubernetes.yml、Kubernetes ConfigMaps、和 Kubernetes Secrets。 +在本教程中，你将学到怎么用后两个方式去设置你的环境变量，而环境变量的值将注入到你的微服务里。 +使用 ConfigMaps 和 Secrets 的一个好处是他们能在多个容器间复用， +比如赋值给不同的容器中的不同环境变量。 + + +ConfigMaps 是存储非机密键值对的 API 对象。 +在互动教程中，你会学到如何用 ConfigMap 来保存应用名字。 +ConfigMap 的更多信息，你可以在[这里](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/)找到文档。 + +Secrets 尽管也用来存储键值对，但区别于 ConfigMaps 的是：它针对机密/敏感数据，且存储格式为 Base64 编码。 +secrets 的这种特性使得它适合于存储证书、密钥、令牌，上述内容你将在交互教程中实现。 +Secrets 的更多信息，你可以在[这里](/zh/docs/concepts/configuration/secret/)找到文档。 + + + +### 从代码外部化配置 +外部化应用配置之所以有用处，是因为配置常常根据环境的不同而变化。 +为了实现此功能，我们用到了 Java 上下文和依赖注入（Contexts and Dependency Injection, CDI）、MicroProfile 配置。 +MicroProfile config 是 MicroProfile 的功能特性， +是一组开放 Java 技术，用于开发、部署云原生微服务。 + + +CDI 提供一套标准的依赖注入能力，使得应用程序可以由相互协作的、松耦合的 beans 组装而成。 +MicroProfile Config 为 app 和微服务提供从各种来源，比如应用、运行时、环境，获取配置参数的标准方法。 +基于来源定义的优先级，属性可以自动的合并到单独一组应用可以通过 API 访问到的属性。 +CDI & MicroProfile 都会被用在互动教程中， +用来从 Kubernetes ConfigMaps 和 Secrets 获得外部提供的属性，并注入应用程序代码中。 + +很多开源框架、运行时支持 MicroProfile Config。 +对于整个互动教程，你都可以使用开放的库、灵活的开源 Java 运行时，去构建并运行云原生的 apps 和微服务。 +然而，任何 MicroProfile 兼容的运行时都可以用来做替代品。 + + +## {{% heading "objectives" %}} + + +* 创建 Kubernetes ConfigMap 和 Secret +* 使用 MicroProfile Config 注入微服务配置 + + + + + +## 示例：使用 MicroProfile、ConfigMaps、Secrets 实现外部化应用配置 +### [启动互动教程](/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice-interactive/) diff --git a/content/zh/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html b/content/zh/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html index d846c9b40d..550ccb488d 100644 --- a/content/zh/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html +++ b/content/zh/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html @@ -91,7 +91,7 @@ weight: 10
-

您可以使用 Kubernetes 命令行界面创建和管理 Deployment，Kubectl.Kubectl 使用 Kubernetes API 与集群进行交互。在本单元中，您将学习创建在 Kubernetes 集群上运行应用程序的 Deployment 所需的最常见的 Kubectl 命令。

+

您可以使用 Kubernetes 命令行界面 Kubectl 创建和管理 Deployment。Kubectl 使用 Kubernetes API 与集群进行交互。在本单元中，您将学习创建在 Kubernetes 集群上运行应用程序的 Deployment 所需的最常见的 Kubectl 命令。

创建 Deployment 时，您需要指定应用程序的容器映像以及要运行的副本数。您可以稍后通过更新 Deployment 来更改该信息; 模块 5 和 6 讨论了如何扩展和更新 Deployments。

@@ -133,4 +133,4 @@ weight: 10
- \ No newline at end of file + diff --git a/content/zh/docs/tutorials/kubernetes-basics/explore/explore-intro.html b/content/zh/docs/tutorials/kubernetes-basics/explore/explore-intro.html index 080e38fb82..d07d155926 100644 --- a/content/zh/docs/tutorials/kubernetes-basics/explore/explore-intro.html +++ b/content/zh/docs/tutorials/kubernetes-basics/explore/explore-intro.html @@ -43,7 +43,7 @@ weight: 10 -

在模块 2创建 Deployment 时, Kubernetes 添加了一个 Pod 来托管你的应用实例。Pod 是 Kubernetes 抽象出来的，表示一组一个或多个应用程序容器（如 Docker），以及这些容器的一些共享资源。这些资源包括:

+

在模块 2创建 Deployment 时, Kubernetes 添加了一个 Pod 来托管你的应用实例。Pod 是 Kubernetes 抽象出来的，表示一组一个或多个应用程序容器（如 Docker），以及这些容器的一些共享资源。这些资源包括:

-

在模块 2,您使用了 Kubectl 命令行界面。 您将继续在第3单元中使用它来获取有关已部署的应用程序及其环境的信息。 最常见的操作可以使用以下 kubectl 命令完成：

+

在模块 2,您使用了 Kubectl 命令行界面。 您将继续在第3单元中使用它来获取有关已部署的应用程序及其环境的信息。 最常见的操作可以使用以下 kubectl 命令完成：

-

Kubernetes Pod 是转瞬即逝的。 Pod 实际上拥有 生命周期。 当一个工作 Node 挂掉后, 在 Node 上运行的 Pod 也会消亡。 ReplicaSet 会自动地通过创建新的 Pod 驱动集群回到目标状态，以保证应用程序正常运行。 换一个例子，考虑一个具有3个副本数的用作图像处理的后端程序。这些副本是可替换的; 前端系统不应该关心后端副本，即使 Pod 丢失或重新创建。也就是说，Kubernetes 集群中的每个 Pod (即使是在同一个 Node 上的 Pod )都有一个惟一的 IP 地址，因此需要一种方法自动协调 Pod 之间的变更，以便应用程序保持运行。

+

Kubernetes Pod 是转瞬即逝的。 Pod 实际上拥有 生命周期。 当一个工作 Node 挂掉后, 在 Node 上运行的 Pod 也会消亡。 ReplicaSet 会自动地通过创建新的 Pod 驱动集群回到目标状态，以保证应用程序正常运行。 换一个例子，考虑一个具有3个副本数的用作图像处理的后端程序。这些副本是可替换的; 前端系统不应该关心后端副本，即使 Pod 丢失或重新创建。也就是说，Kubernetes 集群中的每个 Pod (即使是在同一个 Node 上的 Pod )都有一个惟一的 IP 地址，因此需要一种方法自动协调 Pod 之间的变更，以便应用程序保持运行。

Kubernetes 中的服务(Service)是一种抽象概念，它定义了 Pod 的逻辑集和访问 Pod 的协议。Service 使从属 Pod 之间的松耦合成为可能。 和其他 Kubernetes 对象一样, Service 用 YAML (更推荐) 或者 JSON 来定义. Service 下的一组 Pod 通常由 LabelSelector (请参阅下面的说明为什么您可能想要一个 spec 中不包含selector的服务)来标记。

diff --git a/content/zh/docs/tutorials/kubernetes-basics/scale/scale-intro.html b/content/zh/docs/tutorials/kubernetes-basics/scale/scale-intro.html index 73151bdcb8..ff6094eada 100644 --- a/content/zh/docs/tutorials/kubernetes-basics/scale/scale-intro.html +++ b/content/zh/docs/tutorials/kubernetes-basics/scale/scale-intro.html @@ -33,7 +33,7 @@ weight: 10 -

在之前的模块中，我们创建了一个 Deployment，然后通过 Service让其可以开放访问。Deployment 仅为跑这个应用程序创建了一个 Pod。 当流量增加时，我们需要扩容应用程序满足用户需求。

+

在之前的模块中，我们创建了一个 Deployment，然后通过 Service让其可以开放访问。Deployment 仅为跑这个应用程序创建了一个 Pod。 当流量增加时，我们需要扩容应用程序满足用户需求。

扩缩 是通过改变 Deployment 中的副本数量来实现的。

@@ -99,7 +99,7 @@ weight: 10 -

扩展 Deployment 将创建新的 Pods，并将资源调度请求分配到有可用资源的节点上，收缩 会将 Pods 数量减少至所需的状态。Kubernetes 还支持 Pods 的自动缩放，但这并不在本教程的讨论范围内。将 Pods 数量收缩到0也是可以的，但这会终止 Deployment 上所有已经部署的 Pods。

+

扩展 Deployment 将创建新的 Pods，并将资源调度请求分配到有可用资源的节点上，收缩 会将 Pods 数量减少至所需的状态。Kubernetes 还支持 Pods 的自动缩放，但这并不在本教程的讨论范围内。将 Pods 数量收缩到0也是可以的，但这会终止 Deployment 上所有已经部署的 Pods。

diff --git a/content/zh/docs/tutorials/stateful-application/zookeeper.md b/content/zh/docs/tutorials/stateful-application/zookeeper.md index 25218ecd84..4d95d69a52 100644 --- a/content/zh/docs/tutorials/stateful-application/zookeeper.md +++ b/content/zh/docs/tutorials/stateful-application/zookeeper.md @@ -14,96 +14,159 @@ content_type: tutorial -本教程展示了在 Kubernetes 上使用 [PodDisruptionBudgets](/zh/docs/admin/disruptions/#specifying-a-poddisruptionbudget) 和 [PodAntiAffinity](/zh/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-beta-feature) 特性运行 [Apache Zookeeper](https://zookeeper.apache.org)。 + +本教程展示了在 Kubernetes 上使用 [StatefulSets](/zh/docs/concepts/workloads/controllers/statefulset/)，[PodDisruptionBudgets](/zh/docs/concepts/workloads/pods/disruptions/#pod-disruption-budget) 和 [PodAntiAffinity](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#亲和与反亲和) 特性运行 [Apache Zookeeper](https://zookeeper.apache.org)。 ## {{% heading "prerequisites" %}} + 在开始本教程前，你应该熟悉以下 Kubernetes 概念。 -* [Pods](/zh/docs/user-guide/pods/single-container/) -* [Cluster DNS](/zh/docs/concepts/services-networking/dns-pod-service/) -* [Headless Services](/zh/docs/concepts/services-networking/service/#headless-services) -* [PersistentVolumes](/zh/docs/concepts/storage/volumes/) -* [PersistentVolume Provisioning](http://releases.k8s.io/{{< param "githubbranch" >}}/examples/persistent-volume-provisioning/) -* [ConfigMaps](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/) -* [StatefulSets](/zh/docs/concepts/abstractions/controllers/statefulsets/) -* [PodDisruptionBudgets](/zh/docs/admin/disruptions/#specifying-a-poddisruptionbudget) -* [PodAntiAffinity](/zh/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-beta-feature) -* [kubectl CLI](/zh/docs/user-guide/kubectl) +- [Pods](/zh/docs/concepts/workloads/pods/) +- [Cluster DNS](/zh/docs/concepts/services-networking/dns-pod-service/) +- [Headless Services](/zh/docs/concepts/services-networking/service/#headless-services) +- [PersistentVolumes](/zh/docs/concepts/storage/volumes/) +- [PersistentVolume Provisioning](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/) +- [StatefulSets](/zh/docs/concepts/workloads/controllers/statefulset/) +- [PodDisruptionBudgets](/zh/docs/concepts/workloads/pods/disruptions/#pod-disruption-budget) +- [PodAntiAffinity](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#亲和与反亲和) +- [kubectl CLI](/zh/docs/reference/kubectl/kubectl/) + 你需要一个至少包含四个节点的集群，每个节点至少 2 CPUs 和 4 GiB 内存。在本教程中你将会 cordon 和 drain 集群的节点。**这意味着集群节点上所有的 Pods 将会被终止并移除**。**这些节点也会暂时变为不可调度**。在本教程中你应该使用一个独占的集群，或者保证你造成的干扰不会影响其它租户。 - 本教程假设你的集群配置为动态的提供 PersistentVolumes。如果你的集群没有配置成这样，在开始本教程前，你需要手动准备三个 20 GiB 的卷。 ## {{% heading "objectives" %}} + 在学习本教程后，你将熟悉下列内容。 * 如何使用 StatefulSet 部署一个 ZooKeeper ensemble。 -* 如何使用 ConfigMaps 一致性配置 ensemble。 -* 如何在 ensemble 中 分布 ZooKeeper 服务的部署。 +* 如何一致性配置 ensemble。 +* 如何在 ensemble 中 分布 ZooKeeper 服务器的部署。 * 如何在计划维护中使用 PodDisruptionBudgets 确保服务可用性。 + ### ZooKeeper 基础 +[Apache ZooKeeper](https://zookeeper.apache.org/doc/current/) 是一个分布式的开源协调服务，用于分布式系统。ZooKeeper 允许你读取、写入数据和发现数据更新。数据按层次结构组织在文件系统中，并复制到 ensemble（一个 ZooKeeper 服务器的集合） 中所有的 ZooKeeper 服务器。对数据的所有操作都是原子的和顺序一致的。ZooKeeper 通过 [Zab](https://pdfs.semanticscholar.org/b02c/6b00bd5dbdbd951fddb00b906c82fa80f0b3.pdf) 一致性协议在 ensemble 的所有服务器之间复制一个状态机来确保这个特性。 -[Apache ZooKeeper](https://zookeeper.apache.org/doc/current/) 是一个分布式的开源协调服务，用于分布式系统。ZooKeeper 允许你读取、写入数据和发现数据更新。数据按层次结构组织在文件系统中，并复制到 ensemble（一个 ZooKeeper 服务的集合） 中所有的 ZooKeeper 服务。对数据的所有操作都是原子的和顺序一致的。ZooKeeper 通过 [Zab](https://pdfs.semanticscholar.org/b02c/6b00bd5dbdbd951fddb00b906c82fa80f0b3.pdf) 一致性协议在 ensemble 的所有服务之间复制一个状态机来确保这个特性。 +ensemble 使用 Zab 协议选举一个 leader，在选举出 leader 前不能写入数据。一旦选举出了 leader，ensemble 使用 Zab 保证所有写入被复制到一个 quorum，然后这些写入操作才会被确认并对客户端可用。如果没有遵照加权 quorums，一个 quorum 表示包含当前 leader 的 ensemble 的多数成员。例如，如果 ensemble 有3个服务器，一个包含 leader 的成员和另一个服务器就组成了一个 quorum。如果 ensemble 不能达成一个 quorum，数据将不能被写入。 +ZooKeeper 在内存中保存它们的整个状态机，但是每个改变都被写入一个在存储介质上的持久 WAL（Write Ahead Log）。当一个服务器故障时，它能够通过回放 WAL 恢复之前的状态。为了防止 WAL 无限制的增长，ZooKeeper 服务器会定期的将内存状态快照保存到存储介质。这些快照能够直接加载到内存中，所有在这个快照之前的 WAL 条目都可以被安全的丢弃。 -ensemble 使用 Zab 协议选举一个 leader，在选举出 leader 前不能写入数据。一旦选举出了 leader，ensemble 使用 Zab 保证所有写入被复制到一个 quorum，然后这些写入操作才会被确认并对客户端可用。如果没有遵照加权 quorums，一个 quorum 表示包含当前 leader 的 ensemble 的多数成员。例如，如果 ensemble 有3个服务，一个包含 leader 的成员和另一个服务就组成了一个 quorum。如果 ensemble 不能达成一个 quorum，数据将不能被写入。 - - -ZooKeeper 在内存中保存它们的整个状态机，但是每个改变都被写入一个在存储介质上的持久 WAL（Write Ahead Log）。当一个服务故障时，它能够通过回放 WAL 恢复之前的状态。为了防止 WAL 无限制的增长，ZooKeeper 服务会定期的将内存状态快照保存到存储介质。这些快照能够直接加载到内存中，所有在这个快照之前的 WAL 条目都可以被安全的丢弃。 + ## 创建一个 ZooKeeper Ensemble - 下面的清单包含一个 [Headless Service](/zh/docs/concepts/services-networking/service/#headless-services)， 一个 [Service](/zh/docs/concepts/services-networking/service/)， -一个 [PodDisruptionBudget](/zh/docs/concepts/workloads/pods/disruptions//#specifying-a-poddisruptionbudget)， +一个 [PodDisruptionBudget](/zh/docs/concepts/workloads/pods/disruptions/#specifying-a-poddisruptionbudget)， 和一个 [StatefulSet](/zh/docs/concepts/workloads/controllers/statefulset/)。 {{< codenew file="application/zookeeper/zookeeper.yaml" >}} -打开一个命令行终端，使用 [`kubectl apply`](/zh/docs/reference/generated/kubectl/kubectl-commands/#apply) + + +打开一个命令行终端，使用 [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands/#apply) 创建这个清单。 ```shell kubectl apply -f https://k8s.io/examples/application/zookeeper/zookeeper.yaml ``` + + 这个操作创建了 `zk-hs` Headless Service、`zk-cs` Service、`zk-pdb` PodDisruptionBudget 和 `zk` StatefulSet。 -```shell +``` service/zk-hs created service/zk-cs created poddisruptionbudget.policy/zk-pdb created statefulset.apps/zk created ``` -使用 [`kubectl get`](/zh/docs/user-guide/kubectl/{{< param "version" >}}/#get) 查看 StatefulSet 控制器创建的 Pods。 + + +使用 [`kubectl get`](/docs/reference/generated/kubectl/kubectl-commands/#get) 查看 StatefulSet 控制器创建的 Pods。 ```shell kubectl get pods -w -l app=zk ``` + 一旦 `zk-2` Pod 变成 Running 和 Ready 状态，使用 `CRTL-C` 结束 kubectl。 -```shell +``` NAME READY STATUS RESTARTS AGE zk-0 0/1 Pending 0 0s zk-0 0/1 Pending 0 0s @@ -122,45 +185,66 @@ zk-2 0/1 Running 0 19s zk-2 1/1 Running 0 40s ``` + -StatefulSet 控制器创建了3个 Pods，每个 Pod 包含一个 [ZooKeeper 3.4.9](http://www-us.apache.org/dist/zookeeper/zookeeper-3.4.9/) 服务。 +StatefulSet 控制器创建了3个 Pods，每个 Pod 包含一个 [ZooKeeper](https://www-us.apache.org/dist/zookeeper/stable/) 服务器。 + ### 促成 Leader 选举 +由于在匿名网络中没有用于选举 leader 的终止算法，Zab 要求显式的进行成员关系配置，以执行 leader 选举。Ensemble 中的每个服务器都需要具有一个独一无二的标识符，所有的服务器均需要知道标识符的全集，并且每个标识符都需要和一个网络地址相关联。 -由于在匿名网络中没有用于选举 leader 的终止算法，Zab 要求显式的进行成员关系配置，以执行 leader 选举。Ensemble 中的每个服务都需要具有一个独一无二的标识符，所有的服务均需要知道标识符的全集，并且每个标志都需要和一个网络地址相关联。 - - -使用 [`kubectl exec`](/zh/docs/user-guide/kubectl/{{< param "version" >}}/#exec) 获取 `zk` StatefulSet 中 Pods 的主机名。 +使用 [`kubectl exec`](/docs/reference/generated/kubectl/kubectl-commands/#exec) 获取 `zk` StatefulSet 中 Pods 的主机名。 ```shell for i in 0 1 2; do kubectl exec zk-$i -- hostname; done ``` + StatefulSet 控制器基于每个 Pod 的序号索引为它们各自提供一个唯一的主机名。主机名采用 `-` 的形式。由于 `zk` StatefulSet 的 `replicas` 字段设置为3，这个 Set 的控制器将创建3个 Pods，主机名为：`zk-0`、`zk-1` 和 `zk-2`。 -```shell +``` zk-0 zk-1 zk-2 ``` + +ZooKeeper ensemble 中的服务器使用自然数作为唯一标识符，每个服务器的标识符都保存在服务器的数据目录中一个名为 `myid` 的文件里。 -检查每个服务的 `myid` 文件的内容。 +检查每个服务器的 `myid` 文件的内容。 ```shell for i in 0 1 2; do echo "myid zk-$i";kubectl exec zk-$i -- cat /var/lib/zookeeper/data/myid; done ``` + 由于标识符为自然数并且序号索引是非负整数，你可以在序号上加 1 来生成一个标识符。 -```shell +``` myid zk-0 1 myid zk-1 @@ -169,6 +253,9 @@ myid zk-2 3 ``` + 获取 `zk` StatefulSet 中每个 Pod 的 FQDN (Fully Qualified Domain Name，正式域名)。 @@ -176,29 +263,43 @@ myid zk-2 for i in 0 1 2; do kubectl exec zk-$i -- hostname -f; done ``` + -`zk-headless` Service 为所有 Pods 创建了一个 domain：`zk-headless.default.svc.cluster.local`。 +`zk-hs` Service 为所有 Pods 创建了一个 domain：`zk-hs.default.svc.cluster.local`。 -```shell -zk-0.zk-headless.default.svc.cluster.local -zk-1.zk-headless.default.svc.cluster.local -zk-2.zk-headless.default.svc.cluster.local +``` +zk-0.zk-hs.default.svc.cluster.local +zk-1.zk-hs.default.svc.cluster.local +zk-2.zk-hs.default.svc.cluster.local ``` + [Kubernetes DNS](/zh/docs/concepts/services-networking/dns-pod-service/) 中的 A 记录将 FQDNs 解析成为 Pods 的 IP 地址。如果 Pods 被调度，这个 A 记录将会使用 Pods 的新 IP 地址更新，但 A 记录的名称不会改变。 - ZooKeeper 在一个名为 `zoo.cfg` 的文件中保存它的应用配置。使用 `kubectl exec` 在 `zk-0` Pod 中查看 `zoo.cfg` 文件的内容。 -``` +```shell kubectl exec zk-0 -- cat /opt/zookeeper/conf/zoo.cfg ``` + -文件底部为 `server.1`、`server.2` 和 `server.3`，其中的 `1`、`2`和`3`分别对应 ZooKeeper 服务的 `myid` 文件中的标识符。它们被设置为 `zk` StatefulSet 中的 Pods 的 FQDNs。 +文件底部为 `server.1`、`server.2` 和 `server.3`，其中的 `1`、`2`和`3`分别对应 ZooKeeper 服务器的 `myid` 文件中的标识符。它们被设置为 `zk` StatefulSet 中的 Pods 的 FQDNs。 -```shell +``` clientPort=2181 dataDir=/var/lib/zookeeper/data dataLogDir=/var/lib/zookeeper/log @@ -210,21 +311,26 @@ minSessionTimeout= 4000 maxSessionTimeout= 40000 autopurge.snapRetainCount=3 autopurge.purgeInterval=0 -server.1=zk-0.zk-headless.default.svc.cluster.local:2888:3888 -server.2=zk-1.zk-headless.default.svc.cluster.local:2888:3888 -server.3=zk-2.zk-headless.default.svc.cluster.local:2888:3888 +server.1=zk-0.zk-hs.default.svc.cluster.local:2888:3888 +server.2=zk-1.zk-hs.default.svc.cluster.local:2888:3888 +server.3=zk-2.zk-hs.default.svc.cluster.local:2888:3888 ``` + ### 达成一致 + 一致性协议要求每个参与者的标识符唯一。在 Zab 协议里任何两个参与者都不应该声明相同的唯一标识符。对于让系统中的进程协商哪些进程已经提交了哪些数据而言，这是必须的。如果有两个 Pods 使用相同的序号启动，这两个 ZooKeeper 服务器会将自己识别为相同的服务器。 - 一致性协议要求每个参与者的标识符唯一。在 Zab 协议里任何两个参与者都不应该声明相同的唯一标识符。对于让系统中的进程协商哪些进程已经提交了哪些数据而言，这是必须的。如果有两个 Pods 使用相同的序号启动，这两个 ZooKeeper 服务会将自己识别为相同的服务。 - - -当你创建 `zk` StatefulSet 时，StatefulSet 控制器按照 Pods 的序号索引顺序的创建每个 Pod。在创建下一个 Pod 前会等待每个 Pod 变成 Running 和 Ready 状态。 ```shell kubectl get pods -w -l app=zk +``` + +``` NAME READY STATUS RESTARTS AGE zk-0 0/1 Pending 0 0s zk-0 0/1 Pending 0 0s @@ -243,50 +349,68 @@ zk-2 0/1 Running 0 19s zk-2 1/1 Running 0 40s ``` + -每个 Pod 的 A 记录仅在 Pod 变成 Ready状态时被录入。因此，ZooKeeper 服务的 FQDNs 只会解析到一个 endpoint，而那个 endpoint 将会是一个唯一的 ZooKeeper 服务，这个服务声明了配置在它的 `myid` 文件中的标识符。 +每个 Pod 的 A 记录仅在 Pod 变成 Ready状态时被录入。因此，ZooKeeper 服务器的 FQDNs 只会解析到一个 endpoint，而那个 endpoint 将会是一个唯一的 ZooKeeper 服务器，这个服务器声明了配置在它的 `myid` 文件中的标识符。 -```shell -zk-0.zk-headless.default.svc.cluster.local -zk-1.zk-headless.default.svc.cluster.local -zk-2.zk-headless.default.svc.cluster.local +``` +zk-0.zk-hs.default.svc.cluster.local +zk-1.zk-hs.default.svc.cluster.local +zk-2.zk-hs.default.svc.cluster.local ``` + 这保证了 ZooKeepers 的 `zoo.cfg` 文件中的 `servers` 属性代表了一个正确配置的 ensemble。 -```shell -server.1=zk-0.zk-headless.default.svc.cluster.local:2888:3888 -server.2=zk-1.zk-headless.default.svc.cluster.local:2888:3888 -server.3=zk-2.zk-headless.default.svc.cluster.local:2888:3888 +``` +server.1=zk-0.zk-hs.default.svc.cluster.local:2888:3888 +server.2=zk-1.zk-hs.default.svc.cluster.local:2888:3888 +server.3=zk-2.zk-hs.default.svc.cluster.local:2888:3888 ``` + -当服务使用 Zab 协议尝试提交一个值的时候，它们会达成一致并成功提交这个值（如果 leader 选举成功并且至少有两个 Pods 处于 Running 和 Ready状态），或者将会失败（如果没有满足上述条件中的任意一条）。当一个服务承认另一个服务的代写时不会有状态产生。 +当服务器使用 Zab 协议尝试提交一个值的时候，它们会达成一致并成功提交这个值（如果 leader 选举成功并且至少有两个 Pods 处于 Running 和 Ready状态），或者将会失败（如果没有满足上述条件中的任意一条）。当一个服务器承认另一个服务器的代写时不会有状态产生。 + ### Ensemble 健康检查 - -最基本的健康检查是向一个 ZooKeeper 服务写入一些数据，然后从另一个服务读取这些数据。 - +最基本的健康检查是向一个 ZooKeeper 服务器写入一些数据，然后从另一个服务器读取这些数据。 使用 `zkCli.sh` 脚本在 `zk-0` Pod 上写入 `world` 到路径 `/hello`。 ```shell kubectl exec zk-0 zkCli.sh create /hello world ``` - - -这将会把 `world` 写入 ensemble 的 `/hello` 路径。 - -```shell +``` WATCHER:: WatchedEvent state:SyncConnected type:None path:null Created /hello ``` + 从 `zk-1` Pod 获取数据。 @@ -294,10 +418,14 @@ Created /hello kubectl exec zk-1 zkCli.sh get /hello ``` + -你在 `zk-0` 创建的数据在 ensemble 中所有的服务上都是可用的。 +你在 `zk-0` 创建的数据在 ensemble 中所有的服务器上都是可用的。 -```shell +``` WATCHER:: WatchedEvent state:SyncConnected type:None path:null @@ -315,31 +443,50 @@ dataLength = 5 numChildren = 0 ``` + ### 准备持久存储 +如同在 [ZooKeeper 基础](#zookeeper-基础) 一节所提到的，ZooKeeper 提交所有的条目到一个持久 WAL，并周期性的将内存快照写入存储介质。对于使用一致性协议实现一个复制状态机的应用来说，使用 WALs 提供持久化是一种常用的技术，对于普通的存储应用也是如此。 -如同在 [ZooKeeper 基础](#zookeeper-basics) 一节所提到的，ZooKeeper 提交所有的条目到一个持久 WAL，并周期性的将内存快照写入存储介质。对于使用一致性协议实现一个复制状态机的应用来说，使用 WALs 提供持久化是一种常用的技术，对于普通的存储应用也是如此。 - - -使用 [`kubectl delete`](/zh/docs/user-guide/kubectl/{{< param "version" >}}/#delete) 删除 `zk` StatefulSet。 +使用 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands/#delete) 删除 `zk` StatefulSet。 ```shell kubectl delete statefulset zk -statefulset "zk" deleted ``` +``` +statefulset.apps "zk" deleted +``` + + 观察 StatefulSet 中的 Pods 变为终止状态。 ```shell -get pods -w -l app=zk +kubectl get pods -w -l app=zk ``` + 当 `zk-0` 完全终止时，使用 `CRTL-C` 结束 kubectl。 -```shell +``` zk-2 1/1 Terminating 0 9m zk-0 1/1 Terminating 0 11m zk-1 1/1 Terminating 0 10m @@ -354,33 +501,37 @@ zk-0 0/1 Terminating 0 11m zk-0 0/1 Terminating 0 11m ``` + + 重新应用 `zookeeper.yaml` 中的代码清单。 ```shell -kubectl apply -f https://k8s.io/docs/tutorials/stateful-application/zookeeper.yaml +kubectl apply -f https://k8s.io/examples/application/zookeeper/zookeeper.yaml ``` + `zk` StatefulSet 将会被创建。由于清单中的其他 API 对象已经存在，所以它们不会被修改。 -```shell -statefulset "zk" created -Error from server (AlreadyExists): error when creating "zookeeper.yaml": services "zk-headless" already exists -Error from server (AlreadyExists): error when creating "zookeeper.yaml": configmaps "zk-config" already exists -Error from server (AlreadyExists): error when creating "zookeeper.yaml": poddisruptionbudgets.policy "zk-budget" already exists -``` - - 观察 StatefulSet 控制器重建 StatefulSet 的 Pods。 ```shell kubectl get pods -w -l app=zk ``` + 一旦 `zk-2` Pod 处于 Running 和 Ready 状态，使用 `CRTL-C` 停止 kubectl命令。 -```shell +``` NAME READY STATUS RESTARTS AGE zk-0 0/1 Pending 0 0s zk-0 0/1 Pending 0 0s @@ -399,17 +550,24 @@ zk-2 0/1 Running 0 19s zk-2 1/1 Running 0 40s ``` + -从 `zk-2` Pod 中获取你在[健康检查](#sanity-testing-the-ensemble)中输入的值。 +从 `zk-2` Pod 中获取你在[健康检查](#Ensemble-健康检查)中输入的值。 ```shell kubectl exec zk-2 zkCli.sh get /hello ``` + 尽管 `zk` StatefulSet 中所有的 Pods 都已经被终止并重建过，ensemble 仍然使用原来的数值提供服务。 -```shell +``` WATCHER:: WatchedEvent state:SyncConnected type:None path:null @@ -427,6 +585,9 @@ dataLength = 5 numChildren = 0 ``` + `zk` StatefulSet 的 `spec` 中的 `volumeClaimTemplates` 字段标识了将要为每个 Pod 准备的 PersistentVolume。 @@ -443,29 +604,39 @@ volumeClaimTemplates: storage: 20Gi ``` + StatefulSet 控制器为 StatefulSet 中的每个 Pod 生成一个 PersistentVolumeClaim。 - 获取 StatefulSet 的 PersistentVolumeClaims。 ```shell kubectl get pvc -l app=zk ``` + 当 StatefulSet 重新创建它的 Pods时，Pods 的 PersistentVolumes 会被重新挂载。 -```shell +``` NAME STATUS VOLUME CAPACITY ACCESSMODES AGE datadir-zk-0 Bound pvc-bed742cd-bcb1-11e6-994f-42010a800002 20Gi RWO 1h datadir-zk-1 Bound pvc-bedd27d2-bcb1-11e6-994f-42010a800002 20Gi RWO 1h datadir-zk-2 Bound pvc-bee0817e-bcb1-11e6-994f-42010a800002 20Gi RWO 1h ``` + -StatefulSet 的容器 `template` 中的 `volumeMounts` 一节使得 PersistentVolumes 被挂载到 ZooKeeper 服务的数据目录。 +StatefulSet 的容器 `template` 中的 `volumeMounts` 一节使得 PersistentVolumes 被挂载到 ZooKeeper 服务器的数据目录。 ```shell volumeMounts: @@ -473,163 +644,98 @@ volumeMounts: mountPath: /var/lib/zookeeper ``` -当 `zk` StatefulSet 中的一个 Pod 被（重新）调度时，它总是拥有相同的 PersistentVolume，挂载到 ZooKeeper 服务的数据目录。即使在 Pods 被重新调度时，所有对 ZooKeeper 服务的 WALs 的写入和它们的全部快照都仍然是持久的。 + +当 `zk` StatefulSet 中的一个 Pod 被（重新）调度时，它总是拥有相同的 PersistentVolume，挂载到 ZooKeeper 服务器的数据目录。即使在 Pods 被重新调度时，所有对 ZooKeeper 服务器的 WALs 的写入和它们的全部快照都仍然是持久的。 + + ## 确保一致性配置 +如同在 [促成 leader 选举](#促成-Leader-选举) 和 [达成一致](#达成一致) 小节中提到的，ZooKeeper ensemble 中的服务器需要一致性的配置来选举一个 leader 并形成一个 quorum。它们还需要 Zab 协议的一致性配置来保证这个协议在网络中正确的工作。在这次的样例中，我们通过直接将配置写入代码清单中来达到该目的。 -如同在 [促成 leader 选举](#facilitating-leader-election) 和 [达成一致](#achieving-consensus) 小节中提到的，ZooKeeper ensemble 中的服务需要一致性的配置来选举一个 leader 并形成一个 quorum。它们还需要 Zab 协议的一致性配置来保证这个协议在网络中正确的工作。你可以使用 ConfigMaps 达到目的。 - - -获取 `zk-config` 的 ConfigMap。 +获取 `zk` StatefulSet。 ```shell - kubectl get cm zk-config -o yaml -apiVersion: v1 -data: - client.cnxns: "60" - ensemble: zk-0;zk-1;zk-2 - init: "10" - jvm.heap: 2G - purge.interval: "0" - snap.retain: "3" - sync: "5" - tick: "2000" +kubectl get sts zk -o yaml +``` +``` +… +command: + - sh + - -c + - "start-zookeeper \ + --servers=3 \ + --data_dir=/var/lib/zookeeper/data \ + --data_log_dir=/var/lib/zookeeper/data/log \ + --conf_dir=/opt/zookeeper/conf \ + --client_port=2181 \ + --election_port=3888 \ + --server_port=2888 \ + --tick_time=2000 \ + --init_limit=10 \ + --sync_limit=5 \ + --heap=512M \ + --max_client_cnxns=60 \ + --snap_retain_count=3 \ + --purge_interval=12 \ + --max_session_timeout=40000 \ + --min_session_timeout=4000 \ + --log_level=INFO" +… ``` + -`zk` StatefulSet 的 `template` 中的 `env` 字段读取 ConfigMap 到环境变量中。这些变量将被注入到容器的运行环境里。 +用于启动 ZooKeeper 服务器的命令将这些配置作为命令行参数传给了 ensemble。你也可以通过环境变量来传入这些配置。 -```yaml -env: - - name : ZK_ENSEMBLE - valueFrom: - configMapKeyRef: - name: zk-config - key: ensemble - - name : ZK_HEAP_SIZE - valueFrom: - configMapKeyRef: - name: zk-config - key: jvm.heap - - name : ZK_TICK_TIME - valueFrom: - configMapKeyRef: - name: zk-config - key: tick - - name : ZK_INIT_LIMIT - valueFrom: - configMapKeyRef: - name: zk-config - key: init - - name : ZK_SYNC_LIMIT - valueFrom: - configMapKeyRef: - name: zk-config - key: tick - - name : ZK_MAX_CLIENT_CNXNS - valueFrom: - configMapKeyRef: - name: zk-config - key: client.cnxns - - name: ZK_SNAP_RETAIN_COUNT - valueFrom: - configMapKeyRef: - name: zk-config - key: snap.retain - - name: ZK_PURGE_INTERVAL - valueFrom: - configMapKeyRef: - name: zk-config - key: purge.interval -``` + ### 配置日志 - `zkGenConfig.sh` 脚本产生的一个文件控制了 ZooKeeper 的日志行为。ZooKeeper 使用了 [Log4j](http://logging.apache.org/log4j/2.x/) 并默认使用基于文件大小和时间的滚动文件追加器作为日志配置。 -从 `zk` StatefulSet 的一个 Pods 中获取日志配置。 + +从 `zk` StatefulSet 的一个 Pod 中获取日志配置。 ```shell kubectl exec zk-0 cat /usr/etc/zookeeper/log4j.properties ``` + 下面的日志配置会使 ZooKeeper 进程将其所有的日志写入标志输出文件流中。 -```shell +``` zookeeper.root.logger=CONSOLE zookeeper.console.threshold=INFO log4j.rootLogger=${zookeeper.root.logger} @@ -639,20 +745,31 @@ log4j.appender.CONSOLE.layout=org.apache.log4j.PatternLayout log4j.appender.CONSOLE.layout.ConversionPattern=%d{ISO8601} [myid:%X{myid}] - %-5p [%t:%C{1}@%L] - %m%n ``` + 这是在容器里安全记录日志的最简单的方法。由于应用的日志被写入标准输出，Kubernetes 将会为你处理日志轮转。Kubernetes 还实现了一个智能保存策略，保证写入标准输出和标准错误流的应用日志不会耗尽本地存储媒介。 -使用 [`kubectl logs`](/zh/docs/user-guide/kubectl/{{< param "version" >}}/#logs) 从一个 Pod 中取回最后几行日志。 +使用 [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands/#logs) 从一个 Pod 中取回最后几行日志。 ```shell kubectl logs zk-0 --tail 20 ``` + 使用 `kubectl logs` 或者从 Kubernetes Dashboard 可以查看写入到标准输出和标准错误流中的应用日志。 -```shell +``` 2016-12-06 19:34:16,236 [myid:1] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@827] - Processing ruok command from /127.0.0.1:52740 2016-12-06 19:34:16,237 [myid:1] - INFO [Thread-1136:NIOServerCnxn@1008] - Closed socket connection for client /127.0.0.1:52740 (no session established for client) 2016-12-06 19:34:26,155 [myid:1] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxnFactory@192] - Accepted socket connection from /127.0.0.1:52749 @@ -675,16 +792,34 @@ kubectl logs zk-0 --tail 20 2016-12-06 19:34:46,230 [myid:1] - INFO [Thread-1142:NIOServerCnxn@1008] - Closed socket connection for client /127.0.0.1:52768 (no session established for client) ``` + +Kubernetes 支持与 [Stackdriver](/docs/tasks/debug-application-cluster/logging-stackdriver/) 和 [Elasticsearch and Kibana](/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana/) 的整合以获得复杂但更为强大的日志功能。 +对于集群级别的日志输出与整合，可以考虑部署一个 [sidecar](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) 容器。 + ### 配置非特权用户 - 在容器中允许应用以特权用户运行这条最佳实践是值得商讨的。如果你的组织要求应用以非特权用户运行，你可以使用 [SecurityContext](/zh/docs/tasks/configure-pod-container/security-context/) 控制运行容器入口点的用户。 - -`zk` StatefulSet 的 Pod 的 `template` 包含了一个 SecurityContext。 +`zk` StatefulSet 的 Pod 的 `template` 包含了一个 `SecurityContext`。 ```yaml securityContext: @@ -692,9 +827,14 @@ securityContext: fsGroup: 1000 ``` + +在 Pods 的容器内部，UID 1000 对应用户 zookeeper，GID 1000对应用户组 zookeeper。 从 `zk-0` Pod 获取 ZooKeeper 进程信息。 @@ -702,18 +842,26 @@ securityContext: kubectl exec zk-0 -- ps -elf ``` + -由于 `securityContext` 对象的 `runAsUser` 字段被设置为1000而不是 root，ZooKeeper进程将以 zookeeper 用户运行。 +由于 `securityContext` 对象的 `runAsUser` 字段被设置为1000而不是 root，ZooKeeper 进程将以 zookeeper 用户运行。 -```shell +``` F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD 4 S zookeep+ 1 0 0 80 0 - 1127 - 20:46 ? 00:00:00 sh -c zkGenConfig.sh && zkServer.sh start-foreground 0 S zookeep+ 27 1 0 80 0 - 1155556 - 20:46 ? 00:00:19 /usr/lib/jvm/java-8-openjdk-amd64/bin/java -Dzookeeper.log.dir=/var/log/zookeeper -Dzookeeper.root.logger=INFO,CONSOLE -cp /usr/bin/../build/classes:/usr/bin/../build/lib/*.jar:/usr/bin/../share/zookeeper/zookeeper-3.4.9.jar:/usr/bin/../share/zookeeper/slf4j-log4j12-1.6.1.jar:/usr/bin/../share/zookeeper/slf4j-api-1.6.1.jar:/usr/bin/../share/zookeeper/netty-3.10.5.Final.jar:/usr/bin/../share/zookeeper/log4j-1.2.16.jar:/usr/bin/../share/zookeeper/jline-0.9.94.jar:/usr/bin/../src/java/lib/*.jar:/usr/bin/../etc/zookeeper: -Xmx2G -Xms2G -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.local.only=false org.apache.zookeeper.server.quorum.QuorumPeerMain /usr/bin/../etc/zookeeper/zoo.cfg ``` + +默认情况下，当 Pod 的 PersistentVolume 被挂载到 ZooKeeper 服务器的数据目录时，它只能被 root 用户访问。这个配置将阻止 ZooKeeper 进程写入它的 WAL 及保存快照。 在 `zk-0` Pod 上获取 ZooKeeper 数据目录的文件权限。 @@ -721,35 +869,138 @@ F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD kubectl exec -ti zk-0 -- ls -ld /var/lib/zookeeper/data ``` + 由于 `securityContext` 对象的 `fsGroup` 字段设置为1000，Pods 的 PersistentVolumes 的所有权属于 zookeeper 用户组，因而 ZooKeeper 进程能够成功的读写数据。 -```shell +``` drwxr-sr-x 3 zookeeper zookeeper 4096 Dec 5 20:45 /var/lib/zookeeper/data ``` + ## 管理 ZooKeeper 进程 - [ZooKeeper documentation](https://zookeeper.apache.org/doc/current/zookeeperAdmin.html#sc_supervision) 文档指出“你将需要一个监管程序用于管理每个 ZooKeeper 服务进程（JVM）”。在分布式系统中，使用一个看门狗（监管程序）来重启故障进程是一种常用的模式。 + + +### 更新 Ensemble + +`zk` `StatefulSet` 的更新策略被设置为了 `RollingUpdate`。 + +你可以使用 `kubectl patch` 更新分配给每个服务器的 `cpus` 的数量。 + +```shell +kubectl patch sts zk --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/resources/requests/cpu", "value":"0.3"}]' +``` +``` +statefulset.apps/zk patched +``` + + + +使用 `kubectl rollout status` 观测更新状态。 + +```shell +kubectl rollout status sts/zk +``` +``` +waiting for statefulset rolling update to complete 0 pods at revision zk-5db4499664... +Waiting for 1 pods to be ready... +Waiting for 1 pods to be ready... +waiting for statefulset rolling update to complete 1 pods at revision zk-5db4499664... +Waiting for 1 pods to be ready... +Waiting for 1 pods to be ready... +waiting for statefulset rolling update to complete 2 pods at revision zk-5db4499664... +Waiting for 1 pods to be ready... +Waiting for 1 pods to be ready... +statefulset rolling update complete 3 pods at revision zk-5db4499664... +``` + + + +这项操作会逆序地依次终止每一个 Pod，并用新的配置重新创建。这样做确保了在滚动更新的过程中 quorum 依旧保持工作。 + +使用 `kubectl rollout history` 命令查看历史或先前的配置。 + +```shell +kubectl rollout history sts/zk +``` + +``` +statefulsets "zk" +REVISION +1 +2 +``` + + + +使用 `kubectl rollout undo` 命令撤销这次的改动。 + +```shell +kubectl rollout undo sts/zk +``` + +``` +statefulset.apps/zk rolled back +``` + + ### 处理进程故障 +[Restart Policies](/zh/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) 控制 Kubernetes 如何处理一个 Pod 中容器入口点的进程故障。对于 StatefulSet 中的 Pods 来说，Always 是唯一合适的 RestartPolicy，这也是默认值。你应该**绝不**覆盖 stateful 应用的默认策略。 -[Restart Policies](/zh/docs/user-guide/pod-states/#restartpolicy) 控制 Kubernetes 如何处理一个 Pod 中容器入口点的进程故障。对于 StatefulSet 中的 Pods 来说，Always 是唯一合适的 RestartPolicy，这也是默认值。你应该**绝不**覆盖 stateful 应用的默认策略。 - - -检查 `zk-0` Pod 中运行的 ZooKeeper 服务的进程树。 +检查 `zk-0` Pod 中运行的 ZooKeeper 服务器的进程树。 ```shell kubectl exec zk-0 -- ps -ef ``` + -作为容器入口点的命令的 PID 为 1，Zookeeper 进程是入口点的子进程，PID 为23。 - +作为容器入口点的命令的 PID 为 1，Zookeeper 进程是入口点的子进程，PID 为27。 ``` UID PID PPID C STIME TTY TIME CMD @@ -757,6 +1008,9 @@ zookeep+ 1 0 0 15:03 ? 00:00:00 sh -c zkGenConfig.sh && zkServer zookeep+ 27 1 0 15:03 ? 00:00:03 /usr/lib/jvm/java-8-openjdk-amd64/bin/java -Dzookeeper.log.dir=/var/log/zookeeper -Dzookeeper.root.logger=INFO,CONSOLE -cp /usr/bin/../build/classes:/usr/bin/../build/lib/*.jar:/usr/bin/../share/zookeeper/zookeeper-3.4.9.jar:/usr/bin/../share/zookeeper/slf4j-log4j12-1.6.1.jar:/usr/bin/../share/zookeeper/slf4j-api-1.6.1.jar:/usr/bin/../share/zookeeper/netty-3.10.5.Final.jar:/usr/bin/../share/zookeeper/log4j-1.2.16.jar:/usr/bin/../share/zookeeper/jline-0.9.94.jar:/usr/bin/../src/java/lib/*.jar:/usr/bin/../etc/zookeeper: -Xmx2G -Xms2G -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.local.only=false org.apache.zookeeper.server.quorum.QuorumPeerMain /usr/bin/../etc/zookeeper/zoo.cfg ``` + 在一个终端观察 `zk` StatefulSet 中的 Pods。 @@ -764,6 +1018,9 @@ zookeep+ 27 1 0 15:03 ? 00:00:03 /usr/lib/jvm/java-8-openjdk-amd6 kubectl get pod -w -l app=zk ``` + 在另一个终端杀掉 Pod `zk-0` 中的 ZooKeeper 进程。 @@ -771,12 +1028,13 @@ kubectl get pod -w -l app=zk kubectl exec zk-0 -- pkill java ``` - + ZooKeeper 进程的终结导致了它父进程的终止。由于容器的 RestartPolicy 是 Always，父进程被重启。 - -```shell +``` NAME READY STATUS RESTARTS AGE zk-0 1/1 Running 0 21m zk-1 1/1 Running 0 20m @@ -787,36 +1045,53 @@ zk-0 0/1 Running 1 29m zk-0 1/1 Running 1 29m ``` + 如果你的应用使用一个脚本（例如 zkServer.sh）来启动一个实现了应用业务逻辑的进程，这个脚本必须和子进程一起结束。这保证了当实现应用业务逻辑的进程故障时，Kubernetes 会重启这个应用的容器。 + +### 存活性测试 你的应用配置为自动重启故障进程，但这对于保持一个分布式系统的健康来说是不够的。许多场景下，一个系统进程可以是活动状态但不响应请求，或者是不健康状态。你应该使用 liveness probes 来通知 Kubernetes 你的应用进程处于不健康状态，需要被重启。 - - -`zk` StatefulSet 的 Pod 的 `template` 一节指定了一个 liveness probe。 - +`zk` StatefulSet 的 Pod 的 `template` 一节指定了一个存活探针。 ```yaml livenessProbe: exec: command: - - "zkOk.sh" + - sh + - -c + - "zookeeper-ready 2181" initialDelaySeconds: 15 timeoutSeconds: 5 ``` + -这个探针调用一个简单的 bash 脚本，使用 ZooKeeper 的四字缩写 `ruok` 来测试服务的健康状态。 +这个探针调用一个简单的 bash 脚本，使用 ZooKeeper 的四字缩写 `ruok` 来测试服务器的健康状态。 - -```bash -ZK_CLIENT_PORT=${ZK_CLIENT_PORT:-2181} -OK=$(echo ruok | nc 127.0.0.1 $ZK_CLIENT_PORT) +``` +OK=$(echo ruok | nc 127.0.0.1 $1) if [ "$OK" == "imok" ]; then exit 0 else @@ -824,28 +1099,39 @@ else fi ``` + 在一个终端窗口观察 `zk` StatefulSet 中的 Pods。 +```shell +kubectl get pod -w -l app=zk +``` + + + +在另一个窗口中，从 Pod `zk-0` 的文件系统中删除 `zookeeper-ready` 脚本。 + +```shell +kubectl exec zk-0 -- rm /usr/bin/zookeeper-ready +``` + + + +当 ZooKeeper 进程的存活探针探测失败时，Kubernetes 将会为你自动重启这个进程，从而保证 ensemble 中不健康状态的进程都被重启。 ```shell kubectl get pod -w -l app=zk ``` - -在另一个窗口中，从 Pod `zk-0` 的文件系统中删除 `zkOk.sh` 脚本。 - - -```shell -kubectl exec zk-0 -- rm /opt/zookeeper/bin/zkOk.sh ``` - - -当 ZooKeeper 进程的 liveness probe 失败时，Kubernetes 将会为你自动重启这个进程，从而保证 ensemble 中不健康状态的进程都被重启。 - - -```shell -kubectl get pod -w -l app=zk NAME READY STATUS RESTARTS AGE zk-0 1/1 Running 0 1h zk-1 1/1 Running 0 1h @@ -856,46 +1142,79 @@ zk-0 0/1 Running 1 1h zk-0 1/1 Running 1 1h ``` + -可读性不同于存活性。如果一个进程是存活的，它是可调度和健康的。如果一个进程是就绪的，它应该能够处理输入。存活性是可读性的必要非充分条件。在许多场景下，特别是初始化和终止过程中，一个进程可以是存活但没有就绪。 +### 就绪性测试 +就绪不同于存活。如果一个进程是存活的，它是可调度和健康的。如果一个进程是就绪的，它应该能够处理输入。存活是就绪的必要非充分条件。在许多场景下，特别是初始化和终止过程中，一个进程可以是存活但没有就绪的。 -如果你指定了一个可读性探针，Kubernetes将保证在可读性检查通过之前，你的应用不会接收到网络流量。 - - -对于一个 ZooKeeper 服务来说，存活性实现了可读性。因此 `zookeeper.yaml` 清单中的可读性探针和存活性探针完全相同。 +如果你指定了一个就绪探针，Kubernetes将保证在就绪检查通过之前，你的应用不会接收到网络流量。 +对于一个 ZooKeeper 服务器来说，存活即就绪。因此 `zookeeper.yaml` 清单中的就绪探针和存活探针完全相同。 ```yaml - readinessProbe: - exec: - command: - - "zkOk.sh" - initialDelaySeconds: 15 - timeoutSeconds: 5 + readinessProbe: + exec: + command: + - sh + - -c + - "zookeeper-ready 2181" + initialDelaySeconds: 15 + timeoutSeconds: 5 ``` + +虽然存活探针和就绪探针是相同的，但同时指定它们两者仍然重要。这保证了 ZooKeeper ensemble 中只有健康的服务器能接收网络流量。 -虽然存活性探针和可读性探针是相同的，但同时指定它们两者仍然重要。这保证了 ZooKeeper ensemble 中唯一健康的服务能够接收网络流量。 + ## 容忍节点故障 +ZooKeeper 需要一个 quorum 来提交数据变动。对于一个拥有 3 个服务器的 ensemble来说，必须有两个服务器是健康的，写入才能成功。在基于 quorum 的系统里，成员被部署在故障域之间以保证可用性。为了防止由于某台机器断连引起服务中断，最佳实践是防止应用的多个示例在相同的机器上共存。 -ZooKeeper 需要一个服务的 quorum 来成功的提交数据变动。对于一个 3 个服务的 ensemble，必须有两个是健康的写入才能成功。在基于 quorum 的系统里，成员被部署在故障域之间以保证可用性。为了防止由于某台机器断连引起服务中断，最佳实践是防止应用的多个示例在相同的机器上共存。 - - -默认情况下，Kubernetes 可以把 StatefulSet 的 Pods 部署在相同节点上。对于你创建的 3 个服务的 ensemble 来说，如果有两个服务并存于相同的节点上并且该节点发生故障时，你的 ZooKeeper 服务客户端将不能使用服务，至少一个 Pods 被重新调度后才能恢复。 - - -你应该总是提供额外的容量以允许关键系统进程在节点故障时能够被重新调度。如果你这样做了，服务故障就只会持续到 Kubernetes 调度器重新调度 ZooKeeper 服务之前。但是，如果希望你的服务在容忍节点故障时无停服时间，你应该设置 `podAntiAffinity`。 +默认情况下，Kubernetes 可以把 StatefulSet 的 Pods 部署在相同节点上。对于你创建的 3 个服务器的 ensemble 来说，如果有两个服务器并存于相同的节点上并且该节点发生故障时，ZooKeeper 服务将中断，直至至少一个 Pods 被重新调度。 +你应该总是提供额外的容量以允许关键系统进程在节点故障时能够被重新调度。如果你这样做了，服务故障就只会持续到 Kubernetes 调度器重新调度某个 ZooKeeper 服务器为止。但是，如果希望你的服务在容忍节点故障时无停服时间，你应该设置 `podAntiAffinity`。 获取 `zk` Stateful Set 中的 Pods 的节点。 @@ -903,17 +1222,23 @@ ZooKeeper 需要一个服务的 quorum 来成功的提交数据变动。对于 for i in 0 1 2; do kubectl get pod zk-$i --template {{.spec.nodeName}}; echo ""; done ``` + `zk` StatefulSe 中所有的 Pods 都被部署在不同的节点。 -```shell -kubernetes-minion-group-cxpk -kubernetes-minion-group-a5aq -kubernetes-minion-group-2g2d +``` +kubernetes-node-cxpk +kubernetes-node-a5aq +kubernetes-node-2g2d ``` + -这是因为 `zk` StatefulSet 中的 Pods 指定了 PodAntiAffinity。 +这是因为 `zk` StatefulSet 中的 Pods 指定了 `PodAntiAffinity`。 ```yaml affinity: @@ -928,19 +1253,36 @@ kubernetes-minion-group-2g2d topologyKey: "kubernetes.io/hostname" ``` + -`requiredDuringSchedulingRequiredDuringExecution` 告诉 Kubernetes 调度器，在以 `topologyKey` 指定的域中，绝对不要把带有键为 `app`，值为 `zk` 的标签的两个 Pods 调度到相同的节点。`topologyKey` -`kubernetes.io/hostname` 表示这个域是一个单独的节点。使用不同的 rules、labels 和 selectors，你能够通过这种技术把你的 ensemble 在物理、网络和电力故障域之间分布。 +`requiredDuringSchedulingIgnoredDuringExecution` 告诉 Kubernetes 调度器，在以 `topologyKey` 指定的域中，绝对不要把带有键为 `app`，值为 `zk` 的标签的两个 Pods 调度到相同的节点。`topologyKey` +`kubernetes.io/hostname` 表示这个域是一个单独的节点。使用不同的 rules、labels 和 selectors，你能够通过这种技术把你的 ensemble 分布在不同的物理、网络和电力故障域之间。 + ## 存活管理 - **在本节中你将会 cordon 和 drain 节点。如果你是在一个共享的集群里使用本教程，请保证不会影响到其他租户** - -上一小节展示了如何在节点之间分散 Pods 以在计划外的节点故障时存活。但是你也需要为计划内维护引起的临时节点故障做准备。 - +上一小节展示了如何在节点之间分散 Pods 以在计划外的节点故障时保证服务存活。但是你也需要为计划内维护引起的临时节点故障做准备。 获取你集群中的节点。 @@ -948,58 +1290,88 @@ kubernetes-minion-group-2g2d kubectl get nodes ``` + -使用 [`kubectl cordon`](/zh/docs/user-guide/kubectl/{{< param "version" >}}/#cordon) cordon 你的集群中除4个节点以外的所有节点。 +使用 [`kubectl cordon`](/docs/reference/generated/kubectl/kubectl-commands/#cordon) cordon 你的集群中除4个节点以外的所有节点。 ```shell kubectl cordon < node name > ``` + -获取 `zk-budget` PodDisruptionBudget。 +获取 `zk-pdb` `PodDisruptionBudget`。 ```shell -kubectl get poddisruptionbudget zk-budget +kubectl get pdb zk-pdb ``` + -`min-available` 字段指示 Kubernetes 在任何时候，`zk` StatefulSet 至少有两个 Pods 必须是可用的。 - -```yaml -NAME MIN-AVAILABLE ALLOWED-DISRUPTIONS AGE -zk-budget 2 1 1h +`max-unavailable` 字段指示 Kubernetes 在任何时候，`zk` `StatefulSet` 至多有一个 Pod 是不可用的。 +``` +NAME MIN-AVAILABLE MAX-UNAVAILABLE ALLOWED-DISRUPTIONS AGE +zk-pdb N/A 1 1 ``` + -在一个终端观察 `zk` StatefulSet 中的 Pods。 +在一个终端观察 `zk` `StatefulSet` 中的 Pods。 ```shell kubectl get pods -w -l app=zk ``` + 在另一个终端获取 Pods 当前调度的节点。 ```shell for i in 0 1 2; do kubectl get pod zk-$i --template {{.spec.nodeName}}; echo ""; done -kubernetes-minion-group-pb41 -kubernetes-minion-group-ixsl -kubernetes-minion-group-i4c4 - ``` -使用 [`kubectl drain`](/zh/docs/user-guide/kubectl/{{< param "version" >}}/#drain) 来 cordon 和 drain `zk-0` Pod 调度的节点。 +``` +kubernetes-node-pb41 +kubernetes-node-ixsl +kubernetes-node-i4c4 +``` + + + +使用 [`kubectl drain`](/docs/reference/generated/kubectl/kubectl-commands/#drain) 来 cordon 和 drain `zk-0` Pod 调度的节点。 ```shell kubectl drain $(kubectl get pod zk-0 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data -node "kubernetes-minion-group-pb41" cordoned -WARNING: Deleting pods not managed by ReplicationController, ReplicaSet, Job, or DaemonSet: fluentd-cloud-logging-kubernetes-minion-group-pb41, kube-proxy-kubernetes-minion-group-pb41; Ignoring DaemonSet-managed pods: node-problem-detector-v0.1-o5elz -pod "zk-0" deleted -node "kubernetes-minion-group-pb41" drained - ``` +``` +node "kubernetes-node-pb41" cordoned + +WARNING: Deleting pods not managed by ReplicationController, ReplicaSet, Job, or DaemonSet: fluentd-cloud-logging-kubernetes-node-pb41, kube-proxy-kubernetes-node-pb41; Ignoring DaemonSet-managed pods: node-problem-detector-v0.1-o5elz +pod "zk-0" deleted +node "kubernetes-node-pb41" drained +``` + + 由于你的集群中有4个节点, `kubectl drain` 执行成功，`zk-0 被调度到其它节点。 @@ -1020,22 +1392,35 @@ zk-0 0/1 Running 0 51s zk-0 1/1 Running 0 1m ``` + 在第一个终端持续观察 StatefulSet 的 Pods并 drain `zk-1` 调度的节点。 ```shell -kubectl drain $(kubectl get pod zk-1 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data "kubernetes-minion-group-ixsl" cordoned -WARNING: Deleting pods not managed by ReplicationController, ReplicaSet, Job, or DaemonSet: fluentd-cloud-logging-kubernetes-minion-group-ixsl, kube-proxy-kubernetes-minion-group-ixsl; Ignoring DaemonSet-managed pods: node-problem-detector-v0.1-voc74 -pod "zk-1" deleted -node "kubernetes-minion-group-ixsl" drained - +kubectl drain $(kubectl get pod zk-1 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data "kubernetes-node-ixsl" cordoned ``` +``` +WARNING: Deleting pods not managed by ReplicationController, ReplicaSet, Job, or DaemonSet: fluentd-cloud-logging-kubernetes-node-ixsl, kube-proxy-kubernetes-node-ixsl; Ignoring DaemonSet-managed pods: node-problem-detector-v0.1-voc74 +pod "zk-1" deleted +node "kubernetes-node-ixsl" drained +``` + + `zk-1` Pod 不能被调度。由于 `zk` StatefulSet 包含了一个防止 Pods 共存的 PodAntiAffinity 规则，而且只有两个节点可用于调度，这个 Pod 将保持在 Pending 状态。 ```shell kubectl get pods -w -l app=zk +``` + +``` NAME READY STATUS RESTARTS AGE zk-0 1/1 Running 2 1h zk-1 1/1 Running 0 1h @@ -1058,23 +1443,35 @@ zk-1 0/1 Pending 0 0s zk-1 0/1 Pending 0 0s ``` + 继续观察 stateful set 的 Pods 并 drain `zk-2` 调度的节点。 ```shell kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data -node "kubernetes-minion-group-i4c4" cordoned -WARNING: Deleting pods not managed by ReplicationController, ReplicaSet, Job, or DaemonSet: fluentd-cloud-logging-kubernetes-minion-group-i4c4, kube-proxy-kubernetes-minion-group-i4c4; Ignoring DaemonSet-managed pods: node-problem-detector-v0.1-dyrog -WARNING: Ignoring DaemonSet-managed pods: node-problem-detector-v0.1-dyrog; Deleting pods not managed by ReplicationController, ReplicaSet, Job, or DaemonSet: fluentd-cloud-logging-kubernetes-minion-group-i4c4, kube-proxy-kubernetes-minion-group-i4c4 +``` +``` +node "kubernetes-node-i4c4" cordoned + +WARNING: Deleting pods not managed by ReplicationController, ReplicaSet, Job, or DaemonSet: fluentd-cloud-logging-kubernetes-node-i4c4, kube-proxy-kubernetes-node-i4c4; Ignoring DaemonSet-managed pods: node-problem-detector-v0.1-dyrog +WARNING: Ignoring DaemonSet-managed pods: node-problem-detector-v0.1-dyrog; Deleting pods not managed by ReplicationController, ReplicaSet, Job, or DaemonSet: fluentd-cloud-logging-kubernetes-node-i4c4, kube-proxy-kubernetes-node-i4c4 There are pending pods when an error occurred: Cannot evict pod as it would violate the pod's disruption budget. pod/zk-2 - ``` + 使用 `CRTL-C` 终止 kubectl。 - 你不能 drain 第三个节点，因为删除 `zk-2` 将和 `zk-budget` 冲突。然而这个节点仍然保持 cordoned。 @@ -1084,6 +1481,9 @@ pod/zk-2 kubectl exec zk-0 zkCli.sh get /hello ``` + 由于遵守了 PodDisruptionBudget，服务仍然可用。 @@ -1103,19 +1503,29 @@ dataLength = 5 numChildren = 0 ``` + -使用 [`kubectl uncordon`](/zh/docs/user-guide/kubectl/{{< param "version" >}}/#uncordon) 来取消对第一个节点的隔离。 +使用 [`kubectl uncordon`](/docs/reference/generated/kubectl/kubectl-commands/#uncordon) 来取消对第一个节点的隔离。 ```shell -kubectl uncordon kubernetes-minion-group-pb41 -node "kubernetes-minion-group-pb41" uncordoned +kubectl uncordon kubernetes-node-pb41 +``` +``` +node "kubernetes-node-pb41" uncordoned ``` + `zk-1` 被重新调度到了这个节点。等待 `zk-1` 变为 Running 和 Ready 状态。 ```shell kubectl get pods -w -l app=zk +``` +``` NAME READY STATUS RESTARTS AGE zk-0 1/1 Running 2 1h zk-1 1/1 Running 0 1h @@ -1142,39 +1552,67 @@ zk-1 0/1 Running 0 13m zk-1 1/1 Running 0 13m ``` + 尝试 drain `zk-2` 调度的节点。 ```shell kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data -node "kubernetes-minion-group-i4c4" already cordoned -WARNING: Deleting pods not managed by ReplicationController, ReplicaSet, Job, or DaemonSet: fluentd-cloud-logging-kubernetes-minion-group-i4c4, kube-proxy-kubernetes-minion-group-i4c4; Ignoring DaemonSet-managed pods: node-problem-detector-v0.1-dyrog -pod "heapster-v1.2.0-2604621511-wht1r" deleted -pod "zk-2" deleted -node "kubernetes-minion-group-i4c4" drained - ``` + + +输出： + +``` +node "kubernetes-node-i4c4" already cordoned +WARNING: Deleting pods not managed by ReplicationController, ReplicaSet, Job, or DaemonSet: fluentd-cloud-logging-kubernetes-node-i4c4, kube-proxy-kubernetes-node-i4c4; Ignoring DaemonSet-managed pods: node-problem-detector-v0.1-dyrog +pod "heapster-v1.2.0-2604621511-wht1r" deleted +pod "zk-2" deleted +node "kubernetes-node-i4c4" drained +``` + + 这次 `kubectl drain` 执行成功。 - Uncordon 第二个节点以允许 `zk-2` 被重新调度。 ```shell -kubectl uncordon kubernetes-minion-group-ixsl -node "kubernetes-minion-group-ixsl" uncordoned +kubectl uncordon kubernetes-node-ixsl ``` +``` +node "kubernetes-node-ixsl" uncordoned +``` -你可以同时使用 `kubectl drain` 和 PodDisruptionBudgets 来保证你的服务在维护过程中仍然可用。如果使用 drain 来隔离节点并在此之前删除 pods 使节点进入离线维护状态，如果服务表达了 disruption budget，这个 budget 将被遵守。你应该总是为关键服务分配额外容量，这样它们的 Pods 就能够迅速的重新调度。 - + +你可以同时使用 `kubectl drain` 和 `PodDisruptionBudgets` 来保证你的服务在维护过程中仍然可用。如果使用了 drain 来隔离节点并在节点离线之前排出了 pods，那么表达了 disruption budget 的服务将会遵守该 budget。你应该总是为关键服务分配额外容量，这样它们的 Pods 就能够迅速的重新调度。 ## {{% heading "cleanup" %}} + + * 使用 `kubectl uncordon` 解除你集群中所有节点的隔离。 * 你需要删除在本教程中使用的 PersistentVolumes 的持久存储媒介。请遵循必须的步骤，基于你的环境、存储配置和准备方法，保证回收所有的存储。 - - diff --git a/i18n/en.toml b/i18n/en.toml index bc25eaf2a1..d496085b8d 100644 --- a/i18n/en.toml +++ b/i18n/en.toml @@ -1,7 +1,7 @@ # i18n strings for the English (main) site. # NOTE: Please keep the entries in alphabetical order when editing [announcement_title] -other = "KubeCon + CloudNativeCon NA 2020 virtual." +other = "KubeCon + CloudNativeCon NA 2020 virtual." [announcement_message] other = "4 days of incredible opportunities to collaborate, learn, and share with the entire community!
November 17 – 20 2020" diff --git a/layouts/shortcodes/cncf-landscape.html b/layouts/shortcodes/cncf-landscape.html index ee37678624..a97d4f9f8a 100644 --- a/layouts/shortcodes/cncf-landscape.html +++ b/layouts/shortcodes/cncf-landscape.html @@ -58,9 +58,9 @@ document.addEventListener("DOMContentLoaded", function () { {{- end -}}
{{ if ( .Get "category" ) }} - + {{ else }} - + {{ end }}
diff --git a/static/css/newcommunity.css b/static/css/newcommunity.css index e792fceae9..993cd89e1a 100644 --- a/static/css/newcommunity.css +++ b/static/css/newcommunity.css @@ -241,14 +241,13 @@ a { } .fullbutton { - display: block; + display: inline-block; margin: auto; margin-top: 2rem; - width: 156px; background-color: #0662EE; color: white; font-size: 18px; - padding: 2%; + padding: 2% 2.5%; letter-spacing: 0.07em; font-weight: bold; diff --git a/static/css/training.css b/static/css/training.css index 4aa49c54c9..489bd1e0b2 100644 --- a/static/css/training.css +++ b/static/css/training.css @@ -1,29 +1,28 @@ -#hero { +body.cid-training body.cid-training #hero { text-align: left; padding-bottom: 20px; } -.section { +body.cid-training body.cid-training .section { clear: both; padding: 0px; margin-bottom: 2em; width: 100%; } -section.call-to-action { +body.cid-training section.call-to-action { color: #ffffff; background-color: #3371e3; } -section.call-to-action .main-section { +body.cid-training section.call-to-action .main-section { max-width: initial; } -section.call-to-action .main-section > div.call-to-action { +body.cid-training section.call-to-action .main-section > div.call-to-action { display: flex; flex-direction: row; flex-wrap: wrap; - flex-basis: auto; justify-content: center; align-items: center; margin: initial; @@ -31,54 +30,57 @@ section.call-to-action .main-section > div.call-to-action { padding-bottom: 5rem; } -section.call-to-action .main-section > div.call-to-action > div { - order: 1; +body.cid-training section.call-to-action .main-section > div.call-to-action > div { padding: 20px; } -section.call-to-action .main-section .cta-text { - text-align: center; - flex: 1 1 auto; - max-width: 50vw; +body.cid-training section.call-to-action .main-section .cta-text { + width: 100%; + flex-basis: 100%; } -/* if max() and min() are available, use them */ -section.call-to-action .main-section .cta-text { +body.cid-training section.call-to-action .main-section .cta-text > * { + margin-left: auto; + margin-right: auto; + text-align: center; + /* if max() and min() are available, use them */ min-width: min(20em, 50vw); max-width: min(1000px, 50vw); } -section.call-to-action .main-section .cta-image.cta-image-before { - order: 0 +body.cid-training section.call-to-action .main-section .cta-image { + max-width: max(20vw,150px); + flex-basis: auto; } - -section.call-to-action .main-section .cta-image.cta-image-after { - order: 2 -} - -section.call-to-action .main-section .cta-image > img { +body.cid-training section.call-to-action .main-section .cta-image > img { display: block; width: 150px; margin: auto; } -.col { +body.cid-training #logo-cks { + order: 2; /* central */ +} + + + +body.cid-training .col { display: flex; flex-direction: row; float: left; margin: 1% 0 1% 1.6%; } -.col:first-child { margin-left: 0; } +body.cid-training .col:first-child { margin-left: 0; } -.col-container { +body.cid-training .col-container { display: flex; /* Make the container element behave like a table */ flex-direction: row; width: 100%; /* Set full-width to expand the whole page */ padding-bottom: 30px; } -.col-nav { +body.cid-training .col-nav { display: flex; flex-grow: 1; width: 18%; @@ -87,44 +89,62 @@ section.call-to-action .main-section .cta-image > img { border: 5px solid white; } +body.cid-training #get-certified .col-nav { + flex-flow: column nowrap; + justify-content: space-between; +} + +body.cid-training #get-certified .col-nav > * { + flex-grow: 0; + flex-shrink: 0; + flex-basis: auto; +} + +body.cid-training #get-certified .col-nav > br { + flex-grow: 1; + display: block; + min-height: 2em; +} + +body.cid-training #get-certified .col-nav a.button { + flex: initial; + width: auto; + margin-left: auto; + margin-right: auto; +} + @media only screen and (max-width: 840px) { - section.call-to-action .main-section .cta-image.cta-image-before, section.call-to-action .main-section .cta-image.cta-image-after { - order: 0; - } - section.call-to-action .main-section .cta-image > img { + body.cid-training section.call-to-action .main-section .cta-image > img { margin: 0; } - section.call-to-action .main-section .cta-image > img { + body.cid-training section.call-to-action .main-section .cta-image > img { width: 7rem; } - section.call-to-action .main-section > div.call-to-action > div { + body.cid-training section.call-to-action .main-section > div.call-to-action > div { padding: 0 2rem 0 2rem; } - section.call-to-action .main-section .cta-text { - flex: 2 0 75vw; - max-width: initial; - padding: 5vw 0 0 0; - } } + /* GO FULL WIDTH AT LESS THAN 480 PIXELS */ @media only screen and (max-width: 480px) { - .col { margin: 1% 0 1% 0%;} - .col-container { flex-direction: column; } + body.cid-training .col { margin: 1% 0 1% 0%;} + body.cid-training .col-container { flex-direction: column; } + body.cid-training #logo-cks { order: initial; } } @media only screen and (max-width: 650px) { - .col-nav { + body.cid-training .col-nav { display: block; width: 100%; } - .col-container { flex-direction: column; } + body.cid-training .col-container { flex-direction: column; } } -.button{ +body.cid-training .button { max-width: 100%; box-sizing: border-box; margin: 1em 0; @@ -136,47 +156,48 @@ section.call-to-action .main-section .cta-image > img { font-size: 16px; background-color: #3371e3; text-decoration: none; + text-align: center; } -h5 { +body.cid-training h5 { font-size: 16px; font-weight: 500; line-height: 1.5em; margin-bottom: 2em; } -.white-text { +body.cid-training .white-text { color: #fff; } -.padded { +body.cid-training .padded { padding-top: 100px; padding-bottom: 100px; } -.blue-bg { +body.cid-training .blue-bg { background-color: #3371e3; } -.lighter-gray-bg { +body.cid-training .lighter-gray-bg { background-color: #f4f4f4; } -.two-thirds-centered { +body.cid-training .two-thirds-centered { width: 66%; max-width: 950px; margin-left: auto; margin-right: auto; } -.landscape-section { +body.cid-training .landscape-section { margin-left: auto; margin-right: auto; max-width: 1200px; width: 100%; } -#landscape { +body.cid-training #landscape { opacity: 1; visibility: visible; overflow: hidden; diff --git a/static/images/training/kubernetes-cks-white.svg b/static/images/training/kubernetes-cks-white.svg new file mode 100644 index 0000000000..872c0c6a76 --- /dev/null +++ b/static/images/training/kubernetes-cks-white.svg @@ -0,0 +1,33 @@ + + + + + + image/svg+xml + + + + + + + + + +