Question: <ins> --- title: IPv4/IPv6デュアルスタック feature: title: IPv4/IPv6デュアルスタック description: > IPv4およびIPv6のアドレスをPodとServiceに割り当てる content_type: concept weight: 70 --- <!-- overview --> {{< feature-state for_k8s_version="v1.16" state="alpha" >}} IPv4/IPv6デュアルスタックを利用すると、IPv4とIPv6のアドレスの両方を{{< glossary_tooltip text="Pod" term_id="pod" >}}および{{< glossary_tooltip text="Service" term_id="service" >}}に指定できるようになります。 KubernetesクラスターでIPv4/IPv6デュアルスタックのネットワークを有効にすれば、クラスターはIPv4とIPv6のアドレスの両方を同時に割り当てることをサポートするようになります。 <!-- body --> ## サポートされている機能 KubernetesクラスターでIPv4/IPv6デュアルスタックを有効にすると、以下の機能が提供されます。 * デュアルスタックのPodネットワーク(PodごとにIPv4とIPv6のアドレスが1つずつ割り当てられます) * IPv4およびIPv6が有効化されたService(各Serviceは1つのアドレスファミリーでなければなりません) * IPv4およびIPv6インターフェイスを経由したPodのクラスター外向きの(たとえば、インターネットへの)ルーティング ## 前提条件 IPv4/IPv6デュアルスタックのKubernetesクラスターを利用するには、以下の前提条件を満たす必要があります。 * Kubernetesのバージョンが1.16以降である * プロバイダーがデュアルスタックのネットワークをサポートしている(クラウドプロバイダーなどが、ルーティング可能なIPv4/IPv6ネットワークインターフェイスが搭載されたKubernetesを提供可能である) * ネットワークプラグインがデュアルスタックに対応している(KubenetやCalicoなど) ## IPv4/IPv6デュアルスタックを有効にする IPv4/IPv6デュアルスタックを有効にするには、クラスターの関連コンポーネントで`IPv6DualStack`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にして、デュアルスタックのクラスターネットワークの割り当てを以下のように設定します。 * kube-apiserver: * `--feature-gates="IPv6DualStack=true"` * kube-controller-manager: * `--feature-gates="IPv6DualStack=true"` * `--cluster-cidr=<IPv4 CIDR>,<IPv6 CIDR>` * `--service-cluster-ip-range=<IPv4 CIDR>,<IPv6 CIDR>` * `--node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6` デフォルトのサイズは、IPv4では/24、IPv6では/64です * kubelet: * `--feature-gates="IPv6DualStack=true"` * kube-proxy: * `--cluster-cidr=<IPv4 CIDR>,<IPv6 CIDR>` * `--feature-gates="IPv6DualStack=true"` {{< note >}} IPv4 CIDRの例: `10.244.0.0/16` (自分のクラスターのアドレス範囲を指定してください) IPv6 CIDRの例: `fdXY:IJKL:MNOP:15::/64` (これはフォーマットを示すための例であり、有効なアドレスではありません。詳しくは[RFC 4193](https://tools.ietf.org/html/rfc4193)を参照してください) {{< /note >}} ## Service クラスターでIPv4/IPv6デュアルスタックのネットワークを有効にした場合、IPv4またはIPv6のいずれかのアドレスを持つ{{< glossary_tooltip text="Service" term_id="service" >}}を作成できます。Serviceのcluster IPのアドレスファミリーは、Service上に`.spec.ipFamily`フィールドを設定することで選択できます。このフィールドを設定できるのは、新しいServiceの作成時のみです。`.spec.ipFamily`フィールドの指定はオプションであり、{{< glossary_tooltip text="Service" term_id="service" >}}と{{< glossary_tooltip text="Ingress" term_id="ingress" >}}でIPv4とIPv6を有効にする予定がある場合にのみ使用するべきです。このフィールドの設定は、[外向きのトラフィック](#egress-traffic)に対する要件には含まれません。 {{< note >}} クラスターのデフォルトのアドレスファミリーは、kube-controller-managerに`--service-cluster-ip-range`フラグで設定した、最初のservice cluster IPの範囲のアドレスファミリーです。 {{< /note >}} `.spec.ipFamily`は、次のいずれかに設定できます。 * `IPv4`: APIサーバーは`ipv4`の`service-cluster-ip-range`の範囲からIPアドレスを割り当てます * `IPv6`: APIサーバーは`ipv6`の`service-cluster-ip-range`の範囲からIPアドレスを割り当てます 次のServiceのspecには`ipFamily`フィールドが含まれていません。Kubernetesは、最初に設定した`service-cluster-ip-range`の範囲からこのServiceにIPアドレス(別名「cluster IP」)を割り当てます。 {{< codenew file="service/networking/dual-stack-default-svc.yaml" >}} 次のServiceのspecには`ipFamily`フィールドが含まれています。Kubernetesは、最初に設定した`service-cluster-ip-range`の範囲からこのServiceにIPv6のアドレス(別名「cluster IP」)を割り当てます。 {{< codenew file="service/networking/dual-stack-ipv6-svc.yaml" >}} 比較として次のServiceのspecを見ると、このServiceには最初に設定した`service-cluster-ip-range`の範囲からIPv4のアドレス(別名「cluster IP」)が割り当てられます。 {{< codenew file="service/networking/dual-stack-ipv4-svc.yaml" >}} ### Type LoadBalancer IPv6が有効になった外部ロードバランサーをサポートしているクラウドプロバイダーでは、`type`フィールドに`LoadBalancer`を指定し、`ipFamily`フィールドに`IPv6`を指定することにより、クラウドロードバランサーをService向けにプロビジョニングできます。 ## 外向きのトラフィック {#egress-traffic} パブリックおよび非パブリックでのルーティングが可能なIPv6アドレスのブロックを利用するためには、クラスターがベースにしている{{< glossary_tooltip text="CNI" term_id="cni" >}}プロバイダーがIPv6の転送を実装している必要があります。もし非パブリックでのルーティングが可能なIPv6アドレスを使用するPodがあり、そのPodをクラスター外の送信先(例:パブリックインターネット)に到達させたい場合、外向きのトラフィックと応答の受信のためにIPマスカレードを設定する必要があります。[ip-masq-agent](https://github.com/kubernetes-incubator/ip-masq-agent)はデュアルスタックに対応しているため、デュアルスタックのクラスター上でのIPマスカレードにはip-masq-agentが利用できます。 ## 既知の問題 * Kubenetは、IPv4,IPv6の順番にIPを報告することを強制します(--cluster-cidr) ## {{% heading "whatsnext" %}} * [IPv4/IPv6デュアルスタックのネットワークを検証する](/docs/tasks/network/validate-dual-stack) </ins>

This is a Feature Request What would you like to be Translate into Japanese. Why is this needed This page has not been translated. Comments /language ja /assign


Question: title: v1.18 Release Notes weight: 10 card: <del> name: download </del> <ins> name: release-notes </ins> weight: 20 anchors: - anchor: "#"

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: has a heading, “Download Kubernetes”. However, this heading isn't followed by a button labelled Download as you might expect. Instead, there are links to the release notes. Proposed Solution: Either: Rename the heading to “Release Notes”(?) or Add a button (maybe using a shortcode), Download, that links to (and set this up to be updated automatically when a new version is released). The button should be under the “Download Kubernetes” heading. or Add a button (maybe using a shortcode), Download, that links to The button should be under the “Download Kubernetes” heading. This will take readers to the right page but they will have to find the download links themselves. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--Kubernetes Version: v1.18 Additional Information: /language en
If we wanna go with either option 1 or option 3, I can help with that. Not sure what is the best way to automagically keep the link updated in option 2. Is there some Hugo site param that can be used for that?
let's go with a thing we can implement, and if someone (you? me?) feels strongly they can log a new issue to track the idea of making it even better.


