diff --git a/content/en/docs/contribute/review/reviewing-prs.md b/content/en/docs/contribute/review/reviewing-prs.md index 9240d98f3b..77bdc85806 100644 --- a/content/en/docs/contribute/review/reviewing-prs.md +++ b/content/en/docs/contribute/review/reviewing-prs.md @@ -85,7 +85,11 @@ class third,fourth white - Reading the PR description to understand the changes made, and read any linked issues - Reading any comments by other reviewers - Clicking the **Files changed** tab to see the files and lines changed - - Previewing the changes in the Netlify preview build by scrolling to the PR's build check section at the bottom of the **Conversation** tab and clicking the **deploy/netlify** line's **Details** link. + - Previewing the changes in the Netlify preview build by scrolling to the PR's build check section at the bottom of the **Conversation** tab. + Here's a screenshot (this shows GitHub's desktop site; if you're reviewing + on a tablet or smartphone device, the GitHub web UI is slightly different): + {{< figure src="/images/docs/github_netlify_deploy_preview.png" alt="GitHub pull request details including link to Netlify preview" >}} + To open the preview, click on the **Details** link of the **deploy/netlify** line in the list of checks. 4. Go to the **Files changed** tab to start your review. 1. Click on the `+` symbol beside the line you want to comment on. diff --git a/content/es/docs/concepts/security/controlling-access.md b/content/es/docs/concepts/security/controlling-access.md new file mode 100644 index 0000000000..8d33ac49b4 --- /dev/null +++ b/content/es/docs/concepts/security/controlling-access.md @@ -0,0 +1,179 @@ +--- +reviewers: +- electrocucaracha +- raelga +title: Controlando el Acceso a la API de Kubernetes +content_type: concept +--- + + +Esta página proporciona información sobre cómo controlar el acceso a la API de Kubernetes. + + + +Los usuarios acceden a la [API de Kubernetes](/docs/concepts/overview/kubernetes-api/) usando `kubectl`, +bibliotecas de cliente, o haciendo peticiones REST. Usuarios y +[Kubernetes service accounts](/docs/tasks/configure-pod-container/configure-service-account/) pueden ser +autorizados para acceder a la API. +Cuando una petición llega a la API, pasa por varias etapas, están ilustradas en el +siguiente diagrama: + +![Diagrama de pasos para una petición a la API de Kubernetes](/images/docs/admin/access-control-overview.svg) + +## Seguridad en la capa de transporte + +En un {{< glossary_tooltip term_id="cluster" text="cluster" >}} típico de Kubernetes, la API sirve peticiones en el puerto 443, protegida por TLS. +El {{< glossary_tooltip term_id="kube-apiserver" text="API Server" >}} presenta un certificado. Este certificado puede ser firmando usando +un certificado de autoridad privada (CA) o basado en una llave pública relacionada +generalmente a un CA reconocido. + +Si el cluster usa un certificado de autoridad privado, se necesita copiar este certificado +CA configurado dentro de su `~/.kube/config` en el cliente, entonces se podrá +confiar en la conexión y estar seguro que no será comprometida. + +El cliente puede presentar un certificado TLS de cliente en esta etapa. + +## Autenticación + +Una vez que se estableció la conexión TLS, las peticiones HTTP avanzan a la etapa de autenticación. +Esto se muestra en el paso 1 del diagrama. +El script de creación del cluster o el administrador del cluster puede configurar el {{< glossary_tooltip term_id="kube-apiserver" text="API Server" >}} para ejecutar +uno o mas módulos de autenticación. +Los Autenticadores están descritos con más detalle en +[Authentication](/docs/reference/access-authn-authz/authentication/). + +La entrada al paso de autenticación es la petición HTTP completa, aun así, esta tipicamente +examina las cabeceras y/o el certificado del cliente. + +Los modulos de autenticación incluyen certificado de cliente, contraseña, tokens planos, +tokens de inicio y JSON Web Tokens (usados para los service accounts). + +Múltiples módulos de autenticación puede ser especificados, en este caso cada uno es probado secuencialmente, +hasta que uno de ellos tiene éxito. + +Si la petición no puede ser autenticada, la misma es rechazada con un código HTTP 401. +Si la autenticación tiene éxito, el usuario es validado con el `username` específico, y el nombre de usuario +esta disponible para los pasos siguientes. Algunos autenticadores +también proporcionan membresías de grupo al usuario, mientras que otros +no lo hacen. + +Aunque Kubernetes utiliza los nombres de usuario para tomar decisiones durante el control de acceso y para registrar las peticiones de entrada, no tiene un objeto `User` ni tampoco almacena información sobre los usuarios en la API. + +## Autorización + +Después de autenticar la petición como proveniente de un usuario específico, la petición debe ser autorizada. Esto se muestra en el paso 2 del diagrama. + +Una petición debe incluir el nombre de usuario solicitante, la acción solicitada y el objeto afectado por la acción. La petición es autorizada si hay una política existente que declare que el usuario tiene permisos para la realizar la acción. + +Por ejemplo, si el usuario Bob tiene la siguiente política, entonces puede leer pods solamente en el namespace `projectCaribou`: + +```json +{ + "apiVersion": "abac.authorization.kubernetes.io/v1beta1", + "kind": "Policy", + "spec": { + "user": "bob", + "namespace": "projectCaribou", + "resource": "pods", + "readonly": true + } +} +``` +Si Bob hace la siguiente petición, será autorizada dado que tiene permitido leer los objetos en el namespace `projectCaribou` : + +```json +{ + "apiVersion": "authorization.k8s.io/v1beta1", + "kind": "SubjectAccessReview", + "spec": { + "resourceAttributes": { + "namespace": "projectCaribou", + "verb": "get", + "group": "unicorn.example.org", + "resource": "pods" + } + } +} +``` +En cambio, si Bob en su petición intenta escribir (`create` o `update`) en los objetos del namespace `projectCaribou`, la petición será denegada. Del mismo modo, si Bob hace una petición para leer (`get`) objetos en otro namespace como `projectFish`, la autorización también será denegada. + +Las autorizaciones en Kubernetes requieren que se usen atributos REST comunes para interactuar con el existente sistema de control de toda la organización o del proveedor cloud. Es importante usar formatos REST porque esos sistemas de control pueden interactuar con otras APIs además de la API de Kubernetes. + +Kubernetes soporta múltiples módulos de autorización, como el modo ABAC, el modo RBAC y el modo Webhook. Cuando un administrador crea un cluster, se realiza la configuración de los módulos de autorización que deben ser usados con la API del server. Si más de uno módulo de autorización es configurado, Kubernetes verificada cada uno y si alguno de ellos autoriza la petición entonces la misma se ejecuta. Si todos los modules deniegan la petición, entonces la misma es denegada (Con un error HTTP con código 403). + +Para leer más acerca de las autorizaciones en Kubernetes, incluyendo detalles sobre cómo crear politicas usando los módulos de autorización soportados, vea [Authorization](/docs/reference/access-authn-authz/authorization/). + + +## Control de Admisión + +Los módulos de Control de Admisión son módulos de software que solo pueden modificar o rechazar peticiones. +Adicionalmente a los atributos disponibles en los módulos de Autorización, los de +Control de Admisión pueden acceder al contenido del objeto que esta siendo creado o modificado. + +Los Controles de Admisión actúan en las peticiones que crean, modifican, borran o se conectan (proxy) a un objeto. +Cuando múltiples módulos de control de admisión son configurados, son llamados en orden. + +Esto se muestra en el paso 3 del diagrama. + +A diferencia de los módulos de Autorización y Autenticación, si uno de los módulos de control de admisión +rechaza la petición, entonces es inmediatamente rechazada. + +Adicionalmente a rechazar objetos, los controles de admisión también permiten establecer +valores predeterminados complejos. + +Los módulos de Control de Admisión disponibles están descritos en [Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/). + +Cuando una petición pasa todos los controles de admisión, esta es validada usando la rutinas de validación +para el objeto API correspondiente y luego es escrita en el objeto. + + +## Puertos e IPs del API server + +La discusión previa aplica a peticiones enviadas a un puerto seguro del servidor API +(el caso típico). El servidor API puede en realidad servir en 2 puertos: + +Por defecto, la API de Kubernetes entrega HTTP en 2 puertos: + + 1. puerto `localhost`: + + - debe usarse para testeo e iniciar el sistema y para otros componentes del nodo maestro + (scheduler, controller-manager) para hablar con la API + - no se usa TLS + - el puerto predeterminado es el `8080` + - la IP por defecto es localhost, la puede cambiar con el flag `--insecure-bind-address`. + - la petición no pasa por los mecanismos de autenticación ni autorización + - peticiones controladas por los modulos de control de admisión. + - protegidas por necesidad para tener acceso al host + + 2. “Puerto seguro”: + + - usar siempre que sea posible + - usa TLS. Se configura el certificado con el flag `--tls-cert-file` y la clave con `--tls-private-key-file`. + - el puerto predeterminado es `6443`, se cambia con el flag `--secure-port`. + - la IP por defecto es la primer interface que no es la localhost. se cambia con el flag `--bind-address`. + - peticiones controladas por los módulos de autenticación y autorización. + - peticiones controladas por los módulos de control de admisión. + +## {{% heading "whatsnext" %}} + +En los siguientes enlaces, encontrará mucha más documentación sobre autenticación, autorización y el control de acceso a la API: + +- [Authenticating](/docs/reference/access-authn-authz/authentication/) + - [Authenticating with Bootstrap Tokens](/docs/reference/access-authn-authz/bootstrap-tokens/) +- [Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/) + - [Dynamic Admission Control](/docs/reference/access-authn-authz/extensible-admission-controllers/) +- [Authorization](/docs/reference/access-authn-authz/authorization/) + - [Role Based Access Control](/docs/reference/access-authn-authz/rbac/) + - [Attribute Based Access Control](/docs/reference/access-authn-authz/abac/) + - [Node Authorization](/docs/reference/access-authn-authz/node/) + - [Webhook Authorization](/docs/reference/access-authn-authz/webhook/) +- [Certificate Signing Requests](/docs/reference/access-authn-authz/certificate-signing-requests/) + - including [CSR approval](/docs/reference/access-authn-authz/certificate-signing-requests/#approval-rejection) + and [certificate signing](/docs/reference/access-authn-authz/certificate-signing-requests/#signing) +- Service accounts + - [Developer guide](/docs/tasks/configure-pod-container/configure-service-account/) + - [Administration](/docs/reference/access-authn-authz/service-accounts-admin/) + +- Como los pods pueden usar + [Secrets](/docs/concepts/configuration/secret/#service-accounts-automatically-create-and-attach-secrets-with-api-credentials) + para obtener credenciales para la API. diff --git a/content/id/docs/concepts/cluster-administration/networking.md b/content/id/docs/concepts/cluster-administration/networking.md index 6bcd78d7ef..114f960d49 100644 --- a/content/id/docs/concepts/cluster-administration/networking.md +++ b/content/id/docs/concepts/cluster-administration/networking.md @@ -195,10 +195,6 @@ Multus mendukung semua [plugin referensi](https://github.com/containernetworking Platform Nuage menggunakan _overlay_ untuk menyediakan jaringan berbasis kebijakan yang mulus antara Kubernetes Pod-Pod dan lingkungan non-Kubernetes (VM dan server _bare metal_). Model abstraksi kebijakan Nuage dirancang dengan mempertimbangkan aplikasi dan membuatnya mudah untuk mendeklarasikan kebijakan berbutir halus untuk aplikasi. Mesin analisis _real-time_ platform memungkinkan pemantauan visibilitas dan keamanan untuk aplikasi Kubernetes. -### OpenVSwitch - -[OpenVSwitch](https://www.openvswitch.org/) adalah cara yang agak lebih dewasa tetapi juga rumit untuk membangun jaringan _overlay_. Ini didukung oleh beberapa "Toko Besar" untuk jaringan. - ### OVN (Open Virtual Networking) OVN adalah solusi virtualisasi jaringan opensource yang dikembangkan oleh komunitas Open vSwitch. Ini memungkinkan seseorang membuat switch logis, router logis, ACL stateful, load-balancers dll untuk membangun berbagai topologi jaringan virtual. Proyek ini memiliki plugin dan dokumentasi Kubernetes spesifik di [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes). diff --git a/content/id/docs/concepts/services-networking/service.md b/content/id/docs/concepts/services-networking/service.md index 3c85c5abbf..f464e26468 100644 --- a/content/id/docs/concepts/services-networking/service.md +++ b/content/id/docs/concepts/services-networking/service.md @@ -387,7 +387,7 @@ _Value_ dan perilaku dari tipe `Service` dijelaskan sebagai berikut: * `ClusterIP`: Mengekspos `Service` ke _range_ alamat IP di dalam klaster. Apabila kamu memilih _value_ ini `Service` yang kamu miliki hanya dapat diakses secara internal. tipe ini adalah _default_ _value_ dari _ServiceType_. - * [`NodePort`](#nodeport): Mengekspos `Service` pada setiap IP *node* pada _port_ statis + * [`NodePort`](#type-nodeport): Mengekspos `Service` pada setiap IP *node* pada _port_ statis atau _port_ yang sama. Sebuah `Service` `ClusterIP`, yang mana `Service` `NodePort` akan di-_route_ , dibuat secara otomatis. Kamu dapat mengakses `Service` dengan tipe ini, dari luar klaster melalui `:`. @@ -399,7 +399,7 @@ _Value_ dan perilaku dari tipe `Service` dijelaskan sebagai berikut: catatan `CNAME` beserta _value_-nya. Tidak ada metode _proxy_ apa pun yang diaktifkan. Mekanisme ini setidaknya membutuhkan `kube-dns` versi 1.7. -### Type NodePort {#nodeport} +### Type NodePort {#type-nodeport} Jika kamu menerapkan _value_ `NodePort` pada _field_ _type_, master Kubernetes akan mengalokasikan _port_ dari _range_ yang dispesifikasikan oleh penanda `--service-node-port-range` (secara _default_, 30000-32767) diff --git a/content/ja/docs/concepts/cluster-administration/networking.md b/content/ja/docs/concepts/cluster-administration/networking.md index 49daa2d42d..393829cf2e 100644 --- a/content/ja/docs/concepts/cluster-administration/networking.md +++ b/content/ja/docs/concepts/cluster-administration/networking.md @@ -243,7 +243,7 @@ Lars Kellogg-Stedman. ### Multus (a Multi Network plugin) -[Multus](https://github.com/Intel-Corp/multus-cni) is a Multi CNI plugin to support the Multi Networking feature in Kubernetes using CRD based network objects in Kubernetes. +Multus is a Multi CNI plugin to support the Multi Networking feature in Kubernetes using CRD based network objects in Kubernetes. Multus supports all [reference plugins](https://github.com/containernetworking/plugins) (eg. [Flannel](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel), [DHCP](https://github.com/containernetworking/plugins/tree/master/plugins/ipam/dhcp), [Macvlan](https://github.com/containernetworking/plugins/tree/master/plugins/main/macvlan)) that implement the CNI specification and 3rd party plugins (eg. [Calico](https://github.com/projectcalico/cni-plugin), [Weave](https://github.com/weaveworks/weave), [Cilium](https://github.com/cilium/cilium), [Contiv](https://github.com/contiv/netplugin)). In addition to it, Multus supports [SRIOV](https://github.com/hustcat/sriov-cni), [DPDK](https://github.com/Intel-Corp/sriov-cni), [OVS-DPDK & VPP](https://github.com/intel/vhost-user-net-plugin) workloads in Kubernetes with both cloud native and NFV based applications in Kubernetes. diff --git a/content/ja/docs/concepts/extend-kubernetes/_index.md b/content/ja/docs/concepts/extend-kubernetes/_index.md index fb3b249cfc..b1aaaadf3f 100644 --- a/content/ja/docs/concepts/extend-kubernetes/_index.md +++ b/content/ja/docs/concepts/extend-kubernetes/_index.md @@ -30,7 +30,7 @@ Kubernetesは柔軟な設定が可能で、高い拡張性を持っています ホスティングされたKubernetesサービスやマネージドなKubernetesでは、フラグと設定ファイルが常に変更できるとは限りません。変更可能な場合でも、通常はクラスターの管理者のみが変更できます。また、それらは将来のKubernetesバージョンで変更される可能性があり、設定変更にはプロセスの再起動が必要になるかもしれません。これらの理由により、この方法は他の選択肢が無いときにのみ利用するべきです。 -[ResourceQuota](/docs/concepts/policy/resource-quotas/)、[PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/)、[NetworkPolicy](/docs/concepts/services-networking/network-policies/)、そしてロールベースアクセス制御([RBAC](/docs/reference/access-authn-authz/rbac/))といった *ビルトインポリシーAPI* は、ビルトインのKubernetes APIです。APIは通常、ホスティングされたKubernetesサービスやマネージドなKubernetesで利用されます。これらは宣言的で、Podのような他のKubernetesリソースと同じ慣例に従っています。そのため、新しいクラスターの設定は繰り返し再利用することができ、アプリケーションと同じように管理することが可能です。さらに、安定版(stable)を利用している場合、他のKubernetes APIのような[定義済みのサポートポリシー](/docs/reference/deprecation-policy/)を利用することができます。これらの理由により、この方法は、適切な用途の場合、 *設定ファイル* や *フラグ* よりも好まれます。 +[ResourceQuota](/ja/docs/concepts/policy/resource-quotas/)、[PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/)、[NetworkPolicy](/ja/docs/concepts/services-networking/network-policies/)、そしてロールベースアクセス制御([RBAC](/ja/docs/reference/access-authn-authz/rbac/))といった *ビルトインポリシーAPI* は、ビルトインのKubernetes APIです。APIは通常、ホスティングされたKubernetesサービスやマネージドなKubernetesで利用されます。これらは宣言的で、Podのような他のKubernetesリソースと同じ慣例に従っています。そのため、新しいクラスターの設定は繰り返し再利用することができ、アプリケーションと同じように管理することが可能です。さらに、安定版(stable)を利用している場合、他のKubernetes APIのような[定義済みのサポートポリシー](/docs/reference/deprecation-policy/)を利用することができます。これらの理由により、この方法は、適切な用途の場合、 *設定ファイル* や *フラグ* よりも好まれます。 ## 拡張 @@ -115,7 +115,7 @@ Kubdernetesはいくつかのビルトイン認証方式をサポートしてい [認証](/ja/docs/reference/access-authn-authz/authentication/)は、全てのリクエストのヘッダーまたは証明書情報を、リクエストを投げたクライアントのユーザー名にマッピングします。 -Kubernetesはいくつかのビルトイン認証方式と、それらが要件に合わない場合、[認証Webhook](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication)を提供します。 +Kubernetesはいくつかのビルトイン認証方式と、それらが要件に合わない場合、[認証Webhook](/ja/docs/reference/access-authn-authz/authentication/#webhook-token-authentication)を提供します。 ### 認可 diff --git a/content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md index 85c1c4a77f..9fea0905c6 100644 --- a/content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md +++ b/content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md @@ -118,7 +118,7 @@ CRDオブジェクトの名前は[DNSサブドメイン名](/ja/docs/concepts/ov 通常、Kubernetes APIの各リソースは、RESTリクエストとオブジェクトの永続的なストレージを管理するためのコードが必要です。メインのKubernetes APIサーバーは *Pod* や *Service* のようなビルトインのリソースを処理し、またカスタムリソースも[CRD](#customresourcedefinition)を通じて同じように管理することができます。 -[アグリゲーションレイヤー](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)は、独自のスタンドアローンAPIサーバーを書き、デプロイすることで、カスタムリソースに特化した実装の提供を可能にします。メインのAPIサーバーが、処理したいカスタムリソースへのリクエストを委譲することで、他のクライアントからも利用できるようにします。 +[アグリゲーションレイヤー](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)は、独自のAPIサーバーを書き、デプロイすることで、カスタムリソースに特化した実装の提供を可能にします。メインのAPIサーバーが、処理したいカスタムリソースへのリクエストを独自のAPIサーバーに委譲することで、他のクライアントからも利用できるようにします。 ## カスタムリソースの追加方法を選択する diff --git a/content/ja/docs/concepts/extend-kubernetes/operator.md b/content/ja/docs/concepts/extend-kubernetes/operator.md index 9418540b4b..a674087bce 100644 --- a/content/ja/docs/concepts/extend-kubernetes/operator.md +++ b/content/ja/docs/concepts/extend-kubernetes/operator.md @@ -26,7 +26,8 @@ Kubernetes上でワークロードを稼働させている人は、しばしば Kubernetesは自動化のために設計されています。追加の作業、設定無しに、Kubernetesのコア機能によって多数のビルトインされた自動化機能が提供されます。 ワークロードのデプロイおよび稼働を自動化するためにKubernetesを使うことができます。 *さらに* Kubernetesがそれをどのように行うかの自動化も可能です。 -Kubernetesの{{< glossary_tooltip text="コントローラー" term_id="controller" >}}コンセプトは、Kubernetesのソースコードを修正すること無く、クラスターの振る舞いを拡張することを可能にします。 + +Kubernetesの{{< glossary_tooltip text="オペレーターパターン" term_id="operator-pattern" >}}コンセプトは、Kubernetesのソースコードを修正すること無く、一つ以上のカスタムリソースに{{< glossary_tooltip text="カスタムコントローラー" term_id="controller" >}}をリンクすることで、クラスターの振る舞いを拡張することを可能にします。 オペレーターはKubernetes APIのクライアントで、[Custom Resource](/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources/)にとっての、コントローラーのように振る舞います。 ## オペレーターの例 {#example} diff --git a/content/ja/docs/setup/best-practices/cluster-large.md b/content/ja/docs/setup/best-practices/cluster-large.md index 5a1f45b662..4f99e1b551 100644 --- a/content/ja/docs/setup/best-practices/cluster-large.md +++ b/content/ja/docs/setup/best-practices/cluster-large.md @@ -1,123 +1,98 @@ --- -title: 大規模クラスタの構築 +title: 大規模クラスターの構築 weight: 20 --- -## サポート -At {{< param "version" >}}, Kubernetes supports clusters with up to 5000 nodes. More specifically, we support configurations that meet *all* of the following criteria: +クラスターはKubernetesのエージェントが動作する(物理もしくは仮想の){{< glossary_tooltip text="ノード" term_id="node" >}}の集合で、{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}によって管理されます。 +Kubernetes {{< param "version" >}} では、最大5000ノードから構成されるクラスターをサポートします。 +具体的には、Kubernetesは次の基準を *全て* 満たす構成に対して適用できるように設計されています。 -* No more than 110 pods per node -* No more than 5000 nodes -* No more than 150000 total pods -* No more than 300000 total containers +* 1ノードにつきPodが110個以上存在しない +* 5000ノード以上存在しない +* Podの総数が150000個以上存在しない +* コンテナの総数が300000個以上存在しない + +ノードを追加したり削除したりすることによって、クラスターをスケールできます。 +これを行う方法は、クラスターがどのようにデプロイされたかに依存します。 -## 構築 +## クラウドプロバイダーのリソースクォータ {#クォータの問題} -A cluster is a set of nodes (physical or virtual machines) running Kubernetes agents, managed by a "master" (the cluster-level control plane). +クラウドプロバイダーのクォータの問題に遭遇することを避けるため、多数のノードを使ったクラスターを作成するときには次のようなことを考慮してください。 -Normally the number of nodes in a cluster is controlled by the value `NUM_NODES` in the platform-specific `config-default.sh` file (for example, see [GCE's `config-default.sh`](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/gce/config-default.sh)). +* 次のようなクラウドリソースの増加をリクエストする + * コンピューターインスタンス + * CPU + * ストレージボリューム + * 使用中のIPアドレス + * パケットフィルタリングのルールセット + * ロードバランサーの数 + * ネットワークサブネット + * ログストリーム +* クラウドプロバイダーによる新しいインスタンスの作成に対するレート制限のため、バッチで新しいノードを立ち上げるようなクラスターのスケーリング操作を通すためには、バッチ間ですこし休止を入れます。 -Simply changing that value to something very large, however, may cause the setup script to fail for many cloud providers. A GCE deployment, for example, will run in to quota issues and fail to bring the cluster up. -When setting up a large Kubernetes cluster, the following issues must be considered. +## コントロールプレーンのコンポーネント -### クォータの問題 +大きなクラスターでは、十分な計算とその他のリソースを持ったコントロールプレーンが必要になります。 -To avoid running into cloud provider quota issues, when creating a cluster with many nodes, consider: +特に故障ゾーンあたり1つまたは2つのコントロールプレーンインスタンスを動かす場合、最初に垂直方向にインスタンスをスケールし、垂直方向のスケーリングの効果が低下するポイントに達したら水平方向にスケールします。 -* Increase the quota for things like CPU, IPs, etc. - * In [GCE, for example,](https://cloud.google.com/compute/docs/resource-quotas) you'll want to increase the quota for: - * CPUs - * VM instances - * Total persistent disk reserved - * In-use IP addresses - * Firewall Rules - * Forwarding rules - * Routes - * Target pools -* Gating the setup script so that it brings up new node VMs in smaller batches with waits in between, because some cloud providers rate limit the creation of VMs. +フォールトトレランスを備えるために、1つの故障ゾーンに対して最低1インスタンスを動かすべきです。 +Kubernetesノードは、同一故障ゾーン内のコントロールプレーンエンドポイントに対して自動的にトラフィックが向かないようにします。 +しかし、クラウドプロバイダーはこれを実現するための独自の機構を持っているかもしれません。 -### Etcdのストレージ +例えばマネージドなロードバランサーを使うと、故障ゾーン _A_ にあるkubeletやPodから発生したトラフィックを、同じく故障ゾーン _A_ にあるコントロールプレーンホストに対してのみ送るように設定します。もし1つのコントロールプレーンホストまたは故障ゾーン _A_ のエンドポイントがオフラインになった場合、ゾーン _A_ にあるノードについてすべてのコントロールプレーンのトラフィックはゾーンを跨いで送信されます。それぞれのゾーンで複数のコントロールプレーンホストを動作させることは、結果としてほとんどありません。 -To improve performance of large clusters, we store events in a separate dedicated etcd instance. -When creating a cluster, existing salt scripts: +## etcdストレージ -* start and configure additional etcd instance -* configure api-server to use it for storing events +大きなクラスターの性能を向上させるために、他の専用のetcdインスタンスにイベントオブジェクトを保存できます。 -### マスターのサイズと構成要素 +クラスターを作るときに、(カスタムツールを使って)以下のようなことができます。 -On GCE/Google Kubernetes Engine, and AWS, `kube-up` automatically configures the proper VM size for your master depending on the number of nodes -in your cluster. On other providers, you will need to configure it manually. For reference, the sizes we use on GCE are +* 追加のetcdインスタンスを起動または設定する +* イベントを保存するために{{< glossary_tooltip term_id="kube-apiserver" text="APIサーバ" >}}を設定する -* 1-5 nodes: n1-standard-1 -* 6-10 nodes: n1-standard-2 -* 11-100 nodes: n1-standard-4 -* 101-250 nodes: n1-standard-8 -* 251-500 nodes: n1-standard-16 -* more than 500 nodes: n1-standard-32 +大きなクラスターのためにetcdを設定・管理する詳細については、[Operating etcd clusters for Kubernetes](/docs/tasks/administer-cluster/configure-upgrade-etcd/)または[kubeadmを使用した高可用性etcdクラスターの作成](/ja/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/)を見てください。 -And the sizes we use on AWS are -* 1-5 nodes: m3.medium -* 6-10 nodes: m3.large -* 11-100 nodes: m3.xlarge -* 101-250 nodes: m3.2xlarge -* 251-500 nodes: c4.4xlarge -* more than 500 nodes: c4.8xlarge +## アドオンのリソース -{{< note >}} -On Google Kubernetes Engine, the size of the master node adjusts automatically based on the size of your cluster. For more information, see [this blog post](https://cloudplatform.googleblog.com/2017/11/Cutting-Cluster-Management-Fees-on-Google-Kubernetes-Engine.html). +Kubernetesの[リソース制限](/ja/docs/concepts/configuration/manage-resources-containers/)は、メモリリークの影響やPodやコンテナが他のコンポーネントに与える他の影響を最小化することに役立ちます。 +これらのリソース制限は、アプリケーションのワークロードに適用するのと同様に、{{< glossary_tooltip text="アドオン" term_id="addons" >}}のリソースにも適用されます。 -On AWS, master node sizes are currently set at cluster startup time and do not change, even if you later scale your cluster up or down by manually removing or adding nodes or using a cluster autoscaler. -{{< /note >}} - -### アドオンのリソース - -To prevent memory leaks or other resource issues in [cluster addons](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons) from consuming all the resources available on a node, Kubernetes sets resource limits on addon containers to limit the CPU and Memory resources they can consume (See PR [#10653](https://pr.k8s.io/10653/files) and [#10778](https://pr.k8s.io/10778/files)). - -For example: +例えば、ロギングコンポーネントに対してCPUやメモリ制限を設定できます。 ```yaml + ... containers: - name: fluentd-cloud-logging - image: k8s.gcr.io/fluentd-gcp:1.16 + image: fluent/fluentd-kubernetes-daemonset:v1 resources: limits: cpu: 100m memory: 200Mi ``` -Except for Heapster, these limits are static and are based on data we collected from addons running on 4-node clusters (see [#10335](https://issue.k8s.io/10335#issuecomment-117861225)). The addons consume a lot more resources when running on large deployment clusters (see [#5880](http://issue.k8s.io/5880#issuecomment-113984085)). So, if a large cluster is deployed without adjusting these values, the addons may continuously get killed because they keep hitting the limits. +アドオンのデフォルト制限は、アドオンを小～中規模のKubernetesクラスターで動作させたときの経験から得られたデータに基づきます。 +大規模のクラスターで動作させる場合は、アドオンはデフォルト制限よりも多くのリソースを消費することが多いです。 +これらの値を調整せずに大規模のクラスターをデプロイした場合、メモリー制限に達し続けるため、アドオンが継続的に停止されるかもしれません。 +あるいは、CPUのタイムスライス制限により性能がでない状態で動作するかもしれません。 -To avoid running into cluster addon resource issues, when creating a cluster with many nodes, consider the following: +クラスターのアドオンのリソース制限に遭遇しないために、多くのノードで構成されるクラスターを構築する場合は次のことを考慮します。 -* Scale memory and CPU limits for each of the following addons, if used, as you scale up the size of cluster (there is one replica of each handling the entire cluster so memory and CPU usage tends to grow proportionally with size/load on cluster): - * [InfluxDB and Grafana](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/cluster-monitoring/influxdb/influxdb-grafana-controller.yaml) - * [kubedns, dnsmasq, and sidecar](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kube-dns/kube-dns.yaml.in) - * [Kibana](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/kibana-deployment.yaml) -* Scale number of replicas for the following addons, if used, along with the size of cluster (there are multiple replicas of each so increasing replicas should help handle increased load, but, since load per replica also increases slightly, also consider increasing CPU/memory limits): - * [elasticsearch](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/es-statefulset.yaml) -* Increase memory and CPU limits slightly for each of the following addons, if used, along with the size of cluster (there is one replica per node but CPU/memory usage increases slightly along with cluster load/size as well): - * [FluentD with ElasticSearch Plugin](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/fluentd-es-ds.yaml) - * [FluentD with GCP Plugin](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-gcp/fluentd-gcp-ds.yaml) +* いくつかのアドオンは垂直方向にスケールします - クラスターに1つのレプリカ、もしくは故障ゾーン全体にサービングされるものがあります。このようなアドオンでは、クラスターをスケールアウトしたときにリクエストと制限を増やす必要があります。 +* 数多くのアドオンは、水平方向にスケールします - より多くのPod数を動作させることで性能を向上できます - ただし、とても大きなクラスターではCPUやメモリの制限も少し引き上げる必要があるかもしれません。VerticalPodAutoscalerは、提案されたリクエストや制限の数値を提供する `_recommender_` モードで動作可能です。 +* いくつかのアドオンは{{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}}によって制御され、1ノードに1つ複製される形で動作します: 例えばノードレベルのログアグリゲーターです。水平方向にスケールするアドオンの場合と同様に、CPUやメモリ制限を少し引き上げる必要があるかもしれません。 -Heapster's resource limits are set dynamically based on the initial size of your cluster (see [#16185](http://issue.k8s.io/16185) -and [#22940](http://issue.k8s.io/22940)). If you find that Heapster is running -out of resources, you should adjust the formulas that compute heapster memory request (see those PRs for details). -For directions on how to detect if addon containers are hitting resource limits, see the -[Troubleshooting section of Compute Resources](/docs/concepts/configuration/manage-resources-containers/#troubleshooting). +## {{% heading "whatsnext" %}} -### 少数のノードの起動の失敗を許容する +`VerticalPodAutoscaler` は、リソースのリクエストやPodの制限についての管理を手助けするためにクラスターへデプロイ可能なカスタムリソースです。 +`VerticalPodAutoscaler` やクラスターで致命的なアドオンを含むクラスターコンポーネントをスケールする方法についてさらに知りたい場合は[Vertical Pod Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#readme)をご覧ください。 -For various reasons (see [#18969](https://github.com/kubernetes/kubernetes/issues/18969) for more details) running -`kube-up.sh` with a very large `NUM_NODES` may fail due to a very small number of nodes not coming up properly. -Currently you have two choices: restart the cluster (`kube-down.sh` and then `kube-up.sh` again), or before -running `kube-up.sh` set the environment variable `ALLOWED_NOTREADY_NODES` to whatever value you feel comfortable -with. This will allow `kube-up.sh` to succeed with fewer than `NUM_NODES` coming up. Depending on the -reason for the failure, those additional nodes may join later or the cluster may remain at a size of -`NUM_NODES - ALLOWED_NOTREADY_NODES`. +[cluster autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#readme)は、クラスターで要求されるリソース水準を満たす正確なノード数で動作できるよう、いくつかのクラウドプロバイダーと統合されています。 + +[addon resizer](https://github.com/kubernetes/autoscaler/tree/master/addon-resizer#readme)は、クラスターのスケールが変化したときにアドオンの自動的なリサイズをお手伝いします。 diff --git a/content/pt-br/docs/concepts/configuration/overview.md b/content/pt-br/docs/concepts/configuration/overview.md index 66f369c03b..67ef561605 100644 --- a/content/pt-br/docs/concepts/configuration/overview.md +++ b/content/pt-br/docs/concepts/configuration/overview.md @@ -23,7 +23,7 @@ Isso permite que você reverta rapidamente uma alteração de configuração, ca - Escreva seus arquivos de configuração usando YAML ao invés de JSON. Embora esses formatos possam ser usados alternadamente em quase todos os cenários, YAML tende a ser mais amigável. - Agrupe objetos relacionados em um único arquivo sempre que fizer sentido. Geralmente, um arquivo é mais fácil de -gerenciar do que vários. Veja o [guestbook-all-in-one.yaml](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/all-in-one/guestbook-all-in-one.yaml) como exemplo dessa sintaxe. +gerenciar do que vários. Veja o [guestbook-all-in-one.yaml](https://github.com/kubernetes/examples/tree/master/guestbook/all-in-one/guestbook-all-in-one.yaml) como exemplo dessa sintaxe. - Observe também que vários comandos `kubectl` podem ser chamados em um diretório. Por exemplo, você pode chamar `kubectl apply` em um diretório de arquivos de configuração. diff --git a/content/ru/docs/concepts/overview/kubernetes-api.md b/content/ru/docs/concepts/overview/kubernetes-api.md index c669cb973a..e2523c5191 100644 --- a/content/ru/docs/concepts/overview/kubernetes-api.md +++ b/content/ru/docs/concepts/overview/kubernetes-api.md @@ -77,7 +77,7 @@ GET /swagger-2.0.0.pb-v1.gz | GET /openapi/v2 **Accept**: application/com.github - Названия версий включают надпись `beta` (например, `v2beta3`). - Код хорошо протестирован. Активация этой функциональности — безопасно. Поэтому она включена по умолчанию. - Поддержка функциональности в целом не будет прекращена, хотя кое-что может измениться. - - Схема и/или семантика объектов может стать несовместимой с более поздними бета-версиями или стабильными выпусками. Когда это случится, мы даим инструкции по миграции на следующую версию. Это обновление может включать удаление, редактирование и повторного создание API-объектов. Этот процесс может потребовать тщательного анализа. Кроме этого, это может привести к простою приложений, которые используют данную функциональность. + - Схема и/или семантика объектов может стать несовместимой с более поздними бета-версиями или стабильными выпусками. Когда это случится, мы даем инструкции по миграции на следующую версию. Это обновление может включать удаление, редактирование и повторного создание API-объектов. Этот процесс может потребовать тщательного анализа. Кроме этого, это может привести к простою приложений, которые используют данную функциональность. - Рекомендуется только для неосновного производственного использования из-за риска возникновения возможных несовместимых изменений с будущими версиями. Если у вас есть несколько кластеров, которые возможно обновить независимо, вы можете снять это ограничение. - **Пожалуйста, попробуйте в действии бета-версии функциональности и поделитесь своими впечатлениями! После того, как функциональность выйдет из бета-версии, нам может быть нецелесообразно что-то дальше изменять.** - Стабильные версии: diff --git a/content/ru/docs/templates/feature-state-beta.txt b/content/ru/docs/templates/feature-state-beta.txt index 7e4f0d91b6..2d3786020d 100644 --- a/content/ru/docs/templates/feature-state-beta.txt +++ b/content/ru/docs/templates/feature-state-beta.txt @@ -3,6 +3,6 @@ * Названия версий включают надпись "beta" (например, v2beta3). * Код хорошо протестирован. Активация этой функциональности — безопасно. Поэтому она включена по умолчанию. * Поддержка функциональности в целом не будет прекращена, хотя детали могут измениться. -* Схема и/или семантика объектов может стать несовместимой с более поздними бета-версиями или стабильными выпусками. Когда это случится, мы даим инструкции по миграции на следующую версию. Это обновление может включать удаление, редактирование и повторного создание API-объектов. Этот процесс может потребовать тщательного анализа. Кроме этого, он может привести к простою приложений, которые используют данную функциональность. +* Схема и/или семантика объектов может стать несовместимой с более поздними бета-версиями или стабильными выпусками. Когда это случится, мы даем инструкции по миграции на следующую версию. Это обновление может включать удаление, редактирование и повторного создание API-объектов. Этот процесс может потребовать тщательного анализа. Кроме этого, он может привести к простою приложений, которые используют данную функциональность. * Рекомендуется только для неосновного производственного использования из-за риска возникновения возможных несовместимых изменений с будущими версиями. Если у вас есть несколько кластеров, которые возможно обновить независимо, вы можете снять это ограничение. * **Пожалуйста, попробуйте в действии бета-версии функциональности и поделитесь своими впечатлениями! После того, как функциональность выйдет из бета-версии, нам может быть нецелесообразно что-то дальше изменять.** diff --git a/content/zh/docs/concepts/workloads/pods/disruptions.md b/content/zh/docs/concepts/workloads/pods/disruptions.md index a85f37ff03..d94bf9121a 100644 --- a/content/zh/docs/concepts/workloads/pods/disruptions.md +++ b/content/zh/docs/concepts/workloads/pods/disruptions.md @@ -253,11 +253,12 @@ Pod 控制器的 `.spec.replicas` 计算“预期的” Pod 数量。 根据 Pod 对象的 `.metadata.ownerReferences` 字段来发现控制器。 -PDB 不能阻止[非自愿干扰](#voluntary-and-involuntary-disruptions)的发生，但是确实会计入 -预算。 + +PDB 无法防止[非自愿干扰](#voluntary-and-involuntary-disruptions)； +但它们确实计入预算。 -{{< feature-state state="alpha" for_k8s_version="v1.22" >}} +{{< feature-state state="beta" for_k8s_version="v1.23" >}} -临时容器处于 Alpha 阶段，不适用于生产环境集群。 -根据 [Kubernetes 弃用政策](/zh/docs/reference/using-api/deprecation-policy/)， -此 Alpha 功能将来可能发生重大变化或被完全删除。 -{{< /warning >}} - 本页讨论 Kubernetes 文档的样式指南。 @@ -34,7 +34,7 @@ discussion. 样式指南的变更是 SIG Docs 团队集体决定。 如要提议更改或新增条目，请先将其添加到下一次 SIG Docs 例会的 -[议程表](https://docs.google.com/document/d/1ddHwLK3kUMX1wVFIwlksjTk0MsqitBnWPe1LRa1Rx5A/edit) +[议程表](https://bit.ly/sig-docs-agenda) 上，并按时参加会议讨论。 @@ -123,7 +123,7 @@ For managing confidential data, consider using the Secret API. | For managing co {{< table caption = "使用 Pascal 风格大小写来给出 API 对象的约定" >}} 可以 | 不可以 :--| :----- -该 HorizontalPodAutoscaler 负责... | 该 HorizontalPodAutoscaler 负责... +该 HorizontalPodAutoscaler 负责... | 该 Horizontal pod autoscaler 负责... 每个 PodList 是一个 Pod 组成的列表。 | 每个 Pod List 是一个由 pods 组成的列表。 该 Volume 对象包含一个 `hostPath` 字段。 | 此卷对象包含一个 hostPath 字段。 每个 ConfigMap 对象都是某个名字空间的一部分。| 每个 configMap 对象是某个名字空间的一部分。 diff --git a/content/zh/docs/reference/config-api/apiserver-audit.v1.md b/content/zh/docs/reference/config-api/apiserver-audit.v1.md index c2e4a37704..245096e999 100644 --- a/content/zh/docs/reference/config-api/apiserver-audit.v1.md +++ b/content/zh/docs/reference/config-api/apiserver-audit.v1.md @@ -1,145 +1,171 @@ --- -title: kube-apiserver Audit Configuration (v1) +title: kube-apiserver Audit 配置 (v1) content_type: tool-reference package: audit.k8s.io/v1 auto_generated: true --- + + +## 资源类型 {#resource-types} - [Event](#audit-k8s-io-v1-Event) - [EventList](#audit-k8s-io-v1-EventList) - [Policy](#audit-k8s-io-v1-Policy) - [PolicyList](#audit-k8s-io-v1-PolicyList) - - - ## `Event` {#audit-k8s-io-v1-Event} - - - + +**出现在：** - [EventList](#audit-k8s-io-v1-EventList) - + +Event 结构包含可出现在 API 审计日志中的所有信息。 - + - - - - + + 生成事件所对应的审计级别。 + - - + + 为每个请求所生成的唯一审计 ID。 + - - + + 生成此事件时请求的处理阶段。 + - - + + requestURI 是客户端发送到服务器端的请求 URI。 + - + + verb 是与请求对应的 Kubernetes 动词。对于非资源请求，此字段为 HTTP 方法的小写形式。 + - - + + 关于认证用户的信息。 + - - + + + 关于所伪装（impersonated）的用户的信息。 + - - + + + 发起请求和中间代理的源 IP 地址。 + - - + + + + userAgent 中记录客户端所报告的用户代理（User Agent）字符串。 + 注意 userAgent 信息是由客户端提供的，一定不要信任。 + - - + + + 此请求所指向的对象引用。对于 List 类型的请求或者非资源请求，此字段可忽略。 + - - + + + 响应的状态，当 responseObject 不是 Status 类型时被赋值。 + 对于成功的请求，此字段仅包含 code 和 statusSuccess。 + 对于非 Status 类型的错误响应，此字段会被自动赋值为出错信息。 + - - + @@ -147,470 +173,502 @@ Omitted for non-resource requests. Only logged at Request Level and higher.k8s.io/apimachinery/pkg/runtime.Unknown - - + + + 请求到达 API 服务器时的时间。 + - - + + + 请求到达当前审计阶段时的时间。 + - - + + + annotations 是一个无结构的键-值映射，其中保存的是一个审计事件。 + 该事件可以由请求处理链路上的插件来设置，包括身份认证插件、鉴权插件以及 + 准入控制插件等。 + 注意这些注解是针对审计事件本身的，与所提交的对象中的 metadata.annotations + 之间不存在对应关系。 + 映射中的键名应该唯一性地标识生成该事件的组件，从而避免名字上的冲突 + （例如 podsecuritypolicy.admission.k8s.io/policy）。 + 映射中的键值应该比较简洁。 + 当审计级别为 Metadata 时会包含 annotations 字段。 + - -
FieldDescription
字段描述
apiVersion
string		audit.k8s.io/v1
kind
string		Event
level [Required]
+
level [必需]
Level 		- AuditLevel at which event was generated
auditID [Required]
+
auditID [必需]
k8s.io/apimachinery/pkg/types.UID 		- Unique audit ID, generated for each request.
stage [Required]
+
stage [必需]
Stage 		- Stage of the request handling when this event instance was generated.
requestURI [Required]
+
requestURI [必需]
string 		- RequestURI is the request URI as sent by the client to a server.
verb [Required]
+
verb [必需]
string 		- Verb is the kubernetes verb associated with the request. -For non-resource requests, this is the lower-cased HTTP method.
user [Required]
-authentication/v1.UserInfo +
user [必需]
+authentication/v1.UserInfo 		- Authenticated user information.
impersonatedUser
-authentication/v1.UserInfo +authentication/v1.UserInfo 		- Impersonated user information.
sourceIPs
[]string 		- Source IPs, from where the request originated and intermediate proxies.
userAgent
string 		- UserAgent records the user agent string reported by the client. -Note that the UserAgent is provided by the client, and must not be trusted.
objectRef
ObjectReference 		- Object reference this request is targeted at. -Does not apply for List-type requests, or non-resource requests.
responseStatus
-meta/v1.Status +meta/v1.Status 		- The response status, populated even when the ResponseObject is not a Status type. -For successful responses, this will only include the Code and StatusSuccess. -For non-status type error responses, this will be auto-populated with the error Message.
requestObject
k8s.io/apimachinery/pkg/runtime.Unknown 		- API object from the request, in JSON format. The RequestObject is recorded as-is in the request + + 来自请求的 API 对象，以 JSON 格式呈现。requestObject 在请求中按原样记录 + （可能会采用 JSON 重新编码），之后会进入版本转换、默认值填充、准入控制以及 + 配置信息合并等阶段。此对象为外部版本化的对象类型，甚至其自身可能并不是一个 + 合法的对象。对于非资源请求，此字段被忽略。 + 只有当审计级别为 Request 或更高的时候才会记录。 +
- API object returned in the response, in JSON. The ResponseObject is recorded after conversion + + 响应中包含的 API 对象，以 JSON 格式呈现。requestObject 是在被转换为外部类型 + 并序列化为 JSON 格式之后才被记录的。 + 对于非资源请求，此字段会被忽略。 + 只有审计级别为 Response 时才会记录。 +
requestReceivedTimestamp
-meta/v1.MicroTime +meta/v1.MicroTime 		- Time the request reached the apiserver.
stageTimestamp
-meta/v1.MicroTime +meta/v1.MicroTime 		- Time the request reached current audit stage.
annotations
map[string]string 		- Annotations is an unstructured key value map stored with an audit event that may be set by -plugins invoked in the request serving chain, including authentication, authorization and -admission plugins. Note that these annotations are for the audit event, and do not correspond -to the metadata.annotations of the submitted object. Keys should uniquely identify the informing -component to avoid name collisions (e.g. podsecuritypolicy.admission.k8s.io/policy). Values -should be short. Annotations are included in the Metadata level.
- - ## `EventList` {#audit-k8s-io-v1-EventList} - - - - + +EventList 是审计事件（Event）的列表。 - + - + - - - - - - - -
FieldDescription
字段描述
apiVersion
string		audit.k8s.io/v1
kind
string		EventList
metadata
-meta/v1.ListMeta +meta/v1.ListMeta 		- No description provided. + 列表结构元数据
items [Required]
+ +
items [必需]
[]Event 		- No description provided. + 事件对象列表
- - ## `Policy` {#audit-k8s-io-v1-Policy} - - - + +**出现在：** - [PolicyList](#audit-k8s-io-v1-PolicyList) - + +Policy 定义的是审计日志的配置以及不同类型请求的日志记录规则。 - + - + - - - + + 包含 metadata 字段是为了便于与 API 基础设施之间实现互操作。 + 参考 Kubernetes API 文档了解 metadata 字段的详细信息。 + - - - - - + + + 字段 omitStages 是一个阶段（Stage）列表，其中包含无须生成事件的阶段。 + 注意这一选项也可以通过每条规则来设置。 + 审计组件最终会忽略出现在 omitStages 中阶段，也会忽略规则中的阶段。 + - -
FieldDescription
字段描述
apiVersion
string		audit.k8s.io/v1
kind
string		Policy
metadata
-meta/v1.ObjectMeta +meta/v1.ObjectMeta 		- ObjectMeta is included for interoperability with API infrastructure.Refer to the Kubernetes API documentation for the fields of the metadata field.
rules [Required]
+ +
rules [必需]
[]PolicyRule 		- Rules specify the audit Level a request should be recorded at. + + 字段 rules 设置请求要被记录的审计级别（level）。 + 每个请求可能会与多条规则相匹配；发生这种状况时遵从第一条匹配规则。 + 默认的审计级别是 None，不过可以在列表的末尾使用一条全抓（catch-all）规则 + 重载其设置。 + 列表中的规则（PolicyRule）是严格有序的。 +
omitStages
[]Stage 		- OmitStages is a list of stages for which no events are created. Note that this can also -be specified per rule in which case the union of both are omitted.
- - ## `PolicyList` {#audit-k8s-io-v1-PolicyList} - - - - + +PolicyList 是由审计策略（Policy）组成的列表。 - + - - - - - - - -
FieldDescription
字段描述
apiVersion
string		audit.k8s.io/v1
kind
string		PolicyList
metadata
-meta/v1.ListMeta +meta/v1.ListMeta 		- No description provided. + 列表结构元数据。
items [Required]
+ +
items [必需]
[]Policy 		- No description provided. + 策略（Policy）对象列表。
- - ## `GroupResources` {#audit-k8s-io-v1-GroupResources} - - - + +**出现在：** - [PolicyRule](#audit-k8s-io-v1-PolicyRule) - + +GroupResources 代表的是某 API 组中的资源类别。 - + - - + + 字段 group 给出包含资源的 API 组的名称。 + 空字符串代表 core API 组。 + - - + - - + + + 字段 resourceNames 是策略将匹配的资源实例名称列表。 + 使用此字段时，resources 必须指定。 + 空的 resourceNames 列表意味着资源的所有实例都会匹配到此策略。 + - -
FieldDescription
字段描述
group
string 		- Group is the name of the API group that contains the resources. -The empty string represents the core API group.
resources
[]string 		- Resources is a list of resources this rule applies to. + + 字段 resources 是此规则所适用的资源的列表。
+ 例如：
+ 'pods' 匹配 Pods；
+ 'pods/log' 匹配 Pods 的 log 子资源；
+ '∗' 匹配所有资源及其子资源；
+ 'pods/∗' 匹配 Pods 的所有子资源；
+ '∗/scale' 匹配所有的 scale 子资源。

