jiebi/CodeConvo huggingface dataset:
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
/close
Closing this issue. <detailsIn response to : /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

Discussion:
<ins> --- title: huge pageを管理する content_type: task description: クラスター内のスケジュール可能なリソースとしてhuge pageの設定と管理を行います。 --- <!-- overview --> {{< feature-state state="stable" >}} Kubernetesでは、事前割り当てされたhuge pageをPod内のアプリケーションに割り当てたり利用したりすることをサポートしています。このページでは、ユーザーがhuge pageを利用できるようにする方法について説明します。 ## {{% heading "prerequisites" %}} 1. Kubernetesのノードがhuge pageのキャパシティを報告するためには、ノード上でhuge pageを事前割り当てしておく必要があります。1つのノードでは複数のサイズのhuge pageが事前割り当てできます。 ノードは、すべてのhuge pageリソースを、スケジュール可能なリソースとして自動的に探索・報告してくれます。 <!-- steps --> ## API huge pageはコンテナレベルのリソース要求で`hugepages-<size>`という名前のリソースを指定することで利用できます。ここで、`<size>`は、特定のノード上でサポートされている整数値を使った最も小さなバイナリ表記です。たとえば、ノードが2048KiBと1048576KiBのページサイズをサポートしている場合、ノードはスケジュール可能なリソースとして、`hugepages-2Mi`と`hugepages-1Gi`の2つのリソースを公開します。CPUやメモリとは違い、huge pageはオーバーコミットをサポートしません。huge pageリソースをリクエストするときには、メモリやCPUリソースを同時にリクエストしなければならないことに注意してください。 1つのPodのspec内に書くことで、Podから複数のサイズのhuge pageを利用することもできます。その場合、すべてのボリュームマウントで`medium: HugePages-<hugepagesize>`という表記を使う必要があります。 ```yaml apiVersion: v1 kind: Pod metadata: name: huge-pages-example spec: containers: - name: example image: fedora:latest command: - sleep - inf volumeMounts: - mountPath: /hugepages-2Mi name: hugepage-2mi - mountPath: /hugepages-1Gi name: hugepage-1gi resources: limits: hugepages-2Mi: 100Mi hugepages-1Gi: 2Gi memory: 100Mi requests: memory: 100Mi volumes: - name: hugepage-2mi emptyDir: medium: HugePages-2Mi - name: hugepage-1gi emptyDir: medium: HugePages-1Gi ``` Podで1種類のサイズのhuge pageをリクエストするときだけは、`medium: HugePages`という表記を使うこともできます。 ```yaml apiVersion: v1 kind: Pod metadata: name: huge-pages-example spec: containers: - name: example image: fedora:latest command: - sleep - inf volumeMounts: - mountPath: /hugepages name: hugepage resources: limits: hugepages-2Mi: 100Mi memory: 100Mi requests: memory: 100Mi volumes: - name: hugepage emptyDir: medium: HugePages ``` - huge pageのrequestsはlimitsと等しくなければなりません。limitsを指定した場合にはこれがデフォルトですが、requestsを指定しなかった場合にはデフォルトではありません。 - huge pageはコンテナのスコープで隔離されるため、各コンテナにはそれぞれのcgroupサンドボックスの中でcontainer specでリクエストされた通りのlimitが設定されます。 - huge pageベースのEmptyDirボリュームは、Podがリクエストしたよりも大きなサイズのページメモリーを使用できません。 - `shmget()`に`SHM_HUGETLB`を指定して取得したhuge pageを使用するアプリケーションは、`/proc/sys/vm/hugetlb_shm_group`に一致する補助グループ(supplemental group)を使用して実行する必要があります。 - namespace内のhuge pageの使用量は、ResourceQuotaに対して`cpu`や`memory`のような他の計算リソースと同じように`hugepages-<size>`というトークンを使用することで制御できます。 - 複数のサイズのhuge pageのサポートはフィーチャーゲートによる設定が必要です。{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}と{{< glossary_tooltip text="kube-apiserver" term_id="kube-apiserver" >}}上で、`HugePageStorageMediumSize`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を使用すると有効にできます(`--feature-gates=HugePageStorageMediumSize=true`)。 </ins>
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
/close
Closing this issue. <detailsIn response to : /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