Question: <ins> --- title: プルリクエストのレビュー content_type: concept main_menu: true weight: 10 --- <!-- overview --> ドキュメントのプルリクエストは誰でもレビューすることができます。Kubernetesのwebsiteリポジトリで[pull requests](https://github.com/kubernetes/website/pulls)のセクションに移動し、open状態のプルリクエストを確認してください。 ドキュメントのプルリクエストのレビューは、Kubernetesコミュニティに自分を知ってもらうためのよい方法の1つです。コードベースについて学んだり、他のコントリビューターとの信頼関係を築く助けともなるはずです。 レビューを行う前には、以下のことを理解しておくとよいでしょう。 - [コンテンツガイド](/docs/contribute/style/content-guide/)と[スタイルガイド](/docs/contribute/style/style-guide/)を読んで、有益なコメントを残せるようにする。 - Kubernetesのドキュメントコミュニティにおける[役割と責任](/docs/contribute/participate/roles-and-responsibilities/)の違いを理解する。 <!-- body --> ## はじめる前に レビューを始める前に、以下のことを心に留めてください。 - [CNCFの行動規範](https://github.com/cncf/foundation/blob/master/code-of-conduct.md)を読み、いかなる時にも行動規範にしたがって行動するようにする。 - 礼儀正しく、思いやりを持ち、助け合う気持ちを持つ。 - 変更点だけでなく、PRのポジティブな側面についてもコメントする。 - 相手の気持ちに共感して、自分のレビューが相手にどのように受け取られるのかをよく意識する。 - 相手の善意を前提として、疑問点を明確にする質問をする。 - 経験を積んだコントリビューターの場合、コンテンツに大幅な変更が必要な新規のコントリビューターとペアを組んで作業に取り組むことを考える。 ## レビューのプロセス 一般に、コンテンツや文体に対するプルリクエストは、英語でレビューを行います。 1.  [https://github.com/kubernetes/website/pulls](https://github.com/kubernetes/website/pulls)に移動します。Kubernetesのウェブサイトとドキュメントに対するopen状態のプルリクエスト一覧が表示されます。 2.  open状態のPRに、以下に示すラベルを1つ以上使って絞り込みます。 - `cncf-cla: yes` (推奨): CLAにサインしていないコントリビューターが提出したPRはマージできません。詳しい情報は、[CLAの署名](/docs/contribute/new-content/overview/#sign-the-cla)を読んでください。 - `language/en` (推奨): 英語のPRだけに絞り込みます。 - `size/<size>`: 特定の大きさのPRだけに絞り込みます。レビューを始めたばかりの人は、小さなPRから始めてください。 さらに、PRがwork in progressとしてマークされていないことも確認してください。`work in progress`ラベルの付いたPRは、まだレビューの準備ができていない状態です。 3.  レビューするPRを選んだら、以下のことを行い、変更点について理解します。 - PRの説明を読み、行われた変更について理解し、関連するissueがあればそれも読みます。 - 他のレビュアのコメントがあれば読みます。 - **Files changed**タブをクリックし、変更されたファイルと行を確認します。 - **Conversation**タブの下にあるPRのbuild checkセクションまでスクロールし、**deploy/netlify**の行の**Details**リンクをクリックして、Netlifyのプレビュービルドで変更点をプレビューします。 4.  **Files changed**タブに移動してレビューを始めます。 1. コメントしたい場合は行の横の`+`マークをクリックします。 2. その行に関するコメントを書き、**Add single comment**(1つのコメントだけを残したい場合)または**Start a review**(複数のコメントを行いたい場合)のいずれかをクリックします。 3. コメントをすべて書いたら、ページ上部の**Review changes**をクリックします。ここでは、レビューの要約を追加できます(コントリビューターにポジティブなコメントも書きましょう！)。必要に応じて、PRを承認したり、コメントしたり、変更をリクエストします。新しいコントリビューターの場合は**Comment**だけが行えます。 ## レビューのチェックリスト レビューするときは、最初に以下の点を確認してみてください。 ### 言語と文法 - 言語や文法に明らかな間違いはないですか？ もっとよい言い方はないですか？ - もっと簡単な単語に置き換えられる複雑な単語や古い単語はありませんか？ - 使われている単語や専門用語や言い回しで差別的ではない別の言葉に置き換えられるものはありませんか？ - 言葉選びや大文字の使い方は[style guide](/docs/contribute/style/style-guide/)に従っていますか？ - もっと短くしたり単純な文に書き換えられる長い文はありませんか？ - 箇条書きやテーブルでもっとわかりやすく表現できる長いパラグラフはありませんか？ ### コンテンツ - 同様のコンテンツがKubernetesのサイト上のどこかに存在しませんか？ - コンテンツが外部サイト、特定のベンダー、オープンソースではないドキュメントなどに過剰にリンクを張っていませんか？ ### ウェブサイト - PRはページ名、slug/alias、アンカーリンクの変更や削除をしていますか？ その場合、このPRの変更の結果、リンク切れは発生しませんか？ ページ名を変更してslugはそのままにするなど、他の選択肢はありませんか？ - PRは新しいページを作成するものですか？ その場合、次の点に注意してください。 - ページは正しい[page content type](/docs/contribute/style/page-content-types/)と関係するHugoのshortcodeを使用していますか？ - セクションの横のナビゲーション(または全体)にページは正しく表示されますか？ - ページは[Docs Home](/docs/home/)に一覧されますか？ - Netlifyのプレビューで変更は確認できますか？ 特にリスト、コードブロック、テーブル、備考、画像などに注意してください。 ### その他 PRに関して誤字や空白などの小さな問題を指摘する場合は、コメントの前に`nit:`と書いてください。こうすることで、PRの作者は問題が深刻なものではないことが分かります。 </ins>

This is a Feature Request What would you like to be Translate into Japanese. Why is this needed This page has not been translated. Comments /language ja /assign
/triage accepted
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-contributor-experience at . /lifecycle stale
/remove-lifecycle stale


Question:
While mainly a C++ and Java shop, Amadeus also wanted to be able to adopt new technologies more easily. Some of its developers had started using languages like Python and databases like Couchbase, but Mountain wanted still more options, he says, "in order to better adapt our technical solutions to the products we offer, and open up entirely new possibilities to our developers." Working with recent technologies and cool new things would also make it easier to attract new talent.

All of those needs led Mountain and his team on a search for a new platform. "We did a set of studies and proofs of concept over a fairly short period, and we considered many technologies," he says. "In the end, we were left with three choices: build everything on premise, build on top of Kubernetes whatever happens to be missing from our point of view, or go with OpenShift and build whatever remains there."

All of those needs led Mountain and his team on a search for a new platform. "We did a set of studies and proofs of concept over a fairly short period, and we considered many technologies," he says. "In the end, we were left with three choices: build everything on premise, build on top of Kubernetes whatever happens to be missing from our point of view, or go with OpenShift and build whatever remains there."

The team decided against building everything themselves—though they'd done that sort of thing in the past—because "people were already inventing things that looked good," says Mountain.

to /assign
Page related to issue: /language en
/retitle Update hyperlinks in 'Amadeus Case Study' page to utilize HTTPS instead of HTTP
Which is the page we should fix?
/triage accepted


Question: 容器漏洞扫描和操作系统依赖安全性 | 作为镜像构建的一部分，您应该扫描您的容器里的已知漏洞。 镜像签名和执行 | 对容器镜像进行签名，以维护对容器内容的信任。 禁止特权用户 | 构建容器时，请查阅文档以了解如何在具有最低操作系统特权级别的容器内部创建用户，以实现容器的目标。 <ins> 使用带有较强隔离能力的容器运行时 | 选择提供较强隔离能力的[容器运行时类](/zh/docs/concepts/containers/runtime-class/)。 </ins> <!-- ## Code

! Chinese page link can not open
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
/assign
/kind bug


Question: kubectl proxy -p 8001 ``` <del> Then, you can access urls like ```http://127.0.0.1:8001/api/v1/namespaces/kube-system/services/kube-ui/proxy/``` without the need for client certificates in your browser. </del> <ins> Then, you can access urls like ```http://127.0.0.1:8001/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy/``` without the need for client certificates in your browser. </ins> ## What Kubernetes features do not work on CenturyLink Cloud

Connect with Proxies references kube ui. It should use the kube dashboard instead.
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. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale


Question: ?()      | filter             | {.users[?(@.name=="e2e")].user.password} | secret range, end | iterate list | {range .items[*]}[{.metadata.name}, {.status.capacity}] {end} | [127.0.0.1, map[cpu:4]] [127.0.0.2, map[cpu:8]] ""       | quote interpreted string | {range .items[*]}{.metadata.name}{"t"}{end} | 127.0.0.1    127.0.0.2 <ins> Below are some examples using jsonpath: ```shell $ kubectl get pods -o json $ kubectl get pods -o=jsonpath='{@}' $ kubectl get pods -o=jsonpath='{.items[0]}' $ kubectl get pods -o=jsonpath='{.items[0].metadata.name}' $ kubectl get pods -o=jsonpath='{range .items[*]}{.metadata.name}{"t"}{.status.startTime}{"n"}{end}' ``` </ins>

<!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!--Required Information--This is a... <!-- choose one by changing [ ] to [x] --- [x] Feature Request [ ] Bug Report Problem: No examples Proposed Solution: Add this text: Here's a small example of how to see the structure of data and how to select some parts of it using jsonpaths Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
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. Prevent issues from auto-closing with an comment. 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 /assign


Question: In cases when objects represent a physical entity, like a Node representing a physical host, when the host is re-created under the same name without deleting and re-creating the Node, Kubernetes treats the new host as the old one, which may lead to inconsistencies. {{< /note >}} <del> Below are three types of commonly used name constraints for resources. </del> <ins> Below are four types of commonly used name constraints for resources. </ins> ### DNS Subdomain Names

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: Pod / Service names can not start with an alphanumeric character in kubernetes, but should be possible according to RFC1123 Proposed Solution: Change documentation in sections and to: or change kubernetes name check to use the specification in RFC1123. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--Kubernetes Version: 19.11 <!--Additional Information:--
Kubernetes does not strictly follow the RFC.
this might be true, but the documentation says otherwise. eg.
According to the validation logic, starting with alphanumeric characters should be okay. Can you paste the error message you have got?
I tried locally, and getting this error !
Just double checked the validation logic for core v1 Service. Its name must be a RFC1035 label rather than a RFC1123 label. This is something we need to fix in the docs. Related code:
/triage accepted /kind bug /assign


Question: ... resources: {} ... <ins> status: </ins> qosClass: BestEffort ```

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 location of qosClass is not correct in the last example, which is a result of the following command: Proposed Solution: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/kind bug /language en /priority backlog /sig scheduling
/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 : /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


Question: <ins> --- title: 为 Windows Pod 和容器配置 GMSA content_type: task weight: 20 --- <!-- title: Configure GMSA for Windows Pods and containers content_type: task weight: 20 --> <!-- overview --> {{< feature-state for_k8s_version="v1.18" state="stable" >}} <!-- This page shows how to configure [Group Managed Service Accounts](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview) (GMSA) for Pods and containers that will run on Windows nodes. Group Managed Service Accounts are a specific type of Active Directory account that provides automatic password management, simplified service principal name (SPN) management, and the ability to delegate the management to other administrators across multiple servers. --> 本页展示如何为将运行在 Windows 节点上的 Pod 和容器配置 [组管理的服务账号（Group Managed Service Accounts，GMSA）](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview)。 组管理的服务账号是活动目录（Active Directory）的一种特殊类型，提供自动化的 密码管理、简化的服务主体名称（Service Principal Name，SPN）管理以及跨多个 服务器将管理操作委派给其他管理员等能力。 <!-- In Kubernetes, GMSA credential specs are configured at a Kubernetes cluster-wide scope as Custom Resources. Windows Pods, as well as individual containers within a Pod, can be configured to use a GMSA for domain based functions (e.g. Kerberos authentication) when interacting with other Windows services. As of v1.16, the Docker runtime supports GMSA for Windows workloads. --> 在 Kubernetes 环境中，GMSA 凭据规约配置为 Kubernetes 集群范围的自定义资源 （Custom Resources）形式。Windows Pod 以及各 Pod 中的每个容器可以配置为 使用 GMSA 来完成基于域（Domain）的操作（例如，Kerberos 身份认证），以便 与其他 Windows 服务相交互。自 Kubernetes 1.16 版本起，Docker 运行时为 Windows 负载支持 GMSA。 ## {{% heading "prerequisites" %}} <!-- You need to have a Kubernetes cluster and the `kubectl` command-line tool must be configured to communicate with your cluster. The cluster is expected to have Windows worker nodes. This section covers a set of initial steps required once for each cluster: --> 你需要一个 Kubernetes 集群，以及 `kubectl` 命令行工具，且工具必须已配置 为能够与你的集群通信。集群预期包含 Windows 工作节点。 本节讨论需要为每个集群执行一次的初始操作。 <!-- ### Install the GMSACredentialSpec CRD A [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)(CRD) for GMSA credential spec resources needs to be configured on the cluster to define the custom resource type `GMSACredentialSpec`. Download the GMSA CRD [YAML](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/gmsa-crd.yml) and save it as gmsa-crd.yaml. Next, install the CRD with `kubectl apply -f gmsa-crd.yaml` --> ### 安装 GMSACredentialSpec CRD 你需要在集群上配置一个用于 GMSA 凭据规约资源的 [CustomResourceDefinition](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)(CRD)， 以便定义类型为 `GMSACredentialSpec` 的自定义资源。 首先下载 GMSA CRD [YAML](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/gmsa-crd.yml) 并将其保存为 `gmsa-crd.yaml`。接下来执行 `kubectl apply -f gmsa-crd.yaml` 安装 CRD。 <!-- ### Install webhooks to validate GMSA users Two webhooks need to be configured on the Kubernetes cluster to populate and validate GMSA credential spec references at the Pod or container level: 1. A mutating webhook that expands references to GMSAs (by name from a Pod specification) into the full credential spec in JSON form within the Pod spec. 1. A validating webhook ensures all references to GMSAs are authorized to be used by the Pod service account. --> ### 安装 Webhook 来验证 GMSA 用户 你需要为 Kubernetes 集群配置两个 Webhook，在 Pod 或容器级别填充和检查 GMSA 凭据规约引用。 1. 一个修改模式（Mutating）的 Webhook，将对 GMSA 的引用（在 Pod 规约中体现为名字） 展开为完整凭据规约的 JSON 形式，并保存回 Pod 规约中。 1. 一个验证模式（Validating）的 Webhook，确保对 GMSA 的所有引用都是已经授权 给 Pod 的服务账号使用的。 <!-- Installing the above webhooks and associated objects require the steps below: 1. Create a certificate key pair (that will be used to allow the webhook container to communicate to the cluster) 1. Install a secret with the certificate from above. 1. Create a deployment for the core webhook logic. 1. Create the validating and mutating webhook configurations referring to the deployment. --> 安装以上 Webhook 及其相关联的对象需要执行以下步骤： 1. 创建一个证书密钥对（用于允许 Webhook 容器与集群通信） 1. 安装一个包含如上证书的 Secret 1. 创建一个包含核心 Webhook 逻辑的 Deployment 1. 创建引用该 Deployment 的 Validating Webhook 和 Mutating Webhook 配置 <!-- A [script](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/deploy-gmsa-webhook.sh) can be used to deploy and configure the GMSA webhooks and associated objects mentioned above. The script can be run with a `-dry-run=server` option to allow you to review the changes that would be made to your cluster. The [YAML template](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/gmsa-webhook.yml.tpl) used by the script may also be used to deploy the webhooks and associated objects manually (with appropriate substitutions for the parameters) --> 你可以使用[这个脚本](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/deploy-gmsa-webhook.sh) 来部署和配置上述 GMSA Webhook 及相关联的对象。你还可以在运行脚本时设置 `--dry-run=server` 选项以便审查脚本将会对集群做出的变更。 脚本所使用的[YAML 模板](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/gmsa-webhook.yml.tpl) 也可用于手动部署 Webhook 及相关联的对象，不过需要对其中的参数作适当替换。 <!-- steps --> <!-- ## Configure GMSAs and Windows nodes in Active Directory Before Pods in Kubernetes can be configured to use GMSAs, the desired GMSAs need to be provisioned in Active Directory as described in the [Windows GMSA documentation](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts#BKMK_Step1). Windows worker nodes (that are part of the Kubernetes cluster) need to be configured in Active Directory to access the secret credentials associated with the desired GMSA as described in the [Windows GMSA documentation](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts#to-add-member-hosts-using-the-set-adserviceaccount-cmdlet) --> ## 在活动目录中配置 GMSA 和 Windows 节点 在配置 Kubernetes 中的 Pod 以使用 GMSA 之前，需要按 [Windows GMSA 文档](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts#BKMK_Step1) 中描述的那样先在活动目录中准备好期望的 GMSA。 Windows 工作节点（作为 Kubernetes 集群的一部分）需要被配置到活动目录中，以便 访问与期望的 GSMA 相关联的秘密凭据数据。这一操作的描述位于 [Windows GMSA 文档](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts#to-add-member-hosts-using-the-set-adserviceaccount-cmdlet) 中。 <!-- ## Create GMSA credential spec resources With the GMSACredentialSpec CRD installed (as described earlier), custom resources containing GMSA credential specs can be configured. The GMSA credential spec does not contain secret or sensitive data. It is information that a container runtime can use to describe the desired GMSA of a container to Windows. GMSA credential specs can be generated in YAML format with a utility [PowerShell script](https://github.com/kubernetes-sigs/windows-gmsa/tree/master/scripts/GenerateCredentialSpecResource.ps1). --> ## 创建 GMSA 凭据规约资源 当（如前所述）安装了 GMSACredentialSpec CRD 之后，你就可以配置包含 GMSA 凭据 规约的自定义资源了。GMSA 凭据规约中并不包含秘密或敏感数据。 其中包含的信息主要用于容器运行时，便于后者向 Windows 描述容器所期望的 GMSA。 GMSA 凭据规约可以使用 [PowerShell 脚本](https://github.com/kubernetes-sigs/windows-gmsa/tree/master/scripts/GenerateCredentialSpecResource.ps1) 以 YAML 格式生成。 <!-- Following are the steps for generating a GMSA credential spec YAML manually in JSON format and then converting it: 1. Import the CredentialSpec [module](https://github.com/MicrosoftDocs/Virtualization-Documentation/blob/live/windows-server-container-tools/ServiceAccounts/CredentialSpec.psm1): `ipmo CredentialSpec.psm1` 1. Create a credential spec in JSON format using `New-CredentialSpec`. To create a GMSA credential spec named WebApp1, invoke `New-CredentialSpec -Name WebApp1 -AccountName WebApp1 -Domain $(Get-ADDomain -Current LocalComputer)` 1. Use `Get-CredentialSpec` to show the path of the JSON file. 1. Convert the credspec file from JSON to YAML format and apply the necessary header fields `apiVersion`, `kind`, `metadata` and `credspec` to make it a GMSACredentialSpec custom resource that can be configured in Kubernetes. --> 下面是手动以 JSON 格式生成 GMSA 凭据规约并对其进行 YAML 转换的步骤： 1. 导入 CredentialSpec [模块](https://github.com/MicrosoftDocs/Virtualization-Documentation/blob/live/windows-server-container-tools/ServiceAccounts/CredentialSpec.psm1): `ipmo CredentialSpec.psm1` 1. 使用 `New-CredentialSpec` 来创建一个 JSON 格式的凭据规约。 要创建名为 `WebApp1` 的 GMSA 凭据规约，调用 `New-CredentialSpec -Name WebApp1 -AccountName WebApp1 -Domain $(Get-ADDomain -Current LocalComputer)`。 1. 使用 `Get-CredentialSpec` 来显示 JSON 文件的路径。 1. 将凭据规约从 JSON 格式转换为 YAML 格式，并添加必要的头部字段 `apiVersion`、`kind`、`metadata` 和 `credspec`，使其成为一个可以在 Kubernetes 中配置的 GMSACredentialSpec 自定义资源。 <!-- The following YAML configuration describes a GMSA credential spec named `gmsa-WebApp1`: ```yaml apiVersion: windows.k8s.io/v1alpha1 kind: GMSACredentialSpec metadata: name: gmsa-WebApp1  #This is an arbitrary name but it will be used as a reference credspec: ActiveDirectoryConfig: GroupManagedServiceAccounts: - Name: WebApp1   #Username of the GMSA account Scope: CONTOSO  #NETBIOS Domain Name - Name: WebApp1   #Username of the GMSA account Scope: contoso.com #DNS Domain Name CmsPlugins: - ActiveDirectory DomainJoinConfig: DnsName: contoso.com  #DNS Domain Name DnsTreeName: contoso.com #DNS Domain Name Root Guid: 244818ae-87ac-4fcd-92ec-e79e5252348a  #GUID MachineAccountName: WebApp1 #Username of the GMSA account NetBiosName: CONTOSO  #NETBIOS Domain Name Sid: S-1-5-21-2126449477-2524075714-3094792973 #SID of GMSA ``` --> 下面的 YAML 配置描述的是一个名为 `gmsa-WebApp1` 的 GMSA 凭据规约： ```yaml apiVersion: windows.k8s.io/v1alpha1 kind: GMSACredentialSpec metadata: name: gmsa-WebApp1  # 这是随意起的一个名字，将用作引用 credspec: ActiveDirectoryConfig: GroupManagedServiceAccounts: - Name: WebApp1   # GMSA 账号的用户名 Scope: CONTOSO  # NETBIOS 域名 - Name: WebApp1   # GMSA 账号的用户名 Scope: contoso.com # DNS 域名 CmsPlugins: - ActiveDirectory DomainJoinConfig: DnsName: contoso.com  # DNS 域名 DnsTreeName: contoso.com # DNS 域名根 Guid: 244818ae-87ac-4fcd-92ec-e79e5252348a  # GUID MachineAccountName: WebApp1 # GMSA 账号的用户名 NetBiosName: CONTOSO  # NETBIOS 域名 Sid: S-1-5-21-2126449477-2524075714-3094792973 # GMSA 的 SID ``` <!-- The above credential spec resource may be saved as `gmsa-Webapp1-credspec.yaml` and applied to the cluster using: `kubectl apply -f gmsa-Webapp1-credspec.yml` --> 上面的凭据规约资源可以保存为 `gmsa-Webapp1-credspec.yaml`，之后使用 `kubectl apply -f gmsa-Webapp1-credspec.yml` 应用到集群上。 <!-- ## Configure cluster role to enable RBAC on specific GMSA credential specs A cluster role needs to be defined for each GMSA credential spec resource. This authorizes the `use` verb on a specific GMSA resource by a subject which is typically a service account. The following example shows a cluster role that authorizes usage of the `gmsa-WebApp1` credential spec from above. Save the file as gmsa-webapp1-role.yaml and apply using `kubectl apply -f gmsa-webapp1-role.yaml` --> ## 配置集群角色以启用对特定 GMSA 凭据规约的 RBAC 你需要为每个 GMSA 凭据规约资源定义集群角色。 该集群角色授权某主体（通常是一个服务账号）对特定的 GMSA 资源执行 `use` 动作。 下面的示例显示的是一个集群角色，对前文创建的凭据规约 `gmsa-WebApp1` 执行鉴权。 将此文件保存为 `gmsa-webapp1-role.yaml` 并执行 `kubectl apply -f gmsa-webapp1-role.yaml`。 <!-- ```yaml #Create the Role to read the credspec apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: webapp1-role rules: - apiGroups: ["windows.k8s.io"] resources: ["gmsacredentialspecs"] verbs: ["use"] resourceNames: ["gmsa-WebApp1"] ``` --> ```yaml # 创建集群角色读取凭据规约 apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: webapp1-role rules: - apiGroups: ["windows.k8s.io"] resources: ["gmsacredentialspecs"] verbs: ["use"] resourceNames: ["gmsa-WebApp1"] ``` <!-- ## Assign role to service accounts to use specific GMSA credspecs A service account (that Pods will be configured with) needs to be bound to the cluster role create above. This authorizes the service account to use the desired GMSA credential spec resource. The following shows the default service account being bound to a cluster role `webapp1-role` to use `gmsa-WebApp1` credential spec resource created above. --> ## 将角色指派给要使用特定 GMSA 凭据规约的服务账号 你需要将某个服务账号（Pod 配置所对应的那个）绑定到前文创建的集群角色上。 这一绑定操作实际上授予该服务账号使用所指定的 GMSA 凭据规约资源的访问权限。 下面显示的是一个绑定到集群角色 `webapp1-role` 上的 default 服务账号，使之 能够使用前面所创建的 `gmsa-WebApp1` 凭据规约资源。 ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: allow-default-svc-account-read-on-gmsa-WebApp1 namespace: default subjects: - kind: ServiceAccount name: default namespace: default roleRef: kind: ClusterRole name: webapp1-role apiGroup: rbac.authorization.k8s.io ``` <!-- ## Configure GMSA credential spec reference in Pod spec The Pod spec field `securityContext.windowsOptions.gmsaCredentialSpecName` is used to specify references to desired GMSA credential spec custom resources in Pod specs. This configures all containers in the Pod spec to use the specified GMSA. A sample Pod spec with the annotation populated to refer to `gmsa-WebApp1`: --> ## 在 Pod 规约中配置 GMSA 凭据规约引用 Pod 规约字段 `securityContext.windowsOptions.gmsaCredentialSpecName` 可用来 设置对指定 GMSA 凭据规约自定义资源的引用。 设置此引用将会配置 Pod 中的所有容器使用所给的 GMSA。 下面是一个 Pod 规约示例，其中包含了对 `gmsa-WebApp1` 凭据规约的引用： ```yaml apiVersion: apps/v1 kind: Deployment metadata: labels: run: with-creds name: with-creds namespace: default spec: replicas: 1 selector: matchLabels: run: with-creds template: metadata: labels: run: with-creds spec: securityContext: windowsOptions: gmsaCredentialSpecName: gmsa-webapp1 containers: - image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019 imagePullPolicy: Always name: iis nodeSelector: kubernetes.io/os: windows ``` <!-- Individual containers in a Pod spec can also specify the desired GMSA credspec using a per-container `securityContext.windowsOptions.gmsaCredentialSpecName` field. For example: --> Pod 中的各个容器也可以使用对应容器的 `securityContext.windowsOptions.gmsaCredentialSpecName` 字段来设置期望使用的 GMSA 凭据规约。 例如： ```yaml apiVersion: apps/v1 kind: Deployment metadata: labels: run: with-creds name: with-creds namespace: default spec: replicas: 1 selector: matchLabels: run: with-creds template: metadata: labels: run: with-creds spec: containers: - image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019 imagePullPolicy: Always name: iis securityContext: windowsOptions: gmsaCredentialSpecName: gmsa-Webapp1 nodeSelector: kubernetes.io/os: windows ``` <!-- As Pod specs with GMSA fields populated (as described above) are applied in a cluster, the following sequence of events take place: 1. The mutating webhook resolves and expands all references to GMSA credential spec resources to the contents of the GMSA credential spec. 1. The validating webhook ensures the service account associated with the Pod is authorized for the `use` verb on the specified GMSA credential spec. 1. The container runtime configures each Windows container with the specified GMSA credential spec so that the container can assume the identity of the GMSA in Active Directory and access services in the domain using that identity. --> 当 Pod 规约中填充了 GMSA 相关字段（如上所述），在集群中应用 Pod 规约时会依次 发生以下事件： 1. Mutating Webhook 解析对 GMSA 凭据规约资源的引用，并将其全部展开， 得到 GMSA 凭据规约的实际内容。 1. Validating Webhook 确保与 Pod 相关联的服务账号有权在所给的 GMSA 凭据规约 上执行 `use` 动作。 1. 容器运行时为每个 Windows 容器配置所指定的 GMSA 凭据规约，这样容器就可以以 活动目录中该 GMSA 所代表的身份来执行操作，使用该身份来访问域中的服务。 <!-- ## Troubleshooting If you are having difficulties getting GMSA to work in your environment, there are a few troubleshooting steps you can take. --> ## 故障排查 如果在你的环境中配置 GMSA 时遇到了困难，你可以采取若干步骤来排查可能 的故障。 <!-- First, make sure the credspec has been passed to the Pod.  To do this you will need to `exec` into one of your Pods and check the output of the `nltest.exe /parentdomain` command.  In the example below the Pod did not get the credspec correctly: --> 首先，确保凭据规约已经被传递到 Pod。要实现这点，你需要先通过 `exec` 进入到 你的 Pod 之一，检查 `nltest.exe /parentdomain` 命令的输出。 在下面的例子中，Pod 未能正确地获得凭据规约： ```shell kubectl exec -it iis-auth-7776966999-n5nzr powershell.exe Windows PowerShell Copyright (C) Microsoft Corporation. All rights reserved. PS C:> nltest.exe /parentdomain Getting parent domain failed: Status = 1722 0x6ba RPC_S_SERVER_UNAVAILABLE PS C:> ``` <!-- If your Pod did get the credspec correctly, then next check communication with the domain.  First, from inside of your Pod, quickly do an nslookup to find the root of your domain. This will tell us 3 things: 1. The Pod can reach the DC 1. The DC can reach the Pod 1. DNS is working correctly. --> 如果 Pod 未能正确获得凭据规约，则下一步就要检查与域之间的通信。 首先，从 Pod 内部快速执行一个 nslookup 操作，找到域根。 这一操作会告诉我们三件事情： 1. Pod 能否访问域控制器（DC） 1. DC 能否访问 Pod 1. DNS 是否正常工作 <!-- If the DNS and communication test passes, next you will need to check if the Pod has established secure channel communication with the domain.  To do this, again, `exec` into your Pod and run the `nltest.exe /query` command. --> 如果 DNS 和通信测试通过，接下来你需要检查是否 Pod 已经与域之间建立了 安全通信通道。要执行这一检查，你需要再次通过 `exec` 进入到你的 Pod 中 并执行 `nltest.exe /query` 命令。 ```shell PS C:> nltest.exe /query I_NetLogonControl failed: Status = 1722 0x6ba RPC_S_SERVER_UNAVAILABLE ``` <!-- This tells us that for some reason, the Pod was unable to logon to the domain using the account specified in the credspec.  You can try to repair the secure channel by running the `nltest.exe /sc_reset:domain.example` command. --> 这一输出告诉我们，由于某些原因，Pod 无法使用凭据规约中的账号登录到域。 你可以通过运行 `nltest.exe /sc_reset:domain.example` 命令尝试修复安全通道。 ```shell PS C:> nltest /sc_reset:domain.example Flags: 30 HAS_IP  HAS_TIMESERV Trusted DC Name dc10.domain.example Trusted DC Connection Status Status = 0 0x0 NERR_Success The command completed successfully PS C:> ``` <!-- If the above command corrects the error, you can automate the step by adding the following lifecycle hook to your Pod spec.  If it did not correct the error, you will need to examine your credspec again and confirm that it is correct and complete. --> 如果上述命令修复了错误，你就可以通过向你的 Pod 规约添加生命周期回调来将此操作 自动化。如果上述命令未能奏效，你就需要再次检查凭据规约，以确保其数据时正确的 而且是完整的。 ```yaml image: registry.domain.example/iis-auth:1809v1 lifecycle: postStart: exec: command: ["powershell.exe","-command","do { Restart-Service -Name netlogon } while ( $($Result = (nltest.exe /query); if ($Result -like '*0x0 NERR_Success*') {return $true} else {return $false}) -eq $false)"] imagePullPolicy: IfNotPresent ``` <!-- If you add the `lifecycle` section show above to your Pod spec, the Pod will execute the commands listed to restart the `netlogon` service until the `nltest.exe /query` command exits without error. --> 如果你向你的 Pod 规约中添加如上所示的 `lifecycle` 节，则 Pod 会自动执行所 列举的命令来重启 `netlogon` 服务，直到 `nltest.exe /query` 命令返回时没有错误信息。 <!-- ## GMSA limitations When using the [ContainerD runtime for Windows](/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#cri-containerd) accessing restricted network shares via the GMSA domain identity fails. The container will recieve the identity of and calls from `nltest.exe /query` will work.  It is recommended to use the [Docker EE runtime](/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#docker-ee) if access to network shares is required.  The Windows Server team is working on resolving the issue in the Windows Kernel and will release a patch to resolve this issue in the future. Look for updates on the [Microsoft Windows Containers issue tracker](https://github.com/microsoft/Windows-Containers/issues/44). --> ## GMSA 的局限 在使用 [Windows 版本的 ContainerD 运行时](/zh/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#cri-containerd) 时，通过 GMSA 域身份标识访问受限制的网络共享资源时会出错。 容器会收到身份标识且 `nltest.exe /query` 调用也能正常工作。 当需要访问网络共享资源时，建议使用 [Docker EE 运行时](/zh/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#docker-ee)。 Windows Server 团队正在 Windows 内核中解决这一问题，并在将来发布解决此问题的补丁。 你可以在 [Microsoft Windows Containers 问题跟踪列表](https://github.com/microsoft/Windows-Containers/issues/44) 中查找这类更新。 </ins>

/language zh /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 : /language zh /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
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: The pod index is available in the {{< glossary_tooltip text="annotation" term_id="annotation" >}} `batch.kubernetes.io/job-completion-index` as a string representing its decimal value. In order for the containerized task process to obtain this index, <del> you can publish the value of the annotation using the [downward API](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#the-downward-api) </del> <ins> you can publish the value of the annotation using the [downward API](/docs/concepts/workloads/pods/downward-api/) </ins> mechanism. For convenience, the control plane automatically sets the downward API to expose the index in the `JOB_COMPLETION_INDEX` environment variable.

This is a Bug Report <!--Required Information--Problem: The link is dead. The content from the section seems moved into top of the document and glossary in . Proposed Solution: remove fragment from the link change link to or Page to Update: /docs/concepts/workloads/pods/downward-api /docs/tasks/inject-data-application/downward-api-volume-expose-pod-information /docs/tasks/job/indexed-parallel-processing-static
/assign
/language en /triage accepted /help We should find existing hyperlinks to and replace those with links to
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 : /language en /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
/unassign As has already opened a PR
/assign
GitHub didn't allow me to assign the following users: hs0210. 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 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: {{< kat-button >}} <del> {{< note >}}If you installed Minikube locally, run `minikube start`.{{< /note >}} </del> <ins> {{< note >}} If you installed Minikube locally, run `minikube start`. {{< /note >}} </ins> 2. Open the Kubernetes dashboard in a browser:

This is a Bug Report <!--Required Information--Problem: Text formatting issue under the Create a Minikube cluster heading. The text is listed erroneously (this appears to be a simple authoring/build issue with the content. Proposed Solution: Fix the typo or the build issue for this section of the page. Page to Update:
/labels language/en /assign
Relevant to issue
/language en /kind bug /priority important-longterm


Question: <ins> --- title: 가비지(Garbage) 수집 id: garbage-collection date: 2022-01-14 full_link: /ko/docs/concepts/architecture/garbage-collection/ short_description: > 쿠버네티스가 클러스터 자원을 정리하기 위해 사용하는 다양한 방법을 종합한 용어이다. aka: tags: - fundamental - operation --- 쿠버네티스가 클러스터 자원을 정리하기 위해 사용하는 다양한 방법을 종합한 용어이다. <!--more--> 쿠버네티스는 [사용되지 않는 컨테이너와 이미지](/ko/docs/concepts/architecture/garbage-collection/#containers-images), [실패한 파드](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection), [타겟 리소스가 소유한 오브젝트](/docs/concepts/overview/working-with-objects/owners-dependents/), [종료된 잡](/ko/docs/concepts/workloads/controllers/ttlafterfinished/), 그리고 만료되거나 실패한 리소스를 정리하기 위해 가비지 수집을 사용한다. </ins>

This is a Feature Request Translate in Korean What would you like to be Translate in Korean Why is this needed This file is not translated yet. Comments Page to translate : /language ko /assign Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --
/triage accepted
Resolved by page: /close
Closing this issue. <detailsIn response to : Resolved by 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: hello-world-2895499144-o4z13 ...  10.0.1.7   gke-cluster-1-default-pool-e0b8d269-1afc hello-world-2895499144-segjf ...  10.0.2.5   gke-cluster-1-default-pool-e0b8d269-cpuc <del> 1. Use the external IP address to access the Hello World application: </del> <ins> 1. Use the external IP address (`LoadBalancer Ingress`) to access the Hello World application: </ins> curl http://<external-ip>:<port> <del> where `<external-ip>` is the external IP address of your Service, and `<port>` is the value of `Port` in your Service description. </del> <ins> where `<external-ip>` is the external IP address (`LoadBalancer Ingress`) of your Service, and `<port>` is the value of `NodePort` in your Service description. If you are using minikube, typing `minikube service my-service` will automatically open the Hello World application in a browser. </ins> The response to a successful request is a hello message:

This is a Bug Report Problem: does not have correct instructions. Proposed Solution: In , Make a note of the external IP address exposed by your service should be Make a note of the external IP address () exposed by your service Also note the value of Port. In this example, the port is 8080 should be Also note the value of and . In this example, the port is 8080 and NodePort is Use the external IP address to access the Hello World application should be Use the external IP address () to access the Hello World application where is the external IP address of your Service, and is the value of in your Service description should be where is the external IP address () of your Service, and is the value of in your Service description. If you are using minukube, typing will automatically open the Hello World application in a browser. Page to Update: Kubernetes Version: Additional Information: These corrections will really help new k8s/minikube users. Thanks!
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. Prevent issues from auto-closing with an comment. 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 /assign


Question: /docs/tasks/administer-cluster/certificate-rotation/     /docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/ 301 /docs/tasks/administer-cluster/cilium-network-policy/     /docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy/ 301 /docs/tasks/administer-cluster/configure-namespace-isolation/     /docs/concepts/services-networking/network-policies/ 301 <ins> /docs/tasks/administer-cluster/configure-multiple-schedulers/     /docs/tasks/extend-kubernetes/configure-multiple-schedulers/ 301 </ins> /docs/tasks/administer-cluster/configure-pod-disruption-budget/     /docs/tasks/run-application/configure-pdb/ 301 /docs/tasks/administer-cluster/cpu-constraint-namespace/     /docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/ 301 /docs/tasks/administer-cluster/cpu-default-namespace/     /docs/tasks/administer-cluster/manage-resources/cpu-default-namespace 301

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 Move to be in the same section as the content that currently exists within (that section is titled “Extend Kubernetes”). Consider moving to as well. Redirects will be helpful too. Why is this needed is showing the reader how to extend Kubernetes (by implementing a custom scheduler) more than it is explaining how to administer a cluster. Comments
/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
/sig scheduling
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
/assign
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close 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: # change is that the Hugo version is now an overridable argument rather than a fixed # environment variable. <del> FROM golang:1.15-alpine </del> <ins> FROM golang:1.16-alpine </ins> LABEL maintainer="Luc Perkins <lperkins@linuxfoundation.org>" RUN apk add --no-cache  curl  <ins> gcc  g++  musl-dev  build-base  libc6-compat ARG HUGO_VERSION RUN mkdir $HOME/src &&  cd $HOME/src &&  curl -L https://github.com/gohugoio/hugo/archive/refs/tags/v${HUGO_VERSION}.tar.gz | tar -xz &&  cd "hugo-${HUGO_VERSION}" &&  go install --tags extended FROM golang:1.16-alpine RUN apk add --no-cache  </ins> git  openssh-client  rsync  <del> build-base  libc6-compat  </del> npm &&  npm install -D autoprefixer postcss-cli <del> ARG HUGO_VERSION </del> RUN mkdir -p /usr/local/src &&  cd /usr/local/src &&  <del> curl -L https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_extended_${HUGO_VERSION}_Linux-64bit.tar.gz | tar -xz &&  mv hugo /usr/local/bin/hugo &&  </del> addgroup -Sg 1000 hugo &&  adduser -Sg hugo -u 1000 -h /src hugo <ins> COPY --from=0 /go/bin/hugo /usr/local/bin/hugo </ins> WORKDIR /src USER hugo:hugo

This is a Feature Request What would you like to be Right now, building container images for local use of this repository via does not work with Apple Silicon chips. This is because the Dockerfile downloads the Hugo binary for amd64 architecture. I have been able to workaround this issue by explicitly asking for , however, containers built in this way have very poor performance. Instead, I would like to contribute a Dockerfile that works for arm64 architecture, in a way that contributors can build container images that work in architectures that are not amd64. Why is this needed Provide a better contributor experience while creating new documentation pages and testing them locally using containers.
I created pull request with a Dockerfile and Makefile target that I have tested to address this issue.
/retitle Docs build container image only supports AMD64 architecture
/priority backlog /triage accepted


Question: sudo kubeadm init --control-plane-endpoint "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" --upload-certs ``` - You can use the `--kubernetes-version` flag to set the Kubernetes version to use. <del> It is recommended that the versions of kubeadm, kubelet, kubectl and Kubernetes match. </del> <ins> It is recommended that the versions of kubeadm, kubelet, kubectl and Kubernetes match. </ins> - The `--control-plane-endpoint` flag should be set to the address or DNS and port of the load balancer. - The `--upload-certs` flag is used to upload the certificates that should be shared <del> across all the control-plane instances to the cluster. If instead, you prefer to copy certs across control-plane nodes manually or using automation tools, please remove this flag and refer to [Manual certificate distribution](#manual-certs) section below. </del> <ins> across all the control-plane instances to the cluster. If instead, you prefer to copy certs across control-plane nodes manually or using automation tools, please remove this flag and refer to [Manual certificate distribution](#manual-certs) section below. </ins> {{< note >}} The `kubeadm init` flags `--config` and `--certificate-key` cannot be mixed, therefore if you want <del> to use the [kubeadm configuration](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2) you must add the `certificateKey` field in the appropriate config locations (under `InitConfiguration` and `JoinConfiguration: controlPlane`). </del> <ins> to use the [kubeadm configuration](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2) you must add the `certificateKey` field in the appropriate config locations (under `InitConfiguration` and `JoinConfiguration: controlPlane`). </ins> {{< /note >}} {{< note >}}

This is a Bug Report Formatting is off (broken HTML rendering) on page since earlier this week (Wednesday sometime?) per my comment in - I'm adding as a separate ticket for tracking. Some fixes to Hugo were made in and but the issues on this page are persisting. Problem: Seeing poor formatting and plaintext HTML due to some incorrect syntax on the page: ! - screenshot taken in FireFox, but replicated in Chromium (Brave) as well. Page to Update: Thank you! [EDIT] heh - I switched GitHub accounts - the comments I was referring to were by my other account
thanks for the report. cc possibly caused by the hugo bump too? /sig docs cluster-lifecycle /kind bug
Relates to tracking issue
This is almost fixed. There are some leftovers related to the ordered list. /assign


Question: 1. Unduh versi terbarunya dengan perintah: ``` <del> curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl" </del> <ins> curl -LO "https://dl.k8s.io/release/$(curl -LS https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl" </ins> ``` <del> Untuk mengunduh versi spesifik, ganti bagian `curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt` dengan versi yang diinginkan. </del> <ins> Untuk mengunduh versi spesifik, ganti bagian `curl -LS https://dl.k8s.io/release/stable.txt` dengan versi yang diinginkan. </ins> Misalnya, untuk mengunduh versi {{< param "fullversion" >}} pada macOS, ketik: ``` <del> curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl </del> <ins> curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl </ins> ``` 2. Buat agar program `kubectl` dapat dijalankan.

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: There are still references to instead of is the correct advertised download host and will eventually move to be fastly shielding a fully community-owned bucket ref: Proposed Solution: Replace with Also replace any references with using if applicable. Page to Update: Assorted e.g. , <!--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
/assign
hi Not a problem, didn't see anyone assigned to this issue. I am unassigning myself and assigning it to you. /unassign
/assign
Hi, I found a small issue with your proposed changes regarding one of the URLs, which is mentioned twice in the file. While returns as expected, I am getting an nginx-rendered HTML page saying for the new command () instead. As I understand, it happens due to the redirect configured on the new web server. Thus, works fine for me (it returns as expected).
i see Let me update it, thanks your work
Just done, please review all of PRs
Thanks!
And yes: These will need to follow redirects, in the future the tentative plan is it will redirect to a CDN in front of a different bucket created in a fully project / SIG-K8s-Infra controlled GCP or AWS account. I would recommend for downloading with curl more generally, even in docs / usage for other hosts.


Question: <ins> --- layout: blog title: "Kubernetes 1.24 中的上下文日志记录" date: 2022-05-25 slug: contextual-logging --- <!-- layout: blog title: "Contextual Logging in Kubernetes 1.24" date: 2022-05-25 slug: contextual-logging canonicalUrl: https://kubernetes.dev/blog/2022/05/25/contextual-logging/ --> <!-- **Authors:** Patrick Ohly (Intel) --> **作者:** Patrick Ohly (Intel) <!-- The [Structured Logging Working Group](https://github.com/kubernetes/community/blob/master/wg-structured-logging/README.md) has added new capabilities to the logging infrastructure in Kubernetes 1.24. This blog post explains how developers can take advantage of those to make log output more useful and how they can get involved with improving Kubernetes. --> [结构化日志工作组](https://github.com/kubernetes/community/blob/master/wg-structured-logging/README.md) 在 Kubernetes 1.24 中为日志基础设施添加了新功能。这篇博文解释了开发者如何利用这些功能使日志输出更有用， 以及他们如何参与改进 Kubernetes。 <!-- ## Structured logging --> ## 结构化日志记录 <!-- The goal of [structured logging](https://github.com/kubernetes/enhancements/blob/master/keps/sig-instrumentation/1602-structured-logging/README.md) is to replace C-style formatting and the resulting opaque log strings with log entries that have a well-defined syntax for storing message and parameters separately, for example as a JSON struct. --> [结构化日志](https://github.com/kubernetes/enhancements/blob/master/keps/sig-instrumentation/1602-structured-logging/README.md) 记录的目标是用具有明确定义的语法的日志条目来取代 C 风格的格式化和由此产生的不透明的日志字符串，用于分别存储消息和参数，例如，作为一个 JSON 结构。 <!-- When using the traditional klog text output format for structured log calls, strings were originally printed with `n` escape sequences, except when embedded inside a struct. For structs, log entries could still span multiple lines, with no clean way to split the log stream into individual entries: --> 当使用传统的 klog 文本输出格式进行结构化日志调用时，字符串最初使用 `n` 转义序列打印，除非嵌入到结构中。 对于结构体，日志条目仍然可以跨越多行，没有干净的方法将日志流拆分为单独的条目： ``` I1112 14:06:35.783529  328441 structured_logging.go:51] "using InfoS" longData={Name:long Data:Multiple lines with quite a bit of text. internal:0} I1112 14:06:35.783549  328441 structured_logging.go:52] "using InfoS withnthe message across multiple lines" int=1 stringData="long: Multiplenlinesnwith quite a bitnof text." str="another value" ``` <!-- Now, the `<` and `>` markers along with indentation are used to ensure that splitting at a klog header at the start of a line is reliable and the resulting output is human-readable: --> 现在，`<` 和 `>` 标记以及缩进用于确保在行首的 klog 标头处拆分是可靠的，并且生成的输出是人类可读的： ``` I1126 10:31:50.378204  121736 structured_logging.go:59] "using InfoS" longData=< {Name:long Data:Multiple lines with quite a bit of text. internal:0} > I1126 10:31:50.378228  121736 structured_logging.go:60] "using InfoS withnthe message across multiple lines" int=1 stringData=< long: Multiple lines with quite a bit of text. > str="another value" ``` <!-- Note that the log message itself is printed with quoting. It is meant to be a fixed string that identifies a log entry, so newlines should be avoided there. --> 请注意，日志消息本身带有引号。它是一个用于标识日志条目的固定字符串，因此应避免使用换行符。 <!-- Before Kubernetes 1.24, some log calls in kube-scheduler still used `klog.Info` for multi-line strings to avoid the unreadable output. Now all log calls have been updated to support structured logging. --> 在 Kubernetes 1.24 之前，kube-scheduler 中的一些日志调用仍然使用 `klog.Info` 处理多行字符串， 以避免不可读的输出。现在所有日志调用都已更新以支持结构化日志记录。 <!-- ## Contextual logging --> ## 上下文日志记录 <!-- [Contextual logging](https://github.com/kubernetes/enhancements/blob/master/keps/sig-instrumentation/3077-contextual-logging/README.md) is based on the [go-logr API](https://github.com/go-logr/logr#a-minimal-logging-api-for-go). The key idea is that libraries are passed a logger instance by their caller and use that for logging instead of accessing a global logger. The binary decides about the logging implementation, not the libraries. The go-logr API is designed around structured logging and supports attaching additional information to a logger. --> [上下文日志](https://github.com/kubernetes/enhancements/blob/master/keps/sig-instrumentation/3077-contextual-logging/README.md) 基于 [go-logr API](https://github.com/go-logr/logr#a-minimal-logging-api-for-go)。 关键的想法是，库被其调用者传递给一个记录器实例，并使用它来记录，而不是访问一个全局记录器。 二进制文件决定了日志的实现，而不是库。go-logr API 是围绕着结构化的日志记录而设计的，并支持将额外的信息附加到一个记录器上。 <!-- This enables additional use cases: --> 这使得以下用例成为可能： <!-- - The caller can attach additional information to a logger: - [`WithName`](https://pkg.go.dev/github.com/go-logr/logr#Logger.WithName) adds a prefix - [`WithValues`](https://pkg.go.dev/github.com/go-logr/logr#Logger.WithValues) adds key/value pairs --> - 调用者可以将附加信息附加到记录器： - [`WithName`](https://pkg.go.dev/github.com/go-logr/logr#Logger.WithName) 添加前缀 - [`WithValues`](https://pkg.go.dev/github.com/go-logr/logr#Logger.WithValues) 添加键/值对 <!-- When passing this extended logger into a function and a function uses it instead of the global logger, the additional information is then included in all log entries, without having to modify the code that generates the log entries. This is useful in highly parallel applications where it can become hard to identify all log entries for a certain operation because the output from different operations gets interleaved. --> 当将此扩展记录器传递给函数并且函数使用它而不是全局记录器时，附加信息随后将包含在所有日志条目中，而无需修改生成日志条目的代码。 这在高度并行的应用程序中很有用，在这些应用程序中，由于不同操作的输出会交错，因此很难识别某个操作的所有日志条目。 <!-- - When running unit tests, log output can be associated with the current test. Then when a test fails, only the log output of the failed test gets shown by `go test`. That output can also be more verbose by default because it will not get shown for successful tests. Tests can be run in parallel without interleaving their output. --> - 运行单元测试时，可以将日志输出与当前测试关联起来。当测试失败时，`go test` 只显示失败测试的日志输出。 默认情况下，该输出也可以更详细，因为它不会显示成功的测试。这些测试可以在不交错输出的情况下并行运行。 <!-- One of the design decisions for contextual logging was to allow attaching a logger as value to a `context.Context`. Since the logger encapsulates all aspects of the intended logging for the call, it is *part* of the context and not just *using* it. A practical advantage is that many APIs already have a `ctx` parameter or adding one has additional advantages, like being able to get rid of `context.TODO()` calls inside the functions. --> 上下文日志记录的设计决策之一是允许将记录器作为值附加到 `context.Context`。 由于记录器封装了调用的预期记录的所有方面，它是上下文的**部分**，而不仅仅是**使用**它。 一个实际的优势是许多 API 已经有一个 `ctx` 参数，或者添加一个具有其他优势，例如能够摆脱函数内部的 `context.TODO()` 调用。 <!-- Another decision was to not break compatibility with klog v2: --> 另一个决定是不破坏与 klog v2 的兼容性： <!-- - Libraries that use the traditional klog logging calls in a binary that has set up contextual logging will work and log through the logging backend chosen by the binary. However, such log output will not include the additional information and will not work well in unit tests, so libraries should be modified to support contextual logging. The [migration guide](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/migration-to-structured-logging.md) for structured logging has been extended to also cover contextual logging. --> - 在已设置上下文日志记录的二进制文件中使用传统 klog 日志记录调用的库将通过二进制文件选择的日志记录后端工作和记录。 但是，这样的日志输出不会包含额外的信息，并且在单元测试中不能很好地工作，因此应该修改库以支持上下文日志记录。 结构化日志记录的[迁移指南](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/migration-to-structured-logging.md) 已扩展为也涵盖上下文日志记录。 <!-- - When a library supports contextual logging and retrieves a logger from its context, it will still work in a binary that does not initialize contextual logging because it will get a logger that logs through klog. --> - 当一个库支持上下文日志并从其上下文中检索一个记录器时，它仍将在不初始化上下文日志的二进制文件中工作， 因为它将获得一个通过 klog 记录的记录器。 <!-- In Kubernetes 1.24, contextual logging is a new alpha feature with `ContextualLogging` as feature gate. When disabled (the default), the new klog API calls for contextual logging (see below) become no-ops to avoid performance or functional regressions. --> 在 Kubernetes 1.24 中，上下文日志是一个新的 Alpha 特性，以 `ContextualLogging` 作为特性门控。 禁用时（默认），用于上下文日志记录的新 klog API 调用（见下文）变为无操作，以避免性能或功能回归。 <!-- No Kubernetes component has been converted yet. An [example program](https://github.com/kubernetes/kubernetes/blob/v1.24.0-beta.0/staging/src/k8s.io/component-base/logs/example/cmd/logger.go) in the Kubernetes repository demonstrates how to enable contextual logging in a binary and how the output depends on the binary's parameters: --> 尚未转换任何 Kubernetes 组件。 Kubernetes 存储库中的[示例程序](https://github.com/kubernetes/kubernetes/blob/v1.24.0-beta.0/staging/src/k8s.io/component-base/logs/example/cmd/logger.go) 演示了如何在一个二进制文件中启用上下文日志记录，以及输出如何取决于该二进制文件的参数： ```console $ cd $GOPATH/src/k8s.io/kubernetes/staging/src/k8s.io/component-base/logs/example/cmd/ $ go run . --help ... --feature-gates mapStringBool  A set of key=value pairs that describe feature gates for alpha/experimental features. Options are: AllAlpha=true|false (ALPHA - default=false) AllBeta=true|false (BETA - default=false) ContextualLogging=true|false (ALPHA - default=false) $ go run . --feature-gates ContextualLogging=true ... I0404 18:00:02.916429  451895 logger.go:94] "example/myname: runtime" foo="bar" duration="1m0s" I0404 18:00:02.916447  451895 logger.go:95] "example: another runtime" foo="bar" duration="1m0s" ``` <!-- The `example` prefix and `foo="bar"` were added by the caller of the function which logs the `runtime` message and `duration="1m0s"` value. --> `example` 前缀和 `foo="bar"` 是由记录 `runtime` 消息和 `duration="1m0s"` 值的函数的调用者添加的。 <!-- The sample code for klog includes an [example](https://github.com/kubernetes/klog/blob/v2.60.1/ktesting/example/example_test.go) for a unit test with per-test output. --> 针对 klog 的示例代码包括一个单元测试[示例](https://github.com/kubernetes/klog/blob/v2.60.1/ktesting/example/example_test.go) 以及每个测试的输出。 <!-- ## klog enhancements ### Contextual logging API The following calls manage the lookup of a logger: --> ## klog 增强功能 ### 上下文日志 API 以下调用管理记录器的查找： <!-- [`FromContext`](https://pkg.go.dev/k8s.io/klog/v2#FromContext) : from a `context` parameter, with fallback to the global logger --> [`FromContext`](https://pkg.go.dev/k8s.io/klog/v2#FromContext) ：来自 `context` 参数，回退到全局记录器 <!-- [`Background`](https://pkg.go.dev/k8s.io/klog/v2#Background) : the global fallback, with no intention to support contextual logging [`TODO`](https://pkg.go.dev/k8s.io/klog/v2#TODO) : the global fallback, but only as a temporary solution until the function gets extended to accept a logger through its parameters --> [`Background`](https://pkg.go.dev/k8s.io/klog/v2#Background) ：全局后备，无意支持上下文日志记录 [`TODO`](https://pkg.go.dev/k8s.io/klog/v2#TODO) ：全局回退，但仅作为一个临时解决方案，直到该函数得到扩展能够通过其参数接受一个记录器 <!-- [`SetLoggerWithOptions`](https://pkg.go.dev/k8s.io/klog/v2#SetLoggerWithOptions) : changes the fallback logger; when called with [`ContextualLogger(true)`](https://pkg.go.dev/k8s.io/klog/v2#ContextualLogger), the logger is ready to be called directly, in which case logging will be done without going through klog --> [`SetLoggerWithOptions`](https://pkg.go.dev/k8s.io/klog/v2#SetLoggerWithOptions) ：更改后备记录器；当使用[`ContextualLogger(true)`](https://pkg.go.dev/k8s.io/klog/v2#ContextualLogger) 调用时, 记录器已准备好被直接调用，在这种情况下，记录将无需执行通过 klog <!-- To support the feature gate mechanism in Kubernetes, klog has wrapper calls for the corresponding go-logr calls and a global boolean controlling their behavior: --> 为了支持 Kubernetes 中的特性门控机制，klog 对相应的 go-logr 调用进行了包装调用，并使用了一个全局布尔值来控制它们的行为： - [`LoggerWithName`](https://pkg.go.dev/k8s.io/klog/v2#LoggerWithName) - [`LoggerWithValues`](https://pkg.go.dev/k8s.io/klog/v2#LoggerWithValues) - [`NewContext`](https://pkg.go.dev/k8s.io/klog/v2#NewContext) - [`EnableContextualLogging`](https://pkg.go.dev/k8s.io/klog/v2#EnableContextualLogging) <!-- Usage of those functions in Kubernetes code is enforced with a linter check. The klog default for contextual logging is to enable the functionality because it is considered stable in klog. It is only in Kubernetes binaries where that default gets overridden and (in some binaries) controlled via the `--feature-gate` parameter. --> 在 Kubernetes 代码中使用这些函数是通过 linter 检查强制执行的。 上下文日志的 klog 默认是启用该功能，因为它在 klog 中被认为是稳定的。 只有在 Kubernetes 二进制文件中，该默认值才会被覆盖，并且（在某些二进制文件中）通过 `--feature-gate` 参数进行控制。 <!-- ### ktesting logger The new [ktesting](https://pkg.go.dev/k8s.io/klog/v2@v2.60.1/ktesting) package implements logging through `testing.T` using klog's text output format. It has a [single API call](https://pkg.go.dev/k8s.io/klog/v2@v2.60.1/ktesting#NewTestContext) for instrumenting a test case and [support for command line flags](https://pkg.go.dev/k8s.io/klog/v2@v2.60.1/ktesting/init). --> ### ktesting 记录器 新的 [ktesting](https://pkg.go.dev/k8s.io/klog/v2@v2.60.1/ktesting) 包使用 klog 的文本输出格式通过 `testing.T` 实现日志记录。它有一个 [single API call](https://pkg.go.dev/k8s.io/klog/v2@v2.60.1/ktesting#NewTestContext) 用于检测测试用例和[支持命令行标志](https://pkg.go.dev/k8s.io/klog/v2@v2.60.1/ktesting/init)。 <!-- ### klogr [`klog/klogr`](https://pkg.go.dev/k8s.io/klog/v2@v2.60.1/klogr) continues to be supported and it's default behavior is unchanged: it formats structured log entries using its own, custom format and prints the result via klog. --> ### klogr [`klog/klogr`](https://pkg.go.dev/k8s.io/klog/v2@v2.60.1/klogr) 继续受支持，默认行为不变： 它使用其格式化结构化日志条目拥有自己的自定义格式并通过 klog 打印结果。 <!-- However, this usage is discouraged because that format is neither machine-readable (in contrast to real JSON output as produced by zapr, the go-logr implementation used by Kubernetes) nor human-friendly (in contrast to the klog text format). --> 但是，不鼓励这种用法，因为这种格式既不是机器可读的（与 zapr 生成的真实 JSON 输出相比，Kubernetes 使用的 go-logr 实现）也不是人类友好的（与 klog 文本格式相比）。 <!-- Instead, a klogr instance should be created with [`WithFormat(FormatKlog)`](https://pkg.go.dev/k8s.io/klog/v2@v2.60.1/klogr#WithFormat) which chooses the klog text format. A simpler construction method with the same result is the new [`klog.NewKlogr`](https://pkg.go.dev/k8s.io/klog/v2#NewKlogr). That is the logger that klog returns as fallback when nothing else is configured. --> 相反，应该使用选择 klog 文本格式的 [`WithFormat(FormatKlog)`](https://pkg.go.dev/k8s.io/klog/v2@v2.60.1/klogr#WithFormat) 创建一个 klogr 实例。 一个更简单但结果相同的构造方法是新的 [`klog.NewKlogr`](https://pkg.go.dev/k8s.io/klog/v2#NewKlogr)。 这是 klog 在未配置任何其他内容时作为后备返回的记录器。 <!-- ### Reusable output test --> ### 可重用输出测试 <!-- A lot of go-logr implementations have very similar unit tests where they check the result of certain log calls. If a developer didn't know about certain caveats like for example a `String` function that panics when called, then it is likely that both the handling of such caveats and the unit test are missing. --> 许多 go-logr 实现都有非常相似的单元测试，它们检查某些日志调用的结果。 如果开发人员不知道某些警告，例如调用时会出现恐慌的 `String` 函数，那么很可能缺少对此类警告的处理和单元测试。 <!-- [`klog.test`](https://pkg.go.dev/k8s.io/klog/v2@v2.60.1/test) is a reusable set of test cases that can be applied to a go-logr implementation. --> [`klog.test`](https://pkg.go.dev/k8s.io/klog/v2@v2.60.1/test) 是一组可重用的测试用例，可应用于 go-logr 实现。 <!-- ### Output flushing klog used to start a goroutine unconditionally during `init` which flushed buffered data at a hard-coded interval. Now that goroutine is only started on demand (i.e. when writing to files with buffering) and can be controlled with [`StopFlushDaemon`](https://pkg.go.dev/k8s.io/klog/v2#StopFlushDaemon) and [`StartFlushDaemon`](https://pkg.go.dev/k8s.io/klog/v2#StartFlushDaemon). --> ### 输出刷新 klog 用于在 `init` 期间无条件地启动一个 goroutine，它以硬编码的时间间隔刷新缓冲数据。 现在 goroutine 仅按需启动（即当写入具有缓冲的文件时）并且可以使用 [`StopFlushDaemon`](https://pkg.go.dev/k8s.io/klog/v2#StopFlushDaemon) 和 [`StartFlushDaemon`](https://pkg.go.dev/k8s.io/klog/v2#StartFlushDaemon)。 <!-- When a go-logr implementation buffers data, flushing that data can be integrated into [`klog.Flush`](https://pkg.go.dev/k8s.io/klog/v2#Flush) by registering the logger with the [`FlushLogger`](https://pkg.go.dev/k8s.io/klog/v2#FlushLogger) option. --> 当 go-logr 实现缓冲数据时，可以通过使用 [`FlushLogger`](https://pkg.go.dev/k8s.io/klog/v2#FlushLogger) 选项注册记录器来将刷新该数据集成到 [`klog.Flush`](https://pkg.go.dev/k8s.io/klog/v2#Flush) 中。 <!-- ### Various other changes For a description of all other enhancements see in the [release notes](https://github.com/kubernetes/klog/releases). --> ### 其他各种变化 有关所有其他增强功能的描述，请参见 [发行说明](https://github.com/kubernetes/klog/releases)。 <!-- ## logcheck --> ## 日志检查 <!-- Originally designed as a linter for structured log calls, the [`logcheck`](https://github.com/kubernetes/klog/tree/788efcdee1e9be0bfbe5b076343d447314f2377e/hack/tools/logcheck) tool has been enhanced to support also contextual logging and traditional klog log calls. These enhanced checks already found bugs in Kubernetes, like calling `klog.Info` instead of `klog.Infof` with a format string and parameters. --> 最初设计为结构化日志调用的 linter，[`logcheck`] 工具已得到增强，还支持上下文日志记录和传统的 klog 日志调用。 这些增强检查已经在 Kubernetes 中发现了错误，例如使用格式字符串和参数调用 `klog.Info` 而不是 `klog.Infof`。 <!-- It can be included as a plugin in a `golangci-lint` invocation, which is how [Kubernetes uses it now](https://github.com/kubernetes/kubernetes/commit/17e3c555c5115f8c9176bae10ba45baa04d23a7b), or get invoked stand-alone. --> 它可以作为插件包含在 `golangci-lint` 调用中，这就是 [Kubernetes 现在使用它的方式](https://github.com/kubernetes/kubernetes/commit/17e3c555c5115f8c9176bae10ba45baa04d23a7b)，或者单独调用。 <!-- We are in the process of [moving the tool](https://github.com/kubernetes/klog/issues/312) into a new repository because it isn't really related to klog and its releases should be tracked and tagged properly. --> 我们正在 [移动工具](https://github.com/kubernetes/klog/issues/312) 到一个新的存储库中，因为它与 klog 没有真正的关系，并且应该正确跟踪和标记它的发布。 <!-- ## Next steps The [Structured Logging WG](https://github.com/kubernetes/community/tree/master/wg-structured-logging) is always looking for new contributors. The migration away from C-style logging is now going to target structured, contextual logging in one step to reduce the overall code churn and number of PRs. Changing log calls is good first contribution to Kubernetes and an opportunity to get to know code in various different areas. --> ## 下一步 [Structured Logging WG](https://github.com/kubernetes/community/tree/master/wg-structured-logging) 一直在寻找新的贡献者。 从 C 风格的日志记录迁移现在将一步一步地针对结构化的上下文日志记录， 以减少整体代码流失和 PR 数量。 更改日志调用是对 Kubernetes 的良好贡献，也是了解各个不同领域代码的机会。 </ins>  No newline at end of file

This is a Feature Report Problem: misssing Chinese translation docs: content/en/blog/_posts/2022-05-25-contextual-logging Proposed Solution: add Chinese translation docs in website Kubernetes Blog Comments /language zh /assign
English page:
/triage accepted


Question: `--apiserver-extra-args "enable-admission-plugins=LimitRanger,enable-admission-plugins=NamespaceExists"` but this will result in the key `enable-admission-plugins` only having the value of `NamespaceExists`. <del> A known workaround is to use the kubeadm [configuration file](/docs/reference/config-api/kubeadm-config.v1beta2/). </del> <ins> A known workaround is to use the kubeadm [configuration file](/docs/reference/config-api/kubeadm-config.v1beta3/). </ins> ## kube-proxy scheduled before node is initialized by cloud-controller-manager

says: the “configuration format” is a hyperlink to , it shall instead point to (beta2 → beta3) says: where “NodeRegistrationOptions” is a hyperlink to . It shall instead point to (beta2 → beta3) says: where “configuration file” is a hypelink to . It shall instead point to (beta2 → beta3) says: where “API referenc” is a hyperlink to It shall instead point to .
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 cluster-lifecycle /remove-kind bug /kind cleanup
/language en


Question: Untuk mengunduh versi spesifik, ganti bagian `curl -LS https://dl.k8s.io/release/stable.txt` dengan versi yang diinginkan. <del> Misalnya, untuk mengunduh versi {{< param "fullversion" >}} pada macOS, ketik: </del> <ins> Misalnya, untuk mengunduh versi {{< skew currentPatchVersion >}} pada macOS, ketik: </ins> ``` <del> curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl </del> <ins> curl -LO https://dl.k8s.io/release/v{{< skew currentPatchVersion >}}/bin/darwin/amd64/kubectl </ins> ``` 2. Buat agar program `kubectl` dapat dijalankan.

Problem: Based on , I have created this issue/task to help update the [id] language documentation. Proposed Solution: Page to Update: In the branch, I found: Results for "fullversion" in "k8s-website/content/id" /home/rdlugyhe/kubernetes/k8s-website/content/id/docs/tasks/tools/install- 34: Misalnya, untuk mengunduh versi {{< param "fullversion" }} di Linux, ketik: 37: curl -LO {{< param "fullversion" }}/bin/linux/amd64/kubectl 114: Misalnya, untuk mengunduh versi {{< param "fullversion" }} pada macOS, ketik: 117: curl -LO {{< param "fullversion" }}/bin/darwin/amd64/kubectl 179: 1. Unduh versi terbarunya {{< param "fullversion" }} dari tautan ini /sig docs /sig localization /language id cc:
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : Problem: All the other documents need to change into or appropriatly. Since several languages are involved, I'd like to share this issue to check all localizations complete the task. Proposed Solution: Page to Update: /home/rdlugyhe/kubernetes/k8s-website/content/id/docs/concepts/extend-kubernetes/compute-storage-net/network- /sig localization /language id cc: 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 /area localization /priority backlog


Question: To build an out-of-tree cloud-controller-manager for your cloud: 1. Create a go package with an implementation that satisfies [cloudprovider.Interface](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go). <del> 2. Use [`main.go` in cloud-controller-manager](https://github.com/kubernetes/kubernetes/blob/master/cmd/cloud-controller-manager/controller-manager.go) from Kubernetes core as a template for your `main.go`. As mentioned above, the only difference should be the cloud package that will be imported. </del> <ins> 2. Use [`main.go` in cloud-controller-manager](https://github.com/kubernetes/kubernetes/blob/master/cmd/cloud-controller-manager/main.go) from Kubernetes core as a template for your `main.go`. As mentioned above, the only difference should be the cloud package that will be imported. </ins> 3. Import your cloud package in `main.go`, ensure your package has an `init` block to run [`cloudprovider.RegisterCloudProvider`](https://github.com/kubernetes/cloud-provider/blob/master/plugins.go). Many cloud providers publish their controller manager code as open source. If you are creating

Out of tree developing instructions are now out of date. reference leads to a 404.
The fix, I think, is to change the hyperlink to be /kind bug /priority backlog /triage accepted /language en /sig api-machinery /sig cloud-provider
/assign


Question: not affect the performance of the member. Below is an example for taking a snapshot of the keyspace served by <del> `$ENDPOINT` to the file `snapshotdb`: </del> <ins> `$ENDPOINT` to the file `snapshot.db`: </ins> ```shell <del> ETCDCTL_API=3 etcdctl --endpoints $ENDPOINT snapshot save snapshotdb </del> <ins> ETCDCTL_API=3 etcdctl --endpoints $ENDPOINT snapshot save snapshot.db </ins> ``` Verify the snapshot: ```shell <del> ETCDCTL_API=3 etcdctl --write-out=table snapshot status snapshotdb </del> <ins> ETCDCTL_API=3 etcdctl --write-out=table snapshot status snapshot.db </ins> ``` ```console

The restoration command should be clear containing the new -to-be-created directory and the path containing the backup file. Like:
/language en /kind support
Hey are you talking about this ?
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
/remove-lifecycle rotten
Hi The command - seems fine to me
As it is already mentioned that snapshotdb is a backup file.
/remove-kind support Seems reasonable to do /lifecycle frozen /priority backlog /triage accepted /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 : /remove-kind support Seems reasonable to do /priority backlog /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
/assign


Question: ## Glossary <ins> There are two glossary tooltips. </ins> You can reference glossary terms with an inclusion that automatically updates and replaces content with the relevant links from [our glossary](/docs/reference/glossary/). When the term is moused-over by someone using the online documentation, the glossary entry displays a tooltip. <ins> As well as inclusions with tooltips, you can reuse the definitions from the glossary in page content. </ins> The raw data for glossary terms is stored at [https://github.com/kubernetes/website/tree/master/content/en/docs/reference/glossary](https://github.com/kubernetes/website/tree/master/content/en/docs/reference/glossary), with a content file for each glossary term. <del> ### Glossary Demo </del> <ins> ### Glossary demo </ins> For example, the following include within the markdown renders to {{< glossary_tooltip text="cluster" term_id="cluster" >}} with a tooltip: <del> ```liquid </del> <ins> ``` </ins> {{</* glossary_tooltip text="cluster" term_id="cluster" */>}} ``` <ins> Here's a short glossary definition: ``` {{</* glossary_definition prepend="A cluster is" term_id="cluster" length="short" */>}} ``` which renders as: {{< glossary_definition prepend="A cluster is" term_id="cluster" length="short" >}} You can also include a full definition: ``` {{</* glossary_definition term_id="cluster" length="all" */>}} ``` which renders as: {{< glossary_definition term_id="cluster" length="all" >}} </ins> ## Table captions You can make tables more accessible to screen readers by adding a table caption. To add a [caption](https://www.w3schools.com/tags/tag_caption.asp) to a table, enclose the table with a `table` shortcode and specify the caption with the `caption` parameter.

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: This works: and this too: but: renders incorrectly; the output is similar to the following HTML (escaped when it should not be): Proposed Solution: I'm not sure what needs to change here. I'd like to be able to use short glossary definitions with prepending. <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/kind bug
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


Question: ## Metric lifecycle <del> Alpha metric →  Stable metric →  Deprecated metric →  Hidden metric → Deletion </del> <ins> Alpha metric →  Stable metric →  Deprecated metric →  Hidden metric → Deleted metric </ins> <del> Alpha metrics have no stability guarantees; as such they can be modified or deleted at any time. </del> <ins> Alpha metrics have no stability guarantees. These metrics can be modified or deleted at any time. </ins> <del> Stable metrics can be guaranteed to not change; Specifically, stability means: </del> <ins> Stable metrics are guaranteed to not change. This means: * A stable metric without a deprecated signature will not be deleted or renamed * A stable metric's type will not be modified </ins> <del> * the metric itself will not be deleted (or renamed) * the type of metric will not be modified </del> <ins> Deprecated metrics are slated for deletion, but are still available for use. These metrics include an annotation about the version in which they became deprecated. </ins> <del> Deprecated metric signal that the metric will eventually be deleted; to find which version, you need to check annotation, which includes from which kubernetes version that metric will be considered deprecated. </del> <ins> For example: </ins> <del> Before deprecation: </del> <ins> * Before deprecation </ins> <del> ``` # HELP some_counter this counts things # TYPE some_counter counter some_counter 0 ``` </del> <ins> ``` # HELP some_counter this counts things # TYPE some_counter counter some_counter 0 ``` </ins> <del> After deprecation: </del> <ins> * After deprecation </ins> <del> ``` # HELP some_counter (Deprecated since 1.15.0) this counts things # TYPE some_counter counter some_counter 0 ``` </del> <ins> ``` # HELP some_counter (Deprecated since 1.15.0) this counts things # TYPE some_counter counter some_counter 0 ``` </ins> <del> Once a metric is hidden then by default the metrics is not published for scraping. To use a hidden metric, you need to override the configuration for the relevant cluster component. </del> <ins> Hidden metrics are no longer published for scraping, but are still available for use. To use a hidden metric, please refer to the [Show hidden metrics](#show-hidden-metrics) section. </ins> <del> Once a metric is deleted, the metric is not published. You cannot change this using an override. </del> <ins> Deleted metrics are no longer published and cannot be used. </ins> <del> ## Show Hidden Metrics </del> <ins> ## Show hidden metrics </ins> As described above, admins can enable hidden metrics through a command-line flag on a specific binary. This intends to be used as an escape hatch for admins if they missed the migration of the metrics deprecated in the last release.

This is a Bug Report Problem: The text unclearly says: "Deprecated metric signal that the metric will eventually be deleted; to find which version, you need to check annotation, which includes from which kubernetes version that metric will be considered deprecated." (Note the problems, such as "Deprecated metric signal ...," "to check annotation," unclear references to versions (when metric will be gone, when declared deprecated, other?), etc.) Proposed Solution: Have a fluent English speaker (who knows Kubernetes) edit that. Page to Update:
/language en /sig instrumentation
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
/triage accepted
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
I'd like to try a pass at this. /assign
Not sure if I'm able to do this, but let's try: /remove-lifecycle rotten


Question: One CronJob object is like one line of a _crontab_ (cron table) file. It runs a job periodically on a given schedule, written in [Cron](https://en.wikipedia.org/wiki/Cron) format. <del> {{< note >}} All **CronJob** `schedule:` times are denoted in UTC. {{< /note >}} </del> <ins> {{< caution >}} All **CronJob** `schedule:` times are based on the timezone of the {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}. If your control plane runs the kube-controller-manager in Pods or bare containers, the timezone set for the kube-controller-manager container determines the timezone that the cron job controller uses. {{< /caution >}} </ins> When creating the manifest for a CronJob resource, make sure the name you provide is a valid [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).

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. --We have setup the Kuberntes cluster in our Environment we have 2 master node and 4 worker node which all installed EST Time zone Cron Job is scheduled at 12:01 daily midnight And Job is started on 19:01 EST Time instead of 12:01 Time , I feel this running as UTC Timezone <!--Required Information--Problem: The cron Job is not running on the timezone of the master node its running on the UTC Timezone ie OS layer of your Docker image Proposed Solution: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--v1.13.1 <!--Additional Information:--
It looks like this is a duplicate of issue

It seems that this note is inaccurate by saying it's based on timezone. In fact messaging is alluding that timezone will not be supported and it's based on UTC.
Here's the change for posterity.
Thanks for reporting this /kind bug /priority important-longterm /good-first-issue
/assign
Hello Team Is there any deadline when this issue will be fixed ? can we get the the Timezone functionality also with thes CronJob Just want to know
Kubernetes is an open-source, volunteer led project. There aren't deadlines per se. If you're keen to see the documentation changed, for this or any issue, anyone can .
(If anyone would like to help here but is not sure how to get started, please reply—advice is available).
The change is wrong, the time IS taken from the master node the controller is running on, or from within the container controller-manager is running. It's not hardcoded to be UTC. Why are you claiming otherwise, have you checked?
Ah, so this issue is invalid and needs reverting?
(alternative fix: revert, then revise so that all times are_ in UTC)
I looked at the code: and it looks to me that this issue is invalid. I propose to close it if there's no update in the next fortnight. /remove-good-first-issue /remove-help /remove-kind bug /remove-priority important-longterm
Is this issue not valid ? , In our instance , we have 2 master node and it configured as EST timezone and 4 worker node and configured as EST timezone , but still cron job runs on the UTC Timezone
Is the advice at https://deploy-preview---kubernetes-io-master- accurate?
Okay thanks!! Now document looks aligned thanks we can close!!


Question: the Job in turn is responsible for the management of the Pods it represents. {{% /capture %}} <ins> {{% capture whatsnext %}} [Cron expression format](https://pkg.go.dev/github.com/robfig/cron?tab=doc#hdr-CRON_Expression_Format) documents the format of CronJob `schedule` fields. For instructions on creating and working with cron jobs, and for an example of CronJob manifest, see [Running automated tasks with cron jobs](/docs/tasks/job/automated-tasks-with-cron-jobs). {{% /capture %}} </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: This is the first one you get when searching docs for CronJob. I know this is a small suggestion but i think it would help a lot in reducing time searching / exploring kubectl explain. Proposed Solution: It should imho contain a example just like on the page: this would help to speed up search if needed fast. This example one: (copy paste from url) Page to Update:
This is similar to issue


Question: {{< note >}} एक विशिष्ट संस्करण डाउनलोड करने के लिए, कमांड के `$(curl -L -s https://dl.k8s.io/release/stable.txt)` हिस्से को विशिष्ट संस्करण से बदलें। <del> उदाहरण के लिए, लिनक्स पर {{< param "fullversion" >}} संस्करण डाउनलोड करने के लिए, टाइप करें: </del> <ins> उदाहरण के लिए, लिनक्स पर {{< skew currentPatchVersion >}} संस्करण डाउनलोड करने के लिए, टाइप करें: </ins> ```bash <del> curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/linux/amd64/kubectl </del> <ins> curl -LO https://dl.k8s.io/release/v{{< skew currentPatchVersion >}}/bin/linux/amd64/kubectl </ins> ``` {{< /note >}}

Parent issue: Substitute the outdated shortcode with the new shortcode in the Hindi language documentation. /assign /triage accepted /language hi
PR has been raised to address this issue.