jiebi/CodeConvo huggingface dataset:
Code change:
<ins> --- no_issue: true title: Instalação main_menu: true weight: 30 content_type: concept --- <!-- overview --> Essa seção lista as diferentes formas de instalar e executar o Kubernetes. Quando você realiza a instalação de um cluster Kubernetes, deve decidir o tipo de instalação baseado em critérios como facilidade de manutenção, segurança, controle, quantidade de recursos disponíveis e a experiência necessária para gerenciar e operar o cluster. Você pode criar um cluster Kubernetes em uma máquina local, na nuvem, em um datacenter on-premises ou ainda escolher uma oferta de um cluster Kubernetes gerenciado pelo seu provedor de computação em nuvem. Existem ainda diversos outros tipos de soluções customizadas, que você pode se deparar ao buscar formas de instalação e gerenciamento de seu cluster. <!-- body --> ## Ambientes de aprendizado Se você está aprendendo ou pretende aprender mais sobre o Kubernetes, use ferramentas suportadas pela comunidade, ou ferramentas no ecossistema que te permitam criar um cluster Kubernetes em sua máquina virtual. Temos como exemplo aqui o [Minikube](/docs/tasks/tools/install-minikube/) e o [KinD](https://kind.sigs.k8s.io/docs/user/quick-start/) ## Ambientes de produção Ao analisar uma solução para um ambiente de produção, devem ser considerados quais aspectos de operação de um cluster Kubernetes você deseja gerenciar, ou então delegar ao seu provedor. Temos diversas opções para esse provisionamento, desde o uso de uma ferramenta de deployment de um cluster tal qual o [Kubeadm](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/) ou o [Kubespray](/docs/setup/production-environment/tools/kubespray/) quando se trata de um cluster local, ou ainda o uso de um cluster gerenciado por seu provedor de nuvem. Para a escolha do melhor ambiente e da melhor forma para fazer essa instalação, você deve considerar: * Se você deseja se preocupar com a gestão de backup da sua estrutura do ambiente de gerenciamento * Se você deseja ter um cluster mais atualizado, com novas funcionalidades, ou se deseja seguir a versão suportada pelo fornecedor * Se você deseja ter um cluster com um alto nível de serviço, ou com auto provisionamento de alta disponibilidade * Quanto você deseja pagar por essa produção </ins>

