jiebi/CodeConvo huggingface dataset:
Change:
Source IP for Services with Type=ClusterIP Packets sent to ClusterIP from within the cluster are never source NAT'd if you're running kube-proxy in iptables mode, (the default). You can query the kube-proxy mode by fetching http://localhost:/proxyMode on the node where kube-proxy is running. kubectl get nodes The output is similar to this: NAME STATUS ROLES AGE VERSION kubernetes-node-6jst Ready <none2h v1.13.0 kubernetes-node-cx31 Ready <none2h v1.13.0 kubernetes-node-jj1t Ready <none2h v1.13.0 When I use kubectl get nodes there is no nodes available except NAME STATUS ROLES AGE VERSION minikube Ready control-plane,master 38m v1.20.2
Let's update to recommend running this tutorial on a cluster with at least two nodes that are not acting as control plane hosts. /retitle Unclear requirements for “Using Source IP” tutorial
/triage accepted
The tutorial uses a cluster as an example setup throughout the document. <sub(The text in the screenshot below is the exact section referred in the issue description)</sub! But as pointed in the description of this issue: the section doesn't clearly state that it requires a multi-node cluster to follow through the doc examples. also, it mentions to create a cluster using which usually is taken as a single node (common) control-plane/worker-node setup. As suggested by the fix/solution would be to update the section to mention that it is recommended to run this tutorial on a cluster with at least two nodes that are not acting as control plane hosts. You could also update the part by linking to this article talking about .
/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

Discussion:
You need to have a Kubernetes cluster, and the kubectl command-line tool must <del> be configured to communicate with your cluster. If you do not already have a </del> <ins> be configured to communicate with your cluster. It is recommended to run this tutorial on a cluster with at least two nodes that are not acting as control plane hosts. If you do not already have a </ins> cluster, you can create one by using <del> [minikube](/docs/tasks/tools/#minikube) </del> <ins> [minikube](https://minikube.sigs.k8s.io/docs/tutorials/multi_node/) </ins> or you can use one of these Kubernetes playgrounds: * [Katacoda](https://www.katacoda.com/courses/kubernetes/playground)
Change:
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: mentions that the admission controller is beta; however the related feature gate is now GA. Proposed Solution: Verify the feature status of the TaintNodeByCondition feature for the admission controller specifically. If is in fact stable, update the page. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /sig node /language en
could you confirm whether that admission controller is still beta?
/triage accepted
/assign
is this just a matter of getting a "yes" from someone on SIG Node to confirm that is GA? It seems to be as you mentioned, since 1.17 () but let me know if we need explicit confirmation and I'll chase it down.
Confirmed GA since 1.17 by Will update the page

Discussion:
### TaintNodesByCondition {#taintnodesbycondition} <del> {{< feature-state for_k8s_version="v1.12" state="beta" >}} </del> <ins> {{< feature-state for_k8s_version="v1.17" state="stable" >}} </ins> This admission controller {{< glossary_tooltip text="taints" term_id="taint" >}} newly created Nodes as `NotReady` and `NoSchedule`. That tainting avoids a race condition that could cause Pods to be scheduled on new Nodes before their taints were updated to accurately reflect their reported conditions.
Change:
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: As-is: is rendered like this: ! Proposed Solution: Add a separating blank line. To-be: Page to Update: /assign
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details

Discussion:
- Evicting all the pods from the node using graceful termination if the node continues to be unreachable. The default timeouts are 40s to start reporting ConditionUnknown and 5m after that to start evicting pods. The node controller checks the state of each node every `--node-monitor-period` seconds. #### Heartbeats

`--large-cluster-size-threshold` nodes - default 50), then evictions are stopped. - Otherwise, the eviction rate is reduced to `--secondary-node-eviction-rate` (default 0.01) per second. The reason these policies are implemented per availability zone is because one availability zone might become partitioned from the master while the others remain connected. If your cluster does not span multiple cloud provider availability zones,
Change:
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: Through the progress with many contributors, the content of got a little bit unclear. ] (Most of the sentences are updated about 3 years ago.) ] Let's call the sentence Consequently, a volume outlives any containers that run within the pod, and data is preserved across container restarts. "the sentence A". In the paragraphs of the current version, the sentences ahead of the sentence A is not a basis or reason of the sentence A. Proposed Solution: Page to Update: /assign
/triage accepted
/sig storage

