diff --git a/README-ja.md b/README-ja.md index 91e624c610..c4acd30d84 100644 --- a/README-ja.md +++ b/README-ja.md @@ -4,6 +4,9 @@ このリポジトリには、[KubernetesのWebサイトとドキュメント](https://kubernetes.io/)をビルドするために必要な全アセットが格納されています。貢献に興味を持っていただきありがとうございます！ +- [ドキュメントに貢献する](#contributing-to-the-docs) +- [翻訳された`README.md`一覧](#localization-readmemds) + # リポジトリの使い方 Hugo(Extended version)を使用してWebサイトをローカルで実行することも、コンテナランタイムで実行することもできます。コンテナランタイムを使用することを強くお勧めします。これにより、本番Webサイトとのデプロイメントの一貫性が得られます。 @@ -56,6 +59,43 @@ make serve これで、Hugoのサーバーが1313番ポートを使って開始します。お使いのブラウザにて http://localhost:1313 にアクセスしてください。リポジトリ内のソースファイルに変更を加えると、HugoがWebサイトの内容を更新してブラウザに反映します。 +## API reference pagesをビルドする + +`content/en/docs/reference/kubernetes-api`に配置されているAPIリファレンスページはを使ってSwagger仕様書からビルドされています。 + +新しいKubernetesリリースのためにリファレンスページをアップデートするには、次の手順を実行します: + +1. `api-ref-generator`サブモジュールをプルする: + + ```bash + git submodule update --init --recursive --depth 1 + ``` + +2. Swagger仕様書を更新する: + + ```bash + curl 'https://raw.githubusercontent.com/kubernetes/kubernetes/master/api/openapi-spec/swagger.json' > api-ref-assets/api/swagger.json + ``` + +3. 新しいリリースの変更を反映するため、`api-ref-assets/config/`で`toc.yaml`と`fields.yaml`を適用する。 + +4. 次に、ページをビルドする: + + ```bash + make api-reference + ``` + + コンテナイメージからサイトを作成・サーブする事でローカルで結果をテストすることができます: + + ```bash + make container-image + make container-serve + ``` + + APIリファレンスを見るために、ブラウザでを開いてください。 + +5. 新しいコントラクトのすべての変更が設定ファイル`toc.yaml`と`fields.yaml`に反映されたら、新しく生成されたAPIリファレンスページとともにPull Requestを作成します。 + ## トラブルシューティング ### error: failed to transform resource: TOCSS: failed to transform "scss/main.scss" (text/x-scss): this feature is not available in your current Hugo version @@ -107,7 +147,7 @@ sudo launchctl load -w /Library/LaunchDaemons/limit.maxfiles.plist - [Slack](https://kubernetes.slack.com/messages/kubernetes-docs-ja) - [メーリングリスト](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) -## ドキュメントに貢献する +## ドキュメントに貢献する {#contributing-to-the-docs} GitHubの画面右上にある**Fork**ボタンをクリックすると、お使いのGitHubアカウントに紐付いた本リポジトリのコピーが作成され、このコピーのことを*フォーク*と呼びます。フォークリポジトリの中ではお好きなように変更を加えていただいて構いません。加えた変更をこのリポジトリに追加したい任意のタイミングにて、フォークリポジトリからPull Reqeustを作成してください。 @@ -124,7 +164,15 @@ Kubernetesのドキュメントへの貢献に関する詳細については以 * [ドキュメントのスタイルガイド](https://kubernetes.io/docs/contribute/style/style-guide/) * [Kubernetesドキュメントの翻訳方法](https://kubernetes.io/docs/contribute/localization/) -## 翻訳された`README.md`一覧 +### New Contributor Ambassadors + +コントリビュートする時に何か助けが必要なら、[New Contributor Ambassadors](https://kubernetes.io/docs/contribute/advanced/#serve-as-a-new-contributor-ambassador)に聞いてみると良いでしょう。彼らはSIG Docsのapproverで、最初の数回のPull Requestを通して新しいコントリビューターを指導し助けることを責務としています。New Contributors Ambassadorsにコンタクトするには、[Kubernetes Slack](https://slack.k8s.io)が最適な場所です。現在のSIG DocsのNew Contributor Ambassadorは次の通りです: + +| 名前 | Slack | GitHub | +| -------------------------- | -------------------------- | -------------------------- | +| Arsh Sharma | @arsh | @RinkiyaKeDad | + +## 翻訳された`README.md`一覧 {#localization-readmemds} | Language | Language | |---|---| diff --git a/content/en/blog/_posts/2017-06-00-Kubernetes-1-7-Security-Hardening-Stateful-Application-Extensibility-Updates.md b/content/en/blog/_posts/2017-06-00-Kubernetes-1-7-Security-Hardening-Stateful-Application-Extensibility-Updates.md index e8f15ec6b9..e80f557011 100644 --- a/content/en/blog/_posts/2017-06-00-Kubernetes-1-7-Security-Hardening-Stateful-Application-Extensibility-Updates.md +++ b/content/en/blog/_posts/2017-06-00-Kubernetes-1-7-Security-Hardening-Stateful-Application-Extensibility-Updates.md @@ -19,7 +19,7 @@ Security: - [Node authorizer](/docs/reference/access-authn-authz/node/) and admission control plugin are new additions that restrict kubelet’s access to secrets, pods and other objects based on its node. - [Encryption for Secrets](/docs/tasks/administer-cluster/encrypt-data/), and other resources in etcd, is now available as alpha.  - [Kubelet TLS bootstrapping](/docs/admin/kubelet-tls-bootstrapping/) now supports client and server certificate rotation. -- [Audit logs](/docs/tasks/debug-application-cluster/audit/) stored by the API server are now more customizable and extensible with support for event filtering and webhooks. They also provide richer data for system audit. +- [Audit logs](/docs/tasks/debug/debug-cluster/audit/) stored by the API server are now more customizable and extensible with support for event filtering and webhooks. They also provide richer data for system audit. Stateful workloads: diff --git a/content/en/blog/_posts/2017-12-00-Using-Ebpf-In-Kubernetes.md b/content/en/blog/_posts/2017-12-00-Using-Ebpf-In-Kubernetes.md index 09dd0068f5..cc896a4948 100644 --- a/content/en/blog/_posts/2017-12-00-Using-Ebpf-In-Kubernetes.md +++ b/content/en/blog/_posts/2017-12-00-Using-Ebpf-In-Kubernetes.md @@ -117,7 +117,7 @@ To achieve the best possible isolation, each function call would have to happen By using Landlock, we could isolate function calls from each other within the same container, making a temporary file created by one function call inaccessible to the next function call, for example. Integration between Landlock and technologies like Kubernetes-based serverless frameworks would be a ripe area for further exploration. ## Auditing kubectl-exec with eBPF -In Kubernetes 1.7 the [audit proposal](/docs/tasks/debug-application-cluster/audit/) started making its way in. It's currently pre-stable with plans to be stable in the 1.10 release. As the name implies, it allows administrators to log and audit events that take place in a Kubernetes cluster. +In Kubernetes 1.7 the [audit proposal](/docs/tasks/debug/debug-cluster/audit/) started making its way in. It's currently pre-stable with plans to be stable in the 1.10 release. As the name implies, it allows administrators to log and audit events that take place in a Kubernetes cluster. While these events log Kubernetes events, they don't currently provide the level of visibility that some may require. For example, while we can see that someone has used `kubectl exec` to enter a container, we are not able to see what commands were executed in that session. With eBPF one can attach a BPF program that would record any commands executed in the `kubectl exec` session and pass those commands to a user-space program that logs those events. We could then play that session back and know the exact sequence of events that took place. ## Learn more about eBPF diff --git a/content/en/blog/_posts/2018-07-18-11-ways-not-to-get-hacked.md b/content/en/blog/_posts/2018-07-18-11-ways-not-to-get-hacked.md index 329d81cf56..cf72ba30f3 100644 --- a/content/en/blog/_posts/2018-07-18-11-ways-not-to-get-hacked.md +++ b/content/en/blog/_posts/2018-07-18-11-ways-not-to-get-hacked.md @@ -66,7 +66,7 @@ There are plenty of [good examples](https://docs.bitnami.com/kubernetes/how-to/c Incorrect or excessively permissive RBAC policies are a security threat in case of a compromised pod. Maintaining least privilege, and continuously reviewing and improving RBAC rules, should be considered part of the "technical debt hygiene" that teams build into their development lifecycle. -[Audit Logging](/docs/tasks/debug-application-cluster/audit/) (beta in 1.10) provides customisable API logging at the payload (e.g. request and response), and also metadata levels. Log levels can be tuned to your organisation's security policy - [GKE](https://cloud.google.com/kubernetes-engine/docs/how-to/audit-logging#audit_policy) provides sane defaults to get you started. +[Audit Logging](/docs/tasks/debug/debug-cluster/audit/) (beta in 1.10) provides customisable API logging at the payload (e.g. request and response), and also metadata levels. Log levels can be tuned to your organisation's security policy - [GKE](https://cloud.google.com/kubernetes-engine/docs/how-to/audit-logging#audit_policy) provides sane defaults to get you started. For read requests such as get, list, and watch, only the request object is saved in the audit logs; the response object is not. For requests involving sensitive data such as Secret and ConfigMap, only the metadata is exported. For all other requests, both request and response objects are saved in audit logs. diff --git a/content/en/blog/_posts/2018-08-03-make-kubernetes-production-grade-anywhere.md b/content/en/blog/_posts/2018-08-03-make-kubernetes-production-grade-anywhere.md index 329b2c4de7..00416256e0 100644 --- a/content/en/blog/_posts/2018-08-03-make-kubernetes-production-grade-anywhere.md +++ b/content/en/blog/_posts/2018-08-03-make-kubernetes-production-grade-anywhere.md @@ -174,7 +174,7 @@ Cluster-distributed stateful services (e.g., Cassandra) can benefit from splitti ## Other considerations -[Logs](/docs/concepts/cluster-administration/logging/) and [metrics](/docs/tasks/debug-application-cluster/resource-usage-monitoring/) (if collected and persistently retained) are valuable to diagnose outages, but given the variety of technologies available it will not be addressed in this blog. If Internet connectivity is available, it may be desirable to retain logs and metrics externally at a central location. +[Logs](/docs/concepts/cluster-administration/logging/) and [metrics](/docs/tasks/debug/debug-cluster/resource-usage-monitoring/) (if collected and persistently retained) are valuable to diagnose outages, but given the variety of technologies available it will not be addressed in this blog. If Internet connectivity is available, it may be desirable to retain logs and metrics externally at a central location. Your production deployment should utilize an automated installation, configuration and update tool (e.g., [Ansible](https://github.com/kubernetes-incubator/kubespray), [BOSH](https://github.com/cloudfoundry-incubator/kubo-deployment), [Chef](https://github.com/chef-cookbooks/kubernetes), [Juju](/docs/getting-started-guides/ubuntu/installation/), [kubeadm](/docs/reference/setup-tools/kubeadm/), [Puppet](https://forge.puppet.com/puppetlabs/kubernetes), etc.). A manual process will have repeatability issues, be labor intensive, error prone, and difficult to scale. [Certified distributions](https://www.cncf.io/certification/software-conformance/#logos) are likely to include a facility for retaining configuration settings across updates, but if you implement your own install and config toolchain, then retention, backup and recovery of the configuration artifacts is essential. Consider keeping your deployment components and settings under a version control system such as Git. diff --git a/content/en/blog/_posts/2020-09-03-warnings/index.md b/content/en/blog/_posts/2020-09-03-warnings/index.md index 5d34fb11cf..082aa72f6f 100644 --- a/content/en/blog/_posts/2020-09-03-warnings/index.md +++ b/content/en/blog/_posts/2020-09-03-warnings/index.md @@ -177,7 +177,7 @@ group_right() apiserver_request_total Metrics are a fast way to check whether deprecated APIs are being used, and at what rate, but they don't include enough information to identify particular clients or API objects. -Starting in Kubernetes v1.19, [audit events](/docs/tasks/debug-application-cluster/audit/) +Starting in Kubernetes v1.19, [audit events](/docs/tasks/debug/debug-cluster/audit/) for requests to deprecated APIs include an audit annotation of `"k8s.io/deprecated":"true"`. Administrators can use those audit events to identify specific clients or objects that need to be updated. 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 index 7851a04380..212f66bf37 100644 --- 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 @@ -20,7 +20,7 @@ The paper attempts to _not_ focus on any specific [cloud native project](https:/ When using Kubernetes as a workload orchestrator, some of the security controls this version of the whitepaper recommends are: * [Pod Security Policies](/docs/concepts/security/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 +* [Audit log analysis](/docs/tasks/debug/debug-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 diff --git a/content/en/blog/_posts/2020-12-02-dockershim-faq.md b/content/en/blog/_posts/2020-12-02-dockershim-faq.md index 28eef5b7b9..c0cb2ee83a 100644 --- a/content/en/blog/_posts/2020-12-02-dockershim-faq.md +++ b/content/en/blog/_posts/2020-12-02-dockershim-faq.md @@ -155,7 +155,7 @@ runtime where possible. Another thing to look out for is anything expecting to run for system maintenance or nested inside a container when building images will no longer work. For the -former, you can use the [`crictl`][cr] tool as a drop-in replacement (see [mapping from docker cli to crictl](https://kubernetes.io/docs/tasks/debug-application-cluster/crictl/#mapping-from-docker-cli-to-crictl)) and for the +former, you can use the [`crictl`][cr] tool as a drop-in replacement (see [mapping from docker cli to crictl](https://kubernetes.io/docs/tasks/debug/debug-cluster/crictl/#mapping-from-docker-cli-to-crictl)) and for the latter you can use newer container build options like [img], [buildah], [kaniko], or [buildkit-cli-for-kubectl] that don’t require Docker. diff --git a/content/en/blog/_posts/2020-12-08-kubernetes-release-1.20.md b/content/en/blog/_posts/2020-12-08-kubernetes-release-1.20.md index 8eb382cac1..295c8d7d36 100644 --- a/content/en/blog/_posts/2020-12-08-kubernetes-release-1.20.md +++ b/content/en/blog/_posts/2020-12-08-kubernetes-release-1.20.md @@ -32,7 +32,7 @@ The `kubectl alpha debug` features graduates to beta in 1.20, becoming `kubectl Note that as a new built-in command, `kubectl debug` takes priority over any kubectl plugin named “debug”. You must rename the affected plugin. -Invocations using `kubectl alpha debug` are now deprecated and will be removed in a subsequent release. Update your scripts to use `kubectl debug`. For more information about `kubectl debug`, see [Debugging Running Pods](https://kubernetes.io/docs/tasks/debug-application-cluster/debug-running-pod/). +Invocations using `kubectl alpha debug` are now deprecated and will be removed in a subsequent release. Update your scripts to use `kubectl debug`. For more information about `kubectl debug`, see [Debugging Running Pods](https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/). ### Beta: API Priority and Fairness diff --git a/content/en/blog/_posts/2021-10-05-nsa-cisa-hardening.md b/content/en/blog/_posts/2021-10-05-nsa-cisa-hardening.md index c953a02677..e32d7bcb72 100644 --- a/content/en/blog/_posts/2021-10-05-nsa-cisa-hardening.md +++ b/content/en/blog/_posts/2021-10-05-nsa-cisa-hardening.md @@ -317,7 +317,7 @@ RequestResponse's including metadata and request / response bodies. While helpfu Each organization needs to evaluate their own threat model and build an audit policy that complements or helps troubleshooting incident response. Think -about how someone would attack your organization and what audit trail could identify it. Review more advanced options for tuning audit logs in the official [audit logging documentation](/docs/tasks/debug-application-cluster/audit/#audit-policy). +about how someone would attack your organization and what audit trail could identify it. Review more advanced options for tuning audit logs in the official [audit logging documentation](/docs/tasks/debug/debug-cluster/audit/#audit-policy). It's crucial to tune your audit logs to only include events that meet your threat model. A minimal audit policy that logs everything at `metadata` level can also be a good starting point. Audit logging configurations can also be tested with diff --git a/content/en/blog/_posts/2022-04-28-Increasing-the-security-bar-in-Ingress-NGINX/index.md b/content/en/blog/_posts/2022-04-28-Increasing-the-security-bar-in-Ingress-NGINX/index.md new file mode 100644 index 0000000000..25161b8c96 --- /dev/null +++ b/content/en/blog/_posts/2022-04-28-Increasing-the-security-bar-in-Ingress-NGINX/index.md @@ -0,0 +1,155 @@ +--- +layout: blog +title: 'Increasing the security bar in Ingress-NGINX v1.2.0' +date: 2022-04-28 +slug: ingress-nginx-1-2-0 +--- + +**Authors:** Ricardo Katz (VMware), James Strong (Chainguard) + +The [Ingress](/docs/concepts/services-networking/ingress/) may be one of the most targeted components +of Kubernetes. An Ingress typically defines an HTTP reverse proxy, exposed to the Internet, containing +multiple websites, and with some privileged access to Kubernetes API (such as to read Secrets relating to +TLS certificates and their private keys). + +While it is a risky component in your architecture, it is still the most popular way to properly expose your services. + +Ingress-NGINX has been part of security assessments that figured out we have a big problem: we don't +do all proper sanitization before turning the configuration into an `nginx.conf` file, which may lead to information +disclosure risks. + +While we understand this risk and the real need to fix this, it's not an easy process to do, so we took another approach to reduce (but not remove!) this risk in the current (v1.2.0) release. + +## Meet Ingress NGINX v1.2.0 and the chrooted NGINX process + +One of the main challenges is that Ingress-NGINX runs the web proxy server (NGINX) alongside the Ingress +controller (the component that has access to Kubernetes API that and that creates the `nginx.conf` file). + +So, NGINX does have the same access to the filesystem of the controller (and Kubernetes service account token, and other configurations from the container). While splitting those components is our end goal, the project needed a fast response; that lead us to the idea of using `chroot()`. + +Let's take a look into what an Ingress-NGINX container looked like before this change: + +![Ingress NGINX pre chroot](ingress-pre-chroot.png) + +As we can see, the same container (not the Pod, the container!) that provides HTTP Proxy is the one that watches Ingress objects and writes the Container Volume + +Now, meet the new architecture: + +![Ingress NGINX post chroot](ingress-post-chroot.png) + +What does all of this mean? A basic summary is: that we are isolating the NGINX service as a container inside the +controller container. + +While this is not strictly true, to understand what was done here, it's good to understand how +Linux containers (and underlying mechanisms such as kernel namespaces) work. +You can read about cgroups in the Kubernetes glossary: [`cgroup`](https://kubernetes.io/docs/reference/glossary/?fundamental=true#term-cgroup) and learn more about cgroups interact with namespaces in the NGINX project article +[What Are Namespaces and cgroups, and How Do They Work?](https://www.nginx.com/blog/what-are-namespaces-cgroups-how-do-they-work/). +(As you read that, bear in mind that Linux kernel namespaces are a different thing from +[Kubernetes namespaces](/docs/concepts/overview/working-with-objects/namespaces/)). + +## Skip the talk, what do I need to use this new approach? + +While this increases the security, we made this feature an opt-in in this release so you can have +time to make the right adjustments in your environment(s). This new feature is only available from +release v1.2.0 of the Ingress-NGINX controller. + +There are two required changes in your deployments to use this feature: +* Append the suffix "-chroot" to the container image name. For example: `gcr.io/k8s-staging-ingress-nginx/controller-chroot:v1.2.0` +* In your Pod template for the Ingress controller, find where you add the capability `NET_BIND_SERVICE` and add the capability `SYS_CHROOT`. After you edit the manifest, you'll see a snippet like: + +```yaml +capabilities: + drop: + - ALL + add: + - NET_BIND_SERVICE + - SYS_CHROOT +``` + +If you deploy the controller using the official Helm chart then change the following setting in +`values.yaml`: + +```yaml +controller: + image: + chroot: true +``` + +Ingress controllers are normally set up cluster-wide (the IngressClass API is cluster scoped). If you manage the +Ingress-NGINX controller but you're not the overall cluster operator, then check with your cluster admin about +whether you can use the `SYS_CHROOT` capability, **before** you enable it in your deployment. + +## OK, but how does this increase the security of my Ingress controller? + +Take the following configuration snippet and imagine, for some reason it was added to your `nginx.conf`: +``` +location /randomthing/ { + alias /; + autoindex on; +} +``` + +If you deploy this configuration, someone can call `http://website.example/randomthing` and get some listing (and access) to the whole filesystem of the Ingress controller. + +Now, can you spot the difference between chrooted and non chrooted Nginx on the listings below? + +| Without extra `chroot()` | With extra `chroot()` | +|----------------------------|--------| +| `bin` | `bin` | +| `dev` | `dev` | +| `etc` | `etc` | +| `home` | | +| `lib` | `lib` | +| `media` | | +| `mnt` | | +| `opt` | `opt` | +| `proc` | `proc` | +| `root` | | +| `run` | `run` | +| `sbin` | | +| `srv` | | +| `sys` | | +| `tmp` | `tmp` | +| `usr` | `usr` | +| `var` | `var` | +| `dbg` | | +| `nginx-ingress-controller` | | +| `wait-shutdown` | | + +The one in left side is not chrooted. So NGINX has full access to the filesystem. The one in right side is chrooted, so a new filesystem with only the required files to make NGINX work is created. + +## What about other security improvements in this release? + +We know that the new `chroot()` mechanism helps address some portion of the risk, but still, someone +can try to inject commands to read, for example, the `nginx.conf` file and extract sensitive information. + +So, another change in this release (this is opt-out!) is the _deep inspector_. +We know that some directives or regular expressions may be dangerous to NGINX, so the deep inspector +checks all fields from an Ingress object (during its reconciliation, and also with a +[validating admission webhook](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook)) +to verify if any fields contains these dangerous directives. + +The ingress controller already does this for annotations, and our goal is to move this existing validation to happen inside +deep inspection as part of a future release. + +You can take a look into the existing rules in [https://github.com/kubernetes/ingress-nginx/blob/main/internal/ingress/inspector/rules.go](https://github.com/kubernetes/ingress-nginx/blob/main/internal/ingress/inspector/rules.go). + +Due to the nature of inspecting and matching all strings within relevant Ingress objects, this new feature may consume a bit more CPU. You can disable it by running the ingress controller with the command line argument `--deep-inspect=false`. + +## What's next? + +This is not our final goal. Our final goal is to split the control plane and the data plane processes. +In fact, doing so will help us also achieve a [Gateway](https://gateway-api.sigs.k8s.io/) API implementation, +as we may have a different controller as soon as it "knows" what to provide to the data plane +(we need some help here!!) + +Some other projects in Kubernetes already take this approach +(like [KPNG](​​https://github.com/kubernetes-sigs/kpng), the proposed replacement for `kube-proxy`), +and we plan to align with them and get the same experience for Ingress-NGINX. + +## Further reading + +If you want to take a look into how chrooting was done in Ingress NGINX, take a look +into [https://github.com/kubernetes/ingress-nginx/pull/8337](https://github.com/kubernetes/ingress-nginx/pull/8337) +The release v1.2.0 containing all the changes can be found at +[https://github.com/kubernetes/ingress-nginx/releases/tag/controller-v1.2.0](https://github.com/kubernetes/ingress-nginx/releases/tag/controller-v1.2.0) diff --git a/content/en/blog/_posts/2022-04-28-Increasing-the-security-bar-in-Ingress-NGINX/ingress-post-chroot.png b/content/en/blog/_posts/2022-04-28-Increasing-the-security-bar-in-Ingress-NGINX/ingress-post-chroot.png new file mode 100644 index 0000000000..d5d588a3bb Binary files /dev/null and b/content/en/blog/_posts/2022-04-28-Increasing-the-security-bar-in-Ingress-NGINX/ingress-post-chroot.png differ diff --git a/content/en/blog/_posts/2022-04-28-Increasing-the-security-bar-in-Ingress-NGINX/ingress-pre-chroot.png b/content/en/blog/_posts/2022-04-28-Increasing-the-security-bar-in-Ingress-NGINX/ingress-pre-chroot.png new file mode 100644 index 0000000000..38c7d54a55 Binary files /dev/null and b/content/en/blog/_posts/2022-04-28-Increasing-the-security-bar-in-Ingress-NGINX/ingress-pre-chroot.png differ diff --git a/content/en/blog/_posts/2022-04-29-kubernetes-1.23-release-interview.md b/content/en/blog/_posts/2022-04-29-kubernetes-1.23-release-interview.md new file mode 100644 index 0000000000..c2532638d0 --- /dev/null +++ b/content/en/blog/_posts/2022-04-29-kubernetes-1.23-release-interview.md @@ -0,0 +1,319 @@ +--- +layout: blog +title: "Frontiers, fsGroups and frogs: the Kubernetes 1.23 release interview" +date: 2022-04-29 +--- + +**Author**: Craig Box (Google) + +One of the highlights of hosting the weekly [Kubernetes Podcast from Google](https://kubernetespodcast.com/) is talking to the release managers for each new Kubernetes version. The release team is constantly refreshing. Many working their way from small documentation fixes, step up to shadow roles, and then eventually lead a release. + +As we prepare for the 1.24 release next week, [in accordance with long-standing tradition](https://www.google.com/search?q=%22release+interview%22+site%3Akubernetes.io%2Fblog), I'm pleased to bring you a look back at the story of 1.23. The release was led by [Rey Lejano](https://twitter.com/reylejano), a Field Engineer at SUSE. [I spoke to Rey](https://kubernetespodcast.com/episode/167-kubernetes-1.23/) in December, as he was awaiting the birth of his first child. + +Make sure you [subscribe, wherever you get your podcasts](https://kubernetespodcast.com/subscribe/), so you hear all our stories from the Cloud Native community, including the story of 1.24 next week. + +*This transcript has been lightly edited and condensed for clarity.* + +--- + +**CRAIG BOX: I'd like to start with what is, of course, on top of everyone's mind at the moment. Let's talk African clawed frogs!** + +REY LEJANO: [CHUCKLES] Oh, you mean [Xenopus lavis](https://en.wikipedia.org/wiki/African_clawed_frog), the scientific name for the African clawed frog? + +**CRAIG BOX: Of course.** + +REY LEJANO: Not many people know, but my background and my degree is actually in microbiology, from the University of California Davis. I did some research for about four years in biochemistry, in a biochemistry lab, and I [do have a research paper published](https://www.sciencedirect.com/science/article/pii/). It's actually on glycoproteins, particularly something called "cortical granule lectin". We used frogs, because they generate lots and lots of eggs, from which we can extract the protein. That protein prevents polyspermy. When the sperm goes into the egg, the egg releases a glycoprotein, cortical granule lectin, to the membrane, and prevents any other sperm from going inside the egg. + +**CRAIG BOX: Were you able to take anything from the testing that we did on frogs and generalize that to higher-order mammals, perhaps?** + +REY LEJANO: Yes. Since mammals also have cortical granule lectin, we were able to analyze both the convergence and the evolutionary pattern, not just from multiple species of frogs, but also into mammals as well. + +**CRAIG BOX: Now, there's a couple of different threads to unravel here. When you were young, what led you into the fields of biology, and perhaps more the technical side of it?** + +REY LEJANO: I think it was mostly from family, since I do have a family history in the medical field that goes back generations. So I kind of felt like that was the natural path going into college. + +**CRAIG BOX: Now, of course, you're working in a more abstract tech field. What led you out of microbiology?** + +REY LEJANO: [CHUCKLES] Well, I've always been interested in tech. Taught myself a little programming when I was younger, before high school, did some web dev stuff. Just kind of got burnt out being in a lab. I was literally in the basement. I had a great opportunity to join a consultancy that specialized in [ITIL](https://www.axelos.com/certifications/itil-service-management/what-is-itil). I actually started off with application performance management, went into monitoring, went into operation management and also ITIL, which is aligning your IT asset management and service managements with business services. Did that for a good number of years, actually. + +**CRAIG BOX: It's very interesting, as people describe the things that they went through and perhaps the technologies that they worked on, you can pretty much pinpoint how old they might be. There's a lot of people who come into tech these days that have never heard of ITIL. They have no idea what it is. It's basically just SRE with more process.** + +REY LEJANO: Yes, absolutely. It's not very cloud native. [CHUCKLES] + +**CRAIG BOX: Not at all.** + +REY LEJANO: You don't really hear about it in the cloud native landscape. Definitely, you can tell someone's been in the field for a little bit, if they specialize or have worked with ITIL before. + +**CRAIG BOX: You mentioned that you wanted to get out of the basement. That is quite often where people put the programmers. Did they just give you a bit of light in the new basement?** + +REY LEJANO: [LAUGHS] They did give us much better lighting. Able to get some vitamin D sometimes, as well. + +**CRAIG BOX: To wrap up the discussion about your previous career — over the course of the last year, with all of the things that have happened in the world, I could imagine that microbiology skills may be more in demand than perhaps they were when you studied them?** + +REY LEJANO: Oh, absolutely. I could definitely see a big increase of numbers of people going into the field. Also, reading what's going on with the world currently kind of brings back all the education I've learned in the past, as well. + +**CRAIG BOX: Do you keep in touch with people you went through school with?** + +REY LEJANO: Just some close friends, but not in the microbiology field. + +**CRAIG BOX: One thing that I think will probably happen as a result of the pandemic is a renewed interest in some of these STEM fields. It will be interesting to see what impact that has on society at large.** + +REY LEJANO: Yeah. I think that'll be great. + +**CRAIG BOX: You mentioned working at a consultancy doing IT management, application performance monitoring, and so on. When did Kubernetes come into your professional life?** + +REY LEJANO: One of my good friends at the company I worked at, left in mid-2015. He went on to a company that was pretty heavily into Docker. He taught me a little bit. I did my first "docker run" around 2015, maybe 2016. Then, one of the applications we were using for the ITIL framework was containerized around 2018 or so, also in Kubernetes. At that time, it was pretty buggy. That was my initial introduction to Kubernetes and containerised applications. + +Then I left that company, and I actually joined my friend over at [RX-M](https://rx-m.com/), which is a cloud native consultancy and training firm. They specialize in Docker and Kubernetes. I was able to get my feet wet. I got my CKD, got my CKA as well. And they were really, really great at encouraging us to learn more about Kubernetes and also to be involved in the community. + +**CRAIG BOX: You will have seen, then, the life cycle of people adopting Kubernetes and containerization at large, through your own initial journey and then through helping customers. How would you characterize how that journey has changed from the early days to perhaps today?** + +REY LEJANO: I think the early days, there was a lot of questions of, why do I have to containerize? Why can't I just stay with virtual machines? + +**CRAIG BOX: It's a line item on your CV.** + +REY LEJANO: [CHUCKLES] It is. And nowadays, I think people know the value of using containers, of orchestrating containers with Kubernetes. I don't want to say "jumping on the bandwagon", but it's become the de-facto standard to orchestrate containers. + +**CRAIG BOX: It's not something that a consultancy needs to go out and pitch to customers that they should be doing. They're just taking it as, that will happen, and starting a bit further down the path, perhaps.** + +REY LEJANO: Absolutely. + +**CRAIG BOX: Working at a consultancy like that, how much time do you get to work on improving process, perhaps for multiple customers, and then looking at how you can upstream that work, versus paid work that you do for just an individual customer at a time?** + +REY LEJANO: Back then, it would vary. They helped me introduce myself, and I learned a lot about the cloud native landscape and Kubernetes itself. They helped educate me as to how the cloud native landscape, and the tools around it, can be used together. My boss at that company, Randy, he actually encouraged us to start contributing upstream, and encouraged me to join the release team. He just said, this is a great opportunity. Definitely helped me with starting with the contributions early on. + +**CRAIG BOX: Was the release team the way that you got involved with upstream Kubernetes contribution?** + +REY LEJANO: Actually, no. My first contribution was with SIG Docs. I met Taylor Dolezal — he was the release team lead for 1.19, but he is involved with SIG Docs as well. I met him at KubeCon 2019, I sat at his table during a luncheon. I remember Paris Pittman was hosting this luncheon at the Marriott. Taylor says he was involved with SIG Docs. He encouraged me to join. I started joining into meetings, started doing a few drive-by PRs. That's what we call them — drive-by — little typo fixes. Then did a little bit more, started to send better or higher quality pull requests, and also reviewing PRs. + +**CRAIG BOX: When did you first formally take your release team role?** + +REY LEJANO: That was in [1.18](https://github.com/kubernetes/sig-release/blob/master/releases/release-1.18/release_team.md), in December. My boss at the time encouraged me to apply. I did, was lucky enough to get accepted for the release notes shadow. Then from there, stayed in with release notes for a few cycles, then went into Docs, naturally then led Docs, then went to Enhancements, and now I'm the release lead for 1.23. + +**CRAIG BOX: I don't know that a lot of people think about what goes into a good release note. What would you say does?** + +REY LEJANO: [CHUCKLES] You have to tell the end user what has changed or what effect that they might see in the release notes. It doesn't have to be highly technical. It could just be a few lines, and just saying what has changed, what they have to do if they have to do anything as well. + +**CRAIG BOX: As you moved through the process of shadowing, how did you learn from the people who were leading those roles?** + +REY LEJANO: I said this a few times when I was the release lead for this cycle. You get out of the release team as much as you put in, or it directly aligns to how much you put in. I learned a lot. I went into the release team having that mindset of learning from the role leads, learning from the other shadows, as well. That's actually a saying that my first role lead told me. I still carry it to heart, and that was back in 1.18. That was Eddie, in the very first meeting we had, and I still carry it to heart. + +**CRAIG BOX: You, of course, were [the release lead for 1.23](https://github.com/kubernetes/sig-release/tree/master/releases/release-1.23). First of all, congratulations on the release.** + +REY LEJANO: Thank you very much. + +**CRAIG BOX: The theme for this release is [The Next Frontier](https://kubernetes.io/blog/2021/12/07/kubernetes-1-23-release-announcement/). Tell me the story of how we came to the theme and then the logo.** + +REY LEJANO: The Next Frontier represents a few things. It not only represents the next enhancements in this release, but Kubernetes itself also has a history of Star Trek references. The original codename for Kubernetes was Project Seven, a reference to Seven of Nine, originally from Star Trek Voyager. Also the seven spokes in the helm in the logo of Kubernetes as well. And, of course, Borg, the predecessor to Kubernetes. + +The Next Frontier continues that Star Trek reference. It's a fusion of two titles in the Star Trek universe. One is [Star Trek V, the Final Frontier](https://en.wikipedia.org/wiki/Star_Trek_V:_The_Final_Frontier), and the Star Trek: The Next Generation. + +**CRAIG BOX: Do you have any opinion on the fact that Star Trek V was an odd-numbered movie, and they are [canonically referred to as being lesser than the even-numbered ones](https://screenrant.com/star-trek-movies-odd-number-curse-explained/)?** + +REY LEJANO: I can't say, because I am such a sci-fi nerd that I love all of them even though they're bad. Even the post-Next Generation movies, after the series, I still liked all of them, even though I know some weren't that great. + +**CRAIG BOX: Am I right in remembering that Star Trek V was the one directed by William Shatner?** + +REY LEJANO: Yes, that is correct. + +**CRAIG BOX: I think that says it all.** + +REY LEJANO: [CHUCKLES] Yes. + +**CRAIG BOX: Now, I understand that the theme comes from a part of the [SIG Release charter](https://github.com/kubernetes/community/blob/master/sig-release/charter.md)?** + +REY LEJANO: Yes. There's a line in the SIG Release charter, "ensure there is a consistent group of community members in place to support the release process across time." With the release team, we have new shadows that join every single release cycle. With this, we're growing with this community. We're growing the release team members. We're growing SIG Release. We're growing the Kubernetes community itself. For a lot of people, this is their first time contributing to open source, so that's why I say it's their new open source frontier. + +**CRAIG BOX: And the logo is obviously very Star Trek-inspired. It sort of surprised me that it took that long for someone to go this route.** + +REY LEJANO: I was very surprised as well. I had to relearn Adobe Illustrator to create the logo. + +**CRAIG BOX: This your own work, is it?** + +REY LEJANO: This is my own work. + +**CRAIG BOX: It's very nice.** + +REY LEJANO: Thank you very much. Funny, the galaxy actually took me the longest time versus the ship. Took me a few days to get that correct. I'm always fine-tuning it, so there might be a final change when this is actually released. + +**CRAIG BOX: No frontier is ever truly final.** + +REY LEJANO: True, very true. + +**CRAIG BOX: Moving now from the theme of the release to the substance, perhaps, what is new in 1.23?** + +REY LEJANO: We have 47 enhancements. I'm going to run through most of the stable ones, if not all of them, some of the key Beta ones, and a few of the Alpha enhancements for 1.23. + +One of the key enhancements is [dual-stack IPv4/IPv6](https://github.com/kubernetes/enhancements/issues/563), which went GA in 1.23. + +Some background info: dual-stack was introduced as Alpha in 1.15. You probably saw a keynote at KubeCon 2019. Back then, the way dual-stack worked was that you needed two services — you needed a service per IP family. You would need a service for IPv4 and a service for IPv6. It was refactored in 1.20. In 1.21, it was in Beta; clusters were enabled to be dual-stack by default. + +And then in 1.23 we did remove the IPv6 dual-stack feature flag. It's not mandatory to use dual-stack. It's actually not "default" still. The pods, the services still default to single-stack. There are some requirements to be able to use dual-stack. The nodes have to be routable on IPv4 and IPv6 network interfaces. You need a CNI plugin that supports dual-stack. The pods themselves have to be configured to be dual-stack. And the services need the ipFamilyPolicy field to specify prefer dual-stack, or require dual-stack. + +**CRAIG BOX: This sounds like there's an implication in this that v4 is still required. Do you see a world where we can actually move to v6-only clusters?** + +REY LEJANO: I think we'll be talking about IPv4 and IPv6 for many, many years to come. I remember a long time ago, they kept saying "it's going to be all IPv6", and that was decades ago. + +**CRAIG BOX: I think I may have mentioned on the show before, but there was [a meeting in London that Vint Cerf attended](https://www.youtube.com/watch?v=AEaJtZVimqs), and he gave a public presentation at the time to say, now is the time of v6. And that was 10 years ago at least. It's still not the time of v6, and my desktop still doesn't have Linux on it. One day.** + +REY LEJANO: [LAUGHS] In my opinion, that's one of the big key features that went stable for 1.23. + +One of the other highlights of 1.23 is [pod security admission going to Beta](/blog/2021/12/09/pod-security-admission-beta/). I know this feature is going to Beta, but I highlight this because as some people might know, PodSecurityPolicy, which was deprecated in 1.21, is targeted to be removed in 1.25. Pod security admission replaces pod security policy. It's an admission controller. It evaluates the pods against a predefined set of pod security standards to either admit or deny the pod for running. + +There's three levels of pod security standards. Privileged, that's totally open. Baseline, known privileges escalations are minimized. Or Restricted, which is hardened. And you could set pod security standards either to run in three modes, which is enforce: reject any pods that are in violation; to audit: pods are allowed to be created, but the violations are recorded; or warn: it will send a warning message to the user, and the pod is allowed. + +**CRAIG BOX: You mentioned there that PodSecurityPolicy is due to be deprecated in two releases' time. Are we lining up these features so that pod security admission will be GA at that time?** + +REY LEJANO: Yes. Absolutely. I'll talk about that for another feature in a little bit as well. There's also another feature that went to GA. It was an API that went to GA, and therefore the Beta API is now deprecated. I'll talk about that a little bit. + +**CRAIG BOX: All right. Let's talk about what's next on the list.** + +REY LEJANO: Let's move on to more stable enhancements. One is the [TTL controller](https://github.com/kubernetes/enhancements/issues/592). This cleans up jobs and pods after the jobs are finished. There is a TTL timer that starts when the job or pod is finished. This TTL controller watches all the jobs, and ttlSecondsAfterFinished needs to be set. The controller will see if the ttlSecondsAfterFinished, combined with the last transition time, if it's greater than now. If it is, then it will delete the job and the pods of that job. + +**CRAIG BOX: Loosely, it could be called a garbage collector?** + +REY LEJANO: Yes. Garbage collector for pods and jobs, or jobs and pods. + +**CRAIG BOX: If Kubernetes is truly becoming a programming language, it of course has to have a garbage collector implemented.** + +REY LEJANO: Yeah. There's another one, too, coming in Alpha. [CHUCKLES] + +**CRAIG BOX: Tell me about that.** + +REY LEJANO: That one is coming in in Alpha. It's actually one of my favorite features, because there's only a few that I'm going to highlight today. [PVCs for StafeulSet will be cleaned up](https://github.com/kubernetes/enhancements/issues/1847). It will auto-delete PVCs created by StatefulSets, when you delete that StatefulSet. + +**CRAIG BOX: What's next on our tour of stable features?** + +REY LEJANO: Next one is, [skip volume ownership change goes to stable](https://github.com/kubernetes/enhancements/issues/695). This is from SIG Storage. There are times when you're running a stateful application, like many databases, they're sensitive to permission bits changing underneath. Currently, when a volume is bind mounted inside the container, the permissions of that volume will change recursively. It might take a really long time. + +Now, there's a field, the fsGroupChangePolicy, which allows you, as a user, to tell Kubernetes how you want the permission and ownership change for that volume to happen. You can set it to always, to always change permissions, or just on mismatch, to only do it when the permission ownership changes at the top level is different from what is expected. + +**CRAIG BOX: It does feel like a lot of these enhancements came from a very particular use case where someone said, "hey, this didn't work for me and I've plumbed in a feature that works with exactly the thing I need to have".** + +REY LEJANO: Absolutely. People create issues for these, then create Kubernetes enhancement proposals, and then get targeted for releases. + +**CRAIG BOX: Another GA feature in this release — ephemeral volumes.** + +REY LEJANO: We've always been able to use empty dir for ephemeral volumes, but now we could actually have [ephemeral inline volumes](https://github.com/kubernetes/enhancements/issues/1698), meaning that you could take your standard CSI driver and be able to use ephemeral volumes with it. + +**CRAIG BOX: And, a long time coming, [CronJobs](https://github.com/kubernetes/enhancements/issues/19).** + +REY LEJANO: CronJobs is a funny one, because it was stable before 1.23. For 1.23, it was still tracked,but it was just cleaning up some of the old controller. With CronJobs, there's a v2 controller. What was cleaned up in 1.23 is just the old v1 controller. + +**CRAIG BOX: Were there any other duplications or major cleanups of note in this release?** + +REY LEJANO: Yeah. There were a few you might see in the major themes. One's a little tricky, around FlexVolumes. This is one of the efforts from SIG Storage. They have an effort to migrate in-tree plugins to CSI drivers. This is a little tricky, because FlexVolumes were actually deprecated in November 2020. We're [formally announcing it in 1.23](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md#kubernetes-volume-plugin-faq-for-storage-vendors). + +**CRAIG BOX: FlexVolumes, in my mind, predate CSI as a concept. So it's about time to get rid of them.** + +REY LEJANO: Yes, it is. There's another deprecation, just some [klog specific flags](https://kubernetes.io/docs/concepts/cluster-administration/system-logs/#klog), but other than that, there are no other big deprecations in 1.23. + +**CRAIG BOX: The buzzword of the last KubeCon, and in some ways the theme of the last 12 months, has been secure software supply chain. What work is Kubernetes doing to improve in this area?** + +REY LEJANO: For 1.23, Kubernetes is now SLSA compliant at Level 1, which means that provenance attestation files that describe the staging and release phases of the release process are satisfactory for the SLSA framework. + +**CRAIG BOX: What needs to happen to step up to further levels?** + +REY LEJANO: Level 1 means a few things — that the build is scripted; that the provenance is available, meaning that the artifacts are verified and they're handed over from one phase to the next; and describes how the artifact is produced. Level 2 means that the source is version-controlled, which it is, provenance is authenticated, provenance is service-generated, and there is a build service. There are four levels of SLSA compliance. + +**CRAIG BOX: It does seem like the levels were largely influenced by what it takes to build a big, secure project like this. It doesn't seem like it will take a lot of extra work to move up to verifiable provenance, for example. There's probably just a few lines of script required to meet many of those requirements.** + +REY LEJANO: Absolutely. I feel like we're almost there; we'll see what will come out of 1.24. And I do want to give a big shout-out to SIG Release and Release Engineering, primarily to Adolfo García Veytia, who is aka Puerco on GitHub and on Slack. He's been driving this forward. + +**CRAIG BOX: You've mentioned some APIs that are being graduated in time to replace their deprecated version. Tell me about the new HPA API.** + +REY LEJANO: The [horizontal pod autoscaler v2 API](https://github.com/kubernetes/enhancements/issues/2702), is now stable, which means that the v2beta2 API is deprecated. Just for everyone's knowledge, the v1 API is not being deprecated. The difference is that v2 adds support for multiple and custom metrics to be used for HPA. + +**CRAIG BOX: There's also now a facility to validate my CRDs with an expression language.** + +REY LEJANO: Yeah. You can use the [Common Expression Language, or CEL](https://github.com/google/cel-spec), to validate your CRDs, so you no longer need to use webhooks. This also makes the CRDs more self-contained and declarative, because the rules are now kept within the CRD object definition. + +**CRAIG BOX: What new features, perhaps coming in Alpha or Beta, have taken your interest?** + +REY LEJANO: Aside from pod security policies, I really love [ephemeral containers](https://github.com/kubernetes/enhancements/issues/277) supporting kubectl debug. It launches an ephemeral container and a running pod, shares those pod namespaces, and you can do all your troubleshooting with just running kubectl debug. + +**CRAIG BOX: There's also been some interesting changes in the way that events are handled with kubectl.** + +REY LEJANO: Yeah. kubectl events has always had some issues, like how things weren't sorted. [kubectl events improved](https://github.com/kubernetes/enhancements/issues/1440) that so now you can do `--watch`, and it will also sort with the `--watch` option as well. That is something new. You can actually combine fields and custom columns. And also, you can list events in the timeline with doing the last N number of minutes. And you can also sort events using other criteria as well. + +**CRAIG BOX: You are a field engineer at SUSE. Are there any things that are coming in that your individual customers that you deal with are looking out for?** + +REY LEJANO: More of what I look out for to help the customers. + +**CRAIG BOX: Right.** + +REY LEJANO: I really love kubectl events. Really love the PVCs being cleaned up with StatefulSets. Most of it's for selfish reasons that it will improve troubleshooting efforts. [CHUCKLES] + +**CRAIG BOX: I have always hoped that a release team lead would say to me, "yes, I have selfish reasons. And I finally got something I wanted in."** + +REY LEJANO: [LAUGHS] + +**CRAIG BOX: Perhaps I should run to be release team lead, just so I can finally get init containers fixed once and for all.** + +REY LEJANO: Oh, init containers, I've been looking for that for a while. I've actually created animated GIFs on how init containers will be run with that Kubernetes enhancement proposal, but it's halted currently. + +**CRAIG BOX: One day.** + +REY LEJANO: One day. Maybe I shouldn't stay halted. + +**CRAIG BOX: You mentioned there are obviously the things you look out for. Are there any things that are coming down the line, perhaps Alpha features or maybe even just proposals you've seen lately, that you're personally really looking forward to seeing which way they go?** + +REY LEJANO: Yeah. Oone is a very interesting one, it affects the whole community, so it's not just for personal reasons. As you may have known, Dockershim is deprecated. And we did release a blog that it will be removed in 1.24. + +**CRAIG BOX: Scared a bunch of people.** + +REY LEJANO: Scared a bunch of people. From a survey, we saw that a lot of people are still using Docker and Dockershim. One of the enhancements for 1.23 is, [kubelet CRI goes to Beta](https://github.com/kubernetes/enhancements/issues/2040). This promotes the CRI API, which is required. This had to be in Beta for Dockershim to be removed in 1.24. + +**CRAIG BOX: Now, in the last release team lead interview, [we spoke with Savitha Raghunathan](https://kubernetespodcast.com/episode/157-kubernetes-1.22/), and she talked about what she would advise you as her successor. It was to look out for the mental health of the team members. How were you able to take that advice on board?** + +REY LEJANO: That was great advice from Savitha. A few things I've made note of with each release team meeting. After each release team meeting, I stop the recording, because we do record all the meetings and post them on YouTube. And I open up the floor to anyone who wants to say anything that's not recorded, that's not going to be on the agenda. Also, I tell people not to work on weekends. I broke this rule once, but other than that, I told people it could wait. Just be mindful of your mental health. + +**CRAIG BOX: It's just been announced that [James Laverack from Jetstack](https://twitter.com/JamesLaverack/status/1466834312993644551) will be the release team lead for 1.24. James and I shared an interesting Mexican dinner at the last KubeCon in San Diego.** + +REY LEJANO: Oh, nice. I didn't know you knew James. + +**CRAIG BOX: The British tech scene. We're a very small world. What will your advice to James be?** + +REY LEJANO: What I would tell James for 1.24 is use teachable moments in the release team meetings. When you're a shadow for the first time, it's very daunting. It's very difficult, because you don't know the repos. You don't know the release process. Everyone around you seems like they know the release process, and very familiar with what the release process is. But as a first-time shadow, you don't know all the vernacular for the community. I just advise to use teachable moments. Take a few minutes in the release team meetings to make it a little easier for new shadows to ramp up and to be familiar with the release process. + +**CRAIG BOX: Has there been major evolution in the process in the time that you've been involved? Or do you think that it's effectively doing what it needs to do?** + +REY LEJANO: It's always evolving. I remember my first time in release notes, 1.18, we said that our goal was to automate and program our way out so that we don't have a release notes team anymore. That's changed [CHUCKLES] quite a bit. Although there's been significant advancements in the release notes process by Adolfo and also James, they've created a subcommand in krel to generate release notes. + +But nowadays, all their release notes are richer. Still not there at the automation process yet. Every release cycle, there is something a little bit different. For this release cycle, we had a production readiness review deadline. It was a soft deadline. A production readiness review is a review by several people in the community. It's actually been required since 1.21, and it ensures that the enhancements are observable, scalable, supportable, and it's safe to operate in production, and could also be disabled or rolled back. In 1.23, we had a deadline to have the production readiness review completed by a specific date. + +**CRAIG BOX: How have you found the change of schedule to three releases per year rather than four?** + +REY LEJANO: Moving to three releases a year from four, in my opinion, has been an improvement, because we support the last three releases, and now we can actually support the last releases in a calendar year instead of having 9 months out of 12 months of the year. + +**CRAIG BOX: The next event on the calendar is a [Kubernetes contributor celebration](https://www.kubernetes.dev/events/kcc2021/) starting next Monday. What can we expect from that event?** + +REY LEJANO: This is our second time running this virtual event. It's a virtual celebration to recognize the whole community and all of our accomplishments of the year, and also contributors. There's a number of events during this week of celebration. It starts the week of December 13. + +There's events like the Kubernetes Contributor Awards, where SIGs honor and recognize the hard work of the community and contributors. There's also a DevOps party game as well. There is a cloud native bake-off. I do highly suggest people to go to [kubernetes.dev/celebration](https://www.kubernetes.dev/events/past-events/2021/kcc2021/) to learn more. + +**CRAIG BOX: How exactly does one judge a virtual bake-off?** + +REY LEJANO: That I don't know. [CHUCKLES] + +**CRAIG BOX: I tasted my scones. I think they're the best. I rate them 10 out of 10.** + +REY LEJANO: Yeah. That is very difficult to do virtually. I would have to say, probably what the dish is, how closely it is tied with Kubernetes or open source or to CNCF. There's a few judges. I know Josh Berkus and Rin Oliver are a few of the judges running the bake-off. + +**CRAIG BOX: Yes. We spoke with Josh about his love of the kitchen, and so he seems like a perfect fit for that role.** + +REY LEJANO: He is. + +**CRAIG BOX: Finally, your wife and yourself are expecting your first child in January. Have you had a production readiness review for that?** + +REY LEJANO: I think we failed that review. [CHUCKLES] + +**CRAIG BOX: There's still time.** + +REY LEJANO: We are working on refactoring. We're going to refactor a little bit in December, and `--apply` again. + +--- + +_[Rey Lejano](https://twitter.com/reylejano) is a field engineer at SUSE, by way of Rancher Labs, and was the release team lead for Kubernetes 1.23. He is now also a co-chair for SIG Docs. His son Liam is now 3 and a half months old._ + +_You can find the [Kubernetes Podcast from Google](http://www.kubernetespodcast.com/) at [@KubernetesPod](https://twitter.com/KubernetesPod) on Twitter, and you can [subscribe](https://kubernetespodcast.com/subscribe/) so you never miss an episode._ diff --git a/content/en/blog/_posts/2022-05-06-storage-capacity-GA/index.md b/content/en/blog/_posts/2022-05-06-storage-capacity-GA/index.md new file mode 100644 index 0000000000..35d6838f51 --- /dev/null +++ b/content/en/blog/_posts/2022-05-06-storage-capacity-GA/index.md @@ -0,0 +1,79 @@ +--- +layout: blog +title: "Storage Capacity Tracking reaches GA in Kubernetes 1.24" +date: 2022-05-06 +slug: storage-capacity-ga +--- + + **Authors:** Patrick Ohly (Intel) + +The v1.24 release of Kubernetes brings [storage capacity](/docs/concepts/storage/storage-capacity/) +tracking as a generally available feature. + +## Problems we have solved + +As explained in more detail in the [previous blog post about this +feature](/blog/2021/04/14/local-storage-features-go-beta/), storage capacity +tracking allows a CSI driver to publish information about remaining +capacity. The kube-scheduler then uses that information to pick suitable nodes +for a Pod when that Pod has volumes that still need to be provisioned. + +Without this information, a Pod may get stuck without ever being scheduled onto +a suitable node because kube-scheduler has to choose blindly and always ends up +picking a node for which the volume cannot be provisioned because the +underlying storage system managed by the CSI driver does not have sufficient +capacity left. + +Because CSI drivers publish storage capacity information that gets used at a +later time when it might not be up-to-date anymore, it can still happen that a +node is picked that doesn't work out after all. Volume provisioning recovers +from that by informing the scheduler that it needs to try again with a +different node. + +[Load +tests](https://github.com/kubernetes-csi/csi-driver-host-path/blob/master/docs/storage-capacity-tracking.md) +that were done again for promotion to GA confirmed that all storage in a +cluster can be consumed by Pods with storage capacity tracking whereas Pods got +stuck without it. + +## Problems we have *not* solved + +Recovery from a failed volume provisioning attempt has one known limitation: if a Pod +uses two volumes and only one of them could be provisioned, then all future +scheduling decisions are limited by the already provisioned volume. If that +volume is local to a node and the other volume cannot be provisioned there, the +Pod is stuck. This problem pre-dates storage capacity tracking and while the +additional information makes it less likely to occur, it cannot be avoided in +all cases, except of course by only using one volume per Pod. + +An idea for solving this was proposed in a [KEP +draft](https://github.com/kubernetes/enhancements/pull/1703): volumes that were +provisioned and haven't been used yet cannot have any valuable data and +therefore could be freed and provisioned again elsewhere. SIG Storage is +looking for interested developers who want to continue working on this. + +Also not solved is support in Cluster Autoscaler for Pods with volumes. For CSI +drivers with storage capacity tracking, a prototype was developed and discussed +in [a PR](https://github.com/kubernetes/autoscaler/pull/3887). It was meant to +work with arbitrary CSI drivers, but that flexibility made it hard to configure +and slowed down scale up operations: because autoscaler was unable to simulate +volume provisioning, it only scaled the cluster by one node at a time, which +was seen as insufficient. + +Therefore that PR was not merged and a different approach with tighter coupling +between autoscaler and CSI driver will be needed. For this a better +understanding is needed about which local storage CSI drivers are used in +combination with cluster autoscaling. Should this lead to a new KEP, then users +will have to try out an implementation in practice before it can move to beta +or GA. So please reach out to SIG Storage if you have an interest in this +topic. + +## Acknowledgements + +Thanks a lot to the members of the community who have contributed to this +feature or given feedback including members of [SIG +Scheduling](https://github.com/kubernetes/community/tree/master/sig-scheduling), +[SIG +Autoscaling](https://github.com/kubernetes/community/tree/master/sig-autoscaling), +and of course [SIG +Storage](https://github.com/kubernetes/community/tree/master/sig-storage)! diff --git a/content/en/blog/_posts/2022-05-16-volume-populators-beta.md b/content/en/blog/_posts/2022-05-16-volume-populators-beta.md new file mode 100644 index 0000000000..8585014f7a --- /dev/null +++ b/content/en/blog/_posts/2022-05-16-volume-populators-beta.md @@ -0,0 +1,162 @@ +--- +layout: blog +title: "Kubernetes 1.24: Volume Populators Graduate to Beta" +date: 2022-05-16 +slug: volume-populators-beta +--- + +**Author:** +Ben Swartzlander (NetApp) + +The volume populators feature is now two releases old and entering beta! The `AnyVolumeDataSouce` feature +gate defaults to enabled in Kubernetes v1.24, which means that users can specify any custom resource +as the data source of a PVC. + +An [earlier blog article](/blog/2021/08/30-volume-populators-redesigned/) detailed how the +volume populators feature works. In short, a cluster administrator can install a CRD and +associated populator controller in the cluster, and any user who can create instances of +the CR can create pre-populated volumes by taking advantage of the populator. + +Multiple populators can be installed side by side for different purposes. The SIG storage +community is already seeing some implementations in public, and more prototypes should +appear soon. + +Cluster administrations are **strongly encouraged** to install the +volume-data-source-validator controller and associated `VolumePopulator` CRD before installing +any populators so that users can get feedback about invalid PVC data sources. + +## New Features + +The [lib-volume-populator](https://github.com/kubernetes-csi/lib-volume-populator) library +on which populators are built now includes metrics to help operators monitor and detect +problems. This library is now beta and latest release is v1.0.1. + +The [volume data source validator](https://github.com/kubernetes-csi/volume-data-source-validator) +controller also has metrics support added, and is in beta. The `VolumePopulator` CRD is +beta and the latest release is v1.0.1. + +## Trying it out + +To see how this works, you can install the sample "hello" populator and try it +out. + +First install the volume-data-source-validator controller. + +```shell +kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/volume-data-source-validator/v1.0.1/client/config/crd/populator.storage.k8s.io_volumepopulators.yaml +kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/volume-data-source-validator/v1.0.1/deploy/kubernetes/rbac-data-source-validator.yaml +kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/volume-data-source-validator/v1.0.1/deploy/kubernetes/setup-data-source-validator.yaml +``` + +Next install the example populator. + +```shell +kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/lib-volume-populator/v1.0.1/example/hello-populator/crd.yaml +kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/lib-volume-populator/87a47467b86052819e9ad13d15036d65b9a32fbb/example/hello-populator/deploy.yaml +``` + +Your cluster now has a new CustomResourceDefinition that provides a test API named Hello. +Create an instance of the `Hello` custom resource, with some text: + +```yaml +apiVersion: hello.example.com/v1alpha1 +kind: Hello +metadata: + name: example-hello +spec: + fileName: example.txt + fileContents: Hello, world! +``` + +Create a PVC that refers to that CR as its data source. + +```yaml +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: example-pvc +spec: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 10Mi + dataSourceRef: + apiGroup: hello.example.com + kind: Hello + name: example-hello + volumeMode: Filesystem +``` + +Next, run a Job that reads the file in the PVC. + +```yaml +apiVersion: batch/v1 +kind: Job +metadata: + name: example-job +spec: + template: + spec: + containers: + - name: example-container + image: busybox:latest + command: + - cat + - /mnt/example.txt + volumeMounts: + - name: vol + mountPath: /mnt + restartPolicy: Never + volumes: + - name: vol + persistentVolumeClaim: + claimName: example-pvc +``` + +Wait for the job to complete (including all of its dependencies). + +```shell +kubectl wait --for=condition=Complete job/example-job +``` + +And last examine the log from the job. + +```shell +kubectl logs job/example-job +``` + +The output should be: + +```terminal +Hello, world! +``` + +Note that the volume already contained a text file with the string contents from +the CR. This is only the simplest example. Actual populators can set up the volume +to contain arbitrary contents. + +## How to write your own volume populator + +Developers interested in writing new poplators are encouraged to use the +[lib-volume-populator](https://github.com/kubernetes-csi/lib-volume-populator) library +and to only supply a small controller wrapper around the library, and a pod image +capable of attaching to volumes and writing the appropriate data to the volume. + +Individual populators can be extremely generic such that they work with every type +of PVC, or they can do vendor specific things to rapidly fill a volume with data +if the volume was provisioned by a specific CSI driver from the same vendor, for +example, by communicating directly with the storage for that volume. + +## How can I learn more? + +The enhancement proposal, +[Volume Populators](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/1495-volume-populators), includes lots of detail about the history and technical implementation +of this feature. + +[Volume populators and data sources](/docs/concepts/storage/persistent-volumes/#volume-populators-and-data-sources), within the documentation topic about persistent volumes, +explains how to use this feature in your cluster. + +Please get involved by joining the Kubernetes storage SIG to help us enhance this +feature. There are a lot of good ideas already and we'd be thrilled to have more! + diff --git a/content/en/docs/concepts/cluster-administration/_index.md b/content/en/docs/concepts/cluster-administration/_index.md index 7d5aec5078..7e5827a6f7 100644 --- a/content/en/docs/concepts/cluster-administration/_index.md +++ b/content/en/docs/concepts/cluster-administration/_index.md @@ -59,7 +59,7 @@ Before choosing a guide, here are some considerations: * [Using Sysctls in a Kubernetes Cluster](/docs/tasks/administer-cluster/sysctl-cluster/) describes to an administrator how to use the `sysctl` command-line tool to set kernel parameters . -* [Auditing](/docs/tasks/debug-application-cluster/audit/) describes how to interact with Kubernetes' audit logs. +* [Auditing](/docs/tasks/debug/debug-cluster/audit/) describes how to interact with Kubernetes' audit logs. ### Securing the kubelet * [Control Plane-Node communication](/docs/concepts/architecture/control-plane-node-communication/) diff --git a/content/en/docs/concepts/configuration/manage-resources-containers.md b/content/en/docs/concepts/configuration/manage-resources-containers.md index 575f96f04d..2cb2ee1b7f 100644 --- a/content/en/docs/concepts/configuration/manage-resources-containers.md +++ b/content/en/docs/concepts/configuration/manage-resources-containers.md @@ -47,10 +47,9 @@ or by enforcement (the system prevents the container from ever exceeding the lim runtimes can have different ways to implement the same restrictions. {{< note >}} -If a container specifies its own memory limit, but does not specify a memory request, Kubernetes -automatically assigns a memory request that matches the limit. Similarly, if a container specifies its own -CPU limit, but does not specify a CPU request, Kubernetes automatically assigns a CPU request that matches -the limit. +If you specify a limit for a resource, but do not specify any request, and no admission-time +mechanism has applied a default request for that resource, then Kubernetes copies the limit +you specified and uses it as the requested value for the resource. {{< /note >}} ## Resource types @@ -229,9 +228,9 @@ see the [Troubleshooting](#troubleshooting) section. The kubelet reports the resource usage of a Pod as part of the Pod [`status`](/docs/concepts/overview/working-with-objects/kubernetes-objects/#object-spec-and-status). -If optional [tools for monitoring](/docs/tasks/debug-application-cluster/resource-usage-monitoring/) +If optional [tools for monitoring](/docs/tasks/debug/debug-cluster/resource-usage-monitoring/) are available in your cluster, then Pod resource usage can be retrieved either -from the [Metrics API](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#metrics-api) +from the [Metrics API](/docs/tasks/debug/debug-cluster/resource-metrics-pipeline/#metrics-api) directly or from your monitoring tools. ## Local ephemeral storage diff --git a/content/en/docs/concepts/overview/components.md b/content/en/docs/concepts/overview/components.md index 60433f63e5..387fc157d9 100644 --- a/content/en/docs/concepts/overview/components.md +++ b/content/en/docs/concepts/overview/components.md @@ -114,7 +114,7 @@ Containers started by Kubernetes automatically include this DNS server in their ### Container Resource Monitoring -[Container Resource Monitoring](/docs/tasks/debug-application-cluster/resource-usage-monitoring/) records generic time-series metrics +[Container Resource Monitoring](/docs/tasks/debug/debug-cluster/resource-usage-monitoring/) records generic time-series metrics about containers in a central database, and provides a UI for browsing that data. ### Cluster-level Logging diff --git a/content/en/docs/concepts/security/controlling-access.md b/content/en/docs/concepts/security/controlling-access.md index ff15c1512d..e7ba78e1c4 100644 --- a/content/en/docs/concepts/security/controlling-access.md +++ b/content/en/docs/concepts/security/controlling-access.md @@ -134,7 +134,7 @@ for the corresponding API object, and then written to the object store (shown as Kubernetes auditing provides a security-relevant, chronological set of records documenting the sequence of actions in a cluster. The cluster audits the activities generated by users, by applications that use the Kubernetes API, and by the control plane itself. -For more information, see [Auditing](/docs/tasks/debug-application-cluster/audit/). +For more information, see [Auditing](/docs/tasks/debug/debug-cluster/audit/). ## API server ports and IPs diff --git a/content/en/docs/concepts/security/pod-security-admission.md b/content/en/docs/concepts/security/pod-security-admission.md index 58610081ea..1e452ea6af 100644 --- a/content/en/docs/concepts/security/pod-security-admission.md +++ b/content/en/docs/concepts/security/pod-security-admission.md @@ -86,7 +86,7 @@ takes if a potential violation is detected: Mode | Description :---------|:------------ **enforce** | Policy violations will cause the pod to be rejected. -**audit** | Policy violations will trigger the addition of an audit annotation to the event recorded in the [audit log](/docs/tasks/debug-application-cluster/audit/), but are otherwise allowed. +**audit** | Policy violations will trigger the addition of an audit annotation to the event recorded in the [audit log](/docs/tasks/debug/debug-cluster/audit/), but are otherwise allowed. **warn** | Policy violations will trigger a user-facing warning, but are otherwise allowed. {{< /table >}} diff --git a/content/en/docs/concepts/security/pod-security-policy.md b/content/en/docs/concepts/security/pod-security-policy.md index a8e90040ed..30b0c8bab0 100644 --- a/content/en/docs/concepts/security/pod-security-policy.md +++ b/content/en/docs/concepts/security/pod-security-policy.md @@ -658,8 +658,7 @@ added. Capabilities listed in `RequiredDropCapabilities` must not be included in **DefaultAddCapabilities** - The capabilities which are added to containers by default, in addition to the runtime defaults. See the -[Docker documentation](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities) -for the default list of capabilities when using the Docker runtime. +the documentation for your container runtime for information on working with Linux capabilities. ### SELinux diff --git a/content/en/docs/concepts/storage/storage-classes.md b/content/en/docs/concepts/storage/storage-classes.md index 788f592abe..53ee88a2e7 100644 --- a/content/en/docs/concepts/storage/storage-classes.md +++ b/content/en/docs/concepts/storage/storage-classes.md @@ -49,7 +49,7 @@ metadata: name: standard provisioner: kubernetes.io/aws-ebs parameters: - type: gp3 + type: gp2 reclaimPolicy: Retain allowVolumeExpansion: true mountOptions: @@ -271,9 +271,9 @@ parameters: fsType: ext4 ``` -* `type`: `io1`, `gp2`, `gp3`, `sc1`, `st1`. See +* `type`: `io1`, `gp2`, `sc1`, `st1`. See [AWS docs](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html) - for details. Default: `gp3`. + for details. Default: `gp2`. * `zone` (Deprecated): AWS zone. If neither `zone` nor `zones` is specified, volumes are generally round-robin-ed across all active zones where Kubernetes cluster has a node. `zone` and `zones` parameters must not be used at the same time. diff --git a/content/en/docs/concepts/workloads/pods/ephemeral-containers.md b/content/en/docs/concepts/workloads/pods/ephemeral-containers.md index d32511da28..0a70fedd6f 100644 --- a/content/en/docs/concepts/workloads/pods/ephemeral-containers.md +++ b/content/en/docs/concepts/workloads/pods/ephemeral-containers.md @@ -70,5 +70,5 @@ you can view processes in other containers. ## {{% heading "whatsnext" %}} -* Learn how to [debug pods using ephemeral containers](/docs/tasks/debug-application-cluster/debug-running-pod/#ephemeral-container). +* Learn how to [debug pods using ephemeral containers](/docs/tasks/debug/debug-application/debug-running-pod/#ephemeral-container). diff --git a/content/en/docs/concepts/workloads/pods/init-containers.md b/content/en/docs/concepts/workloads/pods/init-containers.md index 43d23d3a0a..371ef58dac 100644 --- a/content/en/docs/concepts/workloads/pods/init-containers.md +++ b/content/en/docs/concepts/workloads/pods/init-containers.md @@ -332,5 +332,6 @@ Kubernetes, consult the documentation for the version you are using. ## {{% heading "whatsnext" %}} * Read about [creating a Pod that has an init container](/docs/tasks/configure-pod-container/configure-pod-initialization/#create-a-pod-that-has-an-init-container) -* Learn how to [debug init containers](/docs/tasks/debug-application-cluster/debug-init-containers/) +* Learn how to [debug init containers](/docs/tasks/debug/debug-application/debug-init-containers/) + diff --git a/content/en/docs/doc-contributor-tools/linkchecker/README.md b/content/en/docs/doc-contributor-tools/linkchecker/README.md index a575c4d1fe..6d4b714655 100644 --- a/content/en/docs/doc-contributor-tools/linkchecker/README.md +++ b/content/en/docs/doc-contributor-tools/linkchecker/README.md @@ -46,7 +46,7 @@ To run the link checker: 2. Run the following command: ``` - make docker-internal-linkcheck + make container-internal-linkcheck ``` ## Understanding the output diff --git a/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md b/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md index 8d0f9694ce..6f7154cc8a 100644 --- a/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md +++ b/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md @@ -1396,7 +1396,7 @@ monitoring mechanisms help cluster admins to answer questions like: Sometimes it's useful to know which mutating webhook mutated the object in a API request, and what change did the webhook apply. -In v1.16+, kube-apiserver performs [auditing](/docs/tasks/debug-application-cluster/audit/) on each mutating webhook +In v1.16+, kube-apiserver performs [auditing](/docs/tasks/debug/debug-cluster/audit/) on each mutating webhook invocation. Each invocation generates an auditing annotation capturing if a request object is mutated by the invocation, and optionally generates an annotation capturing the applied patch from the webhook admission response. The annotations are set in the audit event for given request on given stage of 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 f0005522d9..8eb23b3a47 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 @@ -607,7 +607,7 @@ Each feature gate is designed for enabling/disabling a specific feature: Docker Engine; no longer available. See [Device Plugins](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) for an alternative. -- `AdvancedAuditing`: Enable [advanced auditing](/docs/tasks/debug-application-cluster/audit/#advanced-audit) +- `AdvancedAuditing`: Enable [advanced auditing](/docs/tasks/debug/debug-cluster/audit/#advanced-audit) - `AffinityInAnnotations`: Enable setting [Pod affinity or anti-affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity). - `AllowExtTrafficLocalEndpoints`: Enable a service to route external requests to node local endpoints. diff --git a/content/en/docs/reference/glossary/dockershim.md b/content/en/docs/reference/glossary/dockershim.md new file mode 100644 index 0000000000..d726679064 --- /dev/null +++ b/content/en/docs/reference/glossary/dockershim.md @@ -0,0 +1,18 @@ +--- +title: Dockershim +id: dockershim +date: 2022-04-15 +full_link: /dockershim +short_description: > + A component of Kubernetes v1.23 and earlier, which allows Kubernetes system components to communicate with Docker Engine. + +aka: +tags: +- fundamental +--- +The dockershim is a component of Kubernetes version 1.23 and earlier. It allows the kubelet +to communicate with {{< glossary_tooltip text="Docker Engine" term_id="docker" >}}. + + + +Starting with version 1.24, dockershim has been removed from Kubernetes. For more information, see [Dockershim FAQ](/dockershim). diff --git a/content/en/docs/reference/glossary/event.md b/content/en/docs/reference/glossary/event.md index e534a91527..23c72302a6 100644 --- a/content/en/docs/reference/glossary/event.md +++ b/content/en/docs/reference/glossary/event.md @@ -21,5 +21,5 @@ or the continued existence of events with that reason. Events should be treated as informative, best-effort, supplemental data. -In Kubernetes, [auditing](/docs/tasks/debug-application-cluster/audit/) generates a different kind of +In Kubernetes, [auditing](/docs/tasks/debug/debug-cluster/audit/) generates a different kind of Event record (API group `audit.k8s.io`). diff --git a/content/en/docs/reference/kubectl/docker-cli-to-kubectl.md b/content/en/docs/reference/kubectl/docker-cli-to-kubectl.md index 9c148702b5..95e2e79c77 100644 --- a/content/en/docs/reference/kubectl/docker-cli-to-kubectl.md +++ b/content/en/docs/reference/kubectl/docker-cli-to-kubectl.md @@ -187,7 +187,7 @@ kubectl exec -ti nginx-app-5jyvm -- /bin/sh # exit ``` -For more information, see [Get a Shell to a Running Container](/docs/tasks/debug-application-cluster/get-shell-running-container/). +For more information, see [Get a Shell to a Running Container](/docs/tasks/debug/debug-application/get-shell-running-container/). ## docker logs diff --git a/content/en/docs/reference/labels-annotations-taints/audit-annotations.md b/content/en/docs/reference/labels-annotations-taints/audit-annotations.md index 682a6aaa8d..4a3d726ce5 100644 --- a/content/en/docs/reference/labels-annotations-taints/audit-annotations.md +++ b/content/en/docs/reference/labels-annotations-taints/audit-annotations.md @@ -11,7 +11,7 @@ namespace. These annotations apply to `Event` object from API group {{< note >}} The following annotations are not used within the Kubernetes API. When you -[enable auditing](/docs/tasks/debug-application-cluster/audit/) in your cluster, +[enable auditing](/docs/tasks/debug/debug-cluster/audit/) in your cluster, audit event data is written using `Event` from API group `audit.k8s.io`. The annotations apply to audit events. Audit events are different from objects in the [Event API](/docs/reference/kubernetes-api/cluster-resources/event-v1/) (API group @@ -64,15 +64,15 @@ Example: `authorization.k8s.io/decision: "forbid"` This annotation indicates whether or not a request was authorized in Kubernetes audit logs. -See [Auditing](/docs/tasks/debug-application-cluster/audit/) for more information. +See [Auditing](/docs/tasks/debug/debug-cluster/audit/) for more information. ## authorization.k8s.io/reason -Example: `authorization.k8s.io/decision: "Human-readable reason for the decision"` +Example: `authorization.k8s.io/reason: "Human-readable reason for the decision"` This annotation gives reason for the [decision](#authorization-k8s-io-decision) in Kubernetes audit logs. -See [Auditing](/docs/tasks/debug-application-cluster/audit/) for more information. +See [Auditing](/docs/tasks/debug/debug-cluster/audit/) for more information. ## missing-san.invalid-cert.kubernetes.io/$hostname diff --git a/content/en/docs/reference/tools/_index.md b/content/en/docs/reference/tools/_index.md index ad10ad1e7c..2ec317bd1f 100644 --- a/content/en/docs/reference/tools/_index.md +++ b/content/en/docs/reference/tools/_index.md @@ -30,9 +30,6 @@ resources itself. [Helm](https://helm.sh/) is a tool for managing packages of pre-configured Kubernetes resources. These packages are known as _Helm charts_. -Helm is a third party managed tool for managing packages of pre-configured -Kubernetes resources, aka Kubernetes charts. - Use Helm to: * Find and use popular software packaged as Kubernetes charts diff --git a/content/en/docs/reference/using-api/deprecation-policy.md b/content/en/docs/reference/using-api/deprecation-policy.md index 49136e6773..9612e1df39 100644 --- a/content/en/docs/reference/using-api/deprecation-policy.md +++ b/content/en/docs/reference/using-api/deprecation-policy.md @@ -286,7 +286,7 @@ behavior get removed. Starting in Kubernetes v1.19, making an API request to a deprecated REST API endpoint: 1. Returns a `Warning` header (as defined in [RFC7234, Section 5.5](https://tools.ietf.org/html/rfc7234#section-5.5)) in the API response. -2. Adds a `"k8s.io/deprecated":"true"` annotation to the [audit event](/docs/tasks/debug-application-cluster/audit/) recorded for the request. +2. Adds a `"k8s.io/deprecated":"true"` annotation to the [audit event](/docs/tasks/debug/debug-cluster/audit/) recorded for the request. 3. Sets an `apiserver_requested_deprecated_apis` gauge metric to `1` in the `kube-apiserver` process. The metric has labels for `group`, `version`, `resource`, `subresource` that can be joined to the `apiserver_request_total` metric, and a `removed_release` label that indicates the diff --git a/content/en/docs/setup/production-environment/_index.md b/content/en/docs/setup/production-environment/_index.md index 1611170ec9..7d8200a6b3 100644 --- a/content/en/docs/setup/production-environment/_index.md +++ b/content/en/docs/setup/production-environment/_index.md @@ -197,7 +197,7 @@ are some virtualization platforms that can be scripted to spin up new nodes based on demand. - *Set up node health checks*: For important workloads, you want to make sure that the nodes and pods running on those nodes are healthy. Using the -[Node Problem Detector](/docs/tasks/debug-application-cluster/monitor-node-health/) +[Node Problem Detector](/docs/tasks/debug/debug-cluster/monitor-node-health/) daemon, you can ensure your nodes are healthy. ## Production user management diff --git a/content/en/docs/setup/production-environment/container-runtimes.md b/content/en/docs/setup/production-environment/container-runtimes.md index 8c5e744502..1f658fa262 100644 --- a/content/en/docs/setup/production-environment/container-runtimes.md +++ b/content/en/docs/setup/production-environment/container-runtimes.md @@ -166,18 +166,14 @@ Use the following commands to install Containerd on your system: 1. Install containerd: Visit - [Getting started with containerd](https://containerd.io/docs/getting-started/#starting-containerd) + [Getting started with containerd](https://github.com/containerd/containerd/blob/main/docs/getting-started.md) and follow the instructions there, up to the point where you have a valid - configuration file (on Linux: `/etc/containerd/config.toml`). + configuration file, config.toml. + On Linux, you can find this file under the path `/etc/containerd/config.toml`. + On Windows, you can find this file under the path `C:\Program Files\containerd\config.toml`. - If you are running Windows, you might want to exclude containerd from Windows Defender Scans - ```powershell - # If excluding containerd from Windows Defender scans, consider how else - # you will make sure that the executable is genuine. - Add-MpPreference -ExclusionProcess "$Env:ProgramFiles\containerd\containerd.exe" - ``` - -For containerd, the CRI socket is `/run/containerd/containerd.sock` by default. +On Linux the default CRI socket for containerd is `/run/containerd/containerd.sock`. +On Windows the default CRI endpoint is `npipe://./pipe/containerd-containerd`. #### Configuring the `systemd` cgroup driver {#containerd-systemd} diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md index cbb659dec4..ac8d89ee3a 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md @@ -93,7 +93,7 @@ This may be caused by a number of problems. The most common are: configure it properly see [Configuring a cgroup driver](/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/). - control plane containers are crashlooping or hanging. You can check this by running `docker ps` and investigating each container by running `docker logs`. For other container runtime see -[Debugging Kubernetes nodes with crictl](/docs/tasks/debug-application-cluster/crictl/). +[Debugging Kubernetes nodes with crictl](/docs/tasks/debug/debug-cluster/crictl/). ## kubeadm blocks when removing managed containers @@ -151,7 +151,7 @@ services](/docs/concepts/services-networking/service/#type-nodeport) or use `Hos ## Pods are not accessible via their Service IP -- Many network add-ons do not yet enable [hairpin mode](/docs/tasks/debug-application-cluster/debug-service/#a-pod-fails-to-reach-itself-via-the-service-ip) +- Many network add-ons do not yet enable [hairpin mode](/docs/tasks/debug/debug-application/debug-service/#a-pod-fails-to-reach-itself-via-the-service-ip) which allows pods to access themselves via their Service IP. This is an issue related to [CNI](https://github.com/containernetworking/cni/issues/476). Please contact the network add-on provider to get the latest status of their support for hairpin mode. diff --git a/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md b/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md index 8e6d6fd816..9c6ab896d7 100644 --- a/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md +++ b/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md @@ -547,7 +547,7 @@ None of the Pod [`securityContext`](/docs/reference/kubernetes-api/workload-reso ### Node problem detector The node problem detector (see -[Monitor Node Health](/docs/tasks/debug-application-cluster/monitor-node-health/)) +[Monitor Node Health](/docs/tasks/debug/debug-cluster/monitor-node-health/)) is not compatible with Windows. ### Pause container @@ -625,7 +625,7 @@ The Kubernetes [version-skew policy](/docs/setup/release/version-skew-policy/) a ## Getting help and troubleshooting {#troubleshooting} Your main source of help for troubleshooting your Kubernetes cluster should start -with the [Troubleshooting](/docs/tasks/debug-application-cluster/troubleshooting/) +with the [Troubleshooting](/docs/tasks/debug/debug-cluster/) page. Some additional, Windows-specific troubleshooting help is included diff --git a/content/en/docs/tasks/administer-cluster/dns-debugging-resolution.md b/content/en/docs/tasks/administer-cluster/dns-debugging-resolution.md index e9dd545955..55030539cb 100644 --- a/content/en/docs/tasks/administer-cluster/dns-debugging-resolution.md +++ b/content/en/docs/tasks/administer-cluster/dns-debugging-resolution.md @@ -176,7 +176,7 @@ The service name is `kube-dns` for both CoreDNS and kube-dns deployments. If you have created the Service or in the case it should be created by default but it does not appear, see -[debugging Services](/docs/tasks/debug-application-cluster/debug-service/) for +[debugging Services](/docs/tasks/debug/debug-application/debug-service/) for more information. ### Are DNS endpoints exposed? @@ -193,7 +193,7 @@ kube-dns 10.180.3.17:53,10.180.3.17:53 1h ``` If you do not see the endpoints, see the endpoints section in the -[debugging Services](/docs/tasks/debug-application-cluster/debug-service/) documentation. +[debugging Services](/docs/tasks/debug/debug-application/debug-service/) documentation. For additional Kubernetes DNS examples, see the [cluster-dns examples](https://github.com/kubernetes/examples/tree/master/staging/cluster-dns) diff --git a/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md b/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md index 36e5a1a00c..8040e1185f 100644 --- a/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md +++ b/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md @@ -11,7 +11,7 @@ weight: 20 This page explains how to upgrade a Kubernetes cluster created with kubeadm from version {{< skew currentVersionAddMinor -1 >}}.x to version {{< skew currentVersion >}}.x, and from version {{< skew currentVersion >}}.x to {{< skew currentVersion >}}.y (where `y > x`). Skipping MINOR versions -when upgrading is unsupported. +when upgrading is unsupported. For more details, please visit [Version Skew Policy](https://kubernetes.io/releases/version-skew-policy/). To see information about upgrading clusters created using older versions of kubeadm, please refer to following pages instead: diff --git a/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents.md b/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents.md index 13219bfd6d..3835057c91 100644 --- a/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents.md +++ b/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents.md @@ -13,7 +13,7 @@ Kubernetes' support for direct integration with Docker Engine is deprecated, and ## Telemetry and security agents Within a Kubernetes cluster there are a few different ways to run telemetry or security agents. -Some agents have a direct dependency on Docker Engine when they as DaemonSets or +Some agents have a direct dependency on Docker Engine when they run as DaemonSets or directly on nodes. ### Why do some telemetry agents communicate with Docker Engine? diff --git a/content/en/docs/tasks/administer-cluster/securing-a-cluster.md b/content/en/docs/tasks/administer-cluster/securing-a-cluster.md index cc463a86c6..f125fd6cf2 100644 --- a/content/en/docs/tasks/administer-cluster/securing-a-cluster.md +++ b/content/en/docs/tasks/administer-cluster/securing-a-cluster.md @@ -210,7 +210,7 @@ access to a subset of the keyspace is strongly recommended. ### Enable audit logging -The [audit logger](/docs/tasks/debug-application-cluster/audit/) is a beta feature that records actions taken by the +The [audit logger](/docs/tasks/debug/debug-cluster/audit/) is a beta feature that records actions taken by the API for later analysis in the event of a compromise. It is recommended to enable audit logging and archive the audit file on a secure server. diff --git a/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index 5128e611ef..b26baabe9e 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -59,7 +59,7 @@ and restarts it. When the container starts, it executes this command: ```shell -/bin/sh -c "touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600" +/bin/sh -c "touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600" ``` For the first 30 seconds of the container's life, there is a `/tmp/healthy` file. diff --git a/content/en/docs/tasks/configure-pod-container/configure-pod-initialization.md b/content/en/docs/tasks/configure-pod-container/configure-pod-initialization.md index cca96f2b79..b7681a8118 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-pod-initialization.md +++ b/content/en/docs/tasks/configure-pod-container/configure-pod-initialization.md @@ -85,7 +85,7 @@ The output shows that nginx is serving the web page that was written by the init [communicating between Containers running in the same Pod](/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/). * Learn more about [Init Containers](/docs/concepts/workloads/pods/init-containers/). * Learn more about [Volumes](/docs/concepts/storage/volumes/). -* Learn more about [Debugging Init Containers](/docs/tasks/debug-application-cluster/debug-init-containers/) +* Learn more about [Debugging Init Containers](/docs/tasks/debug/debug-application/debug-init-containers/) diff --git a/content/en/docs/tasks/configure-pod-container/security-context.md b/content/en/docs/tasks/configure-pod-container/security-context.md index bd7e05a18f..91b914bc54 100644 --- a/content/en/docs/tasks/configure-pod-container/security-context.md +++ b/content/en/docs/tasks/configure-pod-container/security-context.md @@ -399,7 +399,7 @@ in the `securityContext` section of your Pod or Container manifest. The [SeccompProfile](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#seccompprofile-v1-core) object consisting of `type` and `localhostProfile`. Valid options for `type` include `RuntimeDefault`, `Unconfined`, and -`Localhost`. `localhostProfile` must only be set set if `type: Localhost`. It +`Localhost`. `localhostProfile` must only be set if `type: Localhost`. It indicates the path of the pre-configured profile on the node, relative to the kubelet's configured Seccomp profile location (configured with the `--root-dir` flag). diff --git a/content/en/docs/tasks/debug/debug-cluster/local-debugging.md b/content/en/docs/tasks/debug/debug-cluster/local-debugging.md index a4cad902db..f556deaa39 100644 --- a/content/en/docs/tasks/debug/debug-cluster/local-debugging.md +++ b/content/en/docs/tasks/debug/debug-cluster/local-debugging.md @@ -7,7 +7,7 @@ content_type: task {{% thirdparty-content %}} -Kubernetes applications usually consist of multiple, separate services, each running in its own container. Developing and debugging these services on a remote Kubernetes cluster can be cumbersome, requiring you to [get a shell on a running container](/docs/tasks/debug-application-cluster/get-shell-running-container/) in order to run debugging tools. +Kubernetes applications usually consist of multiple, separate services, each running in its own container. Developing and debugging these services on a remote Kubernetes cluster can be cumbersome, requiring you to [get a shell on a running container](/docs/tasks/debug/debug-application/get-shell-running-container/) in order to run debugging tools. `telepresence` is a tool to ease the process of developing and debugging services locally while proxying the service to a remote Kubernetes cluster. Using `telepresence` allows you to use custom tools, such as a debugger and IDE, for a local service and provides the service full access to ConfigMap, secrets, and the services running on the remote cluster. diff --git a/content/en/docs/tasks/debug/debug-cluster/resource-metrics-pipeline.md b/content/en/docs/tasks/debug/debug-cluster/resource-metrics-pipeline.md index ce74c03fb6..62bcc6dfba 100644 --- a/content/en/docs/tasks/debug/debug-cluster/resource-metrics-pipeline.md +++ b/content/en/docs/tasks/debug/debug-cluster/resource-metrics-pipeline.md @@ -28,7 +28,7 @@ The Metrics API, and the metrics pipeline that it enables, only offers the minim CPU and memory metrics to enable automatic scaling using HPA and / or VPA. If you would like to provide a more complete set of metrics, you can complement the simpler Metrics API by deploying a second -[metrics pipeline](/docs/tasks/debug-application-cluster/resource-usage-monitoring/#full-metrics-pipeline) +[metrics pipeline](/docs/tasks/debug/debug-cluster/resource-usage-monitoring/#full-metrics-pipeline) that uses the _Custom Metrics API_. {{< /note >}} diff --git a/content/en/docs/tasks/debug/debug-cluster/resource-usage-monitoring.md b/content/en/docs/tasks/debug/debug-cluster/resource-usage-monitoring.md index 9f7c4fbd3c..b02d6ab31a 100644 --- a/content/en/docs/tasks/debug/debug-cluster/resource-usage-monitoring.md +++ b/content/en/docs/tasks/debug/debug-cluster/resource-usage-monitoring.md @@ -65,8 +65,8 @@ Full metrics pipeline projects that are not part of the CNCF are outside the sco Learn about additional debugging tools, including: * [Logging](/docs/concepts/cluster-administration/logging/) -* [Monitoring](/docs/tasks/debug-application-cluster/resource-usage-monitoring/) -* [Getting into containers via `exec`](/docs/tasks/debug-application-cluster/applications/get-shell-running-container/) +* [Monitoring](/docs/tasks/debug/debug-cluster/resource-usage-monitoring/) +* [Getting into containers via `exec`](/docs/tasks/debug/debug-application/get-shell-running-container/) * [Connecting to containers via proxies](/docs/tasks/extend-kubernetes/http-proxy-access-api/) * [Connecting to containers via port forwarding](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/) -* [Inspect Kubernetes node with crictl](/docs/tasks/debug-application-cluster/monitoring/crictl/) +* [Inspect Kubernetes node with crictl](/docs/tasks/debug/debug-cluster/crictl/) diff --git a/content/en/docs/tasks/inject-data-application/define-command-argument-container.md b/content/en/docs/tasks/inject-data-application/define-command-argument-container.md index 0de57b864f..36368abd3f 100644 --- a/content/en/docs/tasks/inject-data-application/define-command-argument-container.md +++ b/content/en/docs/tasks/inject-data-application/define-command-argument-container.md @@ -114,5 +114,5 @@ args: ["-c", "while true; do echo hello; sleep 10;done"] * Learn more about [configuring pods and containers](/docs/tasks/). -* Learn more about [running commands in a container](/docs/tasks/debug-application-cluster/get-shell-running-container/). +* Learn more about [running commands in a container](/docs/tasks/debug/debug-application/get-shell-running-container/). * See [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core). diff --git a/content/en/docs/tasks/run-application/force-delete-stateful-set-pod.md b/content/en/docs/tasks/run-application/force-delete-stateful-set-pod.md index 0001f4c9f4..a4a145f5b4 100644 --- a/content/en/docs/tasks/run-application/force-delete-stateful-set-pod.md +++ b/content/en/docs/tasks/run-application/force-delete-stateful-set-pod.md @@ -90,6 +90,6 @@ Always perform force deletion of StatefulSet Pods carefully and with complete kn ## {{% heading "whatsnext" %}} -Learn more about [debugging a StatefulSet](/docs/tasks/debug-application-cluster/debug-stateful-set/). +Learn more about [debugging a StatefulSet](/docs/tasks/debug/debug-application/debug-statefulset/). diff --git a/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md b/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md index 0039254f7e..e9a446287c 100644 --- a/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md +++ b/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md @@ -90,7 +90,7 @@ The common use for HorizontalPodAutoscaler is to configure it to fetch metrics f (`metrics.k8s.io`, `custom.metrics.k8s.io`, or `external.metrics.k8s.io`). The `metrics.k8s.io` API is usually provided by an add-on named Metrics Server, which needs to be launched separately. For more information about resource metrics, see -[Metrics Server](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#metrics-server). +[Metrics Server](/docs/tasks/debug/debug-cluster/resource-metrics-pipeline/#metrics-server). [Support for metrics APIs](#support-for-metrics-apis) explains the stability guarantees and support status for these different APIs. diff --git a/content/en/docs/tasks/run-application/run-replicated-stateful-application.md b/content/en/docs/tasks/run-application/run-replicated-stateful-application.md index e98830b9e3..03da601a48 100644 --- a/content/en/docs/tasks/run-application/run-replicated-stateful-application.md +++ b/content/en/docs/tasks/run-application/run-replicated-stateful-application.md @@ -532,7 +532,7 @@ kubectl delete pvc data-mysql-4 ## {{% heading "whatsnext" %}} * Learn more about [scaling a StatefulSet](/docs/tasks/run-application/scale-stateful-set/). -* Learn more about [debugging a StatefulSet](/docs/tasks/debug-application-cluster/debug-stateful-set/). +* Learn more about [debugging a StatefulSet](/docs/tasks/debug/debug-application/debug-statefulset/). * Learn more about [deleting a StatefulSet](/docs/tasks/run-application/delete-stateful-set/). * Learn more about [force deleting StatefulSet Pods](/docs/tasks/run-application/force-delete-stateful-set-pod/). * Look in the [Helm Charts repository](https://artifacthub.io/) diff --git a/content/en/docs/tasks/tls/manual-rotation-of-ca-certificates.md b/content/en/docs/tasks/tls/manual-rotation-of-ca-certificates.md index e56322cbec..4ea543aef8 100644 --- a/content/en/docs/tasks/tls/manual-rotation-of-ca-certificates.md +++ b/content/en/docs/tasks/tls/manual-rotation-of-ca-certificates.md @@ -143,7 +143,7 @@ Configurations with a single API server will experience unavailability while the 1. Validate the logs from control plane components, along with the kubelet and the kube-proxy are not throwing any tls errors, see - [looking at the logs](/docs/tasks/debug-application-cluster/debug-cluster/#looking-at-logs). + [looking at the logs](/docs/tasks/debug/debug-cluster/#looking-at-logs). 1. Validate logs from any aggregated api servers and pods using in-cluster config. diff --git a/content/en/docs/tutorials/stateful-application/cassandra.md b/content/en/docs/tutorials/stateful-application/cassandra.md index ffbf65286b..b6b656b3f5 100644 --- a/content/en/docs/tutorials/stateful-application/cassandra.md +++ b/content/en/docs/tutorials/stateful-application/cassandra.md @@ -93,7 +93,7 @@ cassandra ClusterIP None 9042/TCP 45s ``` If you don't see a Service named `cassandra`, that means creation failed. Read -[Debug Services](/docs/tasks/debug-application-cluster/debug-service/) +[Debug Services](/docs/tasks/debug/debug-application/debug-service/) for help troubleshooting common issues. ## Using a StatefulSet to create a Cassandra ring diff --git a/content/en/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md b/content/en/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md index d22d7df5ca..480316a09c 100644 --- a/content/en/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md +++ b/content/en/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md @@ -236,10 +236,10 @@ Do not leave your WordPress installation on this page. If another user finds it, ## {{% heading "whatsnext" %}} -* Learn more about [Introspection and Debugging](/docs/tasks/debug-application-cluster/debug-application-introspection/) +* Learn more about [Introspection and Debugging](/docs/tasks/debug/debug-application) * Learn more about [Jobs](/docs/concepts/workloads/controllers/job/) * Learn more about [Port Forwarding](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/) -* Learn how to [Get a Shell to a Container](/docs/tasks/debug-application-cluster/get-shell-running-container/) +* Learn how to [Get a Shell to a Container](/docs/tasks/debug/debug-application/get-shell-running-container/) diff --git a/content/en/examples/pods/probe/exec-liveness.yaml b/content/en/examples/pods/probe/exec-liveness.yaml index 07bf75f85c..6a9c9b3213 100644 --- a/content/en/examples/pods/probe/exec-liveness.yaml +++ b/content/en/examples/pods/probe/exec-liveness.yaml @@ -11,7 +11,7 @@ spec: args: - /bin/sh - -c - - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600 + - touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600 livenessProbe: exec: command: diff --git a/content/en/examples/policy/restricted-psp.yaml b/content/en/examples/policy/restricted-psp.yaml index 0837c5a3ce..4c9ae156d1 100644 --- a/content/en/examples/policy/restricted-psp.yaml +++ b/content/en/examples/policy/restricted-psp.yaml @@ -3,6 +3,7 @@ kind: PodSecurityPolicy metadata: name: restricted annotations: + # docker/default identifies a profile for seccomp, but it is not particularly tied to the Docker runtime seccomp.security.alpha.kubernetes.io/allowedProfileNames: 'docker/default,runtime/default' apparmor.security.beta.kubernetes.io/allowedProfileNames: 'runtime/default' apparmor.security.beta.kubernetes.io/defaultProfileName: 'runtime/default' diff --git a/content/fr/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/fr/docs/concepts/workloads/pods/pod-topology-spread-constraints.md index d1cd1f41e1..bd11052a9d 100644 --- a/content/fr/docs/concepts/workloads/pods/pod-topology-spread-constraints.md +++ b/content/fr/docs/concepts/workloads/pods/pod-topology-spread-constraints.md @@ -205,6 +205,7 @@ apiVersion: kubescheduler.config.k8s.io/v1alpha2 kind: KubeSchedulerConfiguration profiles: + - schedulerName: default-scheduler - pluginConfig: - name: PodTopologySpread args: diff --git a/content/id/docs/concepts/storage/storage-classes.md b/content/id/docs/concepts/storage/storage-classes.md index a3684755af..e5f3265768 100644 --- a/content/id/docs/concepts/storage/storage-classes.md +++ b/content/id/docs/concepts/storage/storage-classes.md @@ -89,7 +89,7 @@ Kamu tidak dibatasi untuk hanya menggunakan _provisioner_ internal yang disediak pada list yang tersedia (yang memiliki nama dengan prefix "kubernetes.io" dan didistribusikan bersamaan dengan Kubernetes). Kamu juga dapat menjalankan dan mendefinisikan _provisioner_ eksternal yang merupakan program independen selama -program tersebut menerapkan [spesifikasi](https://git.k8s.io/community/contributors/design-proposals/storage/volume-provisioning.md) +program tersebut menerapkan [spesifikasi](https://github.com/kubernetes/design-proposals-archive/blob/main/storage/volume-provisioning.md) yang didefinisikan oleh Kubernetes. Penulis dari _provisioner_ eksternal Kubernetes memiliki kuasa penuh akan tempat dimana kode sumber yang mereka tulis, bagaimana mekanisme penyediaan (_provisioning_) dilakukan, serta bagaimana hal tersebut dapat dijalankan, diff --git a/content/ko/docs/concepts/overview/working-with-objects/namespaces.md b/content/ko/docs/concepts/overview/working-with-objects/namespaces.md index 2a78361e08..f97d0858de 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/namespaces.md +++ b/content/ko/docs/concepts/overview/working-with-objects/namespaces.md @@ -61,7 +61,6 @@ kube-system Active 1d * `default` 다른 네임스페이스가 없는 오브젝트를 위한 기본 네임스페이스 * `kube-system` 쿠버네티스 시스템에서 생성한 오브젝트를 위한 네임스페이스 * `kube-public` 이 네임스페이스는 자동으로 생성되며 모든 사용자(인증되지 않은 사용자 포함)가 읽기 권한으로 접근할 수 있다. 이 네임스페이스는 주로 전체 클러스터 중에 공개적으로 드러나서 읽을 수 있는 리소스를 위해 예약되어 있다. 이 네임스페이스의 공개적인 성격은 단지 관례이지 요구 사항은 아니다. - * `kube-node-lease` 클러스터가 스케일링될 때 노드 하트비트의 성능을 향상시키는 각 노드와 관련된 리스(lease) 오브젝트에 대한 네임스페이스 * `kube-node-lease` 이 네임스페이스는 각 노드와 연관된 [리스](/docs/reference/kubernetes-api/cluster-resources/lease-v1/) 오브젝트를 갖는다. 노드 리스는 kubelet이 [하트비트](/ko/docs/concepts/architecture/nodes/#하트비트)를 보내서 컨트롤 플레인이 노드의 장애를 탐지할 수 있게 한다. diff --git a/content/pt-br/docs/concepts/overview/components.md b/content/pt-br/docs/concepts/overview/components.md index b03946c4ae..892be1a922 100644 --- a/content/pt-br/docs/concepts/overview/components.md +++ b/content/pt-br/docs/concepts/overview/components.md @@ -59,7 +59,7 @@ O cloud-controller-manager executa apenas controladores que são específicos pa Se você estiver executando o Kubernetes em suas próprias instalações ou em um ambiente de aprendizagem dentro de seu próprio PC, o cluster não possui um gerenciador de controlador de nuvem. -Tal como acontece com o kube-controller-manager, o cloud-controller-manager combina vários ciclos de controle logicamente independentes em um binário único que você executa como um processo único. Você pode escalar horizontalmente (exectuar mais de uma cópia) para melhorar o desempenho ou para auxiliar na tolerância a falhas. +Tal como acontece com o kube-controller-manager, o cloud-controller-manager combina vários ciclos de controle logicamente independentes em um binário único que você executa como um processo único. Você pode escalar horizontalmente (executar mais de uma cópia) para melhorar o desempenho ou para auxiliar na tolerância a falhas. Os seguintes controladores podem ter dependências de provedor de nuvem: diff --git a/content/pt-br/docs/reference/glossary/annotation.md b/content/pt-br/docs/reference/glossary/annotation.md new file mode 100644 index 0000000000..5e3ca07b31 --- /dev/null +++ b/content/pt-br/docs/reference/glossary/annotation.md @@ -0,0 +1,18 @@ +--- +title: Anotação +id: annotation +date: 2018-04-12 +full_link: /docs/concepts/overview/working-with-objects/annotations +short_description: > + Um par de chave-valor (key-value) é usado para anexar metadados arbitrários não identificáveis a objetos. + +aka: +tags: +- fundamental +--- + Um par de chave-valor (key-value) é usado para anexar metadados arbitrários não identificáveis a objetos. + + + +Os metadados em uma anotação podem ser pequenos ou grandes, estruturados ou não estruturados, e podem incluir caracteres não permitidos pelos {{< glossary_tooltip text="rótulos" term_id="label" >}}. Clientes como ferramentas e bibliotecas podem recuperar esses metadados. + diff --git a/content/ru/docs/concepts/cluster-administration/addons.md b/content/ru/docs/concepts/cluster-administration/addons.md index 7e93ef82b2..5c6d6446b6 100644 --- a/content/ru/docs/concepts/cluster-administration/addons.md +++ b/content/ru/docs/concepts/cluster-administration/addons.md @@ -29,7 +29,7 @@ content_type: concept * [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin) - это подключаемый модуль контроллера CNI на основе OVN для обеспечения облачной цепочки сервисных функций (SFC), несколько наложенных сетей OVN, динамического создания подсети, динамического создания виртуальных сетей, сети поставщика VLAN, сети прямого поставщика и подключаемого к другим Multi Сетевые плагины, идеально подходящие для облачных рабочих нагрузок на периферии в сети с несколькими кластерами. * [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) плагин для контейнера (NCP) обеспечивающий интеграцию между VMware NSX-T и контейнерами оркестраторов, таких как Kubernetes, а так же интеграцию между NSX-T и контейнеров на основе платформы CaaS/PaaS, таких как Pivotal Container Service (PKS) и OpenShift. * [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) - эта платформа SDN, которая обеспечивает сетевое взаимодействие на основе политик между Kubernetes подами и не Kubernetes окружением, с отображением и мониторингом безопасности. -* [Romana](https://romana.io) - это сетевое решение уровня 3 для сетей подов, которое также поддерживает [NetworkPolicy API](/docs/concepts/services-networking/network-policies/). Подробности установки Kubeadm доступны [здесь](https://github.com/romana/romana/tree/master/containerize). +* [Romana](https://github.com/romana/romana) - это сетевое решение уровня 3 для сетей подов, которое также поддерживает [NetworkPolicy API](/docs/concepts/services-networking/network-policies/). Подробности установки Kubeadm доступны [здесь](https://github.com/romana/romana/tree/master/containerize). * [Weave Net](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/) предоставляет сеть и обеспечивает сетевую политику, будет работать на обеих сторонах сетевого раздела и не требует внешней базы данных. ## Обнаружение служб diff --git a/content/zh/blog/_posts/2018-10-01-health-checking-grpc.md b/content/zh/blog/_posts/2018-10-01-health-checking-grpc.md index f80633cf8a..98cf437a2b 100644 --- a/content/zh/blog/_posts/2018-10-01-health-checking-grpc.md +++ b/content/zh/blog/_posts/2018-10-01-health-checking-grpc.md @@ -16,6 +16,15 @@ date: 2018-10-01 ---> **作者**： [Ahmet Alp Balkan](https://twitter.com/ahmetb) (Google) + +**更新（2021 年 12 月）：** “Kubernetes 从 v1.23 开始具有内置 gRPC 健康探测。 +了解更多信息，请参阅[配置存活探针、就绪探针和启动探针](/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-grpc-liveness-probe)。 +本文最初是为有关实现相同任务的外部工具所写。” + 请注意，作为新的内置命令，`kubectl debug` 优先于任何名为 “debug” 的 kubectl 插件。你必须重命名受影响的插件。 - -`kubectl alpha debug` 现在不推荐使用，并将在后续版本中删除。更新你的脚本以使用 `kubectl debug`。 有关更多信息 `kubectl debug`，请参阅[调试正在运行的 Pod]((https://kubernetes.io/zh/docs/tasks/debug-application-cluster/debug-running-pod/)。 + +`kubectl alpha debug` 现在不推荐使用，并将在后续版本中删除。更新你的脚本以使用 `kubectl debug`。 有关更多信息 `kubectl debug`，请参阅[调试正在运行的 Pod]((https://kubernetes.io/zh/docs/tasks/debug/debug-application/debug-running-pod/)。 ### 测试版：API 优先级和公平性 {#beta-api-priority-and-fairness) diff --git a/content/zh/blog/_posts/2022-02-17-updated-dockershim-faq.md b/content/zh/blog/_posts/2022-02-17-updated-dockershim-faq.md index 8400012b61..61f3860602 100644 --- a/content/zh/blog/_posts/2022-02-17-updated-dockershim-faq.md +++ b/content/zh/blog/_posts/2022-02-17-updated-dockershim-faq.md @@ -1,12 +1,14 @@ --- layout: blog title: "更新：弃用 Dockershim 的常见问题" +linkTitle: "弃用 Dockershim 的常见问题" date: 2022-02-17 slug: dockershim-faq --- 另外还有一个需要关注的点，那就是当创建镜像时，系统维护或嵌入容器方面的任务将无法工作。 对于前者，可以用 [`crictl`](https://github.com/kubernetes-sigs/cri-tools) 工具作为临时替代方案 -(参阅[从 docker cli 到 crictl 的映射](/zh/docs/tasks/debug-application-cluster/crictl/#mapping-from-docker-cli-to-crictl))。 +(参阅[从 docker cli 到 crictl 的映射](/zh/docs/tasks/debug/debug-cluster/crictl/#mapping-from-docker-cli-to-crictl))。 对于后者，可以用新的容器创建选项，例如 [img](https://github.com/genuinetools/img)、 [buildah](https://github.com/containers/buildah)、 @@ -335,10 +337,10 @@ options are available as you migrate things over. 有关如何在 Kubernetes 中使用 containerd 和 CRI-O 的说明， -请参阅 [Kubernetes 相关文档](/docs/setup/production-environment/container-runtimes/) +请参阅 [Kubernetes 相关文档](/docs/setup/production-environment/container-runtimes/)。 +你可以通过专用 [GitHub 问题](https://github.com/kubernetes/kubernetes/issues/106917) +讨论删除 dockershim 的决定。 + +### 是否有任何工具可以帮助我找到正在使用的 dockershim + + +是的！ [Docker Socket 检测器 (DDS)][dds] 是一个 kubectl 插件， +你可以安装它用于检查你的集群。 DDS 可以检测运行中的 Kubernetes +工作负载是否将 Docker 引擎套接字 (`docker.sock`) 作为卷挂载。 +在 DDS 项目的 [README][dds] 中查找更多详细信息和使用方法。 + +[dds]: https://github.com/aws-containers/kubectl-detector-for-docker-socket + diff --git a/content/zh/case-studies/adidas/adidas-featured.svg b/content/zh/case-studies/adidas/adidas-featured.svg new file mode 100644 index 0000000000..a53d467552 --- /dev/null +++ b/content/zh/case-studies/adidas/adidas-featured.svg @@ -0,0 +1 @@ +kubernetes.io-54664 \ No newline at end of file diff --git a/content/zh/case-studies/adidas/index.html b/content/zh/case-studies/adidas/index.html new file mode 100644 index 0000000000..3a95a5aa1b --- /dev/null +++ b/content/zh/case-studies/adidas/index.html @@ -0,0 +1,78 @@ +--- +title: adidas Case Study +linkTitle: adidas +case_study_styles: true +cid: caseStudies +featured: false + +new_case_study_styles: true +heading_background: /images/case-studies/adidas/banner1.png +heading_title_text: adidas +use_gradient_overlay: true +subheading: > + Staying True to Its Culture, adidas Got 40% of Its Most Impactful Systems Running on Kubernetes in a Year +case_study_details: + - Company: adidas + - Location: Herzogenaurach, Germany + - Industry: Fashion +--- + +

Challenge

+ +

In recent years, the adidas team was happy with its software choices from a technology perspective—but accessing all of the tools was a problem. For instance, "just to get a developer VM, you had to send a request form, give the purpose, give the title of the project, who's responsible, give the internal cost center a call so that they can do recharges," says Daniel Eichten, Senior Director of Platform Engineering. "The best case is you got your machine in half an hour. Worst case is half a week or sometimes even a week."

+ +

Solution

+ +

To improve the process, "we started from the developer point of view," and looked for ways to shorten the time it took to get a project up and running and into the adidas infrastructure, says Senior Director of Platform Engineering Fernando Cornago. They found the solution with containerization, agile development, continuous delivery, and a cloud native platform that includes Kubernetes and Prometheus.

+ +

Impact

+ +

Just six months after the project began, 100% of the adidas e-commerce site was running on Kubernetes. Load time for the e-commerce site was reduced by half. Releases went from every 4-6 weeks to 3-4 times a day. With 4,000 pods, 200 nodes, and 80,000 builds per month, adidas is now running 40% of its most critical, impactful systems on its cloud native platform.

+ +{{< case-studies/quote + image="/images/case-studies/adidas/banner2.png" + author="FERNANDO CORNAGO, SENIOR DIRECTOR OF PLATFORM ENGINEERING AT ADIDAS" +>}} +"For me, Kubernetes is a platform made by engineers for engineers. It's relieving the development team from tasks that they don't want to do, but at the same time giving the visibility of what is behind the curtain, so they can also control it." +{{< /case-studies/quote >}} + +{{< case-studies/lead >}} +In recent years, the adidas team was happy with its software choices from a technology perspective—but accessing all of the tools was a problem. +{{< /case-studies/lead >}} + +

For engineers at adidas, says Daniel Eichten, Senior Director of Platform Engineering, "it felt like being an artist with your hands tied behind your back, and you're supposed to paint something."

+ +

For instance, "just to get a developer VM, you had to send a request form, give the purpose, give the title of the project, who's responsible, give the internal cost center a call so that they can do recharges," says Eichten. "Eventually, after a ton of approvals, then the provisioning of the machine happened within minutes, and then the best case is you got your machine in half an hour. Worst case is half a week or sometimes even a week."

+ +

To improve the process, "we started from the developer point of view," and looked for ways to shorten the time it took to get a project up and running and into the adidas infrastructure, says Senior Director of Platform Engineering Fernando Cornago.

+ +{{< case-studies/quote author="DANIEL EICHTEN, SENIOR DIRECTOR OF PLATFORM ENGINEERING AT ADIDAS" >}} +"I call our cloud native platform the field of dreams. We built it, and we never anticipated that people would come and just love it." +{{< /case-studies/quote >}} + +

"We were engineers before," adds Eichten. "We know what a typical engineer needs, is craving for, what he or she doesn't want to take care of. For us it was pretty clear. We filled the gaps that no one wants to take care of, and we make the stuff that is usually painful as painless as possible." The goals: to improve speed, operability, and observability.

+ +

Cornago and Eichten found the solution with containerization, agile development, continuous delivery, and a cloud native platform that includes Kubernetes and Prometheus. "Choosing Kubernetes was pretty clear," says Eichten. "Day zero, deciding, easy. Day one, installing, configuring, easy. Day two, keeping it up and running even with small workloads, if something goes wrong, you don't know how these things work in detail, you're lost. For day two problems, we needed a partner who's helping us."

+ +

In early 2017, adidas chose Giant Swarm to consult, install, configure, and run all of its Kubernetes clusters in AWS and on premise. "There is no competitive edge over our competitors like Puma or Nike in running and operating a Kubernetes cluster," says Eichten. "Our competitive edge is that we teach our internal engineers how to build cool e-comm stores that are fast, that are resilient, that are running perfectly."

+ +{{< case-studies/quote + image="/images/case-studies/adidas/banner3.png" + author="DANIEL EICHTEN, SENIOR DIRECTOR OF PLATFORM ENGINEERING AT ADIDAS" +>}} +"There is no competitive edge over our competitors like Puma or Nike in running and operating a Kubernetes cluster. Our competitive edge is that we teach our internal engineers how to build cool e-comm stores that are fast, that are resilient, that are running perfectly." +{{< /case-studies/quote >}} + +

Adds Cornago: "For me, our Kubernetes platform is made by engineers for engineers. It's relieving the development team from tasks that they don't want to do, but at the same time giving the visibility of what is behind the curtain, so they can also control it."

+ +

Case in point: For Cyber Week, the team has to create a lot of custom metrics. In November 2017, "because we used the same Prometheus that we use for monitoring the cluster, we really filled the Prometheus database, and we were not able to reduce the retention period [enough]," says Cornago. So during the freeze period before the peak shopping week, five engineers from the platform team worked with five engineers from the e-comm team to figure out a federated solution that was implemented in two days.

+ +

In addition to being ready for Cyber Week—100% of the adidas e-commerce site was running on Kubernetes then, just six months after the project began—the cloud native stack has had other impressive results. Load time for the e-commerce site was reduced by half. Releases went from every 4-6 weeks to 3-4 times a day. With 4,000 pods, 200 nodes, and 80,000 builds per month, adidas is now running 40% of its most critical, impactful systems on its cloud native platform.

+ +

And adoption has spread quickly among adidas's 300-strong engineering corps. "I call our cloud native platform the field of dreams," says Eichten. "We built it, and we never anticipated that people would come and just love it."

+ +

For one thing, "everybody who can touch a line of code" has spent one full week onboarding and learning the platform with members of the 35-person platform engineering team, says Cornago. "We try to spend 50% of our time sitting with the teams, because this is the only way to understand how our platform is being used. And this is how the teams will feel safe that there is someone on the other side of the wall, also feeling the pain."

+ +

Additionally, Cornago and Eichten took advantage of the fact that as a fashion athletic wear brand, adidas has sports and competition in its DNA. "Top-down mandates don't work at adidas, but gamification works," says Cornago. "So this year we had a DevOps Cup competition. Every team created new technical capabilities and had a hypothesis of how this affected business value. We announced the winner at a big internal tech summit with more than 600 people. It's been really, really useful for the teams."

+ +

So if they had any advice for other companies looking to start a cloud native journey, it would be this: "There is no one-size-fits-all for all companies," says Cornago. "Apply your company's culture to everything that you do."

diff --git a/content/zh/case-studies/babylon/babylon_featured_logo.png b/content/zh/case-studies/babylon/babylon_featured_logo.png new file mode 100644 index 0000000000..8b158b5ed3 Binary files /dev/null and b/content/zh/case-studies/babylon/babylon_featured_logo.png differ diff --git a/content/zh/case-studies/babylon/babylon_featured_logo.svg b/content/zh/case-studies/babylon/babylon_featured_logo.svg new file mode 100644 index 0000000000..e84da19268 --- /dev/null +++ b/content/zh/case-studies/babylon/babylon_featured_logo.svg @@ -0,0 +1 @@ +babylon_featured_logo \ No newline at end of file diff --git a/content/zh/case-studies/babylon/index.html b/content/zh/case-studies/babylon/index.html new file mode 100644 index 0000000000..6b86096b02 --- /dev/null +++ b/content/zh/case-studies/babylon/index.html @@ -0,0 +1,84 @@ +--- +title: Babylon Case Study +linkTitle: Babylon +case_study_styles: true +cid: caseStudies +logo: babylon_featured_logo.svg +featured: true +weight: 1 +quote: > + Kubernetes is a great platform for machine learning because it comes with all the scheduling and scalability that you need. + +new_case_study_styles: true +heading_background: /images/case-studies/babylon/banner4.jpg +heading_title_text: Babylon +use_gradient_overlay: true +subheading: > + AppDirect: How Cloud Native Is Enabling Babylon's Medical AI Innovations +case_study_details: + - Company: Babylon + - Location: United Kingdom + - Industry: AI, Healthcare +--- + +

Challenge

+ +

A large number of Babylon's products leverage machine learning and artificial intelligence, and in 2019, there wasn't enough computing power in-house to run a particular experiment. The company was also growing (from 100 to 1,600 in three years) and planning expansion into other countries.

+ +

Solution

+ +

Babylon had migrated its user-facing applications to a Kubernetes platform in 2018, so the infrastructure team turned to Kubeflow, a toolkit for machine learning on Kubernetes. "We tried to create a Kubernetes core server, we deployed Kubeflow, and we orchestrated the whole experiment, which ended up being a really good success," says AI Infrastructure Lead Jérémie Vallée. The team began building a self-service AI training platform on top of Kubernetes.

+ +

Impact

+ +

Instead of waiting hours or days to be able to compute, teams can get access instantaneously. Clinical validations used to take 10 hours; now they are done in under 20 minutes. The portability of the cloud native platform has also enabled Babylon to expand into other countries.

+ +{{< case-studies/quote + image="/images/case-studies/babylon/banner1.jpg" + author="JÉRÉMIE VALLÉE, AI INFRASTRUCTURE LEAD AT BABYLON" +>}} +"Kubernetes is a great platform for machine learning because it comes with all the scheduling and scalability that you need." +{{< /case-studies/quote >}} + +{{< case-studies/lead >}} +Babylon's mission is to put accessible and affordable healthcare services in the hands of every person on earth. +{{< /case-studies/lead >}} + +

Since its launch in the U.K. in 2013, the startup has facilitated millions of digital consultations around the world. In the U.K., patients were typically waiting a week or two for a doctor's appointment. Through Babylon's NHS service, GP at Hand—which has more than 75,000 registered patients—39% get an appointment through their phone within 30 minutes, and 89% within 6 hours.

+ +

That's just the start. "We try to combine different types of technology with the medical expertise that we have in-house to build products that will help patients manage and understand their health, and also help doctors be more efficient at what they do," says Jérémie Vallée, AI Infrastructure Lead at Babylon.

+ +

A large number of these products leverage machine learning and artificial intelligence, and in 2019, researchers hit a pain point. "We have some servers in-house where our researchers were doing a lot of AI experiments and some training of models, and we came to a point where we didn't have enough compute in-house to run a particular experiment," says Vallée.

+ +

Babylon had migrated its user-facing applications to a Kubernetes platform in 2018, "and we had a lot of Kubernetes knowledge thanks to the migration," he adds. To optimize some of the models that had been created, the team turned to Kubeflow, a toolkit for machine learning on Kubernetes. "We tried to create a Kubernetes core server, we deployed Kubeflow, and we orchestrated the whole experiment, which ended up being a really good success," he says.

+ +

Based on that experience, Vallée's team was tasked with building a self-service platform to help Babylon's AI teams become more efficient, and by extension help get products to market faster. The main requirements: (1) the ability to give researchers and engineers access to the compute they needed, regardless of the size of the experiments they may need to run; (2) a way to provide teams with the best tools that they needed to do their work, on demand and in a centralized way; and (3) the training platform had to be close to the data that was being managed, because of the company's expansion into different countries.

+ +{{< case-studies/quote author="CAROLINE HARGROVE, CHIEF TECHNOLOGY OFFICER AT BABYLON" >}} +"Delivering a self-service platform where users are empowered to run their own workload has enabled our data scientist community to do hyper parameter tuning and general algorithm development without any cloud skill and without the help of platform engineers, thus accelerating our innovation." +{{< /case-studies/quote >}} + +

Kubernetes was an enabler on every count. "Kubernetes is a great platform for machine learning because it comes with all the scheduling and scalability that you need," says Vallée. The need to keep data in every country in which Babylon operates requires a multi-region, multi-cloud strategy, and some countries might not even have a public cloud provider at all. "We wanted to make this platform portable so that we can run training jobs anywhere," he says. "Kubernetes offered a base layer that allows you to deploy the platform outside of the cloud provider, and then deploy whatever tooling you need. That was a very good selling point for us."

+ +

Once the team decided to build the Babylon AI Research platform on top of Kubernetes, they referred to the Cloud Native Landscape to build out the stack: Prometheus and Grafana for monitoring; an Istio service mesh to control the network on the training platform and control what access all of the workflows would have; Helm to deploy the stack; and Flux to manage the GitOps part of the pipeline.

+ +

The cloud native AI platform has had a huge impact at Babylon. The first research projects run on the platform mostly involved machine learning and natural language processing. These experiments required a huge amount of compute—1600 CPU, 3.2 TB RAM—which was much more than Babylon had in-house. Plus, access to compute used to take hours, or sometimes even days, depending on how busy the platform team was. "Now, with Kubernetes and the self-service platform that we provide, it's pretty much instantaneous," says Vallée.

+ +

Another important type of work that's done on the platform is clinical validation for new applications such as Babylon's Symptom Checker, which calculates the probability of a disease given the evidence input by the user. "Being in healthcare, we want all of our models to be safe before they're going to hit production," says Vallée. Using Argo for GitOps "enabled us to scale the process massively."

+ +{{< case-studies/quote + image="/images/case-studies/babylon/banner2.jpg" + author="JEAN MARIE FERDEGUE, DIRECTOR OF PLATFORM OPERATIONS AT BABYLON" +>}} +"Giving a Kubernetes-based platform to our data scientists has meant increased security, increased innovation through empowerment, and a more affordable health service as our cloud engineers are building an experience that is used by hundreds on a daily basis, rather than supporting specific bespoke use cases." +{{< /case-studies/quote >}} + +

Researchers used to have to wait up to 10 hours to get results on new versions of their models. With Kubernetes, that time is now down to under 20 minutes. Plus, previously they could only run one clinical validation at a time, now they can run many parallel ones if they need to—a huge benefit considering that in the past three years, Babylon has grown from 100 to 1,600 employees.

+ +

"Delivering a self-service platform where users are empowered to run their own workload has enabled our data scientist community to do hyper parameter tuning and general algorithm development without any cloud skill and without the help of platform engineers, thus accelerating our innovation," says Chief Technology Officer Caroline Hargrove.

+ +

Adds Director of Platform Operations Jean Marie Ferdegue: "Giving a Kubernetes-based platform to our data scientists has meant increased security, increased innovation through empowerment, and a more affordable health service as our cloud engineers are building an experience that is used by hundreds on a daily basis, rather than supporting specific bespoke use cases."

+ +

Plus, as Babylon continues to expand, "it will be very easy to onboard new countries," says Vallée. "Fifteen months ago when we deployed this platform, we had one big environment in the U.K., but now we have one in Canada, we have one in Asia, and we have one coming in the U.S. This is one of the things that Kubernetes and the other cloud native projects have enabled for us."

+ +

Babylon's road map for cloud native involves onboarding all of the company's AI efforts to the platform. Increasingly, that includes AI services of care. "I think this is going to be an interesting field where AI and healthcare meet," Vallée says. "It's kind of a complex problem and there's a lot of issues around this. So with our platform, we want to say, 'What can we do to make this less painful for our developers and machine learning engineers?'"

diff --git a/content/zh/case-studies/booking-com/booking.com_featured_logo.png b/content/zh/case-studies/booking-com/booking.com_featured_logo.png new file mode 100644 index 0000000000..623ca67345 Binary files /dev/null and b/content/zh/case-studies/booking-com/booking.com_featured_logo.png differ diff --git a/content/zh/case-studies/booking-com/booking.com_featured_logo.svg b/content/zh/case-studies/booking-com/booking.com_featured_logo.svg new file mode 100644 index 0000000000..0b245c2700 --- /dev/null +++ b/content/zh/case-studies/booking-com/booking.com_featured_logo.svg @@ -0,0 +1 @@ +booking.com_featured_logo \ No newline at end of file diff --git a/content/zh/case-studies/booking-com/index.html b/content/zh/case-studies/booking-com/index.html new file mode 100644 index 0000000000..74d5b282b1 --- /dev/null +++ b/content/zh/case-studies/booking-com/index.html @@ -0,0 +1,86 @@ +--- +title: Booking.com Case Study +linkTitle: Booking.com +case_study_styles: true +cid: caseStudies +logo: booking.com_featured_logo.png +featured: true +weight: 3 +quote: > + We realized that we needed to learn Kubernetes better in order to fully use the potential of it. At that point, we made the shift to build our own Kubernetes platform. + +new_case_study_styles: true +heading_background: /images/case-studies/booking/banner1.jpg +heading_title_text: Booking.com +use_gradient_overlay: true +subheading: > + After Learning the Ropes with a Kubernetes Distribution, Booking.com Built a Platform of Its Own +case_study_details: + - Company: Booking.com + - Location: Netherlands + - Industry: Travel +--- + +

Challenge

+ +

In 2016, Booking.com migrated to an OpenShift platform, which gave product developers faster access to infrastructure. But because Kubernetes was abstracted away from the developers, the infrastructure team became a "knowledge bottleneck" when challenges arose. Trying to scale that support wasn't sustainable.

+ +

Solution

+ +

After a year operating OpenShift, the platform team decided to build its own vanilla Kubernetes platform—and ask developers to learn some Kubernetes in order to use it. "This is not a magical platform," says Ben Tyler, Principal Developer, B Platform Track. "We're not claiming that you can just use it with your eyes closed. Developers need to do some learning, and we're going to do everything we can to make sure they have access to that knowledge."

+ +

Impact

+ +

Despite the learning curve, there's been a great uptick in adoption of the new Kubernetes platform. Before containers, creating a new service could take a couple of days if the developers understood Puppet, or weeks if they didn't. On the new platform, it can take as few as 10 minutes. About 500 new services were built on the platform in the first 8 months.

+ +{{< case-studies/quote + image="/images/case-studies/booking/banner2.jpg" + author="BEN TYLER, PRINCIPAL DEVELOPER, B PLATFORM TRACK AT BOOKING.COM" +>}} +"As our users learn Kubernetes and become more sophisticated Kubernetes users, they put pressure on us to provide a better, more native Kubernetes experience, which is great. It's a super healthy dynamic." +{{< /case-studies/quote >}} + +​{{< case-studies/lead >}} +Booking.com has a long history with Kubernetes: In 2015, a team at the travel platform prototyped a container platform based on Mesos and Marathon. +{{< /case-studies/lead >}} + +

Impressed by what the technology offered, but in need of enterprise features at its scale—the site handles more than 1.5 million room-night reservations a day on average—the team decided to adopt an OpenShift platform.

+ +

This platform, which was wrapped in a Heroku-style, high-level CLI interface, "was definitely popular with our product developers," says Ben Tyler, Principal Developer, B Platform Track. "We gave them faster access to infrastructure."

+ +

But, he adds, "anytime something went slightly off the rails, developers didn't have any of the knowledge required to support themselves."

+ +

And after a year of operating this platform, the infrastructure team found that it had become "a knowledge bottleneck," he says. "Most of the developers who used it did not know it was Kubernetes underneath. An application failure and a platform failure both looked like failures of that Heroku-style tool."

+ +

Scaling the necessary support did not seem feasible or sustainable, so the platform team needed a new solution. The understanding of Kubernetes that they had gained operating the OpenShift platform gave them confidence to build a vanilla Kubernetes platform of their own and customize it to suit the company's needs.

+ +{{< case-studies/quote author="EDUARD IACOBOAIA, SENIOR SYSTEM ADMINISTRATOR, B PLATFORM TRACK AT BOOKING.COM" >}} +"For entering the landscape, OpenShift was definitely very helpful. It shows you what the technology can do, and it makes it easy for you to use it. After we spent some time on it, we realized that we needed to learn Kubernetes better in order to fully use the potential of it. At that point, we made the shift to build our own Kubernetes platform. We definitely benefit in the long term for taking that step and investing the time in gaining that knowledge." +{{< /case-studies/quote >}} + +

"For entering the landscape, OpenShift was definitely very helpful," says Eduard Iacoboaia, Senior System Administrator, B Platform Track. "It shows you what the technology can do, and it makes it easy for you to use it. After we spent some time on it, we realized that we needed to learn Kubernetes better in order to fully use the potential of it. At that point, we made the shift to build our own Kubernetes platform. We definitely benefit in the long term for taking that step and investing the time in gaining that knowledge."

+ +

Iacoboaia's team had customized a lot of OpenShift tools to make them work at Booking.com, and "those integrations points were kind of fragile," he says. "We spent much more time understanding all the components of Kubernetes, how they work, how they interact with each other." That research led the team to switch from OpenShift's built-in Ansible playbooks to Puppet deployments, which are used for the rest of Booking's infrastructure. The control plane was also moved from inside the cluster onto bare metal, as the company runs tens of thousands of bare-metal servers and a large infrastructure for running applications on bare metal. (Booking runs Kubernetes in multiple clusters in multiple data centers across the various regions where it has compute.) "We decided to keep it as simple as possible and to also use the tools that we know best," says Iacoboaia.

+ +

The other big change was that product engineers would have to learn Kubernetes in order to onboard. "This is not a magical platform," says Tyler. "We're not claiming that you can just use it with your eyes closed. Developers need to do some learning, and we're going to do everything we can to make sure they have access to that knowledge." That includes trainings, blog posts, videos, and Udemy courses.

+ +

Despite the learning curve, there's been a great uptick in adoption of the new Kubernetes platform. "I think the reason we've been able to strike this bargain successfully is that we're not asking them to learn a proprietary app system," says Tyler. "We're asking them to learn something that's open source, where the knowledge is transferable. They're investing in their own careers by learning Kubernetes."

+ +

One clear sign that this strategy has been a success is that in the support channel, when users have questions, other product engineers are jumping in to respond. "I haven't seen that kind of community engagement around a particular platform product internally before," says Tyler. "It helps a lot that it's visibly an ecosystem standard outside of the company, so people feel value in investing in that knowledge and sharing it with others, which is really, really powerful."

+ +{{< case-studies/quote + image="/images/case-studies/booking/banner3.jpg" + author="BEN TYLER, PRINCIPAL DEVELOPER, B PLATFORM TRACK AT BOOKING.COM" +>}} +"We have a tutorial. You follow the tutorial. Your code is running. Then, it's business-logic time. The time to gain access to resources is decreased enormously." +{{< /case-studies/quote >}} + +

There's other quantifiable evidence too: Before containers, creating a new service could take a couple of days if the developers understood Puppet, or weeks if they didn't. On the new platform, it takes 10 minutes. "We have a tutorial. You follow the tutorial. Your code is running. Then, it's business-logic time," says Tyler. "The time to gain access to resources is decreased enormously." About 500 new services were built in the first 8 months on the platform, with hundreds of releases per day.

+ +

The platform offers different "layers of contracts, so to speak," says Tyler. "At the very base, it's just Kubernetes. If you're a pro Kubernetes user, here's a Kubernetes API, just like you get from GKE or AKS. We're trying to be a provider on that same level. But our whole job inside the company is to be a bigger value add than just vanilla infrastructure, so we provide a set of base images for our main stacks, Perl and Java."

+ +

And "as our users learn Kubernetes and become more sophisticated Kubernetes users, they put pressure on us to provide a better more native Kubernetes experience, which is great," says Tyler. "It's a super healthy dynamic."

+ +

The platform also includes other CNCF technologies, such as Envoy, Helm, and Prometheus. Most of the critical service traffic for Booking.com is routed through Envoy, and Prometheus is used primarily to monitor infrastructure components. Helm is consumed as a packaging standard. The team also developed and open sourced Shipper, an extension for Kubernetes to add more complex rollout strategies and multi-cluster orchestration.

+ +

To be sure, there have been internal discussions about the wisdom of building a Kubernetes platform from the ground up. "This is not really our core competency—Kubernetes and travel, they're kind of far apart, right?" says Tyler. "But we've made a couple of bets on CNCF components that have worked out really well for us. Envoy and Kubernetes, in particular, have been really beneficial to our organization. We were able to customize them, either because we could look at the source code or because they had extension points, and we were able to get value out of them very quickly without having to change any paradigms internally."

diff --git a/content/zh/case-studies/booz-allen/booz-allen-featured-logo.svg b/content/zh/case-studies/booz-allen/booz-allen-featured-logo.svg new file mode 100644 index 0000000000..3ce58c68f7 --- /dev/null +++ b/content/zh/case-studies/booz-allen/booz-allen-featured-logo.svg @@ -0,0 +1 @@ +booz-allen-featured \ No newline at end of file diff --git a/content/zh/case-studies/booz-allen/booz-allen_featured_logo.png b/content/zh/case-studies/booz-allen/booz-allen_featured_logo.png new file mode 100644 index 0000000000..f9bc64ba3b Binary files /dev/null and b/content/zh/case-studies/booz-allen/booz-allen_featured_logo.png differ diff --git a/content/zh/case-studies/booz-allen/index.html b/content/zh/case-studies/booz-allen/index.html new file mode 100644 index 0000000000..7b53dc01ae --- /dev/null +++ b/content/zh/case-studies/booz-allen/index.html @@ -0,0 +1,80 @@ +--- +title: Booz Allen Case Study +linkTitle: Booz Allen Hamilton +case_study_styles: true +cid: caseStudies +logo: booz-allen-featured-logo.svg +featured: true +weight: 2 +quote: > + Kubernetes is a great solution for us. It allows us to rapidly iterate on our clients' demands. + +new_case_study_styles: true +heading_background: /images/case-studies/booz-allen/banner4.jpg +heading_title_text: Booz Allen Hamilton +use_gradient_overlay: true +subheading: > + How Booz Allen Hamilton Is Helping Modernize the Federal Government with Kubernetes +case_study_details: + - Company: Booz Allen Hamilton + - Location: United States + - Industry: Government +--- + +

Challenge

+ +

In 2017, Booz Allen Hamilton's Strategic Innovation Group worked with the federal government to relaunch the decade-old recreation.gov website, which provides information and real-time booking for more than 100,000 campsites and facilities on federal lands across the country. The infrastructure needed to be agile, reliable, and scalable—as well as repeatable for the other federal agencies that are among Booz Allen Hamilton's customers.

+ +

Solution

+ +

"The only way that we thought we could be successful with this problem across all the different agencies is to create a microservice architecture and containers, so that we could be very dynamic and very agile to any given agency for whatever requirements that they may have," says Booz Allen Hamilton Senior Lead Technologist Martin Folkoff. To meet those requirements, Folkoff's team looked to Kubernetes for orchestration.

+ +

Impact

+ +

With the recreation.gov Kubernetes platform, changes can be implemented in about 30 minutes, compared to the multiple hours or even days legacy government applications require to review the code, get approval, and deploy the fix. Recreation.gov deploys to production on average 10 times a day. With monitoring, security, and logging built in, developers can create and publish new services to production within a week. Additionally, Folkoff says, "supporting the large, existing monoliths in the government is extremely expensive," and migrating into a more modern platform has resulted in perhaps 50% cost savings.

+ +{{< case-studies/quote + image="/images/case-studies/booz-allen/banner2.jpg" + author="JOSH BOYD, CHIEF TECHNOLOGIST AT BOOZ ALLEN HAMILTON" +>}} +"When there's a regulatory change in an agency, or a legislative change in Congress, or an executive order that changes the way you do business, how do I deploy that and get that out to the people who need it rapidly? At the end of the day, that's the problem we're trying to help the government solve with tools like Kubernetes." +{{< /case-studies/quote >}} +​ +​{{< case-studies/lead >}} +The White House launched an IT modernization effort in 2017, and in addition to improving cybersecurity and shifting to the public cloud and a consolidated IT model, "the federal government is looking to provide a better experience to citizens in every way that we interact with the government through every channel," says Booz Allen Hamilton Senior Lead Technologist Martin Folkoff. +{{< /case-studies/lead >}} + +

To that end, Folkoff's Strategic Innovation Group worked with the federal government last year to relaunch the decade-old recreation.gov website, which provides information and real-time booking for more than 100,000 campsites and facilities on federal lands across the country.

+ +

The infrastructure needed to be agile, reliable, and scalable—as well as repeatable for the other federal agencies that are among Booz Allen Hamilton's customers. "The only way that we thought we could be successful with this problem across all the different agencies is to create a microservice architecture, so that we could be very dynamic and very agile to any given agency for whatever requirements that they may have," says Folkoff.

+ +{{< case-studies/quote author="MARTIN FOLKOFF, SENIOR LEAD TECHNOLOGIST AT BOOZ ALLEN HAMILTON" >}} +"With CNCF, there's a lot of focus on scale, and so there's a lot of comfort knowing that as the project grows, we're going to be comfortable using that tool set." +{{< /case-studies/quote >}} + +

Booz Allen Hamilton, which has provided consulting services to the federal government for more than a century, introduced microservices, Docker containers, and AWS to its federal agency clients about five years ago. The next logical step was Kubernetes for orchestration. "Knowing that we had to be really agile and really reliable and scalable, we felt that the only technology that we know that can enable those kinds of things are the ones the CNCF provides," Folkoff says. "One of the things that is always important for the government is to make sure that the things that we build really endure. Using technology that is supported across multiple different companies and has strong governance gives people a lot of confidence."

+ +

Kubernetes was also aligned with the government's open source and IT modernization initiatives, so there has been an uptick in its usage at federal agencies over the past two years. "Now that Kubernetes is becoming offered as a service by the cloud providers like AWS and Microsoft, we're starting to see even more interest," says Chief Technologist Josh Boyd. Adds Folkoff: "With CNCF, there's a lot of focus on scale, and so there's a lot of comfort knowing that as the project grows, we're going to be comfortable using that tool set."

+ +

The greenfield recreation.gov project allowed the team to build a new Kubernetes-enabled site running on AWS, and the migration lasted only a week, when the old site didn't take bookings. "For the actual transition, we just swapped a DNS server, and it only took about 35 seconds between the old site being down and our new site being up and available," Folkoff adds.

+​ +{{< case-studies/quote + image="/images/case-studies/booz-allen/banner1.png" + author="MARTIN FOLKOFF, SENIOR LEAD TECHNOLOGIST AT BOOZ ALLEN HAMILTON" +>}} +"Kubernetes alone enables a dramatic reduction in cost as resources are prioritized to the day's event" +{{< /case-studies/quote >}} + +

In addition to its work with the Department of Interior for recreation.gov, Booz Allen Hamilton has brought Kubernetes to various Defense, Intelligence, and civilian agencies. Says Boyd: "When there's a regulatory change in an agency, or a legislative change in Congress, or an executive order that changes the way you do business, how do I deploy that and get that out to the people who need it rapidly? At the end of the day, that's the problem we're trying to help the government solve with tools like Kubernetes."

+ +

For recreation.gov, the impact was clear and immediate. With the Kubernetes platform, Folkoff says, "if a new requirement for a permit comes out, we have the ability to design and develop and implement that completely independently of reserving a campsite. It provides a much better experience to users." Today, changes can be implemented in about 30 minutes, compared to the multiple hours or even days legacy government applications require to review the code, get approval, and deploy the fix. Recreation.gov deploys to production on average 10 times a day.

+ +

Developer velocity has been improved. "When I want to do monitoring or security or logging, I don't have to do anything to my services or my application to enable that anymore," says Boyd. "I get all of this magic just by being on the Kubernetes platform." With all of those things built in, developers can create and publish new services to production within one week.

+ +

Additionally, Folkoff says, "supporting the large, existing monoliths in the government is extremely expensive," and migrating into a more modern platform has resulted in perhaps 50% cost savings. "Kubernetes alone enables a dramatic reduction in cost as resources are prioritized to the day's event," he says. "For example, during a popular campsite release, camping-related services are scaled out while permit services are scaled down."

+ +

So far, "Kubernetes is a great solution for us," says Folkoff. "It allows us to rapidly iterate on our clients' demands." Looking ahead, the team sees further adoption of the Kubernetes platform across federal agencies. Says Boyd: "You get the ability for the rapid delivery of business value for your customers. You now have observability into everything that you're doing. You don't have these onesies and twosies unicorn servers anymore. Now everything that you deploy is deployed in the same way, it's all instrumented the same way, and it's all built and deployed the same way through our CI/CD processes."

+ +

They also see a push toward re-platforming. "There's still a lot of legacy workloads out there," says Boyd. "We've got the new challenges of greenfield development and integration with legacy systems, but also that brown field of 'Hey, how do I take this legacy monolith and get it onto a platform where now it's instrumented with all the magic of the Kubernetes platform without having to do a whole lot to my application?' I think re-platforming is a pretty big use case for the government right now."

+ +

And given the success that they've had with Kubernetes so far, Boyd says, "I think at this point that technology is becoming pretty easy to sell." Adds Folkoff: "People are really excited about being able to deploy, scale, be reliable, and do cheaper maintenance of all of this."

diff --git a/content/zh/case-studies/denso/denso_featured_logo.svg b/content/zh/case-studies/denso/denso_featured_logo.svg new file mode 100644 index 0000000000..e2b26b2c8c --- /dev/null +++ b/content/zh/case-studies/denso/denso_featured_logo.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/content/zh/case-studies/denso/index.html b/content/zh/case-studies/denso/index.html new file mode 100644 index 0000000000..31fb1279b9 --- /dev/null +++ b/content/zh/case-studies/denso/index.html @@ -0,0 +1,82 @@ +--- +title: Denso Case Study +linkTitle: Denso +case_study_styles: true +cid: caseStudies +logo: denso_featured_logo.svg +featured: true +weight: 4 +quote: > + We got Kubernetes experts involved on our team, and it dramatically accelerated development speed. + +new_case_study_styles: true +heading_background: /images/case-studies/denso/banner2.jpg +heading_title_text: Denso +use_gradient_overlay: true +subheading: > + How DENSO Is Fueling Development on the Vehicle Edge with Kubernetes +case_study_details: + - Company: Denso + - Location: Japan + - Industry: Automotive, Edge +--- + +

Challenge

+ +

DENSO Corporation is one of the biggest automotive components suppliers in the world. With the advent of connected cars, the company launched a Digital Innovation Department to expand into software, working on vehicle edge and vehicle cloud products. But there were several technical challenges to creating an integrated vehicle edge/cloud platform: "the amount of computing resources, the occasional lack of mobile signal, and an enormous number of distributed vehicles," says R&D Product Manager Seiichi Koizumi.

+ +

Solution

+ +

Koizumi's team realized that because mobility services evolve every day, they needed the flexibility of the cloud native ecosystem for their platform. After considering other orchestrators, DENSO went with Kubernetes for orchestration and added Prometheus, Fluentd, Envoy, Istio, and Helm to the platform. Today, DENSO is using a vehicle edge computer, a private Kubernetes cloud, and managed Kubernetes (GKE, EKS, AKS).

+ +

Impact

+ +

Critical layer features can take 2-3 years to implement in the traditional, waterfall model of development at DENSO. With the Kubernetes platform and agile methods, there's a 2-month development cycle for non-critical software. Now, ten new applications are released a year, and a new prototype is introduced every week. "By utilizing Kubernetes managed services, such as GKE/EKS/AKS, we can unify the environment and simplify our maintenance operation," says Koizumi.

+ +{{< case-studies/quote + image="/images/case-studies/denso/banner1.png" + author="SEIICHI KOIZUMI, R&D PRODUCT MANAGER, DIGITAL INNOVATION DEPARTMENT AT DENSO" +>}} +"Another disruptive innovation is coming, so to survive in this situation, we need to change our culture." +{{< /case-studies/quote >}} + +{{< case-studies/lead >}} +Spun off from Toyota in 1949, DENSO Corporation is one of the top automotive suppliers in the world today, with consolidated net revenue of $48.3 billion. +{{< /case-studies/lead >}} + +

The company's mission is "contributing to a better world by creating value together with a vision for the future"—and part of that vision in recent years has been development on the vehicle edge and vehicle cloud.

+ +

With the advent of connected cars, DENSO established a Digital Innovation Department to expand its business beyond the critical layer of the engine, braking systems, and other automotive parts into the non-critical analytics and entertainment layer. Comparing connected cars to smartphones, R&D Product Manager Seiichi Koizumi says DENSO wants the ability to quickly and easily develop and install apps for the "blank slate" of the car, and iterate them based on the driver's preferences. Thus "we need a flexible application platform," he says.

+ +

But working on vehicle edge and vehicle cloud products meant there were several technical challenges: "the amount of computing resources, the occasional lack of mobile signal, and an enormous number of distributed vehicles," says Koizumi. "We are tackling these challenges to create an integrated vehicle edge/cloud platform."

+ +{{< case-studies/quote author="SEIICHI KOIZUMI, R&D PRODUCT MANAGER, DIGITAL INNOVATION DEPARTMENT AT DENSO" >}} +"We got Kubernetes experts involved on our team, and it dramatically accelerated development speed." +{{< /case-studies/quote >}} + +

Koizumi's team realized that because mobility services evolve every day, they needed the flexibility of the cloud native ecosystem for their platform. As they evaluated technologies, they were led by these criteria: Because their service-enabler business needed to support multiple cloud and on-premise environments, the solution needed to be cloud agnostic, with no vendor lock-in and open governance. It also had to support an edge-cloud integrated environment.

+ +

After considering other orchestrators, DENSO went with Kubernetes for orchestration and added Prometheus, Fluentd, Envoy, Istio, and Helm to the platform. During implementation, the team used "design thinking to clarify use cases and their value proposition," says Koizumi. Next, an agile development team worked on a POC, then an MVP, in DevOps style. "Even in the development phase, we are keeping a channel to end users," he adds.

+ +

One lesson learned during this process was the value of bringing in experts. "We tried to learn Kubernetes and cloud native technologies from scratch, but it took more time than expected," says Koizumi. "We got Kubernetes experts involved on our team, and it dramatically accelerated development speed."

+ +{{< case-studies/quote + image="/images/case-studies/denso/banner4.jpg" + author="SEIICHI KOIZUMI, R&D PRODUCT MANAGER, DIGITAL INNOVATION DEPARTMENT AT DENSO" +>}} +"By utilizing Kubernetes managed services, such as GKE/EKS/AKS, we can unify the environment and simplify our maintenance operation." +{{< /case-studies/quote >}} + +

Today, DENSO is using a vehicle edge computer, a private Kubernetes cloud, and managed Kubernetes on GKE, EKS, and AKS. "We are developing a vehicle edge/cloud integrated platform based on a microservice and service mesh architecture," says Koizumi. "We extend cloud into multiple vehicle edges and manage it as a unified platform."

+ +

Cloud native has enabled DENSO to deliver applications via its new dash cam, which has a secure connection that collects data to the cloud. "It's like a smartphone," he says. "We are installing new applications and getting the data through the cloud, and we can keep updating new applications all through the dash cam."

+ +

The unified cloud native platform, combined with agile development, has had a positive impact on productivity. Critical layer features—those involving engines or braking systems, for example—can take 2-3 years to implement at DENSO, because of the time needed to test safety, but also because of the traditional, waterfall model of development. With the Kubernetes platform and agile methods, there's a 2-month development cycle for non-critical software. Now, ten new applications are released a year, and with the department's scrum-style development, a new prototype is introduced every week.

+ +

Application portability has also led to greater developer efficiency. "There's no need to care about differences in the multi-cloud platform anymore," says Koizumi. Now, "we are also trying to have the same portability between vehicle edge and cloud platform."

+ +

Another improvement: Automotive Tier-1 suppliers like DENSO always have multiple Tier-2 suppliers. "To provide automotive-grade high-availability services, we tried to do the same thing on a multi-cloud platform," says Koizumi. Before Kubernetes, maintaining two different systems simultaneously was difficult. "By utilizing Kubernetes managed services, such as GKE/EKS/AKS, we can unify the environment and simplify our maintenance operation," he says.

+ +

Cloud native has also profoundly changed the culture at DENSO. The Digital Innovation Department is known as "Noah's Ark," and it has grown from 2 members to 70—with plans to more than double in the next year. The way they operate is completely different from the traditional Japanese automotive culture. But just as the company embraced change brought by hybrid cars in the past decade, Koizumi says, they're doing it again now, as technology companies have moved into the connected car space. "Another disruptive innovation is coming," he says, "so to survive in this situation, we need to change our culture."

+ +

Looking ahead, Koizumi and his team are expecting serverless and zero-trust security architecture to be important enhancements of Kubernetes. They are glad DENSO has come along for the ride. "Mobility service businesses require agility and flexibility," he says. "DENSO is trying to bring cloud native flexibility into the vehicle infrastructure."

diff --git a/content/zh/case-studies/ing/index.html b/content/zh/case-studies/ing/index.html new file mode 100644 index 0000000000..037ba9775d --- /dev/null +++ b/content/zh/case-studies/ing/index.html @@ -0,0 +1,78 @@ +--- +title: ING Case Study +linkTitle: ING +case_study_styles: true +cid: caseStudies +weight: 50 +featured: true +quote: > + The big cloud native promise to our business is the ability to go from idea to production within 48 hours. We are some years away from this, but that's quite feasible to us. + +new_case_study_styles: true +heading_background: /images/case-studies/ing/banner1.jpg +heading_title_logo: /images/ing_logo.png +subheading: > + Driving Banking Innovation with Cloud Native +case_study_details: + - Company: ING + - Location: Amsterdam, Netherlands + - Industry: Finance +--- + +

Challenge

+ +

After undergoing an agile transformation, ING realized it needed a standardized platform to support the work their developers were doing. "Our DevOps teams got empowered to be autonomous," says Infrastructure Architect Thijs Ebbers. "It has benefits; you get all kinds of ideas. But a lot of teams are going to devise the same wheel. Teams started tinkering with Docker, Docker Swarm, Kubernetes, Mesos. Well, it's not really useful for a company to have one hundred wheels, instead of one good wheel.

+ +

Solution

+ +

Using Kubernetes for container orchestration and Docker for containerization, the ING team began building an internal public cloud for its CI/CD pipeline and green-field applications. The pipeline, which has been built on Mesos Marathon, will be migrated onto Kubernetes. The bank-account management app Yolt in the U.K. (and soon France and Italy) market already is live hosted on a Kubernetes framework. At least two greenfield projects currently on the Kubernetes framework will be going into production later this year. By the end of 2018, the company plans to have converted a number of APIs used in the banking customer experience to cloud native APIs and host these on the Kubernetes-based platform.

+ +

Impact

+ +

"Cloud native technologies are helping our speed, from getting an application to test to acceptance to production," says Infrastructure Architect Onno Van der Voort. "If you walk around ING now, you see all these DevOps teams, doing stand-ups, demoing. They try to get new functionality out there really fast. We held a hackathon for one of our existing components and basically converted it to cloud native within 2.5 days, though of course the tail takes more time before code is fully production ready."

+ +{{< case-studies/quote author="Thijs Ebbers, Infrastructure Architect, ING">}} +"The big cloud native promise to our business is the ability to go from idea to production within 48 hours. We are some years away from this, but that's quite feasible to us." +{{< /case-studies/quote >}} + +{{< case-studies/lead >}} +ING has long embraced innovation in banking, launching the internet-based ING Direct in 1997. +{{< /case-studies/lead >}} + +

In that same spirit, the company underwent an agile transformation a few years ago. "Our DevOps teams got empowered to be autonomous," says Infrastructure Architect Thijs Ebbers. "It has benefits; you get all kinds of ideas. But a lot of teams are going to devise the same wheel. Teams started tinkering with Docker, Docker Swarm, Kubernetes, Mesos. Well, it's not really useful for a company to have one hundred wheels, instead of one good wheel."

+ +

Looking to standardize the deployment process within the company's strict security guidelines, the team looked at several solutions and found that in the past year, "Kubernetes won the container management framework wars," says Ebbers. "We decided to standardize ING on a Kubernetes framework." Everything is run on premise due to banking regulations, he adds, but "we will be building an internal public cloud. We are trying to get on par with what public clouds are doing. That's one of the reasons we got Kubernetes."

+ +

They also embraced Docker to address a major pain point in ING's CI/CD pipeline. Before containerization, "Every development team had to order a VM, and it was quite a heavy delivery model for them," says Infrastructure Architect Onno Van der Voort. "Another use case for containerization is when the application travels through the pipeline, they fire up Docker containers to do test work against the applications and after they've done the work, the containers get killed again."

+ +{{< case-studies/quote + image="/images/case-studies/ing/banner3.jpg" + author="Thijs Ebbers, Infrastructure Architect, ING" +>}} +"We decided to standardize ING on a Kubernetes framework." Everything is run on premise due to banking regulations, he adds, but "we will be building an internal public cloud. We are trying to get on par with what public clouds are doing. That's one of the reasons we got Kubernetes." +{{< /case-studies/quote >}} + +

Because of industry regulations, applications are only allowed to go through the pipeline, where compliance is enforced, rather than be deployed directly into a container. "We have to run the complete platform of services we need, many routing from different places," says Van der Voort. "We need this Kubernetes framework for deploying the containers, with all those components, monitoring, logging. It's complex." For that reason, ING has chosen to start on the OpenShift Origin Kubernetes distribution.

+ +

Already, "cloud native technologies are helping our speed, from getting an application to test to acceptance to production," says Van der Voort. "If you walk around ING now, you see all these DevOps teams, doing stand-ups, demoing. They try to get new functionality out there really fast. We held a hackathon for one of our existing components and basically converted it to cloud native within 2.5 days, though of course the tail takes more time before code is fully production ready."

+ +

The pipeline, which has been built on Mesos Marathon, will be migrated onto Kubernetes. Some legacy applications are also being rewritten as cloud native in order to run on the framework. At least two smaller greenfield projects built on Kubernetes will go into production this year. By the end of 2018, the company plans to have converted a number of APIs used in the banking customer experience to cloud native APIs and host these on the Kubernetes-based platform.

+ +{{< case-studies/quote + image="/images/case-studies/ing/banner4.jpg" + author="Onno Van der Voort, Infrastructure Architect, ING" +>}} +"We have to run the complete platform of services we need, many routing from different places. We need this Kubernetes framework for deploying the containers, with all those components, monitoring, logging. It's complex." +{{< /case-studies/quote >}} + +

The team, however, doesn't see the bank's back-end systems going onto the Kubernetes platform. "Our philosophy is it only makes sense to move things to cloud if they are cloud native," says Van der Voort. "If you have traditional architecture, build traditional patterns, it doesn't hold any value to go to the cloud." Adds Cloud Platform Architect Alfonso Fernandez-Barandiaran: "ING has a strategy about where we will go, in order to improve our agility. So it's not about how cool this technology is, it's about finding the right technology and the right approach."

+ +

The Kubernetes framework will be hosting some greenfield projects that are high priority for ING: applications the company is developing in response to PSD2, the European Commission directive requiring more innovative online and mobile payments that went into effect at the beginning of 2018. For example, a bank-account management app called Yolt, serving the U.K. market (and soon France and Italy), was built on a Kubernetes platform and has gone into production. ING is also developing blockchain-enabled applications that will live on the Kubernetes platform. "We've been contacted by a lot of development teams that have ideas with what they want to do with containers," says Ebbers.

+ +{{< case-studies/quote author="Alfonso Fernandez-Barandiaran, Cloud Platform Architect, ING" >}} +Even with the particular requirements that come in banking, ING has managed to take a lead in technology and innovation. "Every time we have constraints, we look for maybe a better way that we can use this technology." +{{< /case-studies/quote >}} + +

Even with the particular requirements that come in banking, ING has managed to take a lead in technology and innovation. "Every time we have constraints, we look for maybe a better way that we can use this technology," says Fernandez-Barandiaran.

+ +

The results, after all, are worth the effort. "The big cloud native promise to our business is the ability to go from idea to production within 48 hours," says Ebbers. "That would require all these projects to be mature. We are some years away from this, but that's quite feasible to us."

diff --git a/content/zh/case-studies/ing/ing_featured_logo.svg b/content/zh/case-studies/ing/ing_featured_logo.svg new file mode 100644 index 0000000000..5a2df497c7 --- /dev/null +++ b/content/zh/case-studies/ing/ing_featured_logo.svg @@ -0,0 +1 @@ +kubernetes.io-logos \ No newline at end of file diff --git a/content/zh/case-studies/jd-com/index.html b/content/zh/case-studies/jd-com/index.html new file mode 100644 index 0000000000..ae3360216b --- /dev/null +++ b/content/zh/case-studies/jd-com/index.html @@ -0,0 +1,79 @@ +--- +title: JD.com Case Study +linkTitle: jd-com +case_study_styles: true +cid: caseStudies +featured: false + +new_case_study_styles: true +heading_background: /images/case-studies/jdcom/banner1.jpg +heading_title_logo: /images/jdcom_logo.png +subheading: > + JD.com: How JD.com Pioneered Kubernetes for E-Commerce at Hyperscale +case_study_details: + - Company: JD.com + - Location: Beijing, China + - Industry: eCommerce +--- + +

Challenge

+ +

With more than 300 million active users and total 2017 revenue of more than $55 billion, JD.com is China's largest retailer, and its operations are the epitome of hyperscale. For example, there are more than a trillion images in JD.com's product databases—with 100 million being added daily—and this enormous amount of data needs to be instantly accessible. In 2014, JD.com moved its applications to containers running on bare metal machines using OpenStack and Docker to "speed up the delivery of our computing resources and make the operations much simpler," says Haifeng Liu, JD.com's Chief Architect. But by the end of 2015, with tens of thousands of nodes running in multiple data centers, "we encountered a lot of problems because our platform was not strong enough, and we suffered from bottlenecks and scalability issues," says Liu. "We needed infrastructure for the next five years of development, now."

+ +

Solution

+ +

JD.com turned to Kubernetes to accommodate its clusters. At the beginning of 2016, the company began to transition from OpenStack to Kubernetes, and today, JD.com runs the world's largest Kubernetes cluster. "Kubernetes has provided a strong foundation on top of which we have customized the solution to suit our needs as China's largest retailer."

+ +

Impact

+ +

"We have greater data center efficiency, better managed resources, and smarter deployment with the Kubernetes platform," says Liu. Deployment time went from several hours to tens of seconds. Efficiency has improved by 20-30%, measured in IT costs. With the further optimizations the team is working on, Liu believes there is the potential to save hundreds of millions of dollars a year. But perhaps the best indication of success was the annual Singles Day shopping event, which ran on the Kubernetes platform for the first time in 2018. Over 11 days, transaction volume on JD.com was $23 billion, and "our e-commerce platforms did great," says Liu. "Infrastructure led the way to prep for 11.11. We took the approach of predicting volume, emulating the behavior of customers to prepare beforehand, and drilled for malfunctions. Because of Kubernetes's scalability, we were able to handle an extremely high level of demand."

+ +{{< case-studies/quote author="HAIFENG LIU, CHIEF ARCHITECT, JD.com" >}} +"Kubernetes helped us reduce the complexity of operations to make distributed systems stable and scalable. Most importantly, we can leverage Kubernetes for scheduling resources to reduce hardware costs. That's the big win." +{{< /case-studies/quote >}} + +{{< case-studies/lead >}} +With more than 300 million active users and $55.7 billion in annual revenues last year, JD.com is China's largest retailer, and its operations are the epitome of hyperscale. +{{< /case-studies/lead >}} + +

For example, there are more than a trillion images in JD.com's product databases for customers, with 100 million being added daily. And this enormous amount of data needs to be instantly accessible to enable a smooth online customer experience.

+ +

In 2014, JD.com moved its applications to containers running on bare metal machines using OpenStack and Docker to "speed up the delivery of our computing resources and make the operations much simpler," says Haifeng Liu, JD.com's Chief Architect. But by the end of 2015, with hundreds of thousands of nodes in multiple data centers, "we encountered a lot of problems because our platform was not strong enough, and we suffered from bottlenecks and scalability issues," Liu adds. "We needed infrastructure for the next five years of development, now."

+ +

After considering a number of orchestration technologies, JD.com decided to adopt Kubernetes to accommodate its ever-growing clusters. "The main reason is because Kubernetes can give us more efficient, scalable and much simpler application deployments, plus we can leverage it to do flexible platform scheduling," says Liu.

+ +{{< case-studies/quote + image="/images/case-studies/jdcom/banner3.jpg" + author="HAIFENG LIU, CHIEF ARCHITECT, JD.com" +>}} +"We customized Kubernetes and built a modern system on top of it. This entire ecosystem of Kubernetes plus our own optimizations have helped us save costs and time." +{{< /case-studies/quote >}} + +

The fact that Kubernetes is based on Google's Borg also gave the company confidence. The team liked that Kubernetes has a clear and simple architecture, and that it's developed mostly in Go, which is a popular language within JD.com. Though he felt that at the time Kubernetes "was not mature enough," Liu says, "we adopted it anyway."

+ +

The team spent a year developing the new container engine platform based on Kubernetes, and at the end of 2016, began promoting it within the company. "We wanted the cluster to be the default way for creating services, so scalability is easier," says Liu. "We talked to developers, interest grew, and we solved problems together." Some of these problems included networking performance and etcd scalability. "But during the past two years, Kubernetes has become more mature and very stable," he adds.

+ +

Today, the company runs the world's largest Kubernetes cluster. "We customized Kubernetes and built a modern system on top of it," says Liu. "This entire ecosystem of Kubernetes plus our own optimizations have helped us save costs and time. We have greater data center efficiency, better managed resources, and smarter deployment with the Kubernetes platform."

+ +{{< case-studies/quote + image="/images/case-studies/jdcom/banner4.jpg" + author="HAIFENG LIU, CHIEF ARCHITECT, JD.com" +>}} +"My advice is first you need to combine this technology with your own businesses, and the second is you need clear goals. You cannot just use the technology because others are using it. You need to consider your own objectives." +{{< /case-studies/quote >}} + +

The results are clear: Deployment time went from several hours to tens of seconds. Efficiency has improved by 20-30%, measured in IT costs. But perhaps the best indication of success was the annual Singles Day shopping event, which ran on the Kubernetes platform for the first time in 2018. Over 11 days, transaction volume on JD.com was $23 billion, and "our e-commerce platforms did great," says Liu. "Infrastructure led the way to prep for 11.11. We took the approach of predicting volume, emulating the behavior of customers to prepare beforehand, and drilled for malfunctions. Because of Kubernetes's scalability, we were able to handle an extremely high level of demand."

+ +

JD.com is now in its second stage with Kubernetes: The platform is already stable, scalable, and flexible, so the focus is on how to run things much more efficiently to further reduce costs. With the optimizations the team is working on with resource management, Liu believes there is the potential to save hundreds of millions of dollars a year.

+ +

"We run Kubernetes and container clusters on roughly tens of thousands of physical bare metal nodes," he says. "Using Kubernetes and leveraging our own machine learning pipeline to predict how many resources we need for each application we use, and our own intelligent scaling algorithm, we can improve our resource usage. If we boost the resource usage, for example, by several percent, that means we can reduce huge hardware costs. Then we don't need that many servers to get that same amount of workload. That can save us a lot of resources."

+ +{{< case-studies/quote author="HAIFENG LIU, CHIEF ARCHITECT, JD.com" >}} +"We can share our successful experience with the community, and we also receive good feedback from others. So it's mutually beneficial." +{{< /case-studies/quote >}} + +

JD.com, which won CNCF's 2018 End User Award, is also using Helm, CNI, Harbor, and Vitess on its platform. JD.com developers have made considerable contributions to Vitess, the CNCF project for scalable MySQL cluster management, and the company hopes to donate its own project to CNCF in the near future. Community participation is a priority for JD.com. "We have a good partnership with this community," says Liu. "We can share our successful experience with the community, and we also receive good feedback from others. So it's mutually beneficial."

+ +

To that end, Liu offers this advice for other companies considering adopting cloud native technology. "First you need to combine this technology with your own businesses, and the second is you need clear goals," he says. "You cannot just use the technology because others are using it. You need to consider your own objectives."

+ +

For JD.com's objectives, these cloud native technologies have been an ideal fit with the company's own homegrown innovation. "Kubernetes helped us reduce the complexity of operations to make distributed systems stable and scalable," says Liu. "Most importantly, we can leverage Kubernetes for scheduling resources to reduce hardware costs. That's the big win."

diff --git a/content/zh/case-studies/jd-com/jd.com_featured_logo.svg b/content/zh/case-studies/jd-com/jd.com_featured_logo.svg new file mode 100644 index 0000000000..d13de0240a --- /dev/null +++ b/content/zh/case-studies/jd-com/jd.com_featured_logo.svg @@ -0,0 +1 @@ +kubernetes.io-logos \ No newline at end of file diff --git a/content/zh/case-studies/squarespace/squarespace_featured_logo.svg b/content/zh/case-studies/squarespace/squarespace_featured_logo.svg new file mode 100644 index 0000000000..a69d7ea5c8 --- /dev/null +++ b/content/zh/case-studies/squarespace/squarespace_featured_logo.svg @@ -0,0 +1 @@ +kubernetes.io-logos2 \ No newline at end of file diff --git a/content/zh/docs/concepts/architecture/control-plane-node-communication.md b/content/zh/docs/concepts/architecture/control-plane-node-communication.md index 3e2beaafd9..8cf742e272 100644 --- a/content/zh/docs/concepts/architecture/control-plane-node-communication.md +++ b/content/zh/docs/concepts/architecture/control-plane-node-communication.md @@ -30,9 +30,9 @@ One or more forms of [authorization](/docs/reference/access-authn-authz/authoriz ## 节点到控制面 Kubernetes 采用的是中心辐射型（Hub-and-Spoke）API 模式。 -所有从集群（或所运行的 Pods）发出的 API 调用都终止于 apiserver。 +所有从集群（或所运行的 Pods）发出的 API 调用都终止于 API 服务器。 其它控制面组件都没有被设计为可暴露远程服务。 -apiserver 被配置为在一个安全的 HTTPS 端口（通常为 443）上监听远程连接请求， +API 服务器被配置为在一个安全的 HTTPS 端口（通常为 443）上监听远程连接请求， 并启用一种或多种形式的客户端[身份认证](/zh/docs/reference/access-authn-authz/authentication/)机制。 一种或多种客户端[鉴权机制](/zh/docs/reference/access-authn-authz/authorization/)应该被启用， 特别是在允许使用[匿名请求](/zh/docs/reference/access-authn-authz/authentication/#anonymous-requests) @@ -41,7 +41,7 @@ apiserver 被配置为在一个安全的 HTTPS 端口（通常为 443）上监 -应该使用集群的公共根证书开通节点，这样它们就能够基于有效的客户端凭据安全地连接 apiserver。 +应该使用集群的公共根证书开通节点，这样它们就能够基于有效的客户端凭据安全地连接 API 服务器。 一种好的方法是以客户端证书的形式将客户端凭据提供给 kubelet。 请查看 [kubelet TLS 启动引导](/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) 以了解如何自动提供 kubelet 客户端证书。 @@ -52,12 +52,12 @@ The `kubernetes` service (in `default` namespace) is configured with a virtual I The control plane components also communicate with the cluster apiserver over the secure port. --> -想要连接到 apiserver 的 Pod 可以使用服务账号安全地进行连接。 +想要连接到 API 服务器的 Pod 可以使用服务账号安全地进行连接。 当 Pod 被实例化时，Kubernetes 自动把公共根证书和一个有效的持有者令牌注入到 Pod 里。 `kubernetes` 服务（位于 `default` 名字空间中）配置了一个虚拟 IP 地址，用于（通过 kube-proxy）转发 -请求到 apiserver 的 HTTPS 末端。 +请求到 API 服务器的 HTTPS 末端。 -控制面组件也通过安全端口与集群的 apiserver 通信。 +控制面组件也通过安全端口与集群的 API 服务器通信。 ## 控制面到节点 -从控制面（apiserver）到节点有两种主要的通信路径。 -第一种是从 apiserver 到集群中每个节点上运行的 kubelet 进程。 -第二种是从 apiserver 通过它的代理功能连接到任何节点、Pod 或者服务。 +从控制面（API 服务器）到节点有两种主要的通信路径。 +第一种是从 API 服务器到集群中每个节点上运行的 kubelet 进程。 +第二种是从 API 服务器通过它的代理功能连接到任何节点、Pod 或者服务。 ### API 服务器到 kubelet -从 apiserver 到 kubelet 的连接用于： +从 API 服务器到 kubelet 的连接用于： * 获取 Pod 日志 * 挂接（通过 kubectl）到运行中的 Pod * 提供 kubelet 的端口转发功能。 这些连接终止于 kubelet 的 HTTPS 末端。 -默认情况下，apiserver 不检查 kubelet 的服务证书。这使得此类连接容易受到中间人攻击， +默认情况下，API 服务器不检查 kubelet 的服务证书。这使得此类连接容易受到中间人攻击， 在非受信网络或公开网络上运行也是 **不安全的**。 -为了对这个连接进行认证，使用 `--kubelet-certificate-authority` 标志给 apiserver -提供一个根证书包，用于 kubelet 的服务证书。 +为了对这个连接进行认证，使用 `--kubelet-certificate-authority` 标志给 API +服务器提供一个根证书包，用于 kubelet 的服务证书。 -如果无法实现这点，又要求避免在非受信网络或公共网络上进行连接，可在 apiserver 和 +如果无法实现这点，又要求避免在非受信网络或公共网络上进行连接，可在 API 服务器和 kubelet 之间使用 [SSH 隧道](#ssh-tunnels)。 最后，应该启用 @@ -122,9 +122,9 @@ kubelet 之间使用 [SSH 隧道](#ssh-tunnels)。 The connections from the apiserver to a node, pod, or service default to plain HTTP connections and are therefore neither authenticated nor encrypted. They can be run over a secure HTTPS connection by prefixing `https:` to the node, pod, or service name in the API URL, but they will not validate the certificate provided by the HTTPS endpoint nor provide client credentials so while the connection will be encrypted, it will not provide any guarantees of integrity. These connections **are not currently safe** to run over untrusted and/or public networks. --> -### apiserver 到节点、Pod 和服务 +### API 服务器到节点、Pod 和服务 -从 apiserver 到节点、Pod 或服务的连接默认为纯 HTTP 方式，因此既没有认证，也没有加密。 +从 API 服务器到节点、Pod 或服务的连接默认为纯 HTTP 方式，因此既没有认证，也没有加密。 这些连接可通过给 API URL 中的节点、Pod 或服务名称添加前缀 `https:` 来运行在安全的 HTTPS 连接上。 不过这些连接既不会验证 HTTPS 末端提供的证书，也不会提供客户端证书。 因此，虽然连接是加密的，仍无法提供任何完整性保证。 @@ -140,8 +140,8 @@ SSH tunnels are currently deprecated so you shouldn't opt to use them unless you --> ### SSH 隧道 {#ssh-tunnels} -Kubernetes 支持使用 SSH 隧道来保护从控制面到节点的通信路径。在这种配置下，apiserver -建立一个到集群中各节点的 SSH 隧道（连接到在 22 端口监听的 SSH 服务） +Kubernetes 支持使用 SSH 隧道来保护从控制面到节点的通信路径。在这种配置下，API +服务器建立一个到集群中各节点的 SSH 隧道（连接到在 22 端口监听的 SSH 服务） 并通过这个隧道传输所有到 kubelet、节点、Pod 或服务的请求。 这一隧道保证通信不会被暴露到集群节点所运行的网络之外。 diff --git a/content/zh/docs/concepts/architecture/nodes.md b/content/zh/docs/concepts/architecture/nodes.md index 68ffb345b1..625c114df4 100644 --- a/content/zh/docs/concepts/architecture/nodes.md +++ b/content/zh/docs/concepts/architecture/nodes.md @@ -63,7 +63,7 @@ valid. For example, if you try to create a Node from the following JSON manifest 1. 节点上的 `kubelet` 向控制面执行自注册； 2. 你，或者别的什么人，手动添加一个 Node 对象。 -在你创建了 Node {{< glossary_tooltip text="object" term_id="object" >}}或者节点上的 +在你创建了 Node {{< glossary_tooltip text="对象" term_id="object" >}}或者节点上的 `kubelet` 执行了自注册操作之后，控制面会检查新的 Node 对象是否合法。 例如，如果你尝试使用下面的 JSON 对象来创建 Node 对象： @@ -100,10 +100,9 @@ it becomes healthy. You, or a {{< glossary_tooltip term_id="controller" text="controller">}}, must explicitly delete the Node object to stop that health checking. --> -Kubernetes 会一直保存着非法节点对应的对象，并持续检查该节点是否已经 -变得健康。 -你，或者某个{{< glossary_tooltip term_id="controller" text="控制器">}}必需显式地 -删除该 Node 对象以停止健康检查操作。 +Kubernetes 会一直保存着非法节点对应的对象，并持续检查该节点是否已经变得健康。 +你，或者某个{{< glossary_tooltip term_id="controller" text="控制器">}}必须显式地删除该 +Node 对象以停止健康检查操作。 {{< /note >}} ### 节点名称唯一性 {#node-name-uniqueness} -节点的[名称](/docs/concepts/overview/working-with-objects/names#names)用来标识 Node 对象。 +节点的[名称](/zh/docs/concepts/overview/working-with-objects/names#names)用来标识 Node 对象。 没有两个 Node 可以同时使用相同的名称。 Kubernetes 还假定名字相同的资源是同一个对象。 就 Node 而言，隐式假定使用相同名称的实例会具有相同的状态（例如网络配置、根磁盘内容） 和类似节点标签这类属性。这可能在节点被更改但其名称未变时导致系统状态不一致。 @@ -177,8 +176,8 @@ When the [Node authorization mode](/docs/reference/access-authn-authz/node/) and kubelets are only authorized to create/modify their own Node resource. --> 启用[Node 鉴权模式](/zh/docs/reference/access-authn-authz/node/)和 -[NodeRestriction 准入插件](/zh/docs/reference/access-authn-authz/admission-controllers/#noderestriction) -时，仅授权 `kubelet` 创建或修改其自己的节点资源。 +[NodeRestriction 准入插件](/zh/docs/reference/access-authn-authz/admission-controllers/#noderestriction)时， +仅授权 `kubelet` 创建或修改其自己的节点资源。 {{< note >}} -更多细节参考[安全腾空节点](/zh/docs/tasks/administer-cluster/safely-drain-node/)。 +更多细节参考[安全地腾空节点](/zh/docs/tasks/administer-cluster/safely-drain-node/)。 {{< note >}} ### 状况 {#condition} -`conditions` 字段描述了所有 `Running` 节点的状态。状况的示例包括： +`conditions` 字段描述了所有 `Running` 节点的状况。状况的示例包括： 节点控制器在确认 Pod 在集群中已经停止运行前，不会强制删除它们。 -你可以看到这些可能在无法访问的节点上运行的 Pod 处于 `Terminating` 或者 `Unknown` 状态。 +你可以看到可能在这些无法访问的节点上运行的 Pod 处于 `Terminating` 或者 `Unknown` 状态。 如果 kubernetes 不能基于下层基础设施推断出某节点是否已经永久离开了集群， 集群管理员可能需要手动删除该节点对象。 从 Kubernetes 删除节点对象将导致 API 服务器删除节点上所有运行的 Pod 对象并释放它们的名字。 @@ -480,7 +479,7 @@ the Kubernetes API. ### 信息（Info） {#info} Info 指的是节点的一般信息，如内核版本、Kubernetes 版本（`kubelet` 和 `kube-proxy` 版本）、 -容器运行时详细信息，以及 节点使用的操作系统。 +容器运行时详细信息，以及节点使用的操作系统。 `kubelet` 从节点收集这些信息并将其发布到 Kubernetes API。 ## 心跳 {#heartbeats} + Kubernetes 节点发送的心跳帮助你的集群确定每个节点的可用性，并在检测到故障时采取行动。 对于节点，有两种形式的心跳: @@ -504,7 +504,7 @@ Kubernetes 节点发送的心跳帮助你的集群确定每个节点的可用性 Each Node has an associated Lease object. --> * 更新节点的 `.status` -* `kube-node-lease` {{}}中的 +* `kube-node-lease` {{}}中的 [Lease（租约）](/docs/reference/kubernetes-api/cluster-resources/lease-v1/)对象。 每个节点都有一个关联的 Lease 对象。 @@ -570,26 +570,29 @@ controller deletes the node from its list of nodes. The third is monitoring the nodes' health. The node controller is responsible for: -- In the case that a node becomes unreachable, updating the NodeReady condition - of within the Node's `.status`. In this case the node controller sets the - NodeReady condition to `ConditionUnknown`. +- In the case that a node becomes unreachable, updating the `Ready` condition + in the Node's `.status` field. In this case the node controller sets the + `Ready` condition to `Unknown`. - If a node remains unreachable: triggering [API-initiated eviction](/docs/concepts/scheduling-eviction/api-eviction/) for all of the Pods on the unreachable node. By default, the node controller - waits 5 minutes between marking the node as `ConditionUnknown` and submitting + waits 5 minutes between marking the node as `Unknown` and submitting the first eviction request. -The node controller checks the state of each node every `-node-monitor-period` seconds. +By default, the node controller checks the state of each node every 5 seconds. +This period can be configured using the `--node-monitor-period` flag on the +`kube-controller-manager` component. --> 第三个是监控节点的健康状况。节点控制器负责： -- 在节点不可达的情况下，在 Node 的 `.status` 中更新 NodeReady 状况。 +- 在节点不可达的情况下，在 Node 的 `.status` 中更新 `Ready` 状况。 在这种情况下，节点控制器将 NodeReady 状况更新为 `Unknown` 。 - 如果节点仍然无法访问：对于不可达节点上的所有 Pod 触发 - [API-发起的逐出](/zh/docs/concepts/scheduling-eviction/api-eviction/)。 + [API 发起的逐出](/zh/docs/concepts/scheduling-eviction/api-eviction/)操作。 默认情况下，节点控制器在将节点标记为 `Unknown` 后等待 5 分钟提交第一个驱逐请求。 -节点控制器每隔 `--node-monitor-period` 秒检查每个节点的状态。 +默认情况下，节点控制器每 5 秒检查一次节点状态，可以使用 `kube-controller-manager` +组件上的 `--node-monitor-period` 参数来配置周期。 当一个可用区域（Availability Zone）中的节点变为不健康时，节点的驱逐行为将发生改变。 -节点控制器会同时检查可用区域中不健康（NodeReady 状况为 `Unknown` 或 `False`） +节点控制器会同时检查可用区域中不健康（`Ready` 状况为 `Unknown` 或 `False`） 的节点的百分比： ## 节点拓扑 {#node-topology} -{{< feature-state state="alpha" for_k8s_version="v1.16" >}} +{{< feature-state state="beta" for_k8s_version="v1.18" >}} -注意，默认情况下，下面描述的两个配置选项，`ShutdownGracePeriod` 和 -`ShutdownGracePeriodCriticalPods` 都是被设置为 0 的，因此不会激活体面节点关闭功能。 +注意，默认情况下，下面描述的两个配置选项，`shutdownGracePeriod` 和 +`shutdownGracePeriodCriticalPods` 都是被设置为 0 的，因此不会激活体面节点关闭功能。 要激活此功能特性，这两个 kubelet 配置选项要适当配置，并设置为非零值。 -例如，如果设置了 `ShutdownGracePeriod=30s` 和 `ShutdownGracePeriodCriticalPods=10s`， +例如，如果设置了 `shutdownGracePeriod=30s` 和 `shutdownGracePeriodCriticalPods=10s`， 则 kubelet 将延迟 30 秒关闭节点。 在关闭期间，将保留前 20（30 - 10）秒用于体面终止常规 Pod， 而保留最后 10 秒用于终止[关键 Pod](/zh/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)。 @@ -817,11 +820,6 @@ reserved for terminating [critical pods](/docs/tasks/administer-cluster/guarante When pods were evicted during the graceful node shutdown, they are marked as failed. Running `kubectl get pods` shows the status of the the evicted pods as `Shutdown`. And `kubectl describe pod` indicates that the pod was evicted because of node shutdown: - -``` -Reason: Terminated -Message: Pod was terminated in response to imminent node shutdown. -``` --> {{< note >}} 当 Pod 在正常节点关闭期间被驱逐时，它们会被标记为已经失败（Failed）。 @@ -970,8 +968,8 @@ containing the pod priority class values and their respective shutdown periods. --> 如果此功能特性被启用，但没有提供配置数据，则不会出现排序操作。 -使用此功能特性需要启用 `GracefulNodeShutdownBasedOnPodPriority` 功能特性， -并将 kubelet 配置中的 `ShutdownGracePeriodByPodPriority` 设置为期望的配置， +使用此功能特性需要启用 `GracefulNodeShutdownBasedOnPodPriority` 特性门控， +并将 kubelet 配置中的 `shutdownGracePeriodByPodPriority` 设置为期望的配置， 其中包含 Pod 的优先级类数值以及对应的关闭期限。 要在节点上启用交换内存，必须启用kubelet 的 `NodeSwap` 特性门控， 同时使用 `--fail-swap-on` 命令行参数或者将 `failSwapOn` -[配置](/zh/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration) -设置为 false。 +[配置](/zh/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)设置为 false。 ## 保护集群 {#securing-a-cluster} @@ -116,7 +116,7 @@ Before choosing a guide, here are some considerations: 阐述了在认证和授权之后拦截到 Kubernetes API 服务的请求的插件。 * [在 Kubernetes 集群中使用 Sysctls](/zh/docs/tasks/administer-cluster/sysctl-cluster/) 描述了管理员如何使用 `sysctl` 命令行工具来设置内核参数。 -* [审计](/zh/docs/tasks/debug-application-cluster/audit/) +* [审计](/zh/docs/tasks/debug/debug-cluster/audit/) 描述了如何与 Kubernetes 的审计日志交互。 ## 监控计算和内存资源用量 @@ -422,8 +422,8 @@ kubelet 会将 Pod 的资源使用情况作为 Pod [`status`](/zh/docs/concepts/overview/working-with-objects/kubernetes-objects/#object-spec-and-status) 的一部分来报告的。 -如果为集群配置了可选的[监控工具](/zh/docs/tasks/debug-application-cluster/resource-usage-monitoring/)， -则可以直接从[指标 API](/zh/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#the-metrics-api) +如果为集群配置了可选的[监控工具](/zh/docs/tasks/debug/debug-cluster/resource-usage-monitoring/)， +则可以直接从[指标 API](/zh/docs/tasks/debug/debug-cluster/resource-metrics-pipeline/#metrics-api) 或者监控工具获得 Pod 的资源使用情况。 ### 容器资源监控 -[容器资源监控](/zh/docs/tasks/debug-application-cluster/resource-usage-monitoring/) +[容器资源监控](/zh/docs/tasks/debug/debug-cluster/resource-usage-monitoring/) 将关于容器的一些常见的时间序列度量值保存到一个集中的数据库中，并提供用于浏览这些数据的界面。 你不限于指定此处列出的 "内置" 制备器（其名称前缀为 "kubernetes.io" 并打包在 Kubernetes 中）。 你还可以运行和指定外部制备器，这些独立的程序遵循由 Kubernetes 定义的 -[规范](https://git.k8s.io/community/contributors/design-proposals/storage/volume-provisioning.md)。 +[规范](https://github.com/kubernetes/design-proposals-archive/blob/main/storage/volume-provisioning.md)。 外部供应商的作者完全可以自由决定他们的代码保存于何处、打包方式、运行方式、使用的插件（包括 Flex）等。 代码仓库 [kubernetes-sigs/sig-storage-lib-external-provisioner](https://github.com/kubernetes-sigs/sig-storage-lib-external-provisioner) 包含一个用于为外部制备器编写功能实现的类库。你可以访问代码仓库 @@ -431,8 +431,9 @@ parameters: -* `type`：`io1`，`gp2`，`gp3`，`sc1`，`st1`。详细信息参见 - [AWS 文档](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html)。默认值：`gp3`。 +* `type`：`io1`，`gp2`，`sc1`，`st1`。详细信息参见 + [AWS 文档](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html)。默认值：`gp2`。 * `zone`(弃用)：AWS 区域。如果没有指定 `zone` 和 `zones`， 通常卷会在 Kubernetes 集群节点所在的活动区域中轮询调度分配。 `zone` 和 `zones` 参数不能同时使用。 diff --git a/content/zh/docs/concepts/workloads/pods/_index.md b/content/zh/docs/concepts/workloads/pods/_index.md index 4689f0aca3..5eec324a1a 100644 --- a/content/zh/docs/concepts/workloads/pods/_index.md +++ b/content/zh/docs/concepts/workloads/pods/_index.md @@ -92,6 +92,37 @@ Pod 的共享上下文包括一组 Linux 名字空间、控制组（cgroup）和 +## 使用 Pod {#using-pods} + +下面是一个 Pod 示例，它由一个运行镜像 `nginx:1.14.2` 的容器组成。 + +{{< codenew file="pods/simple-pod.yaml" >}} + +要创建上面显示的 Pod，请运行以下命令： + +```shell +kubectl apply -f https://k8s.io/examples/pods/simple-pod.yaml +``` + + +Pod 通常不是直接创建的，而是使用工作负载资源创建的。 +有关如何将 Pod 用于工作负载资源的更多信息，请参阅 [使用 Pod](#working-with-pods)。 + +### 用于管理 pod 的工作负载资源 + + -## 使用 Pod {#using-pods} - 通常你不需要直接创建 Pod，甚至单实例 Pod。 相反，你会使用诸如 {{< glossary_tooltip text="Deployment" term_id="deployment" >}} 或 @@ -187,9 +216,9 @@ that updates those files from a remote source, as in the following diagram: --> 例如，你可能有一个容器，为共享卷中的文件提供 Web 服务器支持，以及一个单独的 -“sidecar（挂斗）”容器负责从远端更新这些文件，如下图所示： +"边车 (sidercar)" 容器负责从远端更新这些文件，如下图所示： -{{< figure src="/images/docs/pod.svg" alt="example pod diagram" width="50%" >}} +{{< figure src="/images/docs/pod.svg" alt="Pod creation diagram" class="diagram-medium" >}} -在节点上，{{< glossary_tooltip term_id="kubelet" text="kubelet" >}}并不直接监测 +在节点上，{{< glossary_tooltip term_id="kubelet" text="kubelet" >}} 并不直接监测 或管理与 Pod 模版相关的细节或模版的更新，这些细节都被抽象出来。 这种抽象和关注点分离简化了整个系统的语义，并且使得用户可以在不改变现有代码的 前提下就能扩展集群的行为。 @@ -412,7 +441,7 @@ Kubernetes 并不禁止你直接管理 Pod。对运行中的 Pod 的某些字段 Pods enable data sharing and communication among their constituent containters. --> -### 资源共享和通信 {#resource-sharing-and-communication} +### 资源共享和通信 {#resource-sharing-and-communication} Pod 使它的成员容器间能够进行数据共享和通信。 @@ -459,14 +488,13 @@ can find each other via `localhost`. The containers in a Pod can also communicat with each other using standard inter-process communications like SystemV semaphores or POSIX shared memory. Containers in different Pods have distinct IP addresses and can not communicate by IPC without -[special configuration](/docs/concepts/policy/pod-security-policy/). +and can not communicate by OS-level IPC without special configuration. Containers that want to interact with a container running in a different Pod can use IP networking to communicate. --> 在同一个 Pod 内，所有容器共享一个 IP 地址和端口空间，并且可以通过 `localhost` 发现对方。 他们也能通过如 SystemV 信号量或 POSIX 共享内存这类标准的进程间通信方式互相通信。 -不同 Pod 中的容器的 IP 地址互不相同，没有 -[特殊配置](/zh/docs/concepts/policy/pod-security-policy/) 就不能使用 IPC 进行通信。 +不同 Pod 中的容器的 IP 地址互不相同，没有特殊配置，无法通过 OS 级 IPC 进行通信就不能使用 IPC 进行通信。 如果某容器希望与运行于其他 Pod 中的容器通信，可以通过 IP 联网的方式实现。 -* 了解如何[使用临时调试容器来进行调试](/zh/docs/tasks/debug-application-cluster/debug-running-pod/#ephemeral-container) +* 了解如何[使用临时调试容器来进行调试](/zh/docs/tasks/debug/debug-application/debug-running-pod/#ephemeral-container) diff --git a/content/zh/docs/contribute/style/diagram-guide.md b/content/zh/docs/contribute/style/diagram-guide.md index de9b474b43..7a88803e45 100644 --- a/content/zh/docs/contribute/style/diagram-guide.md +++ b/content/zh/docs/contribute/style/diagram-guide.md @@ -860,7 +860,7 @@ K8s components to start a container. 图 8 给出的是一个 Mermaid 时序图，展示启动容器时 K8s 组件间的控制流。 -{{< figure src="/docs/images/diagram-guide-example-3.svg" alt="K8s system flow diagram" class="diagram-large" caption="Figure 8. K8s system flow diagram" link="https://mermaid-js.github.io/mermaid-live-editor/edit/#eyJjb2RlIjoiJSV7aW5pdDp7XCJ0aGVtZVwiOlwibmV1dHJhbFwifX0lJVxuc2VxdWVuY2VEaWFncmFtXG4gICAgYWN0b3IgbWVcbiAgICBwYXJ0aWNpcGFudCBhcGlTcnYgYXMgY29udHJvbCBwbGFuZTxicj48YnI-YXBpLXNlcnZlclxuICAgIHBhcnRpY2lwYW50IGV0Y2QgYXMgY29udHJvbCBwbGFuZTxicj48YnI-ZXRjZCBkYXRhc3RvcmVcbiAgICBwYXJ0aWNpcGFudCBjbnRybE1nciBhcyBjb250cm9sIHBsYW5lPGJyPjxicj5jb250cm9sbGVyPGJyPm1hbmFnZXJcbiAgICBwYXJ0aWNpcGFudCBzY2hlZCBhcyBjb250cm9sIHBsYW5lPGJyPjxicj5zY2hlZHVsZXJcbiAgICBwYXJ0aWNpcGFudCBrdWJlbGV0IGFzIG5vZGU8YnI-PGJyPmt1YmVsZXRcbiAgICBwYXJ0aWNpcGFudCBjb250YWluZXIgYXMgbm9kZTxicj48YnI-Y29udGFpbmVyPGJyPnJ1bnRpbWVcbiAgICBtZS0-PmFwaVNydjogMS4ga3ViZWN0bCBjcmVhdGUgLWYgcG9kLnlhbWxcbiAgICBhcGlTcnYtLT4-ZXRjZDogMi4gc2F2ZSBuZXcgc3RhdGVcbiAgICBjbnRybE1nci0-PmFwaVNydjogMy4gY2hlY2sgZm9yIGNoYW5nZXNcbiAgICBzY2hlZC0-PmFwaVNydjogNC4gd2F0Y2ggZm9yIHVuYXNzaWduZWQgcG9kcyhzKVxuICAgIGFwaVNydi0-PnNjaGVkOiA1LiBub3RpZnkgYWJvdXQgcG9kIHcgbm9kZW5hbWU9XCIgXCJcbiAgICBzY2hlZC0-PmFwaVNydjogNi4gYXNzaWduIHBvZCB0byBub2RlXG4gICAgYXBpU3J2LS0-PmV0Y2Q6IDcuIHNhdmUgbmV3IHN0YXRlXG4gICAga3ViZWxldC0-PmFwaVNydjogOC4gbG9vayBmb3IgbmV3bHkgYXNzaWduZWQgcG9kKHMpXG4gICAgYXBpU3J2LT4-a3ViZWxldDogOS4gYmluZCBwb2QgdG8gbm9kZVxuICAgIGt1YmVsZXQtPj5jb250YWluZXI6IDEwLiBzdGFydCBjb250YWluZXJcbiAgICBrdWJlbGV0LT4-YXBpU3J2OiAxMS4gdXBkYXRlIHBvZCBzdGF0dXNcbiAgICBhcGlTcnYtLT4-ZXRjZDogMTIuIHNhdmUgbmV3IHN0YXRlIiwibWVybWFpZCI6IntcbiAgXCJ0aGVtZVwiOiBcImRlZmF1bHRcIlxufSIsInVwZGF0ZUVkaXRvciI6ZmFsc2UsImF1dG9TeW5jIjp0cnVlLCJ1cGRhdGVEaWFncmFtIjp0cnVlfQ" >}} +{{< figure src="/zh/docs/images/diagram-guide-example-3.svg" alt="K8s system flow diagram" class="diagram-large" caption="Figure 8. K8s system flow diagram" link="https://mermaid-js.github.io/mermaid-live-editor/edit/#eyJjb2RlIjoiJSV7aW5pdDp7XCJ0aGVtZVwiOlwibmV1dHJhbFwifX0lJVxuc2VxdWVuY2VEaWFncmFtXG4gICAgYWN0b3IgbWVcbiAgICBwYXJ0aWNpcGFudCBhcGlTcnYgYXMgY29udHJvbCBwbGFuZTxicj48YnI-YXBpLXNlcnZlclxuICAgIHBhcnRpY2lwYW50IGV0Y2QgYXMgY29udHJvbCBwbGFuZTxicj48YnI-ZXRjZCBkYXRhc3RvcmVcbiAgICBwYXJ0aWNpcGFudCBjbnRybE1nciBhcyBjb250cm9sIHBsYW5lPGJyPjxicj5jb250cm9sbGVyPGJyPm1hbmFnZXJcbiAgICBwYXJ0aWNpcGFudCBzY2hlZCBhcyBjb250cm9sIHBsYW5lPGJyPjxicj5zY2hlZHVsZXJcbiAgICBwYXJ0aWNpcGFudCBrdWJlbGV0IGFzIG5vZGU8YnI-PGJyPmt1YmVsZXRcbiAgICBwYXJ0aWNpcGFudCBjb250YWluZXIgYXMgbm9kZTxicj48YnI-Y29udGFpbmVyPGJyPnJ1bnRpbWVcbiAgICBtZS0-PmFwaVNydjogMS4ga3ViZWN0bCBjcmVhdGUgLWYgcG9kLnlhbWxcbiAgICBhcGlTcnYtLT4-ZXRjZDogMi4gc2F2ZSBuZXcgc3RhdGVcbiAgICBjbnRybE1nci0-PmFwaVNydjogMy4gY2hlY2sgZm9yIGNoYW5nZXNcbiAgICBzY2hlZC0-PmFwaVNydjogNC4gd2F0Y2ggZm9yIHVuYXNzaWduZWQgcG9kcyhzKVxuICAgIGFwaVNydi0-PnNjaGVkOiA1LiBub3RpZnkgYWJvdXQgcG9kIHcgbm9kZW5hbWU9XCIgXCJcbiAgICBzY2hlZC0-PmFwaVNydjogNi4gYXNzaWduIHBvZCB0byBub2RlXG4gICAgYXBpU3J2LS0-PmV0Y2Q6IDcuIHNhdmUgbmV3IHN0YXRlXG4gICAga3ViZWxldC0-PmFwaVNydjogOC4gbG9vayBmb3IgbmV3bHkgYXNzaWduZWQgcG9kKHMpXG4gICAgYXBpU3J2LT4-a3ViZWxldDogOS4gYmluZCBwb2QgdG8gbm9kZVxuICAgIGt1YmVsZXQtPj5jb250YWluZXI6IDEwLiBzdGFydCBjb250YWluZXJcbiAgICBrdWJlbGV0LT4-YXBpU3J2OiAxMS4gdXBkYXRlIHBvZCBzdGF0dXNcbiAgICBhcGlTcnYtLT4-ZXRjZDogMTIuIHNhdmUgbmV3IHN0YXRlIiwibWVybWFpZCI6IntcbiAgXCJ0aGVtZVwiOiBcImRlZmF1bHRcIlxufSIsInVwZGF0ZUVkaXRvciI6ZmFsc2UsImF1dG9TeW5jIjp0cnVlLCJ1cGRhdGVEaWFncmFtIjp0cnVlfQ" >}} + + + diff --git a/content/zh/docs/reference/glossary/pod-security-policy.md b/content/zh/docs/reference/glossary/pod-security-policy.md index 5c8475292f..f80416fb44 100644 --- a/content/zh/docs/reference/glossary/pod-security-policy.md +++ b/content/zh/docs/reference/glossary/pod-security-policy.md @@ -2,7 +2,7 @@ title: Pod 安全策略 id: pod-security-policy date: 2018-04-12 -full_link: /zh/docs/concepts/policy/pod-security-policy/ +full_link: /zh/docs/concepts/security/pod-security-policy/ short_description: > 为 Pod 的创建和更新操作启用细粒度的授权。 @@ -17,7 +17,7 @@ tags: title: Pod Security Policy id: pod-security-policy date: 2018-04-12 -full_link: /docs/concepts/policy/pod-security-policy/ +full_link: /docs/concepts/security/pod-security-policy/ short_description: > Enables fine-grained authorization of pod creation and updates. @@ -43,4 +43,9 @@ A cluster-level resource that controls security sensitive aspects of the Pod spe Pod 安全策略是集群级别的资源，它控制着 Pod 规约中的安全性敏感的内容。 `PodSecurityPolicy`对象定义了一组条件以及相关字段的默认值，Pod 运行时必须满足这些条件。Pod 安全策略控制实现上体现为一个可选的准入控制器。 + +PodSecurityPolicy 自 Kubernetes v1.21 起已弃用，并将在 v1.25 中删除。 +我们建议迁移到 [Pod 安全准入](/zh/docs/concepts/security/pod-security-admission/)或第三方准入插件。 diff --git a/content/zh/docs/reference/labels-annotations-taints/audit-annotations.md b/content/zh/docs/reference/labels-annotations-taints/audit-annotations.md index 2ab584e4ed..a90160888b 100644 --- a/content/zh/docs/reference/labels-annotations-taints/audit-annotations.md +++ b/content/zh/docs/reference/labels-annotations-taints/audit-annotations.md @@ -88,7 +88,7 @@ that was transgressed as well as the specific policies on the fields that were violated from the PodSecurity enforcement. See [Pod Security Standards](/docs/concepts/security/pod-security-standards/) -for more information +for more information. --> ## pod-security.kubernetes.io/audit-violations {#pod-security-kubernetes-io-audit-violations} @@ -99,4 +99,38 @@ PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container 注解值给出审计策略违规的详细说明，它包含所违反的 [Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/)级别以及 PodSecurity 执行中违反的特定策略及对应字段。 -有关详细信息，请参阅 [Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/)。 \ No newline at end of file +有关详细信息，请参阅 [Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/)。 + + +## authorization.k8s.io/decision {#authorization-k8s-io-decision} + +例子：`authorization.k8s.io/decision: "forbid"` + +此注解在 Kubernetes 审计日志中表示请求是否获得授权。 + +有关详细信息，请参阅[审计](/zh/docs/tasks/debug-application-cluster/audit/)。 + + +## authorization.k8s.io/reason {#authorization-k8s-io-reason} + +例子：`authorization.k8s.io/reason: "Human-readable reason for the decision"` + +此注解给出了 Kubernetes 审计日志中 [decision](#authorization-k8s-io-decision) 的原因。 + +有关详细信息，请参阅[审计](/zh/docs/tasks/debug-application-cluster/audit/)。 \ No newline at end of file diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm.md index 8ebdeb3c1d..83ece115b2 100644 --- a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm.md +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm.md @@ -1,8 +1,11 @@ +kubeadm: 轻松创建一个安全的 Kubernetes 集群 ### 摘要 -kubeadm 操作的帮助信息 +

kubeadm 操作的帮助信息

@@ -102,9 +105,9 @@ kubeadm 操作的帮助信息 -[实验] 指向 '真实' 宿主机根文件系统的路径。 +

[实验] 指向 '真实' 宿主机根文件系统的路径。

diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha.md deleted file mode 100644 index f6978fcb6d..0000000000 --- a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha.md +++ /dev/null @@ -1,69 +0,0 @@ - - - -### 概要 - - - -kubeadm 实验子命令 - - - -### 选项 - - ---- - - - - - - - - - - -
-h, --help
- -alpha 操作的帮助命令 -
- - - -### 从父命令继承的选项 - - ---- - - - - - - - - - - -
--rootfs string
- -[实验] 指向 '真实' 宿主机的根文件系统的路径。 -
- diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs.md index 9e34c47542..15278730f5 100644 --- a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs.md +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs.md @@ -1,3 +1,18 @@ + + + +处理 Kubernetes 证书的相关命令 -与处理 kubernetes 证书相关的命令 +处理 Kubernetes 证书相关的命令 -certs 命令的帮助 + +

certs 命令的帮助

@@ -48,8 +63,8 @@ Commands related to handling kubernetes certificates --rootfs string - -[实验] 到'真实'主机根文件系统的路径。 + +

[实验] 到'真实'主机根文件系统的路径。

diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_certificate-key.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_certificate-key.md index b008e44b38..ab4f4b5356 100644 --- a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_certificate-key.md +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_certificate-key.md @@ -1,3 +1,18 @@ + + + +生成证书密钥 certificate-key 操作的帮助命令 +

@@ -64,10 +81,12 @@ certificate-key 操作的帮助命令 +

[实验] 到 '真实' 主机根文件系统的路径。 +

diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew.md index 58fff42d32..d8102a19ce 100644 --- a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew.md +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew.md @@ -1,3 +1,18 @@ + + + +为 Kubernetes 集群更新证书 renew 操作的帮助命令 +

@@ -58,10 +75,12 @@ renew 操作的帮助命令 +

[实验] 到 '真实' 主机根文件系统的路径。 +

diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_etcd-server.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_etcd-server.md index 0f5fb4726e..c669e2d0ee 100644 --- a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_etcd-server.md +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_etcd-server.md @@ -6,9 +6,9 @@ -生成用于提供 etcd 服务的证书，并将其保存到 etcd/server.cert 和 etcd/server.key 文件中。 +生成用于提供 etcd 服务的证书，并将其保存到 etcd/server.crt 和 etcd/server.key 文件中。 -保存和存储证书的路径。 +

保存和存储证书的路径。

@@ -64,9 +64,9 @@ The path where to save and store the certificates. -kubeadm 配置文件的路径。 +

kubeadm 配置文件的路径。

@@ -76,9 +76,9 @@ kubeadm 配置文件的路径。 -etcd-server 操作的帮助命令 +

etcd-server 操作的帮助命令

@@ -93,9 +93,9 @@ etcd-server 操作的帮助命令 -为控制平面指定特定的 Kubernetes 版本。 +

为控制平面指定特定的 Kubernetes 版本。

@@ -122,9 +122,9 @@ Choose a specific Kubernetes version for the control plane. -[实验] 到 '真实' 主机根文件系统的路径。 +

[实验] 到 '真实' 主机根文件系统的路径。

diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade.md index d03885437f..b1a6499f94 100644 --- a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade.md +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade.md @@ -1,3 +1,8 @@ + + +此命令能将集群平滑升级到新版本 -upgrade 操作的帮助命令 +

upgrade 操作的帮助命令

@@ -62,9 +67,9 @@ upgrade 操作的帮助命令 -[实验] 指向 '真实' 宿主机根文件系统的路径。 +

[实验] 指向 '真实' 宿主机根文件系统的路径。

diff --git a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-join.md b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-join.md index e01ff5eea0..9b0fc237d9 100644 --- a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-join.md +++ b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-join.md @@ -67,8 +67,6 @@ For control-plane nodes additional steps are performed: 1. Generating control-plane component manifests, certificates and kubeconfig. 1. Adding new local etcd member. - -1. Adding this node to the ClusterStatus of the kubeadm cluster. --> 对于控制平面节点，执行额外的步骤： @@ -78,8 +76,6 @@ For control-plane nodes additional steps are performed: 1. 添加新的本地 etcd 成员。 -1. 将此节点添加到 kubeadm 集群的 ClusterStatus。 - @@ -123,6 +119,13 @@ For example: sudo kubeadm join --skip-phases=preflight --config=config.yaml ``` +{{< feature-state for_k8s_version="v1.22" state="beta" >}} + + +或者，你可以使用 `JoinConfiguration` 中的 `skipPhases` 字段。 + @@ -523,11 +526,11 @@ the [kubeadm config migrate](/docs/reference/setup-tools/kubeadm/kubeadm-config/ 命令转换。 -有关配置的字段和用法的更多信息，你可以导航到我们的 API 参考页 -并从[列表]中选择一个版本(https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#pkg-subdirectories)。 +有关配置的字段和用法的更多信息，你可以导航到我们的 +[API 参考页](/zh/docs/reference/config-api/kubeadm-config.v1beta3/)。 ## {{% heading "whatsnext" %}} diff --git a/content/zh/docs/setup/production-environment/_index.md b/content/zh/docs/setup/production-environment/_index.md index b3b1d0ce0c..0021a557f7 100644 --- a/content/zh/docs/setup/production-environment/_index.md +++ b/content/zh/docs/setup/production-environment/_index.md @@ -401,12 +401,12 @@ based on demand. - *安装节点健康检查*：对于重要的工作负载，你会希望确保节点以及在节点上 运行的 Pod 处于健康状态。通过使用 - [Node Problem Detector](/zh/docs/tasks/debug-application-cluster/monitor-node-health/)， + [Node Problem Detector](/zh/docs/tasks/debug/debug-cluster/monitor-node-health/)， 你可以确保你的节点是健康的。 ## 在你开始之前 @@ -278,7 +278,34 @@ with one of its main goals being that this approach should not break compatibili 目前，用户需要将 Linux 和 Windows 工作负载运行在各自特定的操作系统的节点上， 因而需要结合使用污点和节点选择算符。 这可能仅给 Windows 用户造成不便。 推荐的方法概述如下，其主要目标之一是该方法不应破坏与现有 Linux 工作负载的兼容性。 + + {{< note >}} +如果 `IdentifyPodOS` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)是启用的， +你可以（并且应该）为 Pod 设置 `.spec.os.name` 以表明该 Pod +中的容器所针对的操作系统。 对于运行 Linux 容器的 Pod，设置 +`.spec.os.name` 为 `linux`。 对于运行 Windows 容器的 Pod，设置 `.spec.os.name` +为 `Windows`。 + +在将 Pod 分配给节点时，调度程序不使用 `.spec.os.name` 的值。你应该使用正常的 Kubernetes +机制[将 Pod 分配给节点](/zh/docs/concepts/scheduling-eviction/assign-pod-node/)， +确保集群的控制平面将 Pod 放置到适合运行的操作系统。 +对 Windows Pod 的调度没有影响，因此仍然需要污点、容忍度以及节点选择器， +以确保 Windows Pod 调度至合适的 Windows 节点。 + {{< /note >}} diff --git a/content/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md b/content/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md index 25f10b0fed..9704cf3760 100644 --- a/content/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md +++ b/content/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md @@ -18,12 +18,12 @@ min-kubernetes-server-version: 1.18 This page explains how to upgrade a Kubernetes cluster created with kubeadm from version {{< skew currentVersionAddMinor -1 >}}.x to version {{< skew currentVersion >}}.x, and from version {{< skew currentVersion >}}.x to {{< skew currentVersion >}}.y (where `y > x`). Skipping MINOR versions -when upgrading is unsupported. +when upgrading is unsupported. For more details, please visit [Version Skew Policy](https://kubernetes.io/releases/version-skew-policy/). --> 本页介绍如何将 `kubeadm` 创建的 Kubernetes 集群从 {{< skew currentVersionAddMinor -1 >}}.x 版本 升级到 {{< skew currentVersion >}}.x 版本以及从 {{< skew currentVersion >}}.x 升级到 {{< skew currentVersion >}}.y（其中 `y > x`）。略过次版本号的升级是 -不被支持的。 +不被支持的。更多详情请访问[版本倾斜政策](https://kubernetes.io/releases/version-skew-policy/)。 + ### 附加信息 -- 在对 kubelet 作次版本升版时需要[腾空节点](/zh/docs/tasks/administer-cluster/safely-drain-node/)。 - 对于控制面节点，其上可能运行着 CoreDNS Pods 或者其它非常重要的负载。 +- 下述说明了在升级过程中何时腾空每个节点。如果你正在对任何 kubelet 进行小版本升级， + 你需要先腾空待升级的节点（或多个节点）。对于控制面节点，其上可能运行着 CoreDNS Pods + 或者其它非常重要的负载。更多信息见[腾空节点](/zh/docs/tasks/administer-cluster/safely-drain-node/)。 - 升级后，因为容器规约的哈希值已更改，所有容器都会被重新启动。 + + +- 要验证 kubelet 服务在升级后是否成功重启，可以执行 `systemctl status kubelet` + 或 `journalctl -xeu kubelet` 查看服务日志。 +- 不建议使用 `kubeadm upgrade` 的 `--config 参数和 [kubeadm 配置 API 类型](/zh/docs/reference/config-api/kubeadm-config.v1beta3) + 来重新配置集群，这样会产生意想不到的结果。请按照[重新配置 kubeadm 集群](/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-reconfigure) + 中的步骤来进行。 + 一旦该命令结束，你应该会看到： - ``` + ```console [upgrade/successful] SUCCESS! Your cluster was upgraded to "v{{< skew currentVersion >}}.x". Enjoy! [upgrade/kubelet] Now that your control plane is upgraded, please proceed with upgrading your kubelets if you haven't already done so. @@ -259,7 +283,7 @@ Same as the first control plane node but use: --> 与第一个控制面节点相同，但是使用： -``` +```shell sudo kubeadm upgrade node ``` @@ -268,7 +292,7 @@ instead of: --> 而不是： -``` +```shell sudo kubeadm upgrade apply ``` @@ -299,34 +323,33 @@ Also calling `kubeadm upgrade plan` and upgrading the CNI provider plugin is no ### 升级 kubelet 和 kubectl -- 升级 kubelet 和 kubectl +- 升级 kubelet 和 kubectl： {{< tabs name="k8s_install_kubelet" >}} {{% tab name="Ubuntu、Debian 或 HypriotOS" %}} - 

-  # 用最新的补丁版本替换 {{< skew currentVersion >}}.x-00 中的 x
-  apt-mark unhold kubelet kubectl && \
-  apt-get update && apt-get install -y kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 && \
-  apt-mark hold kubelet kubectl
-  - 
-  # 从 apt-get 的 1.1 版本开始，你也可以使用下面的方法：
-  apt-get update && \
-  apt-get install -y --allow-change-held-packages kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00
-
+ ```shell + # 用最新的补丁版本替换 {{< skew currentVersion >}}.x-00 中的 x + apt-mark unhold kubelet kubectl && \ + apt-get update && apt-get install -y kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 && \ + apt-mark hold kubelet kubectl + ``` + {{% /tab %}} {{% tab name="CentOS、RHEL 或 Fedora" %}} - - 
 
-  # 用最新的补丁版本号替换 {{< skew currentVersion >}}.x-00 中的 x
-  yum install -y kubelet-{{< skew currentVersion >}}.x-0 kubectl-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes
-
+ + ```shell + # 用最新的补丁版本号替换 {{< skew currentVersion >}}.x-00 中的 x + yum install -y kubelet-{{< skew currentVersion >}}.x-0 kubectl-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes + ``` + {{% /tab %}} {{< /tabs >}} +
-`STATUS` 应显示所有节点为 `Ready` 状态，并且版本号已经被更新。 +`STATUS` 应显示所有节点为 `Ready` 状态，并且版本号已经被更新。 `kubeadm upgrade node` 在工作节点上完成以下工作： -- 从集群取回 kubeadm `ClusterConfiguration`。 +- 从集群取回 kubeadm `ClusterConfiguration`。 - 为本节点升级 kubelet 配置。 - diff --git a/content/zh/docs/tasks/configmap-secret/managing-secret-using-kubectl.md b/content/zh/docs/tasks/configmap-secret/managing-secret-using-kubectl.md index 8e2dd7d202..86d0c9266b 100644 --- a/content/zh/docs/tasks/configmap-secret/managing-secret-using-kubectl.md +++ b/content/zh/docs/tasks/configmap-secret/managing-secret-using-kubectl.md @@ -184,6 +184,10 @@ Now you can decode the `password` data: 现在你可以解码 `password` 的数据： ```shell +# 这是一个用于文档说明的示例。 +# 如果你这样做，数据 'MWYyZDFlMmU2N2Rm' 可以存储在你的 shell 历史中。 +# 可以进入你电脑的人可以找到那个记住的命令并可以在你不知情的情况下 base-64 解码这个 Secret。 +# 通常最好将这些步骤结合起来，如页面后面所示。 echo 'MWYyZDFlMmU2N2Rm' | base64 --decode ``` @@ -194,6 +198,21 @@ echo 'MWYyZDFlMmU2N2Rm' | base64 --decode 1f2d1e2e67df ``` + +为了避免在 shell 历史记录中存储 Secret 的编码值，可以执行如下命令: + +```shell +kubectl get secret db-user-pass -o jsonpath='{.data.password}' | base64 --decode +``` + + +输出应与上述类似。 + ## 清理 {#clean-up} diff --git a/content/zh/docs/tasks/configure-pod-container/configure-projected-volume-storage.md b/content/zh/docs/tasks/configure-pod-container/configure-projected-volume-storage.md index d0ff476b38..66230434d9 100644 --- a/content/zh/docs/tasks/configure-pod-container/configure-projected-volume-storage.md +++ b/content/zh/docs/tasks/configure-pod-container/configure-projected-volume-storage.md @@ -59,7 +59,7 @@ Here is the configuration file for the Pod: ```shell # 创建包含用户名和密码的文件: echo -n "admin" > ./username.txt - echo -n "1f2d1e2e67df" > ./password.txt--> + echo -n "1f2d1e2e67df" > ./password.txt # 将上述文件引用到 Secret： kubectl create secret generic user --from-file=./username.txt diff --git a/content/zh/docs/tasks/configure-pod-container/security-context.md b/content/zh/docs/tasks/configure-pod-container/security-context.md index 1cb617ae85..29e5a3afb3 100644 --- a/content/zh/docs/tasks/configure-pod-container/security-context.md +++ b/content/zh/docs/tasks/configure-pod-container/security-context.md @@ -631,7 +631,7 @@ in the `securityContext` section of your Pod or Container manifest. The [SeccompProfile](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#seccompprofile-v1-core) object consisting of `type` and `localhostProfile`. Valid options for `type` include `RuntimeDefault`, `Unconfined`, and -`Localhost`. `localhostProfile` must only be set set if `type: Localhost`. It +`Localhost`. `localhostProfile` must only be set if `type: Localhost`. It indicates the path of the pre-configured profile on the node, relative to the kubelet's configured Seccomp profile location (configured with the `-root-dir` flag). diff --git a/content/zh/docs/tasks/debug-application-cluster/crictl.md b/content/zh/docs/tasks/debug-application-cluster/crictl.md index f8e126f281..d928d1d0c5 100644 --- a/content/zh/docs/tasks/debug-application-cluster/crictl.md +++ b/content/zh/docs/tasks/debug-application-cluster/crictl.md @@ -45,8 +45,8 @@ Kubernetes node. `crictl` and its source are hosted in the -`crictl` 默认连接到 `unix:///var/run/dockershim.sock`。 -对于其他的运行时，你可以用多种不同的方法设置端点： +你可以用以下方法之一来为 `crictl` 设置端点： -- 通过设置参数 `--runtime-endpoint` 和 `--image-endpoint` -- 通过设置环境变量 `CONTAINER_RUNTIME_ENDPOINT` 和 `IMAGE_SERVICE_ENDPOINT` -- 通过在配置文件中设置端点 `--config=/etc/crictl.yaml` +- 设置参数 `--runtime-endpoint` 和 `--image-endpoint`。 +- 设置环境变量 `CONTAINER_RUNTIME_ENDPOINT` 和 `IMAGE_SERVICE_ENDPOINT`。 +- 在配置文件 `--config=/etc/crictl.yaml` 中设置端点。 + 要设置不同的文件，可以在运行 `crictl` 时使用 `--config=PATH_TO_FILE` 标志。 要查看或编辑当前配置，请查看或编辑 `/etc/crictl.yaml` 的内容。 +例如，使用 `containerd` 容器运行时的配置会类似于这样： -```shell -cat /etc/crictl.yaml ``` -``` -runtime-endpoint: unix:///var/run/dockershim.sock -image-endpoint: unix:///var/run/dockershim.sock +runtime-endpoint: unix:///var/run/containerd/containerd.sock +image-endpoint: unix:///var/run/containerd/containerd.sock timeout: 10 debug: true ``` + +要进一步了解 `crictl`，参阅 +[`crictl` 文档](https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md)。 + +输出类似于： + +``` POD ID CREATED STATE NAME NAMESPACE ATTEMPT 926f1b5a1d33a About a minute ago Ready sh-84d7dcf559-4r2gq default 0 4dccb216c4adb About a minute ago Ready nginx-65899c769f-wv2gp default 0 @@ -157,7 +169,12 @@ List pods by name: crictl pods --name nginx-65899c769f-wv2gp ``` -```none + +输出类似于这样： + +``` POD ID CREATED STATE NAME NAMESPACE ATTEMPT 4dccb216c4adb 2 minutes ago Ready nginx-65899c769f-wv2gp default 0 ``` @@ -170,6 +187,12 @@ List pods by label: ```shell crictl pods --label run=nginx ``` + + +输出类似于这样： + ```none POD ID CREATED STATE NAME NAMESPACE ATTEMPT 4dccb216c4adb 2 minutes ago Ready nginx-65899c769f-wv2gp default 0 @@ -187,6 +210,12 @@ List all images: ```shell crictl images ``` + + +输出类似于这样： + ```none IMAGE TAG IMAGE ID SIZE busybox latest 8c811b4aec35f 1.15MB @@ -203,6 +232,12 @@ List images by repository: ```shell crictl images nginx ``` + + +输出类似于这样： + ```none IMAGE TAG IMAGE ID SIZE nginx latest cd5239a0906a6 109MB @@ -216,6 +251,12 @@ Only list image IDs: ```shell crictl images -q ``` + + +输出类似于这样： + ```none sha256:8c811b4aec35f259572d0f79207bc0678df4c736eeec50bc9fec37ed936a472a sha256:e179bbfe5d238de6069f3b03fccbecc3fb4f2019af741bfff1233c4d7b2970c5 @@ -235,6 +276,12 @@ List all containers: ```shell crictl ps -a ``` + + +输出类似于这样： + ```none CONTAINER ID IMAGE CREATED STATE NAME ATTEMPT 1f73f2d81bf98 busybox@sha256:141c253bc4c3fd0a201d32dc1f493bcf3fff003b6df416dea4f41046e0f37d47 7 minutes ago Running sh 1 @@ -251,6 +298,12 @@ List running containers: ```shell crictl ps ``` + + +输出类似于这样： + ```none CONTAINER ID IMAGE CREATED STATE NAME ATTEMPT 1f73f2d81bf98 busybox@sha256:141c253bc4c3fd0a201d32dc1f493bcf3fff003b6df416dea4f41046e0f37d47 6 minutes ago Running sh 1 @@ -266,6 +319,12 @@ CONTAINER ID IMAGE ```shell crictl exec -i -t 1f73f2d81bf98 ls ``` + + +输出类似于这样： + ```none bin dev etc home proc root sys tmp usr var ``` @@ -282,6 +341,12 @@ Get all container logs: ```shell crictl logs 87d3992f84f74 ``` + + +输出类似于这样： + ```none 10.240.0.96 - - [06/Jun/2018:02:45:49 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.47.0" "-" 10.240.0.96 - - [06/Jun/2018:02:45:50 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.47.0" "-" @@ -296,6 +361,12 @@ Get only the latest `N` lines of logs: ```shell crictl logs --tail=1 87d3992f84f74 ``` + + +输出类似于这样： + ```none 10.240.0.96 - - [06/Jun/2018:02:45:51 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.47.0" "-" ``` @@ -312,8 +383,10 @@ deleted by the Kubelet. 用 `crictl` 运行 Pod 沙盒对容器运行时排错很有帮助。 在运行的 Kubernetes 集群中，沙盒会随机地被 kubelet 停止和删除。 -1. - 编写下面的 JSON 文件： + +1. 编写下面的 JSON 文件： ```json { @@ -329,14 +402,18 @@ deleted by the Kubelet. } ``` -2. - 使用 `crictl runp` 命令应用 JSON 文件并运行沙盒。 + +2. 使用 `crictl runp` 命令应用 JSON 文件并运行沙盒。 ```shell crictl runp pod-config.json ``` - + 返回了沙盒的 ID。 - 拉取 busybox 镜像 + +1. 拉取 busybox 镜像 - ```bash + ```shell crictl pull busybox + ``` + ```none Image is up to date for busybox@sha256:141c253bc4c3fd0a201d32dc1f493bcf3fff003b6df416dea4f41046e0f37d47 ``` -2. - 创建 Pod 和容器的配置： + +2. 创建 Pod 和容器的配置： - + **Pod 配置**： - ```yaml + + ```json { "metadata": { "name": "nginx-sandbox", @@ -378,9 +464,12 @@ deleted by the Kubelet. } ``` - + **容器配置**： - ```yaml + + ```json { "metadata": { "name": "busybox" @@ -397,22 +486,31 @@ deleted by the Kubelet. } ``` -3. - 创建容器，传递先前创建的 Pod 的 ID、容器配置文件和 Pod 配置文件。返回容器的 ID。 + returned. +--> +3. 创建容器，传递先前创建的 Pod 的 ID、容器配置文件和 Pod 配置文件。返回容器的 ID。 ```bash crictl create f84dd361f8dc51518ed291fbadd6db537b0496536c1d2d6c05ff943ce8c9a54f container-config.json pod-config.json ``` -4. - 查询所有容器并确认新创建的容器状态为 `Created`。 + +4. 查询所有容器并确认新创建的容器状态为 `Created`。 ```bash crictl ps -a ``` + + 输出类似于这样： + ```none CONTAINER ID IMAGE CREATED STATE NAME ATTEMPT 3e025dd50a72d busybox 32 seconds ago Created busybox 0 @@ -430,7 +528,13 @@ To start a container, pass its ID to `crictl start`: ```shell crictl start 3e025dd50a72d956c4f14881fbb5b1080c9275674e95fb67f965f6478a957d60 ``` -```none + + +输出类似于这样： + +``` 3e025dd50a72d956c4f14881fbb5b1080c9275674e95fb67f965f6478a957d60 ``` @@ -442,136 +546,23 @@ Check the container has its state set to `Running`. ```shell crictl ps ``` -```none -CONTAINER ID IMAGE CREATED STATE NAME ATTEMPT -3e025dd50a72d busybox About a minute ago Running busybox 0 + + +输出类似于这样： + ``` - +CONTAINER ID IMAGE CREATED STATE NAME ATTEMPT +3e025dd50a72d busybox About a minute ago Running busybox 0 +``` + +## {{% heading "whatsnext" %}} -更多信息请参考 [kubernetes-sigs/cri-tools](https://github.com/kubernetes-sigs/cri-tools)。 +* [进一步了解 `crictl`](https://github.com/kubernetes-sigs/cri-tools). +* [将 `docker` CLI 命令映射到 `crictl`](/zh/docs/reference/tools/map-crictl-dockercli/). - -## Docker CLI 和 crictl 的映射 - - -以下的映射表格只适用于 Docker CLI v1.40 和 crictl v1.19.0 版本。 -请注意该表格并不详尽。例如，其中不包含 Docker CLI 的实验性命令。 - - -{{< note >}} -尽管有些命令的输出缺少了一些数据列，CRICTL 的输出格式与 Docker CLI 是类似的。 -如果你的脚本程序需要解析命令的输出，请确认检查该特定命令的输出。 -{{< /note >}} - - -### 获取调试信息 - -{{< table caption="Docker CLI 和 crictl 的映射 - 获取调试信息" >}} - -docker cli | crictl | 描述 | 不支持的功能 --- | -- | -- | -- -`attach` | `attach` | 连接到一个运行中的容器 | `--detach-keys`, `--sig-proxy` -`exec` | `exec` | 在运行中的容器里运行一个命令 | `--privileged`, `--user`, `--detach-keys` -`images` | `images` | 列举镜像 |   -`info` | `info` | 显示系统级的信息 |   -`inspect` | `inspect`, `inspecti` | 返回容器、镜像或者任务的详细信息 |   -`logs` | `logs` | 获取容器的日志 | `--details` -`ps` | `ps` | 列举容器 |   -`stats` | `stats` | 实时显示容器的资源使用统计信息 | 列：NET/BLOCK I/O, PIDs -`version` | `version` | 显示运行时（Docker、ContainerD、或者其他) 的版本信息 |   -{{< /table >}} - - -### 进行改动 - -{{< table caption="Docker CLI 和 crictl 的映射 - 进行改动" >}} - -docker cli | crictl | 描述 | 不支持的功能 --- | -- | -- | -- -`create` | `create` | 创建一个新的容器 |   -`kill` | `stop` (timeout=0) | 杀死一个或多个正在运行的容器 | `--signal` -`pull` | `pull` | 从镜像仓库拉取镜像或者代码仓库 | `--all-tags`, `--disable-content-trust` -`rm` | `rm` | 移除一个或多个容器 |   -`rmi` | `rmi` | 移除一个或多个镜像 |   -`run` | `run` | 在新容器里运行一个命令 |   -`start` | `start` | 启动一个或多个停止的容器 | `--detach-keys` -`stop` | `stop` | 停止一个或多个正运行的容器 |   -`update` | `update` | 更新一个或多个容器的配置 | CRI 不支持 `--restart`、`--blkio-weight` 以及一些其他的资源限制选项。 -{{< /table >}} - - -### 仅 crictl 支持 - -{{< table caption="Docker CLI 和 crictl 的映射 - 仅 crictl 支持" >}} - -crictl | 描述 --- | -- -`imagefsinfo` | 返回镜像的文件系统信息 -`inspectp` | 显示一个或多个 Pod 的状态 -`port-forward` | 转发本地端口到 Pod -`pods` | 列举 Pod -`runp` | 运行一个新的 Pod -`rmp` | 移除一个或多个 Pod -`stopp` | 停止一个或多个正运行的 Pod -{{< /table >}} diff --git a/content/zh/docs/tasks/debug-application-cluster/debug-application-introspection.md b/content/zh/docs/tasks/debug-application-cluster/debug-application-introspection.md index 7210356959..0c9350aee4 100644 --- a/content/zh/docs/tasks/debug-application-cluster/debug-application-introspection.md +++ b/content/zh/docs/tasks/debug-application-cluster/debug-application-introspection.md @@ -1,4 +1,4 @@ ---- +:--- reviewers: - janetkuo - thockin diff --git a/content/zh/docs/tasks/debug-application-cluster/debug-application.md b/content/zh/docs/tasks/debug-application-cluster/debug-application.md index 99678b817a..6fa979bc16 100644 --- a/content/zh/docs/tasks/debug-application-cluster/debug-application.md +++ b/content/zh/docs/tasks/debug-application-cluster/debug-application.md @@ -120,12 +120,12 @@ Again, the information from `kubectl describe ...` should be informative. The m #### My pod is crashing or otherwise unhealthy Once your pod has been scheduled, the methods described in [Debug Running Pods]( -/docs/tasks/debug-application-cluster/debug-running-pod/) are available for debugging. +/docs/tasks/debug/debug-application/debug-running-pod/) are available for debugging. --> #### Pod 处于 Crashing 或别的不健康状态 一旦 Pod 被调度，就可以采用 -[调试运行中的 Pod](/zh/docs/tasks/debug-application-cluster/debug-running-pod/) +[调试运行中的 Pod](/zh/docs/tasks/debug/debug-application/debug-running-pod/) 中的方法来进一步调试。 ### 我的 Pod 一直 Crashing 或者其他不健康状态 一旦 Pod 已经被调度，就可以依据 -[调试运行中的 Pod](/zh/docs/tasks/debug-application-cluster/debug-running-pod/) +[调试运行中的 Pod](/zh/docs/tasks/debug/debug-application/debug-running-pod/) 展开进一步的调试工作。 + + +此文档包含了一些用来解决容器应用问题的资源。它涵盖了 Kubernetes 资源（如 Pod、Service 或 StatefulSets） +的常见问题，理解容器终止消息的建议以及调试正在运行的容器的方法。 \ No newline at end of file diff --git a/content/zh/docs/tasks/debug/debug-application/debug-service.md b/content/zh/docs/tasks/debug/debug-application/debug-service.md new file mode 100644 index 0000000000..f6e9b6401d --- /dev/null +++ b/content/zh/docs/tasks/debug/debug-application/debug-service.md @@ -0,0 +1,1116 @@ +--- +content_type: concept +title: 调试 Service +--- + + + + + +对于新安装的 Kubernetes，经常出现的问题是 Service 无法正常运行。 你已经通过 +Deployment（或其他工作负载控制器）运行了 Pod，并创建 Service ，但是 +当你尝试访问它时，没有任何响应。此文档有望对你有所帮助并找出问题所在。 + + + +## 在 Pod 中运行命令 + +对于这里的许多步骤，你可能希望知道运行在集群中的 Pod 看起来是什么样的。 +最简单的方法是运行一个交互式的 busybox Pod： + +```none +kubectl run -it --rm --restart=Never busybox --image=gcr.io/google-containers/busybox sh +``` + + +{{< note >}} +如果没有看到命令提示符，请按回车。 +{{< /note >}} + + +如果你已经有了你想使用的正在运行的 Pod，则可以运行以下命令去进入： + +```shell +kubectl exec -c -- +``` + + +## 设置 {#setup} + +为了完成本次实践的任务，我们先运行几个 Pod。 +由于你可能正在调试自己的 Service，所以，你可以使用自己的信息进行替换， +或者你也可以跟着教程并开始下面的步骤来获得第二个数据点。 + +```shell +kubectl create deployment hostnames --image=k8s.gcr.io/serve_hostname +``` + +```none +deployment.apps/hostnames created +``` + + +`kubectl` 命令将打印创建或变更的资源的类型和名称，它们可以在后续命令中使用。 +让我们将这个 deployment 的副本数扩至 3。 + +```shell +kubectl scale deployment hostnames --replicas=3 +``` + +```none +deployment.apps/hostnames scaled +``` + + +请注意这与你使用以下 YAML 方式启动 Deployment 类似： + +```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + labels: + app: hostnames + name: hostnames +spec: + selector: + matchLabels: + app: hostnames + replicas: 3 + template: + metadata: + labels: + app: hostnames + spec: + containers: + - name: hostnames + image: k8s.gcr.io/serve_hostname +``` + + +"app" 标签是 `kubectl create deployment` 根据 Deployment 名称自动设置的。 + +确认你的 Pods 是运行状态: + +```shell +kubectl get pods -l app=hostnames +``` + +```none +NAME READY STATUS RESTARTS AGE +hostnames-632524106-bbpiw 1/1 Running 0 2m +hostnames-632524106-ly40y 1/1 Running 0 2m +hostnames-632524106-tlaok 1/1 Running 0 2m +``` + + +你还可以确认你的 Pod 是否正在提供服务。你可以获取 Pod IP 地址列表并直接对其进行测试。 + +```shell +kubectl get pods -l app=hostnames \ + -o go-template='{{range .items}}{{.status.podIP}}{{"\n"}}{{end}}' +``` + +```none +10.244.0.5 +10.244.0.6 +10.244.0.7 +``` + + +用于本教程的示例容器通过 HTTP 在端口 9376 上提供其自己的主机名， +但是如果要调试自己的应用程序，则需要使用你的 Pod 正在侦听的端口号。 + +在 Pod 内运行： + +```shell +for ep in 10.244.0.5:9376 10.244.0.6:9376 10.244.0.7:9376; do + wget -qO- $ep +done +``` + + +输出类似这样： + +``` +hostnames-632524106-bbpiw +hostnames-632524106-ly40y +hostnames-632524106-tlaok +``` + + +如果此时你没有收到期望的响应，则你的 Pod 状态可能不健康，或者可能没有在你认为正确的端口上进行监听。 +你可能会发现 `kubectl logs` 命令对于查看正在发生的事情很有用， +或者你可能需要通过`kubectl exec` 直接进入 Pod 中并从那里进行调试。 + +假设到目前为止一切都已按计划进行，那么你可以开始调查为何你的 Service 无法正常工作。 + + +## Service 是否存在？ + +细心的读者会注意到我们实际上尚未创建 Service -这是有意而为之。 这一步有时会被遗忘，这是首先要检查的步骤。 + +那么，如果我尝试访问不存在的 Service 会怎样？ 假设你有另一个 Pod 通过名称匹配到 Service ，你将得到类似结果： + +```shell +wget -O- hostnames +``` + +```none +Resolving hostnames (hostnames)... failed: Name or service not known. +wget: unable to resolve host address 'hostnames' +``` + + +首先要检查的是该 Service 是否真实存在： + +```shell +kubectl get svc hostnames +``` + +```none +No resources found. +Error from server (NotFound): services "hostnames" not found +``` + + +让我们创建 Service。 和以前一样，在这次实践中 - 你可以在此处使用自己的 Service 的内容。 + +```shell +kubectl expose deployment hostnames --port=80 --target-port=9376 +``` + +```none +service/hostnames exposed +``` + + +重新运行查询命令： + +```shell +kubectl get svc hostnames +``` + +```none +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +hostnames ClusterIP 10.0.1.175 80/TCP 5s +``` + + +现在你知道了 Service 确实存在。 + +同前，此步骤效果与通过 YAML 方式启动 'Service' 一样： + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: hostnames +spec: + selector: + app: hostnames + ports: + - name: default + protocol: TCP + port: 80 + targetPort: 9376 +``` + + +为了突出配置范围的完整性，你在此处创建的 Service 使用的端口号与 Pods 不同。 +对于许多真实的 Service，这些值可以是相同的。 + + + +## 是否存在影响目标 Pod 的网络策略入站规则？ + +如果你部署了任何可能影响到 `hostnames-*` Pod 的传入流量的网络策略入站规则， +则需要对其进行检查。 + +详细信息，请参阅[网络策略](/zh/docs/concepts/services-networking/network-policies/)。 + + +## Service 是否可通过 DNS 名字访问？ + +通常客户端通过 DNS 名称来匹配到 Service。 + +从相同命名空间下的 Pod 中运行以下命令： + +```shell +nslookup hostnames +``` + +```none +Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local + +Name: hostnames +Address 1: 10.0.1.175 hostnames.default.svc.cluster.local +``` + + +如果失败，那么你的 Pod 和 Service 可能位于不同的命名空间中， +请尝试使用限定命名空间的名称（同样在 Pod 内运行）： + +```shell +nslookup hostnames.default +``` + +```none +Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local + +Name: hostnames.default +Address 1: 10.0.1.175 hostnames.default.svc.cluster.local +``` + + +如果成功，那么需要调整你的应用，使用跨命名空间的名称去访问它， +或者在相同的命名空间中运行应用和 Service。如果仍然失败，请尝试一个完全限定的名称： + +```shell +nslookup hostnames.default.svc.cluster.local +``` + +```none +Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local + +Name: hostnames.default.svc.cluster.local +Address 1: 10.0.1.175 hostnames.default.svc.cluster.local +``` + + +注意这里的后缀："default.svc.cluster.local"。"default" 是我们正在操作的命名空间。 +"svc" 表示这是一个 Service。"cluster.local" 是你的集群域，在你自己的集群中可能会有所不同。 + +你也可以在集群中的节点上尝试此操作： + +{{< note >}} +10.0.0.10 是集群的 DNS 服务 IP，你的可能有所不同。 +{{< /note >}} + +```shell +nslookup hostnames.default.svc.cluster.local 10.0.0.10 +``` + +```none +Server: 10.0.0.10 +Address: 10.0.0.10#53 + +Name: hostnames.default.svc.cluster.local +Address: 10.0.1.175 +``` + + +如果你能够使用完全限定的名称查找，但不能使用相对名称，则需要检查你 Pod 中的 +`/etc/resolv.conf` 文件是否正确。在 Pod 中运行以下命令： + +```shell +cat /etc/resolv.conf +``` + + +你应该可以看到类似这样的输出： + +``` +nameserver 10.0.0.10 +search default.svc.cluster.local svc.cluster.local cluster.local example.com +options ndots:5 +``` + + +`nameserver` 行必须指示你的集群的 DNS Service， +它是通过 `--cluster-dns` 标志传递到 kubelet 的。 + +`search` 行必须包含一个适当的后缀，以便查找 Service 名称。 +在本例中，它查找本地命名空间（`default.svc.cluster.local`）中的服务和 +所有命名空间（`svc.cluster.local`）中的服务，最后在集群（`cluster.local`）中查找 +服务的名称。根据你自己的安装情况，可能会有额外的记录（最多 6 条）。 +集群后缀是通过 `--cluster-domain` 标志传递给 `kubelet` 的。 +本文中，我们假定后缀是 “cluster.local”。 +你的集群配置可能不同，这种情况下，你应该在上面的所有命令中更改它。 + +`options` 行必须设置足够高的 `ndots`，以便 DNS 客户端库考虑搜索路径。 +在默认情况下，Kubernetes 将这个值设置为 5，这个值足够高，足以覆盖它生成的所有 DNS 名称。 + + +### 是否存在 Service 能通过 DNS 名称访问？{#does-any-service-exist-in-dns} + +如果上面的方式仍然失败，DNS 查找不到你需要的 Service ，你可以后退一步， +看看还有什么其它东西没有正常工作。 +Kubernetes 主 Service 应该一直是工作的。在 Pod 中运行如下命令： + +```shell +nslookup kubernetes.default +``` +```none +Server: 10.0.0.10 +Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local + +Name: kubernetes.default +Address 1: 10.0.0.1 kubernetes.default.svc.cluster.local +``` + + +如果失败，你可能需要转到本文的 [kube-proxy](#is-the-kube-proxy-working) 节， +或者甚至回到文档的顶部重新开始，但不是调试你自己的 Service ，而是调试 DNS Service。 + + +### Service 能够通过 IP 访问么？ + +假设你已经确认 DNS 工作正常，那么接下来要测试的是你的 Service 能否通过它的 IP 正常访问。 +从集群中的一个 Pod，尝试访问 Service 的 IP（从上面的 `kubectl get` 命令获取）。 + +```shell +for i in $(seq 1 3); do + wget -qO- 10.0.1.175:80 +done +``` + + +输出应该类似这样： + +``` +hostnames-632524106-bbpiw +hostnames-632524106-ly40y +hostnames-632524106-tlaok +``` + + +如果 Service 状态是正常的，你应该得到正确的响应。如果没有，有很多可能出错的地方，请继续阅读。 + + +## Service 的配置是否正确？ + +这听起来可能很愚蠢，但你应该两次甚至三次检查你的 Service 配置是否正确，并且与你的 Pod 匹配。 +查看你的 Service 配置并验证它： + +```shell +kubectl get service hostnames -o json +``` + +```json +{ + "kind": "Service", + "apiVersion": "v1", + "metadata": { + "name": "hostnames", + "namespace": "default", + "uid": "428c8b6c-24bc-11e5-936d-42010af0a9bc", + "resourceVersion": "347189", + "creationTimestamp": "2015-07-07T15:24:29Z", + "labels": { + "app": "hostnames" + } + }, + "spec": { + "ports": [ + { + "name": "default", + "protocol": "TCP", + "port": 80, + "targetPort": 9376, + "nodePort": 0 + } + ], + "selector": { + "app": "hostnames" + }, + "clusterIP": "10.0.1.175", + "type": "ClusterIP", + "sessionAffinity": "None" + }, + "status": { + "loadBalancer": {} + } +} +``` + +* 你想要访问的 Service 端口是否在 `spec.ports[]` 中列出？ +* `targetPort` 对你的 Pod 来说正确吗（许多 Pod 使用与 Service 不同的端口）？ +* 如果你想使用数值型端口，那么它的类型是一个数值（9376）还是字符串 “9376”？ +* 如果你想使用名称型端口，那么你的 Pod 是否暴露了一个同名端口？ +* 端口的 `protocol` 和 Pod 的是否对应？ + + +## Service 有 Endpoints 吗？ + +如果你已经走到了这一步，你已经确认你的 Service 被正确定义，并能通过 DNS 解析。 +现在，让我们检查一下，你运行的 Pod 确实是被 Service 选中的。 + +早些时候，我们已经看到 Pod 是运行状态。我们可以再检查一下： + +```shell +kubectl get pods -l app=hostnames +``` +```none +NAME READY STATUS RESTARTS AGE +hostnames-632524106-bbpiw 1/1 Running 0 1h +hostnames-632524106-ly40y 1/1 Running 0 1h +hostnames-632524106-tlaok 1/1 Running 0 1h +``` + +`-l app=hostnames` 参数是在 Service 上配置的标签选择器。 + +"AGE" 列表明这些 Pod 已经启动一个小时了，这意味着它们运行良好，而未崩溃。 + +"RESTARTS" 列表明 Pod 没有经常崩溃或重启。经常性崩溃可能导致间歇性连接问题。 +如果重启次数过大，通过[调试 pod](/zh/docs/tasks/debug-application-cluster/debug-application/#debugging-pods) +了解相关技术。 + +在 Kubernetes 系统中有一个控制回路，它评估每个 Service 的选择算符，并将结果保存到 Endpoints 对象中。 + +```shell +kubectl get endpoints hostnames +``` +``` +NAME ENDPOINTS +hostnames 10.244.0.5:9376,10.244.0.6:9376,10.244.0.7:9376 +``` + + +这证实 Endpoints 控制器已经为你的 Service 找到了正确的 Pods。 +如果 `ENDPOINTS` 列的值为 ``，则应检查 Service 的 `spec.selector` 字段， +以及你实际想选择的 Pod 的 `metadata.labels` 的值。 +常见的错误是输入错误或其他错误，例如 Service 想选择 `app=hostnames`，但是 +Deployment 指定的是 `run=hostnames`。在 1.18之前的版本中 `kubectl run` +也可以被用来创建 Deployment。 + + +## Pod 正常工作吗？ + +至此，你知道你的 Service 已存在，并且已匹配到你的Pod。在本实验的开始，你已经检查了 Pod 本身。 +让我们再次检查 Pod 是否确实在工作 - 你可以绕过 Service 机制并直接转到 Pod，如上面的 Endpoint 所示。 + +{{< note >}} +这些命令使用的是 Pod 端口（9376），而不是 Service 端口（80）。 +{{< /note >}} + +在 Pod 中运行： + +```shell +for ep in 10.244.0.5:9376 10.244.0.6:9376 10.244.0.7:9376; do + wget -qO- $ep +done +``` + + +输出应该类似这样： + +``` +hostnames-632524106-bbpiw +hostnames-632524106-ly40y +hostnames-632524106-tlaok +``` + + +你希望 Endpoint 列表中的每个 Pod 都返回自己的主机名。 +如果情况并非如此（或你自己的 Pod 的正确行为是什么），你应调查发生了什么事情。 + + +## kube-proxy 正常工作吗？ + +如果你到达这里，则说明你的 Service 正在运行，拥有 Endpoints，Pod 真正在提供服务。 +此时，整个 Service 代理机制是可疑的。让我们一步一步地确认它没问题。 + +Service 的默认实现（在大多数集群上应用的）是 kube-proxy。 +这是一个在每个节点上运行的程序，负责配置用于提供 Service 抽象的机制之一。 +如果你的集群不使用 kube-proxy，则以下各节将不适用，你将必须检查你正在使用的 Service 的实现方式。 + + +### kube-proxy 正常运行吗？ + +确认 `kube-proxy` 正在节点上运行。 在节点上直接运行，你将会得到类似以下的输出： + +```shell +ps auxw | grep kube-proxy +``` +```none +root 4194 0.4 0.1 101864 17696 ? Sl Jul04 25:43 /usr/local/bin/kube-proxy --master=https://kubernetes-master --kubeconfig=/var/lib/kube-proxy/kubeconfig --v=2 +``` + + +下一步，确认它并没有出现明显的失败，比如连接主节点失败。要做到这一点，你必须查看日志。 +访问日志的方式取决于你节点的操作系统。 +在某些操作系统上日志是一个文件，如 /var/log/messages kube-proxy.log， +而其他操作系统使用 `journalctl` 访问日志。你应该看到输出类似于： + +```none +I1027 22:14:53.995134 5063 server.go:200] Running in resource-only container "/kube-proxy" +I1027 22:14:53.998163 5063 server.go:247] Using iptables Proxier. +I1027 22:14:53.999055 5063 server.go:255] Tearing down userspace rules. Errors here are acceptable. +I1027 22:14:54.038140 5063 proxier.go:352] Setting endpoints for "kube-system/kube-dns:dns-tcp" to [10.244.1.3:53] +I1027 22:14:54.038164 5063 proxier.go:352] Setting endpoints for "kube-system/kube-dns:dns" to [10.244.1.3:53] +I1027 22:14:54.038209 5063 proxier.go:352] Setting endpoints for "default/kubernetes:https" to [10.240.0.2:443] +I1027 22:14:54.038238 5063 proxier.go:429] Not syncing iptables until Services and Endpoints have been received from master +I1027 22:14:54.040048 5063 proxier.go:294] Adding new service "default/kubernetes:https" at 10.0.0.1:443/TCP +I1027 22:14:54.040154 5063 proxier.go:294] Adding new service "kube-system/kube-dns:dns" at 10.0.0.10:53/UDP +I1027 22:14:54.040223 5063 proxier.go:294] Adding new service "kube-system/kube-dns:dns-tcp" at 10.0.0.10:53/TCP +``` + + +如果你看到有关无法连接主节点的错误消息，则应再次检查节点配置和安装步骤。 + +`kube-proxy` 无法正确运行的可能原因之一是找不到所需的 `conntrack` 二进制文件。 +在一些 Linux 系统上，这也是可能发生的，这取决于你如何安装集群， +例如，你是手动开始一步步安装 Kubernetes。如果是这样的话，你需要手动安装 +`conntrack` 包（例如，在 Ubuntu 上使用 `sudo apt install conntrack`），然后重试。 + + +Kube-proxy 可以以若干模式之一运行。在上述日志中，`Using iptables Proxier` +行表示 kube-proxy 在 "iptables" 模式下运行。 +最常见的另一种模式是 "ipvs"。先前的 "userspace" 模式已经被这些所代替。 + + +#### Iptables 模式 + +在 "iptables" 模式中, 你应该可以在节点上看到如下输出: + +```shell +iptables-save | grep hostnames +``` + +```none +-A KUBE-SEP-57KPRZ3JQVENLNBR -s 10.244.3.6/32 -m comment --comment "default/hostnames:" -j MARK --set-xmark 0x00004000/0x00004000 +-A KUBE-SEP-57KPRZ3JQVENLNBR -p tcp -m comment --comment "default/hostnames:" -m tcp -j DNAT --to-destination 10.244.3.6:9376 +-A KUBE-SEP-WNBA2IHDGP2BOBGZ -s 10.244.1.7/32 -m comment --comment "default/hostnames:" -j MARK --set-xmark 0x00004000/0x00004000 +-A KUBE-SEP-WNBA2IHDGP2BOBGZ -p tcp -m comment --comment "default/hostnames:" -m tcp -j DNAT --to-destination 10.244.1.7:9376 +-A KUBE-SEP-X3P2623AGDH6CDF3 -s 10.244.2.3/32 -m comment --comment "default/hostnames:" -j MARK --set-xmark 0x00004000/0x00004000 +-A KUBE-SEP-X3P2623AGDH6CDF3 -p tcp -m comment --comment "default/hostnames:" -m tcp -j DNAT --to-destination 10.244.2.3:9376 +-A KUBE-SERVICES -d 10.0.1.175/32 -p tcp -m comment --comment "default/hostnames: cluster IP" -m tcp --dport 80 -j KUBE-SVC-NWV5X2332I4OT4T3 +-A KUBE-SVC-NWV5X2332I4OT4T3 -m comment --comment "default/hostnames:" -m statistic --mode random --probability 0.33332999982 -j KUBE-SEP-WNBA2IHDGP2BOBGZ +-A KUBE-SVC-NWV5X2332I4OT4T3 -m comment --comment "default/hostnames:" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-X3P2623AGDH6CDF3 +-A KUBE-SVC-NWV5X2332I4OT4T3 -m comment --comment "default/hostnames:" -j KUBE-SEP-57KPRZ3JQVENLNBR +``` + + +对于每个 Service 的每个端口，应有 1 条 `KUBE-SERVICES` 规则、一个 `KUBE-SVC-` 链。 +对于每个 Pod 末端，在那个 `KUBE-SVC-` 链中应该有一些规则与之对应，还应该 +有一个 `KUBE-SEP-` 链与之对应，其中包含为数不多的几条规则。 +实际的规则数量可能会根据你实际的配置（包括 NodePort 和 LoadBalancer 服务）有所不同。 + + +#### IPVS 模式 + +在 "ipvs" 模式中, 你应该在节点下看到如下输出： + +```shell +ipvsadm -ln +``` + +```none +Prot LocalAddress:Port Scheduler Flags + -> RemoteAddress:Port Forward Weight ActiveConn InActConn +... +TCP 10.0.1.175:80 rr + -> 10.244.0.5:9376 Masq 1 0 0 + -> 10.244.0.6:9376 Masq 1 0 0 + -> 10.244.0.7:9376 Masq 1 0 0 +... +``` + + +对于每个 Service 的每个端口，还有 NodePort，External IP 和 LoadBalancer 类型服务 +的 IP，kube-proxy 将创建一个虚拟服务器。 +对于每个 Pod 末端，它将创建相应的真实服务器。 +在此示例中，服务主机名（`10.0.1.175:80`）拥有 3 个末端（`10.244.0.5:9376`、 +`10.244.0.6:9376` 和 `10.244.0.7:9376`）。 + + +#### Userspace 模式 + +在极少数情况下，你可能会用到 "userspace" 模式。在你的节点上运行： + +```shell +iptables-save | grep hostnames +``` + +```none +-A KUBE-PORTALS-CONTAINER -d 10.0.1.175/32 -p tcp -m comment --comment "default/hostnames:default" -m tcp --dport 80 -j REDIRECT --to-ports 48577 +-A KUBE-PORTALS-HOST -d 10.0.1.175/32 -p tcp -m comment --comment "default/hostnames:default" -m tcp --dport 80 -j DNAT --to-destination 10.240.115.247:48577 +``` + + +对于 Service （本例中只有一个）的每个端口，应当有 2 条规则： +一条 "KUBE-PORTALS-CONTAINER" 和一条 "KUBE-PORTALS-HOST" 规则。 + +几乎没有人应该再使用 "userspace" 模式，因此你在这里不会花更多的时间。 + + +### kube-proxy 是否在运行? + +假设你确实遇到上述情况之一，请重试从节点上通过 IP 访问你的 Service ： + +```shell +curl 10.0.1.175:80 +``` + +```none +hostnames-632524106-bbpiw +``` + + +如果失败，并且你正在使用用户空间代理，则可以尝试直接访问代理。 +如果你使用的是 iptables 代理，请跳过本节。 + +回顾上面的 `iptables-save` 输出，并提取 `kube-proxy` 为你的 Service 所使用的端口号。 +在上面的例子中，端口号是 “48577”。现在试着连接它： + +```shell +curl localhost:48577 +``` + +```none +hostnames-632524106-tlaok +``` + + +如果这步操作仍然失败，请查看 `kube-proxy` 日志中的特定行，如： + +```none +Setting endpoints for default/hostnames:default to [10.244.0.5:9376 10.244.0.6:9376 10.244.0.7:9376] +``` + + +如果你没有看到这些，请尝试将 `-V` 标志设置为 4 并重新启动 `kube-proxy`，然后再查看日志。 + + +### 边缘案例: Pod 无法通过 Service IP 连接到它本身 {#a-pod-fails-to-reach-itself-via-the-service-ip} + +这听起来似乎不太可能，但是确实可能发生，并且应该可行。 + +如果网络没有为“发夹模式（Hairpin）”流量生成正确配置， +通常当 `kube-proxy` 以 `iptables` 模式运行，并且 Pod 与桥接网络连接时，就会发生这种情况。 +`kubelet` 提供了 `hairpin-mode` +[标志](/zh/docs/reference/command-line-tools-reference/kubelet/)。 +如果 Service 的末端尝试访问自己的 Service VIP，则该端点可以把流量负载均衡回来到它们自身。 +`hairpin-mode` 标志必须被设置为 `hairpin-veth` 或者 `promiscuous-bridge`。 + + +诊断此类问题的常见步骤如下： + +* 确认 `hairpin-mode` 被设置为 `hairpin-veth` 或 `promiscuous-bridge`。 + 你应该可以看到下面这样。本例中 `hairpin-mode` 被设置为 `promiscuous-bridge`。 + + ```shell + ps auxw | grep kubelet + ``` + ```none + root 3392 1.1 0.8 186804 65208 ? Sl 00:51 11:11 /usr/local/bin/kubelet --enable-debugging-handlers=true --config=/etc/kubernetes/manifests --allow-privileged=True --v=4 --cluster-dns=10.0.0.10 --cluster-domain=cluster.local --configure-cbr0=true --cgroup-root=/ --system-cgroups=/system --hairpin-mode=promiscuous-bridge --runtime-cgroups=/docker-daemon --kubelet-cgroups=/kubelet --babysit-daemons=true --max-pods=110 --serialize-image-pulls=false --outofdisk-transition-frequency=0 + ``` + + +* 确认有效的 `hairpin-mode`。要做到这一点，你必须查看 kubelet 日志。 + 访问日志取决于节点的操作系统。在一些操作系统上，它是一个文件，如 /var/log/kubelet.log， + 而其他操作系统则使用 `journalctl` 访问日志。请注意，由于兼容性， + 有效的 `hairpin-mode` 可能不匹配 `--hairpin-mode` 标志。在 kubelet.log + 中检查是否有带有关键字 `hairpin` 的日志行。应该有日志行指示有效的 + `hairpin-mode`，就像下面这样。 + + ```none + I0629 00:51:43.648698 3252 kubelet.go:380] Hairpin mode set to "promiscuous-bridge" + ``` + + +* 如果有效的发夹模式是 `hairpin-veth`, 要保证 `Kubelet` 有操作节点上 `/sys` 的权限。 + 如果一切正常，你将会看到如下输出: + + ```shell + for intf in /sys/devices/virtual/net/cbr0/brif/*; do cat $intf/hairpin_mode; done + ``` + ```none + 1 + 1 + 1 + 1 + ``` + + +* 如果有效的发卡模式是 `promiscuous-bridge`, 要保证 `Kubelet` 有操作节点上 + Linux 网桥的权限。如果 `cbr0` 桥正在被使用且被正确设置，你将会看到如下输出: + + ```shell + ifconfig cbr0 |grep PROMISC + ``` + ```none + UP BROADCAST RUNNING PROMISC MULTICAST MTU:1460 Metric:1 + ``` + + +* 如果以上步骤都不能解决问题，请寻求帮助。 + + +## 寻求帮助 + +如果你走到这一步，那么就真的是奇怪的事情发生了。你的 Service 正在运行，有 Endpoints 存在， +你的 Pods 也确实在提供服务。你的 DNS 正常，`iptables` 规则已经安装，`kube-proxy` 看起来也正常。 +然而 Service 还是没有正常工作。这种情况下，请告诉我们，以便我们可以帮助调查！ + +通过 +[Slack](/zh/docs/tasks/debug-application-cluster/troubleshooting/#slack) 或者 +[Forum](https://discuss.kubernetes.io) 或者 +[GitHub](https://github.com/kubernetes/kubernetes) +联系我们。 + +## {{% heading "whatsnext" %}} + + +访问[故障排查文档](/zh/docs/tasks/debug-application-cluster/troubleshooting/) 获取更多信息。 diff --git a/content/zh/docs/tasks/debug/debug-application/get-shell-running-container.md b/content/zh/docs/tasks/debug/debug-application/get-shell-running-container.md new file mode 100644 index 0000000000..e67d6b1859 --- /dev/null +++ b/content/zh/docs/tasks/debug/debug-application/get-shell-running-container.md @@ -0,0 +1,211 @@ +--- +title: 获取正在运行容器的 Shell +content_type: task +--- + + + + +本文介绍怎样使用 `kubectl exec` 命令获取正在运行容器的 Shell。 + +## {{% heading "prerequisites" %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + + + +## 获取容器的 Shell + + + +在本练习中，你将创建包含一个容器的 Pod。容器运行 nginx 镜像。下面是 Pod 的配置文件： + +{{< codenew file="application/shell-demo.yaml" >}} + + + +创建 Pod： + +```shell +kubectl create -f https://k8s.io/examples/application/shell-demo.yaml +``` + + + +检查容器是否运行正常： + +```shell +kubectl get pod shell-demo +``` + + + +获取正在运行容器的 Shell： + +```shell +kubectl exec -it shell-demo -- /bin/bash +``` +{{< note >}} + + +双破折号 "--" 用于将要传递给命令的参数与 kubectl 的参数分开。 +{{< /note >}} + + + +在 shell 中，打印根目录： + +```shell +root@shell-demo:/# ls / +``` + + + +在 shell 中，实验其他命令。下面是一些示例： + +```shell +root@shell-demo:/# ls / +root@shell-demo:/# cat /proc/mounts +root@shell-demo:/# cat /proc/1/maps +root@shell-demo:/# apt-get update +root@shell-demo:/# apt-get install -y tcpdump +root@shell-demo:/# tcpdump +root@shell-demo:/# apt-get install -y lsof +root@shell-demo:/# lsof +root@shell-demo:/# apt-get install -y procps +root@shell-demo:/# ps aux +root@shell-demo:/# ps aux | grep nginx +``` + + + +## 编写 nginx 的根页面 + + + +在看一下 Pod 的配置文件。该 Pod 有个 `emptyDir` 卷，容器将该卷挂载到了 `/usr/share/nginx/html`。 + + + +在 shell 中，在 `/usr/share/nginx/html` 目录创建一个 `index.html` 文件： + +```shell +root@shell-demo:/# echo Hello shell demo > /usr/share/nginx/html/index.html +``` + + + +在 shell 中，向 nginx 服务器发送 GET 请求： + +```shell +root@shell-demo:/# apt-get update +root@shell-demo:/# apt-get install curl +root@shell-demo:/# curl localhost +``` + + + +输出结果显示了你在 `index.html` 中写入的文本。 + +```shell +Hello shell demo +``` + + + +当用完 shell 后，输入 `exit` 退出。 + + + +## 在容器中运行单个命令 + + + +在普通的命令窗口（而不是 shell）中，打印环境运行容器中的变量： + +```shell +kubectl exec shell-demo env +``` + + + +实验运行其他命令。下面是一些示例： + +```shell +kubectl exec shell-demo ps aux +kubectl exec shell-demo ls / +kubectl exec shell-demo cat /proc/1/mounts +``` + + + + + +## 当 Pod 包含多个容器时打开 shell + + + +如果 Pod 有多个容器，`--container` 或者 `-c` 可以在 `kubectl exec` 命令中指定容器。 +例如，您有个名为 my-pod 的容器，该 Pod 有两个容器分别为 main-app 和 healper-app。 +下面的命令将会打开一个 shell 访问 main-app 容器。 + +```shell +kubectl exec -it my-pod --container main-app -- /bin/bash +``` + +## {{% heading "whatsnext" %}} + +* [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec) diff --git a/content/zh/docs/tasks/debug/debug-cluster/audit.md b/content/zh/docs/tasks/debug/debug-cluster/audit.md new file mode 100644 index 0000000000..b4b4c9ee66 --- /dev/null +++ b/content/zh/docs/tasks/debug/debug-cluster/audit.md @@ -0,0 +1,453 @@ +--- +title: 审计 +content_type: concept +--- + + + +{{< feature-state state="beta" >}} + + +Kubernetes _审计（Auditing）_ 功能提供了与安全相关的、按时间顺序排列的记录集， +记录每个用户、使用 Kubernetes API 的应用以及控制面自身引发的活动。 + +审计功能使得集群管理员能够回答以下问题： + + + - 发生了什么？ + - 什么时候发生的？ + - 谁触发的？ + - 活动发生在哪个（些）对象上？ + - 在哪观察到的？ + - 它从哪触发的？ + - 活动的后续处理行为是什么？ + + + + +审计记录最初产生于 +[kube-apiserver](/zh/docs/reference/command-line-tools-reference/kube-apiserver/) +内部。每个请求在不同执行阶段都会生成审计事件；这些审计事件会根据特定策略 +被预处理并写入后端。策略确定要记录的内容和用来存储记录的后端。 +当前的后端支持日志文件和 webhook。 + + +每个请求都可被记录其相关的 _阶段（stage）_。已定义的阶段有： + +- `RequestReceived` - 此阶段对应审计处理器接收到请求后，并且在委托给 + 其余处理器之前生成的事件。 +- `ResponseStarted` - 在响应消息的头部发送后，响应消息体发送前生成的事件。 + 只有长时间运行的请求（例如 watch）才会生成这个阶段。 +- `ResponseComplete` - 当响应消息体完成并且没有更多数据需要传输的时候。 +- `Panic` - 当 panic 发生时生成。 + + +{{< note >}} +[审计事件配置](/zh/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event) +的配置与 [Event](/zh/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#event-v1-core) +API 对象不同。 +{{< /note >}} + + +审计日志记录功能会增加 API server 的内存消耗，因为需要为每个请求存储审计所需的某些上下文。 +此外，内存消耗取决于审计日志记录的配置。 + + +## 审计策略 {#audit-policy} + +审计政策定义了关于应记录哪些事件以及应包含哪些数据的规则。 +审计策略对象结构定义在 +[`audit.k8s.io` API 组](/zh/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy) +处理事件时，将按顺序与规则列表进行比较。第一个匹配规则设置事件的 +_审计级别（Audit Level）_。已定义的审计级别有： + + +- `None` - 符合这条规则的日志将不会记录。 +- `Metadata` - 记录请求的元数据（请求的用户、时间戳、资源、动词等等）， + 但是不记录请求或者响应的消息体。 +- `Request` - 记录事件的元数据和请求的消息体，但是不记录响应的消息体。 + 这不适用于非资源类型的请求。 +- `RequestResponse` - 记录事件的元数据，请求和响应的消息体。这不适用于非资源类型的请求。 + + +你可以使用 `--audit-policy-file` 标志将包含策略的文件传递给 `kube-apiserver`。 +如果不设置该标志，则不记录事件。 +注意 `rules` 字段 __必须__ 在审计策略文件中提供。没有（0）规则的策略将被视为非法配置。 + +以下是一个审计策略文件的示例： + +{{< codenew file="audit/audit-policy.yaml" >}} + + +你可以使用最低限度的审计策略文件在 `Metadata` 级别记录所有请求： + +```yaml +# 在 Metadata 级别为所有请求生成日志 +apiVersion: audit.k8s.io/v1beta1 +kind: Policy +rules: +- level: Metadata +``` + + +如果你在打磨自己的审计配置文件，你可以使用为 Google Container-Optimized OS +设计的审计配置作为出发点。你可以参考 +[configure-helper.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/gce/gci/configure-helper.sh) +脚本，该脚本能够生成审计策略文件。你可以直接在脚本中看到审计策略的绝大部份内容。 + +你也可以参考 [`Policy` 配置参考](/zh/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy) +以获取有关已定义字段的详细信息。 + + + +## 审计后端 {#audit-backends} + +审计后端实现将审计事件导出到外部存储。`Kube-apiserver` 默认提供两个后端： + +- Log 后端，将事件写入到文件系统 +- Webhook 后端，将事件发送到外部 HTTP API + +在这所有情况下，审计事件均遵循 Kubernetes API 在 +[`audit.k8s.io` API 组](/zh/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event) +中定义的结构。 + + +{{< note >}} +对于 patch 请求，请求的消息体需要是设定 patch 操作的 JSON 所构成的一个串， +而不是一个完整的 Kubernetes API 对象 JSON 串。 +例如，以下的示例是一个合法的 patch 请求消息体，该请求对应 +`/apis/batch/v1/namespaces/some-namespace/jobs/some-job-name`。 + +```json +[ + { + "op": "replace", + "path": "/spec/parallelism", + "value": 0 + }, + { + "op": "remove", + "path": "/spec/template/spec/containers/0/terminationMessagePolicy" + } +] +``` +{{< /note >}} + + +### Log 后端 + +Log 后端将审计事件写入 [JSONlines](https://jsonlines.org/) 格式的文件。 +你可以使用以下 `kube-apiserver` 标志配置 Log 审计后端： + + +- `--audit-log-path` 指定用来写入审计事件的日志文件路径。不指定此标志会禁用日志后端。`-` 意味着标准化 +- `--audit-log-maxage` 定义保留旧审计日志文件的最大天数 +- `--audit-log-maxbackup` 定义要保留的审计日志文件的最大数量 +- `--audit-log-maxsize` 定义审计日志文件的最大大小（兆字节） + + +如果你的集群控制面以 Pod 的形式运行 kube-apiserver，记得要通过 `hostPath` +卷来访问策略文件和日志文件所在的目录，这样审计记录才会持久保存下来。例如： + +```shell + --audit-policy-file=/etc/kubernetes/audit-policy.yaml + --audit-log-path=/var/log/kubernetes/audit/audit.log +``` + +接下来挂载数据卷： + +```yaml +volumeMounts: + - mountPath: /etc/kubernetes/audit-policy.yaml + name: audit + readOnly: true + - mountPath: /var/log/kubernetes/audit/ + name: audit-log + readOnly: false +``` + + +最后配置 `hostPath`： + +```yaml +... +volumes: +- name: audit + hostPath: + path: /etc/kubernetes/audit-policy.yaml + type: File + +- name: audit-log + hostPath: + path: /var/log/kubernetes/audit/ + type: DirectoryOrCreate +``` + + +### Webhook 后端 {#webhook-backend} + +Webhook 后端将审计事件发送到远程 Web API，该远程 API 应该暴露与 `kube-apiserver` +形式相同的 API，包括其身份认证机制。你可以使用如下 kube-apiserver 标志来配置 +Webhook 审计后端： + + +- `--audit-webhook-config-file` 设置 Webhook 配置文件的路径。Webhook 配置文件实际上是一个 + [kubeconfig 文件](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/)。 +- `--audit-webhook-initial-backoff` 指定在第一次失败后重发请求等待的时间。随后的请求将以指数退避重试。 + +Webhook 配置文件使用 kubeconfig 格式指定服务的远程地址和用于连接它的凭据。 + + +## 事件批处理 {#batching} + +日志和 Webhook 后端都支持批处理。以 Webhook 为例，以下是可用参数列表。要获取日志 +后端的同样参数，请在参数名称中将 `webhook` 替换为 `log`。 +默认情况下，在 `webhook` 中批处理是被启用的，在 `log` 中批处理是被禁用的。 +同样，默认情况下，在 `webhook` 中启用带宽限制，在 `log` 中禁用带宽限制。 + + +- `--audit-webhook-mode` 定义缓存策略，可选值如下： + - `batch` - 以批处理缓存事件和异步的过程。这是默认值。 + - `blocking` - 在 API 服务器处理每个单独事件时，阻塞其响应。 + - `blocking-strict` - 与 `blocking` 相同，不过当审计日志在 RequestReceived 阶段 + 失败时，整个 API 服务请求会失效。 + + +以下参数仅用于 `batch` 模式。 + +- `--audit-webhook-batch-buffer-size` 定义 batch 之前要缓存的事件数。 + 如果传入事件的速率溢出缓存区，则会丢弃事件。 +- `--audit-webhook-batch-max-size` 定义一个 batch 中的最大事件数。 +- `--audit-webhook-batch-max-wait` 无条件 batch 队列中的事件前等待的最大事件。 +- `--audit-webhook-batch-throttle-qps` 每秒生成的最大批次数。 +- `--audit-webhook-batch-throttle-burst` 在达到允许的 QPS 前，同一时刻允许存在的最大 batch 生成数。 + + +## 参数调整 {#parameter-tuning} + +需要设置参数以适应 API 服务器上的负载。 + +例如，如果 kube-apiserver 每秒收到 100 个请求，并且每个请求仅在 `ResponseStarted` +和 `ResponseComplete` 阶段进行审计，则应该考虑每秒生成约 200 个审计事件。 +假设批处理中最多有 100 个事件，则应将限制级别设置为每秒至少 2 个查询。 +假设后端最多需要 5 秒钟来写入事件，你应该设置缓冲区大小以容纳最多 5 秒的事件， +即 10 个 batch，即 1000 个事件。 + + +但是，在大多数情况下，默认参数应该足够了，你不必手动设置它们。 +你可以查看 kube-apiserver 公开的以下 Prometheus 指标，并在日志中监控审计子系统的状态。 + +- `apiserver_audit_event_total` 包含所有暴露的审计事件数量的指标。 +- `apiserver_audit_error_total` 在暴露时由于发生错误而被丢弃的事件的数量。 + + +### 日志条目截断 {#truncate} + +日志后端和 Webhook 后端都支持限制所输出的事件的尺寸。 +例如，下面是可以为日志后端配置的标志列表： + + +- `audit-log-truncate-enabled`：是否弃用事件和批次的截断处理。 +- `audit-log-truncate-max-batch-size`：向下层后端发送的各批次的最大尺寸字节数。 +- `audit-log-truncate-max-event-size`：向下层后端发送的审计事件的最大尺寸字节数。 + + +默认情况下，截断操作在 `webhook` 和 `log` 后端都是被禁用的，集群管理员需要设置 +`audit-log-truncate-enabled` 或 `audit-webhook-truncate-enabled` 标志来启用此操作。 + +## {{% heading "whatsnext" %}} + + +* 了解 [Mutating webhook 审计注解](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#mutating-webhook-auditing-annotations)。 + diff --git a/content/zh/docs/tasks/debug/debug-cluster/crictl.md b/content/zh/docs/tasks/debug/debug-cluster/crictl.md new file mode 100644 index 0000000000..3eb5cf4955 --- /dev/null +++ b/content/zh/docs/tasks/debug/debug-cluster/crictl.md @@ -0,0 +1,566 @@ +--- +reviewers: +- Random-Liu +- feiskyer +- mrunalp +title: 使用 crictl 对 Kubernetes 节点进行调试 +content_type: task +--- + + + + + +{{< feature-state for_k8s_version="v1.11" state="stable" >}} + + + +`crictl` 是 CRI 兼容的容器运行时命令行接口。 +你可以使用它来检查和调试 Kubernetes 节点上的容器运行时和应用程序。 +`crictl` 和它的源代码在 +[cri-tools](https://github.com/kubernetes-sigs/cri-tools) 代码库。 + +## {{% heading "prerequisites" %}} + + +`crictl` 需要带有 CRI 运行时的 Linux 操作系统。 + + + + +## 安装 crictl + +你可以从 cri-tools [发布页面](https://github.com/kubernetes-sigs/cri-tools/releases) +下载一个压缩的 `crictl` 归档文件，用于几种不同的架构。 +下载与你的 kubernetes 版本相对应的版本。 +提取它并将其移动到系统路径上的某个位置，例如`/usr/local/bin/`。 + + +## 一般用法 + +`crictl` 命令有几个子命令和运行时参数。 +有关详细信息，请使用 `crictl help` 或 `crictl help` 获取帮助信息。 + + +你可以用以下方法之一来为 `crictl` 设置端点： + + +- 设置参数 `--runtime-endpoint` 和 `--image-endpoint`。 +- 设置环境变量 `CONTAINER_RUNTIME_ENDPOINT` 和 `IMAGE_SERVICE_ENDPOINT`。 +- 在配置文件 `--config=/etc/crictl.yaml` 中设置端点。 + 要设置不同的文件，可以在运行 `crictl` 时使用 `--config=PATH_TO_FILE` 标志。 + + +你还可以在连接到服务器并启用或禁用调试时指定超时值，方法是在配置文件中指定 +`timeout` 或 `debug` 值，或者使用 `--timeout` 和 `--debug` 命令行参数。 + + +要查看或编辑当前配置，请查看或编辑 `/etc/crictl.yaml` 的内容。 +例如，使用 `containerd` 容器运行时的配置会类似于这样： + +``` +runtime-endpoint: unix:///var/run/containerd/containerd.sock +image-endpoint: unix:///var/run/containerd/containerd.sock +timeout: 10 +debug: true +``` + + +要进一步了解 `crictl`，参阅 +[`crictl` 文档](https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md)。 + + +## crictl 命令示例 + +{{< warning >}} + +如果使用 `crictl` 在正在运行的 Kubernetes 集群上创建 Pod 沙盒或容器， +kubelet 最终将删除它们。 +`crictl` 不是一个通用的工作流工具，而是一个对调试有用的工具。 +{{< /warning >}} + + +### 打印 Pod 清单 + +打印所有 Pod 的清单： + +```shell +crictl pods +``` + + +输出类似于： + +``` +POD ID CREATED STATE NAME NAMESPACE ATTEMPT +926f1b5a1d33a About a minute ago Ready sh-84d7dcf559-4r2gq default 0 +4dccb216c4adb About a minute ago Ready nginx-65899c769f-wv2gp default 0 +a86316e96fa89 17 hours ago Ready kube-proxy-gblk4 kube-system 0 +919630b8f81f1 17 hours ago Ready nvidia-device-plugin-zgbbv kube-system 0 +``` + + +根据名称打印 Pod 清单： + +```shell +crictl pods --name nginx-65899c769f-wv2gp +``` + + +输出类似于这样： + +``` +POD ID CREATED STATE NAME NAMESPACE ATTEMPT +4dccb216c4adb 2 minutes ago Ready nginx-65899c769f-wv2gp default 0 +``` + + +根据标签打印 Pod 清单： + +```shell +crictl pods --label run=nginx +``` + + +输出类似于这样： + +```none +POD ID CREATED STATE NAME NAMESPACE ATTEMPT +4dccb216c4adb 2 minutes ago Ready nginx-65899c769f-wv2gp default 0 +``` + + +### 打印镜像清单 + +打印所有镜像清单： + +```shell +crictl images +``` + + +输出类似于这样： + +```none +IMAGE TAG IMAGE ID SIZE +busybox latest 8c811b4aec35f 1.15MB +k8s-gcrio.azureedge.net/hyperkube-amd64 v1.10.3 e179bbfe5d238 665MB +k8s-gcrio.azureedge.net/pause-amd64 3.1 da86e6ba6ca19 742kB +nginx latest cd5239a0906a6 109MB +``` + + +根据仓库打印镜像清单： + +```shell +crictl images nginx +``` + + +输出类似于这样： + +```none +IMAGE TAG IMAGE ID SIZE +nginx latest cd5239a0906a6 109MB +``` + + +只打印镜像 ID： + +```shell +crictl images -q +``` + + +输出类似于这样： + +```none +sha256:8c811b4aec35f259572d0f79207bc0678df4c736eeec50bc9fec37ed936a472a +sha256:e179bbfe5d238de6069f3b03fccbecc3fb4f2019af741bfff1233c4d7b2970c5 +sha256:da86e6ba6ca197bf6bc5e9d900febd906b133eaa4750e6bed647b0fbe50ed43e +sha256:cd5239a0906a6ccf0562354852fae04bc5b52d72a2aff9a871ddb6bd57553569 +``` + + +### 打印容器清单 + +打印所有容器清单： + +```shell +crictl ps -a +``` + + +输出类似于这样： + +```none +CONTAINER ID IMAGE CREATED STATE NAME ATTEMPT +1f73f2d81bf98 busybox@sha256:141c253bc4c3fd0a201d32dc1f493bcf3fff003b6df416dea4f41046e0f37d47 7 minutes ago Running sh 1 +9c5951df22c78 busybox@sha256:141c253bc4c3fd0a201d32dc1f493bcf3fff003b6df416dea4f41046e0f37d47 8 minutes ago Exited sh 0 +87d3992f84f74 nginx@sha256:d0a8828cccb73397acb0073bf34f4d7d8aa315263f1e7806bf8c55d8ac139d5f 8 minutes ago Running nginx 0 +1941fb4da154f k8s-gcrio.azureedge.net/hyperkube-amd64@sha256:00d814b1f7763f4ab5be80c58e98140dfc69df107f253d7fdd714b30a714260a 18 hours ago Running kube-proxy 0 +``` + + +打印正在运行的容器清单： + +```shell +crictl ps +``` + + +输出类似于这样： + +```none +CONTAINER ID IMAGE CREATED STATE NAME ATTEMPT +1f73f2d81bf98 busybox@sha256:141c253bc4c3fd0a201d32dc1f493bcf3fff003b6df416dea4f41046e0f37d47 6 minutes ago Running sh 1 +87d3992f84f74 nginx@sha256:d0a8828cccb73397acb0073bf34f4d7d8aa315263f1e7806bf8c55d8ac139d5f 7 minutes ago Running nginx 0 +1941fb4da154f k8s-gcrio.azureedge.net/hyperkube-amd64@sha256:00d814b1f7763f4ab5be80c58e98140dfc69df107f253d7fdd714b30a714260a 17 hours ago Running kube-proxy 0 +``` + + +### 在正在运行的容器上执行命令 + +```shell +crictl exec -i -t 1f73f2d81bf98 ls +``` + + +输出类似于这样： + +```none +bin dev etc home proc root sys tmp usr var +``` + + +### 获取容器日志 + +获取容器的所有日志： + +```shell +crictl logs 87d3992f84f74 +``` + + +输出类似于这样： + +```none +10.240.0.96 - - [06/Jun/2018:02:45:49 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.47.0" "-" +10.240.0.96 - - [06/Jun/2018:02:45:50 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.47.0" "-" +10.240.0.96 - - [06/Jun/2018:02:45:51 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.47.0" "-" +``` + + +获取最近的 `N` 行日志： + +```shell +crictl logs --tail=1 87d3992f84f74 +``` + + +输出类似于这样： + +```none +10.240.0.96 - - [06/Jun/2018:02:45:51 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.47.0" "-" +``` + + +### 运行 Pod 沙盒 + +用 `crictl` 运行 Pod 沙盒对容器运行时排错很有帮助。 +在运行的 Kubernetes 集群中，沙盒会随机地被 kubelet 停止和删除。 + + +1. 编写下面的 JSON 文件： + + ```json + { + "metadata": { + "name": "nginx-sandbox", + "namespace": "default", + "attempt": 1, + "uid": "hdishd83djaidwnduwk28bcsb" + }, + "logDirectory": "/tmp", + "linux": { + } + } + ``` + + +2. 使用 `crictl runp` 命令应用 JSON 文件并运行沙盒。 + + ```shell + crictl runp pod-config.json + ``` + + + 返回了沙盒的 ID。 + + +### 创建容器 + +用 `crictl` 创建容器对容器运行时排错很有帮助。 +在运行的 Kubernetes 集群中，沙盒会随机的被 kubelet 停止和删除。 + + +1. 拉取 busybox 镜像 + + ```shell + crictl pull busybox + ``` + ```none + Image is up to date for busybox@sha256:141c253bc4c3fd0a201d32dc1f493bcf3fff003b6df416dea4f41046e0f37d47 + ``` + + +2. 创建 Pod 和容器的配置： + + + **Pod 配置**： + + ```json + { + "metadata": { + "name": "nginx-sandbox", + "namespace": "default", + "attempt": 1, + "uid": "hdishd83djaidwnduwk28bcsb" + }, + "log_directory": "/tmp", + "linux": { + } + } + ``` + + + **容器配置**： + + ```json + { + "metadata": { + "name": "busybox" + }, + "image":{ + "image": "busybox" + }, + "command": [ + "top" + ], + "log_path":"busybox.log", + "linux": { + } + } + ``` + + +3. 创建容器，传递先前创建的 Pod 的 ID、容器配置文件和 Pod 配置文件。返回容器的 ID。 + + ```bash + crictl create f84dd361f8dc51518ed291fbadd6db537b0496536c1d2d6c05ff943ce8c9a54f container-config.json pod-config.json + ``` + + +4. 查询所有容器并确认新创建的容器状态为 `Created`。 + + ```bash + crictl ps -a + ``` + + 输出类似于这样： + + ```none + CONTAINER ID IMAGE CREATED STATE NAME ATTEMPT + 3e025dd50a72d busybox 32 seconds ago Created busybox 0 + ``` + + +### 启动容器 + +要启动容器，要将容器 ID 传给 `crictl start`： + +```shell +crictl start 3e025dd50a72d956c4f14881fbb5b1080c9275674e95fb67f965f6478a957d60 +``` + + +输出类似于这样： + +``` +3e025dd50a72d956c4f14881fbb5b1080c9275674e95fb67f965f6478a957d60 +``` + + +确认容器的状态为 `Running`。 + +```shell +crictl ps +``` + + +输出类似于这样： + +``` +CONTAINER ID IMAGE CREATED STATE NAME ATTEMPT +3e025dd50a72d busybox About a minute ago Running busybox 0 +``` + +## {{% heading "whatsnext" %}} + + +* [进一步了解 `crictl`](https://github.com/kubernetes-sigs/cri-tools). +* [将 `docker` CLI 命令映射到 `crictl`](/zh/docs/reference/tools/map-crictl-dockercli/). diff --git a/content/zh/docs/tasks/debug-application-cluster/local-debugging.md b/content/zh/docs/tasks/debug/debug-cluster/local-debugging.md similarity index 98% rename from content/zh/docs/tasks/debug-application-cluster/local-debugging.md rename to content/zh/docs/tasks/debug/debug-cluster/local-debugging.md index aca2f2e7e8..c296d44cdf 100644 --- a/content/zh/docs/tasks/debug-application-cluster/local-debugging.md +++ b/content/zh/docs/tasks/debug/debug-cluster/local-debugging.md @@ -1,10 +1,10 @@ --- -title: 在本地开发和调试服务 +title: 使用 telepresence 在本地开发和调试服务 content_type: task --- diff --git a/content/zh/docs/tasks/debug-application-cluster/monitor-node-health.md b/content/zh/docs/tasks/debug/debug-cluster/monitor-node-health.md similarity index 99% rename from content/zh/docs/tasks/debug-application-cluster/monitor-node-health.md rename to content/zh/docs/tasks/debug/debug-cluster/monitor-node-health.md index 5d4a265b10..7a8f5028c9 100644 --- a/content/zh/docs/tasks/debug-application-cluster/monitor-node-health.md +++ b/content/zh/docs/tasks/debug/debug-cluster/monitor-node-health.md @@ -1,6 +1,7 @@ --- content_type: task title: 节点健康监测 +weight: 20 --- diff --git a/content/zh/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md b/content/zh/docs/tasks/debug/debug-cluster/resource-metrics-pipeline.md similarity index 99% rename from content/zh/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md rename to content/zh/docs/tasks/debug/debug-cluster/resource-metrics-pipeline.md index 7318664952..ac5f488edd 100644 --- a/content/zh/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md +++ b/content/zh/docs/tasks/debug/debug-cluster/resource-metrics-pipeline.md @@ -1,6 +1,7 @@ --- title: 资源指标管道 content_type: concept +weight: 15 --- diff --git a/content/zh/docs/tasks/debug/debug-cluster/resource-usage-monitoring.md b/content/zh/docs/tasks/debug/debug-cluster/resource-usage-monitoring.md new file mode 100644 index 0000000000..86345a09a8 --- /dev/null +++ b/content/zh/docs/tasks/debug/debug-cluster/resource-usage-monitoring.md @@ -0,0 +1,113 @@ +--- +content_type: concept +title: 资源监控工具 +--- + + + + + +要扩展应用程序并提供可靠的服务，你需要了解应用程序在部署时的行为。 +你可以通过检测容器检查 Kubernetes 集群中的应用程序性能， +[Pods](/zh/docs/concepts/workloads/pods), +[服务](/zh/docs/concepts/services-networking/service/) +和整个集群的特征。 +Kubernetes 在每个级别上提供有关应用程序资源使用情况的详细信息。 +此信息使你可以评估应用程序的性能，以及在何处可以消除瓶颈以提高整体性能。 + + + + +在 Kubernetes 中，应用程序监控不依赖单个监控解决方案。 +在新集群上，你可以使用[资源度量](#resource-metrics-pipeline)或 +[完整度量](#full-metrics-pipeline)管道来收集监视统计信息。 + + +## 资源度量管道 {#resource-metrics-pipeline} + +资源指标管道提供了一组与集群组件，例如 +[Horizontal Pod Autoscaler](/zh/docs/tasks/run-application/horizontal-pod-autoscale/) +控制器以及 `kubectl top` 实用程序相关的有限度量。 +这些指标是由轻量级的、短期、内存存储的 +[metrics-server](https://github.com/kubernetes-sigs/metrics-server) 收集的， +通过 `metrics.k8s.io` 公开。 + + +度量服务器发现集群中的所有节点，并且查询每个节点的 +[kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) +以获取 CPU 和内存使用情况。 +Kubelet 充当 Kubernetes 主节点与节点之间的桥梁，管理机器上运行的 Pod 和容器。 +kubelet 将每个 Pod 转换为其组成的容器，并在容器运行时通过容器运行时接口 +获取各个容器使用情况统计信息。 +kubelet 从集成的 cAdvisor 获取此信息，以进行旧式 Docker 集成。 +然后，它通过 metrics-server Resource Metrics API 公开聚合的 pod 资源使用情况统计信息。 +该 API 在 kubelet 的经过身份验证和只读的端口上的 `/metrics/resource/v1beta1` 中提供。 + + +## 完整度量管道 {#full-metrics-pipeline} + +一个完整度量管道可以让你访问更丰富的度量。 +Kubernetes 还可以根据集群的当前状态，使用 Pod 水平自动扩缩器等机制， +通过自动调用扩展或调整集群来响应这些度量。 +监控管道从 kubelet 获取度量值，然后通过适配器将它们公开给 Kubernetes， +方法是实现 `custom.metrics.k8s.io` 或 `external.metrics.k8s.io` API。 + + +[Prometheus](https://prometheus.io) 是一个 CNCF 项目，可以原生监控 Kubernetes、 +节点和 Prometheus 本身。 +完整度量管道项目不属于 CNCF 的一部分，不在 Kubernetes 文档的范围之内。 + diff --git a/content/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md b/content/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md index 603274f5c2..38af138e61 100644 --- a/content/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md +++ b/content/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md @@ -1384,8 +1384,8 @@ procedure. *选项 1：* 使用存储版本迁移程序（Storage Version Migrator） @@ -1409,13 +1409,29 @@ The following is an example procedure to upgrade from `v1beta1` to `v1`. 2. Write an upgrade procedure to list all existing objects and write them with the same content. This forces the backend to write objects in the current storage version, which is `v1`. -3. Update the CustomResourceDefinition `Status` by removing `v1beta1` from - `storedVersions` field. +3. Remove `v1beta1` from the CustomResourceDefinition `status.storedVersions` field. --> 1. 在 CustomResourceDefinition 文件中将 `v1` 设置为存储版本，并使用 kubectl 应用它。 `storedVersions`现在是`v1beta1, v1`。 2. 编写升级过程以列出所有现有对象并使用相同内容将其写回存储。 这会强制后端使用当前存储版本（即 `v1`）写入对象。 -3. 通过从 `storedVersions` 字段中删除 `v1beta1` 来更新 CustomResourceDefinition - 的`Status`。 +3. 从 CustomResourceDefinition 的 `status.storedVersions` 字段中删除 `v1beta1`。 + +{{< note >}} +`kubectl` 工具目前不能用于编辑或修补 CRD 上的 `status` 子资源：请参阅 +[kubectl Subresource Support KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-cli/2590-kubectl-subresource) +了解更多细节。 + +从 CLI 给 `status` 子资源打补丁的更简单的方法是使用 `curl` 工具直接与 API 服务器交互，示例: +```bash +kubectl proxy & +curl --header "Content-Type: application/json-patch+json" \ + --request PATCH http://localhost:8001/apis/apiextensions.k8s.io/v1/customresourcedefinitions//status \ + --data '[{"op": "replace", "path": "/status/storedVersions", "value":["v1"]}]' +``` +{{< /note >}} \ No newline at end of file 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 8cc8dc42f4..4ba6b9857a 100644 --- a/content/zh/docs/tasks/run-application/horizontal-pod-autoscale.md +++ b/content/zh/docs/tasks/run-application/horizontal-pod-autoscale.md @@ -148,12 +148,12 @@ The common use for HorizontalPodAutoscaler is to configure it to fetch metrics f (`metrics.k8s.io`, `custom.metrics.k8s.io`, or `external.metrics.k8s.io`). The `metrics.k8s.io` API is usually provided by an add-on named Metrics Server, which needs to be launched separately. For more information about resource metrics, see -[Metrics Server](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#metrics-server). +[Metrics Server](/docs/tasks/debug/debug-cluster/resource-metrics-pipeline/#metrics-server). --> HorizontalPodAutoscaler 的常见用途是将其配置为从{{< glossary_tooltip text="聚合 API" term_id="aggregation-layer" >}} （`metrics.k8s.io`、`custom.metrics.k8s.io` 或 `external.metrics.k8s.io`）获取指标。 `metrics.k8s.io` API 通常由名为 Metrics Server 的插件提供，需要单独启动。有关资源指标的更多信息， -请参阅 [Metrics Server](/zh/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#metrics-server)。 +请参阅 [Metrics Server](/zh/docs/tasks/debug/debug-cluster/resource-metrics-pipeline/#metrics-server)。 -使用 `certificates.k8s.io` API 创建的证书由指定 CA 颁发。将集群配置为使用集群根目录 -CA 可以达到这个目的，但是你永远不要依赖这一假定。不要以为 -这些证书将针对群根目录 CA 进行验证。 +使用 `certificates.k8s.io` API 创建的证书由指定 [CA](#a-note-to-cluster-administrators) 颁发。 +将集群配置为使用集群根目录 CA 可以达到这个目的，但是你永远不要依赖这一假定。 +不要以为这些证书将针对群根目录 CA 进行验证。 {{< /note >}} ## {{% heading "prerequisites" %}} -{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} +{{< include "task-tutorial-prereqs.md" >}} + + +你需要 `cfssl` 工具。 +你可以从 [https://github.com/cloudflare/cfssl/releases](https://github.com/cloudflare/cfssl/releases) +下载 `cfssl`。 + +本文中某些步骤使用 `jq` 工具。如果你没有 `jq`，你可以通过操作系统的软件源安装， +或者从 [https://stedolan.github.io/jq/](https://stedolan.github.io/jq/) 获取。 ## 集群中的 TLS 信任 -信任 Pod 中运行的应用程序所提供的 CA 通常需要一些额外的应用程序配置。 +信任 Pod 中运行的应用程序所提供的[自定义 CA](#a-note-to-cluster-administrators) 通常需要一些额外的应用程序配置。 你需要将 CA 证书包添加到 TLS 客户端或服务器信任的 CA 证书列表中。 例如，你可以使用 Golang TLS 配置通过解析证书链并将解析的证书添加到 -[`tls.Config`](https://godoc.org/crypto/tls#Config) 结构中的 `RootCAs` +[`tls.Config`](https://pkg.go.dev/crypto/tls#Config) 结构中的 `RootCAs` 字段中。 -你可以用你的应用能够访问到的 -[ConfigMap](/zh/docs/tasks/configure-pod-container/configure-pod-configmap) -的形式来发布 CA 证书。 +{{< note >}} + +即使自定义 CA 证书可能包含在文件系统中（在 ConfigMap `kube-root-ca.crt` 中）， +除了验证内部 Kubernetes 端点之外，你不应将该证书颁发机构用于任何目的。 +内部 Kubernetes 端点的一个示例是默认命名空间中名为 `kubernetes` 的服务。 + +如果你想为你的工作负载使用自定义证书颁发机构，你应该单独生成该 CA， +并使用你的 Pod 有读权限的 [ConfigMap](/zh/docs/tasks/configure-pod-container/configure-pod-configmap) +分发该 CA 证书。 +{{< /note >}} -## 下载并安装 CFSSL - -本例中使用的 cfssl 工具可以在 [github.com/cloudflare/cfssl/releases](https://github.com/cloudflare/cfssl/releases) 下载。 - - 其中 `192.0.2.24` 是服务的集群 IP，`my-svc.my-namespace.svc.cluster.local` 是服务的 DNS 名称，`10.0.34.2` 是 Pod 的 IP，而 `my-pod.my-namespace.pod.cluster.local` 是 Pod 的 DNS 名称。 -你能看到以下的输出： +你能看到的输出类似于： ``` -2017/03/21 06:48:17 [INFO] generate received request -2017/03/21 06:48:17 [INFO] received CSR -2017/03/21 06:48:17 [INFO] generating key: ecdsa-256 -2017/03/21 06:48:17 [INFO] encoded CSR +2022/02/01 11:45:32 [INFO] generate received request +2022/02/01 11:45:32 [INFO] received CSR +2022/02/01 11:45:32 [INFO] generating key: ecdsa-256 +2022/02/01 11:45:32 [INFO] encoded CSR ``` 此命令生成两个文件；它生成包含 PEM 编码 -[pkcs#10](https://tools.ietf.org/html/rfc2986) 证书请求的 `server.csr`， +[PKCS#10](https://tools.ietf.org/html/rfc2986) 证书请求的 `server.csr`， 以及 PEM 编码密钥的 `server-key.pem`，用于待生成的证书。 -## 创建证书签名请求对象发送到 Kubernetes API +## 创建证书签名请求（CSR）对象发送到 Kubernetes API 使用以下命令创建 CSR YAML 文件，并发送到 API 服务器： @@ -178,7 +192,7 @@ metadata: name: my-svc.my-namespace spec: request: $(cat server.csr | base64 | tr -d '\n') - signerName: kubernetes.io/kubelet-serving + signerName: example.com/serving usages: - digital signature - key encipherment @@ -188,9 +202,9 @@ EOF 请注意，在步骤 1 中创建的 `server.csr` 文件是 base64 编码并存储在 -`.spec.request` 字段中的。我们还要求提供 “digital signature（数字签名）”， +`.spec.request` 字段中的。你还要求提供 “digital signature（数字签名）”， “密钥加密（key encipherment）” 和 “服务器身份验证（server auth）” 密钥用途， -由 `kubernetes.io/kubelet-serving` 签名程序签名的证书。 +由 `example.com/serving` 示例签名程序签名的证书。 你也可以要求使用特定的 `signerName`。更多信息可参阅 [支持的签署者名称](/zh/docs/reference/access-authn-authz/certificate-signing-requests/#signers)。 @@ -215,28 +229,30 @@ kubectl describe csr my-svc.my-namespace Name: my-svc.my-namespace Labels: Annotations: -CreationTimestamp: Tue, 21 Mar 2017 07:03:51 -0700 +CreationTimestamp: Tue, 01 Feb 2022 11:49:15 -0500 Requesting User: yourname@example.com +Signer: example.com/serving Status: Pending Subject: - Common Name: my-svc.my-namespace.svc.cluster.local + Common Name: my-pod.my-namespace.pod.cluster.local Serial Number: Subject Alternative Names: - DNS Names: my-svc.my-namespace.svc.cluster.local + DNS Names: my-pod.my-namespace.pod.cluster.local + my-svc.my-namespace.svc.cluster.local IP Addresses: 192.0.2.24 10.0.34.2 Events: ``` -## 批准证书签名请求 +## 批准证书签名请求（CSR） {#get-the-certificate-signing-request-approved} [证书签名请求](/zh/docs/reference/access-authn-authz/certificate-signing-requests/) 的批准或者是通过自动批准过程完成的，或由集群管理员一次性完成。 @@ -250,29 +266,167 @@ kubectl certificate approve my-svc.my-namespace certificatesigningrequest.certificates.k8s.io/my-svc.my-namespace approved ``` - -## 下载证书并使用它 - -CSR 被签署并获得批准后，你应该看到以下内容： + +你现在应该能看到如下输出： ```shell kubectl get csr ``` ```none -NAME AGE REQUESTOR CONDITION -my-svc.my-namespace 10m yourname@example.com Approved,Issued +NAME AGE SIGNERNAME REQUESTOR REQUESTEDDURATION CONDITION +my-svc.my-namespace 10m example.com/serving yourname@example.com Approved +``` + + +这意味着证书请求已被批准，并正在等待请求的签名者对其签名。 + + +## 签名证书签名请求（CSR） {#sign-the-certificate-signing-request} + +接下来，你将扮演证书签署者的角色，颁发证书并将其上传到 API 服务器。 + +签名者通常会使用其 `signerName` 查看对象的 CertificateSigningRequest API， +检查它们是否已被批准，为这些请求签署证书，并使用已颁发的证书更新 API 对象状态。 + + +### 创建证书颁发机构 + +你需要授权在新证书上提供数字签名。 + +首先，通过运行以下命令创建签名证书： + +```shell +cat < +你应该看到类似于以下的输出： + +```none +2022/02/01 11:50:39 [INFO] generating a new CA key and certificate from CSR +2022/02/01 11:50:39 [INFO] generate received request +2022/02/01 11:50:39 [INFO] received CSR +2022/02/01 11:50:39 [INFO] generating key: rsa-2048 +2022/02/01 11:50:39 [INFO] encoded CSR +2022/02/01 11:50:39 [INFO] signed certificate with serial number 263983151013686720899716354349605500797834580472 +``` + + +这会产生一个证书颁发机构密钥文件（`ca-key.pem`）和证书（`ca.pem`）。 + + + +### 颁发证书 + +{{< codenew file="tls/server-signing-config.json" >}} + + +使用 `server-signing-config.json` 签名配置、证书颁发机构密钥文件和证书来签署证书请求： + +```shell +kubectl get csr my-svc.my-namespace -o jsonpath='{.spec.request}' | \ + base64 --decode | \ + cfssl sign -ca ca.pem -ca-key ca-key.pem -config server-signing-config.json - | \ + cfssljson -bare ca-signed-server +``` + + +你应该看到类似于以下的输出： + +``` +2022/02/01 11:52:26 [INFO] signed certificate with serial number 576048928624926584381415936700914530534472870337 +``` + + +这会生成一个签名的服务证书文件，`ca-signed-server.pem`。 + + + +### 上传签名证书 + +最后，在 API 对象的状态中填充签名证书： + +```shell +kubectl get csr my-svc.my-namespace -o json | \ + jq '.status.certificate = "'$(base64 ca-signed-server.pem | tr -d '\n')'"' | \ + kubectl replace --raw /apis/certificates.k8s.io/v1/certificatesigningrequests/my-svc.my-namespace/status -f - +``` + +{{< note >}} + +这使用命令行工具 [`jq`](https://stedolan.github.io/jq/) +在 `.status.certificate` 字段中填充 base64 编码的内容。 +如果你没有 `jq` 工具，你还可以将 JSON 输出保存到文件中，手动填充此字段，然后上传结果文件。 +{{< /note >}} + + +批准 CSR 并上传签名证书后，运行： + +```shell +kubectl get csr +``` + + +输入类似于： + +```none +NAME AGE SIGNERNAME REQUESTOR REQUESTEDDURATION CONDITION +my-svc.my-namespace 20m example.com/serving yourname@example.com Approved,Issued ``` -你可以通过运行以下命令下载颁发的证书并将其保存到 `server.crt` 文件中： +## 下载证书并使用它 + +现在，作为请求用户，你可以通过运行以下命令下载颁发的证书并将其保存到 `server.crt` 文件中： + +CSR 被签署并获得批准后，你应该看到以下内容： ```shell kubectl get csr my-svc.my-namespace -o jsonpath='{.status.certificate}' \ @@ -280,31 +434,74 @@ kubectl get csr my-svc.my-namespace -o jsonpath='{.status.certificate}' \ ``` -现在你可以将 `server.crt` 和 `server-key.pem` 作为键值对来启动 HTTPS 服务器。 +现在你可以将 `server.crt` 和 `server-key.pem` 填充到 +{{}} 中， +稍后你可以将其挂载到 Pod 中（例如，用于提供 HTTPS 的网络服务器）。 + +```shell +kubectl create secret tls server --cert server.crt --key server-key.pem +``` + +```none +secret/server created +``` + + +最后，你可以将 `ca.pem` 填充到 +{{}} +并将其用作信任根来验证服务证书： + +```shell +kubectl create configmap example-serving-ca --from-file ca.crt=ca.pem +``` + +```none +configmap/example-serving-ca created +``` -## 批准证书签名请求 +## 批准证书签名请求（CSR） {#approving-certificate-signing-requests} Kubernetes 管理员（具有适当权限）可以使用 `kubectl certificate approve` 和 -`kubectl certificate deny` 命令手动批准（或拒绝）证书签名请求。 +`kubectl certificate deny` 命令手动批准（或拒绝）证书签名请求（CSR）。 但是，如果你打算大量使用此 API，则可以考虑编写自动化的证书控制器。 +{{< caution >}} + +批准证书 CSR 的能力决定了在你的环境中谁信任谁。 +不应广泛或轻率地授予批准 CSR 的能力。 + +在授予 `approve` 权限之前，你应该确保自己充分了解批准人的验证要求**和**颁发特定证书的后果。 +{{< /caution >}} + -无论上述机器或人使用 kubectl，批准者的作用是验证 CSR 满足如下两个要求： +无论上述机器或人使用 kubectl，“批准者”的作用是验证 CSR 满足如下两个要求： 当且仅当满足这两个要求时，审批者应该批准 CSR，否则拒绝 CSR。 - -## 关于批准权限的警告 - -批准 CSR 的能力决定了群集中的信任关系。这也包括 Kubernetes API 所信任的人。 -批准 CSR 的能力不能过于广泛和轻率。 -在给予本许可之前，应充分了解上一节中提到的挑战和发布特定证书的后果。 +有关证书批准和访问控制的更多信息， +请阅读[证书签名请求](/zh/docs/reference/access-authn-authz/certificate-signing-requests/)参考页。 ## 给集群管理员的一个建议 -本教程假设已经为 certificates API 配置了签名者。Kubernetes 控制器管理器 -提供了一个签名者的默认实现。要启用它，请为控制器管理器设置 +本页面假设已经为 certificates API 配置了签名者。 +Kubernetes 控制器管理器提供了一个签名者的默认实现。要启用它，请为控制器管理器设置 `--cluster-signing-cert-file` 和 `--cluster-signing-key-file` 参数， 使之取值为你的证书机构的密钥对的路径。 - diff --git a/content/zh/docs/test.md b/content/zh/docs/test.md index b6ee5be151..9642299b5d 100644 --- a/content/zh/docs/test.md +++ b/content/zh/docs/test.md @@ -156,7 +156,7 @@ Markdown 在如何处理列表方面没有严格的规则。在我们从 Jekyll consecutive lists. **The HTML comment needs to be at the left margin.** - Bullet lists can have paragraphs or block elements within them. - Indent the content to be one tab stop beyond the text of the bullet + Indent the content to be the same as the first line of the bullet point. **This paragraph and the code block line up with the second `l` in `Bullet` above.** @@ -669,12 +669,12 @@ HTML。 ## Visualizations with Mermaid You can use [Mermaid JS](https://mermaidjs.github.io) visualizations. -The Mermaid JS version is specified in [/layouts/partials/head.html](https://github.com/kubernetes/website/blob/master/layouts/partials/head.html) +The Mermaid JS version is specified in [/layouts/partials/head.html](https://github.com/kubernetes/website/blob/main/layouts/partials/head.html) --> ## 使用 Mermaid 来可视化 你可以使用 [Mermaid JS](https://mermaidjs.github.io) 来进行可视化展示。 -Mermaid JS 版本在 [/layouts/partials/head.html](https://github.com/kubernetes/website/blob/master/layouts/partials/head.html) +Mermaid JS 版本在 [/layouts/partials/head.html](https://github.com/kubernetes/website/blob/main/layouts/partials/head.html) 中设置。 如果没有看到名为 `cassandra` 的服务，则表示创建失败。 -请阅读[调试服务](/zh/docs/tasks/debug-application-cluster/debug-service/)，以解决常见问题。 +请阅读[调试服务](/zh/docs/tasks/debug/debug-application/debug-service/)，以解决常见问题。 -* 了解更多关于 [Introspection and Debugging](/zh/docs/tasks/debug-application-cluster/debug-application-introspection/) +* 了解更多关于 [Introspection and Debugging](/zh/docs/tasks/debug/debug-application) * 了解更多关于 [Jobs](/zh/docs/concepts/workloads/controllers/jobs-run-to-completion/) * 了解更多关于 [Port Forwarding](/zh/docs/tasks/access-application-cluster/port-forward-access-application-cluster/) -* 了解如何 [Get a Shell to a Container](/zh/docs/tasks/debug-application-cluster/get-shell-running-container/) +* 了解如何 [Get a Shell to a Container](/zh/docs/tasks/debug/debug-application/get-shell-running-container/) diff --git a/content/zh/examples/admin/dns/dns-horizontal-autoscaler.yaml b/content/zh/examples/admin/dns/dns-horizontal-autoscaler.yaml index dff87cf851..f7e7660e7a 100644 --- a/content/zh/examples/admin/dns/dns-horizontal-autoscaler.yaml +++ b/content/zh/examples/admin/dns/dns-horizontal-autoscaler.yaml @@ -1,33 +1,87 @@ +kind: ServiceAccount +apiVersion: v1 +metadata: + name: kube-dns-autoscaler + namespace: kube-system +--- +kind: ClusterRole +apiVersion: rbac.authorization.k8s.io/v1 +metadata: + name: system:kube-dns-autoscaler +rules: + - apiGroups: [""] + resources: ["nodes"] + verbs: ["list", "watch"] + - apiGroups: [""] + resources: ["replicationcontrollers/scale"] + verbs: ["get", "update"] + - apiGroups: ["apps"] + resources: ["deployments/scale", "replicasets/scale"] + verbs: ["get", "update"] +# 待以下 issue 修复后，请删除 Configmaps +# kubernetes-incubator/cluster-proportional-autoscaler#16 + - apiGroups: [""] + resources: ["configmaps"] + verbs: ["get", "create"] +--- +kind: ClusterRoleBinding +apiVersion: rbac.authorization.k8s.io/v1 +metadata: + name: system:kube-dns-autoscaler +subjects: + - kind: ServiceAccount + name: kube-dns-autoscaler + namespace: kube-system +roleRef: + kind: ClusterRole + name: system:kube-dns-autoscaler + apiGroup: rbac.authorization.k8s.io + +--- apiVersion: apps/v1 kind: Deployment metadata: - name: dns-autoscaler + name: kube-dns-autoscaler namespace: kube-system labels: - k8s-app: dns-autoscaler + k8s-app: kube-dns-autoscaler + kubernetes.io/cluster-service: "true" spec: selector: matchLabels: - k8s-app: dns-autoscaler + k8s-app: kube-dns-autoscaler template: metadata: labels: - k8s-app: dns-autoscaler + k8s-app: kube-dns-autoscaler spec: + priorityClassName: system-cluster-critical + securityContext: + seccompProfile: + type: RuntimeDefault + supplementalGroups: [ 65534 ] + fsGroup: 65534 + nodeSelector: + kubernetes.io/os: linux containers: - name: autoscaler - image: k8s.gcr.io/cluster-proportional-autoscaler-amd64:1.6.0 + image: k8s.gcr.io/cpa/cluster-proportional-autoscaler:1.8.4 resources: - requests: - cpu: 20m - memory: 10Mi + requests: + cpu: "20m" + memory: "10Mi" command: - - /cluster-proportional-autoscaler - - --namespace=kube-system - - --configmap=dns-autoscaler - - --target= - # When cluster is using large nodes(with more cores), "coresPerReplica" should dominate. - # If using small nodes, "nodesPerReplica" should dominate. - - --default-params={"linear":{"coresPerReplica":256,"nodesPerReplica":16,"min":1}} - - --logtostderr=true - - --v=2 + - /cluster-proportional-autoscaler + - --namespace=kube-system + - --configmap=kube-dns-autoscaler + # 应该保持目标与 cluster/addons/dns/kube-dns.yaml.base 同步 + - --target= + #当集群使用大节点（有更多核）时，“coresPerReplica”应该占主导地位。 + #如果使用小节点，“nodesPerReplica“ 应该占主导地位。 + - --default-params={"linear":{"coresPerReplica":256,"nodesPerReplica":16,"preventSinglePointFailure":true,"includeUnschedulableNodes":true}} + - --logtostderr=true + - --v=2 + tolerations: + - key: "CriticalAddonsOnly" + operator: "Exists" + serviceAccountName: kube-dns-autoscaler diff --git a/content/zh/examples/application/mongodb/mongo-deployment.yaml b/content/zh/examples/application/mongodb/mongo-deployment.yaml new file mode 100644 index 0000000000..04908ce25b --- /dev/null +++ b/content/zh/examples/application/mongodb/mongo-deployment.yaml @@ -0,0 +1,31 @@ +apiVersion: apps/v1 +kind: Deployment +metadata: + name: mongo + labels: + app.kubernetes.io/name: mongo + app.kubernetes.io/component: backend +spec: + selector: + matchLabels: + app.kubernetes.io/name: mongo + app.kubernetes.io/component: backend + replicas: 1 + template: + metadata: + labels: + app.kubernetes.io/name: mongo + app.kubernetes.io/component: backend + spec: + containers: + - name: mongo + image: mongo:4.2 + args: + - --bind_ip + - 0.0.0.0 + resources: + requests: + cpu: 100m + memory: 100Mi + ports: + - containerPort: 27017 diff --git a/content/zh/examples/application/mongodb/mongo-service.yaml b/content/zh/examples/application/mongodb/mongo-service.yaml new file mode 100644 index 0000000000..b9cef607bc --- /dev/null +++ b/content/zh/examples/application/mongodb/mongo-service.yaml @@ -0,0 +1,14 @@ +apiVersion: v1 +kind: Service +metadata: + name: mongo + labels: + app.kubernetes.io/name: mongo + app.kubernetes.io/component: backend +spec: + ports: + - port: 27017 + targetPort: 27017 + selector: + app.kubernetes.io/name: mongo + app.kubernetes.io/component: backend diff --git a/content/zh/examples/application/mysql/mysql-statefulset.yaml b/content/zh/examples/application/mysql/mysql-statefulset.yaml index b69af02c59..22aa944748 100644 --- a/content/zh/examples/application/mysql/mysql-statefulset.yaml +++ b/content/zh/examples/application/mysql/mysql-statefulset.yaml @@ -21,17 +21,18 @@ spec: - "-c" - | set -ex - # Generate mysql server-id from pod ordinal index. + # 基于 Pod 序号生成 MySQL 服务器的 ID。 [[ `hostname` =~ -([0-9]+)$ ]] || exit 1 ordinal=${BASH_REMATCH[1]} echo [mysqld] > /mnt/conf.d/server-id.cnf - # Add an offset to avoid reserved server-id=0 value. + # 添加偏移量以避免使用 server-id=0 这一保留值。 echo server-id=$((100 + $ordinal)) >> /mnt/conf.d/server-id.cnf # Copy appropriate conf.d files from config-map to emptyDir. + # 将合适的 conf.d 文件从 config-map 复制到 emptyDir。 if [[ $ordinal -eq 0 ]]; then - cp /mnt/config-map/master.cnf /mnt/conf.d/ + cp /mnt/config-map/primary.cnf /mnt/conf.d/ else - cp /mnt/config-map/slave.cnf /mnt/conf.d/ + cp /mnt/config-map/replica.cnf /mnt/conf.d/ fi volumeMounts: - name: conf @@ -45,15 +46,15 @@ spec: - "-c" - | set -ex - # Skip the clone if data already exists. + # 如果已有数据，则跳过克隆。 [[ -d /var/lib/mysql/mysql ]] && exit 0 - # Skip the clone on master (ordinal index 0). + # 跳过主实例（序号索引 0）的克隆。 [[ `hostname` =~ -([0-9]+)$ ]] || exit 1 ordinal=${BASH_REMATCH[1]} [[ $ordinal -eq 0 ]] && exit 0 - # Clone data from previous peer. + # 从原来的对等节点克隆数据。 ncat --recv-only mysql-$(($ordinal-1)).mysql 3307 | xbstream -x -C /var/lib/mysql - # Prepare the backup. + # 准备备份。 xtrabackup --prepare --target-dir=/var/lib/mysql volumeMounts: - name: data @@ -88,7 +89,7 @@ spec: timeoutSeconds: 5 readinessProbe: exec: - # Check we can execute queries over TCP (skip-networking is off). + # 检查我们是否可以通过 TCP 执行查询（skip-networking 是关闭的）。 command: ["mysql", "-h", "127.0.0.1", "-e", "SELECT 1"] initialDelaySeconds: 5 periodSeconds: 2 @@ -105,22 +106,22 @@ spec: set -ex cd /var/lib/mysql - # Determine binlog position of cloned data, if any. + # 确定克隆数据的 binlog 位置（如果有的话）。 if [[ -f xtrabackup_slave_info && "x$( change_master_to.sql.in - # Ignore xtrabackup_binlog_info in this case (it's useless). + # 在这里要忽略 xtrabackup_binlog_info （它是没用的）。 rm -f xtrabackup_slave_info xtrabackup_binlog_info elif [[ -f xtrabackup_binlog_info ]]; then - # We're cloning directly from master. Parse binlog position. + # 我们直接从主实例进行克隆。解析 binlog 位置。 [[ `cat xtrabackup_binlog_info` =~ ^(.*?)[[:space:]]+(.*?)$ ]] || exit 1 rm -f xtrabackup_binlog_info xtrabackup_slave_info echo "CHANGE MASTER TO MASTER_LOG_FILE='${BASH_REMATCH[1]}',\ MASTER_LOG_POS=${BASH_REMATCH[2]}" > change_master_to.sql.in fi - # Check if we need to complete a clone by starting replication. + # 检查我们是否需要通过启动复制来完成克隆。 if [[ -f change_master_to.sql.in ]]; then echo "Waiting for mysqld to be ready (accepting connections)" until mysql -h 127.0.0.1 -e "SELECT 1"; do sleep 1; done @@ -133,11 +134,11 @@ spec: MASTER_PASSWORD='', \ MASTER_CONNECT_RETRY=10; \ START SLAVE;" || exit 1 - # In case of container restart, attempt this at-most-once. + # 如果容器重新启动，最多尝试一次。 mv change_master_to.sql.in change_master_to.sql.orig fi - # Start a server to send backups when requested by peers. + # 当对等点请求时，启动服务器发送备份。 exec ncat --listen --keep-open --send-only --max-conns=1 3307 -c \ "xtrabackup --backup --slave-info --stream=xbstream --host=127.0.0.1 --user=root" volumeMounts: diff --git a/content/zh/examples/pods/probe/exec-liveness.yaml b/content/zh/examples/pods/probe/exec-liveness.yaml index 07bf75f85c..6a9c9b3213 100644 --- a/content/zh/examples/pods/probe/exec-liveness.yaml +++ b/content/zh/examples/pods/probe/exec-liveness.yaml @@ -11,7 +11,7 @@ spec: args: - /bin/sh - -c - - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600 + - touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600 livenessProbe: exec: command: diff --git a/content/zh/examples/policy/restricted-psp.yaml b/content/zh/examples/policy/restricted-psp.yaml index 99c836b9ff..53dec3a1af 100644 --- a/content/zh/examples/policy/restricted-psp.yaml +++ b/content/zh/examples/policy/restricted-psp.yaml @@ -3,6 +3,7 @@ kind: PodSecurityPolicy metadata: name: restricted annotations: + # docker/default 标识 seccomp 的配置文件，但它与 Docker 运行时没有特别关联 seccomp.security.alpha.kubernetes.io/allowedProfileNames: 'docker/default,runtime/default' apparmor.security.beta.kubernetes.io/allowedProfileNames: 'runtime/default' apparmor.security.beta.kubernetes.io/defaultProfileName: 'runtime/default' @@ -45,3 +46,4 @@ spec: - min: 1 max: 65535 readOnlyRootFilesystem: false + diff --git a/content/zh/examples/security/kind-with-cluster-level-baseline-pod-security.sh b/content/zh/examples/security/kind-with-cluster-level-baseline-pod-security.sh new file mode 100644 index 0000000000..15017d868b --- /dev/null +++ b/content/zh/examples/security/kind-with-cluster-level-baseline-pod-security.sh @@ -0,0 +1,70 @@ +#!/bin/sh +mkdir -p /tmp/pss +cat < /tmp/pss/cluster-level-pss.yaml +apiVersion: apiserver.config.k8s.io/v1 +kind: AdmissionConfiguration +plugins: +- name: PodSecurity + configuration: + apiVersion: pod-security.admission.config.k8s.io/v1beta1 + kind: PodSecurityConfiguration + defaults: + enforce: "baseline" + enforce-version: "latest" + audit: "restricted" + audit-version: "latest" + warn: "restricted" + warn-version: "latest" + exemptions: + usernames: [] + runtimeClasses: [] + namespaces: [kube-system] +EOF +cat < /tmp/pss/cluster-config.yaml +kind: Cluster +apiVersion: kind.x-k8s.io/v1alpha4 +nodes: +- role: control-plane + kubeadmConfigPatches: + - | + kind: ClusterConfiguration + apiServer: + extraArgs: + admission-control-config-file: /etc/config/cluster-level-pss.yaml + extraVolumes: + - name: accf + hostPath: /etc/config + mountPath: /etc/config + readOnly: false + pathType: "DirectoryOrCreate" + extraMounts: + - hostPath: /tmp/pss + containerPath: /etc/config + # optional: if set, the mount is read-only. + # default false + readOnly: false + # optional: if set, the mount needs SELinux relabeling. + # default false + selinuxRelabel: false + # optional: set propagation mode (None, HostToContainer or Bidirectional) + # see https://kubernetes.io/docs/concepts/storage/volumes/#mount-propagation + # default None + propagation: None +EOF +kind create cluster --name psa-with-cluster-pss --image kindest/node:v1.23.0 --config /tmp/pss/cluster-config.yaml +kubectl cluster-info --context kind-psa-with-cluster-pss +# 等待 15 秒（任意）ServiceAccount 准入控制器可用 +sleep 15 +cat < /tmp/pss/nginx-pod.yaml +apiVersion: v1 +kind: Pod +metadata: + name: nginx +spec: + containers: + - image: nginx + name: nginx + ports: + - containerPort: 80 +EOF +kubectl apply -f /tmp/pss/nginx-pod.yaml diff --git a/content/zh/examples/security/kind-with-namespace-level-baseline-pod-security.sh b/content/zh/examples/security/kind-with-namespace-level-baseline-pod-security.sh new file mode 100644 index 0000000000..278978753c --- /dev/null +++ b/content/zh/examples/security/kind-with-namespace-level-baseline-pod-security.sh @@ -0,0 +1,28 @@ +#!/bin/sh +# 直到 v1.23 发布，kind 节点镜像需要从 k/k master 分支构建 +# 参考：https://kind.sigs.k8s.io/docs/user/quick-start/#building-images +kind create cluster --name psa-ns-level --image kindest/node:v1.23.0 +kubectl cluster-info --context kind-psa-ns-level +# 等待 15 秒（任意）ServiceAccount 准入控制器可用 +sleep 15 +kubectl create ns example +kubectl label --overwrite ns example \ + pod-security.kubernetes.io/enforce=baseline \ + pod-security.kubernetes.io/enforce-version=latest \ + pod-security.kubernetes.io/warn=restricted \ + pod-security.kubernetes.io/warn-version=latest \ + pod-security.kubernetes.io/audit=restricted \ + pod-security.kubernetes.io/audit-version=latest +cat < /tmp/pss/nginx-pod.yaml +apiVersion: v1 +kind: Pod +metadata: + name: nginx +spec: + containers: + - image: nginx + name: nginx + ports: + - containerPort: 80 +EOF +kubectl apply -n example -f /tmp/pss/nginx-pod.yaml diff --git a/content/zh/examples/tls/server-signing-config.json b/content/zh/examples/tls/server-signing-config.json new file mode 100644 index 0000000000..86860d7369 --- /dev/null +++ b/content/zh/examples/tls/server-signing-config.json @@ -0,0 +1,15 @@ +{ + "signing": { + "default": { + "usages": [ + "digital signature", + "key encipherment", + "server auth" + ], + "expiry": "876000h", + "ca_constraint": { + "is_ca": false + } + } + } +} \ No newline at end of file