Merge remote-tracking branch 'upstream/main' into dev-1.24
This commit is contained in:
@@ -59,7 +59,7 @@ Before choosing a guide, here are some considerations:
|
||||
|
||||
* [Using Sysctls in a Kubernetes Cluster](/docs/tasks/administer-cluster/sysctl-cluster/) describes to an administrator how to use the `sysctl` command-line tool to set kernel parameters .
|
||||
|
||||
* [Auditing](/docs/tasks/debug-application-cluster/audit/) describes how to interact with Kubernetes' audit logs.
|
||||
* [Auditing](/docs/tasks/debug/debug-cluster/audit/) describes how to interact with Kubernetes' audit logs.
|
||||
|
||||
### Securing the kubelet
|
||||
* [Control Plane-Node communication](/docs/concepts/architecture/control-plane-node-communication/)
|
||||
|
||||
@@ -47,10 +47,9 @@ or by enforcement (the system prevents the container from ever exceeding the lim
|
||||
runtimes can have different ways to implement the same restrictions.
|
||||
|
||||
{{< note >}}
|
||||
If a container specifies its own memory limit, but does not specify a memory request, Kubernetes
|
||||
automatically assigns a memory request that matches the limit. Similarly, if a container specifies its own
|
||||
CPU limit, but does not specify a CPU request, Kubernetes automatically assigns a CPU request that matches
|
||||
the limit.
|
||||
If you specify a limit for a resource, but do not specify any request, and no admission-time
|
||||
mechanism has applied a default request for that resource, then Kubernetes copies the limit
|
||||
you specified and uses it as the requested value for the resource.
|
||||
{{< /note >}}
|
||||
|
||||
## Resource types
|
||||
@@ -229,9 +228,9 @@ see the [Troubleshooting](#troubleshooting) section.
|
||||
The kubelet reports the resource usage of a Pod as part of the Pod
|
||||
[`status`](/docs/concepts/overview/working-with-objects/kubernetes-objects/#object-spec-and-status).
|
||||
|
||||
If optional [tools for monitoring](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)
|
||||
If optional [tools for monitoring](/docs/tasks/debug/debug-cluster/resource-usage-monitoring/)
|
||||
are available in your cluster, then Pod resource usage can be retrieved either
|
||||
from the [Metrics API](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#metrics-api)
|
||||
from the [Metrics API](/docs/tasks/debug/debug-cluster/resource-metrics-pipeline/#metrics-api)
|
||||
directly or from your monitoring tools.
|
||||
|
||||
## Local ephemeral storage
|
||||
|
||||
@@ -114,7 +114,7 @@ Containers started by Kubernetes automatically include this DNS server in their
|
||||
|
||||
### Container Resource Monitoring
|
||||
|
||||
[Container Resource Monitoring](/docs/tasks/debug-application-cluster/resource-usage-monitoring/) records generic time-series metrics
|
||||
[Container Resource Monitoring](/docs/tasks/debug/debug-cluster/resource-usage-monitoring/) records generic time-series metrics
|
||||
about containers in a central database, and provides a UI for browsing that data.
|
||||
|
||||
### Cluster-level Logging
|
||||
|
||||
@@ -134,7 +134,7 @@ for the corresponding API object, and then written to the object store (shown as
|
||||
Kubernetes auditing provides a security-relevant, chronological set of records documenting the sequence of actions in a cluster.
|
||||
The cluster audits the activities generated by users, by applications that use the Kubernetes API, and by the control plane itself.
|
||||
|
||||
For more information, see [Auditing](/docs/tasks/debug-application-cluster/audit/).
|
||||
For more information, see [Auditing](/docs/tasks/debug/debug-cluster/audit/).
|
||||
|
||||
## API server ports and IPs
|
||||
|
||||
|
||||
@@ -86,7 +86,7 @@ takes if a potential violation is detected:
|
||||
Mode | Description
|
||||
:---------|:------------
|
||||
**enforce** | Policy violations will cause the pod to be rejected.
|
||||
**audit** | Policy violations will trigger the addition of an audit annotation to the event recorded in the [audit log](/docs/tasks/debug-application-cluster/audit/), but are otherwise allowed.
|
||||
**audit** | Policy violations will trigger the addition of an audit annotation to the event recorded in the [audit log](/docs/tasks/debug/debug-cluster/audit/), but are otherwise allowed.
|
||||
**warn** | Policy violations will trigger a user-facing warning, but are otherwise allowed.
|
||||
{{< /table >}}
|
||||
|
||||
|
||||
@@ -658,8 +658,7 @@ added. Capabilities listed in `RequiredDropCapabilities` must not be included in
|
||||
|
||||
**DefaultAddCapabilities** - The capabilities which are added to containers by
|
||||
default, in addition to the runtime defaults. See the
|
||||
[Docker documentation](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities)
|
||||
for the default list of capabilities when using the Docker runtime.
|
||||
the documentation for your container runtime for information on working with Linux capabilities.
|
||||
|
||||
### SELinux
|
||||
|
||||
|
||||
@@ -49,7 +49,7 @@ metadata:
|
||||
name: standard
|
||||
provisioner: kubernetes.io/aws-ebs
|
||||
parameters:
|
||||
type: gp3
|
||||
type: gp2
|
||||
reclaimPolicy: Retain
|
||||
allowVolumeExpansion: true
|
||||
mountOptions:
|
||||
@@ -271,9 +271,9 @@ parameters:
|
||||
fsType: ext4
|
||||
```
|
||||
|
||||
* `type`: `io1`, `gp2`, `gp3`, `sc1`, `st1`. See
|
||||
* `type`: `io1`, `gp2`, `sc1`, `st1`. See
|
||||
[AWS docs](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html)
|
||||
for details. Default: `gp3`.
|
||||
for details. Default: `gp2`.
|
||||
* `zone` (Deprecated): AWS zone. If neither `zone` nor `zones` is specified, volumes are
|
||||
generally round-robin-ed across all active zones where Kubernetes cluster
|
||||
has a node. `zone` and `zones` parameters must not be used at the same time.
|
||||
|
||||
@@ -70,5 +70,5 @@ you can view processes in other containers.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* Learn how to [debug pods using ephemeral containers](/docs/tasks/debug-application-cluster/debug-running-pod/#ephemeral-container).
|
||||
* Learn how to [debug pods using ephemeral containers](/docs/tasks/debug/debug-application/debug-running-pod/#ephemeral-container).
|
||||
|
||||
|
||||
@@ -332,5 +332,6 @@ Kubernetes, consult the documentation for the version you are using.
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* Read about [creating a Pod that has an init container](/docs/tasks/configure-pod-container/configure-pod-initialization/#create-a-pod-that-has-an-init-container)
|
||||
* Learn how to [debug init containers](/docs/tasks/debug-application-cluster/debug-init-containers/)
|
||||
* Learn how to [debug init containers](/docs/tasks/debug/debug-application/debug-init-containers/)
|
||||
|
||||
|
||||
|
||||
@@ -46,7 +46,7 @@ To run the link checker:
|
||||
2. Run the following command:
|
||||
|
||||
```
|
||||
make docker-internal-linkcheck
|
||||
make container-internal-linkcheck
|
||||
```
|
||||
|
||||
## Understanding the output
|
||||
|
||||
@@ -1396,7 +1396,7 @@ monitoring mechanisms help cluster admins to answer questions like:
|
||||
Sometimes it's useful to know which mutating webhook mutated the object in a API request, and what change did the
|
||||
webhook apply.
|
||||
|
||||
In v1.16+, kube-apiserver performs [auditing](/docs/tasks/debug-application-cluster/audit/) on each mutating webhook
|
||||
In v1.16+, kube-apiserver performs [auditing](/docs/tasks/debug/debug-cluster/audit/) on each mutating webhook
|
||||
invocation. Each invocation generates an auditing annotation
|
||||
capturing if a request object is mutated by the invocation, and optionally generates an annotation capturing the applied
|
||||
patch from the webhook admission response. The annotations are set in the audit event for given request on given stage of
|
||||
|
||||
@@ -607,7 +607,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
|
||||
Docker Engine; no longer available. See
|
||||
[Device Plugins](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) for
|
||||
an alternative.
|
||||
- `AdvancedAuditing`: Enable [advanced auditing](/docs/tasks/debug-application-cluster/audit/#advanced-audit)
|
||||
- `AdvancedAuditing`: Enable [advanced auditing](/docs/tasks/debug/debug-cluster/audit/#advanced-audit)
|
||||
- `AffinityInAnnotations`: Enable setting
|
||||
[Pod affinity or anti-affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity).
|
||||
- `AllowExtTrafficLocalEndpoints`: Enable a service to route external requests to node local endpoints.
|
||||
|
||||
@@ -0,0 +1,18 @@
|
||||
---
|
||||
title: Dockershim
|
||||
id: dockershim
|
||||
date: 2022-04-15
|
||||
full_link: /dockershim
|
||||
short_description: >
|
||||
A component of Kubernetes v1.23 and earlier, which allows Kubernetes system components to communicate with Docker Engine.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
---
|
||||
The dockershim is a component of Kubernetes version 1.23 and earlier. It allows the kubelet
|
||||
to communicate with {{< glossary_tooltip text="Docker Engine" term_id="docker" >}}.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Starting with version 1.24, dockershim has been removed from Kubernetes. For more information, see [Dockershim FAQ](/dockershim).
|
||||
@@ -21,5 +21,5 @@ or the continued existence of events with that reason.
|
||||
|
||||
Events should be treated as informative, best-effort, supplemental data.
|
||||
|
||||
In Kubernetes, [auditing](/docs/tasks/debug-application-cluster/audit/) generates a different kind of
|
||||
In Kubernetes, [auditing](/docs/tasks/debug/debug-cluster/audit/) generates a different kind of
|
||||
Event record (API group `audit.k8s.io`).
|
||||
|
||||
@@ -187,7 +187,7 @@ kubectl exec -ti nginx-app-5jyvm -- /bin/sh
|
||||
# exit
|
||||
```
|
||||
|
||||
For more information, see [Get a Shell to a Running Container](/docs/tasks/debug-application-cluster/get-shell-running-container/).
|
||||
For more information, see [Get a Shell to a Running Container](/docs/tasks/debug/debug-application/get-shell-running-container/).
|
||||
|
||||
## docker logs
|
||||
|
||||
|
||||
@@ -11,7 +11,7 @@ namespace. These annotations apply to `Event` object from API group
|
||||
|
||||
{{< note >}}
|
||||
The following annotations are not used within the Kubernetes API. When you
|
||||
[enable auditing](/docs/tasks/debug-application-cluster/audit/) in your cluster,
|
||||
[enable auditing](/docs/tasks/debug/debug-cluster/audit/) in your cluster,
|
||||
audit event data is written using `Event` from API group `audit.k8s.io`.
|
||||
The annotations apply to audit events. Audit events are different from objects in the
|
||||
[Event API](/docs/reference/kubernetes-api/cluster-resources/event-v1/) (API group
|
||||
@@ -64,15 +64,15 @@ Example: `authorization.k8s.io/decision: "forbid"`
|
||||
|
||||
This annotation indicates whether or not a request was authorized in Kubernetes audit logs.
|
||||
|
||||
See [Auditing](/docs/tasks/debug-application-cluster/audit/) for more information.
|
||||
See [Auditing](/docs/tasks/debug/debug-cluster/audit/) for more information.
|
||||
|
||||
## authorization.k8s.io/reason
|
||||
|
||||
Example: `authorization.k8s.io/decision: "Human-readable reason for the decision"`
|
||||
Example: `authorization.k8s.io/reason: "Human-readable reason for the decision"`
|
||||
|
||||
This annotation gives reason for the [decision](#authorization-k8s-io-decision) in Kubernetes audit logs.
|
||||
|
||||
See [Auditing](/docs/tasks/debug-application-cluster/audit/) for more information.
|
||||
See [Auditing](/docs/tasks/debug/debug-cluster/audit/) for more information.
|
||||
|
||||
## missing-san.invalid-cert.kubernetes.io/$hostname
|
||||
|
||||
|
||||
@@ -30,9 +30,6 @@ resources itself.
|
||||
[Helm](https://helm.sh/) is a tool for managing packages of pre-configured
|
||||
Kubernetes resources. These packages are known as _Helm charts_.
|
||||
|
||||
Helm is a third party managed tool for managing packages of pre-configured
|
||||
Kubernetes resources, aka Kubernetes charts.
|
||||
|
||||
Use Helm to:
|
||||
|
||||
* Find and use popular software packaged as Kubernetes charts
|
||||
|
||||
@@ -286,7 +286,7 @@ behavior get removed.
|
||||
Starting in Kubernetes v1.19, making an API request to a deprecated REST API endpoint:
|
||||
|
||||
1. Returns a `Warning` header (as defined in [RFC7234, Section 5.5](https://tools.ietf.org/html/rfc7234#section-5.5)) in the API response.
|
||||
2. Adds a `"k8s.io/deprecated":"true"` annotation to the [audit event](/docs/tasks/debug-application-cluster/audit/) recorded for the request.
|
||||
2. Adds a `"k8s.io/deprecated":"true"` annotation to the [audit event](/docs/tasks/debug/debug-cluster/audit/) recorded for the request.
|
||||
3. Sets an `apiserver_requested_deprecated_apis` gauge metric to `1` in the `kube-apiserver`
|
||||
process. The metric has labels for `group`, `version`, `resource`, `subresource` that can be joined
|
||||
to the `apiserver_request_total` metric, and a `removed_release` label that indicates the
|
||||
|
||||
@@ -197,7 +197,7 @@ are some virtualization platforms that can be scripted to spin up new nodes
|
||||
based on demand.
|
||||
- *Set up node health checks*: For important workloads, you want to make sure
|
||||
that the nodes and pods running on those nodes are healthy. Using the
|
||||
[Node Problem Detector](/docs/tasks/debug-application-cluster/monitor-node-health/)
|
||||
[Node Problem Detector](/docs/tasks/debug/debug-cluster/monitor-node-health/)
|
||||
daemon, you can ensure your nodes are healthy.
|
||||
|
||||
## Production user management
|
||||
|
||||
@@ -166,18 +166,14 @@ Use the following commands to install Containerd on your system:
|
||||
1. Install containerd:
|
||||
|
||||
Visit
|
||||
[Getting started with containerd](https://containerd.io/docs/getting-started/#starting-containerd)
|
||||
[Getting started with containerd](https://github.com/containerd/containerd/blob/main/docs/getting-started.md)
|
||||
and follow the instructions there, up to the point where you have a valid
|
||||
configuration file (on Linux: `/etc/containerd/config.toml`).
|
||||
configuration file, config.toml.
|
||||
On Linux, you can find this file under the path `/etc/containerd/config.toml`.
|
||||
On Windows, you can find this file under the path `C:\Program Files\containerd\config.toml`.
|
||||
|
||||
If you are running Windows, you might want to exclude containerd from Windows Defender Scans
|
||||
```powershell
|
||||
# If excluding containerd from Windows Defender scans, consider how else
|
||||
# you will make sure that the executable is genuine.
|
||||
Add-MpPreference -ExclusionProcess "$Env:ProgramFiles\containerd\containerd.exe"
|
||||
```
|
||||
|
||||
For containerd, the CRI socket is `/run/containerd/containerd.sock` by default.
|
||||
On Linux the default CRI socket for containerd is `/run/containerd/containerd.sock`.
|
||||
On Windows the default CRI endpoint is `npipe://./pipe/containerd-containerd`.
|
||||
|
||||
#### Configuring the `systemd` cgroup driver {#containerd-systemd}
|
||||
|
||||
|
||||
+2
-2
@@ -93,7 +93,7 @@ This may be caused by a number of problems. The most common are:
|
||||
configure it properly see [Configuring a cgroup driver](/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/).
|
||||
- control plane containers are crashlooping or hanging. You can check this by running `docker ps`
|
||||
and investigating each container by running `docker logs`. For other container runtime see
|
||||
[Debugging Kubernetes nodes with crictl](/docs/tasks/debug-application-cluster/crictl/).
|
||||
[Debugging Kubernetes nodes with crictl](/docs/tasks/debug/debug-cluster/crictl/).
|
||||
|
||||
## kubeadm blocks when removing managed containers
|
||||
|
||||
@@ -151,7 +151,7 @@ services](/docs/concepts/services-networking/service/#type-nodeport) or use `Hos
|
||||
|
||||
## Pods are not accessible via their Service IP
|
||||
|
||||
- Many network add-ons do not yet enable [hairpin mode](/docs/tasks/debug-application-cluster/debug-service/#a-pod-fails-to-reach-itself-via-the-service-ip)
|
||||
- Many network add-ons do not yet enable [hairpin mode](/docs/tasks/debug/debug-application/debug-service/#a-pod-fails-to-reach-itself-via-the-service-ip)
|
||||
which allows pods to access themselves via their Service IP. This is an issue related to
|
||||
[CNI](https://github.com/containernetworking/cni/issues/476). Please contact the network
|
||||
add-on provider to get the latest status of their support for hairpin mode.
|
||||
|
||||
@@ -547,7 +547,7 @@ None of the Pod [`securityContext`](/docs/reference/kubernetes-api/workload-reso
|
||||
### Node problem detector
|
||||
|
||||
The node problem detector (see
|
||||
[Monitor Node Health](/docs/tasks/debug-application-cluster/monitor-node-health/))
|
||||
[Monitor Node Health](/docs/tasks/debug/debug-cluster/monitor-node-health/))
|
||||
is not compatible with Windows.
|
||||
|
||||
### Pause container
|
||||
@@ -625,7 +625,7 @@ The Kubernetes [version-skew policy](/docs/setup/release/version-skew-policy/) a
|
||||
## Getting help and troubleshooting {#troubleshooting}
|
||||
|
||||
Your main source of help for troubleshooting your Kubernetes cluster should start
|
||||
with the [Troubleshooting](/docs/tasks/debug-application-cluster/troubleshooting/)
|
||||
with the [Troubleshooting](/docs/tasks/debug/debug-cluster/)
|
||||
page.
|
||||
|
||||
Some additional, Windows-specific troubleshooting help is included
|
||||
|
||||
@@ -176,7 +176,7 @@ The service name is `kube-dns` for both CoreDNS and kube-dns deployments.
|
||||
|
||||
If you have created the Service or in the case it should be created by default
|
||||
but it does not appear, see
|
||||
[debugging Services](/docs/tasks/debug-application-cluster/debug-service/) for
|
||||
[debugging Services](/docs/tasks/debug/debug-application/debug-service/) for
|
||||
more information.
|
||||
|
||||
### Are DNS endpoints exposed?
|
||||
@@ -193,7 +193,7 @@ kube-dns 10.180.3.17:53,10.180.3.17:53 1h
|
||||
```
|
||||
|
||||
If you do not see the endpoints, see the endpoints section in the
|
||||
[debugging Services](/docs/tasks/debug-application-cluster/debug-service/) documentation.
|
||||
[debugging Services](/docs/tasks/debug/debug-application/debug-service/) documentation.
|
||||
|
||||
For additional Kubernetes DNS examples, see the
|
||||
[cluster-dns examples](https://github.com/kubernetes/examples/tree/master/staging/cluster-dns)
|
||||
|
||||
@@ -11,7 +11,7 @@ weight: 20
|
||||
This page explains how to upgrade a Kubernetes cluster created with kubeadm from version
|
||||
{{< skew currentVersionAddMinor -1 >}}.x to version {{< skew currentVersion >}}.x, and from version
|
||||
{{< skew currentVersion >}}.x to {{< skew currentVersion >}}.y (where `y > x`). Skipping MINOR versions
|
||||
when upgrading is unsupported.
|
||||
when upgrading is unsupported. For more details, please visit [Version Skew Policy](https://kubernetes.io/releases/version-skew-policy/).
|
||||
|
||||
To see information about upgrading clusters created using older versions of kubeadm,
|
||||
please refer to following pages instead:
|
||||
|
||||
+1
-1
@@ -13,7 +13,7 @@ Kubernetes' support for direct integration with Docker Engine is deprecated, and
|
||||
## Telemetry and security agents
|
||||
|
||||
Within a Kubernetes cluster there are a few different ways to run telemetry or security agents.
|
||||
Some agents have a direct dependency on Docker Engine when they as DaemonSets or
|
||||
Some agents have a direct dependency on Docker Engine when they run as DaemonSets or
|
||||
directly on nodes.
|
||||
|
||||
### Why do some telemetry agents communicate with Docker Engine?
|
||||
|
||||
@@ -210,7 +210,7 @@ access to a subset of the keyspace is strongly recommended.
|
||||
|
||||
### Enable audit logging
|
||||
|
||||
The [audit logger](/docs/tasks/debug-application-cluster/audit/) is a beta feature that records actions taken by the
|
||||
The [audit logger](/docs/tasks/debug/debug-cluster/audit/) is a beta feature that records actions taken by the
|
||||
API for later analysis in the event of a compromise. It is recommended to enable audit logging
|
||||
and archive the audit file on a secure server.
|
||||
|
||||
|
||||
+1
-1
@@ -59,7 +59,7 @@ and restarts it.
|
||||
When the container starts, it executes this command:
|
||||
|
||||
```shell
|
||||
/bin/sh -c "touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600"
|
||||
/bin/sh -c "touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600"
|
||||
```
|
||||
|
||||
For the first 30 seconds of the container's life, there is a `/tmp/healthy` file.
|
||||
|
||||
@@ -85,7 +85,7 @@ The output shows that nginx is serving the web page that was written by the init
|
||||
[communicating between Containers running in the same Pod](/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/).
|
||||
* Learn more about [Init Containers](/docs/concepts/workloads/pods/init-containers/).
|
||||
* Learn more about [Volumes](/docs/concepts/storage/volumes/).
|
||||
* Learn more about [Debugging Init Containers](/docs/tasks/debug-application-cluster/debug-init-containers/)
|
||||
* Learn more about [Debugging Init Containers](/docs/tasks/debug/debug-application/debug-init-containers/)
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -399,7 +399,7 @@ in the `securityContext` section of your Pod or Container manifest. The
|
||||
[SeccompProfile](/docs/reference/generated/kubernetes-api/{{< param "version"
|
||||
>}}/#seccompprofile-v1-core) object consisting of `type` and `localhostProfile`.
|
||||
Valid options for `type` include `RuntimeDefault`, `Unconfined`, and
|
||||
`Localhost`. `localhostProfile` must only be set set if `type: Localhost`. It
|
||||
`Localhost`. `localhostProfile` must only be set if `type: Localhost`. It
|
||||
indicates the path of the pre-configured profile on the node, relative to the
|
||||
kubelet's configured Seccomp profile location (configured with the `--root-dir`
|
||||
flag).
|
||||
|
||||
@@ -7,7 +7,7 @@ content_type: task
|
||||
|
||||
{{% thirdparty-content %}}
|
||||
|
||||
Kubernetes applications usually consist of multiple, separate services, each running in its own container. Developing and debugging these services on a remote Kubernetes cluster can be cumbersome, requiring you to [get a shell on a running container](/docs/tasks/debug-application-cluster/get-shell-running-container/) in order to run debugging tools.
|
||||
Kubernetes applications usually consist of multiple, separate services, each running in its own container. Developing and debugging these services on a remote Kubernetes cluster can be cumbersome, requiring you to [get a shell on a running container](/docs/tasks/debug/debug-application/get-shell-running-container/) in order to run debugging tools.
|
||||
|
||||
`telepresence` is a tool to ease the process of developing and debugging services locally while proxying the service to a remote Kubernetes cluster. Using `telepresence` allows you to use custom tools, such as a debugger and IDE, for a local service and provides the service full access to ConfigMap, secrets, and the services running on the remote cluster.
|
||||
|
||||
|
||||
@@ -28,7 +28,7 @@ The Metrics API, and the metrics pipeline that it enables, only offers the minim
|
||||
CPU and memory metrics to enable automatic scaling using HPA and / or VPA.
|
||||
If you would like to provide a more complete set of metrics, you can complement
|
||||
the simpler Metrics API by deploying a second
|
||||
[metrics pipeline](/docs/tasks/debug-application-cluster/resource-usage-monitoring/#full-metrics-pipeline)
|
||||
[metrics pipeline](/docs/tasks/debug/debug-cluster/resource-usage-monitoring/#full-metrics-pipeline)
|
||||
that uses the _Custom Metrics API_.
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
@@ -65,8 +65,8 @@ Full metrics pipeline projects that are not part of the CNCF are outside the sco
|
||||
Learn about additional debugging tools, including:
|
||||
|
||||
* [Logging](/docs/concepts/cluster-administration/logging/)
|
||||
* [Monitoring](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)
|
||||
* [Getting into containers via `exec`](/docs/tasks/debug-application-cluster/applications/get-shell-running-container/)
|
||||
* [Monitoring](/docs/tasks/debug/debug-cluster/resource-usage-monitoring/)
|
||||
* [Getting into containers via `exec`](/docs/tasks/debug/debug-application/get-shell-running-container/)
|
||||
* [Connecting to containers via proxies](/docs/tasks/extend-kubernetes/http-proxy-access-api/)
|
||||
* [Connecting to containers via port forwarding](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)
|
||||
* [Inspect Kubernetes node with crictl](/docs/tasks/debug-application-cluster/monitoring/crictl/)
|
||||
* [Inspect Kubernetes node with crictl](/docs/tasks/debug/debug-cluster/crictl/)
|
||||
|
||||
@@ -114,5 +114,5 @@ args: ["-c", "while true; do echo hello; sleep 10;done"]
|
||||
|
||||
|
||||
* Learn more about [configuring pods and containers](/docs/tasks/).
|
||||
* Learn more about [running commands in a container](/docs/tasks/debug-application-cluster/get-shell-running-container/).
|
||||
* Learn more about [running commands in a container](/docs/tasks/debug/debug-application/get-shell-running-container/).
|
||||
* See [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core).
|
||||
|
||||
@@ -90,6 +90,6 @@ Always perform force deletion of StatefulSet Pods carefully and with complete kn
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
Learn more about [debugging a StatefulSet](/docs/tasks/debug-application-cluster/debug-stateful-set/).
|
||||
Learn more about [debugging a StatefulSet](/docs/tasks/debug/debug-application/debug-statefulset/).
|
||||
|
||||
|
||||
|
||||
@@ -90,7 +90,7 @@ The common use for HorizontalPodAutoscaler is to configure it to fetch metrics f
|
||||
(`metrics.k8s.io`, `custom.metrics.k8s.io`, or `external.metrics.k8s.io`). The `metrics.k8s.io` API is
|
||||
usually provided by an add-on named Metrics Server, which needs to be launched separately.
|
||||
For more information about resource metrics, see
|
||||
[Metrics Server](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#metrics-server).
|
||||
[Metrics Server](/docs/tasks/debug/debug-cluster/resource-metrics-pipeline/#metrics-server).
|
||||
|
||||
[Support for metrics APIs](#support-for-metrics-apis) explains the stability guarantees and support status for these
|
||||
different APIs.
|
||||
|
||||
@@ -532,7 +532,7 @@ kubectl delete pvc data-mysql-4
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* Learn more about [scaling a StatefulSet](/docs/tasks/run-application/scale-stateful-set/).
|
||||
* Learn more about [debugging a StatefulSet](/docs/tasks/debug-application-cluster/debug-stateful-set/).
|
||||
* Learn more about [debugging a StatefulSet](/docs/tasks/debug/debug-application/debug-statefulset/).
|
||||
* Learn more about [deleting a StatefulSet](/docs/tasks/run-application/delete-stateful-set/).
|
||||
* Learn more about [force deleting StatefulSet Pods](/docs/tasks/run-application/force-delete-stateful-set-pod/).
|
||||
* Look in the [Helm Charts repository](https://artifacthub.io/)
|
||||
|
||||
@@ -143,7 +143,7 @@ Configurations with a single API server will experience unavailability while the
|
||||
|
||||
1. Validate the logs from control plane components, along with the kubelet and the
|
||||
kube-proxy are not throwing any tls errors, see
|
||||
[looking at the logs](/docs/tasks/debug-application-cluster/debug-cluster/#looking-at-logs).
|
||||
[looking at the logs](/docs/tasks/debug/debug-cluster/#looking-at-logs).
|
||||
|
||||
1. Validate logs from any aggregated api servers and pods using in-cluster config.
|
||||
|
||||
|
||||
@@ -93,7 +93,7 @@ cassandra ClusterIP None <none> 9042/TCP 45s
|
||||
```
|
||||
|
||||
If you don't see a Service named `cassandra`, that means creation failed. Read
|
||||
[Debug Services](/docs/tasks/debug-application-cluster/debug-service/)
|
||||
[Debug Services](/docs/tasks/debug/debug-application/debug-service/)
|
||||
for help troubleshooting common issues.
|
||||
|
||||
## Using a StatefulSet to create a Cassandra ring
|
||||
|
||||
@@ -236,10 +236,10 @@ Do not leave your WordPress installation on this page. If another user finds it,
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* Learn more about [Introspection and Debugging](/docs/tasks/debug-application-cluster/debug-application-introspection/)
|
||||
* Learn more about [Introspection and Debugging](/docs/tasks/debug/debug-application)
|
||||
* Learn more about [Jobs](/docs/concepts/workloads/controllers/job/)
|
||||
* Learn more about [Port Forwarding](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)
|
||||
* Learn how to [Get a Shell to a Container](/docs/tasks/debug-application-cluster/get-shell-running-container/)
|
||||
* Learn how to [Get a Shell to a Container](/docs/tasks/debug/debug-application/get-shell-running-container/)
|
||||
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user