Discussion:
<ins> --- title: "TLS" weight: 100 description: Transport Layer Security(TLS)を使用して、クラスター内のトラフィックを保護する方法について理解します。 --- </ins>

<ins> --- title: Kubeletの証明書のローテーションを設定する content_type: task --- <!-- overview --> このページでは、kubeletの証明書のローテーションを設定する方法を説明します。 {{< feature-state for_k8s_version="v1.8" state="beta" >}} ## {{% heading "prerequisites" %}} * Kubernetesはバージョン1.8.0以降である必要があります。 <!-- steps --> ## 概要 kubeletは、Kubernetes APIへの認証のために証明書を使用します。デフォルトでは、証明書は1年間の有効期限付きで発行されるため、頻繁に更新する必要はありません。 Kubernetes 1.8にはベータ機能の[kubelet certificate rotation](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)が含まれているため、現在の証明書の有効期限が近づいたときに自動的に新しい鍵を生成して、Kubernetes APIに新しい証明書をリクエストできます。新しい証明書が利用できるようになると、Kubernetes APIへの接続の認証に利用されます。 ## クライアント証明書のローテーションを有効にする `kubelet`プロセスは`--rotate-certificates`という引数を受け付けます。この引数によって、現在使用している証明書の有効期限が近づいたときに、kubeletが自動的に新しい証明書をリクエストするかどうかを制御できます。証明書のローテーションはベータ機能であるため、`--feature-gates=RotateKubeletClientCertificate=true`を使用してフィーチャーフラグを有効にする必要もあります。 `kube-controller-manager`プロセスは、`--experimental-cluster-signing-duration`という引数を受け付け、この引数で証明書が発行される期間を制御できます。 ## 証明書のローテーションの設定を理解する kubeletが起動すると、ブートストラップが設定されている場合(`--bootstrap-kubeconfig`フラグを使用した場合)、初期証明書を使用してKubernetes APIに接続して、証明書署名リクエスト(certificate signing request、CSR)を発行します。証明書署名リクエストのステータスは、次のコマンドで表示できます。 ```sh kubectl get csr ``` ノード上のkubeletから発行された証明書署名リクエストは、初めは`Pending`状態です。証明書署名リクエストが特定の条件を満たすと、コントローラーマネージャーに自動的に承認され、`Approved`状態になります。次に、コントローラーマネージャーは`--experimental-cluster-signing-duration`パラメーターで指定された有効期限で発行された証明書に署名を行い、署名された証明書が証明書署名リクエストに添付されます。 kubeletは署名された証明書をKubernetes APIから取得し、ディスク上の`--cert-dir`で指定された場所に書き込みます。その後、kubeletは新しい証明書を使用してKubernetes APIに接続するようになります。 署名された証明書の有効期限が近づくと、kubeletはKubernetes APIを使用して新しい証明書署名リクエストを自動的に発行します。再び、コントローラーマネージャーは証明書のリクエストを自動的に承認し、署名された証明書を証明書署名リクエストに添付します。kubeletは新しい署名された証明書をKubernetes APIから取得してディスクに書き込みます。その後、kubeletは既存のコネクションを更新して、新しい証明書でKubernetes APIに再接続します。 </ins>
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

