k3s-io · dereknola · Nov 21, 2023 · Nov 20, 2023 · Nov 20, 2023 · Nov 20, 2023
diff --git a/docs/cli/certificate.md b/docs/cli/certificate.md
@@ -106,7 +106,7 @@ graph TD
 
 #### Using the Example Script
 
-:::important
+:::info Important
 If you want to sign the cluster CA certificates with an existing root CA using the example script, you must place the root and intermediate files in the target directory prior to running the script.
 If the files do not exist, the script will create new root and intermediate CA certificates.
 :::
@@ -142,7 +142,7 @@ If the script generated root and/or intermediate CA files, you should back up th
 To rotate custom CA certificates, use the `k3s certificate rotate-ca` subcommand.
 Updated files must be staged into a temporary directory, loaded into the datastore, and k3s must be restarted on all nodes to use the updated certificates.
 
-:::caution
+:::warning
 You must not overwrite the currently in-use data in `/var/lib/rancher/k3s/server/tls`.  
 Stage the updated certificates and keys into a separate directory.
 :::
@@ -185,7 +185,7 @@ The token may be stored in a `.env` file, systemd unit, or config.yaml, dependin
 To rotate the K3s-generated self-signed CA certificates, use the `k3s certificate rotate-ca` subcommand.
 Updated files must be staged into a temporary directory, loaded into the datastore, and k3s must be restarted on all nodes to use the updated certificates.
 
-:::caution
+:::warning
 You must not overwrite the currently in-use data in `/var/lib/rancher/k3s/server/tls`.  
 Stage the updated certificates and keys into a separate directory.
 :::
@@ -294,7 +294,7 @@ The service-account issuer key is an RSA private key used to sign service-accoun
 When rotating the service-account issuer key, at least one old key should be retained in the file so that existing service-account tokens are not invalidated.
 It can be rotated independent of the cluster CAs by using the `k3s certificate rotate-ca` to install only an updated `service.key` file that includes both the new and old keys.
 
-:::caution
+:::warning
 You must not overwrite the currently in-use data in `/var/lib/rancher/k3s/server/tls`.  
 Stage the updated key into a separate directory.
 :::

diff --git a/docs/cli/secrets-encrypt.md b/docs/cli/secrets-encrypt.md
@@ -19,7 +19,7 @@ K3s contains a CLI tool `secrets-encrypt`, which enables automatic control over
 - Rotating and deleting encryption keys
 - Reencrypting secrets
 
-:::caution
+:::warning
 Failure to follow proper procedure for rotating encryption keys can leave your cluster permanently corrupted. Proceed with caution.
 :::
 

