jiebi/CodeConvo huggingface dataset:
<ins> apiVersion: audit.k8s.io/v1 # 필수사항임. kind: Policy # Request Received 단계의 모든 요청에 대해 감사 이벤트를 생성하지 않음. omitStages: - "RequestReceived" rules: # RequestResponse 수준에서 파드 변경 사항 기록 - level: RequestResponse resources: - group: "" # 리소스 "파드" 가 RBAC 정책과 부합하는 파드의 하위 리소스에 대한 # 요청과 일치하지 않음. resources: ["pods"] # 메타데이터 수준에서 "pods/log", "pods/status"를 기록함. - level: Metadata resources: - group: "" resources: ["pods/log", "pods/status"] # "controller-leader" 라는 컨피그맵에 요청을 기록하지 않음." - level: None resources: - group: "" resources: ["configmaps"] resourceNames: ["controller-leader"] # 엔드포인트 또는 서비스의 "system:kube-proxy"에 의한 감시 요청 기록하지 않음. - level: None users: ["system:kube-proxy"] verbs: ["watch"] resources: - group: "" # 핵심 API 그룹 resources: ["endpoints", "services"] # 인증된 요청을 특정 리소스가 아닌 URL 경로에 기록하지 않음. - level: None userGroups: ["system:authenticated"] nonResourceURLs: - "/api*" # 와일드카드 매칭(wildcard matching). - "/version" # kube-system에 컨피그맵 변경 사항의 요청 본문을 기록함. - level: Request resources: - group: "" # 핵심 API 그룹 resources: ["configmaps"] # 이 정책은 "kube-system" 네임스페이스의 리소스에만 적용됨. # 빈 문자열 "" 은 네임스페이스가 없는 리소스를 선택하는데 사용할 수 있음. namespaces: ["kube-system"] # 메타데이터 수준에서 다른 모든 네임스페이스의 컨피그맵과 시크릿 변경 사항을 기록함. - level: Metadata resources: - group: "" # 핵심 API 그룹 resources: ["secrets", "configmaps"] # 요청 수준에서 코어 및 확장에 있는 다른 모든 리소스를 기록함. - level: Request resources: - group: "" # 핵심 API 그룹 - group: "extensions" # 그룹의 버전을 기재하면 안 된다. # 메타데이터 수준에서 다른 모든 요청을 기록하기 위한 모든 수집 정책. - level: Metadata # 이 정책에 해당하는 감시자와 같은 장기 실행 요청은 # RequestReceived에서 감사 이벤트를 생성하지 않음. omitStages: - "RequestReceived" </ins>
title: 代码贡献者（Code Contributor） id: code-contributor date: 2018-04-12 <del> full_link: /docs/community/devel/ </del> <ins> full_link: https://github.com/kubernetes/community/tree/master/contributors/devel </ins> short_description: > 为 Kubernetes 开源代码库开发并贡献代码的人。
--- title: アプリケーションのトラブルシューティング <del> description: Debugging common containerized application issues. </del> <ins> description: コンテナ化されたアプリケーションの一般的な問題をデバッグします。 </ins> weight: 20 --- <del> This doc contains a set of resources for fixing issues with containerized applications. It covers things like common issues with Kubernetes resources (like Pods, Services, or StatefulSets), advice on making sense of container termination messages, and ways to debug running containers. </del> <ins> このドキュメントには、コンテナ化されたアプリケーションの問題を解決するための、一連のリソースが記載されています。Kubernetesリソース(Pod、Service、StatefulSetなど)に関する一般的な問題や、コンテナ終了メッセージを理解するためのアドバイス、実行中のコンテナをデバッグする方法などが網羅されています。 </ins>
<ins> --- title: क्यूबएडीएम (Kubeadm) id: kubeadm date: 2018-04-12 full_link: /docs/admin/kubeadm/ short_description: > कुबेरनेट्स को जल्दी से इंस्टॉल करने और एक सुरक्षित क्लस्टर स्थापित करने के लिए एक उपकरण। aka: tags: - tool - operation --- कुबेरनेट्स को जल्दी से इंस्टॉल करने और एक सुरक्षित क्लस्टर स्थापित करने के लिए एक उपकरण। <!--more--> आप कंट्रोल प्लेन और {{< glossary_tooltip text="वर्कर नोड्स" term_id="node" >}} दोनों घटकों को स्थापित करने के लिए क्यूबएडीएम का उपयोग कर सकते हैं। </ins>
<ins> --- title: लिमिटरेंज (LimitRange) id: limitrange date: 2019-04-15 full_link:  /docs/concepts/policy/limit-range/ short_description: > नेमस्पेस में प्रति कंटेनर या पॉड में संसाधन खपत को सीमित करने के लिए प्रतिबंध प्रदान करता है। aka: tags: - core-object - fundamental - architecture related: - pod - container --- नेमस्पेस में प्रति {{< glossary_tooltip text="कंटेनर" term_id="container" >}} या {{< glossary_tooltip text="पॉड" term_id="pod" >}} में संसाधन खपत को सीमित करने के लिए प्रतिबंध प्रदान करता है। <!--more--> लिमिटरेंज, टाइप (type) द्वारा बनाई जा सकने वाले ऑब्जेक्ट्स और साथ ही नेमस्पेस में अलग-अलग {{< glossary_tooltip text="कंटेनर" term_id="container" >}} या {{< glossary_tooltip text="पॉड" term_id="pod" >}} द्वारा अनुरोध/उपभोग किए जा सकने वाले कंप्यूट संसाधनों की मात्रा को सीमित करता है। </ins>
<div class="row"> <div class="col-md-8"> <del> <h3>Objectives</h3> </del> <ins> <h3>उद्देश्य</h3> </ins> <ul> <li>जानें कुबेरनेट्स क्लस्टर क्या है।</li> <li>जानें मिनिक्यूब क्या है।</li>
## Uses for Secrets <del> There are three main ways for a Pod to use a Secret: </del> <ins> You can use Secrets for purposes such as the following: </ins> <del> - As [files](#using-secrets-as-files-from-a-pod) in a {{< glossary_tooltip text="volume" term_id="volume" >}} mounted on one or more of its containers. - As [container environment variable](#using-secrets-as-environment-variables). - By the [kubelet when pulling images](#using-imagepullsecrets) for the Pod. </del> <ins> - [Set environment variables for a container](/docs/tasks/inject-data-application/distribute-credentials-secure/#define-container-environment-variables-using-secret-data). - [Provide credentials such as SSH keys or passwords to Pods](/docs/tasks/inject-data-application/distribute-credentials-secure/#provide-prod-test-creds). - [Allow the kubelet to pull container images from private registries](/docs/tasks/configure-pod-container/pull-image-private-registry/). </ins> The Kubernetes control plane also uses Secrets; for example, [bootstrap token Secrets](#bootstrap-token-secrets) are a mechanism to help automate node registration. <ins> ### Use case: dotfiles in a secret volume You can make your data "hidden" by defining a key that begins with a dot. This key represents a dotfile or "hidden" file. For example, when the following secret is mounted into a volume, `secret-volume`, the volume will contain a single file, called `.secret-file`, and the `dotfile-test-container` will have this file present at the path `/etc/secret-volume/.secret-file`. {{< note >}} Files beginning with dot characters are hidden from the output of `ls -l`; you must use `ls -la` to see them when listing directory contents. {{< /note >}} ```yaml apiVersion: v1 kind: Secret metadata: name: dotfile-secret data: .secret-file: dmFsdWUtMg0KDQo= --- apiVersion: v1 kind: Pod metadata: name: secret-dotfiles-pod spec: volumes: - name: secret-volume secret: secretName: dotfile-secret containers: - name: dotfile-test-container image: registry.k8s.io/busybox command: - ls - "-l" - "/etc/secret-volume" volumeMounts: - name: secret-volume readOnly: true mountPath: "/etc/secret-volume" ``` ### Use case: Secret visible to one container in a Pod Consider a program that needs to handle HTTP requests, do some complex business logic, and then sign some messages with an HMAC. Because it has complex application logic, there might be an unnoticed remote file reading exploit in the server, which could expose the private key to an attacker. This could be divided into two processes in two containers: a frontend container which handles user interaction and business logic, but which cannot see the private key; and a signer container that can see the private key, and responds to simple signing requests from the frontend (for example, over localhost networking). With this partitioned approach, an attacker now has to trick the application server into doing something rather arbitrary, which may be harder than getting it to read a file. </ins> ### Alternatives to Secrets Rather than using a Secret to protect confidential data, you can pick from alternatives.
Kubernetes imposes on them. | Built-in Type                         | Usage                                   | <del> | ------------------------------------- | --------------------------------------- | | `Opaque`                              | arbitrary user-defined data             | </del> <ins> | ------------------------------------- |---------------------------------------- | | `Opaque`                              | arbitrary user-defined data            | </ins> | `kubernetes.io/service-account-token` | ServiceAccount token                    | | `kubernetes.io/dockercfg`             | serialized `~/.dockercfg` file          | | `kubernetes.io/dockerconfigjson`      | serialized `~/.docker/config.json` file |
name: mypod spec: containers: <del> - name: mypod image: redis volumeMounts: - name: foo mountPath: "/etc/foo" readOnly: true volumes: </del> <ins> - name: mypod image: redis volumeMounts: </ins> - name: foo <del> secret: secretName: mysecret optional: true </del> <ins> mountPath: "/etc/foo" readOnly: true volumes: - name: foo secret: secretName: mysecret optional: true </ins> ``` By default, Secrets are required. None of a Pod's containers will start until
password: 39528$vdg7Jb ``` <ins> ## Example: Provide prod/test credentials to Pods using Secrets {#provide-prod-test-creds} This example illustrates a Pod which consumes a secret containing production credentials and another Pod which consumes a secret with test environment credentials. 1. Create a secret for prod environment credentials: ```shell kubectl create secret generic prod-db-secret --from-literal=username=produser --from-literal=password=Y4nys7f11 ``` The output is similar to: ``` secret "prod-db-secret" created ``` 1. Create a secret for test environment credentials. ```shell kubectl create secret generic test-db-secret --from-literal=username=testuser --from-literal=password=iluvtests ``` The output is similar to: ``` secret "test-db-secret" created ``` {{< note >}} Special characters such as `$`, ``, `*`, `=`, and `!` will be interpreted by your [shell](https://en.wikipedia.org/wiki/Shell_(computing)) and require escaping. In most shells, the easiest way to escape the password is to surround it with single quotes (`'`). For example, if your actual password is `S!B*d$zDsb=`, you should execute the command as follows: ```shell kubectl create secret generic dev-db-secret --from-literal=username=devuser --from-literal=password='S!B*d$zDsb=' ``` You do not need to escape special characters in passwords from files (`--from-file`). {{< /note >}} 1. Create the Pod manifests: ```shell cat <<EOF > pod.yaml apiVersion: v1 kind: List items: - kind: Pod apiVersion: v1 metadata: name: prod-db-client-pod labels: name: prod-db-client spec: volumes: - name: secret-volume secret: secretName: prod-db-secret containers: - name: db-client-container image: myClientImage volumeMounts: - name: secret-volume readOnly: true mountPath: "/etc/secret-volume" - kind: Pod apiVersion: v1 metadata: name: test-db-client-pod labels: name: test-db-client spec: volumes: - name: secret-volume secret: secretName: test-db-secret containers: - name: db-client-container image: myClientImage volumeMounts: - name: secret-volume readOnly: true mountPath: "/etc/secret-volume" EOF ``` Note how the specs for the two Pods differ only in one field; this facilitates creating Pods with different capabilities from a common Pod template. 1. Apply all those objects on the API server by running: ```shell kubectl create -f pod.yaml ``` Both containers will have the following files present on their filesystems with the values for each container's environment: ``` /etc/secret-volume/username /etc/secret-volume/password ``` You could further simplify the base Pod specification by using two service accounts: 1. `prod-user` with the `prod-db-secret` 1. `test-user` with the `test-db-secret` The Pod specification is shortened to: ```yaml apiVersion: v1 kind: Pod metadata: name: prod-db-client-pod labels: name: prod-db-client spec: serviceAccount: prod-db-client containers: - name: db-client-container image: myClientImage ``` </ins> ### References - [Secret](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)
be reserved for the system as a whole and for Kubernetes system daemons respectively. <del> {{< note >}} Before Kubernetes version 1.20, PID resource limiting with Node-level reservations required enabling the [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `SupportNodePidsLimit` to work. {{< /note >}} </del> ## Pod PID limits Kubernetes allows you to limit the number of processes running in a Pod. You
to the kubelet, or set `PodPidsLimit` in the kubelet [configuration file](/docs/tasks/administer-cluster/kubelet-config-file/). <del> {{< note >}} Before Kubernetes version 1.20, PID resource limiting for Pods required enabling the [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `SupportPodPidsLimit` to work. {{< /note >}} </del> ## PID based eviction You can configure kubelet to start terminating a Pod when it is misbehaving and consuming abnormal amount of resources.
* `periodSeconds`: Probeが実行される頻度(秒数)。デフォルトは10秒。最小値は1。 * `timeoutSeconds`: Probeがタイムアウトになるまでの秒数。デフォルトは1秒。最小値は1。 * `successThreshold`: 一度Probeが失敗した後、次のProbeが成功したとみなされるための最小連続成功数。 <del> デフォルトは1。Liveness Probeには1を設定する必要があります。最小値は1。 </del> <ins> デフォルトは1。Liveness ProbeおよびStartup Probeには1を設定する必要があります。最小値は1。 </ins> * `failureThreshold`: Probeが失敗した場合、Kubernetesは`failureThreshold`に設定した回数までProbeを試行します。 Liveness Probeにおいて、試行回数に到達することはコンテナを再起動することを意味します。 Readiness Probeの場合は、Podが準備できていない状態として通知されます。デフォルトは3。最小値は1。
... ``` <del> contains two elements in the `from` array, and allows connections from Pods in the local Namespace with the label `role=client`, *or* from any Pod in any namespace with the label `user=alice`. </del> <ins> It contains two elements in the `from` array, and allows connections from Pods in the local Namespace with the label `role=client`, *or* from any Pod in any namespace with the label `user=alice`. </ins> When in doubt, use `kubectl describe` to see how Kubernetes has interpreted the policy. <a name="behavior-of-ipblock-selectors"></a> <del> __ipBlock__: This selects particular IP CIDR ranges to allow as ingress sources or egress destinations. These should be cluster-external IPs, since Pod IPs are ephemeral and unpredictable. </del> <ins> **ipBlock**: This selects particular IP CIDR ranges to allow as ingress sources or egress destinations. These should be cluster-external IPs, since Pod IPs are ephemeral and unpredictable. </ins> Cluster ingress and egress mechanisms often require rewriting the source or destination IP of packets. In cases where this happens, it is not defined whether this happens before or
This is achievable with the usage of the `endPort` field, as the following example: <del> ```yaml apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: multi-port-egress namespace: default spec: podSelector: matchLabels: role: db policyTypes: - Egress egress: - to: - ipBlock: cidr: 10.0.0.0/24 ports: - protocol: TCP port: 32000 endPort: 32768 ``` </del> <ins> {{< codenew file="service/networking/networkpolicy-multiport-egress.yaml" >}} </ins> The above rule allows any Pod with label `role=db` on the namespace `default` to communicate with any IP within the range `10.0.0.0/24` over TCP, provided that the target port is between the range 32000 and 32768. The following restrictions apply when using this field: * The `endPort` field must be equal to or greater than the `port` field. * `endPort` can only be defined if `port` is also defined. * Both ports must be numeric.
"name-virtual-host-ingress-no-third-host": {&networking.Ingress{}}, "namespaced-params":                       {&networking.IngressClass{}}, "networkpolicy":                           {&networking.NetworkPolicy{}}, <ins> "networkpolicy-multiport-egress":          {&networking.NetworkPolicy{}}, </ins> "network-policy-allow-all-egress":         {&networking.NetworkPolicy{}}, "network-policy-allow-all-ingress":        {&networking.NetworkPolicy{}}, "network-policy-default-deny-egress":      {&networking.NetworkPolicy{}},
both version before the node is upgraded in order to guarantee that device allocations continue to complete successfully during the upgrade. <del> Refer to [API compatiblity](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#api-compatibility) and [Kubelet Device Manager API Versions](/docs/reference/node/device-plugin-api-versions/) for more details. </del> <ins> Refer to [API compatibility](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#api-compatibility) and [Kubelet Device Manager API Versions](/docs/reference/node/device-plugin-api-versions/) for more details. </ins>  No newline at end of file
First, the user defines a new configuration containing only the `replicas` field: <del> {{< codenew file="application/ssa/nginx-deployment-replicas-only.yaml" >}} </del> <ins> ```yaml # Save this file as 'nginx-deployment-replicas-only.yaml'. apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 3 ``` {{< note >}} The YAML file for SSA in this case only contains the fields you want to change. You are not supposed to provide a fully compliant Deployment manifest if you only want to modify the `spec.replicas` field using SSA. {{< /note >}} </ins> The user applies that configuration using the field manager name `handover-to-hpa`: ```shell <del> kubectl apply -f https://k8s.io/examples/application/ssa/nginx-deployment-replicas-only.yaml  </del> <ins> kubectl apply -f nginx-deployment-replicas-only.yaml  </ins> --server-side --field-manager=handover-to-hpa  --validate=false ```
"nginx-svc":        {&api.Service{}}, }, "application/ssa": { <del> "nginx-deployment":               {&apps.Deployment{}}, "nginx-deployment-no-replicas":   {&apps.Deployment{}}, "nginx-deployment-replicas-only": {&apps.Deployment{}}, </del> <ins> "nginx-deployment":             {&apps.Deployment{}}, "nginx-deployment-no-replicas": {&apps.Deployment{}}, </ins> }, "application/web": { "web":          {&api.Service{}, &apps.StatefulSet{}},
この時点で、オブジェクトはKubernetesAPIに表示されなくなります。 フォアグラウンドカスケード削除中に、オーナーの削除をブロックする依存関係は、`ownerReference.blockOwnerDeletion=true`フィールドを持つ依存関係のみです。 <del> 詳細については、[フォアグラウンドカスケード削除の使用](/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion)を参照してください。 </del> <ins> 詳細については、[フォアグラウンドカスケード削除の使用](/ja/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion)を参照してください。 </ins> ### バックグラウンドカスケード削除 {#background-deletion} バックグラウンドカスケード削除では、Kubernetes APIサーバーがオーナーオブジェクトをすぐに削除し、コントローラーがバックグラウンドで依存オブジェクトをクリーンアップします。 デフォルトでは、フォアグラウンド削除を手動で使用するか、依存オブジェクトを孤立させることを選択しない限り、Kubernetesはバックグラウンドカスケード削除を使用します。 <del> 詳細については、[バックグラウンドカスケード削除の使用](/docs/tasks/administer-cluster/use-cascading-deletion/#use-background-cascading-deletion)を参照してください。 </del> <ins> 詳細については、[バックグラウンドカスケード削除の使用](/ja/docs/tasks/administer-cluster/use-cascading-deletion/#use-background-cascading-deletion)を参照してください。 </ins> ### 孤立した依存関係 Kubernetesがオーナーオブジェクトを削除すると、残された依存関係は*orphan*オブジェクトと呼ばれます。 <del> デフォルトでは、Kubernetesは依存関係オブジェクトを削除します。この動作をオーバーライドする方法については、[オーナーオブジェクトと孤立した依存関係の削除](/docs/tasks/administer-cluster/use-cascading-deletion/#set-orphan-deletion-policy)を参照してください。 </del> <ins> デフォルトでは、Kubernetesは依存関係オブジェクトを削除します。この動作をオーバーライドする方法については、[オーナーオブジェクトの削除と従属オブジェクトの孤立](/ja/docs/tasks/administer-cluster/use-cascading-deletion/#set-orphan-deletion-policy)を参照してください。 </ins> ## 未使用のコンテナとイメージのガベージコレクション {#containers-images}
これらのリソースを管理するコントローラーに固有のオプションを設定することにより、リソースのガベージコレクションを調整できます。次のページは、ガベージコレクションを設定する方法を示しています。 <del> * [Kubernetesオブジェクトのカスケード削除の設定](/docs/tasks/administer-cluster/use-cascading-deletion/) </del> <ins> * [Kubernetesオブジェクトのカスケード削除の設定](/ja/docs/tasks/administer-cluster/use-cascading-deletion/) </ins> * [完了したジョブのクリーンアップの設定](/ja/docs/concepts/workloads/controllers/ttlafterfinished/) <!-- * [Configuring unused container and image garbage collection](/docs/tasks/administer-cluster/reconfigure-kubelet/) -->
<!-- lessoncontent --> <del> ## nginx deploymentの作成と探検 </del> <ins> ## nginx deploymentの作成と探検 {#creating-and-exploring-an-nginx-deployment} </ins> Kubernetes Deploymentオブジェクトを作成することでアプリケーションを実行できます。また、YAMLファイルでDeploymentを記述できます。例えば、このYAMLファイルはnginx:1.14.2 Dockerイメージを実行するデプロイメントを記述しています:
<div class="row"> <div class="col-md-8"> <p><b>The Control Plane is responsible for managing the cluster.</b> The Control Plane coordinates all activities in your cluster, such as scheduling applications, maintaining applications' desired state, scaling applications, and rolling out new updates.</p> <del> <p><b>A node is a VM or a physical computer that serves as a worker machine in a Kubernetes cluster.</b> Each node has a Kubelet, which is an agent for managing the node and communicating with the Kubernetes control plane. The node should also have tools for handling container operations, such as containerd or Docker. A Kubernetes cluster that handles production traffic should have a minimum of three nodes because if one node goes down, both an <a href="/docs/concepts/overview/components/#etcd">etcd</a> member and a control plane instance are lost, and redundancy is compromised. You can mitigate this risk by adding more control plane nodes.</p> </del> <ins> <p><b>A node is a VM or a physical computer that serves as a worker machine in a Kubernetes cluster.</b> Each node has a Kubelet, which is an agent for managing the node and communicating with the Kubernetes control plane. The node should also have tools for handling container operations, such as {{< glossary_tooltip text="containerd" term_id="containerd" >}} or {{< glossary_tooltip term_id="cri-o" >}}. A Kubernetes cluster that handles production traffic should have a minimum of three nodes because if one node goes down, both an <a href="/docs/concepts/overview/components/#etcd">etcd</a> member and a control plane instance are lost, and redundancy is compromised. You can mitigate this risk by adding more control plane nodes.</p> </ins> </div> <div class="col-md-4">
* The root filesystem of the Node will be mounted at `/host`. * The container runs in the host IPC, Network, and PID namespaces, although the pod isn't privileged, so reading some process information may fail, <del> and `chroot /host` will fail. </del> <ins> and `chroot /host` may fail. </ins> * If you need a privileged pod, create it manually. Don't forget to clean up the debugging Pod when you're finished with it:
<!-- body --> ## Control Plane Components <del> The control plane's components make global decisions about the cluster (for example, scheduling), as well as detecting and responding to cluster events (for example, starting up a new {{< glossary_tooltip text="pod" term_id="pod">}} when a deployment's `replicas` field is unsatisfied). </del> <ins> The control plane's components make global decisions about the cluster (for example, scheduling), as well as detecting and responding to cluster events (for example, starting up a new {{< glossary_tooltip text="pod" term_id="pod">}} when a Deployment's `{{< glossary_tooltip text="replicas" term_id="replica" >}}` field is unsatisfied). </ins> Control plane components can be run on any machine in the cluster. However, for simplicity, set up scripts typically start all control plane components on
### DNS <del> While the other addons are not strictly required, all Kubernetes clusters should have [cluster DNS](/docs/concepts/services-networking/dns-pod-service/), as many examples rely on it. </del> <ins> While the other addons are not strictly required, all Kubernetes clusters should have [cluster DNS](/docs/concepts/services-networking/dns-pod-service/), as many examples rely on it. </ins> <del> Cluster DNS is a DNS server, in addition to the other DNS server(s) in your environment, which serves DNS records for Kubernetes services. </del> <ins> Cluster DNS is a DNS server, in addition to the other DNS server(s) in your environment, which serves DNS records for Kubernetes services. </ins> Containers started by Kubernetes automatically include this DNS server in their DNS searches. ### Web UI (Dashboard) <del> [Dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/) is a general purpose, web-based UI for Kubernetes clusters. It allows users to manage and troubleshoot applications running in the cluster, as well as the cluster itself. </del> <ins> [Dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/) is a general purpose, web-based UI for Kubernetes clusters. It allows users to manage and troubleshoot applications running in the cluster, as well as the cluster itself. </ins> ### Container Resource Monitoring <del> [Container Resource Monitoring](/docs/tasks/debug/debug-cluster/resource-usage-monitoring/) records generic time-series metrics </del> <ins> [Container Resource Monitoring](/docs/tasks/debug/debug-cluster/resource-usage-monitoring/) records generic time-series metrics </ins> about containers in a central database, and provides a UI for browsing that data. ### Cluster-level Logging