Discussion:
Kubernetes supports many types of volumes. A {{< glossary_tooltip term_id="pod" text="Pod" >}} can use any number of volume types simultaneously. Ephemeral volume types have a lifetime of a pod, but persistent volumes exist beyond <del> the lifetime of a pod. Consequently, a volume outlives any containers that run within the pod, and data is preserved across container restarts. When a pod ceases to exist, Kubernetes destroys ephemeral volumes; however, Kubernetes does not destroy persistent volumes. </del> <ins> the lifetime of a pod. When a pod ceases to exist, Kubernetes destroys ephemeral volumes; however, Kubernetes does not destroy persistent volumes. For any kind of volume in a given pod, data is preserved across container restarts. </ins> At its core, a volume is just a directory, possibly with some data in it, which is accessible to the containers in a pod. How that directory comes to be, the
Change:
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: ! (One can find this error with regexp: ) Proposed Solution: The custom heading ID should include . () As-is: To-be: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/language zh /assign
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details

Discussion:
All code snippets in Windows sections are to be run in a PowerShell environment with elevated permissions (Administrator) on the Windows worker node. --> <del> ### 加入 Windows 工作节点   {joining-a-windows-worker-node} </del> <ins> ### 加入 Windows 工作节点   {#joining-a-windows-worker-node} </ins> 你必须安装 `Containers` 功能特性并安装 Docker 工具。相关的指令可以在 [Install Docker Engine - Enterprise on Windows Servers](https://hub.docker.com/editions/enterprise/docker-ee-server-windows)
Change:
This is a Bug Report Problem: The entire website is currently vunerable to clickjacking due to not having a proper header. This issue came to our attention via an email to the Code of Conduct Committee inbox. For more information on what a clickjacking attack is, see the following: Proposed Solution(s): Option 1: Easy, but not supported by all browsers Add a header to I recommend we use to do this, as that's simplest. This has the advantage of being easy to implement on a static site, but isn't supported by all browsers (yet). I think we should implement it regardless, and assume that it will be supported by all browsers in the near future. Option 2: more complicated, but currently supported Set an header. We need to do this : What to allow: In both cases, we want to allow at least the following: Any CDN we pull javascript from Any CDN we pull CSS from Youtube Google Analytics Discourse twitter Google Calendar I suspect there's more and I'm just not remembering it though.
/priority important-soon /triage accepted
/help
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /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 I feel like this has come up before in another issue. Will do some looking...
Also see
We could also set to allow frames; that feels like it would be OK.

Discussion:
# DO NOT REMOVE THIS (contact @kubernetes/sig-docs-leads) publish = "public" command = "git submodule update --init --recursive --depth 1 && make production-build" <ins> # adding in headers to prevent clickjacking [[headers]] for = "/*" [headers.values] X-Frame-Options = "DENY" X-XSS-Protection = "1; mode=block" </ins>
Change:
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 a couple of issues with existing wording: “master” should be read “control plane” versions aren't current. Proposed Solution: Replace that text with: Page to Update: Additional Information: /language en /kind bug /wg naming
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
/help If you're picking this up and want to be extra neat, replace those specific version numbers with shortcodes that automatically fill in based on the current release; for example:
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 </details
/assign

Discussion:
## {{% heading "prerequisites" %}} <del> You must use a kubectl version that is within one minor version difference of your cluster. For example, a v1.2 client should work with v1.1, v1.2, and v1.3 master. </del> <ins> You must use a kubectl version that is within one minor version difference of your cluster. For example, a v{{< skew latestVersion >}} client can communicate with v{{< skew prevMinorVersion >}}, v{{< skew latestVersion >}}, and v{{< skew nextMinorVersion >}} control planes. </ins> Using the latest version of kubectl helps avoid unforeseen issues. ## Install kubectl on Linux

## {{% heading "prerequisites" %}} <del> You must use a kubectl version that is within one minor version difference of your cluster. For example, a v1.2 client should work with v1.1, v1.2, and v1.3 master. </del> <ins> You must use a kubectl version that is within one minor version difference of your cluster. For example, a v{{< skew latestVersion >}} client can communicate with v{{< skew prevMinorVersion >}}, v{{< skew latestVersion >}}, and v{{< skew nextMinorVersion >}} control planes. </ins> Using the latest version of kubectl helps avoid unforeseen issues. ## Install kubectl on macOS

