Question: <ins> --- title: Istio id: istio date: 2018-04-12 full_link: https://istio.io/docs/concepts/what-is-istio/ short_description: > एक ओपन प्लैटफ़ॉर्म (कुबेरनेट्स-विशिष्ट नहीं) जो माइक्रोसर्विसेज को एकीकृत करने, ट्रैफ़िक प्रवाह को प्रबंधित करने, नीतियों को लागू करने और टेलीमेट्री डेटा को एकत्र करने का एक समान तरीका प्रदान करता हैं। aka: tags: - networking - architecture - extension --- एक ओपन प्लैटफ़ॉर्म (कुबेरनेट्स-विशिष्ट नहीं) जो माइक्रोसर्विसेज को एकीकृत करने, ट्रैफ़िक प्रवाह को प्रबंधित करने, नीतियों को लागू करने और टेलीमेट्री डेटा को एकत्र करने का एक समान तरीका प्रदान करता हैं। <!--more--> Istio को जोड़ने के लिए एप्लिकेशन कोड बदलने की आवश्यकता नहीं है। यह एक सर्विस और नेटवर्क के बीच बुनियादी ढांचे की एक परत है, जिसे जब सर्विस डिप्लॉयमेंट के साथ जोड़ा जाता है, तो इसे आमतौर पर सर्विस मैश (Service Mesh) के रूप में भी जाना जाता है। Istio का कंट्रोल प्लेन अंतर्निहित क्लस्टर प्रबंधन प्लैटफ़ॉर्म को अलग कर देता है, जो कुबेरनेट्स, Mesosphere आदि हो सकते हैं। </ins>

If this is your first contribution, visit for information on how to get started. Review a few to see which content you have to change and which you leave unchanged. Make sure your base, target branch is and create a working branch called . Create a file called Copy the content of to the file you created Localize the content. Push your change and create a pull request. Completing this feature issue fixes part of /language hi /triage accepted
/assign


Question: - `kubectl edit cm kubelet-config-x.yy -n kube-system`を呼び出します(`x.yy`はKubernetesのバージョンに置き換えてください)。 - 既存の`cgroupDriver`の値を修正するか、以下のような新しいフィールドを追加します。 <del> ``yaml </del> <ins> ```yaml </ins> cgroupDriver: systemd ```

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: The code block is not being processed correctly, resulting in the page rendering in an unexpected way. <img width="625" alt="Screenshot 2023-12-06 at 16 52 11" src=""Proposed Solution: fix L84 (to yaml) Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/language ja /assign
/area localization


