Question:
Translate into Japanese. This page has not been translated. /language ja /assign
/triage accepted

 --- title: kube-apiserver Audit Configuration (v1) content_type: tool-reference package: audit.k8s.io/v1 auto_generated: true --- ## Resource Types - [Event](#audit-k8s-io-v1-Event) - [EventList](#audit-k8s-io-v1-EventList) - [Policy](#audit-k8s-io-v1-Policy) - [PolicyList](#audit-k8s-io-v1-PolicyList) ## `Event`     {#audit-k8s-io-v1-Event} **Appears in:** - [EventList](#audit-k8s-io-v1-EventList) Event captures all the information that can be included in an API audit log.

Field	Description

apiVersion
string	audit.k8s.io/v1

kind
string	Event

level [Required]
 Level 	  AuditLevel at which event was generated

auditID [Required]
 k8s.io/apimachinery/pkg/types.UID 	  Unique audit ID, generated for each request.

stage [Required]
 Stage 	  Stage of the request handling when this event instance was generated.

requestURI [Required]
 string 	  RequestURI is the request URI as sent by the client to a server.

verb [Required]
 string 	  Verb is the kubernetes verb associated with the request. For non-resource requests, this is the lower-cased HTTP method.

user [Required]
 authentication/v1.UserInfo 	  Authenticated user information.

impersonatedUser
 authentication/v1.UserInfo 	  Impersonated user information.

sourceIPs
 []string 	  Source IPs, from where the request originated and intermediate proxies.

userAgent
 string 	  UserAgent records the user agent string reported by the client. Note that the UserAgent is provided by the client, and must not be trusted.

objectRef
 ObjectReference 	  Object reference this request is targeted at. Does not apply for List-type requests, or non-resource requests.

responseStatus
 meta/v1.Status 	  The response status, populated even when the ResponseObject is not a Status type. For successful responses, this will only include the Code and StatusSuccess. For non-status type error responses, this will be auto-populated with the error Message.

requestObject
 k8s.io/apimachinery/pkg/runtime.Unknown 	  API object from the request, in JSON format. The RequestObject is recorded as-is in the request (possibly re-encoded as JSON), prior to version conversion, defaulting, admission or merging. It is an external versioned object type, and may not be a valid object on its own. Omitted for non-resource requests.  Only logged at Request Level and higher.

responseObject
 k8s.io/apimachinery/pkg/runtime.Unknown 	  API object returned in the response, in JSON. The ResponseObject is recorded after conversion to the external type, and serialized as JSON.  Omitted for non-resource requests.  Only logged at Response Level.

requestReceivedTimestamp
 meta/v1.MicroTime 	  Time the request reached the apiserver.

stageTimestamp
 meta/v1.MicroTime 	  Time the request reached current audit stage.

annotations
 map[string]string 	  Annotations is an unstructured key value map stored with an audit event that may be set by plugins invoked in the request serving chain, including authentication, authorization and admission plugins. Note that these annotations are for the audit event, and do not correspond to the metadata.annotations of the submitted object. Keys should uniquely identify the informing component to avoid name collisions (e.g. podsecuritypolicy.admission.k8s.io/policy). Values should be short. Annotations are included in the Metadata level.

 ## `EventList`     {#audit-k8s-io-v1-EventList} EventList is a list of audit Events.

Field	Description

apiVersion
string	audit.k8s.io/v1

kind
string	EventList

metadata
 meta/v1.ListMeta 	  No description provided.

items [Required]
 []Event 	  No description provided.

 ## `Policy`     {#audit-k8s-io-v1-Policy} **Appears in:** - [PolicyList](#audit-k8s-io-v1-PolicyList) Policy defines the configuration of audit logging, and the rules for how different request categories are logged.

Field	Description

apiVersion
string	audit.k8s.io/v1

kind
string	Policy

metadata
 meta/v1.ObjectMeta 	  ObjectMeta is included for interoperability with API infrastructure.Refer to the Kubernetes API documentation for the fields of the metadata field.

rules [Required]
 []PolicyRule 	  Rules specify the audit Level a request should be recorded at. A request may match multiple rules, in which case the FIRST matching rule is used. The default audit level is None, but can be overridden by a catch-all rule at the end of the list. PolicyRules are strictly ordered.

omitStages
 []Stage 	  OmitStages is a list of stages for which no events are created. Note that this can also be specified per rule in which case the union of both are omitted.

 ## `PolicyList`     {#audit-k8s-io-v1-PolicyList} PolicyList is a list of audit Policies.

Field	Description

apiVersion
string	audit.k8s.io/v1

kind
string	PolicyList

metadata
 meta/v1.ListMeta 	  No description provided.

items [Required]
 []Policy 	  No description provided.

 ## `GroupResources`     {#audit-k8s-io-v1-GroupResources} **Appears in:** - [PolicyRule](#audit-k8s-io-v1-PolicyRule) GroupResources represents resource kinds in an API group.

Field	Description

group
 string 	  Group is the name of the API group that contains the resources. The empty string represents the core API group.

resources
 []string 	  Resources is a list of resources this rule applies to. For example: 'pods' matches pods. 'pods/log' matches the log subresource of pods. '∗' matches all resources and their subresources. 'pods/∗' matches all subresources of pods. '∗/scale' matches all scale subresources. If wildcard is present, the validation rule will ensure resources do not overlap with each other. An empty list implies all resources and subresources in this API groups apply.

resourceNames
 []string 	  ResourceNames is a list of resource instance names that the policy matches. Using this field requires Resources to be specified. An empty list implies that every instance of the resource is matched.

 ## `Level`     {#audit-k8s-io-v1-Level} (Alias of `string`) **Appears in:** - [Event](#audit-k8s-io-v1-Event) - [PolicyRule](#audit-k8s-io-v1-PolicyRule) Level defines the amount of information logged during auditing ## `ObjectReference`     {#audit-k8s-io-v1-ObjectReference} **Appears in:** - [Event](#audit-k8s-io-v1-Event) ObjectReference contains enough information to let you inspect or modify the referred object.

Field	Description

resource
 string 	  No description provided.

namespace
 string 	  No description provided.

name
 string 	  No description provided.

uid
 k8s.io/apimachinery/pkg/types.UID 	  No description provided.

apiGroup
 string 	  APIGroup is the name of the API group that contains the referred object. The empty string represents the core API group.

apiVersion
 string 	  APIVersion is the version of the API group that contains the referred object.

resourceVersion
 string 	  No description provided.

subresource
 string 	  No description provided.

 ## `PolicyRule`     {#audit-k8s-io-v1-PolicyRule} **Appears in:** - [Policy](#audit-k8s-io-v1-Policy) PolicyRule maps requests based off metadata to an audit Level. Requests must match the rules of every field (an intersection of rules).

Field	Description

level [Required]
 Level 	  The Level that requests matching this rule are recorded at.

users
 []string 	  The users (by authenticated user name) this rule applies to. An empty list implies every user.

userGroups
 []string 	  The user groups this rule applies to. A user is considered matching if it is a member of any of the UserGroups. An empty list implies every user group.

verbs
 []string 	  The verbs that match this rule. An empty list implies every verb.

resources
 []GroupResources 	  Resources that this rule matches. An empty list implies all kinds in all API groups.

namespaces
 []string 	  Namespaces that this rule matches. The empty string "" matches non-namespaced resources. An empty list implies every namespace.

nonResourceURLs
 []string 	  NonResourceURLs is a set of URL paths that should be audited. ∗s are allowed, but only as the full, final step in the path. Examples: "/metrics" - Log requests for apiserver metrics "/healthz∗" - Log all health checks

omitStages
 []Stage 	  OmitStages is a list of stages for which no events are created. Note that this can also be specified policy wide in which case the union of both are omitted. An empty list means no restrictions will apply.

 ## `Stage`     {#audit-k8s-io-v1-Stage} (Alias of `string`) **Appears in:** - [Event](#audit-k8s-io-v1-Event) - [Policy](#audit-k8s-io-v1-Policy) - [PolicyRule](#audit-k8s-io-v1-PolicyRule) Stage defines the stages in request handling that audit events may be generated.


Question:
Translate into Japanese. This page has not been translated. /language ja /assign
/triage accepted