Related discussion:
text: 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: is giving 404 Proposed Solution: if doesn't have the pt version Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/assign
Code change:
name: game-config namespace: default resourceVersion: "516" <del> selfLink: /api/v1/namespaces/default/configmaps/game-config-2 </del> <ins> selfLink: /api/v1/namespaces/default/configmaps/game-config </ins> uid: b4952dc3-d670-11e5-8cd0-68f728db1985 ```

Related discussion:
text: <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!--Required Information--The typo in the example. The first "game-config-2" shall be "game-config"? <!-- choose one by changing [ ] to [x] --- [ ] Feature Request [x] Bug Report Problem: The typo in the example. The first "game-config-2" shall be "game-config"? I believe the game-config-2 is the name of configuremap in 2nd example. Proposed Solution: Change the first "game-config-2" shall be "game-config"? Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
kubectl describe configmaps game-config Name: game-config Namespace: default Labels: <noneAnnotations: <noneData game.properties: 158 bytes ui.properties: 83 bytes The game.properties and ui.properties files in the docs/user-guide/configmap/kubectl/ directory are represented in the data section of the ConfigMap. kubectl get configmaps game-config-2 -o yaml
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
Code change:
placement policies while keeping the abstraction free from explicit placement directives. <ins> For detailed information on resource management, please refer to the [Resource Management for Pods and Containers](/docs/concepts/configuration/manage-resources-containers) documentation. </ins> ## {{% heading "prerequisites" %}}

Related discussion:
text: Add a link that explains how the limits are enforced at the OS level. For example, a) How the "shared CPU" is allocated between various running containers? (e.g., how they differ from multiple java processes running on a plain vanilla CentOS VM running without k8s) b) What are the background processes that are managing these quota limits? (both k8s and OS processes)? c) How much resources are consumed by these background processes, compared to (a), (20%, 40%, 50%)? d) Can some of these managerial quota processes be turned off (e.g, to let OS handle the CPU sharing)? If yes, then how? If no, then why not?
Which page do you want to update? Do you have a link which redirects to the desired site ?
this is the page which mentions in issue link also . PTAL
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs 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 or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs 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 or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR 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 and PRs.
Code change:
placement policies while keeping the abstraction free from explicit placement directives. <ins> For detailed information on resource management, please refer to the [Resource Management for Pods and Containers](/docs/concepts/configuration/manage-resources-containers) documentation. </ins> ## {{% heading "prerequisites" %}}

Related discussion:
text: This bot triages issues and PRs 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 or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
/remove-lifecycle rotten
How about linking to /triage accepted /language en /priority backlog
/assign
Code change:
### Docker <!-- <del> 1. On each of your nodes, install the Docker for your Linux distribution as per [Install Docker Engine](https://docs.docker.com/engine/install/#server). You can find the latest validated version of Docker in this [dependencies](https://git.k8s.io/kubernetes/build/dependencies.yaml) file. </del> <ins> 1. On each of your nodes, install the Docker for your Linux distribution as per [Install Docker Engine](https://docs.docker.com/engine/install/#server). You can find the latest validated version of Docker in this [dependencies](https://git.k8s.io/kubernetes/build/dependencies.yaml) file. </ins> --> 1. 在每个节点上，根据[安装 Docker 引擎](https://docs.docker.com/engine/install/#server) 为你的 Linux 发行版安装 Docker。

Related discussion:
text: ! w sudo systemctl enable crio --now
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
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: Typo in zh/docs/setup/production-environment/container-runtimes Proposed Solution: -Page to Update: zh: (en: ) <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/retitle [zh] Typo in docs/setup/production-environment/container-runtimes /kind bug /language zh
Page is a little bit lagging behind. Will fix. /assign
Code change:
| strategic-merge-patch | The new endpoints support PATCH with `Content-Type: application/strategic-merge-patch+json`. Useful for updating objects that may be modified both locally, and by the server. For more information, see ["Update API Objects in Place Using kubectl patch"](/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/) | No | Yes | | Protocol Buffers | The new resource supports clients that want to use Protocol Buffers | No | Yes | | OpenAPI Schema | Is there an OpenAPI (swagger) schema for the types that can be dynamically fetched from the server? Is the user protected from misspelling field names by ensuring only allowed fields are set? Are types enforced (in other words, don't put an `int` in a `string` field?) | Yes, based on the [OpenAPI v3.0 validation](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation) schema (GA in 1.16). | Yes | <ins> | Instance Name | Does this extension mechanism impose any constraints on the names of objects whose kind/resource is defined this way? | Yes, such an object's name must be a valid DNS subdomain name. | No | </ins> ### Common Features

Related discussion:
text: 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: I wondered what are the restrictions (if any) that Kubernetes imposes on the names of objects of a kind that gets defined by a CustomResourceDefinition. I am not talking about the name of the CRD itself. I tried to find this in the documentation, and couldn't. I asked on the channel on the Kubernetes Slack, and was referred to . The text there says Since a CRD is itself an object, I thought this was clearly talking about the name of the CRD itself (I temporarily forgot that I know that the name of the CRD itself is constrained to be ). But I was assured that this text is trying to talk about the objects whose kind is defined by the CRD. Proposed Solution: Update the cited doc to be clearer. Page to Update:
/sig docs /language en
/triage accepted /wg api-expression Since a CRD is itself an object, I thought this was clearly talking about the name of the CRD itself Yes, that's right. Both I and confirm this; I'm an emeritus tech lead for SIG Docs, and is a current tech lead. (sic) Would be good to add that detail to the page.
Code change:
```shell kubectl apply -f services.yaml ``` <ins> 実行結果は下記のようになります。 </ins> ``` service/myservice created service/mydb created

Related discussion:
text: 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 <!-- Describe as precisely as possible how this feature/enhancement should work from the user perspective. What should be changed, etc. --Updated Japanese translation for the file. Why is this needed There are several updates in and therefore this page is outdated. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/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
Code change:
`Guaranteed` pods are guaranteed only when requests and limits are specified for all the containers and they are equal. These pods will never be evicted because of another pod's resource consumption. If a system daemon (such as `kubelet`, <del> `docker`, and `journald`) is consuming more resources than were reserved via </del> <ins> and `journald`) is consuming more resources than were reserved via </ins> `system-reserved` or `kube-reserved` allocations, and the node only has `Guaranteed` or `Burstable` pods using less resources than requests left on it, then the kubelet must choose to evict one of these pods to preserve node stability

Related discussion:
text: There is a bug: ,%E8%AE%BE%E4%B8%BA%20%2D997%E3%80%82 ""'s hyperlink status is 404, it should be changed 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
/language zh /kind bug
/assign
Code change:
1. Download the latest release with the command: <del> ```bash </del> <ins> {{< tabs name="download_convert_binary_linux" >}} {{< tab name="x86-64" codelang="bash" >}} </ins> curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl-convert" <del> ``` </del> <ins> {{< /tab >}} {{< tab name="ARM64" codelang="bash" >}} curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/arm64/kubectl-convert" {{< /tab >}} {{< /tabs >}} </ins> 1. Validate the binary (optional) Download the kubectl-convert checksum file: <del> ```bash </del> <ins> {{< tabs name="download_convert_checksum_linux" >}} {{< tab name="x86-64" codelang="bash" >}} </ins> curl -LO "https://dl.k8s.io/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl-convert.sha256" <del> ``` </del> <ins> {{< /tab >}} {{< tab name="ARM64" codelang="bash" >}} curl -LO "https://dl.k8s.io/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/arm64/kubectl-convert.sha256" {{< /tab >}} {{< /tabs >}} </ins> Validate the kubectl-convert binary against the checksum file:

