Question: ### Установка двоичного файла kubectl с помощью curl в Windows <del> 1. Загрузите последнюю версию {{< param "fullversion" >}} по [этой ссылке](https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe). </del> <ins> 1. Загрузите последнюю версию {{< param "fullversion" >}} по [этой ссылке](https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe). </ins> Либо, если у вас установлен `curl`, выполните команду ниже: ``` <del> curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe </del> <ins> curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe </ins> ``` <del> Последнюю стабильную версию (например, при написании скриптов) вы можете узнать из файла по ссылке [https://storage.googleapis.com/kubernetes-release/release/stable.txt](https://storage.googleapis.com/kubernetes-release/release/stable.txt). </del> <ins> Последнюю стабильную версию (например, при написании скриптов) вы можете узнать из файла по ссылке [https://dl.k8s.io/release/stable.txt](https://dl.k8s.io/release/stable.txt). </ins> 2. Переместите двоичный файл в директорию из переменной окружения PATH: 3. Убедитесь, что версия `kubectl` совпадает загружённой:

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: security mechanisms to make sure that users and workloads can get access to the resources they need, while keeping workloads, and the cluster itself, secure. You can set limits on the resources that users and workloads can access <del> by managing [policies](https://kubernetes.io/docs/concepts/policy/) and </del> <ins> by managing [policies](/docs/concepts/policy/) and </ins> [container resources](/docs/concepts/configuration/manage-resources-containers/). Before building a Kubernetes production environment on your own, consider

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


Question: **Notes:** <del> - Please refer to the [kubeadm reference guide](/docs/reference/setup-tools/kubeadm/) if you want to </del> <ins> - Please refer to the [kubeadm reference guide](/docs/reference/setup-tools/kubeadm/kubeadm/) if you want to </ins> read more about the flags `kubeadm init` provides. You can also specify a [configuration file](/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file) instead of using flags. - You need to choose a Pod Network Plugin in the next step. Depending on what

<!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!--Required Information--This is a... <!-- choose one by changing [ ] to [x] --- [ ] Feature Request [x ] Bug Report Problem: Link to kubeadm reference guide broken. In step (2/4) Initializing your master, the link here is broken: "Please refer to the kubeadm reference guide if you want to read ..." Proposed Solution: Page to Update: backed by: docs/setup/independent/create-cluster- <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--


Question: ### Accessing the cluster with a browser <del> We install two UIs on Kubernetes. The original KubeUI and [the newer kube dashboard](/docs/tasks/web-ui-dashboard/). When you create a cluster, the script should output URLs for these interfaces like this: KubeUI is running at ```https://${MASTER_IP}:6443/api/v1/namespaces/kube-system/services/kube-ui/proxy```. </del> <ins> We install [the kubernetes dashboard](/docs/tasks/web-ui-dashboard/). When you create a cluster, the script should output URLs for these interfaces like this: </ins> kubernetes-dashboard is running at ```https://${MASTER_IP}:6443/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy```.

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: kind: EncryptionConfiguration resources: - resources: <del> - secrets </del> <ins> - secrets </ins> providers: <del> - aescbc: keys: - name: key1 secret: <BASE 64 ENCODED SECRET> - identity: {} </del> <ins> - aescbc: keys: - name: key1 secret: <BASE 64 ENCODED SECRET> - identity: {} </ins> ``` <del> To create a new secret perform the following steps: </del> <ins> To create a new Secret, perform the following steps: </ins> <del> 1. Generate a 32 byte random key and base64 encode it. If you're on Linux or macOS, run the following command: </del> <ins> 1. Generate a 32-byte random key and base64 encode it. If you're on Linux or macOS, run the following command: </ins> ```shell head -c 32 /dev/urandom | base64 ``` <del> 2. Place that value in the secret field. 3. Set the `--encryption-provider-config` flag on the `kube-apiserver` to point to the location of the config file. 4. Restart your API server. </del> <ins> 1. Place that value in the `secret` field of the `EncryptionConfiguration` struct. 1. Set the `--encryption-provider-config` flag on the `kube-apiserver` to point to the location of the config file. 1. Restart your API server. </ins> {{< caution >}} <del> Your config file contains keys that can decrypt content in etcd, so you must properly restrict permissions on your masters so only the user who runs the kube-apiserver can read it. </del> <ins> Your config file contains keys that can decrypt the contents in etcd, so you must properly restrict permissions on your control-plane nodes so only the user who runs the `kube-apiserver` can read it. </ins> {{< /caution >}} ## Verifying that data is encrypted Data is encrypted when written to etcd. After restarting your `kube-apiserver`, any newly created or <del> updated secret should be encrypted when stored. To check, you can use the `etcdctl` command line program to retrieve the contents of your secret. </del> <ins> updated Secret should be encrypted when stored. To check this, you can use the `etcdctl` command line program to retrieve the contents of your Secret. </ins> <del> 1. Create a new secret called `secret1` in the `default` namespace: </del> <ins> 1. Create a new Secret called `secret1` in the `default` namespace: </ins> ```shell kubectl create secret generic secret1 -n default --from-literal=mykey=mydata ``` <del> 2. Using the etcdctl commandline, read that secret out of etcd: </del> <ins> 1. Using the `etcdctl` command line, read that Secret out of etcd: </ins> `ETCDCTL_API=3 etcdctl get /registry/secrets/default/secret1 [...] | hexdump -C` where `[...]` must be the additional arguments for connecting to the etcd server. <del> 3. Verify the stored secret is prefixed with `k8s:enc:aescbc:v1:` which indicates the `aescbc` provider has encrypted the resulting data. </del> <ins> 1. Verify the stored Secret is prefixed with `k8s:enc:aescbc:v1:` which indicates the `aescbc` provider has encrypted the resulting data. </ins> <del> 4. Verify the secret is correctly decrypted when retrieved via the API: </del> <ins> 1. Verify the Secret is correctly decrypted when retrieved via the API: </ins> ```shell kubectl describe secret secret1 -n default ``` <del> should match `mykey: bXlkYXRh`, mydata is encoded, check [decoding a secret](/docs/tasks/configmap-secret/managing-secret-using-kubectl/#decoding-secret) to completely decode the secret. </del> <ins> The output should contain `mykey: bXlkYXRh`, with contents of `mydata` encoded, check [decoding a Secret](/docs/tasks/configmap-secret/managing-secret-using-kubectl/#decoding-secret) to completely decode the Secret. </ins> <del> ## Ensure all secrets are encrypted </del> <ins> ## Ensure all Secrets are encrypted </ins> <del> Since secrets are encrypted on write, performing an update on a secret will encrypt that content. </del> <ins> Since Secrets are encrypted on write, performing an update on a Secret will encrypt that content. </ins> ```shell kubectl get secrets --all-namespaces -o json | kubectl replace -f - ``` <del> The command above reads all secrets and then updates them to apply server side encryption. </del> <ins> The command above reads all Secrets and then updates them to apply server side encryption. </ins> {{< note >}} If an error occurs due to a conflicting write, retry the command. For larger clusters, you may wish to subdivide the secrets by namespace or script an update. {{< /note >}} ## Rotating a decryption key <del> Changing the secret without incurring downtime requires a multi step operation, especially in the presence of a highly available deployment where multiple `kube-apiserver` processes are running. </del> <ins> Changing a Secret without incurring downtime requires a multi-step operation, especially in the presence of a highly-available deployment where multiple `kube-apiserver` processes are running. </ins> 1. Generate a new key and add it as the second key entry for the current provider on all servers <del> 2. Restart all `kube-apiserver` processes to ensure each server can decrypt using the new key 3. Make the new key the first entry in the `keys` array so that it is used for encryption in the config 4. Restart all `kube-apiserver` processes to ensure each server now encrypts using the new key 5. Run `kubectl get secrets --all-namespaces -o json | kubectl replace -f -` to encrypt all existing secrets with the new key 6. Remove the old decryption key from the config after you back up etcd with the new key in use and update all secrets With a single `kube-apiserver`, step 2 may be skipped. </del> <ins> 1. Restart all `kube-apiserver` processes to ensure each server can decrypt using the new key 1. Make the new key the first entry in the `keys` array so that it is used for encryption in the config 1. Restart all `kube-apiserver` processes to ensure each server now encrypts using the new key 1. Run `kubectl get secrets --all-namespaces -o json | kubectl replace -f -` to encrypt all existing Secrets with the new key 1. Remove the old decryption key from the config after you have backed up etcd with the new key in use and updated all Secrets When running a single `kube-apiserver` instance, step 2 may be skipped. </ins> ## Decrypting all data <del> To disable encryption at rest place the `identity` provider as the first entry in the config: </del> <ins> To disable encryption at rest, place the `identity` provider as the first entry in the config and restart all `kube-apiserver` processes. </ins> ```yaml apiVersion: apiserver.config.k8s.io/v1 kind: EncryptionConfiguration resources: - resources: <del> - secrets </del> <ins> - secrets </ins> providers: <del> - identity: {} - aescbc: keys: - name: key1 secret: <BASE 64 ENCODED SECRET> </del> <ins> - identity: {} - aescbc: keys: - name: key1 secret: <BASE 64 ENCODED SECRET> </ins> ``` <del> and restart all `kube-apiserver` processes. Then run: </del> <ins> Then run the following command to force decrypt all Secrets: </ins> ```shell kubectl get secrets --all-namespaces -o json | kubectl replace -f - ``` <del> to force all secrets to be decrypted. </del> <ins> ## {{% heading "whatsnext" %}} * Learn more about the [EncryptionConfiguration configuration API (v1)](/docs/reference/config-api/apiserver-encryption.v1/). </ins>

This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be Within add a new generated page that documents the format for an encryption configuration. Update to hyperlink to that new reference Why is this needed Within , there is a configuration format for the API server, EncryptionConfiguration. At the moment that format is not documented in Readers may want to look up what that format covers. Comments /sig api-machinery /sig auth /kind feature /language en
/triage accepted
/assign This file is already generated in the generator. All we need to do is to copy it to the website repo.


Question: Before starting the restore operation, a snapshot file must be present. It can either be a snapshot file from a previous backup operation, or from a remaining [data directory](https://etcd.io/docs/current/op-guide/configuration/#--data-dir). Here is an example: ```shell <del> ETCDCTL_API=3 etcdctl --endpoints 10.2.0.9:2379 snapshot restore snapshotdb </del> <ins> ETCDCTL_API=3 etcdctl --endpoints 10.2.0.9:2379 snapshot restore snapshot.db </ins> ``` <del> Another example for restoring using etcdctl options: </del> <ins> Another example for restoring using `etcdctl` options: </ins> ```shell <del> ETCDCTL_API=3 etcdctl snapshot restore --data-dir <data-dir-location> snapshotdb </del> <ins> ETCDCTL_API=3 etcdctl --data-dir <data-dir-location> snapshot restore snapshot.db </ins> ``` <del> Yet another example would be to first export the environment variable </del> <ins> where `<data-dir-location>` is a directory that will be created during the restore process. Yet another example would be to first export the `ETCDCTL_API` environment variable: </ins> ```shell export ETCDCTL_API=3 <del> etcdctl snapshot restore --data-dir <data-dir-location> snapshotdb </del> <ins> etcdctl --data-dir <data-dir-location> snapshot restore snapshot.db </ins> ``` For more information and examples on restoring a cluster from a snapshot file, see

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: title: "PowerShell auto-completion" description: "Some optional configuration for powershell auto-completion." headless: true <ins> _build: list: never render: never publishResources: false </ins> --- The kubectl completion script for PowerShell can be generated with the command `kubectl completion powershell`.

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 source Markdown needs to exist for pages such as but we don't need to make those turn into actual web pages. Proposed Solution: Edit every file within : Page to Update: and its contents /area web-development /help /priority backlog /good-first-issue
This request has been marked as suitable for new contributors. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : This is a Bug Report <!-- See for guidance on writing an actionable issue description. --Problem: The source Markdown needs to exist for pages such as but we don't need to make those turn into actual web pages. Edit every file within : Page to Update: and its contents /help /priority backlog /good-first-issue </details
/retitle Include files for install are rendered and served /triage accepted
/assign
/unassign
Thanks !


Question: <ins> --- title: "例: PHP / Redisを使用したゲストブックの例にロギングとメトリクスを追加する" content_type: tutorial weight: 21 card: name: tutorials weight: 31 title: "例: PHP / Redisを使用したゲストブックの例にロギングとメトリクスを追加する" --- <!-- overview --> このチュートリアルは、[Redisを使用したPHPのゲストブック](/ja/docs/tutorials/stateless-application/guestbook)のチュートリアルを前提に作られています。Elasticが開発したログ、メトリクス、ネットワークデータを転送するオープンソースの軽量データシッパーである*Beats*を、ゲストブックと同じKubernetesクラスターにデプロイします。BeatsはElasticsearchに対してデータの収集、分析、インデックス作成を行うため、結果の運用情報をKibana上で表示・分析できるようになります。この例は、以下のコンポーネントから構成されます。 * [Redisを使用したPHPのゲストブック](/ja/docs/tutorials/stateless-application/guestbook)の実行中のインスタンス * ElasticsearchとKibana * Filebeat * Metricbeat * Packetbeat ## {{% heading "objectives" %}} * Redisを使用したPHPのゲストブックを起動する。 * kube-state-metricsをインストールする。 * KubernetesのSecretを作成する。 * Beatsをデプロイする。 * ログとメトリクスのダッシュボードを表示する。 ## {{% heading "prerequisites" %}} {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} 追加で以下の作業が必要です。 * [Redisを使用したPHPのゲストブック](/ja/docs/tutorials/stateless-application/guestbook)チュートリアルの実行。 * ElasticsearchとKibanaのdeploymentの実行。[Elastic Cloud上のElasticsearchサービス](https://cloud.elastic.co)を使用するか、[ファイルをダウンロード](https://www.elastic.co/guide/en/elastic-stack-get-started/current/get-started-elastic-stack.html)してワークステーションやサーバー上で実行するか、または[Elastic Helm Chart](https://github.com/elastic/helm-charts)が使用できます。 <!-- lessoncontent --> ## Redisを使用したPHPのゲストブックを起動する このチュートリアルは、[Redisを使用したPHPのゲストブック](/ja/docs/tutorials/stateless-application/guestbook)のチュートリアルを前提に作られています。もしゲストブックアプリケーションが実行中なら、そのアプリケーションを監視できます。もしまだ実行中のアプリケーションがなければ、ゲストブックのデプロイの手順を行い、**クリーンアップ**のステップは実行しないでください。ゲストブックが起動したら、このページに戻ってきてください。 ## Cluster role bindingを追加する [クラスターレベルのrole binding](/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding)を作成して、kube-state-metricsとBeatsをクラスターレベルで(kube-system内に)デプロイできるようにします。 ```shell kubectl create clusterrolebinding cluster-admin-binding  --clusterrole=cluster-admin --user=<k8sのプロバイダーアカウントと紐付いたあなたのメールアドレス> ``` ## kube-state-metricsをインストールする Kubernetesの[*kube-state-metrics*](https://github.com/kubernetes/kube-state-metrics)は、Kubernetes APIサーバーをlistenして、オブジェクトの状態に関するメトリクスを生成する単純なサービスです。Metricbeatはこれらのメトリクスを報告します。kube-state-metricsをゲストブックが実行されているKubernetesクラスターに追加しましょう。 ### kube-state-metricsが起動しているか確認する ```shell kubectl get pods --namespace=kube-system | grep kube-state ``` ### 必要に応じてkube-state-metricsをインストールする ```shell git clone https://github.com/kubernetes/kube-state-metrics.git kube-state-metrics kubectl apply -f kube-state-metrics/examples/standard kubectl get pods --namespace=kube-system | grep kube-state-metrics ``` kube-state-metricsがRunningかつreadyの状態になっていることを確認します。 ```shell kubectl get pods -n kube-system -l app.kubernetes.io/name=kube-state-metrics ``` 結果は次のようになります。 ```shell NAME                                 READY   STATUS    RESTARTS   AGE kube-state-metrics-89d656bf8-vdthm   1/1     Running     0          21s ``` ## GitHubリポジトリのElasticの例をクローンする ```shell git clone https://github.com/elastic/examples.git ``` これ以降のコマンドは`examples/beats-k8s-send-anywhere`ディレクトリ内のファイルを参照するため、カレントディレクトリを変更します。 ```shell cd examples/beats-k8s-send-anywhere ``` ## KubernetesのSecretを作成する Kubernetesの{{< glossary_tooltip text="Secret" term_id="secret" >}}とは、パスワード、トークン、または鍵などの小さなサイズの機密データを含んだオブジェクトのことです。このような機密情報はPodのspecやイメージの中に置くことも不可能ではありませんが、Secretオブジェクトの中に置くことで、情報の使用方法を適切に制御したり、誤って公開してしまうリスクを減らすことができます。 {{< note >}} ここでは2種類の手順を紹介します。1つは*セルフマネージド*な(自分のサーバーで実行中またはElastic Helm Chartを使用して構築された)ElasticsearchおよびKibanaのためのもので、もう1つは*マネージドサービス*のElastic CloudのElasticsearch Serviceのための別の手順です。このチュートリアルで使う種類のElasticsearchおよびKibanaのシステムのためのSecretだけを作成してください。 {{< /note >}} {{< tabs name="tab_with_md" >}} {{% tab name="セルフマネージド" %}} ### セルフマネージド Elastic Cloud上のElasticsearch Serviceに接続する場合は、**マネージドサービス**タブに切り替えてください。 ### クレデンシャルを設定する セルフマネージドのElasticsearchとKibanaへ接続する場合、KubernetesのSecretを作成するために編集するべきファイルは4つあります(セルフマネージドとは、事実上Elastic Cloud以外で実行されているElasticsearch Serviceを指します)。ファイルは次の4つです。 1. ELASTICSEARCH_HOSTS 1. ELASTICSEARCH_PASSWORD 1. ELASTICSEARCH_USERNAME 1. KIBANA_HOST これらのファイルにElasticsearchクラスターとKibanaホストの情報を設定してください。ここでは例をいくつか示します([*こちらの設定*](https://stackoverflow.com/questions/59892896/how-to-connect-from-minikube-to-elasticsearch-installed-on-host-local-developme/59892897#59892897)も参照してください)。 #### `ELASTICSEARCH_HOSTS` 1. Elastic Elasticsearch Helm Chartで作成したnodeGroupの場合。 ```shell ["http://elasticsearch-master.default.svc.cluster.local:9200"] ``` 1. Mac上で単一のElasticsearchノードが実行されており、BeatsがDocker for Macで実行中の場合。 ```shell ["http://host.docker.internal:9200"] ``` 1. 2ノードのElasticsearchがVM上または物理ハードウェア上で実行中の場合。 ```shell ["http://host1.example.com:9200", "http://host2.example.com:9200"] ``` `ELASTICSEARCH_HOSTS`を編集します。 ```shell vi ELASTICSEARCH_HOSTS ``` #### `ELASTICSEARCH_PASSWORD` パスワードだけを書きます。空白、クォート、<>などの文字は書かないでください。 <yoursecretpassword> `ELASTICSEARCH_PASSWORD`を編集します。 ```shell vi ELASTICSEARCH_PASSWORD ``` #### `ELASTICSEARCH_USERNAME` ユーザー名だけを書きます。空白、クォート、<>などの文字は書かないでください。 <Elasticsearchに追加するユーザー名> `ELASTICSEARCH_USERNAME`を編集します。 ```shell vi ELASTICSEARCH_USERNAME ``` #### `KIBANA_HOST` 1. Elastic Kibana Helm Chartで作成したKibanaインスタンスが実行中の場合。`default`というサブドメインは、default Namespaceを指します。もしHelm Chartを別のNamespaceにデプロイした場合、サブドメインは異なります。 ```shell "kibana-kibana.default.svc.cluster.local:5601" ``` 1. Mac上でKibanaインスタンスが実行中で、BeatsがDocker for Macで実行中の場合。 ```shell "host.docker.internal:5601" ``` 1. 2つのElasticsearchノードが、VMまたは物理ハードウェア上で実行中の場合。 ```shell "host1.example.com:5601" ``` `KIBANA_HOST`を編集します。 ```shell vi KIBANA_HOST ``` ### KubernetesのSecretを作成する 次のコマンドを実行すると、KubernetesのシステムレベルのNamespace(kube-system)に、たった今編集したファイルを元にSecretが作成されます。 kubectl create secret generic dynamic-logging  --from-file=./ELASTICSEARCH_HOSTS  --from-file=./ELASTICSEARCH_PASSWORD  --from-file=./ELASTICSEARCH_USERNAME  --from-file=./KIBANA_HOST  --namespace=kube-system {{% /tab %}} {{% tab name="マネージドサービス" %}} ## マネージドサービス このタブは、Elastic Cloud上のElasticsearch Serviceの場合のみ必要です。もしセルフマネージドのElasticsearchとKibanaのDeployment向けにSecretをすでに作成した場合、[Beatsをデプロイする](#deploy-the-beats)に進んでください。 ### クレデンシャルを設定する Elastic Cloud上のマネージドElasticsearch Serviceに接続する場合、KubernetesのSecretを作成するために編集する必要があるのは、次の2つのファイルです。 1. ELASTIC_CLOUD_AUTH 1. ELASTIC_CLOUD_ID Deploymentを作成するときに、Elasticsearch Serviceのコンソールから提供された情報を設定してください。以下に例を示します。 #### ELASTIC_CLOUD_ID ```shell devk8s:ABC123def456ghi789jkl123mno456pqr789stu123vwx456yza789bcd012efg345hijj678klm901nop345zEwOTJjMTc5YWQ0YzQ5OThlN2U5MjAwYTg4NTIzZQ== ``` #### ELASTIC_CLOUD_AUTH ユーザー名、コロン(`:`)、パスワードだけを書きます。空白やクォートは書かないでください。 ```shell elastic:VFxJJf9Tjwer90wnfTghsn8w ``` ### 必要なファイルを編集する ```shell vi ELASTIC_CLOUD_ID vi ELASTIC_CLOUD_AUTH ``` ### KubernetesのSecretを作成する 次のコマンドを実行すると、KubernetesのシステムレベルのNamespace(kube-system)に、たった今編集したファイルを元にSecretが作成されます。 kubectl create secret generic dynamic-logging  --from-file=./ELASTIC_CLOUD_ID  --from-file=./ELASTIC_CLOUD_AUTH  --namespace=kube-system {{% /tab %}} {{< /tabs >}} ## Beatsをデプロイする {#deploy-the-beats} マニフェストファイルはBeatごとに提供されます。これらのマニフェストファイルは、上で作成したSecretを使用して、BeatsをElasticsearchおよびKibanaサーバーに接続するように設定します。 ### Filebeatについて Filebeatは、Kubernetesのノードと、ノード上で実行している各Pod内のコンテナから、ログを収集します。Filebeatは{{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}}としてデプロイされます。FilebeatはKubernetesクラスター上で実行されているアプリケーションを自動検出することもできます。起動時にFilebeatは既存のコンテナをスキャンし、それらに対して適切な設定を立ち上げ、その後、新しいstart/stopイベントを監視します。 Filebeatが、ゲストブックアプリケーションでデプロイしたRedisコンテナからRedisのログを特定・解析できるように自動検出を設定する例を示します。この設定は`filebeat-kubernetes.yaml`ファイル内にあります。 ```yaml - condition.contains: kubernetes.labels.app: redis config: - module: redis log: input: type: docker containers.ids: - ${data.kubernetes.container.id} slowlog: enabled: true var.hosts: ["${data.host}:${data.port}"] ``` この設定により、Filebeatは、`app`ラベルに`redis`という文字列が含まれるコンテナを検出したときに`redis` Filebeatモジュールを適用するようになります。redisモジュールには、input typeとしてdockerを使用することで(このRedisコンテナの標準出力のストリームと関連付けられた、Kubernetesノード上のファイルを読み取ることで)コンテナから`log`ストリームを収集する機能があります。さらに、このモジュールには、コンテナのメタデータとして提供された適切なPodのホストとポートと接続することにより、Redisの`slowlog`エントリーを収集する機能もあります。 ### Filebeatをデプロイする ```shell kubectl create -f filebeat-kubernetes.yaml ``` #### 検証する ```shell kubectl get pods -n kube-system -l k8s-app=filebeat-dynamic ``` ### Metricbeatについて Metricbeatの自動検出はFilebeatと同じ方法で設定します。以下にMetricbeatにおけるRedisコンテナの自動検出の設定を示します。この設定は`metricbeat-kubernetes.yaml`ファイル内にあります。 ```yaml - condition.equals: kubernetes.labels.tier: backend config: - module: redis metricsets: ["info", "keyspace"] period: 10s # Redis hosts hosts: ["${data.host}:${data.port}"] ``` この設定により、Metricbeatは、`tier`ラベルに`backend`という文字列が含まれるコンテナを検出したときに`redis` Metricbeatモジュールを適用するようになります。redisモジュールには、コンテナのメタデータとして提供された適切なPodのホストとポートと接続することにより、コンテナから`info`および`keyspace`メトリクスを収集する機能があります。 ### Metricbeatをデプロイする ```shell kubectl create -f metricbeat-kubernetes.yaml ``` #### 検証する ```shell kubectl get pods -n kube-system -l k8s-app=metricbeat ``` ### Packetbeatについて Packetbeatの設定は、FilebeatやMetricbeatとは異なります。コンテナのラベルに対するパターンマッチを指定する代わりに、関連するプロトコルとポート番号に基づいた設定を書きます。以下に示すのは、ポート番号のサブセットです。 {{< note >}} サービスを標準ポート以外で実行している場合、そのポート番号を`filebeat.yaml`内の適切なtypeに追加し、PacketbeatのDaemonSetを削除・再作成してください。 {{< /note >}} ```yaml packetbeat.interfaces.device: any packetbeat.protocols: - type: dns ports: [53] include_authorities: true include_additionals: true - type: http ports: [80, 8000, 8080, 9200] - type: mysql ports: [3306] - type: redis ports: [6379] packetbeat.flows: timeout: 30s period: 10s ``` #### Packetbeatをデプロイする ```shell kubectl create -f packetbeat-kubernetes.yaml ``` #### 検証する ```shell kubectl get pods -n kube-system -l k8s-app=packetbeat-dynamic ``` ## Kibanaで表示する ブラウザでKibanaを開き、**Dashboard**アプリケーションを開きます。検索バーでKubernetesと入力して、KubernetesのためのMetricbeatダッシュボードを開きます。このダッシュボードでは、NodeやDeploymentなどの状態のレポートが表示されます。 DashboardページでPacketbeatと検索し、Packetbeat overviewを表示します。 同様に、ApacheおよびRedisのためのDashboardを表示します。それぞれに対してログとメトリクスのDashboardが表示されます。Apache Metricbeat dashboardには何も表示されていないはずです。Apache Filebeat dashboardを表示して、ページの最下部までスクロールしてApacheのエラーログを確認します。ログを読むと、Apacheのメトリクスが表示されない理由が分かります。 Metricbeatを有効にしてApacheのメトリクスを取得するには、mod-status設定ファイルを含んだConfigMapを追加してゲストブックを再デプロイすることで、server-statusを有効にします。 ## Deploymentをスケールして新しいPodが監視されるのを確認する 存在するDeploymentを一覧します。 ```shell kubectl get deployments ``` 出力は次のようになります。 ```shell NAME            READY   UP-TO-DATE   AVAILABLE   AGE frontend        3/3     3            3           3h27m redis-master    1/1     1            1           3h27m redis-slave     2/2     2            2           3h27m ``` frontendのPodを2つにスケールダウンします。 ```shell kubectl scale --replicas=2 deployment/frontend ``` 出力は次のようになります。 ```shell deployment.extensions/frontend scaled ``` frontendのPodを再び3つにスケールアップします。 ```shell kubectl scale --replicas=3 deployment/frontend ``` ## Kibana上で変更を表示する スクリーンショットを確認し、指定されたフィルターを追加して、ビューにカラムを追加します。赤い枠の右下を見ると、ScalingReplicaSetというエントリーが確認できます。そこからリストを上に見てゆくと、イメージのpull、ボリュームのマウント、Podのスタートなどのイベントが確認できます。 ![Kibana Discover](https://raw.githubusercontent.com/elastic/examples/master/beats-k8s-send-anywhere/scaling-up.png) ## {{% heading "cleanup" %}} DeploymentとServiceを削除すると、実行中のすべてのPodも削除されます。ラベルを使って複数のリソースを1つのコマンドで削除します。 1. 次のコマンドを実行して、すべてのPod、Deployment、Serviceを削除します。 ```shell kubectl delete deployment -l app=redis kubectl delete service -l app=redis kubectl delete deployment -l app=guestbook kubectl delete service -l app=guestbook kubectl delete -f filebeat-kubernetes.yaml kubectl delete -f metricbeat-kubernetes.yaml kubectl delete -f packetbeat-kubernetes.yaml kubectl delete secret dynamic-logging -n kube-system ``` 1. Podの一覧を問い合わせて、実行中のPodがなくなったことを確認します。 ```shell kubectl get pods ``` 結果は次のようになるはずです。 ``` No resources found. ``` ## {{% heading "whatsnext" %}} * [リソースを監視するためのツール](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)について学ぶ。 * [ロギングのアーキテクチャ](/docs/concepts/cluster-administration/logging/)についてもっと読む。 * [アプリケーションのイントロスペクションとデバッグ](/ja/docs/tasks/debug-application-cluster/)についてもっと読む。 * [アプリケーションのトラブルシューティング](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)についてもっと読む。 </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: gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled by default to validate custom resource based on _validation rules_. You can disable this feature by explicitly setting the `CustomResourceValidationExpressions` feature gate to `false`, <del> for the `[kube-apiserver](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/)` component. </del> <ins> for the [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) component. </ins> This feature is only available if the schema is a [structural schema](#specifying-a-structural-schema).

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 Markdown error. renders like that, but should be a hyperlink: Proposed Solution: Update the Markdown source Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /language en /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. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : This is a Bug Report <!-- See for guidance on writing an actionable issue description. --Problem: has a Markdown error. renders like that, but should be a hyperlink: Update the Markdown source <!--Kubernetes Version:--/language en /help /triage accepted </details
/assign
/assign


Question: </div> </div> </div> <del> {{ partial "footer.html" . }} </del> </div> <ins> {{ partial "footer.html" . }} </ins> {{ partial "scripts.html" . }} </body> </html>  No newline at end of file

This is a Bug Report Problem: There are whitespaces on both sides of the footer on the blog page. ! Page to Update:
/area web-development
/priority backlog /triage accepted
A little whitespace line across whole page is also present , but maybe in this case it will get resolved by fixing footer.


Question: --> {{< note >}} 如果你在本地运行 Minikube 环境，你可以使用浏览器来访问 <del> hellow-world.info 和 hello-world.info/v2。 </del> <ins> hello-world.info 和 hello-world.info/v2。 </ins> {{< /note >}} ## {{% heading "whatsnext" %}}

Ingress Ingress Minikube hellow- hellow- typohellow
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: curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl-certinfo_1.5.0_linux_amd64 -o cfssl-certinfo chmod +x cfssl-certinfo <del> <!-- 1.  Create a directory to hold the artifacts and initialize cfssl: --> 1.  创建一个目录，用它保存所生成的构件和初始化 cfssl： </del> <ins> <!-- 2.  Create a directory to hold the artifacts and initialize cfssl: --> 2.  创建一个目录，用它保存所生成的构件和初始化 cfssl： </ins> mkdir cert cd cert ../cfssl print-defaults config > config.json ../cfssl print-defaults csr > csr.json <del> <!-- 1.  Create a JSON config file for generating the CA file, for example, `ca-config.json`: --> 1.  创建一个 JSON 配置文件来生成 CA 文件，例如：`ca-config.json`： </del> <ins> <!-- 3.  Create a JSON config file for generating the CA file, for example, `ca-config.json`: --> 3.  创建一个 JSON 配置文件来生成 CA 文件，例如：`ca-config.json`： </ins> { "signing": {

Link to The secondary list elements in the page are all "1." , they are not in order, it looks weird
/sig docs
Hi can you please elaborate which page are you talking about?
Sorry, I forgot to check the link in my issue, the correct link is
/language zh /triage accepted /retitle [zh] Wrong list numbering in page FYI: Page to update: page: file:
/assign
/assign
This fixes this issue.
please avoid assigning yourself to a issue that is already assigned to somebody else.


Question: * Modifies the object to add a `metadata.deletionTimestamp` field with the time you started the deletion. <del> * Prevents the object from being removed until its `metadata.finalizers` field is empty. </del> <ins> * Prevents the object from being removed until all items are removed from its `metadata.finalizers` field </ins> * Returns a `202` status code (HTTP "Accepted") The controller managing that finalizer notices the update to the object setting the

states that finalizers can be used to block deletion indefinitely. However, there is no explicit statement on updates to deletionTimestamp. It would make sense to prevent updates other from zero to some value, but if that's the case, it should also be mentioned here. This might look like a detail, but it is an important one when designing controller deletion protocols.
/retitle Clarify updates to during object removal /sig api-machinery /language en
Hi there is a very good regarding finalizers that mention deletionTimestamp. PTAL. If I'm understanding right this blog might help.
Hi I get how the deletion protocol works in Kubernetes. I also get why that's the case. What I ask is to extend the documentation with the guarantee that, once a deletion timestamp has been set to a nonzero value, it will never get another value thereafter. The issue is that there are guides to use finalization for indefinite deferral of the actual delete. But, there is no mechanism to actually abort the delete. Thus, if someone decides to manually delete a resource that cannot be deleted that way, the only fix for this is either to have a protection finalizer and completely ignore deletion timestamp or to replace the resource with an equivalent copy. Furthermore, I ask for a specific documentation, because the interaction with ownership is non-trivial and one should be assured that whatever is implemented will stay that way in future versions.
When you an object, Kubernetes makes that object almost read-only. If the object has no finalizers then the read-only object can disappear right away. Otherwise, the “read only” object is changed to record the timestamp that it was frozen. It's almost read-only because: the field gets set you can remove, but not add or change, finalizers As far as I know, admission control checks still apply. For example, if there's a ValidatingAdmissionWebhook that restricts removal of a particular finalizer, the restrictions still happen even for an object that's being deleted. Let's clearly document that objects being finalised are read-only with the exceptions I've mentioned. Then the immutability of goes without saying. If we want to we can explain the implication: you cannot resurrect an object that is has already had deletion requested; you can only delete it and then make a new similar object.
Thanks, that clarification would be great.

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]:
/triage accepted Hi !contribution is welcome regarding this issue. As it has been long time without any comments , i''d like to ask if you want to work on this?
If you are not working on it ,I'll be happy to update the text as this information/note is quite helpful in understanding the concept with clarity.
/remove-lifecycle stale
Hi I'm currently not working on this.
Thanks for clarifying . /assign
Raised PR: for the same.PTAL is this what you expected ? please let me know
yes, thanks; left a comment in the PR


Question: --build-arg HUGO_VERSION=$(HUGO_VERSION) container-build: module-check <del> $(CONTAINER_RUN) $(CONTAINER_IMAGE) hugo --minify </del> <ins> $(CONTAINER_RUN) --read-only $(CONTAINER_IMAGE) hugo --minify </ins> container-serve: module-check <del> $(CONTAINER_RUN) --mount type=tmpfs,destination=/src/resources,tmpfs-mode=0777 -p 1313:1313 $(CONTAINER_IMAGE) hugo server --buildFuture --bind 0.0.0.0 </del> <ins> $(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 </ins> test-examples: scripts/test_examples.sh install

This is a Bug Report run : output : my environment: mac version10.14.3 bash: 5.0.11 docker engine19.03.13 Proposed Solution: I try to figure out what's the problem, and I got following clue: line 71 of Makefile: container, list directory of /src/resources : line 32 of Dockerfile: seems it is a permission problem I simply commented out lines 32 of dockerfile , and the problem get solved Page to Update: Makefile Dockerfile
/assign
/cc
/priority important-soon
It seems like the challenge for compatibility is the Docker Desktop product on macOS. The symptoms don't seem to be present on Linux.
/kind bug /triage accepted


Question: ## Check required ports These [required ports](/docs/reference/ports-and-protocols/) <del> need to be open in order for Kubernetes components to communicate with each other. You can use `telnet` to check if a port is open. for example: </del> <ins> need to be open in order for Kubernetes components to communicate with each other. You can use telnet to check if a port is open. For example: </ins> ```shell telnet 127.0.0.1 6443

The "Install kubeadm" page has an incorrect capitalization in the "" section. Should be /language en /kind cleanup /good-first-issue
This request has been marked as suitable for new contributors. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : The "Install kubeadm" page has an incorrect capitalization in the "" section. You can use telnet to check if a port is open. For example: /kind cleanup /good-first-issue </details
/triage accepted
/remove-kind bug
Hey, could you please assign me ?
/assign


Question: title: 容器环境变量 id: container-env-variables date: 2018-04-12 <del> full_link: /docs/concepts/containers/container-environment-variables.md </del> <ins> full_link: /zh/docs/concepts/containers/container-environment/ </ins> short_description: > 容器环境变量提供了运行容器化应用所必须的一些重要信息。

could you please be more specific? I cannot find the broken link...
if you enter [], you can see next describtion: Pod PodPreset Secret Pod . and you click ‘’ the link is broken
thank you, I'm fixing it now ~
/assign
/language zh


Question: Um eine bestimmte Version herunterzuladen, ersetzen Sie den Befehlsteil `$(curl -LS https://dl.k8s.io/release/stable.txt)` mit der jeweiligen Version. <del> Um beispielsweise die Version {{< param "fullversion" >}} auf Linux herunterzuladen, verwenden Sie den folgenden Befehl: </del> <ins> Um beispielsweise die Version {{< skew currentPatchVersion >}} auf Linux herunterzuladen, verwenden Sie den folgenden Befehl: </ins> ``` <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> ``` 2. Machen Sie die kubectl-Binärdatei ausführbar.

[de] Replace deprecated shortcode Problem: Based on , I have created this issue/task to help update the [de] language documentation. Proposed Solution: Page to Update: In the branch, I found: Results for "fullversion" in "k8s-website" /home/rdlugyhe/kubernetes/k8s-website/content/de/docs/tasks/tools/install-kubectl- 42: Um zum Beispiel Version {{< param "fullversion" }} auf Linux herunterzuladen: 45: curl -LO {{< param "fullversion" }}/bin/linux/amd64/kubectl /home/rdlugyhe/kubernetes/k8s-website/content/de/docs/tasks/tools/install-kubectl- 47: Um zum Beispiel Version {{< param "fullversion" }} auf Intel macOS herunterzuladen: 50: curl -LO "{{< param "fullversion" }}/bin/darwin/amd64/kubectl" 56: curl -LO "{{< param "fullversion" }}/bin/darwin/arm64/kubectl" /home/rdlugyhe/kubernetes/k8s-website/content/de/docs/tasks/tools/install- 200: Um beispielsweise die Version {{< param "fullversion" }} auf macOS herunterzuladen, verwenden Sie 203: curl -LO {{< param "fullversion" }}/bin/darwin/amd64/kubectl 228: Um beispielsweise die Version {{< param "fullversion" }} auf Linux herunterzuladen, verwenden Sie 231: curl -LO {{< param "fullversion" }}/bin/linux/amd64/kubectl 247: Laden Sie das aktuellste Release {{< param "fullversion" }} von diesem linkg


Question: 2. Create a Service to expose MongoDB on the network: ```shell <del> kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-service.yaml </del> <ins> kubectl apply -f https://k8s.io/examples/application/mongodb/mongo-service.yaml </ins> ``` The output of a successful command verifies that the Service was created:

In the section of There is no file with the specified URL, and the output of running this command is:
In PR the is deleted, which is used in the 'Creating MongoDB deployment and service' page. /kind bug
/triage accepted /retitle Example missing from Use Port Forwarding to Access Applications in a Cluster
/assign will add these yaml's
Fix it here


Question: <ins> --- title: Podのオーバーヘッド content_type: concept weight: 30 --- <!-- overview --> {{< feature-state for_k8s_version="v1.18" state="beta" >}} PodをNode上で実行する時に、Pod自身は大量のシステムリソースを消費します。これらのリソースは、Pod内のコンテナ(群)を実行するために必要なリソースとして追加されます。Podのオーバーヘッドは、コンテナの要求と制限に加えて、Podのインフラストラクチャで消費されるリソースを計算するための機能です。 <!-- body --> Kubernetesでは、Podの[RuntimeClass](/docs/concepts/containers/runtime-class/)に関連するオーバーヘッドに応じて、[アドミッション](/ja/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks)時にPodのオーバーヘッドが設定されます。 Podのオーバーヘッドを有効にした場合、Podのスケジューリング時にコンテナのリソース要求の合計に加えて、オーバーヘッドも考慮されます。同様に、Kubeletは、Podのcgroupのサイズ決定時およびPodの退役の順位付け時に、Podのオーバーヘッドを含めます。 ## Podのオーバーヘッドの有効化　{#set-up} クラスター全体で`PodOverhead`の[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)が有効になっていること（1.18時点ではデフォルトでオンになっています）と、`overhead`フィールドを定義する`RuntimeClass`が利用されていることを確認する必要があります。 ## 使用例 Podのオーバーヘッド機能を使用するためには、`overhead`フィールドが定義されたRuntimeClassが必要です。例として、仮想マシンとゲストOSにPodあたり約120MiBを使用する仮想化コンテナランタイムで、次のようなRuntimeClassを定義できます。 ```yaml --- kind: RuntimeClass apiVersion: node.k8s.io/v1 metadata: name: kata-fc handler: kata-fc overhead: podFixed: memory: "120Mi" cpu: "250m" ``` `kata-fc`RuntimeClassハンドラーを指定して作成されたワークロードは、リソースクォータの計算や、Nodeのスケジューリング、およびPodのcgroupのサイズ決定にメモリーとCPUのオーバーヘッドが考慮されます。 次のtest-podのワークロードの例を実行するとします。 ```yaml apiVersion: v1 kind: Pod metadata: name: test-pod spec: runtimeClassName: kata-fc containers: - name: busybox-ctr image: busybox stdin: true tty: true resources: limits: cpu: 500m memory: 100Mi - name: nginx-ctr image: nginx resources: limits: cpu: 1500m memory: 100Mi ``` アドミッション時、RuntimeClass[アドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/)は、RuntimeClass内に記述された`オーバーヘッド`を含むようにワークロードのPodSpecを更新します。もし既にPodSpec内にこのフィールドが定義済みの場合、そのPodは拒否されます。この例では、RuntimeClassの名前しか指定されていないため、アドミッションコントローラーは`オーバーヘッド`を含むようにPodを変更します。 RuntimeClassのアドミッションコントローラーの後、更新されたPodSpecを確認できます。 ```bash kubectl get pod test-pod -o jsonpath='{.spec.overhead}' ``` 出力は次の通りです: ``` map[cpu:250m memory:120Mi] ``` ResourceQuotaが定義されている場合、コンテナ要求の合計と`オーバーヘッド`フィールドがカウントされます。 kube-schedulerが新しいPodを実行すべきNodeを決定する際、スケジューラーはそのPodの`オーバーヘッド`と、そのPodに対するコンテナ要求の合計を考慮します。この例だと、スケジューラーは、要求とオーバーヘッドを追加し、2.25CPUと320MiBのメモリを持つNodeを探します。 PodがNodeにスケジュールされると、そのNodeのkubeletはPodのために新しい{{< glossary_tooltip text="cgroup" term_id="cgroup" >}}を生成します。基盤となるコンテナランタイムがコンテナを作成するのは、このPod内です。 リソースにコンテナごとの制限が定義されている場合(制限が定義されているGuaranteed QoSまたはBustrable QoS)、kubeletはそのリソース(CPUはcpu.cfs_quota_us、メモリはmemory.limit_in_bytes)に関連するPodのcgroupの上限を設定します。この上限は、コンテナの制限とPodSpecで定義された`オーバーヘッド`の合計に基づきます。 CPUについては、PodがGuaranteedまたはBurstable QoSの場合、kubeletはコンテナの要求の合計とPodSpecに定義された`オーバーヘッド`に基づいて`cpu.share`を設定します。 次の例より、ワークロードに対するコンテナの要求を確認できます。 ```bash kubectl get pod test-pod -o jsonpath='{.spec.containers[*].resources.limits}' ``` コンテナの要求の合計は、CPUは2000m、メモリーは200MiBです。 ``` map[cpu: 500m memory:100Mi] map[cpu:1500m memory:100Mi] ``` Nodeで観測される値と比較してみましょう。 ```bash kubectl describe node | grep test-pod -B2 ``` 出力では、2250mのCPUと320MiBのメモリーが要求されており、Podのオーバーヘッドが含まれていることが分かります。 ``` Namespace                   Name                CPU Requests  CPU Limits   Memory Requests  Memory Limits  AGE ---------                   ----                ------------  ----------   ---------------  -------------  --- default                     test-pod            2250m (56%)   2250m (56%)  320Mi (1%)       320Mi (1%)     36m ``` ## Podのcgroupの制限を確認 ワークロードで実行中のNode上にある、Podのメモリーのcgroupを確認します。次に示す例では、CRI互換のコンテナランタイムのCLIを提供するNodeで[`crictl`](https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md)を使用しています。これはPodのオーバーヘッドの動作を示すための高度な例であり、ユーザーがNode上で直接cgroupsを確認する必要はありません。 まず、特定のNodeで、Podの識別子を決定します。 ```bash # PodがスケジュールされているNodeで実行 POD_ID="$(sudo crictl pods --name test-pod -q)" ``` ここから、Podのcgroupのパスが決定します。 ```bash # PodがスケジュールされているNodeで実行 sudo crictl inspectp -o=json $POD_ID | grep cgroupsPath ``` 結果のcgroupパスにはPodの`ポーズ中`コンテナも含まれます。Podレベルのcgroupは１つ上のディレクトリです。 ``` "cgroupsPath": "/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/7ccf55aee35dd16aca4189c952d83487297f3cd760f1bbf09620e206e7d0c27a" ``` 今回のケースでは、Podのcgroupパスは、`kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2`となります。メモリーのPodレベルのcgroupの設定を確認しましょう。 ```bash # PodがスケジュールされているNodeで実行 # また、Podに割り当てられたcgroupと同じ名前に変更 cat /sys/fs/cgroup/memory/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/memory.limit_in_bytes ``` 予想通り320MiBです。 ``` 335544320 ``` ### Observability Podのオーバヘッドが利用されているタイミングを特定し、定義されたオーバーヘッドで実行されているワークロードの安定性を観察するため、[kube-state-metrics](https://github.com/kubernetes/kube-state-metrics)には`kube_pod_overhead`というメトリクスが用意されています。この機能はv1.9のkube-state-metricsでは利用できませんが、次のリリースで期待されています。それまでは、kube-state-metricsをソースからビルドする必要があります。 ## {{% heading "whatsnext" %}} * [RuntimeClass](/ja/docs/concepts/containers/runtime-class/) * [Podのオーバーヘッドの設計](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/688-pod-overhead) </ins>

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


Question: Les objets `secret` de Kubernetes vous permettent de stocker et de gérer des informations sensibles, telles que les mots de passe, les jetons OAuth et les clés ssh. Mettre ces informations dans un `secret` est plus sûr et plus flexible que de le mettre en dur dans la définition d'un {{< glossary_tooltip term_id="pod" >}} ou dans une {{< glossary_tooltip text="container image" term_id="image" >}}. <del> Voir [Document de conception des secrets](https://git.k8s.io/community/contributors/design-proposals/auth/secrets.md) pour plus d'informations. </del> <ins> Voir [Document de conception des secrets](https://github.com/kubernetes/design-proposals-archive/blob/main/auth/secrets.md) pour plus d'informations. </ins>

The link is broken
Hey Could you provide the page in which you found this broken link!
/triage needs-infomation /language e
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /triage needs-infomation /language e 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
/language en /triage needs-information
The broken link is on the following page:
I think the correct link is :
/assign
the language is not , it's . /language fr
/remove-language en
/triage accepted /priority backlog
/retitle Stale link in French concept page “Secrets”


Question: - name: nginx-helper-b # key: nginx-helper-b; akan dipertahankan pada hasil akhir image: helper:1.3 <del> # nilai file konfigurasi </del> <ins> # nilai berkas konfigurasi </ins> containers: - name: nginx image: nginx:1.10

This issue is intended for contributor workshop as part of Cloud Native Day Indonesia on 7th Nov 2020. Please don't take it if you are not part of the workshop. There are several old translated pages that contain the english glossary "file", supposed to use Indonesian "berkas" as per KBBI. Please claim the task to fix them by giving comments on this Github issue. /language id Tasks to fix "file" -"berkas": [x] docs/tasks/manage-kubernetes-objects/imperative-[x] docs/tasks/manage-kubernetes-objects/declarative-[ ] docs/tasks/manage-kubernetes-objects/imperative-[ ] docs/tasks/configure-pod-container/configure-pod-[ ] docs/tasks/administer-cluster/sysctl-[ ] [x] [ ] docs/concepts/storage/storage-[ ] docs/concepts/services-networking/connect-applications-[ ] docs/concepts/services-[x] [x] docs/concepts/cluster-
/triage accepted
/assign
I'm taking this page docs/tasks/manage-kubernetes-objects/imperative-
/reopen
Reopened this issue. <detailsIn response to : /reopen 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
i'm taking this page docs/tasks/manage-kubernetes-objects/declarative-
may i change this file:
thanks feel free to raise the PR and link this issue
/reopen
Reopened this issue. <detailsIn response to : /reopen 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
I take this page :
please let me change another part. I will try to change this file
sure just mention this issue number when you raise the pull request /reopen
Reopened this issue. <detailsIn response to : please let me change another part sure just mention this issue number when you raise the pull request 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
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
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-contributor-experience at . /lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-contributor-experience at . /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: Readiness probes runs on the container during its whole lifecycle. {{< /note >}} <del> {{< warning >}} </del> <ins> {{< caution >}} </ins> Liveness probes *do not* wait for readiness probes to succeed. If you want to wait before executing a liveness probe you should use initialDelaySeconds or a startupProbe. <del> {{< /warning >}} </del> <ins> {{< /caution >}} </ins> Readiness probes are configured similarly to liveness probes. The only difference is that you use the `readinessProbe` field instead of the `livenessProbe` field.

The page for incorrectly calls out waiting behavior as a warning rather than a caution. For more information, see Change the callout for to a caution instead of a warning: /sig docs
/good-first-issue /triage accepted
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /good-first-issue /triage accepted 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
As a reminder, anyone can open a pull request on an open issue, whether it’s assigned or not. Also as a reminder, please save issues marked good-first-issue for first time contributors.
/unassign
It would also be good to change the text of the caution slightly - see


Question: options.   ## What's next {#whats-next} * Verify that your cluster is running properly with [Sonobuoy](https://github.com/heptio/sonobuoy) * See [Upgrading kubeadm clusters](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) for details about upgrading your cluster using `kubeadm`. * Learn about advanced `kubeadm` usage in the [kubeadm reference documentation](/docs/reference/setup-tools/kubeadm/) * Learn more about Kubernetes [concepts](/docs/concepts/) and [`kubectl`](/docs/reference/kubectl/). * See the [Cluster Networking](/docs/concepts/cluster-administration/networking/) page for a bigger list of Pod network add-ons. * See the [list of add-ons](/docs/concepts/cluster-administration/addons/) to explore other add-ons, including tools for logging, monitoring, network policy, visualization & control of your Kubernetes cluster. * Configure how your cluster handles logs for cluster events and from applications running in Pods. See [Logging Architecture](/docs/concepts/cluster-administration/logging/) for an overview of what is involved. ### Feedback {#feedback} * For bugs, visit the [kubeadm GitHub issue tracker](https://github.com/kubernetes/kubeadm/issues) * For support, visit the [#kubeadm](https://kubernetes.slack.com/messages/kubeadm/) Slack channel * General SIG Cluster Lifecycle development Slack channel: [#sig-cluster-lifecycle](https://kubernetes.slack.com/messages/sig-cluster-lifecycle/) * SIG Cluster Lifecycle [SIG information](https://github.com/kubernetes/community/tree/master/sig-cluster-lifecycle#readme) * SIG Cluster Lifecycle mailing list: [kubernetes-sig-cluster-lifecycle](https://groups.google.com/forum/#!forum/kubernetes-sig-cluster-lifecycle)  ## Version skew policy {#version-skew-policy} While kubeadm allows version skew against some components that it manages, it is recommended that you

This is a Bug Report Problem: 'What's next' and 'Feedback' heading of this page is in the middle of page that should be at the end of the page. Proposed Solution: Cut-paste content shown in 1st picture and paste it after the heading 'Troubleshooting' (Refer 3rd picture) Page to Update: ! ! !
/sig docs /priority backlog /triage accepted /good-first-issue /help /language en
This request has been marked as suitable for new contributors. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /sig docs /priority backlog /triage accepted /good-first-issue /help /language en 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
this issue is already assigned to Prashant and he has already raised a PR for it which is under review process. There are plenty of other issues available here, try your hands on them :)
Yeah, I checked that's why i deleted the comment


Question: <script src="https://cdnjs.cloudflare.com/ajax/libs/iframe-resizer/4.3.9/iframeResizer.min.js" integrity="sha384-hHTwgxzjpO1G1NI0wMHWQYUxnGtpWyDjVSZrFnDrlWa5OL+DFY57qnDWw/5WSJOl" crossorigin="anonymous"></script> {{- end -}} <ins> <!-- Enable zoom-on-click for figures that opt in to this --> {{- if .HasShortcode "figure" -}} <script defer src="{{ "js/zoom.js" | relURL }}"></script> {{- end -}} </ins> {{- if eq (lower .Params.cid) "community" -}} {{- if eq .Params.community_styles_migrated true -}} <link href="/css/community.css" rel="stylesheet"><!-- legacy styles -->

This is a Feature Request Some images in concepts sections are quite detailed but in normal scope the texts inside of them look small and unreadable. Can we add feature for the images to pop up on clicking? It will add to the user experience as well as ease the pain of zooming out the page in whole. What would you like to be Feature to Pop up images on click Why is this needed The texts and details seem too small to read. Comments Reference of some of the pages where the issue arises: Example to the pop-up view for image:
/area web-development /kind feature
/area web-development Something similar to https://medium- ?
/retitle Enable click-to-zoom for some diagrams and other images
/triage accepted /priority backlog /lifecycle frozen
Thanks , I investigated on hugo's documents regarding any shortcode or feature that provide this functionality. but till now haven't found any.
For now I'll investigate more and try to find out what can work so assigning it to myself /assign
A couple of hints:
There is one more way like the above reference link mentioned, If we put full-resolution images in other paths and do this : It is in case we want minimal change in the code. I'm going to add ways here as I find so the community can vote or suggest which will be better for a clean code
one is a good reference for same functionality with example. I'll try both and raise a PR after that.
We using vector images.
This issue has not been updated in over 1 year, and should be re-triaged. You can: Confirm that this issue is still relevant with (org members only) Close this issue with For more details on the triage process, see /remove-triage accepted
My apologies,Due to bandwidth issue couldn't work on this, It's open for other people to self-assign.
This could be a positive and beneficial addition to the website. Worth doing (re-triaging as accepted). /triage accepted /lifecycle frozen
Let me see if I can assist with this. Edit: I request review and feedback on pull request


Question: This is useful if you want to target a specific namespace with a label {{< glossary_tooltip text="selector" term_id="selector" >}}. <ins> ### kubernetes.io/limit-ranger Example: `kubernetes.io/limit-ranger: "LimitRanger plugin set: cpu, memory request for container nginx; cpu, memory limit for container nginx"` Used on: Pod Kubernetes by default doesn't provide any resource limit, that means unless you explicitly define limits, your container can consume unlimited CPU and memory. You can define a default request or default limit for pods. You do this by creating a LimitRange in the relevant namespace. Pods deployed after you define a LimitRange will have these limits applied to them. The annotation `kubernetes.io/limit-ranger` records that resource defaults were specified for the Pod, and they were applied successfully. For more details, read about [LimitRanges](/docs/concepts/policy/limit-range). </ins> ### beta.kubernetes.io/arch (deprecated) This label has been deprecated. Please use `kubernetes.io/arch` instead.

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: Kubernetes uses an annotation, ; however, this annotation is not registered or documented. Proposed Solution: Document the annotation Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /language en
/triage accepted
/sig docs
/assign
/sig scheduling
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 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: Reopen this issue or PR with Mark this issue or PR as fresh with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /close [1]:
Closing this issue.

<detailsIn response to : The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. 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 closedReopen this issue or PR with Mark this issue or PR as fresh with Offer to help out with [Issue Triage][1] 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
/reopen /remove-lifecycle rotten /lifecycle frozen
Reopened this issue. <detailsIn response to : /reopen /remove-lifecycle rotten /lifecycle frozen 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: <del> --- reviewers: - davidopp - madhusudancs title: Configure Multiple Schedulers content_type: task --- <!-- overview --> Kubernetes ships with a default scheduler that is described [here](/docs/admin/kube-scheduler/). If the default scheduler does not suit your needs you can implement your own scheduler. Not just that, you can even run multiple schedulers simultaneously alongside the default scheduler and instruct Kubernetes what scheduler to use for each of your pods. Let's learn how to run multiple schedulers in Kubernetes with an example. A detailed description of how to implement a scheduler is outside the scope of this document. Please refer to the kube-scheduler implementation in [pkg/scheduler](https://github.com/kubernetes/kubernetes/tree/{{< param "githubbranch" >}}/pkg/scheduler) in the Kubernetes source directory for a canonical example. ## {{% heading "prerequisites" %}} {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} <!-- steps --> ## Package the scheduler Package your scheduler binary into a container image. For the purposes of this example, let's just use the default scheduler (kube-scheduler) as our second scheduler as well. Clone the [Kubernetes source code from GitHub](https://github.com/kubernetes/kubernetes) and build the source. ```shell git clone https://github.com/kubernetes/kubernetes.git cd kubernetes make ``` Create a container image containing the kube-scheduler binary. Here is the `Dockerfile` to build the image: ```docker FROM busybox ADD ./_output/local/bin/linux/amd64/kube-scheduler /usr/local/bin/kube-scheduler ``` Save the file as `Dockerfile`, build the image and push it to a registry. This example pushes the image to [Google Container Registry (GCR)](https://cloud.google.com/container-registry/). For more details, please read the GCR [documentation](https://cloud.google.com/container-registry/docs/). ```shell docker build -t gcr.io/my-gcp-project/my-kube-scheduler:1.0 . gcloud docker -- push gcr.io/my-gcp-project/my-kube-scheduler:1.0 ``` ## Define a Kubernetes Deployment for the scheduler Now that we have our scheduler in a container image, we can just create a pod config for it and run it in our Kubernetes cluster. But instead of creating a pod directly in the cluster, let's use a [Deployment](/docs/concepts/workloads/controllers/deployment/) for this example. A [Deployment](/docs/concepts/workloads/controllers/deployment/) manages a [Replica Set](/docs/concepts/workloads/controllers/replicaset/) which in turn manages the pods, thereby making the scheduler resilient to failures. Here is the deployment config. Save it as `my-scheduler.yaml`: {{< codenew file="admin/sched/my-scheduler.yaml" >}} An important thing to note here is that the name of the scheduler specified as an argument to the scheduler command in the container spec should be unique. This is the name that is matched against the value of the optional `spec.schedulerName` on pods, to determine whether this scheduler is responsible for scheduling a particular pod. Note also that we created a dedicated service account `my-scheduler` and bind the cluster role `system:kube-scheduler` to it so that it can acquire the same privileges as `kube-scheduler`. Please see the [kube-scheduler documentation](/docs/admin/kube-scheduler/) for detailed description of other command line arguments. ## Run the second scheduler in the cluster In order to run your scheduler in a Kubernetes cluster, just create the deployment specified in the config above in a Kubernetes cluster: ```shell kubectl create -f my-scheduler.yaml ``` Verify that the scheduler pod is running: ```shell kubectl get pods --namespace=kube-system ``` ``` NAME                                           READY     STATUS    RESTARTS   AGE .... my-scheduler-lnf4s-4744f                       1/1       Running   0          2m ... ``` You should see a "Running" my-scheduler pod, in addition to the default kube-scheduler pod in this list. ### Enable leader election To run multiple-scheduler with leader election enabled, you must do the following: First, update the following fields in your YAML file: * `--leader-elect=true` * `--lock-object-namespace=<lock-object-namespace>` * `--lock-object-name=<lock-object-name>` {{< note >}} The control plane creates the lock objects for you, but the namespace must already exist. You can use the `kube-system` namespace. {{< /note >}} If RBAC is enabled on your cluster, you must update the `system:kube-scheduler` cluster role. Add your scheduler name to the resourceNames of the rule applied for `endpoints` and `leases` resources, as in the following example: ``` kubectl edit clusterrole system:kube-scheduler ``` ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: annotations: rbac.authorization.kubernetes.io/autoupdate: "true" labels: kubernetes.io/bootstrapping: rbac-defaults name: system:kube-scheduler rules: - apiGroups: - coordination.k8s.io resources: - leases verbs: - create - apiGroups: - coordination.k8s.io resourceNames: - kube-scheduler - my-scheduler resources: - leases verbs: - get - update - apiGroups: - "" resourceNames: - kube-scheduler - my-scheduler resources: - endpoints verbs: - delete - get - patch - update ``` ## Specify schedulers for pods Now that our second scheduler is running, let's create some pods, and direct them to be scheduled by either the default scheduler or the one we just deployed. In order to schedule a given pod using a specific scheduler, we specify the name of the scheduler in that pod spec. Let's look at three examples. - Pod spec without any scheduler name {{< codenew file="admin/sched/pod1.yaml" >}} When no scheduler name is supplied, the pod is automatically scheduled using the default-scheduler. Save this file as `pod1.yaml` and submit it to the Kubernetes cluster. ```shell kubectl create -f pod1.yaml ``` - Pod spec with `default-scheduler` {{< codenew file="admin/sched/pod2.yaml" >}} A scheduler is specified by supplying the scheduler name as a value to `spec.schedulerName`. In this case, we supply the name of the default scheduler which is `default-scheduler`. Save this file as `pod2.yaml` and submit it to the Kubernetes cluster. ```shell kubectl create -f pod2.yaml ``` - Pod spec with `my-scheduler` {{< codenew file="admin/sched/pod3.yaml" >}} In this case, we specify that this pod should be scheduled using the scheduler that we deployed - `my-scheduler`. Note that the value of `spec.schedulerName` should match the name supplied to the scheduler command as an argument in the deployment config for the scheduler. Save this file as `pod3.yaml` and submit it to the Kubernetes cluster. ```shell kubectl create -f pod3.yaml ``` Verify that all three pods are running. ```shell kubectl get pods ``` <!-- discussion --> ### Verifying that the pods were scheduled using the desired schedulers In order to make it easier to work through these examples, we did not verify that the pods were actually scheduled using the desired schedulers. We can verify that by changing the order of pod and deployment config submissions above. If we submit all the pod configs to a Kubernetes cluster before submitting the scheduler deployment config, we see that the pod `annotation-second-scheduler` remains in "Pending" state forever while the other two pods get scheduled. Once we submit the scheduler deployment config and our new scheduler starts running, the `annotation-second-scheduler` pod gets scheduled as well. Alternatively, one could just look at the "Scheduled" entries in the event logs to verify that the pods were scheduled by the desired schedulers. ```shell kubectl get events ``` </del>

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: ``` ``` <del> Name:               cluster-node-23 Roles:              <none> Labels:             beta.amd.com/gpu.cu-count.64=1 beta.amd.com/gpu.device-id.6860=1 beta.amd.com/gpu.family.AI=1 beta.amd.com/gpu.simd-count.256=1 beta.amd.com/gpu.vram.16G=1 beta.kubernetes.io/arch=amd64 beta.kubernetes.io/os=linux kubernetes.io/hostname=cluster-node-23 Annotations:        kubeadm.alpha.kubernetes.io/cri-socket: /var/run/dockershim.sock node.alpha.kubernetes.io/ttl: 0 … </del> <ins> Name:               cluster-node-23 Roles:              <none> Labels:             beta.amd.com/gpu.cu-count.64=1 beta.amd.com/gpu.device-id.6860=1 beta.amd.com/gpu.family.AI=1 beta.amd.com/gpu.simd-count.256=1 beta.amd.com/gpu.vram.16G=1 kubernetes.io/arch=amd64 kubernetes.io/os=linux kubernetes.io/hostname=cluster-node-23 Annotations:        node.alpha.kubernetes.io/ttl: 0 … </ins> ``` With the Node Labeller in use, you can specify the GPU type in the Pod spec:

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: doesn't have our disclaimer for 3rd party content. Proposed Solution: Add a third party content disclaimer. See for an example. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /language en /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. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : This is a Bug Report <!-- See for guidance on writing an actionable issue description. --Problem: doesn't have our disclaimer for 3rd party content. Add a third party content disclaimer. See for an example. <!--Kubernetes Version:--/language en /help /triage accepted 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
Separately, it would be good if didn't include advice about installing the plugins. Instead, we can hyperlink to the vendors' own docs (where those exist).


Question: <ins> --- title: ファイナライザー(Finalizers) content_type: concept weight: 80 --- <!-- overview --> {{<glossary_definition term_id="finalizer" length="long">}} ファイナライザーを利用すると、対象のリソースを削除する前に特定のクリーンアップを行うように{{<glossary_tooltip text="コントローラー" term_id="controller">}}に警告することで、{{<glossary_tooltip text="ガベージコレクション" term_id="garbage-collection">}}を管理することができます。 大抵の場合ファイナライザーは実行されるコードを指定することはありません。 その代わり、一般的にはアノテーションのように特定のリソースに関するキーのリストになります。 Kubernetesはいくつかのファイナライザーを自動的に追加しますが、自分で追加することもできます。 ## ファイナライザーはどのように動作するか マニフェストファイルを使ってリソースを作るとき、`metadata.finalizers`フィールドの中でファイナライザーを指定することができます。 リソースを削除しようとするとき、削除リクエストを扱うAPIサーバーは`finalizers`フィールドの値を確認し、以下のように扱います。 * 削除を開始した時間をオブジェクトの`metadata.deletionTimestamp`フィールドに設定します。 * `metadata.finalizers`フィールドが空になるまでオブジェクトが削除されるのを阻止します。 * ステータスコード`202`(HTTP "Accepted")を返します。 ファイナライザーを管理しているコントローラーは、オブジェクトの削除がリクエストされたことを示す`metadata.deletionTimestamp`がオブジェクトに設定されたことを検知します。 するとコントローラーはリソースに指定されたファイナライザーの要求を満たそうとします。 ファイナライザーの条件が満たされるたびに、そのコントローラーはリソースの`finalizers`フィールドの対象のキーを削除します。 `finalizers`フィールドが空になったとき、`deletionTimestamp`フィールドが設定されたオブジェクトは自動的に削除されます。管理外のリソース削除を防ぐためにファイナライザーを利用することもできます。 ファイナライザーの一般的な例は`kubernetes.io/pv-protection`で、これは `PersistentVolume`オブジェクトが誤って削除されるのを防ぐためのものです。 `PersistentVolume`オブジェクトをPodが利用中の場合、Kubernetesは`pv-protection`ファイナライザーを追加します。 `PersistentVolume`を削除しようとすると`Terminating`ステータスになりますが、ファイナライザーが存在しているためコントローラーはボリュームを削除することができません。 Podが`PersistentVolume`の利用を停止するとKubernetesは`pv-protection`ファイナライザーを削除し、コントローラーがボリュームを削除します。 ## オーナーリファレンス、ラベル、ファイナライザー {#owners-labels-finalizers} {{<glossary_tooltip text="ラベル" term_id="label">}}のように、 [オーナーリファレンス](/docs/concepts/overview/working-with-objects/owners-dependents/)はKubernetesのオブジェクト間の関係性を説明しますが、利用される目的が異なります。 {{<glossary_tooltip text="コントローラー" term_id="controller">}} がPodのようなオブジェクトを管理するとき、関連するオブジェクトのグループの変更を追跡するためにラベルを利用します。 例えば、{{<glossary_tooltip text="Job" term_id="job">}}がいくつかのPodを作成するとき、JobコントローラーはそれらのPodにラベルを付け、クラスター内の同じラベルを持つPodの変更を追跡します。 Jobコントローラーは、Podを作成したJobを指す*オーナーリファレンス*もそれらのPodに追加します。 Podが実行されているときにJobを削除すると、Kubernetesはオーナーリファレンス(ラベルではない)を使って、クリーンアップする必要のあるPodをクラスター内から探し出します。 また、Kubernetesは削除対象のリソースのオーナーリファレンスを認識して、ファイナライザーを処理します。 状況によっては、ファイナライザーが依存オブジェクトの削除をブロックしてしまい、対象のオーナーオブジェクトが完全に削除されず予想以上に長時間残ってしまうことがあります。 このような状況では、対象のオーナーと依存オブジェクトの、ファイナライザーとオーナーリファレンスを確認して問題を解決する必要があります。 {{<note>}} オブジェクトが削除中の状態で詰まってしまった場合、削除を続行するために手動でファイナライザーを削除することは避けてください。 通常、ファイナライザーは理由があってリソースに追加されているものであるため、強制的に削除してしまうとクラスターで何らかの問題を引き起こすことがあります。 そのファイナライザーの目的を理解しているかつ、別の方法で達成できる場合にのみ行うべきです(例えば、依存オブジェクトを手動で削除するなど)。 {{</note>}} ## {{% heading "whatsnext" %}} * Kubernetesブログの[ファイナライザーを利用した削除の制御](/blog/2021/05/14/using-finalizers-to-control-deletion/)をお読みください。 </ins>

This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be <!-- Describe as precisely as possible how this feature/enhancement should work from the user perspective. What should be changed, etc. --Translate into Japanese Why is this needed 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


Question: If the number of backend endpoints falls below 1000, the control plane removes this annotation. <ins> ### control-plane.alpha.kubernetes.io/leader (deprecated) {#control-plane-alpha-kubernetes-io-leader} Type: Annotation Example: `control-plane.alpha.kubernetes.io/leader={"holderIdentity":"controller-0","leaseDurationSeconds":15,"acquireTime":"2023-01-19T13:12:57Z","renewTime":"2023-01-19T13:13:54Z","leaderTransitions":1}` Used on: Endpoints The {{< glossary_tooltip text="control plane" term_id="control-plane" >}} previously set annotation on an [Endpoints](/docs/concepts/services-networking/service/#endpoints) object. This annotation provided the following detail: - Who is the current leader. - The time when the current leadership was acquired. - The duration of the lease (of the leadership) in seconds. - The time the current lease (the current leadership) should be renewed. - The number of leadership transitions that happened in the past. Kubernetes now uses [Leases](/docs/concepts/architecture/leases/) to manage leader assignment for the Kubernetes control plane. </ins> ### batch.kubernetes.io/job-tracking (deprecated) {#batch-kubernetes-io-job-tracking} Type: Annotation

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: Kubernetes an annotation, . For example, this annotation is set on ConfigMaps that are being used for legacy leader election (the modern / GA way to do this is using a Lease). That annotation is unregistered because it doesn't appear inside Proposed Solution: Register the annotation, by documenting it in Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /sig architecture /language en
/assign
/triage accepted


Question: * Swap disabled. You **MUST** disable swap in order for the kubelet to work properly. * For example, `sudo swapoff -a` will disable swapping temporarily. To make this change persistent across reboots, make sure swap is disabled in config files like `/etc/fstab`, `systemd.swap`, depending how it was configured on your system. <ins> {{< note >}} The `kubeadm` installation is done via binaries that use dynamic linking and assumes that your target system provides `glibc`. This is a reasonable assumption on many Linux distributions (including Debian, Ubuntu, Fedora, CentOS, etc.) but it is not always the case with custom and lightweight distributions which don't include `glibc` by default, such as Alpine Linux. The expectation is that the distribution either includes `glibc` or a [compatibility layer](https://wiki.alpinelinux.org/wiki/Running_glibc_programs) that provides the expected symbols. {{< /note >}} </ins> <!-- steps --> ## Verify the MAC address and product_uuid are unique for every node {#verify-mac-address}

By looking at the documentation: we see an option to install the kubeadm without the package manager. However, it is not a static compilation. In this way: a) Should it not describe what libs should be present in the host before installation?b) Could the binaries be static so they could be entirely self-contained? c) Is that an option recommended for prod envs, or is it more like installing from the source for testing purposes? d) When/and for what situations would it be recommended install kubeadm via binaries? Would that address more needs of toolings and other projects that use kubeadm to do the installation against many OSs and do not want to care about the target OS? It would be great to have further information regards the above questions. PS.: It also might to be related to:
/sig docs /sig release
/transfer website
Hi Thank you for looking on this one. However, you transfered this issue to the docs. However, will the docs team be able to answer the questions for them we are able to add the info there? Or would this info better gathered checked by the kubeadm maintainers?
This is the right repo. SIGs including cluster lifecycle work in this repo and do see issues against the pages they maintain.
/sig cluster-lifecycle
if you want to request that the binaries for Kubernetes are static with no dynamically linked dependencies, I recommend that you open a separate new issue against . However even for those static binaries we would still need to document system-level prerequisites (a common example is a mechanism to discover the expected means of name resolution).
Hi! I was curious so I took a look; some binaries (like ) are static, while others (like ) are dynamic. This seems to be controlled by in (with some overrides in a few lines below). As an experiment, I tried to add to , and then gave me a static binary which seemed to run fine. That being said, I didn't run any extensive tests on it, and I don't know what's the rationale for having some binaries linked dynamically vs statically.

(In my experience, with Go binaries, dynamic linking is necessary when enabling CGO, which is used by some dependencies; for instance to use a custom DNS resolver using avahi/bonjour configured through nsswitch instead of Go's built-in resolver; but again, I don't know the rationale for kubelet.) From my perspective, it would be acceptable to mention in the docs something like the following: WDYT?
The (fake) libraries you listed are all from the glibc package on Linux. The glibc package is there to be able to parse and load all Linux standard binaries (ELF format). They are not real dependencies to any add-on type of libraries or packages. I would not see them as an extra dependency for installation. For example, without ld-, the operating system won't be able to load your binary from disk into memory for execution. That library is a parser for your ELF binary. It knows how to layout your code, you data and your stack in memory. It knows how to make the 'open' syscalls linked to the OS kernel so that when your binary (kubelet) wants to open a file, the kernel is properly invoked to get it done.
I agree - has alternatives, but , and are unavoidably part of the OS.
as dates from January 1997. You won't be able to run Kubernetes on computers running an older Linux. Do we need to document this?
is a generic symbol for portability's purpose. Is there a real scenario where we a Linux doesn't support ? My understanding is that all Linux distributions (including their minimal install variants) have to have a library (which in theory doesn't have to be ) that provides the symbol. By Linux distribution, I'm also referring to those base OS images built for a cloud environment.
I'd like to know why we should do this. /priority awaiting-more-evidence
What and wrote above is mostly correct, but not totally correct, in the sense that , , and are not unavoidably part of the OS, and they are not necessary to run Linux binaries.

They are necessary to run dynamic Linux binaries, and 99% of the binaries shipping with 99% of the distros are dynamic, so it's mostly correct; but these files are not necessary to run static binaries (see all the -based container images for examples; or the fact that some distros ship a static , which you can use as an replacement for troubleshooting/salvage purposes, in case your libc or linker are corrupted). Furthermore, the linker ( and ) are libc-specific; i.e. the glibc one won't work with musl dynamic binaries and vice-versa (although I've read that there are compatibility things that can be done on the musl side to let the musl linker load glibc binaries with some limitations). Some folks building custom Kubernetes distributions (e.g. based on Alpine, to be more space-efficient, e.g. to load the whole system in RAM and operate without a local disk) might want binaries that don't rely on glibc. But, I'd argue that these folks should usually know what they're doing - in the sense that they should know that they're using Alpine (or a glibc-less system) and they should know how to figure out if the binaries are static or dynamic, and which steps to follow to obtain static builds, for instance. I don't have a particular opinion about what should be included in the install docs. I think it's fair to mention that some binaries rely on glibc, but it's also fair to leave that out since it might confuse more folks than it will help :-)
Hi Everybody, Thank you a lot for all info provided. So, I think we have a conclusion for the raised questions. Please, let me know if I misunderstand something. We could add a small note to help out advanced users without bringing confusion. Something like: (Following a suggestion) NOTE: This installation is done via binaries that use dynamic linking and assumes that your system provides glibc. This is a reasonable assumption on many Linux distributions (including Debian, Ubuntu, Fedora, CentOS, and many others) but it is not the case of custom and light distributions which are glibc-less systems such as Alphine._ We raise an issue to check that: and can leave the discussion there. I think we can assume that it is supported for production env, and we do not need to change the docs.

If that were not supported, then we would expect the docs to have a WARNING saying that it should not be used on those. I do not think that we need to address it in the docs. However, I would assume that the big motivation for we provide binaries and does not use the package manager is when we want to automate the installation. Please, let me know if I need to correct something. Thank you a lot for all your input and time so far.
+1 for adding a note.
I'd add that note in the “Before you begin” section: and then maybe have a couple of words (maybe four or five) linking back to that, just at the point we tell people to download binaries.
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]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages 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: Reopen this issue with Mark this issue as fresh with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /close not-planned [1]:
Closing this issue, marking it as "Not Planned".

<detailsIn response to : The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. 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 closedReopen this issue with Mark this issue as fresh with Offer to help out with [Issue Triage][1] 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
/reopen /triage accepted /remove-lifecycle rotten /priority backlog please consider updating the issue description to either: link to summarize that thinking
Reopened this issue. <detailsIn response to : /reopen /triage accepted /remove-lifecycle rotten /priority backlog link to summarize that thinking 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
I would add that we document We can clarify, if we want, that we expect a Linux distribution that provides glibc or a compatibility layer providing the expected symbols. Remember, the docs explain how Kubernetes works now and not how we might hope it works in the future. Right now at last some release binaries do assume that glibc is available.
/assign
commented on the linked website PR: before merging the note, this thread needs feedback from a kubelet maintainer to confirim if the CGO / dynamic linking is expected. IIRC, in the past the kubelet had a CGO dependency by mistake, it was resolved, and more recently it may have re-appeared.


Question: section [Graceful Node Shutdown](#graceful-node-shutdown) for more details. When a node is shutdown but not detected by kubelet's Node Shutdown Manager, the pods <del> that are part of a StatefulSet will be stuck in terminating status on </del> <ins> that are part of a {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}} will be stuck in terminating status on </ins> the shutdown node and cannot move to a new running node. This is because kubelet on the shutdown node is not available to delete the pods so the StatefulSet cannot create a new pod with the same name. If there are volumes used by the pods, the

This is a Feature Request What would you like to be Below are terms that can use the addition of a glossary tooltip to show the meaning of the said term.Below points can be to section of Nodes page which will help users for quick follow-ups. Why is this needed These references can help user understanding the concept while staying on same page or finding more about the concept with right link. it will enhance user experience and bring more clarity and less confusion. Comments :
/sig docs / language en /assign
If triage is accepted, i would be happy to contribute on it. PTAL.
/language en Fixed here .
/triage accepted