Discussion:
<ins> --- title: Limit Range content_type: concept weight: 10 --- <!-- overview --> デフォルトでは、コンテナは、Kubernetesクラスター上の[計算リソース](/docs/concepts/configuration/manage-resources-containers/)の消費を制限されずに実行されます。リソースクォータを利用すれば、クラスター管理者はリソースの消費と作成を{{< glossary_tooltip text="名前空間" term_id="namespace" >}}ベースで制限することができます。名前空間内では、Podやコンテナは名前空間のリソースクォータで定義された範囲内でできるだけ多くのCPUとメモリーを消費できてしまうため、1つのPodまたはコンテナが利用可能なすべてのリソースを専有してしまう恐れがあります。LimitRangeを利用すれば、このような名前空間内での(Podやコンテナへの)リソースの割り当てを制限するポリシーを定めることができます。 <!-- body --> *LimitRange*を利用すると、次のような制約を課せるようになります。 - 名前空間内のPodまたはコンテナごとに、計算リソースの使用量の最小値と最大値を強制する。 - 名前空間内のPersistentVolumeClaimごとに、ストレージリクエストの最小値と最大値を強制する。 - 名前空間内で、リソースのrequestとlimitの割合を強制する。 - 名前空間内の計算リソースのデフォルトのrequest/limitの値を設定して、実行時にコンテナに自動的に注入する。 ## LimitRangeを有効にする Kubernetes 1.10以降では、LimitRangeのサポートはデフォルトで有効になりました。 LimitRangeが特定の名前空間内で強制されるのは、その名前空間内にLimitRangeオブジェクトが存在する場合です。 LimitRangeオブジェクトの名前は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)でなければなりません。 ### Limit Rangeの概要 - 管理者は、1つの名前空間に1つのLimitRangeを作成します。 - ユーザーは、Pod、コンテナ、PersistentVolumeClaimのようなリソースを名前空間内に作成します。 - `LimitRanger`アドミッションコントローラーは、計算リソース要求が設定されていないすべてのPodとコンテナに対して、デフォルト値と制限値を強制します。そして、リソースの使用量を追跡し、名前空間内に存在するすべてのLimitRangeで定義された最小値、最大値、割合を外れないことを保証します。 - LimitRangeの制約を破るようなリソース(Pod、コンテナ、PersistentVolumeClaim)の作成や更新を行うと、APIサーバーへのリクエストがHTTPステータスコード`403 FORBIDDEN`で失敗し、破られた制約を説明するメッセージが返されます。 - 名前空間内でLimitRangeが`cpu`や`memory`などの計算リソースに対して有効になっている場合、ユーザーはrequestsやlimitsに値を指定しなければなりません。指定しなかった場合、システムはPodの作成を拒否する可能性があります。 - LimitRangeの検証は、Podのアドミッションステージでのみ発生し、実行中のPodでは発生しません。 以下は、LimitRangeを使用して作成できるポリシーの例です。 - 8GiBのRAMと16コアのCPUの容量がある2ノードのクラスター上で、名前空間内のPodに対して、CPUには100mのrequestと最大500mのlimitの制約を課し、メモリーには200Miのrequestと600Miのlimitの制約を課す。 - Spec内のrequestsにcpuやmemoryを指定せずに起動したコンテナに対して、CPUにはデフォルトで150mのlimitとrequestを、メモリーにはデフォルトで300Miのrequestをそれぞれ定義する。 名前空間のlimitの合計が、Podやコンテナのlimitの合計よりも小さくなる場合、リソースの競合が起こる可能性があります。その場合、コンテナやPodは作成されません。 LimitRangeに対する競合や変更は、すでに作成済みのリソースに対しては影響しません。 ## {{% heading "whatsnext" %}} より詳しい情報は、[LimitRangerの設計ドキュメント](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md)を参照してください。 制限の使用例については、以下のページを読んでください。 - [名前空間ごとにCPUの最小値と最大値の制約を設定する方法](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)。 - [名前空間ごとにメモリーの最小値と最大値の制約を設定する方法](/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)。 - [名前空間ごとにCPUのRequestとLimitのデフォルト値を設定する方法](/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)。 - [名前空間ごとにメモリーのRequestとLimitのデフォルト値を設定する方法](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)。 - [名前空間ごとにストレージ消費量の最小値と最大値を設定する方法](/docs/tasks/administer-cluster/limit-storage-consumption/#limitrange-to-limit-requests-for-storage)。 - [名前空間ごとのクォータを設定する詳細な例](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)。 </ins>
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
/close
Closing this issue. <detailsIn response to : /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