## {{% heading "prerequisites" %}} <del> You must use a kubectl version that is within one minor version difference of your cluster. For example, a v1.2 client should work with v1.1, v1.2, and v1.3 master. </del> <ins> You must use a kubectl version that is within one minor version difference of your cluster. For example, a v{{< skew latestVersion >}} client can communicate with v{{< skew prevMinorVersion >}}, v{{< skew latestVersion >}}, and v{{< skew nextMinorVersion >}} control planes. </ins> Using the latest version of kubectl helps avoid unforeseen issues. ## Install kubectl on Windows
Change:
They library is mildly defunct now The following project: has been forked and is meant to replace the former per Please update the documentation
Thanks for the suggestion I think we'd be happy to link to an extra project. I'm more wary of removing a project from the list because someone has forked it. If were marked as archived, it'd be easy to agree with the removal. If not, well, maybe we should leave it in and let the reader decide.
OK, with the understanding that we'll add an extra link but won't remove the old one: /triage accepted /language en
/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

Discussion:
| Python               | [github.com/Frankkkkk/pykorm](https://github.com/Frankkkkk/pykorm) | | Ruby                 | [github.com/abonas/kubeclient](https://github.com/abonas/kubeclient) | | Ruby                 | [github.com/Ch00k/kuber](https://github.com/Ch00k/kuber) | <ins> | Ruby                 | [github.com/k8s-ruby/k8s-ruby](https://github.com/k8s-ruby/k8s-ruby) | </ins> | Ruby                 | [github.com/kontena/k8s-client](https://github.com/kontena/k8s-client) | | Rust                 | [github.com/clux/kube-rs](https://github.com/clux/kube-rs) | | Rust                 | [github.com/ynqa/kubernetes-rust](https://github.com/ynqa/kubernetes-rust) |

| Elixir               | [github.com/coryodaniel/k8s](https://github.com/coryodaniel/k8s) |
Change:
links to in the table, but does not exist. Probably it should be linked to another page?
/triage accepted /kind bug /assign

Discussion:
## Resource Types - [KubeProxyConfiguration](#kubeproxy-config-k8s-io-v1alpha1-KubeProxyConfiguration)

<ins> ## `ClientConnectionConfiguration`     {#ClientConnectionConfiguration} **Appears in:** - [KubeProxyConfiguration](#kubeproxy-config-k8s-io-v1alpha1-KubeProxyConfiguration) ClientConnectionConfiguration contains details for constructing a client. <table class="table"> <thead><tr><th width="30%">Field</th><th>Description</th></tr></thead> <tbody> <tr><td><code>kubeconfig</code> <B>[Required]</B><br/> <code>string</code> </td> <td> kubeconfig is the path to a KubeConfig file.</td> </tr> <tr><td><code>acceptContentTypes</code> <B>[Required]</B><br/> <code>string</code> </td> <td> acceptContentTypes defines the Accept header sent by clients when connecting to a server, overriding the default value of 'application/json'. This field will control all connections to the server used by a particular client.</td> </tr> <tr><td><code>contentType</code> <B>[Required]</B><br/> <code>string</code> </td> <td> contentType is the content type used when sending data to the server from this client.</td> </tr> <tr><td><code>qps</code> <B>[Required]</B><br/> <code>float32</code> </td> <td> qps controls the number of queries per second allowed for this connection.</td> </tr> <tr><td><code>burst</code> <B>[Required]</B><br/> <code>int32</code> </td> <td> burst allows extra queries to accumulate when a client is exceeding its rate.</td> </tr> </tbody> </table> </ins>
Change:
Hi, I've tested this example : It returns image names double, because "{..image}" recursively search in the output of JSON, So at the first, it will find the "image" word in "" and at the second time, it will find the "image" word in "". It means you will see the image name two times for each pod at least. Please change your example. Best Regards, Alireza Bahmani.
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Hi What's the URL of the page where you've seen a problem?
here are the links to the: kubernetes docs website page ~ markdown file(s) where it require changes ~
The issue is, the following command produces 2 times (the count of image in a single pod). As mentioned, it is because the command count both the occurrence from the & sections from a single pod json manifest. Ideally it should be:
Following could be one of the fix for it:
/assign
There are other references . These would return duplicate images as well, right? I've updated those as well for now.
Hi yes, I feel those also need to be fixed. Let's wait for to provide their review. :)

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

- Use `uniq` to aggregate image counts ```shell <del> kubectl get pods --all-namespaces -o jsonpath="{..image}" | </del> <ins> kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" | </ins> tr -s '[[:space:]]' 'n' | sort | uniq -c

following matches only Pods with labels matching `app=nginx`. ```shell <del> kubectl get pods --all-namespaces -o=jsonpath="{..image}" -l app=nginx </del> <ins> kubectl get pods --all-namespaces -o=jsonpath="{.items[*].spec.containers[*].image}" -l app=nginx </ins> ``` ## List Container images filtering by Pod namespace

following matches only Pods in the `kube-system` namespace. ```shell <del> kubectl get pods --namespace kube-system -o jsonpath="{..image}" </del> <ins> kubectl get pods --namespace kube-system -o jsonpath="{.items[*].spec.containers[*].image}" </ins> ``` ## List Container images using a go-template instead of jsonpath
Change:
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
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

Discussion:
<ins> --- title: 新しいコンテンツの貢献 weight: 20 --- </ins>

<ins> --- title: 新しいコンテンツの貢献の概要 linktitle: 概要 content_type: concept main_menu: true weight: 5 --- <!-- overview --> このセクションでは、新しいコンテンツの貢献を行う前に知っておくべき情報を説明します。 <!-- body --> ## 貢献の基本 - KubernetesのドキュメントはMarkdownで書き、Kubernetesのウェブサイトは[Hugo](https://gohugo.io/)を使ってビルドします。 - ソースは[GitHub](https://github.com/kubernetes/website)にあります。Kubernetesのドキュメントは`/content/en/docs/`にあります。リファレンスドキュメントの一部は、`update-imported-docs/`ディレクトリ内のスクリプトから自動的に生成されます。 - [Page content types](/docs/contribute/style/page-content-types/)にHugoによるドキュメントのコンテンツの見え方を記述しています。 - 標準のHugoのshortcodeに加えて、多数の[カスタムのHugo shortcode](/docs/contribute/style/hugo-shortcodes/)を使用してコンテンツの見え方をコントロールしています。 - ドキュメントのソースは`/content/`内にある複数の言語で利用できます。各言語はそれぞれ[ISO 639-1標準](https://www.loc.gov/standards/iso639-2/php/code_list.php)で定義された2文字のコードの名前のフォルダを持ちます。たとえば、英語のドキュメントのソースは`/content/en/docs/`内に置かれています。 - 複数言語でのドキュメントへの貢献や新しい翻訳の開始に関する情報については、[Kubernetesのドキュメントを翻訳する](/docs/contribute/localization)を参照してください。 ## 始める前に {#before-you-begin} ### CNCF CLAに署名する {#sign-the-cla} すべてのKubernetesのコントリビューターは、[コントリビューターガイド](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md)を読み、[Contributor License Agreement(コントリビューターライセンス契約、CLA)への署名](https://github.com/kubernetes/community/blob/master/CLA.md)を**必ず行わなければなりません**。 CLAへの署名が完了していないコントリビューターからのpull requestは、自動化されたテストで失敗します。名前とメールアドレスは`git config`コマンドで表示されるものに一致し、gitの名前とメールアドレスはCNCF CLAで使われたものに一致しなければなりません。 ### どのGitブランチを使用するかを選ぶ pull requestをオープンするときは、どのブランチをベースにして作業するかをあらかじめ知っておく必要があります。 シナリオ | ブランチ :---------|:------------ 現在のリリースに対する既存または新しい英語のコンテンツ | `master` 機能変更のリリースに対するコンテンツ | 機能変更が含まれるメジャーおよびマイナーバージョンに対応する、`dev-<version>`というパターンのブランチを使います。たとえば、機能変更が`v{{< skew nextMinorVersion >}}`に含まれる場合、ドキュメントの変更は``dev-{{< skew nextMinorVersion >}}``ブランチに追加します。 他の言語内のコンテンツ(翻訳) | 各翻訳対象の言語のルールに従います。詳しい情報は、[翻訳のブランチ戦略](/docs/contribute/localization/#branching-strategy)を読んでください。 それでも選ぶべきブランチがわからないときは、Slack上の`#sig-docs`チャンネルで質問してください。 {{< note >}} すでにpull requestを作成していて、ベースブランチが間違っていたことに気づいた場合は、作成者であるあなただけがベースブランチを変更できます。 {{< /note >}} ### 言語ごとのPR pull requestはPRごとに1つの言語に限定してください。複数の言語に同一の変更を行う必要がある場合は、言語ごとに別々のPRを作成してください。 ## コントリビューターのためのツール `kubernetes/website`リポジトリ内の[doc contributors tools](https://github.com/kubernetes/website/tree/master/content/en/docs/doc-contributor-tools)ディレクトリには、コントリビューターとしての旅を楽にしてくれるツールがあります。 </ins>