diff --git a/docs/cli/token.md b/docs/cli/token.md
@@ -55,7 +55,7 @@ The server token can be used to join both server and agent nodes to the cluster.
 
 The server token is also used as the [PBKDF2](https://en.wikipedia.org/wiki/PBKDF2) passphrase for the key used to encrypt confidential information that is persisted to the datastore, such as the secrets-encryption configuration, wireguard keys, and private keys for cluster CA certificates and service-account tokens. For this reason, the token must be backed up alongside the cluster datastore itself.
 
-:::caution
+:::warning
 Unless custom CA certificates are in use, only the short (password-only) token format can be used when starting the first server in the cluster. This is because the cluster CA hash cannot be known until after the server has generated the self-signed cluster CA certificates.
 :::
 

diff --git a/docs/datastore/backup-restore.md b/docs/datastore/backup-restore.md
@@ -5,7 +5,7 @@ weight: 26
 
 The way K3s is backed up and restored depends on which type of datastore is used.
 
-:::caution
+:::warning
 In addition to backing up the datastore itself, you must also back up the server token file at `/var/lib/rancher/k3s/server/token`.
 You must restore this file, or pass its value into the `--token` option, when restoring from backup.
 If you do not use the same token value when restoring, the snapshot will be unusable, as the token is used to encrypt confidential data within the datastore itself.

diff --git a/docs/datastore/cluster-loadbalancer.md b/docs/datastore/cluster-loadbalancer.md
@@ -130,7 +130,7 @@ server-3   Ready    control-plane,etcd,master   3m12s   v1.27.3+k3s1
 
 ## Nginx Load Balancer
 
-:::warning
+:::danger
 Nginx does not natively support a High Availability (HA) configuration. If setting up an HA cluster, having a single load balancer in front of K3s will reintroduce a single point of failure.
 :::
 

diff --git a/docs/datastore/datastore.md b/docs/datastore/datastore.md
@@ -26,7 +26,7 @@ K3s supports the following datastore options:
   * [MariaDB](https://mariadb.org/) (certified against version 10.6.8)
   * [PostgreSQL](https://www.postgresql.org/) (certified against versions 10.7, 11.5, and 14.2)
 
-:::caution Prepared Statement Support
+:::warning Prepared Statement Support
 K3s requires prepared statements support from the DB. This means that connection poolers such as [PgBouncer](https://www.pgbouncer.org/faq.html#how-to-use-prepared-statements-with-transaction-pooling) may require additional configuration to work with K3s.
 :::
 

diff --git a/docs/datastore/ha-embedded.md b/docs/datastore/ha-embedded.md
@@ -3,7 +3,7 @@ title: "High Availability Embedded etcd"
 weight: 40
 ---
 
-:::caution
+:::warning
 Embedded etcd (HA) may have performance issues on slower disks such as Raspberry Pis running with SD cards.
 :::
 

diff --git a/docs/installation/network-options.md b/docs/installation/network-options.md
@@ -138,7 +138,7 @@ Stable support is available as of [v1.23.7+k3s1](https://github.com/k3s-io/k3s/r
 
 :::
 
-:::caution Known Issue 
+:::warning Known Issue 
 
 Before 1.27, Kubernetes [Issue #111695](https://github.com/kubernetes/kubernetes/issues/111695) causes the Kubelet to ignore the node IPv6 addresses if you have a dual-stack environment and you are not using the primary network interface for cluster traffic. To avoid this bug, use 1.27 or newer or add the following flag to both K3s servers and agents:
 
@@ -162,7 +162,7 @@ Note that you may configure any valid `cluster-cidr` and `service-cidr` values,
 
 If you are using a custom CNI plugin, i.e. a CNI plugin other than Flannel, the additional configuration may be required. Please consult your plugin's dual-stack documentation and verify if network policies can be enabled.
 
-:::caution Known Issue
+:::warning Known Issue
 When defining cluster-cidr and service-cidr with IPv6 as the primary family, the node-ip of all cluster members should be explicitly set, placing node's desired IPv6 address as the first address. By default, the kubelet always uses IPv4 as the primary address family.
 :::
 
@@ -172,7 +172,7 @@ When defining cluster-cidr and service-cidr with IPv6 as the primary family, the
 Available as of [v1.22.9+k3s1](https://github.com/k3s-io/k3s/releases/tag/v1.22.9%2Bk3s1)
 :::
 
-:::caution Known Issue
+:::warning Known Issue
 If your IPv6 default route is set by a router advertisement (RA), you will need to set the sysctl `net.ipv6.conf.all.accept_ra=2`; otherwise, the node will drop the default route once it expires. Be aware that accepting RAs could increase the risk of [man-in-the-middle attacks](https://github.com/kubernetes/kubernetes/issues/91507).
 :::
 
@@ -186,11 +186,11 @@ Single-stack IPv6 clusters (clusters without IPv4) are supported on K3s using th
 
 A K3s cluster can still be deployed on nodes which do not share a common private network and are not directly connected (e.g. nodes in different public clouds). There are two options to achieve this: the embedded k3s multicloud solution and the integration with the `tailscale` VPN provider.
 
-:::caution Warning
+:::warning
 The latency between nodes will increase as external connectivity requires more hops. This will reduce the network performance and could also impact the health of the cluster if latency is too high.
 :::
 
-:::caution Warning
+:::warning
 Embedded etcd is not supported in this type of deployment. If using embedded etcd, all server nodes must be reachable to each other via their private IPs. Agents may be distributed over multiple networks, but all servers should be in the same location.
 :::
 
@@ -258,7 +258,7 @@ or provide that information in a file and use the parameter:
 
 Optionally, if you have your own Tailscale server (e.g. headscale), you can connect to it by appending `,controlServerURL=$URL` to the vpn-auth parameters
 
-:::caution Warning
+:::warning
 
 If you plan on running several K3s clusters using the same tailscale network, please create appropriate [ACLs](https://tailscale.com/kb/1018/acls/) to avoid IP conflicts or use different podCIDR subnets for each cluster.
 

diff --git a/docs/installation/packaged-components.md b/docs/installation/packaged-components.md
@@ -31,7 +31,7 @@ Here is en example of an error that would be reported if the file name contains
    a lowercase RFC 1123 subdomain must consist of lower case alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character
    (e.g. 'example.com', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?(\\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*')`
 
-:::warning
+:::danger
 If you have multiple server nodes, and place additional AddOn manifests on more than one server, it is your responsibility to ensure that files stay in sync across those nodes. K3s does not sync AddOn content between nodes, and cannot guarantee correct behavior if different servers attempt to deploy conflicting manifests.
 :::
 

diff --git a/docs/installation/requirements.md b/docs/installation/requirements.md
@@ -21,7 +21,7 @@ K3s is available for the following architectures:
 - arm64/aarch64
 - s390x
 
-:::caution ARM64 Page Size
+:::warning ARM64 Page Size
 
 Prior to May 2023 releases (v1.24.14+k3s1, v1.25.10+k3s1, v1.26.5+k3s1, v1.27.2+k3s1), on `aarch64/arm64` systems, the OS must use a 4k page size. **RHEL9**, **Ubuntu**, **Raspberry PI OS**, and **SLES** all meet this requirement.
 
@@ -127,7 +127,7 @@ If you plan on achieving high availability with embedded etcd, server nodes must
 The VXLAN port on nodes should not be exposed to the world as it opens up your cluster network to be accessed by anyone. Run your nodes behind a firewall/security group that disables access to port 8472.
 :::
 
-:::warning
+:::danger
 Flannel relies on the [Bridge CNI plugin](https://www.cni.dev/plugins/current/main/bridge/) to create a L2 network that switches traffic. Rogue pods with `NET_RAW` capabilities can abuse that L2 network to launch attacks such as [ARP spoofing](https://static.sched.com/hosted_files/kccncna19/72/ARP%20DNS%20spoof.pdf). Therefore, as documented in the [Kubernetes docs](https://kubernetes.io/docs/concepts/security/pod-security-standards/), please set a restricted profile that disables `NET_RAW` on non-trustable pods.
 :::
 

diff --git a/docs/installation/uninstall.md b/docs/installation/uninstall.md
@@ -3,7 +3,7 @@ title: Uninstalling K3s
 weight: 61
 ---
 
-:::caution
+:::warning
 Uninstalling K3s deletes the local cluster data, configuration, and all of the scripts and CLI tools.  
 It does not remove any data from external datastores, or created by pods using external Kubernetes storage volumes.
 :::

diff --git a/docs/release-notes/v1.24.X.md b/docs/release-notes/v1.24.X.md
@@ -4,7 +4,7 @@ hide_table_of_contents: true
 
 # v1.24.X
 
-:::caution Upgrade Notice
+:::warning Upgrade Notice
 Before upgrading from earlier releases, be sure to read the Kubernetes [Urgent Upgrade Notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.24.md#urgent-upgrade-notes).
 :::
 
@@ -35,7 +35,7 @@ Before upgrading from earlier releases, be sure to read the Kubernetes [Urgent U
 <!-- v1.24.17+k3s1 -->
 This release updates Kubernetes to v1.24.17, and fixes a number of issues.
 
-:::caution IMPORTANT
+:::warning IMPORTANT
 This release includes support for remediating CVE-2023-32187, a potential Denial of Service attack vector on K3s servers. See https://github.com/k3s-io/k3s/security/advisories/GHSA-m4hf-6vgr-75r2 for more information, including mandatory steps necessary to harden clusters against this vulnerability.
 :::
 

diff --git a/docs/release-notes/v1.25.X.md b/docs/release-notes/v1.25.X.md
@@ -4,7 +4,7 @@ hide_table_of_contents: true
 
 # v1.25.X
 
-:::caution Upgrade Notice
+:::warning Upgrade Notice
 Before upgrading from earlier releases, be sure to read the Kubernetes [Urgent Upgrade Notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.25.md#urgent-upgrade-notes).
 :::
 

diff --git a/docs/release-notes/v1.26.X.md b/docs/release-notes/v1.26.X.md
@@ -4,7 +4,7 @@ hide_table_of_contents: true
 
 # v1.26.X
 
-:::caution Upgrade Notice
+:::warning Upgrade Notice
 Before upgrading from earlier releases, be sure to read the Kubernetes [Urgent Upgrade Notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.26.md#urgent-upgrade-notes).
 :::
 

diff --git a/docs/release-notes/v1.27.X.md b/docs/release-notes/v1.27.X.md
@@ -4,7 +4,7 @@ hide_table_of_contents: true
 
 # v1.27.X
 
-:::caution Upgrade Notice
+:::warning Upgrade Notice
 Before upgrading from earlier releases, be sure to read the Kubernetes [Urgent Upgrade Notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.27.md#urgent-upgrade-notes).
 :::
 

diff --git a/docs/release-notes/v1.28.X.md b/docs/release-notes/v1.28.X.md
@@ -4,7 +4,7 @@ hide_table_of_contents: true
 
 # v1.28.X
 
-:::caution Upgrade Notice
+:::warning Upgrade Notice
 Before upgrading from earlier releases, be sure to read the Kubernetes [Urgent Upgrade Notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.28.md#urgent-upgrade-notes).
 :::
 
@@ -123,9 +123,13 @@ For more details on what's new, see the [Kubernetes release notes](https://githu
 <!-- v1.28.1+k3s1 -->
 This release is K3S's first in the v1.28 line. This release updates Kubernetes to v1.28.1.
 
-⚠️ IMPORTANT: This release includes remediation for CVE-2023-32187, a potential Denial of Service attack vector on K3s servers. See https://github.com/k3s-io/k3s/security/advisories/GHSA-m4hf-6vgr-75r2 for more information, including documentation on changes in behavior that harden clusters against this vulnerability.
+:::caution Important
+This release includes remediation for CVE-2023-32187, a potential Denial of Service attack vector on K3s servers. See https://github.com/k3s-io/k3s/security/advisories/GHSA-m4hf-6vgr-75r2 for more information, including documentation on changes in behavior that harden clusters against this vulnerability.
+:::
 
+:::danger Critical Regression
 Kubernetes v1.28 contains a critical regression ([kubernetes/kubernetes#120247](https://github.com/kubernetes/kubernetes/issues/120247)) that causes init containers to run at the same time as app containers following a restart of the node. This issue will be fixed in v1.28.2. We do not recommend using K3s v1.28 at this time if your application depends on init containers.
+:::
 
 For more details on what's new, see the [Kubernetes release notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.28.md#changelog-since-v1270).
 

diff --git a/docs/storage/storage.md b/docs/storage/storage.md
@@ -93,7 +93,7 @@ The status should be Bound for each.
 
 ## Setting up Longhorn
 
-:::caution
+:::warning
 
 Longhorn does not support ARM32.
 

diff --git a/i18n/kr/docusaurus-plugin-content-docs/current/cli/certificate.md b/i18n/kr/docusaurus-plugin-content-docs/current/cli/certificate.md
@@ -106,7 +106,7 @@ graph TD
 
 #### Using the Example Script
 
-:::important
+:::info 중요한
 If you want to sign the cluster CA certificates with an existing root CA using the example script, you must place the root and intermediate files in the target directory prior to running the script.
 If the files do not exist, the script will create new root and intermediate CA certificates.
 :::
@@ -142,7 +142,7 @@ If the script generated root and/or intermediate CA files, you should back up th
 To rotate custom CA certificates, use the `k3s certificate rotate-ca` subcommand.
 Updated files must be staged into a temporary directory, loaded into the datastore, and k3s must be restarted on all nodes to use the updated certificates.
 
-:::caution
+:::warning
 You must not overwrite the currently in-use data in `/var/lib/rancher/k3s/server/tls`.  
 Stage the updated certificates and keys into a separate directory.
 :::
@@ -185,7 +185,7 @@ The token may be stored in a `.env` file, systemd unit, or config.yaml, dependin
 To rotate the K3s-generated self-signed CA certificates, use the `k3s certificate rotate-ca` subcommand.
 Updated files must be staged into a temporary directory, loaded into the datastore, and k3s must be restarted on all nodes to use the updated certificates.
 
-:::caution
+:::warning
 You must not overwrite the currently in-use data in `/var/lib/rancher/k3s/server/tls`.  
 Stage the updated certificates and keys into a separate directory.
 :::
@@ -294,7 +294,7 @@ The service-account issuer key is an RSA private key used to sign service-accoun
 When rotating the service-account issuer key, at least one old key should be retained in the file so that existing service-account tokens are not invalidated.
 It can be rotated independent of the cluster CAs by using the `k3s certificate rotate-ca` to install only an updated `service.key` file that includes both the new and old keys.
 
-:::caution
+:::warning
 You must not overwrite the currently in-use data in `/var/lib/rancher/k3s/server/tls`.  
 Stage the updated key into a separate directory.
 :::

diff --git a/i18n/kr/docusaurus-plugin-content-docs/current/cli/secrets-encrypt.md b/i18n/kr/docusaurus-plugin-content-docs/current/cli/secrets-encrypt.md
@@ -19,7 +19,7 @@ K3s contains a CLI tool `secrets-encrypt`, which enables automatic control over
 - Rotating and deleting encryption keys
 - Reencrypting secrets
 
-:::caution
+:::warning
 Failure to follow proper procedure for rotating encryption keys can leave your cluster permanently corrupted. Proceed with caution.
 :::
 

diff --git a/i18n/kr/docusaurus-plugin-content-docs/current/cli/token.md b/i18n/kr/docusaurus-plugin-content-docs/current/cli/token.md
@@ -55,7 +55,7 @@ The server token can be used to join both server and agent nodes to the cluster.
 
 The server token is also used as the [PBKDF2](https://en.wikipedia.org/wiki/PBKDF2) passphrase for the key used to encrypt confidential information that is persisted to the datastore, such as the secrets-encryption configuration, wireguard keys, and private keys for cluster CA certificates and service-account tokens. For this reason, the token must be backed up alongside the cluster datastore itself.
 
-:::caution
+:::warning
 Unless custom CA certificates are in use, only the short (password-only) token format can be used when starting the first server in the cluster. This is because the cluster CA hash cannot be known until after the server has generated the self-signed cluster CA certificates.
 :::
 

diff --git a/i18n/kr/docusaurus-plugin-content-docs/current/datastore/backup-restore.md b/i18n/kr/docusaurus-plugin-content-docs/current/datastore/backup-restore.md
@@ -5,7 +5,7 @@ weight: 26
 
 The way K3s is backed up and restored depends on which type of datastore is used.
 
-:::caution
+:::warning
 In addition to backing up the datastore itself, you must also back up the server token file at `/var/lib/rancher/k3s/server/token`.
 You must restore this file, or pass its value into the `--token` option, when restoring from backup.
 If you do not use the same token value when restoring, the snapshot will be unusable, as the token is used to encrypt confidential data within the datastore itself.

diff --git a/i18n/kr/docusaurus-plugin-content-docs/current/datastore/ha-embedded.md b/i18n/kr/docusaurus-plugin-content-docs/current/datastore/ha-embedded.md
@@ -12,7 +12,7 @@ Experimental support as of [v1.19.1+k3s1](https://github.com/k3s-io/k3s/releases
 Embedded etcd replaced experimental Dqlite in the K3s v1.19.1 release. This is a breaking change. Please note that upgrades from experimental Dqlite to embedded etcd are not supported. If you attempt an upgrade it will not succeed and data will be lost.
 :::
 
-:::caution
+:::warning
 Embedded etcd (HA) may have performance issues on slower disks such as Raspberry Pis running with SD cards.
 :::
 

diff --git a/i18n/kr/docusaurus-plugin-content-docs/current/installation/network-options.md b/i18n/kr/docusaurus-plugin-content-docs/current/installation/network-options.md
@@ -122,7 +122,7 @@ Stable support is available as of [v1.23.7+k3s1](https://github.com/k3s-io/k3s/r
 
 :::
 
-:::caution Known Issue 
+:::warning Known Issue 
 
 Kubernetes v1.24 and v1.25 include [an issue](https://github.com/kubernetes/kubernetes/issues/111695) that ignores the node IPv6 addresses if you have a dual-stack environment and you are not using the primary network interface for cluster traffic. To avoid this bug, add the following flag to both K3s servers and agents:
 
@@ -152,7 +152,7 @@ If you are using a custom CNI plugin, i.e. a CNI plugin other than Flannel, the
 Available as of [v1.22.9+k3s1](https://github.com/k3s-io/k3s/releases/tag/v1.22.9%2Bk3s1)
 :::
 
-:::caution Known Issue
+:::warning Known Issue
 If your IPv6 default route is set by a router advertisement (RA), you will need to set the sysctl `net.ipv6.conf.all.accept_ra=2`; otherwise, the node will drop the default route once it expires. Be aware that accepting RAs could increase the risk of [man-in-the-middle attacks](https://github.com/kubernetes/kubernetes/issues/91507).
 :::
 
@@ -189,11 +189,11 @@ systemctl restart k3s
 ```
 :::
 
-:::caution Warning
+:::warning
 The latency between nodes will increase as external connectivity requires more hops. This will reduce the network performance and could also impact the health of the cluster if latency is too high.
 :::
 
-:::caution Warning
+:::warning
 Embedded etcd will not use external IPs for communication. If using embedded etcd; all server nodes must be reachable to each other via their private IPs.
 :::