Discussion:
<ins> --- title: Serviceトポロジーを有効にする content_type: task --- <!-- overview --> このページでは、Kubernetes上でServiceトポロジーを有効にする方法の概要について説明します。 ## {{% heading "prerequisites" %}} {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} <!-- steps --> ## はじめに *Serviceトポロジー*は、クラスターのノードのトポロジーに基づいてトラフィックをルーティングできるようにする機能です。たとえば、あるServiceのトラフィックに対して、できるだけ同じノードや同じアベイラビリティゾーン上にあるエンドポイントを優先してルーティングするように指定できます。 ## 前提 トポロジーを考慮したServiceのルーティングを有効にするには、以下の前提を満たしている必要があります。 * Kubernetesバージョン1.17以降である * {{< glossary_tooltip text="Kube-proxy" term_id="kube-proxy" >}}がiptableモードまたはIPVSモードで稼働している * [Endpoint Slice](/docs/concepts/services-networking/endpoint-slices/)を有効にしている ## Serviceトポロジーを有効にする {{< feature-state for_k8s_version="v1.17" state="alpha" >}} Serviceトポロジーを有効にするには、すべてのKubernetesコンポーネントで`ServiceTopology`と`EndpointSlice`フィーチャーゲートを有効にする必要があります。 ``` --feature-gates="ServiceTopology=true,EndpointSlice=true" ``` ## {{% heading "whatsnext" %}} * [Serviceトポロジー](/ja/docs/concepts/services-networking/service-topology)のコンセプトについて読む * [Endpoint Slice](/docs/concepts/services-networking/endpoint-slices)について読む * [サービスとアプリケーションの接続](/ja/docs/concepts/services-networking/connect-applications-service/)を読む </ins>
Change:
This is a Bug Report Inability to set kubelet Problem: As per Expected result Kubelet should point to the correct api-servers. Actual result kubelet cannot start because is not a valid option, since it was changed to Proposed Solution: Modify the documentation to create a kubeconfig file that points to the api servers . Page to Update: Kubernetes Version: v1.18.5
/language en /kind bug /assign
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale

Discussion:
## Running Node Conformance Test To run the node conformance test, perform the following steps: <del> 1. Point your Kubelet to localhost `--api-servers="http://localhost:8080"`, because the test framework starts a local master to test Kubelet. There are some other Kubelet flags you may care: </del> <ins> 1. Work out the value of the `--kubeconfig` option for the kubelet; for example: `--kubeconfig=/var/lib/kubelet/config.yaml`. Because the test framework starts a local control plane to test the kubelet, use `http://localhost:8080` as the URL of the API server. There are some other kubelet command line parameters you may want to use: </ins> * `--pod-cidr`: If you are using `kubenet`, you should specify an arbitrary CIDR to Kubelet, for example `--pod-cidr=10.180.0.0/24`. * `--cloud-provider`: If you are using `--cloud-provider=gce`, you should
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

