Consildate several pages under Add-Ons section (#496)

* Consildate several pages under Add-Ons section

Signed-off-by: Derek Nola <derek.nola@suse.com>

Author: dereknola

docs/helm.md renamed to docs/add-ons/helm.md

@@ -4,9 +4,9 @@ title: Helm
 
 Helm is the package management tool of choice for Kubernetes. Helm charts provide templating syntax for Kubernetes YAML manifest documents. With Helm, developers or cluster administrators can create configurable templates known as Charts, instead of just using static manifests. For more information about creating your own Chart catalog, check out the docs at [https://helm.sh/docs/intro/quickstart/](https://helm.sh/docs/intro/quickstart/).
 
-K3s does not require any special configuration to support Helm. Just be sure you have properly set the kubeconfig path as per the [cluster access](./cluster-access.md) documentation. 
+K3s does not require any special configuration to support Helm. Just be sure you have properly set the kubeconfig path as per the [cluster access](../cluster-access.md) documentation. 
 
-K3s includes a [Helm Controller](https://github.com/k3s-io/helm-controller/) that manages installing, upgrading/reconfiguring, and uninstalling Helm charts using a HelmChart Custom Resource Definition (CRD). Paired with [auto-deploying AddOn manifests](./installation/packaged-components.md), installing a Helm chart on your cluster can be automated by creating a single file on disk.
+K3s includes a [Helm Controller](https://github.com/k3s-io/helm-controller/) that manages installing, upgrading/reconfiguring, and uninstalling Helm charts using a HelmChart Custom Resource Definition (CRD). Paired with [auto-deploying AddOn manifests](../installation/packaged-components.md), installing a Helm chart on your cluster can be automated by creating a single file on disk.
 
 ## Using the Helm Controller
 

docs/import-images.md renamed to docs/add-ons/import-images.md

@@ -6,7 +6,7 @@ Container images are cached locally on each node by the containerd image store.
 
 ## On-demand image pulling
 
-Kubernetes, by default, automatically pulls images when a Pod requires them if the image is not already present on the node. This behavior can be changed by using the [image pull policy](https://kubernetes.io/docs/concepts/containers/images/#image-pull-policy) field of the Pod. When using the default `IfNotPresent` policy, containerd will pull the image from either upstream (default) or your [private registry](installation/private-registry.md) and store it in its image store. Users do not need to apply any additional configuration for on-demand image pulling to work.
+Kubernetes, by default, automatically pulls images when a Pod requires them if the image is not already present on the node. This behavior can be changed by using the [image pull policy](https://kubernetes.io/docs/concepts/containers/images/#image-pull-policy) field of the Pod. When using the default `IfNotPresent` policy, containerd will pull the image from either upstream (default) or your [private registry](../installation/private-registry.md) and store it in its image store. Users do not need to apply any additional configuration for on-demand image pulling to work.
 
 
 ## Pre-import images
@@ -21,7 +21,7 @@ K3s includes two mechanisms to pre-import images into the containerd image store
 <Tabs groupId="import-images" queryString>
 <TabItem value="Online image importing" default>
 
-Users can trigger a pull of images into the containerd image store by placing a text file containing the image names, one per line, in the `/var/lib/rancher/k3s/agent/images` directory. The text file can be placed before K3s is started, or created/modified while K3s is running. K3s will sequentially pull the images via the CRI API, optionally using the [registries.yaml](installation/private-registry.md) configuration.
+Users can trigger a pull of images into the containerd image store by placing a text file containing the image names, one per line, in the `/var/lib/rancher/k3s/agent/images` directory. The text file can be placed before K3s is started, or created/modified while K3s is running. K3s will sequentially pull the images via the CRI API, optionally using the [registries.yaml](../installation/private-registry.md) configuration.
 
 For example:
 
@@ -57,7 +57,7 @@ After a few seconds, the images included in the image tarball will be available
 
 Use `sudo k3s ctr images list` to query the containerd image store.
 
-This is the method used in Airgap. Please follow the [Airgap install documentation](installation/airgap.md) for detailed information.
+This is the method used in Airgap. Please follow the [Airgap install documentation](../installation/airgap.md) for detailed information.
 
 </TabItem>
 </Tabs>
@@ -66,6 +66,6 @@ This is the method used in Airgap. Please follow the [Airgap install documentati
 
 K3s supports two alternatives for image registries:
 
-* [Private Registry Configuration](installation/private-registry.md) covers use of `registries.yaml` to configure container image registry authentication and mirroring.
+* [Private Registry Configuration](../installation/private-registry.md) covers use of `registries.yaml` to configure container image registry authentication and mirroring.
 
-* [Embedded Registry Mirror](installation/registry-mirror.md) shows how to enable the embedded distributed image registry mirror, for peer-to-peer sharing of images between nodes.
+* [Embedded Registry Mirror](../installation/registry-mirror.md) shows how to enable the embedded distributed image registry mirror, for peer-to-peer sharing of images between nodes.

docs/storage.md renamed to docs/add-ons/storage.md

@@ -65,7 +65,7 @@ If Traefik had already been deployed prior to creating the `traefik.skip` file,
 
 ## Helm AddOns
 
-For information about managing Helm charts via auto-deploying manifests, refer to the section about [Helm.](../helm.md)
+For information about managing Helm charts via auto-deploying manifests, refer to the section about [Helm.](../add-ons/helm.md)
 
 
 

docs/installation/packaged-components.md

@@ -16,7 +16,7 @@ This option enables the embedded mirror for use on all nodes in the cluster.
 When enabled at a cluster level, all nodes will host a local OCI registry on port 6443,
 and publish a list of available images via a peer to peer network on port 5001.
 Any image available in the containerd image store on any node, can be pulled by other cluster members without access to an external registry.
-Images imported via [air-gap image tar files](./airgap.md?airgap-load-images=Manually+Deploy+Images) or [pre-imported](../import-images.md#pre-import-images) are pinned in containerd to ensure that they remain available and are not pruned by Kubelet garbage collection.
+Images imported via [air-gap image tar files](./airgap.md?airgap-load-images=Manually+Deploy+Images) or [pre-imported](../add-ons/import-images.md#pre-import-images) are pinned in containerd to ensure that they remain available and are not pruned by Kubelet garbage collection.
 
 The peer to peer port can changed from 5001 by setting the `K3S_P2P_PORT` environment variable for the K3s service. The port must be set to the same value on all nodes.
 Changing the port is unsupported and not recommended.
@@ -129,7 +129,7 @@ If image integrity is important, you should use image digests instead of tags, a
 ## Sharing Air-gap or Manually Loaded Images
 
 Image sharing is controlled based on the source registry.
-Images loaded directly into containerd via [air-gap tarballs](./airgap.md?airgap-load-images=Manually+Deploy+Images), [pre-imported](../import-images.md#pre-import-images) or loaded directly into containerd's image store using the `ctr` command line tool, will be shared between nodes if they are tagged as being from a registry that is enabled for mirroring.
+Images loaded directly into containerd via [air-gap tarballs](./airgap.md?airgap-load-images=Manually+Deploy+Images), [pre-imported](../add-ons/import-images.md#pre-import-images) or loaded directly into containerd's image store using the `ctr` command line tool, will be shared between nodes if they are tagged as being from a registry that is enabled for mirroring.
 
 Note that the upstream registry that the images appear to come from does not actually have to exist or be reachable.
 For example, you could tag images as being from a fictitious upstream registry, and import those images into containerd's image store.
@@ -140,5 +140,5 @@ You would then be able to pull those images from all cluster members, as long as
 The embedded registry is read-only, and cannot be pushed to directly using `docker push` or other common tools that interact with OCI registries.
 
 Images can be manually made available via the embedded registry by running `ctr -n k8s.io image pull` to pull an image,
-or by loading image archives created by `docker save` via the `ctr -n k8s.io image import` command or the [pre-import feature](../import-images.md#pre-import-images).
+or by loading image archives created by `docker save` via the `ctr -n k8s.io image import` command or the [pre-import feature](../add-ons/import-images.md#pre-import-images).
 Note that the `k8s.io` namespace must be specified when managing images via `ctr` in order for them to be visible to the kubelet.

docs/installation/registry-mirror.md

@@ -8,7 +8,7 @@ Uninstalling K3s may cause data loss!
 
 If you installed K3s using the installation script, a script to uninstall K3s was generated during installation.
 
-Running the uninstall script stops K3s and all running pods, and deletes the local cluster datastore, [Local Storage](../storage.md#setting-up-the-local-storage-provider) Persistent Volume data, node configuration, and all of the scripts and CLI tools.
+Running the uninstall script stops K3s and all running pods, and deletes the local cluster datastore, [Local Storage](../add-ons/storage.md#setting-up-the-local-storage-provider) Persistent Volume data, node 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 Persistent Volumes.
 
 If you are planning on rejoining a node to an existing cluster after uninstalling and reinstalling, be sure to delete the node from the cluster to ensure that the node password secret is removed. See the [Node Registration](../architecture.md#how-agent-node-registration-works) documentation for more information.

docs/installation/uninstall.md

@@ -26,7 +26,7 @@ To restrict the nodes used by Traefik, and by extension the node IPs advertised
 
 Traefik is deployed by default when starting the server. The default chart values can be found in `/var/lib/rancher/k3s/server/manifests/traefik.yaml`, but this file should not be edited manually, as K3s will replace the file with defaults at startup. 
 Instead, you should customize Traefik by creating an additional `HelmChartConfig` manifest in `/var/lib/rancher/k3s/server/manifests`.
-For more details and an example see [Customizing Packaged Components with HelmChartConfig](../helm.md#customizing-packaged-components-with-helmchartconfig).
+For more details and an example see [Customizing Packaged Components with HelmChartConfig](../add-ons/helm.md#customizing-packaged-components-with-helmchartconfig).
 For more information on the possible configuration values, refer to `values.yaml` of the [Traefik Helm Chart](https://github.com/k3s-io/k3s-charts/tree/main/charts/traefik) included with your version of K3s.
 
 To remove Traefik from your cluster, start all servers with the `--disable=traefik` flag.

docs/networking/networking-services.md

@@ -140,6 +140,9 @@ module.exports = {
           { from: '/reference/server-config', to: '/cli/server' },
 	        { from: '/installation/network-options', to: '/networking/basic-network-options' },
 	        { from: '/security/self-assessment', to: '/security/self-assessment-1.23' },
+	        { from: '/helm', to: '/add-ons/helm' },
+	        { from: '/import-images', to: '/add-ons/import-images' },
+	        { from: '/storage', to: '/add-ons/storage' },
         ],
       },
     ],

docusaurus.config.js

@@ -4,9 +4,9 @@ title: Helm
 
 HelmはKubernetesのためのパッケージ管理ツールです。HelmチャートはKubernetes YAMLマニフェストドキュメントのためのテンプレート構文を提供します。Helmを使用すると、開発者やクラスター管理者は静的なマニフェストを使用する代わりに、チャートとして知られる設定可能なテンプレートを作成できます。独自のチャートカタログを作成する方法については、[https://helm.sh/docs/intro/quickstart/](https://helm.sh/docs/intro/quickstart/)のドキュメントを参照してください。
 
-K3sはHelmをサポートするために特別な設定を必要としません。[クラスターアクセス](./cluster-access.md)のドキュメントに従って、kubeconfigパスを正しく設定していることを確認してください。
+K3sはHelmをサポートするために特別な設定を必要としません。[クラスターアクセス](../cluster-access.md)のドキュメントに従って、kubeconfigパスを正しく設定していることを確認してください。
 
-K3sには、HelmChartカスタムリソース定義（CRD）を使用してHelmチャートのインストール、アップグレード/再構成、およびアンインストールを管理する[Helmコントローラー](https://github.com/k3s-io/helm-controller/)が含まれています。[自動デプロイAddOnマニフェスト](./installation/packaged-components.md)と組み合わせることで、ディスク上に1つのファイルを作成するだけでクラスターにHelmチャートを自動的にインストールできます。
+K3sには、HelmChartカスタムリソース定義（CRD）を使用してHelmチャートのインストール、アップグレード/再構成、およびアンインストールを管理する[Helmコントローラー](https://github.com/k3s-io/helm-controller/)が含まれています。[自動デプロイAddOnマニフェスト](../installation/packaged-components.md)と組み合わせることで、ディスク上に1つのファイルを作成するだけでクラスターにHelmチャートを自動的にインストールできます。
 
 ### Helmコントローラーの使用
 
@@ -142,7 +142,7 @@ spec:
 
 ### Helm v2からの移行
 
-K3sはHelm v2またはHelm v3のいずれかを処理できます。Helm v3に移行したい場合は、Helmの[この](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/)ブログ投稿でプラグインを使用して成功裏に移行する方法を説明しています。詳細については、公式のHelm 3ドキュメント[こちら](https://helm.sh/docs/)を参照してください。[クラスターアクセス](./cluster-access.md)のセクションに従ってkubeconfigを正しく設定していることを確認してください。
+K3sはHelm v2またはHelm v3のいずれかを処理できます。Helm v3に移行したい場合は、Helmの[この](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/)ブログ投稿でプラグインを使用して成功裏に移行する方法を説明しています。詳細については、公式のHelm 3ドキュメント[こちら](https://helm.sh/docs/)を参照してください。[クラスターアクセス](../cluster-access.md)のセクションに従ってkubeconfigを正しく設定していることを確認してください。
 
 :::note
 Helm 3はもはやTillerと`helm init`コマンドを必要としません。詳細については公式ドキュメントを参照してください。

i18n/ja/docusaurus-plugin-content-docs/current/helm.md renamed to i18n/ja/docusaurus-plugin-content-docs/current/add-ons/helm.md

@@ -0,0 +1 @@
+このページはまだ翻訳されていません