Related discussion:
text: The page assumes one is using and as an architecture. The download commands won't work for e.g. / .
/kind bug /retitle kubectl download page for Linux assumes amd64 architecture
/language en /triage accepted /priority important-longterm Thanks for filing this
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs 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 or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR 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 and PRs. This bot triages issues and PRs 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 or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
The issue has been marked as an important bug and triaged. Such issues are automatically marked as frozen when hitting the rotten state to avoid missing important bugs. Please send feedback to sig-contributor-experience at . /lifecycle frozen
/assign
Code change:
--- title: Workload <del> id: workloads </del> <ins> id: workload </ins> date: 2019-02-13 full_link: /docs/concepts/workloads/ short_description: >

Related discussion:
text: This is a Bug Report Problem: Glossary term id and title must be same as per the current design. But for Glossary , term id is documented wrongly as whereas title and file name is . Proposed Solution: Update term id from workloads to . Page to Update: <!--Additional Information:--
/language en /sig docs /assign
I don't think this is true. We prefer it if the term ID and the display text are similar though.
Hi ok, might be my understanding is wrong on it. But i was verifying the existing Glossary items, most of them are documented term id and title are same. Also if we use term id as in PR, build is getting fail and giving error as invalid term id "workloads". Test cases are accepting only if we mention term id as . is the related error, Thanks.
Looks like a bug, isn't it?
Hi Yes, but I'm not sure if the bug is in the documentation or in the test cases. First, we must determine the correct term id among these two (workload/workloads), and then only we can proceed.
I've gone through the other files in the and noticed a pattern that the id most often matches with the title itself. Hence for this, I believe workload should work fine. However, I'm not sure why a change in the id is leading to CI failure?
The glossary shortcode does care about the field? I don't think so. That is the reason why referencing the field rather than the file name sometimes failed.
Any updates onto it?
I looked up what is for: it's the fragment identifier on the glossary page.
The following is from the shortcode. is the variable used in the shortcode, then it is used to generate the file name of the glossary. The code never extract the in the glossary entry, right?
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 .
Code change:
--- title: Workload <del> id: workloads </del> <ins> id: workload </ins> date: 2019-02-13 full_link: /docs/concepts/workloads/ short_description: >

Related discussion:
text: /lifecycle stale [1]:
If we look at this, here it is trying to match which doesn't exist. That's why the error is comming if i am not wrong. What do you suggest to be done?
/remove-lifecycle stale
SIG Docs: Can you please have a look into this as its waiting since many days.
Is there are fix proposal for this? /triage accepted
/assign
IMO we can change id to that will exactly match with existing filename which can fix the issue. I will propose a PR if OK.
PR raised
Code change:
The output is similar to this: <del> NAME                      READY   UP-TO-DATE   AVAILABLE   AGE </del> <ins> NAME                   READY   UP-TO-DATE   AVAILABLE   AGE </ins> ... <del> dns-autoscaler            1/1     1            1           ... </del> <ins> kube-dns-autoscaler    1/1     1            1           ... </ins> ... <del> If you see "dns-autoscaler" in the output, DNS horizontal autoscaling is </del> <ins> If you see "kube-dns-autoscaler" in the output, DNS horizontal autoscaling is </ins> already enabled, and you can skip to [Tuning autoscaling parameters](#tuning-autoscaling-parameters).

Related discussion:
text: dns-horizontal- kube-dns-autoscaler dns-autoscaler 2
/language zh
please describe the issue in English
page related to the issue:
/triage needs-information
Translate to English: The kube-dns-autoscaler used in dns-horizontal- and the dns-autoscaler used in subsequent commands are confused and out of sync. It seems that the English version also has this problem. /triage accepted /kind bug /retitle Inconsistent name in the DNS horizontal autoscaling example
/language en
/assign
Code change:
<ins> You need to have shell access to all the nodes, and the kubectl command-line tool must 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. </ins>

Related discussion:
text: Missing important step new people SSH into the node
/language en
Hi could you please explain the issue in detail. /triage needs-information
Page mentioned in the issue (based on the title): /language en
/retitle Users not instructed to SSH into the node before executing commands in "Upgrading Linux nodes" page
/sig cluster-lifecycle
I'm not sure this is valid, though there isn't much detail to the issue to explain what the concern is. The commands on that page need to be run on the node being upgraded, but I think how the administrator connects to that node is out of scope. It may be SSH, it may be by accessing the cloud providers console. It may be by rolling up a crash cart and plugging in a monitor and keyboard. That all depends on the individuals environment.
/remove-triage needs-information
/remove-kind support /priority awaiting-more-evidence /kind feature /sig cluster-lifecycle
Those labels are not set on the issue: <detailsIn response to : /remove-kind support /priority awaiting-more-evidence /kind feature /sig cluster-lifecycle 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
My opinion: if you (the reader) don't know how to get a shell on a node, it may not be a good idea to try upgrading it. Best learn the basics first.
We could list “shell access to the node“ as a prerequisite. I don't think we can or should assume SSH; I'm barely happy that we assume superuser access comes via .
for new contributors. page to update: change: to: make sure you add in the PR description. /help /triage accepted
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.