Discussion:
<ins> --- title: HostAliasesを使用してPodの/etc/hostsにエントリーを追加する content_type: concept weight: 60 min-kubernetes-server-version: 1.7 --- <!-- overview --> Podの`/etc/hosts`ファイルにエントリーを追加すると、DNSやその他の選択肢を利用できない場合に、Podレベルでホスト名の名前解決を上書きできるようになります。このようなカスタムエントリーは、PodSpecのHostAliasesフィールドに追加できます。 HostAliasesを使用せずにファイルを修正することはおすすめできません。このファイルはkubeletが管理しており、Podの作成や再起動時に上書きされる可能性があるためです。 <!-- body --> ## デフォルトのhostsファイルの内容 Nginx Podを実行すると、Pod IPが割り当てられます。 ```shell kubectl run nginx --image nginx ``` ``` pod/nginx created ``` Pod IPを確認します。 ```shell kubectl get pods --output=wide ``` ``` NAME     READY     STATUS    RESTARTS   AGE    IP           NODE nginx    1/1       Running   0          13s    10.200.0.4   worker0 ``` hostsファイルの内容は次のようになります。 ```shell kubectl exec nginx -- cat /etc/hosts ``` ``` # Kubernetes-managed hosts file. 127.0.0.1	localhost ::1	localhost ip6-localhost ip6-loopback fe00::0	ip6-localnet fe00::0	ip6-mcastprefix fe00::1	ip6-allnodes fe00::2	ip6-allrouters 10.200.0.4	nginx ``` デフォルトでは、`hosts`ファイルには、`localhost`やPod自身のホスト名などのIPv4とIPv6のボイラープレートだけが含まれています。 ## 追加エントリーをhostAliasesに追加する デフォルトのボイラープレートに加えて、`hosts`ファイルに追加エントリーを追加できます。たとえば、`foo.local`と`bar.local`を`127.0.0.1`に、`foo.remote`と`bar.remote`を`10.1.2.3`にそれぞれ解決するためには、PodのHostAliasesを`.spec.hostAliases`以下に設定します。 {{< codenew file="service/networking/hostaliases-pod.yaml" >}} この設定を使用したPodを開始するには、次のコマンドを実行します。 ```shell kubectl apply -f https://k8s.io/examples/service/networking/hostaliases-pod.yaml ``` ``` pod/hostaliases-pod created ``` Podの詳細情報を表示して、IPv4アドレスと状態を確認します。 ```shell kubectl get pod --output=wide ``` ``` NAME                           READY     STATUS      RESTARTS   AGE       IP              NODE hostaliases-pod                0/1       Completed   0          6s        10.200.0.5      worker0 ``` `hosts`ファイルの内容は次のようになります。 ```shell kubectl logs hostaliases-pod ``` ``` # Kubernetes-managed hosts file. 127.0.0.1	localhost ::1	localhost ip6-localhost ip6-loopback fe00::0	ip6-localnet fe00::0	ip6-mcastprefix fe00::1	ip6-allnodes fe00::2	ip6-allrouters 10.200.0.5	hostaliases-pod # Entries added by HostAliases. 127.0.0.1	foo.local	bar.local 10.1.2.3	foo.remote	bar.remote ``` ファイルの最後に追加エントリーが指定されています。 ## kubeletがhostsファイルを管理するのはなぜですか？ {#why-does-kubelet-manage-the-hosts-file} kubeletがPodの各コンテナの`hosts`ファイルを[管理する](https://github.com/kubernetes/kubernetes/issues/14633)のは、コンテナ起動後にDockerがファイルを[編集する](https://github.com/moby/moby/issues/17190)のを防ぐためです。 {{< caution >}} コンテナ内部でhostsファイルを手動で変更するのは控えてください。 hostsファイルを手動で変更すると、コンテナが終了したときに変更が失われてしまいます。 {{< /caution >}} </ins>
Change:
It would be VERY helpful to know, that you have to download, extract, etc... the etcd binaries. Or that etcd will run as pods. The only point where this is mentioned is in the "optional" section... thank you!
hello, this is a valid request. PRs are welcome. this list here: could include something like: file to change: /sig cluster-lifecycle /kind feature /priority backlog /help /good-first-issue
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : hello, this is a valid request. PRs are welcome. file to change: /kind feature /priority backlog /help /good-first-issue </details
/assign
I think I can help with this, thank you.