-If wildcard is present, the validation rule will ensure resources do not -overlap with each other. + + 如果存在通配符，则合法性检查逻辑会确保 resources 中的条目不会彼此重叠。
+ 空的列表意味着规则适用于该 API 组中的所有资源及其子资源。 +
resourceNames
[]string 		- ResourceNames is a list of resource instance names that the policy matches. -Using this field requires Resources to be specified. -An empty list implies that every instance of the resource is matched.
- - ## `Level` {#audit-k8s-io-v1-Level} - + + +string 数据类型的别名。 - + +**出现在：** - [Event](#audit-k8s-io-v1-Event) - - [PolicyRule](#audit-k8s-io-v1-PolicyRule) - + +Level 定义的是审计过程中在日志内记录的信息量。 ## `ObjectReference` {#audit-k8s-io-v1-ObjectReference} - - - + +**出现在：** - [Event](#audit-k8s-io-v1-Event) - + +ObjectReference 包含的是用来检查或修改所引用对象时将需要的全部信息。 - + - - - - + - - + - - + - - + + + 字段 apiGroup 给出包含所引用对象的 API 组的名称。 + 空字符串代表 core API 组。 + - - + + + 字段 apiVersion 是包含所引用对象的 API 组的版本。 + - - + - - + - -
FieldDescription
字段描述
resource
string 		- No description provided. + 资源类别。
namespace
string 		- No description provided. + 资源对象所在名字空间。
name
string 		- No description provided. + 资源对象名称。
uid
k8s.io/apimachinery/pkg/types.UID 		- No description provided. + 资源对象的唯一标识（UID）。
apiGroup
string 		- APIGroup is the name of the API group that contains the referred object. -The empty string represents the core API group.
apiVersion
string 		- APIVersion is the version of the API group that contains the referred object.
resourceVersion
string 		- No description provided. + 资源对象自身的版本值。
subresource
string 		- No description provided. + 子资源的类别。
- - ## `PolicyRule` {#audit-k8s-io-v1-PolicyRule} - - - + +**出现在：** - [Policy](#audit-k8s-io-v1-Policy) - + +PolicyRule 包含一个映射，基于元数据将请求映射到某审计级别。 +请求必须与每个字段所定义的规则都匹配（即 rules 的交集）才被视为匹配。 - + - - - + + 与此规则匹配的请求所对应的日志记录级别（Level）。 + - - + + + 根据身份认证所确定的用户名的列表，给出此规则所适用的用户。 + 空列表意味着适用于所有用户。 + - - + + + 此规则所适用的用户组的列表。如果用户是所列用户组中任一用户组的成员，则视为匹配。 + 空列表意味着适用于所有用户组。 + - - + + + 此规则所适用的动词（verb）列表。 + 空列表意味着适用于所有动词。 + - - + + + 此规则所适用的资源类别列表。 + 空列表意味着适用于 API 组中的所有资源类别。 + - - + + + + 此规则所适用的名字空间列表。 + 空字符串（""）意味着适用于非名字空间作用域的资源。 + 空列表意味着适用于所有名字空间。 - - + + + 字段 nonResourceURLs 给出一组需要被审计的 URL 路径。 + 允许使用 ∗，但只能作为路径中最后一个完整分段。
+ 例如：
+ "/metrics" - 记录对 API 服务器度量值（metrics）的所有请求；
+ "/healthz∗" - 记录所有健康检查请求。 + - - + + + 字段 omitStages 是一个阶段（Stage）列表，针对所列的阶段服务器不会生成审计事件。 + 注意这一选项也可以在策略（Policy）级别指定。服务器审计组件会忽略 + omitStages 中给出的阶段，也会忽略策略中给出的阶段。 + 空列表意味着不对阶段作任何限制。 + - -
FieldDescription
字段描述
level [Required]
+
level [必需]
Level 		- The Level that requests matching this rule are recorded at.
users
[]string 		- The users (by authenticated user name) this rule applies to. -An empty list implies every user.
userGroups
[]string 		- The user groups this rule applies to. A user is considered matching -if it is a member of any of the UserGroups. -An empty list implies every user group.
verbs
[]string 		- The verbs that match this rule. -An empty list implies every verb.
resources
[]GroupResources 		- Resources that this rule matches. An empty list implies all kinds in all API groups.
namespaces
[]string 		- Namespaces that this rule matches. -The empty string "" matches non-namespaced resources. -An empty list implies every namespace.
nonResourceURLs
[]string 		- NonResourceURLs is a set of URL paths that should be audited. -∗s are allowed, but only as the full, final step in the path. -Examples: - "/metrics" - Log requests for apiserver metrics - "/healthz∗" - Log all health checks
omitStages
[]Stage 		- OmitStages is a list of stages for which no events are created. Note that this can also -be specified policy wide in which case the union of both are omitted. -An empty list means no restrictions will apply.
- - ## `Stage` {#audit-k8s-io-v1-Stage} - + + +string 数据类型的别名。 - + +**出现在：** - [Event](#audit-k8s-io-v1-Event) - - [Policy](#audit-k8s-io-v1-Policy) - - [PolicyRule](#audit-k8s-io-v1-PolicyRule) - + +Stage 定义在请求处理过程中可以生成审计事件的阶段。 + diff --git a/content/zh/docs/reference/config-api/apiserver-webhookadmission.v1.md b/content/zh/docs/reference/config-api/apiserver-webhookadmission.v1.md index fb45ca7b1a..e577e497c6 100644 --- a/content/zh/docs/reference/config-api/apiserver-webhookadmission.v1.md +++ b/content/zh/docs/reference/config-api/apiserver-webhookadmission.v1.md @@ -1,46 +1,52 @@ --- -title: WebhookAdmission Configuration (v1) +title: WebhookAdmission 配置 (v1) content_type: tool-reference package: apiserver.config.k8s.io/v1 auto_generated: true --- + + + + +此 API 的版本是 v1。 +## 资源类型 {#resource-types} - [WebhookAdmission](#apiserver-config-k8s-io-v1-WebhookAdmission) - - - ## `WebhookAdmission` {#apiserver-config-k8s-io-v1-WebhookAdmission} - - - - + +WebhookAdmission 为 Webhook 准入控制器提供配置信息。 - + - - - + + 字段 kubeConfigFile 包含指向 kubeconfig 文件的路径。 + -
FieldDescription
字段描述
apiVersion
string		apiserver.config.k8s.io/v1
kind
string		WebhookAdmission
kubeConfigFile [Required]
+
kubeConfigFile [必需]
string 		- KubeConfigFile is the path to the kubeconfig file.
- - + diff --git a/content/zh/docs/reference/config-api/client-authentication.v1.md b/content/zh/docs/reference/config-api/client-authentication.v1.md new file mode 100644 index 0000000000..e3b919b9c4 --- /dev/null +++ b/content/zh/docs/reference/config-api/client-authentication.v1.md @@ -0,0 +1,280 @@ +--- +title: 客户端身份认证（Client Authentication） (v1) +content_type: tool-reference +package: client.authentication.k8s.io/v1 +auto_generated: true +--- + + + + +## 资源类型 {#resource-types} + +- [ExecCredential](#client-authentication-k8s-io-v1-ExecCredential) + +## `ExecCredential` {#client-authentication-k8s-io-v1-ExecCredential} + + +ExecCredential 由基于 exec 的插件使用，与 HTTP 传输组件沟通凭据信息。 + + + + + + + + + + + + + + + + +
字段描述
apiVersion
string		client.authentication.k8s.io/v1
kind
string		ExecCredential
spec [必需]
+ExecCredentialSpec +		 + + 字段 spec 包含由 HTTP 传输组件传递给插件的信息。 +
status
+ExecCredentialStatus +		 + + 字段 status 由插件填充，包含传输组件与 API 服务器连接时需要提供的凭据。 +
+ +## `Cluster` {#client-authentication-k8s-io-v1-Cluster} + + +**出现在：** + +- [ExecCredentialSpec](#client-authentication-k8s-io-v1-ExecCredentialSpec) + + +Cluster 中包含允许 exec 插件与 Kubernetes 集群进行通信身份认证时所需 +的信息。 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
字段描述
server [必需]
+string +		 + + 字段 server 是 Kubernetes 集群的地址（https://hostname:port）。 +
tls-server-name
+string +		 + + tls-server-name 是用来提供给服务器用作 SNI 解析的，客户端以此检查服务器的证书。 + 如此字段为空，则使用链接服务器时使用的主机名。 +
insecure-skip-tls-verify
+bool +		 + + 设置此字段之后，会令客户端跳过对服务器端证书的合法性检查。 + 这会使得你的 HTTPS 链接不再安全。 +
certificate-authority-data
+[]byte +		 + + 此字段包含 PEM 编码的证书机构（CA）证书。 + 如果为空，则使用系统的根证书。 +
proxy-url
+string +		 + + 此字段用来设置向集群发送所有请求时要使用的代理服务器。 +
config
+k8s.io/apimachinery/pkg/runtime.RawExtension +		 + +