Question: * [Scheduler Policies](/docs/reference/scheduling/policies) * [Scheduler Profiles](/docs/reference/scheduling/config#profiles) <ins> * List of [ports and protocols](/docs/reference/ports-and-protocols/) that should be open on control plane and worker nodes </ins> ## Config APIs This section hosts the documentation for "unpublished" APIs which are used to

What would you like to be Create a dedicated ports and protocols page for Kubernetes Clusters. Why is this needed Currently, the closest page that provides this information is under KubeAdm install setup . This is hard to find for any cluster administrator trying to deploy Kubernetes Documented Ports for and are incorrect and need an update Slack thread: /sig security node docs architecture /area security
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : What would you like to be Create a dedicated ports and protocols page for Kubernetes Clusters. Currently, the closest page that provides this information is under KubeAdm install setup . This is hard to find for any cluster administrator trying to deploy Kubernetes Documented Ports for and are incorrect and need an update /area security Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/triage accepted
Hi Would you be OK to have this as a reference page, rather than as a concept?
/sig network
/sig cluster-lifecycle Given the PR touches kubeadm docs.
Moved it under . This was the kind of feedback I was looking for from SIG Docs. Thank you


Question: You should now be able to curl the nginx Service on `<CLUSTER-IP>:<PORT>` from any node in your cluster. Note that the Service IP is completely virtual, it never hits the wire. If you're curious about how this works you can read more <del> about the [service proxy](/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies). </del> <ins> about the [service proxy](/docs/reference/networking/virtual-ips/). </ins> ## Accessing the Service

This is a Bug Report <!--Required Information--Problem: The under the in redirects to the following link: i.e. concept page in which there is nothing about Service Proxy. It is due to the revision of the Service concept page by the following PR: Proposed Solution: service proxy should redirect to instead of Page to Update:
/sig network /sig docs
I am working on the issue and will raise a PR soon. Thanks /assign
/triage accepted /priority backlog
Fixed it here:


Question: With one of those specification, both an integer and a string validate. <del> In [Validation Schema Publishing](#publish-validation-schema-in-openapi-v2), </del> <ins> In [Validation Schema Publishing](#publish-validation-schema-in-openapi), </ins> `x-kubernetes-int-or-string: true` is unfolded to one of the two patterns shown above. ### RawExtension

This is a Bug Report Problem: The hyperlinks for OpenAPI validation schemas are also published and Validation Schema Publishing under the task page is not working. They both redirect to which is incorrect, the correct one is Proposed Solution: OpenAPI validation schemas are also published and Validation Schema Publishing should redirect to instead of Page to Update:
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign
/sig api-machinery /language en /sig docs
Fixed the issue here:


Question: <ins> --- layout: blog title: "Gateway API v1.1: サービスメッシュ、GRPCRoute、そして更なる進化" date: 2024-05-09T09:00:00-08:00 slug: gateway-api-v1-1 author: > [Richard Belleville](https://github.com/gnossen) (Google), [Frank Budinsky](https://github.com/frankbu) (IBM), [Arko Dasgupta](https://github.com/arkodg) (Tetrate), [Flynn](https://github.com/kflynn) (Buoyant), [Candace Holman](https://github.com/candita) (Red Hat), [John Howard](https://github.com/howardjohn) (Solo.io), [Christine Kim](https://github.com/xtineskim) (Isovalent), [Mattia Lavacca](https://github.com/mlavacca) (Kong), [Keith Mattix](https://github.com/keithmattix) (Microsoft), [Mike Morris](https://github.com/mikemorris) (Microsoft), [Rob Scott](https://github.com/robscott) (Google), [Grant Spence](https://github.com/gcs278) (Red Hat), [Shane Utt](https://github.com/shaneutt) (Kong), [Gina Yeh](https://github.com/ginayeh) (Google), and other review and release note contributors translator: > [Taisuke Okamoto](https://github.com/b1gb4by) ([IDC Frontier Inc.](https://www.idcf.jp/)), [Daiki Hayakawa(bells17)](https://github.com/bells17) ([3-shake Inc.](https://3-shake.com/en/)), [Junya Okabe](https://github.com/Okabe-Junya) (University of Tsukuba) --- ![Gateway API logo](gateway-api-logo.svg) 昨年10月のGateway APIの正式リリース後、Kubernetes SIG Networkは[Gateway API](https://gateway-api.sigs.k8s.io/)のv1.1リリースを発表しました。 このリリースでは、いくつかの機能が _標準機能_ (GA)に昇格しています。 特にサービスメッシュとGRPCRouteのサポートが含まれます。 また、セッション維持とクライアント証明書の検証を含む新しい実験的機能も導入しています。 ## 新機能 ### GAへの昇格 このリリースでは、4つの待望の機能が標準機能に昇格しました。 これにより、これらの機能は実験的な段階を卒業したことになります。 GAへの昇格が行われたということは、APIの設計に対する高い信頼性を示すとともに、後方互換性を保証するものです。 他のKubernetes APIと同様に、GAへ昇格した機能も時間とともに後方互換性を保ちながら進化していきます。 今後もこれらの新機能のさらなる改良と改善が行われることを期待しています。 これらの仕組みについて詳しくは、Gateway APIの[バージョニングポリシー](https://gateway-api.sigs.k8s.io/concepts/versioning/)をご覧ください。 #### [サービスメッシュのサポート](https://gateway-api.sigs.k8s.io/mesh/) Gateway APIのサービスメッシュサポートにより、サービスメッシュユーザーは同じAPIを使用してIngressトラフィックとメッシュトラフィックを管理することが可能になります。 これにより同じポリシーとルーティングインターフェースを再利用することができます。 また、Gateway API v1.1では、HTTPRouteなどのルートがServiceを`parentRef`として持つことができるようになり、特定のサービスへのトラフィックの動作を制御できます。 詳細については、[Gateway APIのサービスメッシュドキュメント](https://gateway-api.sigs.k8s.io/mesh/)をお読みいただくか、[Gateway APIの実装リスト](https://gateway-api.sigs.k8s.io/implementations/#service-mesh-implementation-status)をご覧ください。 例えば、アプリケーションのコールグラフの深部にあるワークロードに対して、HTTPRouteを使用してカナリアデプロイメントを行うことができます。 以下はその例です： ```yaml apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: color-canary namespace: faces spec: parentRefs: - name: color kind: Service group: "" port: 80 rules: - backendRefs: - name: color port: 80 weight: 50 - name: color2 port: 80 weight: 50 ``` これにより、名前空間`faces`内の`color`サービスに送信されるトラフィックが、元の`color`サービスと`color2`サービスの間で50対50に分割されます。 この設定は移植性が高く、あるメッシュから別のメッシュへ簡単に移行できます。 #### [GRPCRoute](https://gateway-api.sigs.k8s.io/guides/grpc-routing/) すでにGRPCRouteの実験的機能バージョンを使用している場合、使用しているコントローラーがGRPCRoute v1をサポートするようアップデートされるまで、標準バージョンのGRPCRouteへのアップグレードは控えることをお勧めします。 それまでは、`v1alpha2`と`v1`の両方のAPIバージョンを含むv1.1の実験的チャンネルバージョンのGRPCRouteにアップグレードしても問題ありません。 #### [ParentReference Port](https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io%2fv1.ParentReference) ParentReferenceにportフィールドが追加されました。 これにより、リソースをGatewayのリスナー、Service、あるいは他の親リソース(実装によって異なります)に関連付けることができるようになりました。 ポートにバインドすることで、複数のリスナーに一度に関連付けることも可能です。 例えば、HTTPRouteをGatewayの特定のリスナーに関連付ける際、リスナー名ではなくリスナーのポートを指定できるようになりました。 これにより、一つまたは複数の特定のリスナーに関連付けることができます。 詳細については、[Gatewayへの関連付け](https://gateway-api.sigs.k8s.io/api-types/httproute/#attaching-to-gateways)を参照してください。 #### [適合性プロファイルとレポート](https://gateway-api.sigs.k8s.io/concepts/conformance/#conformance-profiles) 適合性レポートのAPIが拡張され、実装の動作モードを指定する`mode`フィールドと、Gateway APIのチャネル(標準版または実験的機能版)をしめす`gatewayAPIChannel`が追加されました。 `gatewayAPIVersion`と`gatewayAPIChannel`は、テスト結果の簡単な説明とともに、テストスイートの仕組みによって自動的に入力されるようになりました。 レポートの構成がより体系的に整理され、実装者はテストの実行方法に関する情報を追加し、再現手順を提供できるようになりました。 ### 実験的機能版チャンネルへの新機能追加 #### [Gatewayのクライアント証明書の検証](https://gateway-api.sigs.k8s.io/geps/gep-91/) Gatewayの各リスナーでクライアント証明書の検証が設定できるようになりました。 これは、`tls`内に新しく追加された`frontendValidation`フィールドによって実現されています。 このフィールドでは、クライアントが提示する証明書を検証するための信頼アンカーとして使用できるCA証明書のリストを設定できます。 以下の例は、ConfigMapの`foo-example-com-ca-cert`に保存されているCA証明書を使用して、Gatewayリスナーの`foo-https`に接続するクライアントの証明書を検証する方法を示しています。 ```yaml apiVersion: gateway.networking.k8s.io/v1 kind: Gateway metadata: name: client-validation-basic spec: gatewayClassName: acme-lb listeners: name: foo-https protocol: HTTPS port: 443 hostname: foo.example.com tls: certificateRefs: kind: Secret group: "" name: foo-example-com-cert frontendValidation: caCertificateRefs: kind: ConfigMap group: "" name: foo-example-com-ca-cert ``` #### [セッション維持とBackendLBPolicy](https://gateway-api.sigs.k8s.io/geps/gep-1619/) Gateway APIに[セッション維持機能](https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io%2fv1.SessionPersistence)が導入されました。 これは新しいポリシー([BackendLBPolicy](https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1alpha2.BackendLBPolicy))によってサービスレベルで設定でき、さらにHTTPRouteとGRPCRoute内のフィールドを使用してルートレベルでも設定可能です。 BackendLBPolicyとルートレベルのAPIは、セッションのタイムアウト、セッション名、セッションタイプ、クッキーの有効期間タイプなど、同じセッション維持の設定を提供します。 以下は、`foo`サービスにクッキーベースのセッション維持を有効にする`BackendLBPolicy`の設定例です。 セッション名を`foo-session`に設定し、絶対タイムアウトとアイドルタイムアウトを定義し、クッキーをセッションクッキーとして設定しています： ```yaml apiVersion: gateway.networking.k8s.io/v1alpha2 kind: BackendLBPolicy metadata: name: lb-policy namespace: foo-ns spec: targetRefs: - group: core kind: service name: foo sessionPersistence: sessionName: foo-session absoluteTimeout: 1h idleTimeout: 30m type: Cookie cookieConfig: lifetimeType: Session ``` ### その他の変更点 #### [TLS関連用語の明確化](https://gateway-api.sigs.k8s.io/geps/gep-2907/) API全体でTLS関連の用語を統一する取り組みの一環として、BackendTLSPolicyに互換性のない変更を加えました。 これにより、新しいAPIバージョン(v1alpha3)が導入されました。 既存のv1alpha2を使用している場合は、データのバックアップや古いバージョンのアンインストールなど、適切な対応が必要です。 v1alpha2のBackendTLSPolicyフィールドへの参照は、v1alpha3に更新する必要があります。 主な変更点は以下の通りです： - `targetRef`が`targetRefs`に変更(複数のターゲットへの適用が可能に) - `tls`が`validation`に変更 - `tls.caCertRefs`が`validation.caCertificateRefs`に変更 - `tls.wellKnownCACerts`が`validation.wellKnownCACertificates`に変更 このリリースに含まれるすべての変更点については、[v1.1.0リリースノート](https://github.com/kubernetes-sigs/gateway-api/releases/tag/v1.1.0)をご覧ください。 ## Gateway APIの背景 Gateway APIのアイデアは、2019年のKubeCon San Diegoで次世代のIngress APIとして[最初に提案](https://youtu.be/Ne9UJL6irXY?si=wgtC9w8PMB5ZHil2)されました。 それ以来、すばらしいコミュニティが形成され、おそらく[Kubernetes史上最も協力的なAPI](https://www.youtube.com/watch?v=V3Vu_FWb4l4)を開発してきました。 これまでに200人以上がこのAPIに貢献しており、その数は今も増え続けています。 メンテナーは、リポジトリへのコミット、議論、アイデア、あるいは一般的なサポートなど、あらゆる形でGateway APIに貢献してくださった _全ての方々_ に感謝の意を表します。 このように献身的で活発なコミュニティのサポートなしでは、ここまで到達することはできませんでした。 ## 実際に使ってみましょう Gateway APIの特徴として、最新版を使用するためにKubernetesそのものを最新にする必要がありません。 Kubernetes 1.26以降であれば、このバージョンのGateway APIをすぐに利用開始できます。 APIを試すには、[スタートガイド](https://gateway-api.sigs.k8s.io/guides/)をご覧ください。 ## 開発に参加しませんか Ingressやサービスメッシュ向けのKubernetesルーティングAPIの未来を形作るチャンスがたくさんあります。 - [ユーザーガイド](https://gateway-api.sigs.k8s.io/guides)で、対応可能なユースケースをチェックしてみてください。 - [既存のGatewayコントローラー](https://gateway-api.sigs.k8s.io/implementations/)を実際に試してみるのもおすすめです。 - さらに、[コミュニティへの参加](https://gateway-api.sigs.k8s.io/contributing/)もお待ちしています。一緒にGateway APIの未来を築いていきましょう！ ## 関連するKubernetesブログ記事 - [New Experimental Features in Gateway API v1.0](/blog/2023/11/28/gateway-api-ga/) 11/2023 - [Gateway API v1.0: GA Release](/blog/2023/10/31/gateway-api-ga/) 10/2023 - [Introducing ingress2gateway; Simplifying Upgrades to Gateway API](/blog/2023/10/25/introducing-ingress2gateway/) 10/2023 - [Gateway API v0.8.0: Introducing Service Mesh Support](/blog/2023/08/29/gateway-api-v0-8/) 08/2023 </ins>

This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --- Translate "" What would you like to be <!-- Describe as precisely as possible how this feature/enhancement should work from the user perspective. What should be changed, etc. --Why is this needed There is no Japanese translation for this page Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/area localization /language ja /assign
Thanks! /triage accepted


Question: A cluster consists of a master API server and a set of worker VMs called nodes. <del> Create a cluster via the Console: *Compute > Container Engine > Container Clusters > New container cluster*. Leave all the options default, and you should get a Kubernetes cluster with three nodes, ready to receive your container image. </del> <ins> Create a cluster via the Console: *Compute > Container Engine > Container Clusters > New container cluster*. Set the name to 'hello-world', leaving all other options default.  You should get a Kubernetes cluster with three nodes, ready to receive your container image. </ins> ![image](/images/hellonode/image_11.png)

When creating your cluster: "Leave all the options default, and you should get a Kubernetes cluster with three nodes, ready to receive your container image." ..should read: "Set the name to 'hello-world', leaving all other options default. You should get a Kubernetes cluster with three nodes, ready to receive your container image."
PR submitted:
cc
should be closed now


Question: - Fetch all Pods in all namespaces using `kubectl get pods --all-namespaces` - Format the output to include only the list of Container image names <del> using `-o jsonpath={..image}`.  This will recursively parse out the </del> <ins> using `-o jsonpath={.items[*].spec.containers[*].image}`.  This will recursively parse out the </ins> `image` field from the returned json. - See the [jsonpath reference](/docs/reference/kubectl/jsonpath/) for further information on how to use jsonpath.

Hi, I've tested this example : It returns image names double, because "{..image}" recursively search in the output of JSON, So at the first, it will find the "image" word in "" and at the second time, it will find the "image" word in "". It means you will see the image name two times for each pod at least. Please change your example. Best Regards, Alireza Bahmani.
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Hi What's the URL of the page where you've seen a problem?
here are the links to the: kubernetes docs website page ~ markdown file(s) where it require changes ~
The issue is, the following command produces 2 times (the count of image in a single pod). As mentioned, it is because the command count both the occurrence from the & sections from a single pod json manifest. Ideally it should be:
Following could be one of the fix for it:
/assign
There are other references . These would return duplicate images as well, right? I've updated those as well for now.
Hi yes, I feel those also need to be fixed. Let's wait for to provide their review. :)


Question: ### Authorization <del> [Authorization](/docs/reference/access-authn-authz/webhook/) determines whether specific users can read, write, and do other operations on API resources. It works at the level of whole resources -- it doesn't discriminate based on arbitrary object fields. If the built-in authorization options don't meet your needs, and [Authorization webhook](/docs/reference/access-authn-authz/webhook/) allows calling out to user-provided code to make an authorization decision. </del> <ins> [Authorization](/docs/reference/access-authn-authz/authorization/) determines whether specific users can read, write, and do other operations on API resources. It works at the level of whole resources -- it doesn't discriminate based on arbitrary object fields. If the built-in authorization options don't meet your needs, [Authorization webhook](/docs/reference/access-authn-authz/webhook/) allows calling out to user-provided code to make an authorization decision. </ins> ### Dynamic Admission Control

This is a Bug Report Problem: The link for Authorization under in is wrong. It is redirected to the which is wrong, It should redirect to Proposed Solution: We will have to use this link: for Authorization instead of . Page to Update:
/assign
Fixed it here:
Hey Do check on issue triage for this! Thank you.
/triage accepted
/language en


Question: #### Metadatos de los Objectos <del> * [Annotations](/docs/concepts/overview/working-with-objects/annotations/) </del> <ins> * [Annotations](/es/docs/concepts/overview/working-with-objects/annotations/) </ins> ## {{% heading "whatsnext" %}} <del> Si estás interesado en escribir una página sobre conceptos, revisa [Usando Templates de Páginas](/docs/home/contribute/page-templates/) para obtener información sobre el tipo de página conceptos y la plantilla conceptos. </del> <ins> Si quieres empezar a contribuir a la documentación de Kubernetes accede a la página [Empieza a contribuir](/es/docs/contribute/start/). </ins>

This is a Bug Report concepts page for spanish links doesn't take to spanish pages <!--Required Information--Problem: The page is the Spanish translation, the links on this page should take you to the Spanish version of the link when available, if not available then ok to leave it pointing to English Proposed Solution: Update the page links to point to Spanish version (ie. es) Page to Update: I intended to review and submit a PR
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/language es
/assign
/assign
Thanks for the report, this is quite common as the translation is a work in progress and we don't have (yet) a way to easily detect where a page is referenced. Let me know if you have any issue working with the PR.
I will work on this page as one-off, and think about how can we automate the detection for all links that should point to the Spanish version.
Maybe something that can be done at build time? Don't know how is the site is build I guess Hugo but not how much pre-processing is done


Question: The response to a successful request is a hello message: <del> Hello Kubernetes! </del> <ins> ```shell Hello Kubernetes! ``` </ins> ## {{% heading "cleanup" %}} To delete the Service, enter this command: <del> kubectl delete services my-service </del> <ins> ```shell kubectl delete services my-service ``` </ins> To delete the Deployment, the ReplicaSet, and the Pods that are running the Hello World application, enter this command: <del> kubectl delete deployment hello-world </del> <ins> ```shell kubectl delete deployment hello-world ``` </ins> ## {{% heading "whatsnext" %}} Learn more about [connecting applications with services](/docs/concepts/services-networking/connect-applications-service/).

This is a Bug Report There are some commands in the tutorial that are missing code formatting. This is a request to update those commands and remove any extra lines in the page. <!--Required Information--Problem: The tutorial has commands that are not formatted as code. For example, kubectl get deployments hello-world Add code formatting: Proposed Solution: Identify the commands that are missing code formatting. Add the code formatting to the commands. Clean up any extra lines in the page. Page to Update: This is a good issue for a first time contributor. If you need more information, feel free to ask in this issue. It is a good idea to build your changes locally.
/good-first-issue
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /good-first-issue Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/triage accepted /language en Thanks - another good spot
Is this PR currently being worked on?
it seems already formatted, right?
I don't see any issues with the page as well, and it looks like it was last modified July 27, 2020 at 4:18. Are we missing something?
Let me look. I'd like a first time contributor to work on this issue.
The page renders correctly, however, it would be helpful to clean up the formatting of the page such as extra lines and spaces. Also, the page should use code blocks around any commands (instead of indentation). Let me know if you need more information. Thanks!
i'm a first timer in kubernetes. But i saw nothing wrong in formatting code nor indentation. Only i think there is missing some instruction in creating apps. Should be better to follow Just my 2cent. wdyt?
/assign


Question: #### Network traffic is not forwarded <del> Please see [debugging service](/docs/tasks/debug/debug-applications/debug-service/) for more information. </del> <ins> Please see [debugging service](/docs/tasks/debug/debug-application/debug-service/) for more information. </ins> ## {{% heading "whatsnext" %}} If none of the above solves your problem, follow the instructions in <del> [Debugging Service document](/docs/tasks/debug/debug-applications/debug-service/) </del> <ins> [Debugging Service document](/docs/tasks/debug/debug-application/debug-service/) </ins> to make sure that your `Service` is running, has `Endpoints`, and your `Pods` are actually serving; you have DNS working, iptables rules installed, and kube-proxy does not seem to be misbehaving.

Links to "Debugging Service" documents are not working. It is currently linking to when it should be
/triage accepted


Question: For more details please see the [Network Plugin Requirements](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#network-plugin-requirements) page. ## Check required ports <del> ### Control-plane node(s) | Protocol | Direction | Port Range | Purpose                 | Used By                   | |----------|-----------|------------|-------------------------|---------------------------| | TCP      | Inbound   | 6443*      | Kubernetes API server   | All                       | | TCP      | Inbound   | 2379-2380  | etcd server client API  | kube-apiserver, etcd      | | TCP      | Inbound   | 10250      | kubelet API             | Self, Control plane       | | TCP      | Inbound   | 10251      | kube-scheduler          | Self                      | | TCP      | Inbound   | 10252      | kube-controller-manager | Self                      | ### Worker node(s) | Protocol | Direction | Port Range  | Purpose               | Used By                 | |----------|-----------|-------------|-----------------------|-------------------------| | TCP      | Inbound   | 10250       | kubelet API           | Self, Control plane     | | TCP      | Inbound   | 30000-32767 | NodePort Services†    | All                     | † Default port range for [NodePort Services](/docs/concepts/services-networking/service/). Any port numbers marked with * are overridable, so you will need to ensure any custom ports you provide are also open. Although etcd ports are included in control-plane nodes, you can also host your own etcd cluster externally or on custom ports. </del> <ins> These [required ports](/docs/reference/ports-and-protocols/) need to be open in order for Kubernetes components to communicate with each other. </ins> The pod network plugin you use (see below) may also require certain ports to be open. Since this differs with each pod network plugin, please see the

What would you like to be Create a dedicated ports and protocols page for Kubernetes Clusters. Why is this needed Currently, the closest page that provides this information is under KubeAdm install setup . This is hard to find for any cluster administrator trying to deploy Kubernetes Documented Ports for and are incorrect and need an update Slack thread: /sig security node docs architecture /area security
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : What would you like to be Create a dedicated ports and protocols page for Kubernetes Clusters. Currently, the closest page that provides this information is under KubeAdm install setup . This is hard to find for any cluster administrator trying to deploy Kubernetes Documented Ports for and are incorrect and need an update /area security Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/triage accepted
Hi Would you be OK to have this as a reference page, rather than as a concept?
/sig network
/sig cluster-lifecycle Given the PR touches kubeadm docs.
Moved it under . This was the kind of feedback I was looking for from SIG Docs. Thank you


Question: ### Local <del> {{< feature-state for_k8s_version="v1.14" state="stable" >}} </del> ```yaml apiVersion: storage.k8s.io/v1 kind: StorageClass

There's a section for ReclaimPolicy, which states that this can be or . It is not clear as to what those states mean, there's NO explanation. I was researching how to expand disk, and one guide says that the must be , but I cannot find reference as to what this means. My expectation was that these would be explained what they mean, rather than this is the only do option.
Page related to issue: /retitle Lack of explanation for options - Retain and Delete /language en
These concepts are well explained in 'concepts/storage/persistent-'. Maybe a pointer or two suffices?
Please refer link here you will find the brief introduction about the retain or delete. I think this link will be helpful to understand.
/assign
/triage accepted


Question: kubectl exec -ti cassandra-0 -- nodetool status # cleanup <del> grace=$(kubectl get po cassandra-0 --template '{{.spec.terminationGracePeriodSeconds}}')  </del> <ins> grace=$(kubectl get po cassandra-0 -o=jsonpath='{.spec.terminationGracePeriodSeconds}')  </ins> && kubectl delete statefulset,po -l app=cassandra  && echo "Sleeping $grace"  && sleep $grace

<!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!--Required Information--This is a... <!-- choose one by changing [ ] to [x] --- [ ] Feature Request [X] Bug Report Problem: There is a warning during the Netlify preview build process: Looks like liquid is trying to parse in the line: Proposed Solution: Find out how to escape in a code block for Liquid. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Kubernetes 1.6 <!--Additional Information:--


Question: <ins> --- title: 确保 PodDisruptionBudget 的前提下安全地清空一个节点 content_type: task --- <!-- reviewers: - davidopp - mml - foxish - kow3ns title: Safely Drain a Node while Respecting the PodDisruptionBudget content_type: task --> <!-- overview --> <!-- This page shows how to safely drain a node, respecting the PodDisruptionBudget you have defined. --> 本页展示了如何在确保 PodDisruptionBudget 的前提下，安全地清空一个节点。 ## {{% heading "prerequisites" %}} <!-- This task assumes that you have met the following prerequisites: * You are using Kubernetes release >= 1.5. * Either: 1. You do not require your applications to be highly available during the node drain, or 1. You have read about the [PodDisruptionBudget concept](/docs/concepts/workloads/pods/disruptions/) and [Configured PodDisruptionBudgets](/docs/tasks/run-application/configure-pdb/) for applications that need them. --> 此任务假设您已经满足以下先决条件： * 使用的 Kubernetes 版本 >= 1.5。 * 以下两项，具备其一： 1. 在节点清空期间，不要求应用程序具有高可用性 1. 你已经了解了 [PodDisruptionBudget 的概念](/zh/docs/concepts/workloads/pods/disruptions/)，并为需要它的应用程序[配置了 PodDisruptionBudget](/zh/docs/tasks/run-application/configure-pdb/)。 <!-- steps --> <!-- ## Use `kubectl drain` to remove a node from service You can use `kubectl drain` to safely evict all of your pods from a node before you perform maintenance on the node (e.g. kernel upgrade, hardware maintenance, etc.). Safe evictions allow the pod's containers to [gracefully terminate](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination) and will respect the `PodDisruptionBudgets` you have specified. --> ## 使用 `kubectl drain` 从服务中删除一个节点 {#use-kubectl-drain-to-remove-a-node-from-service} 在对节点执行维护（例如内核升级、硬件维护等）之前， 可以使用 `kubectl drain` 从节点安全地逐出所有 Pods。 安全的驱逐过程允许 Pod 的容器 [体面地终止](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)， 并确保满足指定的 `PodDisruptionBudgets` 。 <!-- By default `kubectl drain` will ignore certain system pods on the node that cannot be killed; see the [kubectl drain](/docs/reference/generated/kubectl/kubectl-commands/#drain) documentation for more details. --> {{< note >}} 默认情况下， `kubectl drain` 将忽略节点上不能杀死的特定系统 Pod； 有关更多细节，请参阅 [kubectl drain](/docs/reference/generated/kubectl/kubectl-commands/#drain) 文档。 {{< /note >}} <!-- When `kubectl drain` returns successfully, that indicates that all of the pods (except the ones excluded as described in the previous paragraph) have been safely evicted (respecting the desired graceful termination period, and respecting the PodDisruptionBudget you have defined). It is then safe to bring down the node by powering down its physical machine or, if running on a cloud platform, deleting its virtual machine. First, identify the name of the node you wish to drain. You can list all of the nodes in your cluster with --> `kubectl drain` 的成功返回，表明所有的 Pods（除了上一段中描述的被排除的那些）， 已经被安全地逐出（考虑到期望的终止宽限期和你定义的 PodDisruptionBudget）。 然后就可以安全地关闭节点， 比如关闭物理机器的电源，如果它运行在云平台上，则删除它的虚拟机。 ```shell kubectl get nodes ``` <!-- Next, tell Kubernetes to drain the node: --> 接下来，告诉 Kubernetes 清空节点： ```shell kubectl drain <node name> ``` <!-- Once it returns (without giving an error), you can power down the node (or equivalently, if on a cloud platform, delete the virtual machine backing the node). If you leave the node in the cluster during the maintenance operation, you need to run --> 一旦它返回（没有报错）， 你就可以下电此节点（或者等价地，如果在云平台上，删除支持该节点的虚拟机）。 如果要在维护操作期间将节点留在集群中，则需要运行： ```shell kubectl uncordon <node name> ``` <!-- afterwards to tell Kubernetes that it can resume scheduling new pods onto the node. --> 然后告诉 Kubernetes，它可以继续在此节点上调度新的 Pods。 <!-- ## Draining multiple nodes in parallel The `kubectl drain` command should only be issued to a single node at a time. However, you can run multiple `kubectl drain` commands for different nodes in parallel, in different terminals or in the background. Multiple drain commands running concurrently will still respect the `PodDisruptionBudget` you specify. --> ## 并行清空多个节点  {#draining-multiple-nodes-in-parallel} `kubectl drain` 命令一次只能发送给一个节点。 但是，你可以在不同的终端或后台为不同的节点并行地运行多个 `kubectl drain` 命令。 同时运行的多个 drain 命令仍然遵循你指定的 `PodDisruptionBudget` 。 <!-- For example, if you have a StatefulSet with three replicas and have set a `PodDisruptionBudget` for that set specifying `minAvailable: 2`. `kubectl drain` will only evict a pod from the StatefulSet if all three pods are ready, and if you issue multiple drain commands in parallel, Kubernetes will respect the PodDisruptionBudget and ensure that only one pod is unavailable at any given time. Any drains that would cause the number of ready replicas to fall below the specified budget are blocked. --> 例如，如果你有一个三副本的 StatefulSet， 并设置了一个 `PodDisruptionBudget`，指定 `minAvailable: 2`。 如果所有的三个 Pod 均就绪，并且你并行地发出多个 drain 命令， 那么 `kubectl drain` 只会从 StatefulSet 中逐出一个 Pod， 因为 Kubernetes 会遵守 PodDisruptionBudget 并确保在任何时候只有一个 Pod 不可用。 任何会导致就绪副本数量低于指定预算的清空操作都将被阻止。 <!-- ## The Eviction API If you prefer not to use [kubectl drain](/docs/reference/generated/kubectl/kubectl-commands/#drain) (such as to avoid calling to an external command, or to get finer control over the pod eviction process), you can also programmatically cause evictions using the eviction API. --> ## 驱逐 API {#the-eviction-api} 如果你不喜欢使用 [kubectl drain](/zh/docs/reference/generated/kubectl/kubectl-commands/#drain) （比如避免调用外部命令，或者更细化地控制 pod 驱逐过程）， 你也可以用驱逐 API 通过编程的方式达到驱逐的效果。 <!-- You should first be familiar with using [Kubernetes language clients](/docs/tasks/administer-cluster/access-cluster-api/#programmatic-access-to-the-api). The eviction subresource of a pod can be thought of as a kind of policy-controlled DELETE operation on the pod itself. To attempt an eviction (perhaps more REST-precisely, to attempt to *create* an eviction), you POST an attempted operation. Here's an example: --> 首先应该熟悉使用 [Kubernetes 语言客户端](/zh/docs/tasks/administer-cluster/access-cluster-api/#programmatic-access-to-the-api)。 Pod 的 Eviction 子资源可以看作是一种策略控制的 DELETE 操作，作用于 Pod 本身。 要尝试驱逐（更准确地说，尝试 *创建* 一个 Eviction），需要用 POST 发出所尝试的操作。这里有一个例子： ```json { "apiVersion": "policy/v1beta1", "kind": "Eviction", "metadata": { "name": "quux", "namespace": "default" } } ``` <!-- You can attempt an eviction using `curl`: --> 你可以使用 `curl` 尝试驱逐： ```bash curl -v -H 'Content-type: application/json' http://127.0.0.1:8080/api/v1/namespaces/default/pods/quux/eviction -d @eviction.json ``` <!-- The API can respond in one of three ways: - If the eviction is granted, then the pod is deleted just as if you had sent a `DELETE` request to the pod's URL and you get back `200 OK`. - If the current state of affairs wouldn't allow an eviction by the rules set forth in the budget, you get back `429 Too Many Requests`. This is typically used for generic rate limiting of *any* requests, but here we mean that this request isn't allowed *right now* but it may be allowed later. Currently, callers do not get any `Retry-After` advice, but they may in future versions. - If there is some kind of misconfiguration, like multiple budgets pointing at the same pod, you will get `500 Internal Server Error`. --> API可以通过以下三种方式之一进行响应： - 如果驱逐被授权，那么 Pod 将被删掉，并且你会收到 `200 OK`， 就像你向 Pod 的 URL 发送了 `DELETE` 请求一样。 - 如果按照预算中规定，目前的情况不允许的驱逐，你会收到 `429 Too Many Requests`。 这通常用于对 *一些* 请求进行通用速率限制， 但这里我们的意思是：此请求 *现在* 不允许，但以后可能会允许。 目前，调用者不会得到任何 `Retry-After` 的提示，但在将来的版本中可能会得到。 - 如果有一些错误的配置，比如多个预算指向同一个 Pod，你将得到 `500 Internal Server Error`。 <!-- For a given eviction request, there are two cases: - There is no budget that matches this pod. In this case, the server always returns `200 OK`. - There is at least one budget. In this case, any of the three above responses may apply. --> 对于一个给定的驱逐请求，有两种情况： - 没有匹配这个 Pod 的预算。这种情况，服务器总是返回 `200 OK`。 - 至少匹配一个预算。在这种情况下，上述三种回答中的任何一种都可能适用。 <!-- In some cases, an application may reach a broken state where it will never return anything other than 429 or 500. This can happen, for example, if the replacement pod created by the application's controller does not become ready, or if the last pod evicted has a very long termination grace period. In this case, there are two potential solutions: - Abort or pause the automated operation. Investigate the reason for the stuck application, and restart the automation. - After a suitably long wait, `DELETE` the pod instead of using the eviction API. Kubernetes does not specify what the behavior should be in this case; it is up to the application owners and cluster owners to establish an agreement on behavior in these cases. --> 在某些情况下，应用程序可能会到达一个中断状态，除了 429 或 500 之外，它将永远不会返回任何内容。 例如应用程序控制器创建的替换 Pod 没有准备好，或者被驱逐的最后一个 Pod 有很长的终止宽限期，就会发生这种情况。 在这种情况下，有两种可能的解决方案： - 中止或暂停自动操作。调查应用程序卡住的原因，并重新启动自动化。 - 经过适当的长时间等待后， `DELETE` Pod，而不是使用驱逐 API。 Kubernetes 并没有具体说明在这种情况下应该采取什么行为； 这应该由应用程序所有者和集群所有者紧密沟通，并达成对行动一致意见。 ## {{% heading "whatsnext" %}} <!-- * Follow steps to protect your application by [configuring a Pod Disruption Budget](/docs/tasks/run-application/configure-pdb/). * Learn more about [maintenance on a node](/docs/tasks/administer-cluster/cluster-management/#maintenance-on-a-node). --> * 跟随以下步骤保护应用程序：[配置 Pod 中断预算](/zh/docs/tasks/run-application/configure-pdb/)。 * 进一步了解[节点维护](/zh/docs/tasks/administer-cluster/cluster-management/#maintenance-on-a-node)。 </ins>

This is a Feature Request page /docs/tasks/administer-cluster/safely-drain-node/ is not available in Chinese version. What would you like to be file: content/zh/docs/tasks/administer-cluster/safely-drain- the file from its english version Why is this needed synchronize Chinese with English version Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --
/language zh /assign


Question: 4. Katacoda environment only: Type `30000`, and then click **Display Port**. <ins> {{< note >}} The `dashboard` command enables the dashboard add-on and opens the proxy in the default web browser. You can create Kubernetes resources on the dashboard such as Deployment and Service. If you are running in an environment as root, see [Open Dashboard with URL](/docs/tutorials/hello-minikube#open-dashboard-with-url). To stop the proxy, run `Ctrl+C` to exit the process. The dashboard remains running. {{< /note >}} ## Open Dashboard with URL If you don't want to open a web browser, run the dashboard command with the url flag to emit a URL: ```shell minikube dashboard --url ``` </ins> ## Create a Deployment A Kubernetes [*Pod*](/docs/concepts/workloads/pods/) is a group of one or more Containers,

After issuing the command "minikube dashboard" in the "Create a minikube cluster" section, I never get the command prompt back. How, then, am I supposed to issue the commands listed in the following section, "Create a deployment"?
/retitle “Hello Minikube” tutorial runs dashboard subcommand in foreground /kind bug /triage accepted That's a good point. The tutorial doesn't explain what to do here. /priority important-longterm /language en
!
/assign


Question: min-kubernetes-server-version: v1.22 --- <del> Namespaces can be labeled to enforce the [Pod Security Standards](/docs/concepts/security/pod-security-standards). </del> <ins> Namespaces can be labeled to enforce the [Pod Security Standards](/docs/concepts/security/pod-security-standards). The three policies [privileged](/docs/concepts/security/pod-security-standards/#privileged), [baseline](/docs/concepts/security/pod-security-standards/#baseline) and [restricted](https://kubernetes.io/docs/concepts/security/pod-security-standards/#restricted) broadly cover the security spectrum and are implemented by the [Pod Security](/docs/concepts/security/pod-security-admission/) {{< glossary_tooltip text="admission controller" term_id="admission-controller" >}}. </ins> ## {{% heading "prerequisites" %}}

Hello, It's not clear what the meaning of restricted warnings and restricted audit or any combination of them. It seems that you attempt to design in a way that you want to make things more complicated. The aim of your design seems that nobody should be able to understand clearly and one should spend a lot of time for understanding the basics. You can create very complex systems but at the end you will see that nobody uses them. We have seen such attempts in the past from big vendors and after a lot of marketing and spending millions of dollars, those big guys failed miserably. Can someone explain the meaning of all those and possibly more combinations? enforce: baseline, audit: baseline, warn: baseline enforce: baseline, audit: restricted, warn: baseline enforce: baseline, audit: restricted, warn: restricted enforce: restricted, audit: baseline, warn: baseline enforce: restricted, audit: restricted, warn: baseline enforce: restricted, audit: restricted, warn: restricted enforce: privileged, audit: baseline, warn: baseline enforce: privileged, audit: privileged, warn: baseline enforce: privileged, audit: privileged, warn: privileged enforce: baseline, audit: restricted, warn: privileged ... ... ...
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
The first sentence in this page is Although this introduction is accurate, we could add more text to avoid the risk of a reader skipping past it and then feeling confused. For example, we could name the three Pod Security Standards and make each of those names a link to the relevant part of ; we could also repeat the table from the top of do you think adding more text to the introduction would help here? /language en
We could also link to in the introduction; I think we should.


Question: <!-- ## Debugging via a shell on the node {#node-shell-session} <del> If none of these approaches work, you can find the host machine that the pod is running on and SSH into that host, but this should generally not be necessary given tools in the Kubernetes API. Therefore, if you find yourself needing to ssh into a machine, please file a feature request on GitHub describing your use case and why these tools are insufficient. </del> <ins> If none of these approaches work, you can find the Node on which the Pod is running and create a privileged Pod running in the host namespaces. To create an interactive shell on a node using `kubectl debug`, run: </ins> --> <del> ## 在节点上通过 shell 来调试 {#node-shell-session} </del> <ins> ## 在节点上通过 shell 来进行调试 {#node-shell-session} </ins> <del> 如果这些方法都不起作用，你可以找到运行 Pod 的主机并通过 SSH 进入该主机， 但是如果使用 Kubernetes API 中的工具，则通常不需要这样做。 因此，如果你发现自己需要使用 ssh 进入主机，请在GitHub 上提交功能请求， 以描述你的用例以及这些工具不足的原因。 </del> <ins> 如果这些方法都不起作用，你可以找到运行 Pod 的节点，然后在节点上部署一个运行在宿主名字空间的特权 Pod。 你可以通过`kubectl debug` 在节点上创建一个交互式 shell： ```shell kubectl debug node/mynode -it --image=ubuntu ``` ``` Creating debugging pod node-debugger-mynode-pdx84 with container debugger on node mynode. If you don't see a command prompt, try pressing enter. root@ek8s:/# ``` <!-- When creating a debugging session on a node, keep in mind that: * `kubectl debug` automatically generates the name of the new Pod based on the name of the Node. * The container runs in the host IPC, Network, and PID namespaces. * The root filesystem of the Node will be mounted at `/host`. Don't forget to clean up the debugging Pod when you're finished with it: --> 当在节点上创建调试会话，注意以下要点： * `kubectl debug` 基于节点的名字自动生成新的 Pod 的名字。 * 新的调试容器运行在宿主命名空间里（IPC, 网络 还有PID命名空间）。 * 节点的根文件系统会被挂载在 `/host`。 当你完成节点调试时，不要忘记清理调试 Pod： ```shell kubectl delete pod node-debugger-mynode-pdx84 ``` </ins>  No newline at end of file

Recently I am exploring the and found that section of in the Chinese document is outdated so I tried to update it. en: zh:
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/language zh


Question:
--service-account-key-file strings

File containing PEM-encoded x509 RSA or ECDSA private or public keys, used to verify ServiceAccount tokens. The specified file can contain multiple keys, and the flag can be specified multiple times with different files. If unspecified, --tls-private-key-file is used. Must be specified when --service-account-signing-key is provided

File containing PEM-encoded x509 RSA or ECDSA private or public keys, used to verify ServiceAccount tokens. The specified file can contain multiple keys, and the flag can be specified multiple times with different files. If unspecified, --tls-private-key-file is used. Must be specified when --service-account-signing-key-file is provided

This is a Bug Report Problem: Documentation for cli tool kube-apiserver ] references flag which doesn't exist. The intended documentation should reference the flag. The cli tool implementation ] also has an incorrect doc-string ]. I'll make cross-referencing issues for both projects Proposed Solution: All references to the should be updated to Page to Update: Kubernetes Versions: Additional Information: Issue and PR on the kubernetes/kubernetes project are:
/assign /triage accepted
/retitle Documentation references --service-account-signing-key flag that doesn't exist
This is now essentially a duplicate of


Question: ## {{% heading "whatsnext" %}} <del> * Read the [kube-scheduler reference](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/) </del> <ins> * Read the [kube-scheduler reference](/docs/reference/command-line-tools-reference/kube-scheduler/) </ins> * Learn about [scheduling](/docs/concepts/scheduling-eviction/kube-scheduler/) * Read the [kube-scheduler configuration (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) reference

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: The href of contains unwanted . A slash () is missing in the href of . Proposed Solution: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/language en /assign
/triage accepted


Question: 힙스터에서 메트릭 가져오기는 Kubernetes 1.11에서 사용 중단(deprecated)됨. {{< /note >}} <del> 자세한 사항은 [메트릭 API를 위한 지원](#메트릭-API를-위한-지원)을 참조한다. </del> <ins> 자세한 사항은 [메트릭 API를 위한 지원](#메트릭-api를-위한-지원)을 참조한다. </ins> 오토스케일러는 스케일 하위 리소스를 사용하여 상응하는 확장 가능 컨트롤러(예: 레플리케이션 컨트롤러, 디플로이먼트, 레플리케이션 셋)에 접근한다. 스케일은 레플리카의 개수를 동적으로 설정하고 각 현재 상태를 검사 할 수 있게 해주는 인터페이스이다.

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: In , the link " API " is broken. Proposed Solution: Page to Update: -- <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/language ko
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/good-first-issue
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /good-first-issue </details
/assign


Question: For example, if you are intending to run a Kubernetes cluster on your laptop (locally), you will need a tool like [Minikube](https://minikube.sigs.k8s.io/docs/start/) to be installed first and then re-run the commands stated above. <del> If kubectl cluster-info returns the url response but you can't access your cluster, </del> <ins> If `kubectl cluster-info` returns the url response but you can't access your cluster, </ins> to check whether it is configured properly, use: ```shell

The is a command code but not marked as inline code. I think marking it will help learners
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/language en
Raised PR with fix /assign


Question: <ins> apiVersion: v1 kind: Pod metadata: name: env-single-secret spec: containers: - name: envars-test-container image: nginx env: - name: SECRET_USERNAME valueFrom: secretKeyRef: name: backend-user key: backend-username </ins>

Translate into Japanese. This page has not been translated. /language ja /assign
/triage accepted


This is a Feature Report Problem: misssing Chinese translation docs: content/en/blog/_posts/2022-08-16-PSP-historical- URL Proposed Solution: add Chinese translation docs in website Kubernetes Blog Comments /language zh /assign
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details


Question: - You can't use ConfigMaps for {{< glossary_tooltip text="static pods" term_id="static-pod" >}}, because the Kubelet does not support this. <ins> ### Optional ConfigMaps In a Pod, or pod template, you can mark a reference to a ConfigMap as _optional_. If the ConfigMap is non-existent, the configuration for which it provides data in the Pod (e.g. environment variable, mounted volume) will be empty. If the ConfigMap exists, but the referenced key is non-existent the data is also empty. #### Optional ConfigMap in environment variables There might be situations where environment variables are not always required. You can mark an environment variables for a container as optional, like this: ```yaml apiVersion: v1 kind: Pod metadata: name: dapi-test-pod spec: containers: - name: test-container image: gcr.io/google_containers/busybox command: [ "/bin/sh", "-c", "env" ] env: - name: SPECIAL_LEVEL_KEY valueFrom: configMapKeyRef: name: a-config key: akey optional: true # mark the variable as optional restartPolicy: Never ``` If you run this pod, and there is no ConfigMap named `a-config`, the output is empty. If you run this pod, and there is a ConfigMap named `a-config` but that ConfigMap doesn't have a key named `akey`, the output is also empty. If you do set a value for `akey` in the `a-config` ConfigMap, this pod prints that value and then terminates. #### Optional ConfigMap via volume plugin Volumes and files provided by a ConfigMap can be also be marked as optional. The ConfigMap or the key specified does not have to exist. The mount path for such items will always be created. ```yaml apiVersion: v1 kind: Pod metadata: name: dapi-test-pod spec: containers: - name: test-container image: gcr.io/google_containers/busybox command: [ "/bin/sh", "-c", "ls /etc/config" ] volumeMounts: - name: config-volume mountPath: /etc/config volumes: - name: config-volume configMap: name: no-config optional: true # mark the source ConfigMap as optional restartPolicy: Never ``` If you run this pod, and there is no ConfigMap named `no-config`, the mounted volume will be empty. ### Mounted ConfigMaps are updated automatically When a mounted ConfigMap is updated, the projected content is eventually updated too.  This applies in the case where an optionally referenced ConfigMap comes into existence after a pod has started. The kubelet checks whether the mounted ConfigMap is fresh on every periodic sync. However, it uses its local TTL-based cache for getting the current value of the ConfigMap. As a result, the total delay from the moment when the ConfigMap is updated to the moment when new keys are projected to the pod can be as long as kubelet sync period (1 minute by default) + TTL of ConfigMaps cache (1 minute by default) in kubelet. {{< note >}} A container using a ConfigMap as a [subPath](/docs/concepts/storage/volumes/#using-subpath) volume will not receive ConfigMap updates. {{< /note >}} </ins> ## {{% heading "whatsnext" %}}

This is a... [x] Bug Report Problem: The documentation mentions "optional" in the restrictions for configmap, but doesn't explain how to use it anywhere else in the documentation. You must create a ConfigMap before referencing it in a Pod specification (unless you mark the ConfigMap as “optional”). If you reference a ConfigMap that doesn’t exist, the Pod won’t start. Likewise, references to keys that don’t exist in the ConfigMap will prevent the pod from starting. Please see for the feature. It appears it got lost in the 1.5-1.6 upgrade. Proposed Solution: Restore the copy from that wrote. Page to Update:
For clarity, the copy from got removed here:
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/language en /remove-lifecycle stale /assign
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
/priority backlog
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle stale
/remove-lifecycle rotten
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Relevant to /remove-lifecycle stale
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
This awesome feature is still missing in the documentation, Can someone please add it ?
were you thinking of opening a pull request? We'd be happy to help you with that.
/remove-lifecycle stale
/lifecycle frozen
/triage accepted
I don't see any updates; so unassigning you. Please feel free to assign, if you come back here again and are willing to work on it. Thank you! /unassign
/assign


Question: 1. Apply the MongoDB Service from the following `mongo-service.yaml` file: <ins> <!--- for local testing of the content via relative file path kubectl apply -f ./content/en/examples/application/guestbook/mongo-service.yaml --> </ins> ```shell kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-service.yaml ``` <del> <!--- for local testing of the content via relative file path kubectl apply -f ./content/en/examples/application/guestbook/mongo-service.yaml --> </del> 1. Query the list of Services to verify that the MongoDB Service is running: ```shell

4 ordered lists have wrong indexes. For example, the number below should be 3. ! Page to update: /language en /kind cleanup
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign


Question: The version of Kubernetes that you need depends on which KMS API version you have selected.  Kubernetes recommends using KMS v2. <del> - If you selected KMS API v2, you should use Kubernetes v{{< skew currentVersion >}} (if you are running a different version of Kubernetes that also supports the v2 KMS API, switch to the documentation for that version of Kubernetes). </del> - If you selected KMS API v1 to support clusters prior to version v1.27 or if you have a legacy KMS plugin that only supports KMS v1, any supported Kubernetes version will work.  This API is deprecated as of Kubernetes v1.28.

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: The prerequisites for KMS encryption of control plane data are a bit stale given that KMSv2 is now fully stable and all supported releases include some level of KMSv2 support. no longer really applies. Proposed Solution: Revise and reword the start of the page, to focus on recommending KMSv2 rather than recommending specific Kubernetes versions. Page to Update: Additional Information: /sig security /language en
/priority backlog /triage accepted
/assign


Question: ```shell kubectl cluster-info dump <del> ``` </del>  No newline at end of file <ins> ``` ### Troubleshooting the 'No Auth Provider Found' error message {#no-auth-provider-found} In Kubernetes 1.26, kubectl removed the built-in authentication for the following cloud providers' managed Kubernetes offerings. These providers have released kubectl plugins to provide the cloud-specific authentication. For instructions, refer to the following provider documentation: * Azure  AKS: [kubelogin plugin](https://azure.github.io/kubelogin/) * Google Kubernetes Engine: [gke-gcloud-auth-plugin](https://cloud.google.com/kubernetes-engine/docs/how-to/cluster-access-for-kubectl#install_plugin) (There could also be other reasons to see the same error message, unrelated to that change.) </ins>

This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be (As I understand it), Kubernetes ~v1.25~ v1.26 ships an updated . The updated won't include built-in plugins for authenticating to AKS or GKE. This is likely to surprise folks. Update 3 pages: to signpost users to the right internal ~and external~ docs. We can remove this signposting once Kubernetes v1.27 (sic) is the oldest supported version of Kubernetes (consider adding an HTML comment with that detail). Optionally, also update to mention that earlier versions of included built-in support for authenticating to AKS and GKE, but this is no longer present. Why is this needed Readers may follow the “install kubectl” docs and get a tool that's missing functionality they thought was built in. Comments /sig cli /language en
/triage accepted /priority important-soon
For each of the three pages, add the following under the Verify kubectl configuration heading, at the end of the section:
/help-wanted
The label(s) cannot be applied. These labels are supported: <detailsIn response to : /label help-wanted Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/help
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /help Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository.

</details
/assign
Kubernetes 1.25.0 did not remove Google and Azure auth plugins due to a regression issue, see The revert is in PR
This change is likely to arrive in v1.26, so we should get it staffed.
would you be willing to change the minor version in ?
-- as author/reviewer of the , can you please review the doc change suggested by in
A few suggestions: I probably would not put "panic" in the heading title Can we link to as well I'm on the fence about whether we need the cloud-specific links in this doc... if you try to use them in a kubectl version that has removed them, you already get a message output at time of use with the appropriate link/reference. If we do keep those links, I would say something like "These providers have released kubectl plugins to provide the cloud-specific authentication." instead of "fix the authentication"
I personally do not think the kube authn docs should contain cloud-specific links. It is on the cloud providers to migrate their users anyway, and the cloud CLI tools are fully capable of hiding the bulk of this migration by performing runtime checks and/or preferring credential plugins over the legacy approach.
I agree about not including cloud-provider-specific links. Integrations with cloud providers are not required for a (vanilla) Kubernetes cluster to function. See for some more context.
We can instead advise readers to search in their cloud provider's documentation for further advice.
Hello , 1.26 Release Docs Lead here. This feature request needs Docs for 1.26 release. Please to open a PR against dev-1.26 branch in the k/website repo. This PR can be just a placeholder at this time, and must be created by November 10. Also, take a look at to familiarize yourself with the docs requirement for the release. Any doubt, reach us! Thank you!
/unassign
This issue is labeled with but has not been updated in over 90 days, and should be re-triaged. Important-soon issues must be staffed and worked on either currently, or very soon, ideally in time for the next release.

You can: Confirm that this issue is still relevant with (org members only) Deprioritize it with or Close this issue with For more details on the triage process, see /remove-triage accepted
//remove-priority important-soon /priority important-longterm /triage accepted
/remove-priority important-soon
could you kindly provide a detailed description of the issue once more? Upon reviewing the above comments, it appears that numerous changes have been implemented.
looks right to me. In terms of the “right internal and internal docs” to link to, you should use your judgement. You could link to or to a task page; you might need to write the task page first. Any more questions? It's clear to me, but I might have missed something.
/assign
Thanks , I am working on this, will create a PR soon ;)


Question:
 --- title: kube-apiserver Configuration (v1alpha1) content_type: tool-reference package: apiserver.k8s.io/v1alpha1 auto_generated: true ---
Package v1alpha1 is the v1alpha1 version of the API.
 ## Resource Types - [AdmissionConfiguration](#apiserver-k8s-io-v1alpha1-AdmissionConfiguration) - [EgressSelectorConfiguration](#apiserver-k8s-io-v1alpha1-EgressSelectorConfiguration) - [TracingConfiguration](#apiserver-k8s-io-v1alpha1-TracingConfiguration) ## `AdmissionConfiguration`     {#apiserver-k8s-io-v1alpha1-AdmissionConfiguration}
AdmissionConfiguration provides versioned configuration for admission controllers.

Field	Description

apiVersion
string	apiserver.k8s.io/v1alpha1

kind
string	AdmissionConfiguration

plugins
 []AdmissionPluginConfiguration
Plugins allows specifying a configuration per admission control plugin.

 ## `EgressSelectorConfiguration`     {#apiserver-k8s-io-v1alpha1-EgressSelectorConfiguration}
EgressSelectorConfiguration provides versioned configuration for egress selector clients.

Field	Description

apiVersion
string	apiserver.k8s.io/v1alpha1

kind
string	EgressSelectorConfiguration

egressSelections [Required]
 []EgressSelection
connectionServices contains a list of egress selection client configurations

 ## `TracingConfiguration`     {#apiserver-k8s-io-v1alpha1-TracingConfiguration}
TracingConfiguration provides versioned configuration for tracing clients.

Field	Description

apiVersion
string	apiserver.k8s.io/v1alpha1

kind
string	TracingConfiguration

endpoint
 string
Endpoint of the collector that's running on the control-plane node. The APIServer uses the egressType ControlPlane when sending data to the collector. The syntax is defined in https://github.com/grpc/grpc/blob/master/doc/naming.md. Defaults to the otlpgrpc default, localhost:4317 The connection is insecure, and does not support TLS.

samplingRatePerMillion
 int32
SamplingRatePerMillion is the number of samples to collect per million spans. Defaults to 0.

 ## `AdmissionPluginConfiguration`     {#apiserver-k8s-io-v1alpha1-AdmissionPluginConfiguration} **Appears in:** - [AdmissionConfiguration](#apiserver-k8s-io-v1alpha1-AdmissionConfiguration)
AdmissionPluginConfiguration provides the configuration for a single plug-in.

Field	Description

name [Required]
 string
Name is the name of the admission controller. It must match the registered admission plugin name.

path
 string
Path is the path to a configuration file that contains the plugin's configuration

configuration
 k8s.io/apimachinery/pkg/runtime.Unknown
Configuration is an embedded configuration object to be used as the plugin's configuration. If present, it will be used instead of the path to the configuration file.

 ## `Connection`     {#apiserver-k8s-io-v1alpha1-Connection} **Appears in:** - [EgressSelection](#apiserver-k8s-io-v1alpha1-EgressSelection)
Connection provides the configuration for a single egress selection client.

Field	Description

proxyProtocol [Required]
 ProtocolType
Protocol is the protocol used to connect from client to the konnectivity server.

transport
 Transport
Transport defines the transport configurations we use to dial to the konnectivity server. This is required if ProxyProtocol is HTTPConnect or GRPC.

 ## `EgressSelection`     {#apiserver-k8s-io-v1alpha1-EgressSelection} **Appears in:** - [EgressSelectorConfiguration](#apiserver-k8s-io-v1alpha1-EgressSelectorConfiguration)
EgressSelection provides the configuration for a single egress selection client.

Field	Description

name [Required]
 string
name is the name of the egress selection. Currently supported values are "controlplane", "master", "etcd" and "cluster" The "master" egress selector is deprecated in favor of "controlplane"

connection [Required]
 Connection
connection is the exact information used to configure the egress selection

 ## `ProtocolType`     {#apiserver-k8s-io-v1alpha1-ProtocolType} (Alias of `string`) **Appears in:** - [Connection](#apiserver-k8s-io-v1alpha1-Connection)
ProtocolType is a set of valid values for Connection.ProtocolType
 ## `TCPTransport`     {#apiserver-k8s-io-v1alpha1-TCPTransport} **Appears in:** - [Transport](#apiserver-k8s-io-v1alpha1-Transport)
TCPTransport provides the information to connect to konnectivity server via TCP

Field	Description

url [Required]
 string
URL is the location of the konnectivity server to connect to. As an example it might be "https://127.0.0.1:8131"

tlsConfig
 TLSConfig
TLSConfig is the config needed to use TLS when connecting to konnectivity server

 ## `TLSConfig`     {#apiserver-k8s-io-v1alpha1-TLSConfig} **Appears in:** - [TCPTransport](#apiserver-k8s-io-v1alpha1-TCPTransport)
TLSConfig provides the authentication information to connect to konnectivity server Only used with TCPTransport

Field	Description

caBundle
 string
caBundle is the file location of the CA to be used to determine trust with the konnectivity server. Must be absent/empty if TCPTransport.URL is prefixed with http:// If absent while TCPTransport.URL is prefixed with https://, default to system trust roots.

clientKey
 string
clientKey is the file location of the client key to be used in mtls handshakes with the konnectivity server. Must be absent/empty if TCPTransport.URL is prefixed with http:// Must be configured if TCPTransport.URL is prefixed with https://

clientCert
 string
clientCert is the file location of the client certificate to be used in mtls handshakes with the konnectivity server. Must be absent/empty if TCPTransport.URL is prefixed with http:// Must be configured if TCPTransport.URL is prefixed with https://

 ## `Transport`     {#apiserver-k8s-io-v1alpha1-Transport} **Appears in:** - [Connection](#apiserver-k8s-io-v1alpha1-Connection)
Transport defines the transport configurations we use to dial to the konnectivity server

Field	Description

tcp
 TCPTransport
TCP is the TCP configuration for communicating with the konnectivity server via TCP ProxyProtocol of GRPC is not supported with TCP transport at the moment Requires at least one of TCP or UDS to be set

uds
 UDSTransport
UDS is the UDS configuration for communicating with the konnectivity server via UDS Requires at least one of TCP or UDS to be set

 ## `UDSTransport`     {#apiserver-k8s-io-v1alpha1-UDSTransport} **Appears in:** - [Transport](#apiserver-k8s-io-v1alpha1-Transport)
UDSTransport provides the information to connect to konnectivity server via UDS

Field	Description

udsName [Required]
 string
UDSName is the name of the unix domain socket to connect to konnectivity server This does not use a unix:// prefix. (Eg: /etc/srv/kubernetes/konnectivity-server/konnectivity-server.socket)

Hi, this page has a link which is 404, but I can't find this page in kubernetes website.
In this PR the page: has been removed. should point to the latest page link: /assign
/triage accepted
I could not find the description in the latest page link Is that missing?
Yes, I also checked this struct just now, it doesn't exist in the This struct was removed in version v1. Not sure about the upgrade status of this struct. /cc
There were some nits in the reference generator. We are fixing them and then regenerate the references.
TracingConfiguration is still alpha, and thus doesn't exist in the v1 version of the API.
/kind bug /language en
So do we need to create a new page containing the TracingConfiguration struct so that we can link to it? Or link to the kubernetes TracingConfiguration code line: Which one do you prefer or have a better suggestion?
I'll create a PR updating the config APIs. As for the TracingConfiguration type, it is only part of the v1alpha1 version. This means the current code is incorrect and the v1alpha1 reference needs to be back. This warrants a separate PR.
First PR created
Second PR created /assign


Question: 1. This Service specification explicitly defines `IPv6` and `IPv4` in `.spec.ipFamilies` as well as defining `PreferDualStack` in `.spec.ipFamilyPolicy`. When Kubernetes assigns an IPv6 and <del> IPv4 address in `.spec.ClusterIPs`, `.spec.ClusterIP` is set to the IPv6 address because that is the first element in the `.spec.ClusterIPs` array, overriding the default. </del> <ins> IPv4 address in `.spec.clusterIPs`, `.spec.clusterIP` is set to the IPv6 address because that is the first element in the `.spec.clusterIPs` array, overriding the default. </ins> {{% code_sample file="service/networking/dual-stack-preferred-ipfamilies-svc.yaml" %}}

page is plenty of wrong references to the non defined ` instead.
/triage accepted
/good-first-issue
This request has been marked as suitable for new contributors. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /good-first-issue Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/kind bug
/assign
Thanks for solving this so so quick (you are the best ;-)


Question:
--cloud-config string

  	The path to the cloud provider configuration file. Empty string for no configuration file. (DEPRECATED: will be removed in 1.23, in favor of removing cloud providers code from Kubelet.)	   	The path to the cloud provider configuration file. Empty string for no configuration file. (DEPRECATED: will be removed in 1.24 or later, in favor of removing cloud providers code from kubelet.)

 --cloud-provider string

  	The provider for cloud services. Set to empty string for running with no cloud provider. If set, the cloud provider determines the name of the node (consult cloud provider documentation to determine if and how the hostname is used). (DEPRECATED: will be removed in 1.23, in favor of removing cloud provider code from Kubelet.)	   	The provider for cloud services. Set to empty string for running with no cloud provider. If set, the cloud provider determines the name of the node (consult cloud provider documentation to determine if and how the hostname is used). (DEPRECATED: will be removed in 1.24 or later, in favor of removing cloud provider code from Kubelet.)

As per the Kubernetes documentation option is deprecated and removed in v1.23. The link for the documentation. But this parameter is still valid. I got the confiramation. Kublet code : configured the kubelet with in my test K8s v1.23 environment. validated in the # sig-cloud-provider. Document should reflect the correct details: The link for the documentation. Configure the kubelet with the option. No response <details</details<detailsopenstack </details<details</details<details</details<details</details<details</details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig node /sig cloud-provider
This pr has fixed this, waiting website docs to be published.
/kind documentation /remove-kind bug /transfer-issue website
/assign


Question: #### Install wins, kubelet, and kubeadm ```PowerShell <del> curl.exe -LO https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/PrepareNode.ps1 </del> <ins> curl.exe -LO https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/kubeadm/scripts/PrepareNode.ps1 </ins> .PrepareNode.ps1 -KubernetesVersion {{< param "fullversion" >}} -ContainerRuntime containerD ```

Please change the link at ("Adding Windows nodes" page): with the new one:
Welcome and thanks for the first issue here! I will look into this issue. /assign
/triage accepted /kind bug
Instead you can request a new release in the sig windows tools repo, by logging an issue there. Linking to the master branch there is not a good idea, IMO. /sig windows
Also what problems are you seeing?
The problem is that the link is dead. We need to replace it with the link in
GitHub didn't allow me to assign the following users: steven-my. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign steven-my Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign


Question:
Kubernetes Service 总览

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

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

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

"" is a wrong expression, "" is right.
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details


/language zh
/sig auth
/remove-sig auth /assign
Is this not SIG Auth?
By mentioning 'SIG Auth', we mean we want members from that SIG to help review the localization. For one thing, I'm not convinced that will happen. For the other, such mentions are distracting that SIG's attention on PRs which needs their feedback.


Question: 2. Download the Google Cloud public signing key: ```shell <del> sudo curl -fsSLo /etc/apt/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg </del> <ins> curl -fsSL https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-archive-keyring.gpg </ins> ``` 3. Add the Kubernetes `apt` repository:

It is easy to reproduce:
This seems to work: The was . A different solution would be to use , but is deprecated.
This issue is referring the same problem as in I think this will be helpful.
/language en /sig docs
Page related to issue: /kind bug
/retitle Unable to Install kubectl due to GPG Key Issue
We have made recent revisions to the documentation regarding the Google signing key for the installation page, as reflected in the pull request found at In order to resolve this issue, it will be necessary to make corresponding updates to the Kubectl installation instructions.
/triage accepted /priority important-soon
Please change: shell sudo curl -fsSLo /etc/apt/keyrings/kubernetes-archive- curl -fsSL | sudo gpg --dearmor -o /usr/share/keyrings/kubernetes-archive- /help
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : Please change: sudo curl -fsSLo /etc/apt/keyrings/kubernetes-archive- curl -fsSL | sudo gpg --dearmor -o /usr/share/keyrings/kubernetes-archive- Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
would you be willing to edit the initial description for this issue, to make it easy to find: Code changes: link to )
I created a PR to update the docs.
I'd prefer a PR where the commit messages don't mention this issue. It's OK to mention the issue in the GitHub description of the change, but please don't mention the issue in commit messages.

If anyone would like to open a PR, similar to , that doesn't mention this issue in the commit message, then we can accept and merge that PR. Also you are welcome you amend to make it acceptable.
I have raised PR to assist in resolving this issue.
If you followed the guideline and you still get a error. You can do: then retry updating.


Question: Patch your Deployment again with this new patch: ```shell <del> kubectl patch deployment retainkeys-demo --type merge --patch-file patch-file-retainkeys.yaml </del> <ins> kubectl patch deployment retainkeys-demo --type strategic --patch-file patch-file-retainkeys.yaml </ins> ``` Examine the content of the Deployment:

example commands are missing Resulting in: I will prepare a patch for this.
/triage accepted /help
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /triage accepted /help Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details


Question: extended tokens by starting `kube-apiserver` with flag `--service-account-extend-token-expiration=false`. Check [Bound Service Account Tokens](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md) for more details. <ins> - `ControllerManagerLeaderMigration`: Enables Leader Migration for [kube-controller-manager](/docs/tasks/administer-cluster/controller-manager-leader-migration/#initial-leader-migration-configuration) and [cloud-controller-manager](/docs/tasks/administer-cluster/controller-manager-leader-migration/#deploy-cloud-controller-manager) which allows a cluster operator to live migrate controllers from the kube-controller-manager into an external controller-manager (e.g. the cloud-controller-manager) in an HA cluster without downtime. </ins> - `CPUManager`: Enable container level CPU affinity support, see [CPU Management Policies](/docs/tasks/administer-cluster/cpu-management-policies/). - `CRIContainerLogRotation`: Enable container log rotation for CRI container runtime. The default max size of a log file is 10MB and the

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: doesn't list ControllerManagerLeaderMigration although there is a page that mentions it. Proposed Solution: Update / write the documentation for the feature, including a mention of in Page to Update: Additional Information: /sig cloud-provider
I think there's a plan to graduate this to beta; if so, we should definitely look at getting it properly documented.
yup, agreed. I think we can address it once they open a doc for their enhancement /cc /triage accepted
/assign


Question: 建议使用基于策略的准入插件（例如 [PodSecurityPolicy](#podsecuritypolicy) 和自定义准入插件）， 该插件可以针对特定用户或命名空间，还可以防止创建权限过高的 Pod。 <del> ### EventRateLimit {#eventratelimit} {{< feature-state for_k8s_version="v1.13" state="alpha" >}} </del> <ins> ### EventRateLimit {#eventratelimit} {{< feature-state for_k8s_version="v1.13" state="alpha" >}} </ins> <!-- This admission controller mitigates the problem where the API server gets flooded by

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: Page /zh/docs/reference/access-authn-authz/admission-controllers/ display abnormally, these anchor points should start on a new line. Proposed Solution: fix the anchor point format. abnormal format: normal format: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/assign /language zh


Question: * 安装 [kubectl](/zh/docs/tasks/tools/install-kubectl/). <del> * 使用 Google Kubernetes Engine 或 Amazon Web Services 等云供应商创建 Kubernetes 群集。 本教程创建了一个[外部负载均衡器](/zh/docs/tasks/access-application-cluster/create-external-load-balancer/)，需要云供应商。 </del> <ins> * 使用 Google Kubernetes Engine 或 Amazon Web Services 等云供应商创建 Kubernetes 集群。 本教程创建了一个[外部负载均衡器](/zh/docs/tasks/access-application-cluster/create-external-load-balancer/)， 需要云供应商。 </ins> * 配置 `kubectl` 与 Kubernetes API 服务器通信。有关说明，请参阅云供应商文档。 ## {{% heading "objectives" %}} <!-- * Run five instances of a Hello World application. * Create a Service object that exposes an external IP address. * Use the Service object to access the running application. --> * 运行 Hello World 应用程序的五个实例。 * 创建一个公开外部 IP 地址的 Service 对象。 * 使用 Service 对象访问正在运行的应用程序。 <!-- lessoncontent --> <!--

This is a Bug Report Chinese page contentzhdocstutorialsstateless-applicationexpose-external-ip- outdated <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: Chinese page contentzhdocstutorialsstateless-applicationexpose-external-ip- is different with English version page. Proposed Solution: Update Chinese page Page to Update: contentzhdocstutorialsstateless-applicationexpose-external-ip- <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/language zh
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle rotten
/assign


Question: <ins> --- title: 升级集群 content_type: task --- <!-- --- title: Upgrade A Cluster content_type: task --- --> <!-- overview --> <!-- This page provides an overview of the steps you should follow to upgrade a Kubernetes cluster. The way that you upgrade a cluster depends on how you initially deployed it and on any subsequent changes. At a high level, the steps you perform are: --> 本页概述升级 Kubernetes 集群的步骤。 升级集群的方式取决于你最初部署它的方式、以及后续更改它的方式。 从高层规划的角度看，要执行的步骤是： <!-- - Upgrade the {{< glossary_tooltip text="control plane" term_id="control-plane" >}} - Upgrade the nodes in your cluster - Upgrade clients such as {{< glossary_tooltip text="kubectl" term_id="kubectl" >}} - Adjust manifests and other resources based on the API changes that accompany the new Kubernetes version --> - 升级{{< glossary_tooltip text="控制平面" term_id="control-plane" >}} - 升级集群中的节点 - 升级 {{< glossary_tooltip text="kubectl" term_id="kubectl" >}} 之类的客户端 - 根据新 Kubernetes 版本带来的 API 变化，调整清单文件和其他资源 ## {{% heading "prerequisites" %}} <!-- You must have an existing cluster. This page is about upgrading from Kubernetes {{< skew prevMinorVersion >}} to Kubernetes {{< skew latestVersion >}}. If your cluster is not currently running Kubernetes {{< skew prevMinorVersion >}} then please check the documentation for the version of Kubernetes that you plan to upgrade to. --> 你必须有一个集群。 本页内容涉及从 Kubernetes {{< skew prevMinorVersion >}} 升级到 Kubernetes {{< skew latestVersion >}}。 如果你的集群未运行 Kubernetes {{< skew prevMinorVersion >}}， 那请参考目标 Kubernetes 版本的文档。 <!-- ## Upgrade approaches --> ## 升级方法 {#upgrade-approaches} ### kubeadm {#upgrade-kubeadm} <!-- If your cluster was deployed using the `kubeadm` tool, refer to [Upgrading kubeadm clusters](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) for detailed information on how to upgrade the cluster. Once you have upgraded the cluster, remember to [install the latest version of `kubectl`](/docs/tasks/tools/install-kubectl/). --> 如果你的集群是使用 `kubeadm` 安装工具部署而来， 那么升级群集的详细信息，请参阅 [升级 kubeadm 集群](/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)。 升级集群之后，要记得 [安装最新版本的 `kubectl`](/zh/docs/tasks/tools/install-kubectl/). <!-- ### Manual deployments --> ### 手动部署 {#manual-deployments} <!-- These steps do not account for third-party extensions such as network and storage plugins. You should manually update the control plane following this sequence: --> {{< caution >}} 这些步骤不考虑第三方扩展，例如网络和存储插件。 {{< /caution >}} 你应该跟随下面操作顺序，手动更新控制平面： <!-- - etcd (all instances) - kube-apiserver (all control plane hosts) - kube-controller-manager - kube-scheduler - cloud controller manager, if you use one --> - etcd (所有实例) - kube-apiserver (所有控制平面的宿主机) - kube-controller-manager - kube-scheduler - cloud controller manager, 在你用到时 <!-- At this point you should [install the latest version of `kubectl`](/docs/tasks/tools/install-kubectl/). For each node in your cluster, [drain](/docs/tasks/administer-cluster/safely-drain-node/) that node and then either replace it with a new node that uses the {{< skew latestVersion >}} kubelet, or upgrade the {{< skew latestVersion >}} kubelet on that node and bring the node back into service. --> 现在，你应该 [安装最新版本的 `kubectl`](/zh/docs/tasks/tools/install-kubectl/). 对于群集中的每个节点， [排空](/zh/docs/tasks/administer-cluster/safely-drain-node/) 节点，然后，或者用一个运行了 {{< skew latestVersion >}} kubelet 的新节点替换它； 或者升级此节点的 kubelet，并使节点恢复服务。 <!-- ### Other deployments {#upgrade-other} Refer to the documentation for your cluster deployment tool to learn the recommended set up steps for maintenance. ## Post-upgrade tasks ### Switch your cluster's storage API version --> ### 其他部署方式 {#upgrade-other} 参阅你的集群部署工具对应的文档，了解用于维护的推荐设置步骤。 ## 升级后的任务 {#post-upgrade-tasks} ### 切换群集的存储 API 版本 {#switch-your-clusters-storage-api-version} <!-- The objects that are serialized into etcd for a cluster's internal representation of the Kubernetes resources active in the cluster are written using a particular version of the API. When the supported API changes, these objects may need to be rewritten in the newer API. Failure to do this will eventually result in resources that are no longer decodable or usable by the Kubernetes API server. For each affected object, fetch it using the latest supported API and then write it back also using the latest supported API. --> 对象序列化到 etcd，是为了提供集群中活动 Kubernetes 资源的内部表示法， 这些对象都使用特定版本的 API 编写。 当底层的 API 更改时，这些对象可能需要用新 API 重写。 如果不能做到这一点，会导致再也不能用 Kubernetes API 服务器解码、使用该对象。 对于每个受影响的对象，用最新支持的 API 获取它，然后再用最新支持的 API 写回来。 <!-- ### Update manifests Upgrading to a new Kubernetes version can provide new APIs. You can use `kubectl convert` command to convert manifests between different API versions. For example: --> ### 更新清单 {#update-manifests} 升级到新版本 Kubernetes 就可以提供新的 API。 你可以使用 `kubectl convert` 命令在不同 API 版本之间转换清单。 例如： ```shell kubectl convert -f pod.yaml --output-version v1 ``` <!-- The `kubectl` tool replaces the contents of `pod.yaml` with a manifest that sets `kind` to Pod (unchanged), but with a revised `apiVersion`. --> `kubectl` 替换了 `pod.yaml` 的内容， 在新的清单文件中，`kind` 被设置为 Pod（未变）， 但 `apiVersion` 则被修订了。 </ins>

Translate docs/tasks/administer-cluster/cluster-upgrade/ into Chinese /language zh /assign
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details


Question: title: Kubernetesを拡張する weight: 110 description: Kubernetesクラスターの挙動を変えるいろいろな方法 <ins> feature: title: 拡張性を考慮した設計 description: > アップストリームのソースコードを変更することなく、Kubernetesクラスターに機能を追加できます。 </ins> content_type: concept no_list: true ---

This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be enhanced? At feature section, Original K8s site contain 10 highlighted features and in "Ja" Localized version contain 9 highlighted features. That's the mismatch i wanted to address with this issue. ! !
/language ja /sig docs /area web-development
/assign
/assign
It looks no change on this issue for several months, so I remove the assignee. feel free to re-assign :) /unassign /unassign
/triage accepted
/assign
Target file: Japanese Localization document:
Thank you for your working!!


Question: ### PriorityLevelConfiguration <del> A PriorityLevelConfiguration represents a single isolation class. Each </del> <ins> A PriorityLevelConfiguration represents a single priority level. Each </ins> PriorityLevelConfiguration has an independent limit on the number of outstanding requests, and limitations on the number of queued requests.

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: Someone reading was not able to discern the intended meaning of the term "isolation class". See . This term is only used twice, and is used in a way that is synonymous with another term already introduced ("priority level"). I think it would be clearer to replace "isolation class" with "priority level". Proposed Solution: Replace "isolation class" with "priority level". Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--This has been there for a while. <!--Additional Information:--
/assign
/triage accepted
This is what I originally posted in the #api-priority-and-fairness Slack channel. Thanks for filing this on GitHub, Mike. !


Question: Machine | 머신 | manifest | 매니페스트 | Master | 마스터 | <del> max limit/request ratio | 최대 상한/요청량 비율 | </del> metadata | 메타데이터 | metric | 메트릭 | masquerading | 마스커레이딩 |

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: / . '' '' . English | -- | -- Default Limit | Default Request | max limit/request ratio | / Resource Limit | Proposed Solution: / '' '' , . LimitRange API yaml English -- -- Default Limit Default Request max limit/request ratio Resource Limit limit ResourceQuota, LimitRange request ResourceQuota, LimitRange Page to Update: - <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/language ko
/assign
. before : LimitRange after : ResourceQuota, LimitRange LimitRange ResourceQuota .