Discussion:
document assumes these default ports. However, they are configurable through the kubeadm config file. * Each host must [have docker, kubelet, and kubeadm installed](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/). <ins> * Each host should have access to the Kubernetes container image registry (`k8s.gcr.io`) or list/pull the required etcd image using `kubeadm config images list/pull`. This guide will setup etcd instances as [static pods](https://kubernetes.io/docs/tasks/configure-pod-container/static-pod/) managed by a kubelet. </ins> * Some infrastructure to copy files between hosts. For example `ssh` and `scp` can satisfy this requirement.
Change:
This is a Bug Report As discussed in the SIG-Docs meeting, the current steps for building doc website in README is incomplete in the following point of views. It requires yarn on top of npm, but is missing and package- is there. did not work for me but I need further investigation on it. The build step is going to be equal in containerized and local in , but yarn installation or npm ci is currently missing in . <!--Required Information--Proposed Solution: and remove yarn from the dependency the npm command inside of the container Page to Update: N/A
Here's my cat picture after the sig-docs meeting lol !
AIUI, the live website build (within Netlify) relies on , and does not use Yarn.
/area web-development
Could you have a quick look if npm ci in local works just fine?
Yes, I believe so.
worked in my local environment
/kind bug /priority important-longterm
/sig contributor-experience I suppose

Discussion:
build-base  libc6-compat  npm &&  <del> npm install -G autoprefixer postcss-cli </del> <ins> npm install -D autoprefixer postcss-cli </ins> ARG HUGO_VERSION

--build-arg HUGO_VERSION=$(HUGO_VERSION) container-build: module-check <del> $(CONTAINER_RUN) --read-only $(CONTAINER_IMAGE) hugo --minify </del> <ins> $(CONTAINER_RUN) --read-only --mount type=tmpfs,destination=/tmp,tmpfs-mode=01777 $(CONTAINER_IMAGE) sh -c "npm ci && hugo --minify" </ins> container-serve: module-check $(CONTAINER_RUN) --read-only --mount type=tmpfs,destination=/tmp,tmpfs-mode=01777 -p 1313:1313 $(CONTAINER_IMAGE) hugo server --buildFuture --bind 0.0.0.0 --destination /tmp/hugo --cleanDestinationDir

To use this repository, you need the following installed locally: <del> - [yarn](https://yarnpkg.com/) </del> - [npm](https://www.npmjs.com/) - [Go](https://golang.org/) - [Hugo (Extended version)](https://gohugo.io/)

The Kubernetes website uses the [Docsy Hugo theme](https://github.com/google/docsy#readme). Even if you plan to run the website in a container, we strongly recommend pulling in the submodule and other development dependencies by running the following: ``` <del> # install dependencies yarn </del> # pull in the Docsy submodule git submodule update --init --recursive --depth 1 ```

To build and test the site locally, run: ```bash <ins> # install dependencies npm ci </ins> make serve ```
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: 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

Discussion:
requests: cpu: 700m memory: 200Mi <del> ... </del> <ins> ... status: </ins> qosClass: Guaranteed ```

memory: 200Mi requests: memory: 100Mi <del> ... </del> <ins> ... status: </ins> qosClass: Burstable ```

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

name: qos-demo-4-ctr-2 resources: {} ... <ins> status: </ins> qosClass: Burstable ```
Change:
This is a Bug Report Problem: cannot access the link destination of word. If click this link, 404 error. Page Link Link of "ServiceAccount" in sentence("However, setting of this field can be automated by setting the imagePullSecrets in a ServiceAccount resource.") Proposed Solution: I see this link path is worng. Page to Update: Additional Information: I found this while translating this page into Japanese. I found a fix that I think was correct and will register a modified PR. /language en /assign

Discussion:
This needs to be done for each pod that is using a private registry. However, setting of this field can be automated by setting the imagePullSecrets <del> in a [ServiceAccount](/docs/tasks/configure-pod-container/configure-service-accounts/) resource. </del> <ins> in a [ServiceAccount](/docs/tasks/configure-pod-container/configure-service-account/) resource. </ins> Check [Add ImagePullSecrets to a Service Account](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) for detailed instructions.
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: Line 260, should be removed from the link to PodDisruptionBudget: Read about [PodDisruptionBudget]() and how you can use it to manage application availability during disruptions. Proposed Solution: Read about [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/) and how you can use it to manage application availability during disruptions. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/language en
/assign

Discussion:
* Lean about [RuntimeClass](/docs/concepts/containers/runtime-class/) and how you can use it to configure different Pods with different container runtime configurations. * Read about [Pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/). <del> * Read about [PodDisruptionBudget](https://kubernetes.io/docs/concepts/workloads/pods/disruptions/) and how you can use it to manage application availability during disruptions. </del> <ins> * Read about [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/) and how you can use it to manage application availability during disruptions. </ins> * Pod is a top-level resource in the Kubernetes REST API. The [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core) object definition describes the object in detail.
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: Line 355: There is no description before the code. Line 1005: There is no description before the code. Proposed Solution: Line 355: You can view a description of the secret: Line 1005: You can also create a secret for test environment credentials. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/language en
/assign

Discussion:
db-user-pass-96mffmfh4k          Opaque                                2         51s ``` <ins> You can view a description of the secret: </ins> ```shell kubectl describe secrets/db-user-pass-96mffmfh4k ```

secret "prod-db-secret" created ``` <ins> You can also create a secret for test environment credentials. </ins> ```shell kubectl create secret generic test-db-secret --from-literal=username=testuser --from-literal=password=iluvtests ```