此字段包含一些额外的、特定于 exec 插件和所连接的集群的数据，

+

此字段来自于 clientcmd 集群对象的 extensions[client.authentication.k8s.io/exec] + 字段：

+
+clusters:
+- name: my-cluster
+  cluster:
+    ...
+    extensions:
+    - name: client.authentication.k8s.io/exec  # 针对每个集群 exec 配置所预留的扩展名称
+      extension:
+        audience: 06e3fbd18de8  # 任意配置信息
+
+ + +

在某些环境中，用户配置可能对很多集群而言都完全一样（即调用同一个 exec 插件）， + 只是针对不同集群会有一些细节上的差异，例如 audience。 + 此字段使得特定于集群的配置可以直接使用集群信息来设置。 + 不建议使用此字段来保存 Secret 数据，因为 exec 插件的主要优势之一是不需要在 + kubeconfig 中保存 Secret 数据。 +

+ +## `ExecCredentialSpec` {#client-authentication-k8s-io-v1-ExecCredentialSpec} + + +**出现在：** + +- [ExecCredential](#client-authentication-k8s-io-v1-ExecCredential) + + +ExecCredentialSpec 保存传输组件所提供的特定于请求和运行时的信息。 + + + + + + + + + + + + + +
字段描述
cluster
+Cluster +		 + + 此字段中包含的信息使得 exec 插件能够与要访问的 Kubernetes 集群通信。 + 注意，cluster 字段只有在 exec 驱动的配置中 provideClusterInfo + （即：ExecConfig.ProvideClusterInfo）被设置为 true 时才不能为空。 +
interactive [必需]
+bool +		 + + 此字段用来标明标准输出信息是否已传递给 exec 插件。 +
+ +## `ExecCredentialStatus` {#client-authentication-k8s-io-v1-ExecCredentialStatus} + + + +- [ExecCredential](#client-authentication-k8s-io-v1-ExecCredential) + + +