<ins> --- content_type: concept reviewers: - ptux title: 監査 --- <!-- overview --> Kubernetesの監査はクラスター内の一連の行動を記録するセキュリティに関連した時系列の記録を提供します。 クラスターはユーザー、Kubernetes APIを使用するアプリケーション、 およびコントロールプレーン自体によって生成されたアクティビティなどを監査します。 監査により、クラスター管理者は以下の質問に答えることができます: - 何が起きたのか？ - いつ起こったのか？ - 誰がそれを始めたのか？ - 何のために起こったのか？ - それはどこで観察されましたか？ - それはどこから始まったのか？ - それはどこへ向かっていたのか？ <!-- body --> 監査記録のライフサイクルは[kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/)コンポーネントの中で始まります。 各リクエストは、その実行の各段階でその実行の各段階で、監査イベントが生成されます。 ポリシーに従って前処理され、バックエンドに書き込まれます。 ポリシーが何を記録するかを決定しを決定し、 バックエンドがその記録を永続化します。現在のバックエンドの実装はログファイルやWebhookなどがあります。 各リクエストは関連する _stage_ で記録されます。 定義されたステージは以下の通りです: - `RequestReceived` - 監査ハンドラーがリクエストを受信すると同時に生成されるイベントのステージ。 つまり、ハンドラーチェーンに委譲される前に生成されるイベントのステージです。 - `ResponseStarted` - レスポンスヘッダーが送信された後、レスポンスボディが送信される前のステージです。 このステージは長時間実行されるリクエスト（watchなど）でのみ発生します。 - `ResponseComplete` - レスポンスボディの送信が完了して、それ以上のバイトは送信されません。 - `Panic` - パニックが起きたときに発生するイベント。 {{< note >}} [Audit Event configuration](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event)の設定は[Event](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#event-v1-core)APIオブジェクトとは異なります。 {{< /note >}} 監査ログ機能は、リクエストごとに監査に必要なコンテキストが保存されるため、APIサーバーのメモリ消費量が増加します。 メモリの消費量は、監査ログ機能の設定によって異なります。 ## Audit policy 監査ポリシーはどのようなイベントを記録し、どのようなデータを含むべきかについてのルールを定義します。 監査ポリシーのオブジェクト構造は、[audit.k8s.io` API group](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy)で定義されています。 イベントが処理されると、そのイベントは順番にルールのリストと比較されます。 最初のマッチングルールは、イベントの監査レベルを設定します。 定義されている監査レベルは: - `None` - ルールに一致するイベントを記録しません。 - `Metadata` - lリクエストのメタデータ（リクエストしたユーザー、タイムスタンプ、リソース、動作など）を記録しますが、リクエストやレスポンスのボディは記録しません。 - `Request` - ログイベントのメタデータとリクエストボディは表示されますが、レスポンスボディは表示されません。 これは非リソースリクエストには適用されません。 - `RequestResponse` - イベントのメタデータ、リクエストとレスポンスのボディを記録しますが、 非リソースリクエストには適用されません。 You can pass a file with the policy to `kube-apiserver` using the `--audit-policy-file` flag. If the flag is omitted, no events are logged. Note that the `rules` field __must__ be provided in the audit policy file. A policy with no (0) rules is treated as illegal. `audit-policy-file`フラグを使って、ポリシーを記述したファイルを `kube-apiserver`に渡すことができます。 このフラグが省略された場合イベントは記録されません。 監査ポリシーファイルでは、`rules`フィールドが必ず指定されることに注意してください。 ルールがない(0)ポリシーは不当なものとして扱われます。 以下は監査ポリシーファイルの例: {{< codenew file="audit/audit-policy.yaml" >}} 最小限の監査ポリシーファイルを使用して、すべてのリクエストを `Metadata`レベルで記録することができます。 ```yaml # Log all requests at the Metadata level. apiVersion: audit.k8s.io/v1 kind: Policy rules: - level: Metadata ``` 独自の監査プロファイルを作成する場合は、Google Container-Optimized OSの監査プロファイルを出発点として使用できます。 監査ポリシーファイルを生成する[configure-helper.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/gce/gci/configure-helper.sh)スクリプトを確認することができます。 スクリプトを直視することで、監査ポリシーファイルのほとんどを見ることができます。 また、定義されているフィールドの詳細については、[Policy` configuration reference](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy)を参照できます。 ## 監査バックエンド 監査バックエンドは監査イベントを外部ストレージに永続化します。 kube-apiserverには2つのバックエンドが用意されています。 - イベントをファイルシステムに書き込むログバックエンド - 外部のHTTP APIにイベントを送信するWebhookバックエンド いずれの場合も、監査イベントはKubernetes API[`audit.k8s.io` API group](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event)で定義されている構造に従います。 {{< note >}} パッチの場合、リクエストボディはパッチ操作を含むJSON配列であり、適切なKubernetes APIオブジェクトを含むJSONオブジェクトではありません。 例えば、以下のリクエストボディは`/apis/batch/v1/namespaces/some-namespace/jobs/some-job-name`に対する有効なパッチリクエストです。 ```json [ { "op": "replace", "path": "/spec/parallelism", "value": 0 }, { "op": "remove", "path": "/spec/template/spec/containers/0/terminationMessagePolicy" } ] ``` {{< /note >}} ### ログバックエンド ログバックエンドは監査イベントを[JSONlines](https://jsonlines.org/)形式のファイルに書き込みます。 以下の `kube-apiserver` フラグを使ってログ監査バックエンドを設定できます。 - `--audit-log-path` は、ログバックエンドが監査イベントを書き込む際に使用するログファイルのパスを指定します。 このフラグを指定しないと、ログバックエンドは無効になります。`-` は標準出力を意味します。 - `--audit-log-maxage` は、古い監査ログファイルを保持する最大日数を定義します。 - `audit-log-maxbackup`は、保持する監査ログファイルの最大数を定義します。 - `--audit-log-maxsize` は、監査ログファイルがローテーションされるまでの最大サイズをメガバイト単位で定義します。 クラスターのコントロールプレーンでkube-apiserverをPodとして動作させている場合は、監査記録が永久化されるように、ポリシーファイルとログファイルの場所に`hostPath`をマウントすることを忘れないでください。 例えば: ```shell --audit-policy-file=/etc/kubernetes/audit-policy.yaml  --audit-log-path=/var/log/audit.log ``` それからボリュームをマウントします: ```yaml ... volumeMounts: - mountPath: /etc/kubernetes/audit-policy.yaml name: audit readOnly: true - mountPath: /var/log/audit.log name: audit-log readOnly: false ``` 最後に`hostPath`を設定します: ```yaml ... - name: audit hostPath: path: /etc/kubernetes/audit-policy.yaml type: File - name: audit-log hostPath: path: /var/log/audit.log type: FileOrCreate ``` ### Webhook バックエンド Webhook監査バックエンドは、監査イベントをリモートのWeb APIに送信しますが、 これは認証手段を含むKubernetes APIの形式であると想定されます。 Webhook監査バックエンドを設定するには、以下のkube-apiserverフラグを使用します。 - `--audit-webhook-config-file` は、Webhookの設定ファイルのパスを指定します。 webhookの設定は、事実上特化した [kubeconfig](/docs/tasks/access-application-cluster/configure-access-multiple-clusters) です。 - `--audit-webhook-initial-backoff` は、最初に失敗したリクエストの後、再試行するまでに待つ時間を指定します。 それ以降のリクエストは、指数関数的なバックオフで再試行されます。 Webhookの設定ファイルは、kubeconfig 形式でサービスのリモートアドレスと接続に使用する認証情報を指定します。 ## イベントバッチ {#batching} ログバックエンドとwebhookバックエンドの両方がバッチ処理をサポートしています。 webhookを例に、利用可能なフラグの一覧を示します。 ログバックエンドで同じフラグを取得するには、フラグ名の`webhook`を`log`に置き換えてください。 デフォルトでは、バッチングは`webhook`では有効で、`log`では無効です。 同様に、デフォルトではスロットリングは `webhook` で有効で、`log`では無効です。 - `--audit-webhook-mode` は、バッファリング戦略を定義します。以下のいずれかとなります。 - `batch` - イベントをバッファリングして、非同期にバッチ処理します。これがデフォルトです。 - `blocking` - 個々のイベントを処理する際に、APIサーバーの応答をブロックします。 - `blocking-strict` - blockingと同じですが、RequestReceivedステージでの監査ログに失敗した場合は RequestReceivedステージで監査ログに失敗すると、kube-apiserverへのリクエスト全体が失敗します。 以下のフラグは `batch` モードでのみ使用されます: - `--audit-webhook-batch-buffer-size`は、バッチ処理を行う前にバッファリングするイベントの数を定義します。 入力イベントの割合がバッファをオーバーフローすると、イベントはドロップされます。 - `--audit-webhook-batch-max-size`は、1つのバッチに入れるイベントの最大数を定義します。 - `--audit-webhook-batch-max-wait`は、キュー内のイベントを無条件にバッチ処理するまでの最大待機時間を定義します。 - `--audit-webhook-batch-throttle-qps`は、1秒あたりに生成されるバッチの最大平均数を定義します。 - `--audit-webhook-batch-throttle-burst`は、許可された QPS が低い場合に、同じ瞬間に生成されるバッチの最大数を定義します。 ## パラメーターチューニング パラメーターは、APIサーバーの負荷に合わせて設定してください。 例えば、kube-apiserverが毎秒100件のリクエストを受け取り、それぞれのリクエストが`ResponseStarted`と`ResponseComplete`の段階でのみ監査されるとします。毎秒≅200の監査イベントが発生すると考えてください。 1 つのバッチに最大 100 個のイベントがあるの場合、スロットリングレベルを少なくとも2クエリ/秒に設定する必要があります。 バックエンドがイベントを書き込むのに最大で5秒かかる場合、5秒分のイベントを保持するようにバッファサイズを設定する必要があります。 10バッチ、または1000イベントとなります。 しかし、ほとんどの場合デフォルトのパラメーターで十分であり、手動で設定する必要はありません。 kube-apiserverが公開している以下のPrometheusメトリクスや、ログを見て監査サブシステムの状態を監視することができます。 - `apiserver_audit_event_total` メトリックには、エクスポートされた監査イベントの合計数が含まれます。 - `apiserver_audit_error_total` メトリックには、エクスポート中にエラーが発生してドロップされたイベントの総数が含まれます。 ### ログエントリー・トランケーション {#truncate} logバックエンドとwebhookバックエンドは、ログに記録されるイベントのサイズを制限することをサポートしています。 例として、logバックエンドで利用可能なフラグの一覧を以下に示します - `audit-log-truncate-enabled` イベントとバッチの切り捨てを有効にするかどうかです。 - `audit-log-truncate-max-batch-size` バックエンドに送信されるバッチのバイト単位の最大サイズ。 - `audit-log-truncate-max-event-size` バックエンドに送信される監査イベントのバイト単位の最大サイズです。 デフォルトでは、`webhook`と`log`の両方で切り捨ては無効になっていますが、クラスター管理者は `audit-log-truncate-enabled`または`audit-webhook-truncate-enabled`を設定して、この機能を有効にする必要があります。 ## {{% heading "whatsnext" %}} * [Mutating webhook auditing annotations](/docs/reference/access-authn-authz/extensible-admission-controllers/#mutating-webhook-auditing-annotations). * [`Event`](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event) * [`Policy`](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy) </ins>


Question:
This is a Feature Request Port this: to the migration guide documentation: as a known issue. Note, CRI-O behavior may be different.
/sig node
/language en
Is the ask here to port the Google doc into the Kubernetes docs or just link to the Google documentation (which isn't necessarily allowed)?
We can't really do either, unless Google licenses to the CNCF. We could write new docs to highlight the same known issue (what's the issue? - I deliberated haven't looked).
Here is the GH issue: These metrics are missing in endpoint with Containerd (they were present with Dockershim): Also the format of container name dimension of many metrics was with dockershim, but the format on the containerd node is . This is coming from this file: that even has an internesting note that this is implementaiton details, but changing it will likely break somethings (btw, maybe this may be noted as well in the list of known issues). So workaround for both issues (missing metrics and the name of metric dimension) is to use a standalone cAdvisor, and use one of the releases with the suffix "-containerd-cri"
That sounds quite involved - should we open a related issue to track explaining how folks would do that?
Do we have a document that can be followed for using a standalone cadvisor? I checked the tags in cadvisor and turns out 2 versions have containerd as suffix but none have the "-containerd-cri" suffix. Ex: v0.41.0-containerd-fix-rc.2 Does the latest version v0.44.0 contain the fix?
can you please help here?
The fix was in I think but not sure which releases contain it
So what do we need to do next, Align versions?
/assign
Yeah I'm not sure how to tell which version has the changes. It's for sure in 0.43.x but the current "Latest" tag is 0.39.x and doesn't seem to have the fix. I think we should wait for or to verify.
It looks like updates the page's docker-specific information related to cAdvisor to be more generic to container runtimes. Would that be enough to address this issue or does more runtime-specific information need to be ?
what's your opinion in respect of ?
It's due to it being reverted in which is a real bummer for those of us using GKE and the default for new node pools is containerd.
/triage accepted
What should the next steps on this issue look like?
my thoughts: This doesn't belong on the suggested page because it's specific to containerd. I'd say let's update as follows: In Before you begin, add a line to "Read the known issues section" Add a section at the end, before What's Next, called "Known issues after migrating" Add "Versions of containerd prior to 0.45.0 didn't collect some metrics in the endpoint. For a list of missing metrics, refer to . To collect these metrics, install a containerd package that is version 0.45.0 or later that has the suffix." In , mention "To avoid the missing metrics in [Known issues after migrating](#known-issues-after-migrating), install a containerd package that is version 0.45.0 or later that has the suffix."
According to the comment at the only current work-around for containerd users is to deploy and scrape a standalone cadvisor daemonset, built from the branch. The stats exposed by the kubelet will be broken until 1.25 or 1.26 when is complete. Since it is the kubelet's cadvisor that is broken (and I would argue that it is broken/regressed by this issue), it should be covered in the kubernetes docs.
Is there a more involved process then than just installing the package?
it's not a package, it's a branch of the cadvisor project: I'm not sure if they're publishing binaries or images from that branch. A sample DaemonSet is available, which could be modified to use :
Could we say: "To collect these metrics, . Set the $VERSION variable to any cAdvisor version that has the suffix, such as " ?
I think that needs more work, for example the default DaemonSet only mounts the docker socket path; it does not mount the containerd socket, and even when I modify it to do so the metrics appear to be missing most of the important labels. Perhaps has some suggestions.
This feels like it would need to be its own task page, possibly linked from our existing Metrics doc as well
I've put a ready to run temporary solution here
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale

### Reverting the Registry Name in kubelet <del> The image used by kubelet for the pod sandbox (`pause`) can be overridden by setting the `--pod-infra-container-image` flag. For example: </del> <ins> The image used by kubelet for the pod sandbox (`pause`) can be overridden by configuring your container runtime or by setting the `--pod-infra-container-image` flag depending on the version of Kubernetes you are using. Other runtimes: [containerd](/docs/setup/production-environment/container-runtimes/#override-pause-image-containerd), [CRI-O](/docs/setup/production-environment/container-runtimes/#override-pause-image-cri-o), [cri-dockerd](/docs/setup/production-environment/container-runtimes/#override-pause-image-cri-dockerd-mcr). When using dockershim before v1.23: </ins> ``` kubelet --pod-infra-container-image=k8s.gcr.io/pause:3.5


Question:
This is a Feature Request Port this: to the migration guide documentation: as a known issue. Note, CRI-O behavior may be different.
/sig node
/language en
Is the ask here to port the Google doc into the Kubernetes docs or just link to the Google documentation (which isn't necessarily allowed)?
We can't really do either, unless Google licenses to the CNCF. We could write new docs to highlight the same known issue (what's the issue? - I deliberated haven't looked).
Here is the GH issue: These metrics are missing in endpoint with Containerd (they were present with Dockershim): Also the format of container name dimension of many metrics was with dockershim, but the format on the containerd node is . This is coming from this file: that even has an internesting note that this is implementaiton details, but changing it will likely break somethings (btw, maybe this may be noted as well in the list of known issues). So workaround for both issues (missing metrics and the name of metric dimension) is to use a standalone cAdvisor, and use one of the releases with the suffix "-containerd-cri"
That sounds quite involved - should we open a related issue to track explaining how folks would do that?
Do we have a document that can be followed for using a standalone cadvisor? I checked the tags in cadvisor and turns out 2 versions have containerd as suffix but none have the "-containerd-cri" suffix. Ex: v0.41.0-containerd-fix-rc.2 Does the latest version v0.44.0 contain the fix?
can you please help here?
The fix was in I think but not sure which releases contain it
So what do we need to do next, Align versions?
/assign
Yeah I'm not sure how to tell which version has the changes. It's for sure in 0.43.x but the current "Latest" tag is 0.39.x and doesn't seem to have the fix. I think we should wait for or to verify.
It looks like updates the page's docker-specific information related to cAdvisor to be more generic to container runtimes. Would that be enough to address this issue or does more runtime-specific information need to be ?
what's your opinion in respect of ?
It's due to it being reverted in which is a real bummer for those of us using GKE and the default for new node pools is containerd.
/triage accepted
What should the next steps on this issue look like?
my thoughts: This doesn't belong on the suggested page because it's specific to containerd. I'd say let's update as follows: In Before you begin, add a line to "Read the known issues section" Add a section at the end, before What's Next, called "Known issues after migrating" Add "Versions of containerd prior to 0.45.0 didn't collect some metrics in the endpoint. For a list of missing metrics, refer to . To collect these metrics, install a containerd package that is version 0.45.0 or later that has the suffix." In , mention "To avoid the missing metrics in [Known issues after migrating](#known-issues-after-migrating), install a containerd package that is version 0.45.0 or later that has the suffix."
According to the comment at the only current work-around for containerd users is to deploy and scrape a standalone cadvisor daemonset, built from the branch. The stats exposed by the kubelet will be broken until 1.25 or 1.26 when is complete. Since it is the kubelet's cadvisor that is broken (and I would argue that it is broken/regressed by this issue), it should be covered in the kubernetes docs.
Is there a more involved process then than just installing the package?
it's not a package, it's a branch of the cadvisor project: I'm not sure if they're publishing binaries or images from that branch. A sample DaemonSet is available, which could be modified to use :
Could we say: "To collect these metrics, . Set the $VERSION variable to any cAdvisor version that has the suffix, such as " ?
I think that needs more work, for example the default DaemonSet only mounts the docker socket path; it does not mount the containerd socket, and even when I modify it to do so the metrics appear to be missing most of the important labels. Perhaps has some suggestions.
This feels like it would need to be its own task page, possibly linked from our existing Metrics doc as well
I've put a ready to run temporary solution here
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale

Your container runtime must support at least v1alpha2 of the container runtime interface. <del> Kubernetes {{< skew currentVersion >}}  defaults to using v1 of the CRI API. If a container runtime does not support the v1 API, the kubelet falls back to </del> <ins> Kubernetes [starting v1.26](/blog/2022/11/18/upcoming-changes-in-kubernetes-1-26/#cri-api-removal) _only works_ with v1 of the CRI API. Earlier versions default to v1 version, however if a container runtime does not support the v1 API, the kubelet falls back to </ins> using the (deprecated) v1alpha2 API instead. ## Container runtimes


Question:
This is a Feature Request Port this: to the migration guide documentation: as a known issue. Note, CRI-O behavior may be different.
/sig node
/language en
Is the ask here to port the Google doc into the Kubernetes docs or just link to the Google documentation (which isn't necessarily allowed)?
We can't really do either, unless Google licenses to the CNCF. We could write new docs to highlight the same known issue (what's the issue? - I deliberated haven't looked).
Here is the GH issue: These metrics are missing in endpoint with Containerd (they were present with Dockershim): Also the format of container name dimension of many metrics was with dockershim, but the format on the containerd node is . This is coming from this file: that even has an internesting note that this is implementaiton details, but changing it will likely break somethings (btw, maybe this may be noted as well in the list of known issues). So workaround for both issues (missing metrics and the name of metric dimension) is to use a standalone cAdvisor, and use one of the releases with the suffix "-containerd-cri"
That sounds quite involved - should we open a related issue to track explaining how folks would do that?
Do we have a document that can be followed for using a standalone cadvisor? I checked the tags in cadvisor and turns out 2 versions have containerd as suffix but none have the "-containerd-cri" suffix. Ex: v0.41.0-containerd-fix-rc.2 Does the latest version v0.44.0 contain the fix?
can you please help here?
The fix was in I think but not sure which releases contain it
So what do we need to do next, Align versions?
/assign
Yeah I'm not sure how to tell which version has the changes. It's for sure in 0.43.x but the current "Latest" tag is 0.39.x and doesn't seem to have the fix. I think we should wait for or to verify.
It looks like updates the page's docker-specific information related to cAdvisor to be more generic to container runtimes. Would that be enough to address this issue or does more runtime-specific information need to be ?
what's your opinion in respect of ?
It's due to it being reverted in which is a real bummer for those of us using GKE and the default for new node pools is containerd.
/triage accepted
What should the next steps on this issue look like?
my thoughts: This doesn't belong on the suggested page because it's specific to containerd. I'd say let's update as follows: In Before you begin, add a line to "Read the known issues section" Add a section at the end, before What's Next, called "Known issues after migrating" Add "Versions of containerd prior to 0.45.0 didn't collect some metrics in the endpoint. For a list of missing metrics, refer to . To collect these metrics, install a containerd package that is version 0.45.0 or later that has the suffix." In , mention "To avoid the missing metrics in [Known issues after migrating](#known-issues-after-migrating), install a containerd package that is version 0.45.0 or later that has the suffix."
According to the comment at the only current work-around for containerd users is to deploy and scrape a standalone cadvisor daemonset, built from the branch. The stats exposed by the kubelet will be broken until 1.25 or 1.26 when is complete. Since it is the kubelet's cadvisor that is broken (and I would argue that it is broken/regressed by this issue), it should be covered in the kubernetes docs.
Is there a more involved process then than just installing the package?
it's not a package, it's a branch of the cadvisor project: I'm not sure if they're publishing binaries or images from that branch. A sample DaemonSet is available, which could be modified to use :
Could we say: "To collect these metrics, . Set the $VERSION variable to any cAdvisor version that has the suffix, such as " ?
I think that needs more work, for example the default DaemonSet only mounts the docker socket path; it does not mount the containerd socket, and even when I modify it to do so the metrics appear to be missing most of the important labels. Perhaps has some suggestions.
This feels like it would need to be its own task page, possibly linked from our existing Metrics doc as well
I've put a ready to run temporary solution here
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale

You might need to restart `containerd` as well once you've updated the config file: `systemctl restart containerd`. <ins> Please note, that it is a best practice for kubelet to declare the matching `pod-infra-container-image`. If not configured, kubelet may attempt to garbage collect the `pause` image. There is ongoing work in [containerd to pin the pause image](https://github.com/containerd/containerd/issues/6352) and not require this setting on kubelet any longer. </ins> ### CRI-O This section contains the necessary steps to install CRI-O as a container runtime.


Question:
This is a Feature Request Port this: to the migration guide documentation: as a known issue. Note, CRI-O behavior may be different.
/sig node
/language en
Is the ask here to port the Google doc into the Kubernetes docs or just link to the Google documentation (which isn't necessarily allowed)?
We can't really do either, unless Google licenses to the CNCF. We could write new docs to highlight the same known issue (what's the issue? - I deliberated haven't looked).
Here is the GH issue: These metrics are missing in endpoint with Containerd (they were present with Dockershim): Also the format of container name dimension of many metrics was with dockershim, but the format on the containerd node is . This is coming from this file: that even has an internesting note that this is implementaiton details, but changing it will likely break somethings (btw, maybe this may be noted as well in the list of known issues). So workaround for both issues (missing metrics and the name of metric dimension) is to use a standalone cAdvisor, and use one of the releases with the suffix "-containerd-cri"
That sounds quite involved - should we open a related issue to track explaining how folks would do that?
Do we have a document that can be followed for using a standalone cadvisor? I checked the tags in cadvisor and turns out 2 versions have containerd as suffix but none have the "-containerd-cri" suffix. Ex: v0.41.0-containerd-fix-rc.2 Does the latest version v0.44.0 contain the fix?
can you please help here?
The fix was in I think but not sure which releases contain it
So what do we need to do next, Align versions?
/assign
Yeah I'm not sure how to tell which version has the changes. It's for sure in 0.43.x but the current "Latest" tag is 0.39.x and doesn't seem to have the fix. I think we should wait for or to verify.
It looks like updates the page's docker-specific information related to cAdvisor to be more generic to container runtimes. Would that be enough to address this issue or does more runtime-specific information need to be ?
what's your opinion in respect of ?
It's due to it being reverted in which is a real bummer for those of us using GKE and the default for new node pools is containerd.
/triage accepted
What should the next steps on this issue look like?
my thoughts: This doesn't belong on the suggested page because it's specific to containerd. I'd say let's update as follows: In Before you begin, add a line to "Read the known issues section" Add a section at the end, before What's Next, called "Known issues after migrating" Add "Versions of containerd prior to 0.45.0 didn't collect some metrics in the endpoint. For a list of missing metrics, refer to . To collect these metrics, install a containerd package that is version 0.45.0 or later that has the suffix." In , mention "To avoid the missing metrics in [Known issues after migrating](#known-issues-after-migrating), install a containerd package that is version 0.45.0 or later that has the suffix."
According to the comment at the only current work-around for containerd users is to deploy and scrape a standalone cadvisor daemonset, built from the branch. The stats exposed by the kubelet will be broken until 1.25 or 1.26 when is complete. Since it is the kubelet's cadvisor that is broken (and I would argue that it is broken/regressed by this issue), it should be covered in the kubernetes docs.
Is there a more involved process then than just installing the package?
it's not a package, it's a branch of the cadvisor project: I'm not sure if they're publishing binaries or images from that branch. A sample DaemonSet is available, which could be modified to use :
Could we say: "To collect these metrics, . Set the $VERSION variable to any cAdvisor version that has the suffix, such as " ?
I think that needs more work, for example the default DaemonSet only mounts the docker socket path; it does not mount the containerd socket, and even when I modify it to do so the metrics appear to be missing most of the important labels. Perhaps has some suggestions.
This feels like it would need to be its own task page, possibly linked from our existing Metrics doc as well
I've put a ready to run temporary solution here
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale

If you use Docker Engine via dockershim as your container runtime and wish to upgrade to v1.24, it is recommended that you either migrate to another runtime or find an alternative means to obtain Docker Engine support. Check out the [container runtimes](/docs/setup/production-environment/container-runtimes/) <del> section to know your options. Make sure to </del> <ins> section to know your options. The version of Kubernetes with dockershim (1.23) is out of support and the v1.24 will run out of support [soon](/releases/#release-v1-24). Make sure to </ins> [report issues](https://github.com/kubernetes/kubernetes/issues) you encountered with the migration so the issues can be fixed in a timely manner and your cluster would be <del> ready for dockershim removal. </del> <ins> ready for dockershim removal. After v1.24 running out of support, you will need to contact your Kubernetes provider for support or upgrade multiple versions at a time if there are critical issues affecting your cluster. </ins> Your cluster might have more than one kind of node, although this is not a common configuration.


Question:
This is a Feature Request Port this: to the migration guide documentation: as a known issue. Note, CRI-O behavior may be different.
/sig node
/language en
Is the ask here to port the Google doc into the Kubernetes docs or just link to the Google documentation (which isn't necessarily allowed)?
We can't really do either, unless Google licenses to the CNCF. We could write new docs to highlight the same known issue (what's the issue? - I deliberated haven't looked).
Here is the GH issue: These metrics are missing in endpoint with Containerd (they were present with Dockershim): Also the format of container name dimension of many metrics was with dockershim, but the format on the containerd node is . This is coming from this file: that even has an internesting note that this is implementaiton details, but changing it will likely break somethings (btw, maybe this may be noted as well in the list of known issues). So workaround for both issues (missing metrics and the name of metric dimension) is to use a standalone cAdvisor, and use one of the releases with the suffix "-containerd-cri"
That sounds quite involved - should we open a related issue to track explaining how folks would do that?
Do we have a document that can be followed for using a standalone cadvisor? I checked the tags in cadvisor and turns out 2 versions have containerd as suffix but none have the "-containerd-cri" suffix. Ex: v0.41.0-containerd-fix-rc.2 Does the latest version v0.44.0 contain the fix?
can you please help here?
The fix was in I think but not sure which releases contain it
So what do we need to do next, Align versions?
/assign
Yeah I'm not sure how to tell which version has the changes. It's for sure in 0.43.x but the current "Latest" tag is 0.39.x and doesn't seem to have the fix. I think we should wait for or to verify.
It looks like updates the page's docker-specific information related to cAdvisor to be more generic to container runtimes. Would that be enough to address this issue or does more runtime-specific information need to be ?
what's your opinion in respect of ?
It's due to it being reverted in which is a real bummer for those of us using GKE and the default for new node pools is containerd.
/triage accepted
What should the next steps on this issue look like?
my thoughts: This doesn't belong on the suggested page because it's specific to containerd. I'd say let's update as follows: In Before you begin, add a line to "Read the known issues section" Add a section at the end, before What's Next, called "Known issues after migrating" Add "Versions of containerd prior to 0.45.0 didn't collect some metrics in the endpoint. For a list of missing metrics, refer to . To collect these metrics, install a containerd package that is version 0.45.0 or later that has the suffix." In , mention "To avoid the missing metrics in [Known issues after migrating](#known-issues-after-migrating), install a containerd package that is version 0.45.0 or later that has the suffix."
According to the comment at the only current work-around for containerd users is to deploy and scrape a standalone cadvisor daemonset, built from the branch. The stats exposed by the kubelet will be broken until 1.25 or 1.26 when is complete. Since it is the kubelet's cadvisor that is broken (and I would argue that it is broken/regressed by this issue), it should be covered in the kubernetes docs.
Is there a more involved process then than just installing the package?
it's not a package, it's a branch of the cadvisor project: I'm not sure if they're publishing binaries or images from that branch. A sample DaemonSet is available, which could be modified to use :
Could we say: "To collect these metrics, . Set the $VERSION variable to any cAdvisor version that has the suffix, such as " ?
I think that needs more work, for example the default DaemonSet only mounts the docker socket path; it does not mount the containerd socket, and even when I modify it to do so the metrics appear to be missing most of the important labels. Perhaps has some suggestions.
This feels like it would need to be its own task page, possibly linked from our existing Metrics doc as well
I've put a ready to run temporary solution here
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale

* Check out [container runtimes](/docs/setup/production-environment/container-runtimes/) to understand your options for an alternative. <del> * There is a [GitHub issue](https://github.com/kubernetes/kubernetes/issues/106917) to track the discussion about the deprecation and removal of dockershim. </del> * If you find a defect or other technical concern relating to migrating away from dockershim, you can [report an issue](https://github.com/kubernetes/kubernetes/issues/new/choose) to the Kubernetes project.


Question:
This is a Feature Request Port this: to the migration guide documentation: as a known issue. Note, CRI-O behavior may be different.
/sig node
/language en
Is the ask here to port the Google doc into the Kubernetes docs or just link to the Google documentation (which isn't necessarily allowed)?
We can't really do either, unless Google licenses to the CNCF. We could write new docs to highlight the same known issue (what's the issue? - I deliberated haven't looked).
Here is the GH issue: These metrics are missing in endpoint with Containerd (they were present with Dockershim): Also the format of container name dimension of many metrics was with dockershim, but the format on the containerd node is . This is coming from this file: that even has an internesting note that this is implementaiton details, but changing it will likely break somethings (btw, maybe this may be noted as well in the list of known issues). So workaround for both issues (missing metrics and the name of metric dimension) is to use a standalone cAdvisor, and use one of the releases with the suffix "-containerd-cri"
That sounds quite involved - should we open a related issue to track explaining how folks would do that?
Do we have a document that can be followed for using a standalone cadvisor? I checked the tags in cadvisor and turns out 2 versions have containerd as suffix but none have the "-containerd-cri" suffix. Ex: v0.41.0-containerd-fix-rc.2 Does the latest version v0.44.0 contain the fix?
can you please help here?
The fix was in I think but not sure which releases contain it
So what do we need to do next, Align versions?
/assign
Yeah I'm not sure how to tell which version has the changes. It's for sure in 0.43.x but the current "Latest" tag is 0.39.x and doesn't seem to have the fix. I think we should wait for or to verify.
It looks like updates the page's docker-specific information related to cAdvisor to be more generic to container runtimes. Would that be enough to address this issue or does more runtime-specific information need to be ?
what's your opinion in respect of ?
It's due to it being reverted in which is a real bummer for those of us using GKE and the default for new node pools is containerd.
/triage accepted
What should the next steps on this issue look like?
my thoughts: This doesn't belong on the suggested page because it's specific to containerd. I'd say let's update as follows: In Before you begin, add a line to "Read the known issues section" Add a section at the end, before What's Next, called "Known issues after migrating" Add "Versions of containerd prior to 0.45.0 didn't collect some metrics in the endpoint. For a list of missing metrics, refer to . To collect these metrics, install a containerd package that is version 0.45.0 or later that has the suffix." In , mention "To avoid the missing metrics in [Known issues after migrating](#known-issues-after-migrating), install a containerd package that is version 0.45.0 or later that has the suffix."
According to the comment at the only current work-around for containerd users is to deploy and scrape a standalone cadvisor daemonset, built from the branch. The stats exposed by the kubelet will be broken until 1.25 or 1.26 when is complete. Since it is the kubelet's cadvisor that is broken (and I would argue that it is broken/regressed by this issue), it should be covered in the kubernetes docs.
Is there a more involved process then than just installing the package?
it's not a package, it's a branch of the cadvisor project: I'm not sure if they're publishing binaries or images from that branch. A sample DaemonSet is available, which could be modified to use :
Could we say: "To collect these metrics, . Set the $VERSION variable to any cAdvisor version that has the suffix, such as " ?
I think that needs more work, for example the default DaemonSet only mounts the docker socket path; it does not mount the containerd socket, and even when I modify it to do so the metrics appear to be missing most of the important labels. Perhaps has some suggestions.
This feels like it would need to be its own task page, possibly linked from our existing Metrics doc as well
I've put a ready to run temporary solution here
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale

Kubernetes. They needed to be pushed to some registry to allow them to be used by Kubernetes. <ins> ## Known issues ### Some filesystem metrics are missing and the metrics format is different The Kubelet `/metrics/cadvisor` endpoint provides Prometheus metrics, as documented in [Metrics for Kubernetes system components](/docs/concepts/cluster-administration/system-metrics/). If you install a metrics collector that depends on that endpoint, you might see the following issues: - The metrics format on the Docker node is `k8s_<container-name>_<pod-name>_<namespace>_<pod-uid>_<restart-count>` but the format on other runtime is different. For example, on containerd node it is `<container-id>`. - Some filesystem metrics are missing, as follows: ``` container_fs_inodes_free container_fs_inodes_total container_fs_io_current container_fs_io_time_seconds_total container_fs_io_time_weighted_seconds_total container_fs_limit_bytes container_fs_read_seconds_total container_fs_reads_merged_total container_fs_sector_reads_total container_fs_sector_writes_total container_fs_usage_bytes container_fs_write_seconds_total container_fs_writes_merged_total ``` #### Workaround You can mitigate this issue by using [cAdvisor](https://github.com/google/cadvisor) as a standalone daemonset. 1. Find the latest [cAdvisor release](https://github.com/google/cadvisor/releases) with the name pattern `vX.Y.Z-containerd-cri` (for example, `v0.42.0-containerd-cri`). 2. Follow the steps in [cAdvisor Kubernetes Daemonset](https://github.com/google/cadvisor/tree/master/deploy/kubernetes) to create the daemonset. 3. Point the installed metrics collector to use the cAdvisor `/metrics` endpoint which provides the full set of [Prometheus container metrics](https://github.com/google/cadvisor/blob/master/docs/storage/prometheus.md). Alternatives: - Use alternative third party metrics collection solution. - Collect metrics from the Kubelet summary API that is served at `/stats/summary`. </ins> ## {{% heading "whatsnext" %}} - Read [Migrating from dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/) to understand your next steps


Question:
As discussed in the sig-networking mailing list (), has not been fully updated since the introduction of egress filtering.
/sig network /sig docs /kind bug (it's a bug because the doc should already have been updated) /language en /triage accepted
/priority backlog

<!-- overview --> <del> If you want to control traffic flow at the IP address or port level (OSI layer 3 or 4), then you might consider using Kubernetes NetworkPolicies for particular applications in your cluster.  NetworkPolicies are an application-centric construct which allow you to specify how a {{< glossary_tooltip text="pod" term_id="pod">}} is allowed to communicate with various network "entities" (we use the word "entity" here to avoid overloading the more common terms such as "endpoints" and "services", which have specific Kubernetes connotations) over the network. </del> <ins> If you want to control traffic flow at the IP address or port level (OSI layer 3 or 4), then you might consider using Kubernetes NetworkPolicies for particular applications in your cluster.  NetworkPolicies are an application-centric construct which allow you to specify how a {{< glossary_tooltip text="pod" term_id="pod">}} is allowed to communicate with various network "entities" (we use the word "entity" here to avoid overloading the more common terms such as "endpoints" and "services", which have specific Kubernetes connotations) over the network. NetworkPolicies apply to a connection with a pod on one or both ends, and are not relevant to other connections. </ins> The entities that a Pod can communicate with are identified through a combination of the following 3 identifiers:


Question:
As discussed in the sig-networking mailing list (), has not been fully updated since the introduction of egress filtering.
/sig network /sig docs /kind bug (it's a bug because the doc should already have been updated) /language en /triage accepted
/priority backlog

Network policies are implemented by the [network plugin](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/). To use network policies, you must be using a networking solution which supports NetworkPolicy. Creating a NetworkPolicy resource without a controller that implements it will have no effect. <del> ## Isolated and Non-isolated Pods </del> <ins> ## The Two Sorts of Pod Isolation </ins> <del> By default, pods are non-isolated; they accept traffic from any source. </del> <ins> There are two sorts of isolation for a pod: isolation for egress, and isolation for ingress.  They concern what connections may be established.  "Isolation" here is not absolute, rather it means "some restrictions apply".  The alternative, "non-isolated for $direction", means that no restrictions apply in the stated direction.  The two sorts of isolation (or not) are declared independently, and are both relevant for a connection from one pod to another. </ins> <del> Pods become isolated by having a NetworkPolicy that selects them. Once there is any NetworkPolicy in a namespace selecting a particular pod, that pod will reject any connections that are not allowed by any NetworkPolicy. (Other pods in the namespace that are not selected by any NetworkPolicy will continue to accept all traffic.) </del> <ins> By default, a pod is non-isolated for egress; all outbound connections are allowed.  A pod is isolated for egress if there is any NetworkPolicy that both selects the pod and has "Egress" in its `policyTypes`; we say that such a policy applies to the pod for egress.  When a pod is isolated for egress, the only allowed connections from the pod are those allowed by the `egress` list of some NetworkPolicy that applies to the pod for egress.  The effects of those `egress` lists combine additively. </ins> <del> Network policies do not conflict; they are additive. If any policy or policies select a pod, the pod is restricted to what is allowed by the union of those policies' ingress/egress rules. Thus, order of evaluation does not affect the policy result. </del> <ins> By default, a pod is non-isolated for ingress; all inbound connections are allowed.  A pod is isolated for ingress if there is any NetworkPolicy that both selects the pod and has "Ingress" in its `policyTypes`; we say that such a policy applies to the pod for ingress.  When a pod is isolated for ingress, the only allowed connections into the pod are those from the pod's node and those allowed by the `ingress` list of some NetworkPolicy that applies to the pod for ingress.  The effects of those `ingress` lists combine additively. </ins> <del> For a network flow between two pods to be allowed, both the egress policy on the source pod and the ingress policy on the destination pod need to allow the traffic. If either the egress policy on the source, or the ingress policy on the destination denies the traffic, the traffic will be denied. </del> <ins> Network policies do not conflict; they are additive. If any policy or policies apply to a given pod for a given direction, the connections allowed in that direction from that pod is the union of what the applicable policies allow. Thus, order of evaluation does not affect the policy result. For a connection from a source pod to a destination pod to be allowed, both the egress policy on the source pod and the ingress policy on the destination pod need to allow the connection. If either side does not allow the connection, it will not happen. </ins> ## The NetworkPolicy resource {#networkpolicy-resource}


Question:
As discussed in the sig-networking mailing list (), has not been fully updated since the introduction of egress filtering.
/sig network /sig docs /kind bug (it's a bug because the doc should already have been updated) /language en /triage accepted
/priority backlog

### Default deny all ingress traffic <del> You can create a "default" isolation policy for a namespace by creating a NetworkPolicy that selects all pods but does not allow any ingress traffic to those pods. </del> <ins> You can create a "default" ingress isolation policy for a namespace by creating a NetworkPolicy that selects all pods but does not allow any ingress traffic to those pods. </ins> {{< codenew file="service/networking/network-policy-default-deny-ingress.yaml" >}} <del> This ensures that even pods that aren't selected by any other NetworkPolicy will still be isolated. This policy does not change the default egress isolation behavior. </del> <ins> This ensures that even pods that aren't selected by any other NetworkPolicy will still be isolated for ingress. This policy does not affect isolation for egress from any pod. </ins> <del> ### Default allow all ingress traffic </del> <ins> ### Allow all ingress traffic </ins> <del> If you want to allow all traffic to all pods in a namespace (even if policies are added that cause some pods to be treated as "isolated"), you can create a policy that explicitly allows all traffic in that namespace. </del> <ins> If you want to allow all incoming connections to all pods in a namespace, you can create a policy that explicitly allows that. </ins> {{< codenew file="service/networking/network-policy-allow-all-ingress.yaml" >}} <ins> With this policy in place, no additional policy or policies can cause any incoming connection to those pods to be denied.  This policy has no effect on isolation for egress from any pod. </ins> ### Default deny all egress traffic You can create a "default" egress isolation policy for a namespace by creating a NetworkPolicy that selects all pods but does not allow any egress traffic from those pods.


Question:
As discussed in the sig-networking mailing list (), has not been fully updated since the introduction of egress filtering.
/sig network /sig docs /kind bug (it's a bug because the doc should already have been updated) /language en /triage accepted
/priority backlog

{{< codenew file="service/networking/network-policy-default-deny-egress.yaml" >}} This ensures that even pods that aren't selected by any other NetworkPolicy will not be allowed egress traffic. This policy does not <del> change the default ingress isolation behavior. </del> <ins> change the ingress isolation behavior of any pod. </ins> <del> ### Default allow all egress traffic </del> <ins> ### Allow all egress traffic </ins> <del> If you want to allow all traffic from all pods in a namespace (even if policies are added that cause some pods to be treated as "isolated"), you can create a policy that explicitly allows all egress traffic in that namespace. </del> <ins> If you want to allow all connections from all pods in a namespace, you can create a policy that explicitly allows all outgoing connections from pods in that namespace. </ins> {{< codenew file="service/networking/network-policy-allow-all-egress.yaml" >}} <ins> With this policy in place, no additional policy or policies can cause any outgoing connection from those pods to be denied.  This policy has no effect on isolation for ingress to any pod. </ins> ### Default deny all ingress and all egress traffic You can create a "default" policy for a namespace which prevents all ingress AND egress traffic by creating the following NetworkPolicy in that namespace.


Question:
Ref: needs a rewrite. It mentions Docker (and Podman!) all over the place, which is a good indication that the docs are old enough to need a rewrite. At a minimum, remove mentions of Docker in these topics: /triage accepted /milestone 1.24
/assign
/assign
Reasked folks in Slack for correct disposition
Asked in the SIG Node slack channel:
To summarize the consensus from talking with folks about this issue, specifically the examples in Using a Private Registry section: The steps in the Using a Private Registry section are still valid. However, as written, it makes it sound like Docker is the only/recommended way to do this-which we dont want. We should be able to remove the docker examples and point folks to this page , which covers most of the same content with third party disclaimers already written into the examples. I plan to open a PR later this week with these changes!
Has anyone opened a PR for this issue? It seems to be referring to

If you don't specify a registry hostname, Kubernetes assumes that you mean the Docker public registry. <del> After the image name part you can add a _tag_ (as also using with commands such as `docker` and `podman`). </del> <ins> After the image name part you can add a _tag_ (in the same way you would when using with commands like `docker` or `podman`). </ins> Tags let you identify different versions of the same series of images. Image tags consist of lowercase and uppercase letters, digits, underscores (`_`),


Question:
Ref: needs a rewrite. It mentions Docker (and Podman!) all over the place, which is a good indication that the docs are old enough to need a rewrite. At a minimum, remove mentions of Docker in these topics: /triage accepted /milestone 1.24
/assign
/assign
Reasked folks in Slack for correct disposition
Asked in the SIG Node slack channel:
To summarize the consensus from talking with folks about this issue, specifically the examples in Using a Private Registry section: The steps in the Using a Private Registry section are still valid. However, as written, it makes it sound like Docker is the only/recommended way to do this-which we dont want. We should be able to remove the docker examples and point folks to this page , which covers most of the same content with third party disclaimers already written into the examples. I plan to open a PR later this week with these changes!
Has anyone opened a PR for this issue? It seems to be referring to

replace `<image-name>:<tag>` with `<image-name>@<digest>` (for example, `image@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`). <del> When using image tags, if the image registry were to change the code that the tag on that image represents, you might end up with a mix of Pods running the old and new code. An image digest uniquely identifies a specific version of the image, so Kubernetes runs the same code every time it starts a container with that image name and digest specified. Specifying an image fixes the code that you run so that a change at the registry cannot lead to that mix of versions. </del> <ins> When using image tags, if the image registry were to change the code that the tag on that image represents, you might end up with a mix of Pods running the old and new code. An image digest uniquely identifies a specific version of the image, so Kubernetes runs the same code every time it starts a container with that image name and digest specified. Specifying an image by digest fixes the code that you run so that a change at the registry cannot lead to that mix of versions. </ins> There are third-party [admission controllers](/docs/reference/access-authn-authz/admission-controllers/) that mutate Pods (and pod templates) when they are created, so that the


Question:
Ref: needs a rewrite. It mentions Docker (and Podman!) all over the place, which is a good indication that the docs are old enough to need a rewrite. At a minimum, remove mentions of Docker in these topics: /triage accepted /milestone 1.24
/assign
/assign
Reasked folks in Slack for correct disposition
Asked in the SIG Node slack channel:
To summarize the consensus from talking with folks about this issue, specifically the examples in Using a Private Registry section: The steps in the Using a Private Registry section are still valid. However, as written, it makes it sound like Docker is the only/recommended way to do this-which we dont want. We should be able to remove the docker examples and point folks to this page , which covers most of the same content with third party disclaimers already written into the examples. I plan to open a PR later this week with these changes!
Has anyone opened a PR for this issue? It seems to be referring to

### Configuring nodes to authenticate to a private registry <del> If you run Docker on your nodes, you can configure the Docker container runtime to authenticate to a private container registry. </del> <ins> Specific instructions for setting credentials depends on the container runtime and registry you chose to use. You should refer to your solution's documentation for the most accurate information. </ins> <del> This approach is suitable if you can control node configuration. {{< note >}} Default Kubernetes only supports the `auths` and `HttpHeaders` section in Docker configuration. Docker credential helpers (`credHelpers` or `credsStore`) are not supported. {{< /note >}} Docker stores keys for private registries in the `$HOME/.dockercfg` or `$HOME/.docker/config.json` file.  If you put the same file in the search paths list below, kubelet uses it as the credential provider when pulling images. * `{--root-dir:-/var/lib/kubelet}/config.json` * `{cwd of kubelet}/config.json` * `${HOME}/.docker/config.json` * `/.docker/config.json` * `{--root-dir:-/var/lib/kubelet}/.dockercfg` * `{cwd of kubelet}/.dockercfg` * `${HOME}/.dockercfg` * `/.dockercfg` {{< note >}} You may have to set `HOME=/root` explicitly in the environment of the kubelet process. {{< /note >}} Here are the recommended steps to configuring your nodes to use a private registry.  In this example, run these on your desktop/laptop: 1. Run `docker login [server]` for each set of credentials you want to use.  This updates `$HOME/.docker/config.json` on your PC. 1. View `$HOME/.docker/config.json` in an editor to ensure it contains only the credentials you want to use. 1. Get a list of your nodes; for example: - if you want the names: `nodes=$( kubectl get nodes -o jsonpath='{range.items[*].metadata}{.name} {end}' )` - if you want to get the IP addresses: `nodes=$( kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}' )` 1. Copy your local `.docker/config.json` to one of the search paths list above. - for example, to test this out: `for n in $nodes; do scp ~/.docker/config.json root@"$n":/var/lib/kubelet/config.json; done` {{< note >}} For production clusters, use a configuration management tool so that you can apply this setting to all the nodes where you need it. {{< /note >}} Verify by creating a Pod that uses a private image; for example: ```shell kubectl apply -f - <<EOF apiVersion: v1 kind: Pod metadata: name: private-image-test-1 spec: containers: - name: uses-private-image image: $PRIVATE_IMAGE_NAME imagePullPolicy: Always command: [ "echo", "SUCCESS" ] EOF ``` ``` pod/private-image-test-1 created ``` If everything is working, then, after a few moments, you can run: ```shell kubectl logs private-image-test-1 ``` and see that the command outputs: ``` SUCCESS ``` If you suspect that the command failed, you can run: ```shell kubectl describe pods/private-image-test-1 | grep 'Failed' ``` In case of failure, the output is similar to: ``` Fri, 26 Jun 2015 15:36:13 -0700    Fri, 26 Jun 2015 15:39:13 -0700    19    {kubelet node-i2hq}    spec.containers{uses-private-image}    failed        Failed to pull image "user/privaterepo:v1": Error: image user/privaterepo:v1 not found ``` You must ensure all nodes in the cluster have the same `.docker/config.json`.  Otherwise, pods will run on some nodes and fail to run on others.  For example, if you use node autoscaling, then each instance template needs to include the `.docker/config.json` or mount a drive that contains it. All pods will have read access to images in any private registry once private registry keys are added to the `.docker/config.json`. </del> <ins> For an example of configuring a private container image registry, see the [Pull an Image from a Private Registry](/docs/tasks/configure-pod-container/pull-image-private-registry) task. That example uses a private registry in Docker Hub. </ins> ### Interpretation of config.json {#config-json}


Question:
Ref: needs a rewrite. It mentions Docker (and Podman!) all over the place, which is a good indication that the docs are old enough to need a rewrite. At a minimum, remove mentions of Docker in these topics: /triage accepted /milestone 1.24
/assign
/assign
Reasked folks in Slack for correct disposition
Asked in the SIG Node slack channel:
To summarize the consensus from talking with folks about this issue, specifically the examples in Using a Private Registry section: The steps in the Using a Private Registry section are still valid. However, as written, it makes it sound like Docker is the only/recommended way to do this-which we dont want. We should be able to remove the docker examples and point folks to this page , which covers most of the same content with third party disclaimers already written into the examples. I plan to open a PR later this week with these changes!
Has anyone opened a PR for this issue? It seems to be referring to

to be pulled, then the kubelet will try to download them from both authentication sources if one of them fails. ### Pre-pulled images {{< note >}}


Question:
Ref: needs a rewrite. It mentions Docker (and Podman!) all over the place, which is a good indication that the docs are old enough to need a rewrite. At a minimum, remove mentions of Docker in these topics: /triage accepted /milestone 1.24
/assign
/assign
Reasked folks in Slack for correct disposition
Asked in the SIG Node slack channel:
To summarize the consensus from talking with folks about this issue, specifically the examples in Using a Private Registry section: The steps in the Using a Private Registry section are still valid. However, as written, it makes it sound like Docker is the only/recommended way to do this-which we dont want. We should be able to remove the docker examples and point folks to this page , which covers most of the same content with third party disclaimers already written into the examples. I plan to open a PR later this week with these changes!
Has anyone opened a PR for this issue? It seems to be referring to

#### Creating a Secret with a Docker config <ins> You need to know the username, registry password and client email address for authenticating to the registry, as well as its hostname. </ins> Run the following command, substituting the appropriate uppercase values: ```shell


Question:
Ref: needs a rewrite. It mentions Docker (and Podman!) all over the place, which is a good indication that the docs are old enough to need a rewrite. At a minimum, remove mentions of Docker in these topics: /triage accepted /milestone 1.24
/assign
/assign
Reasked folks in Slack for correct disposition
Asked in the SIG Node slack channel:
To summarize the consensus from talking with folks about this issue, specifically the examples in Using a Private Registry section: The steps in the Using a Private Registry section are still valid. However, as written, it makes it sound like Docker is the only/recommended way to do this-which we dont want. We should be able to remove the docker examples and point folks to this page , which covers most of the same content with third party disclaimers already written into the examples. I plan to open a PR later this week with these changes!
Has anyone opened a PR for this issue? It seems to be referring to

common use cases and suggested solutions. 1. Cluster running only non-proprietary (e.g. open-source) images.  No need to hide images. <del> - Use public images on the Docker hub. </del> <ins> - Use public images from a public registry </ins> - No configuration required. - Some cloud providers automatically cache or mirror public images, which improves availability and reduces the time to pull images. 1. Cluster running some proprietary images which should be hidden to those outside the company, but visible to all cluster users. <del> - Use a hosted private [Docker registry](https://docs.docker.com/registry/). - It may be hosted on the [Docker Hub](https://hub.docker.com/signup), or elsewhere. - Manually configure .docker/config.json on each node as described above. </del> <ins> - Use a hosted private registry - Manual configuration may be required on the nodes that need to access to private registry </ins> - Or, run an internal private registry behind your firewall with open read access. - No Kubernetes configuration is required. - Use a hosted container image registry service that controls image access


Question:
Ref: needs a rewrite. It mentions Docker (and Podman!) all over the place, which is a good indication that the docs are old enough to need a rewrite. At a minimum, remove mentions of Docker in these topics: /triage accepted /milestone 1.24
/assign
/assign
Reasked folks in Slack for correct disposition
Asked in the SIG Node slack channel:
To summarize the consensus from talking with folks about this issue, specifically the examples in Using a Private Registry section: The steps in the Using a Private Registry section are still valid. However, as written, it makes it sound like Docker is the only/recommended way to do this-which we dont want. We should be able to remove the docker examples and point folks to this page , which covers most of the same content with third party disclaimers already written into the examples. I plan to open a PR later this week with these changes!
Has anyone opened a PR for this issue? It seems to be referring to

If you need access to multiple registries, you can create one secret for each registry. <del> Kubelet will merge any `imagePullSecrets` into a single virtual `.docker/config.json` </del> ## {{% heading "whatsnext" %}}


Question:
<!-- 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: When I was reading this , I felt very confused. The meaning of this sentence is to explain that the node, volume, pod and container level information cannot be obtained from the summary API? But I read and code implementation: My understanding is: The node, volume, pod and container level information can be obtained from the summary API. So is an expression error? Proposed Solution: Enhanced description to avoid ambiguity or misrepresentation. Suggested modification: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--The English version of the original PR: /assign
Hi agree it needs fixing per I have a bunch of notes, please add your thoughts so we can clarify this matter. It is confusing.
/language en The best place to add more notes is issue
Thanks for the reminder, I've comment to
it sounds like the original author intended instead. Outputs definitely works too.
Use as the word makes sense, thanks for the reply!
/triage accepted

[the design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md). ### Summary API Source <del> The [Kubelet](/docs/reference/command-line-tools-reference/kubelet/) gathers stats at node, volume, pod and container level, and omits them in the [Summary API](https://github.com/kubernetes/kubernetes/blob/7d309e0104fedb57280b261e5677d919cb2a0e2d/staging/src/k8s.io/kubelet/pkg/apis/stats/v1alpha1/types.go) </del> <ins> The [Kubelet](/docs/reference/command-line-tools-reference/kubelet/) gathers stats at node, volume, pod and container level, and emits their statistics in the [Summary API](https://github.com/kubernetes/kubernetes/blob/7d309e0104fedb57280b261e5677d919cb2a0e2d/staging/src/k8s.io/kubelet/pkg/apis/stats/v1alpha1/types.go) </ins> for consumers to read. Pre-1.23, these resources have been primarily gathered from [cAdvisor](https://github.com/google/cadvisor). However, in 1.23 with the


Question:
deployment does not exist
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

A partir de Kubernetes 1.8, el servidor de métricas se despliega por defecto como un objeto de tipo [Deployment](https://github.com/docs/concepts/workloads/controllers/deployment/) en clústeres creados con el script `kube-up.sh`. Si usas otro mecanismo de configuración de Kubernetes, puedes desplegarlo <del> usando los [yamls de despliegue](https://github.com/kubernetes-incubator/metrics-server/tree/master/deploy) </del> <ins> usando los [yamls de despliegue](https://github.com/kubernetes-sigs/metrics-server/releases) </ins> proporcionados. Está soportado a partir de Kubernetes 1.7 (más detalles al final). El servidor reune métricas de la Summary API, que es expuesta por el [Kubelet](/docs/admin/kubelet/) en cada nodo.


Question:
On line - Its better to clarify where node object is created. My assumption is on control panel (api server).
We could use a for “object”, so that you can click on that and confirm that objects are created in the API server. /kind feature /triage accepted /priority backlog
/retitle Explain meaning of “object” in Nodes concept /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 : /retitle Explain meaning of “object” in Nodes concept /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
Hi, I would like to work on this issue. /assign

1. The kubelet on a node self-registers to the control plane 2. You (or another human user) manually add a Node object <del> After you create a Node object, or the kubelet on a node self-registers, the </del> <ins> After you create a Node {{< glossary_tooltip text="object" term_id="object" >}}, or the kubelet on a node self-registers, the </ins> control plane checks whether the new Node object is valid. For example, if you try to create a Node from the following JSON manifest:


Question:
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: (Despite the PR has been merged, it seems that the error still exists. So opening an issue here. ) From the PR : [As-is] ! ! [To-be] ! ! Proposed Solution: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--CC /area web-development
/triage accepted
Hello Thanks for reporting this issue. May i kindly know some more details to reproduce the issue. 1) Browser & Version ? 2) Resolution of your display ? I'm trying to reproduce it on wide viewport !
Hello Here is the info of my env: Windows 10 Enterprise 20H2 Google Chrome 97.0.4692.99 (64bit) Monitor resolution: 3840 1600 Chrome window size: [1868 1592] ! [1868 1592] [3767 1600] ! [3767 * 1600]
I can replicate this with Chromium and with Firefox.
/priority backlog
Thanks for the information. Please can you assign this issue to me.
try this Prow command: /assign ravikiranr26 (reply in a comment with that command on a line by itself)
/assign ravikiranr26

} } <del> body > footer { width: 100vw; } </del> /* FOOTER */ footer { background-color: #303030;


Question:
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: (Despite the PR has been merged, it seems that the error still exists. So opening an issue here. ) From the PR : [As-is] ! ! [To-be] ! ! Proposed Solution: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--CC /area web-development
/triage accepted
Hello Thanks for reporting this issue. May i kindly know some more details to reproduce the issue. 1) Browser & Version ? 2) Resolution of your display ? I'm trying to reproduce it on wide viewport !
Hello Here is the info of my env: Windows 10 Enterprise 20H2 Google Chrome 97.0.4692.99 (64bit) Monitor resolution: 3840 1600 Chrome window size: [1868 1592] ! [1868 1592] [3767 1600] ! [3767 * 1600]
I can replicate this with Chromium and with Firefox.
/priority backlog
Thanks for the information. Please can you assign this issue to me.
try this Prow command: /assign ravikiranr26 (reply in a comment with that command on a line by itself)
/assign ravikiranr26

margin-top: 25px; } <del> footer { float: left !important; } </del> p { font-weight: 300 !important; }


Question:
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: (Despite the PR has been merged, it seems that the error still exists. So opening an issue here. ) From the PR : [As-is] ! ! [To-be] ! ! Proposed Solution: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--CC /area web-development
/triage accepted
Hello Thanks for reporting this issue. May i kindly know some more details to reproduce the issue. 1) Browser & Version ? 2) Resolution of your display ? I'm trying to reproduce it on wide viewport !
Hello Here is the info of my env: Windows 10 Enterprise 20H2 Google Chrome 97.0.4692.99 (64bit) Monitor resolution: 3840 1600 Chrome window size: [1868 1592] ! [1868 1592] [3767 1600] ! [3767 * 1600]
I can replicate this with Chromium and with Firefox.
/priority backlog
Thanks for the information. Please can you assign this issue to me.
try this Prow command: /assign ravikiranr26 (reply in a comment with that command on a line by itself)
/assign ravikiranr26

.resources { width: 100%; <del> margin-top; 5%; </del> <ins> margin-top: 5%; </ins> margin-bottom: 3%; float: left; }


Question:
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: (Despite the PR has been merged, it seems that the error still exists. So opening an issue here. ) From the PR : [As-is] ! ! [To-be] ! ! Proposed Solution: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--CC /area web-development
/triage accepted
Hello Thanks for reporting this issue. May i kindly know some more details to reproduce the issue. 1) Browser & Version ? 2) Resolution of your display ? I'm trying to reproduce it on wide viewport !
Hello Here is the info of my env: Windows 10 Enterprise 20H2 Google Chrome 97.0.4692.99 (64bit) Monitor resolution: 3840 1600 Chrome window size: [1868 1592] ! [1868 1592] [3767 1600] ! [3767 * 1600]
I can replicate this with Chromium and with Firefox.
/priority backlog
Thanks for the information. Please can you assign this issue to me.
try this Prow command: /assign ravikiranr26 (reply in a comment with that command on a line by itself)
/assign ravikiranr26

font-weight: bold; } <del> /* .fullbutton { padding: 3% !important; } */ </del> } @media (max-width:1000px) {


Question:
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: (Despite the PR has been merged, it seems that the error still exists. So opening an issue here. ) From the PR : [As-is] ! ! [To-be] ! ! Proposed Solution: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--CC /area web-development
/triage accepted
Hello Thanks for reporting this issue. May i kindly know some more details to reproduce the issue. 1) Browser & Version ? 2) Resolution of your display ? I'm trying to reproduce it on wide viewport !
Hello Here is the info of my env: Windows 10 Enterprise 20H2 Google Chrome 97.0.4692.99 (64bit) Monitor resolution: 3840 1600 Chrome window size: [1868 1592] ! [1868 1592] [3767 1600] ! [3767 * 1600]
I can replicate this with Chromium and with Firefox.
/priority backlog
Thanks for the information. Please can you assign this issue to me.
try this Prow command: /assign ravikiranr26 (reply in a comment with that command on a line by itself)
/assign ravikiranr26

.resources { width: 100%; <del> margin-top; 8%; </del> <ins> margin-top: 8%; </ins> margin-bottom: 8%; float: left; }


Question:
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: (Despite the PR has been merged, it seems that the error still exists. So opening an issue here. ) From the PR : [As-is] ! ! [To-be] ! ! Proposed Solution: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--CC /area web-development
/triage accepted
Hello Thanks for reporting this issue. May i kindly know some more details to reproduce the issue. 1) Browser & Version ? 2) Resolution of your display ? I'm trying to reproduce it on wide viewport !
Hello Here is the info of my env: Windows 10 Enterprise 20H2 Google Chrome 97.0.4692.99 (64bit) Monitor resolution: 3840 1600 Chrome window size: [1868 1592] ! [1868 1592] [3767 1600] ! [3767 * 1600]
I can replicate this with Chromium and with Firefox.
/priority backlog
Thanks for the information. Please can you assign this issue to me.
try this Prow command: /assign ravikiranr26 (reply in a comment with that command on a line by itself)
/assign ravikiranr26

margin-left: 5%; } .contributor { float: left; width: 100%;


Question:
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: (Despite the PR has been merged, it seems that the error still exists. So opening an issue here. ) From the PR : [As-is] ! ! [To-be] ! ! Proposed Solution: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--CC /area web-development
/triage accepted
Hello Thanks for reporting this issue. May i kindly know some more details to reproduce the issue. 1) Browser & Version ? 2) Resolution of your display ? I'm trying to reproduce it on wide viewport !
Hello Here is the info of my env: Windows 10 Enterprise 20H2 Google Chrome 97.0.4692.99 (64bit) Monitor resolution: 3840 1600 Chrome window size: [1868 1592] ! [1868 1592] [3767 1600] ! [3767 * 1600]
I can replicate this with Chromium and with Firefox.
/priority backlog
Thanks for the information. Please can you assign this issue to me.
try this Prow command: /assign ravikiranr26 (reply in a comment with that command on a line by itself)
/assign ravikiranr26

font-size: 0.7em !important; } }  No newline at end of file


Question:
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

<ins> --- title: 拡張リソースのリソースビンパッキング content_type: concept weight: 80 --- <!-- overview --> {{< feature-state for_k8s_version="v1.16" state="alpha" >}} kube-schedulerでは、優先度関数`RequestedToCapacityRatioResourceAllocation`を使用した、 拡張リソースを含むリソースのビンパッキングを有効化できます。優先度関数はそれぞれのニーズに応じて、kube-schedulerを微調整するために使用できます。 <!-- body --> ## `RequestedToCapacityRatioResourceAllocation`を使用したビンパッキングの有効化 Kubernetesでは、キャパシティー比率への要求に基づいたNodeのスコアリングをするために、各リソースの重みと共にリソースを指定することができます。これにより、ユーザーは適切なパラメーターを使用することで拡張リソースをビンパックすることができ、大規模クラスターにおける希少なリソースを有効活用できるようになります。優先度関数`RequestedToCapacityRatioResourceAllocation`の動作は`RequestedToCapacityRatioArgs`と呼ばれる設定オプションによって変わります。この引数は`shape`と`resources`パラメーターによって構成されます。`shape`パラメーターは`utilization`と`score`の値に基づいて、最も要求が多い場合か最も要求が少ない場合の関数をチューニングできます。`resources`パラメーターは、スコアリングの際に考慮されるリソース名の`name`と、各リソースの重みを指定する`weight`で構成されます。 以下は、拡張リソース`intel.com/foo`と`intel.com/bar`のビンパッキングに`requestedToCapacityRatioArguments`を設定する例になります。 ```yaml apiVersion: kubescheduler.config.k8s.io/v1beta1 kind: KubeSchedulerConfiguration profiles: # ... pluginConfig: - name: RequestedToCapacityRatio args: shape: - utilization: 0 score: 10 - utilization: 100 score: 0 resources: - name: intel.com/foo weight: 3 - name: intel.com/bar weight: 5 ``` スケジューラーには、kube-schedulerフラグ`--config=/path/to/config/file`を使用して`KubeSchedulerConfiguration`のファイルを指定することで渡すことができます。 **この機能はデフォルトで無効化されています** ### 優先度関数のチューニング `shape`は`RequestedToCapacityRatioPriority`関数の動作を指定するために使用されます。 ```yaml shape: - utilization: 0 score: 0 - utilization: 100 score: 10 ``` 上記の引数は、`utilization`が0%の場合は0、`utilization`が100%の場合は10という`score`をNodeに与え、ビンパッキングの動作を有効にしています。最小要求を有効にするには、次のようにスコアを反転させる必要があります。 ```yaml shape: - utilization: 0 score: 10 - utilization: 100 score: 0 ``` `resources`はオプションパラメーターで、デフォルトでは以下の通りです。 ``` yaml resources: - name: cpu weight: 1 - name: memory weight: 1 ``` 以下のように拡張リソースの追加に利用できます。 ```yaml resources: - name: intel.com/foo weight: 5 - name: cpu weight: 3 - name: memory weight: 1 ``` `weight`はオプションパラメーターで、指定されてない場合1が設定されます。また、マイナスの値は設定できません。 ### キャパシティ割り当てのためのNodeスコアリング このセクションは、本機能の内部詳細について理解したい方を対象としています。以下は、与えられた値に対してNodeのスコアがどのように計算されるかの例です。 要求されたリソース: ``` intel.com/foo : 2 memory: 256MB cpu: 2 ``` リソースの重み: ``` intel.com/foo : 5 memory: 1 cpu: 3 ``` `shape`の値 {{0, 0}, {100, 10}} Node1のスペック: ``` Available: intel.com/foo: 4 memory: 1 GB cpu: 8 Used: intel.com/foo: 1 memory: 256MB cpu: 1 ``` Nodeのスコア: ``` intel.com/foo  = resourceScoringFunction((2+1),4) = (100 - ((4-3)*100/4) = (100 - 25) = 75                       # requested + used = 75% * available = rawScoringFunction(75) = 7                        # floor(75/10) memory         = resourceScoringFunction((256+256),1024) = (100 -((1024-512)*100/1024)) = 50                       # requested + used = 50% * available = rawScoringFunction(50) = 5                        # floor(50/10) cpu            = resourceScoringFunction((2+1),8) = (100 -((8-3)*100/8)) = 37.5                     # requested + used = 37.5% * available = rawScoringFunction(37.5) = 3                        # floor(37.5/10) NodeScore   =  (7 * 5) + (5 * 1) + (3 * 3) / (5 + 1 + 3) =  5 ``` Node2のスペック: ``` Available: intel.com/foo: 8 memory: 1GB cpu: 8 Used: intel.com/foo: 2 memory: 512MB cpu: 6 ``` Nodeのスコア: ``` intel.com/foo  = resourceScoringFunction((2+2),8) =  (100 - ((8-4)*100/8) =  (100 - 50) =  50 =  rawScoringFunction(50) = 5 memory         = resourceScoringFunction((256+512),1024) = (100 -((1024-768)*100/1024)) = 75 = rawScoringFunction(75) = 7 cpu            = resourceScoringFunction((2+6),8) = (100 -((8-8)*100/8)) = 100 = rawScoringFunction(100) = 10 NodeScore   =  (5 * 5) + (7 * 1) + (10 * 3) / (5 + 1 + 3) =  7 ``` ## {{% heading "whatsnext" %}} - [スケジューリングフレームワーク](/ja/docs/concepts/scheduling-eviction/scheduling-framework/)について更に読む - [スケジューラーの設定](/docs/reference/scheduling/config/)について更に読む </ins>


Question:
This is a Bug Report Problem: The of is mentioned in . which is wrong, As per mention in the the correct Feature state for is . Proposed Solution: Change the Feature State of from to . Page to Update:
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
/sig network /assign
Fixed it here:

## Targeting a Namespace by its name <del> {{< feature-state state="beta" for_k8s_version="1.21" >}} </del> <ins> {{< feature-state for_k8s_version="1.22" state="stable" >}} </ins> The Kubernetes control plane sets an immutable label `kubernetes.io/metadata.name` on all namespaces, provided that the `NamespaceDefaultLabelName`