ExecCredentialStatus 中包含传输组件要使用的凭据。

+

字段 token 和 clientKeyData 都是敏感字段。此数据只能在 +客户端与 exec 插件进程之间使用内存来传递。exec 插件本身至少 +应通过文件访问许可来实施保护。

》 + + + + + + + + + + + + + + + + + + + + +
字段描述
expirationTimestamp
+meta/v1.Time +		 + + 给出所提供的凭据到期的时间。 +
token [必需]
+string +		 + + 客户端用做请求身份认证的持有者令牌。 +
clientCertificateData [必需]
+string +		 + + PEM 编码的客户端 TLS 证书（如果有临时证书，也会包含）。 +
clientKeyData [必需]
+string +		 + + 与上述证书对应的、PEM 编码的私钥。 +
+ diff --git a/content/zh/docs/setup/production-environment/container-runtimes.md b/content/zh/docs/setup/production-environment/container-runtimes.md index 655db08c84..03380bae14 100644 --- a/content/zh/docs/setup/production-environment/container-runtimes.md +++ b/content/zh/docs/setup/production-environment/container-runtimes.md @@ -147,7 +147,7 @@ Kubernetes 仅支持使用同一 cgroup 版本来管理所有控制器。 # dnf install -y grubby && \ sudo grubby \ --update-kernel=ALL \ - --args=”systemd.unified_cgroup_hierarchy=1" + --args="systemd.unified_cgroup_hierarchy=1" ``` -## 访问集群中正在运行的服务 {#accessing-services-running-on-the-cluster} -上一节介绍了如何连接 Kubernetes API 服务。本节介绍如何连接到 Kubernetes -集群上运行的其他服务。 -在 Kubernetes 中，[节点](/zh/docs/concepts/architecture/nodes/)、 -[pods](/zh/docs/concepts/workloads/pods/) 和 -[服务](/zh/docs/concepts/services-networking/service/) 都有自己的 IP。 -在许多情况下，集群上的节点 IP、Pod IP 和某些服务 IP 将无法路由， -因此无法从集群外部的计算机（例如桌面计算机）访问它们。 +## 访问集群上运行的服务 {#accessing-services-running-on-the-cluster} - -### 连接的方法 {#ways-to-connect} - -有多种方式可以从集群外部连接节点、Pod 和服务： - -- 通过公共 IP 访问服务。 - - - 类型为 `NodePort` 或 `LoadBalancer` 的服务，集群外部可以访问。 - 请参阅 [服务](/zh/docs/concepts/services-networking/service/) 和 - [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) 文档。 - - 取决于你的集群环境，该服务可能仅暴露给你的公司网络，或者也可能暴露给 - 整个互联网。 - 请考虑公开该服务是否安全。它是否进行自己的身份验证？ - - 在服务后端放置 Pod。要从一组副本中访问一个特定的 Pod，例如进行调试， - 请在 Pod 上设置一个唯一的标签，然后创建一个选择此标签的新服务。 - - 在大多数情况下，应用程序开发人员不应该通过其 nodeIP 直接访问节点。 - - -- 使用 proxy 动词访问服务、节点或者 Pod。 - - 在访问远程服务之前进行 apiserver 身份验证和授权。 - 如果服务不能够安全地暴露到互联网，或者服务不能获得节点 IP 端口的 - 访问权限，或者是为了调试，那么请使用此选项。 - - 代理可能会给一些 web 应用带来问题。 - - 只适用于 HTTP/HTTPS。 - - 更多详细信息在[这里](#manually-constructing-apiserver-proxy-urls)。 - - -- 从集群中的节点或者 Pod 中访问。 - - - 运行一个 Pod，然后使用 [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec) - 来连接 Pod 里的 Shell。 - 然后从 Shell 中连接其它的节点、Pod 和服务。 - - 有些集群可能允许你通过 SSH 连接到节点，从那你可能可以访问集群的服务。 - 这是一个非正式的方式，可能可以运行在个别的集群上。 - 浏览器和其它一些工具可能没有被安装。集群的 DNS 可能无法使用。 - - -### 发现内建服务 - -通常来说，集群中会有 kube-system 创建的一些运行的服务。 - -通过 `kubectl cluster-info` 命令获得这些服务列表： - -```shell -kubectl cluster-info -``` - -``` -Kubernetes master is running at https://104.197.5.247 -elasticsearch-logging is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy -kibana-logging is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/kibana-logging/proxy -kube-dns is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/kube-dns/proxy -grafana is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy -heapster is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy -``` - - -这展示了访问每个服务的 proxy-verb URL。 -例如，如果集群启动了集群级别的日志（使用 Elasticsearch），并且传递合适的凭证， -那么可以通过 -`https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/` -进行访问。日志也能通过 kubectl 代理获取，例如： -`http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`。 -（参阅[使用 Kubernetes API 访问集群](/zh/docs/tasks/administer-cluster/access-cluster-api/) -了解如何传递凭据，或者使用 kubectl proxy） - -#### 手动构建 apiserver 代理 URL {#manually-constructing-apiserver-proxy-urls} - -如上所述，你可以使用 `kubectl cluster-info` 命令来获得服务的代理 URL。 -要创建包含服务端点、后缀和参数的代理 URL，需添加到服务的代理 URL： -`http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`service_name[:port_name]`*`/proxy` - -如果尚未为端口指定名称，则不必在 URL 中指定 *port_name*。 -对于已命名和未命名的端口，也可以使用端口号代替 *port_name*。 - -默认情况下，API server 使用 HTTP 代理你的服务。 -要使用 HTTPS，请在服务名称前加上 `https:`： -`http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`https:service_name:[port_name]`*`/proxy` - -URL 名称段支持的格式为： - -* `` - 使用 http 代理到默认或未命名的端口 -* `:` - 使用 http 代理到指定的端口名称或端口号 -* `https::` - 使用 https 代理到默认或未命名的端口（注意后面的冒号） -* `https::` - 使用 https 代理到指定的端口名称或端口号 - - -##### 示例 - -* 要访问 Elasticsearch 服务端点 `_search?q=user:kimchy`，你需要使用： - `http://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy` -* 要访问 Elasticsearch 集群健康信息 `_cluster/health?pretty=true`，你需要使用： - `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true` - -```json - { - "cluster_name" : "kubernetes_logging", - "status" : "yellow", - "timed_out" : false, - "number_of_nodes" : 1, - "number_of_data_nodes" : 1, - "active_primary_shards" : 5, - "active_shards" : 5, - "relocating_shards" : 0, - "initializing_shards" : 0, - "unassigned_shards" : 5 - } -``` - - -### 使用 web 浏览器访问运行在集群上的服务 - -你可以在浏览器地址栏中输入 apiserver 代理 URL。但是： - -- Web 浏览器通常不能传递令牌，因此你可能需要使用基本（密码）身份验证。 - Apiserver 可以配置为接受基本身份验证，但你的集群可能未进行配置。 -- 某些 Web 应用程序可能无法运行，尤其是那些使用客户端 javascript - 以不知道代理路径前缀的方式构建 URL 的应用程序。 本任务使用[外部负载均衡服务](/zh/docs/tasks/access-application-cluster/create-external-load-balancer/)， 所以需要对应的可支持此功能的环境。如果你的环境不能支持，你可以使用 -[NodePort](/zh/docs/concepts/services-networking/service/#nodeport) +[NodePort](/zh/docs/concepts/services-networking/service/#type-nodeport) 类型的服务代替。 diff --git a/content/zh/docs/tasks/access-application-cluster/list-all-running-container-images.md b/content/zh/docs/tasks/access-application-cluster/list-all-running-container-images.md index bf205350dd..6459875aeb 100644 --- a/content/zh/docs/tasks/access-application-cluster/list-all-running-container-images.md +++ b/content/zh/docs/tasks/access-application-cluster/list-all-running-container-images.md @@ -107,17 +107,17 @@ Pod is returned instead of a list of items. {{< /note >}} -## 列出 Pod 中的容器 +## 按 Pod 列出容器镜像 可以使用 `range` 操作进一步控制格式化，以单独操作每个元素。 ```shell -kubectl get pods --all-namespaces -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\ +kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\ sort ``` @@ -132,7 +132,7 @@ following matches only Pods with labels matching `app=nginx`. 要获取匹配特定标签的 Pod，请使用 -l 参数。以下匹配仅与标签 `app=nginx` 相符的 Pod。 ```shell -kubectl get pods --all-namespaces -o=jsonpath="{.items[*].spec.containers[*].image}" -l app=nginx +kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" -l app=nginx ``` 你现在可以关闭连接到节点的 Shell。 + + +## 在两个地方挂载相同的 persistentVolume + +{{< codenew file="pods/storage/pv-duplicate.yaml" >}} + + +你可以在 nginx 容器上执行两个卷挂载: + +`/usr/share/nginx/html` 用于静态网站 +`/etc/nginx/nginx.conf` 作为默认配置 + * 进一步了解[`projected`](/zh/docs/concepts/storage/volumes/#projected) 卷。 -* 阅读[一体卷](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/node/all-in-one-volume.md)设计文档。 +* 阅读[一体卷](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/all-in-one-volume.md)设计文档。 diff --git a/content/zh/docs/tasks/configure-pod-container/configure-service-account.md b/content/zh/docs/tasks/configure-pod-container/configure-service-account.md index e7bba36668..46d1c46202 100644 --- a/content/zh/docs/tasks/configure-pod-container/configure-service-account.md +++ b/content/zh/docs/tasks/configure-pod-container/configure-service-account.md @@ -423,7 +423,7 @@ command line arguments to `kube-apiserver`: * `--service-account-issuer` * `--service-account-key-file` * `--service-account-signing-key-file` -* `--api-audiences` +* `--api-audiences` (can be omitted) --> {{< note >}} @@ -432,7 +432,7 @@ command line arguments to `kube-apiserver`: * `--service-account-issuer` * `--service-account-key-file` * `--service-account-signing-key-file` -* `--api-audiences` +* `--api-audiences`（可以省略） {{< /note >}} diff --git a/content/zh/docs/tasks/configure-pod-container/pull-image-private-registry.md b/content/zh/docs/tasks/configure-pod-container/pull-image-private-registry.md index c3b896ec35..c29009533f 100644 --- a/content/zh/docs/tasks/configure-pod-container/pull-image-private-registry.md +++ b/content/zh/docs/tasks/configure-pod-container/pull-image-private-registry.md @@ -13,20 +13,26 @@ weight: 100 -本文介绍如何使用 Secret 从私有的 Docker 镜像仓库或代码仓库拉取镜像来创建 Pod。 +本文介绍如何使用 {{< glossary_tooltip text="Secret" term_id="secret" >}} +从私有的镜像仓库或代码仓库拉取镜像来创建 Pod。 + +{{% thirdparty-content single="true" %}} ## {{% heading "prerequisites" %}} -* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} +* {{< include "task-tutorial-prereqs.md" >}} -你需要 [Docker ID](https://docs.docker.com/docker-id/) 和密码来进行本练习。 + +要进行此练习，你需要 `docker` 命令行工具和一个知道密码的 +[Docker ID](https://docs.docker.com/docker-id/)。 @@ -44,15 +50,18 @@ docker login ``` -当出现提示时，输入 Docker 用户名和密码。 +当出现提示时，输入您的 Docker ID 和登录凭证（访问令牌、 +或 Docker ID 的密码）。 登录过程会创建或更新保存有授权令牌的 `config.json` 文件。 +查看 [Kubernetes 中如何解析这个文件](/zh/docs/concepts/containers/images#config-json)。 查看 `config.json` 文件： @@ -125,7 +134,7 @@ You have successfully set your Docker credentials in the cluster as a Secret cal * `` 是你的 Docker 密码。 * `` 是你的 Docker 邮箱。 -这样你就成功地将集群中的 Docker 凭据设置为名为 `regcred` 的 Secret。 +这样你就成功地将集群中的 Docker 凭证设置为名为 `regcred` 的 Secret。 -`.dockerconfigjson` 字段的值是 Docker 凭据的 base64 表示。 +`.dockerconfigjson` 字段的值是 Docker 凭证的 base64 表示。 要了解 `dockerconfigjson` 字段中的内容，请将 Secret 数据转换为可读格式： @@ -201,24 +210,27 @@ You have successfully set your Docker credentials as a Secret called `regcred` i --> 注意，Secret 数据包含与本地 `~/.docker/config.json` 文件类似的授权令牌。 -这样你就已经成功地将 Docker 凭据设置为集群中的名为 `regcred` 的 Secret。 +这样你就已经成功地将 Docker 凭证设置为集群中的名为 `regcred` 的 Secret。 ## 创建一个使用你的 Secret 的 Pod -下面是一个 Pod 配置文件，它需要访问 `regcred` 中的 Docker 凭据： +下面是一个 Pod 配置清单示例，该示例中 Pod 需要访问你的 Docker 凭证 `regcred`： {{< codenew file="pods/private-reg-pod.yaml" >}} - -下载上述文件： + + +将上述文件下载到你的计算机中： ```shell -wget -O my-private-reg-pod.yaml https://k8s.io/examples/pods/private-reg-pod.yaml +curl -L -O my-private-reg-pod.yaml https://k8s.io/examples/pods/private-reg-pod.yaml ``` -* 进一步了解 [Secret](/zh/docs/concepts/configuration/secret/) +* 进一步了解 [Secrets](/zh/docs/concepts/configuration/secret/) + * 或阅读 {{< api-reference page="config-and-storage-resources/secret-v1" >}} 的 API 参考 * 进一步了解 [使用私有仓库](/zh/docs/concepts/containers/images/#using-a-private-registry) -* 参考 [kubectl create secret docker-registry](/docs/reference/generated/kubectl/kubectl-commands/#-em-secret-docker-registry-em-) -* 参考 [Secret](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core) -* 参考 [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) 中的 `imagePullSecrets` 字段 - - +* 进一步了解 [为服务账户添加拉取镜像凭证](/zh/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) +* 查看 [kubectl 创建 docker-registry 凭证](/docs/reference/generated/kubectl/kubectl-commands/#-em-secret-docker-registry-em-) +* 查看 Pod [容器定义](/docs/reference/kubernetes-api/workload-resources/pod-v1/#containers)中的 `imagePullSecrets` 字段。 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 f05e678392..424985b678 100644 --- a/content/zh/docs/tasks/configure-pod-container/security-context.md +++ b/content/zh/docs/tasks/configure-pod-container/security-context.md @@ -240,7 +240,7 @@ exit --> ## 为 Pod 配置卷访问权限和属主变更策略 -{{< feature-state for_k8s_version="v1.20" state="beta" >}} +{{< feature-state for_k8s_version="v1.23" state="stable" >}} ## 将卷权限和所有权更改委派给 CSI 驱动程序 -{{< feature-state for_k8s_version="v1.22" state="alpha" >}} +{{< feature-state for_k8s_version="v1.23" state="beta" >}} + +{{< note >}} +静态 Pod 的 `spec` 不能引用其他 API 对象 +（如：{{< glossary_tooltip text="ServiceAccount" term_id="service-account" >}}、 +{{< glossary_tooltip text="ConfigMap" term_id="configmap" >}}、 +{{< glossary_tooltip text="Secret" term_id="secret" >}} 等）。 +{{< /note >}} + ## {{% heading "prerequisites" %}} {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} diff --git a/content/zh/docs/tasks/tools/install-kubectl-linux.md b/content/zh/docs/tasks/tools/install-kubectl-linux.md index 6f9457297b..2bd64b6315 100644 --- a/content/zh/docs/tasks/tools/install-kubectl-linux.md +++ b/content/zh/docs/tasks/tools/install-kubectl-linux.md @@ -165,49 +165,49 @@ The following methods exist for installing kubectl on Linux: ### 用原生包管理工具安装 {#install-using-native-package-management} {{< tabs name="kubectl_install" >}} -{{< tab name="Ubuntu、Debian 或 HypriotOS" codelang="bash" >}} +{{% tab name="Ubuntu、Debian 或 HypriotOS" %}} - -1. 更新 `apt` 包索引，并安装使用 Kubernetes `apt` 仓库锁需要的包： + + 1. 更新 `apt` 包索引，并安装使用 Kubernetes `apt` 仓库所需要的包： - ```shell - sudo apt-get update - sudo apt-get install -y apt-transport-https ca-certificates curl - ``` + ```shell + sudo apt-get update + sudo apt-get install -y apt-transport-https ca-certificates curl + ``` + + 2. 下载 Google Cloud 公开签名秘钥： - -2. 下载 Google Cloud 公开签名秘钥： + ```shell + sudo curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg + ``` - ```shell - sudo curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg - ``` + + 3. 添加 Kubernetes `apt` 仓库： - -3. 添加 Kubernetes `apt` 仓库： + ```shell + echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list + ``` - ```shell - echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list - ``` + + 4. 更新 `apt` 包索引，使之包含新的仓库并安装 kubectl： - -4. 更新 `apt` 包索引，使之包含新的仓库并安装 kubectl： + ```shell + sudo apt-get update + sudo apt-get install -y kubectl + ``` +{{% /tab %}} - ```shell - sudo apt-get update - sudo apt-get install -y kubectl - ``` +{{% tab name="基于 Red Hat 的发行版" %}} -{{< /tab >}} - -{{< tab name="基于 Red Hat 的发行版" codelang="bash" >}} +```shell cat <}} +``` + +{{% /tab %}} {{< /tabs >}} -## 基础知识 +## 基础知识 {#basics} * [Kubernetes 基础知识](/zh/docs/tutorials/Kubernetes-Basics/)是一个深入的 交互式教程，帮助您理解 Kubernetes 系统，并尝试一些基本的 Kubernetes 特性。 @@ -55,7 +55,7 @@ Kubernetes 文档的这一部分包含教程。每个教程展示了如何完成 * [Configuring Redis Using a ConfigMap](/docs/tutorials/configuration/configure-redis-using-configmap/) --> -## 配置 +## 配置 {#configuration} * [示例：配置 Java 微服务](/zh/docs/tutorials/configuration/configure-java-microservice/) @@ -68,7 +68,7 @@ Kubernetes 文档的这一部分包含教程。每个教程展示了如何完成 * [Example: Deploying PHP Guestbook application with MongoDB](/docs/tutorials/stateless-application/guestbook/) --> -## 无状态应用程序 +## 无状态应用程序 {#stateless-applications} * [公开外部 IP 地址访问集群中的应用程序](/zh/docs/tutorials/stateless-application/expose-external-ip-address/) @@ -86,7 +86,7 @@ Kubernetes 文档的这一部分包含教程。每个教程展示了如何完成 * [Running ZooKeeper, A CP Distributed System](/docs/tutorials/stateful-application/zookeeper/) --> -## 有状态应用程序 +## 有状态应用程序 {#stateful-applications} * [StatefulSet 基础](/zh/docs/tutorials/stateful-application/basic-stateful-set/) @@ -99,9 +99,13 @@ Kubernetes 文档的这一部分包含教程。每个教程展示了如何完成 -## 集群 +## 集群 {#clusters} + +* [AppArmor](/zh/docs/tutorials/clusters/apparmor/) * [seccomp](/zh/docs/tutorials/clusters/seccomp/) @@ -110,10 +114,21 @@ Kubernetes 文档的这一部分包含教程。每个教程展示了如何完成 * [Using Source IP](/docs/tutorials/services/source-ip/) --> -## 服务 +## 服务 {#services} * [使用源 IP](/zh/docs/tutorials/services/source-ip/) + +## 安全 {#security} + +* [在集群级别应用 Pod 安全标准](/zh/docs/tutorials/security/cluster-level-pss/) +* [在名字空间级别应用 Pod 安全标准](/zh/docs/tutorials/security/ns-level-pss/) + ## {{% heading "whatsnext" %}}