Add documentation for 1.109

docs/versioned_docs/version-1.109.x/architecture-configuration/_category_.json

@@ -0,0 +1,8 @@
+{
+  "label": "Architecture / Configuration",
+  "position": 2,
+  "link": {
+    "type": "generated-index",
+    "description": "Architecture description of the YAKE Gardener distribution"
+  }
+}

docs/versioned_docs/version-1.109.x/architecture-configuration/architecture.md

@@ -0,0 +1,46 @@
+---
+sidebar_position: 1
+---
+
+# Architecture
+
+## High Level Overview
+![YAKE High Level Overview](high-level-overview.excalidraw.png "YAKE High Level Overview")
+
+Let's start off with the very high level overview in the block diagram above. The most important aspect to note is that all deployments needed for the [Gardener](https://gardener.cloud/) installation are based on helm charts. Since the helm charts developed in the Gardener upstream are distributed over several repositories in the Gardener [Github organization](https://github.com/gardener/external-dns-management), we consolidated the relevant charts in another [repository](https://github.com/gardener-community/gardener-charts) hosted on Github. Consequently, YAKE fetches helm charts from several helm repositories and deploys the components for the Gardener installation into the base cluster.
+
+## Detailed Architecture
+
+A more detailed view of the YAKE architecture is depicted in the block diagram below.
+
+![YAKE architecture](yake-architecture.png "YAKE architecture")
+
+### Main entry points
+
+Conceptually, there are two entry points for Gardener operators to interact with the configuration:
+
+1. The `yake-config` secret in the base cluster
+2. The YAKE configuration git repository
+
+The reason for having a dedicated `yake-config` secret lies in the assumption that an operator does not want to store credentials such as dnsprovider credentials in a git repository. Of course, this could also be handled by solutions like [sops](https://github.com/mozilla/sops), but we wanted to let the operator decide where to store the `yake-config` secret in the end.
+
+### General Concepts
+
+As observed from the figure, the YAKE concept divides the installation process into tree separate stages: The `configuration`, `pre-gardener` stage and the `gardener` stage. The configuration stages transfer the content of the `yake-config` secret into separate secrets serving as values for the eventually deployed helm charts. Consequently, the default values given in the upstream values files for the helm charts are extended by the `*-base-values` secrets, so that all components come with a meaningful base configuration. This base configuration is assumed to be homogeneous across many Gardener environments. For the parts which are environment specific, another set of secrets stores another set of values for the helm charts. These secrets are pulled in from the YAKE configuration git repository and managed by a GitOps workflow.
+
+As we assume that the underlying base cluster does not come with any services installed, the `pre-gardener` stage ensures that the required services are deployed to the cluster. In more detail, the following services and resources are deployed:
+
+- [cert-manager](https://cert-manager.io/) for internal certificate handling
+- [cert-management](https://github.com/gardener/cert-management) for browser trusted certificate handling
+  - An `issuer` resource representing a certificate issuer in the base cluster
+- [external-dns-management](https://github.com/gardener/external-dns-management) for creation of DNS entries
+  - A `dnsprovider` resource representing a DNS provider such as azure-dns, aws-route53 etc. in the base cluster
+- [ingress-nginx](https://kubernetes.github.io/ingress-nginx/) as ingress controller
+
+In the `gardener` stage, the gardener specific components are deployed to the base cluster and to the [virtual garden](https://github.com/gardener/garden-setup#concept-the-virtual-cluster). The most important aspect to note here is that the [gardenlet](https://gardener.cloud/docs/gardener/concepts/gardenlet/) is deployed to the base cluster, i.e. the base cluster also serves as initial seed cluster for the resulting Gardener environment.
+
+
+
+### backups
+
+### webterminal

docs/versioned_docs/version-1.109.x/architecture-configuration/helm-flux.md

@@ -0,0 +1,78 @@
+---
+sidebar_position: 4
+---
+
+# Working with Helm and Flux
+
+On this page, you'll find some useful information on how to work with the commandline interfaces for [helm](https://helm.sh/) and [flux](https://fluxcd.io/) in the context of your YAKE-based Gardener installation.
+
+## Useful Helm Commands
+
+First things first. As already introduced in the [architecture description](./architecture.md), most of the YAKE helm charts stem from a helm repository hosted at `gardener.community.github.io/gardener-charts`. Consider adding this helm repository to your local repository cache by
+
+```sh
+helm repo add gardener-charts https://gardener-community.github.io/gardener-charts
+helm repo update
+```
+
+Afterwards you can use get further information about the charts using the helm cli.
+
+### Show upstream chart info
+
+E.g., for the `cloudprofiles` chart:
+
+```sh
+helm show chart gardener-charts/cloudprofiles
+```
+
+### Show upstream helm default values
+
+E.g., for the `cloudprofiles` chart:
+
+```sh
+helm show values gardener-charts/cloudprofiles
+```
+
+## Useful Flux Commands
+
+### Check flux versions
+
+The flux controllers running in the basecluster are maintained by YAKE itself, i.e. the flux controllers will be updated with YAKE updates. You can check the state of your cli version and the version of the cluster side components by
+
+```sh
+flux version
+```
+
+If you feel like your cli version is outdated. Go ahead and download a recent version from [the Github release page](https://github.com/fluxcd/flux2/releases). If you feel like your in-cluster components are outdated, think about updating YAKE.
+
+### Reconcile of a resource
+
+If you want to get fast feedback in your GitOps workflow you can trigger the reconciliation of resources manually using the `flux reconcile command`. If you want a `helmrelease` to be reconciled immediately, you can achieve this by the following command:
+
+```sh
+flux reconcile helmrelease <NAME_OF_HELMRELEASE>
+```
+
+### Suspend/Resume Reconciliation of a resource
+
+Maybe you want to get your hands dirty and do some manual (i.e. not GitOps driven) configuration changes. For instance, this could be useful in staging environments for rapid prototyping. In this case, you need to make sure that flux does not revert your "dirty" changes and suspend the reconciliation of the affected resources. Checkout the help for `flux suspend` to get further information
+
+```sh
+flux suspend -h
+```
+
+E.g., a helmrelease can be suspended by
+
+```sh
+flux suspend helmrelease <NAME_OF_HELMRELEASE>
+```
+
+Don't forget to resume the reconciliation, when you are done with your experiments so that flux will take over the control of your deployed resources again:
+
+```sh
+flux resume helmrelease <NAME_OF_HELMRELEASE>
+```
+
+:::note
+Sometimes you will need to `suspend` and `resume` resources in order to trigger an update of the deployed resources. If have the impression that the state in the cluster does not match your definitions in the git repository, try to `suspend` and `resume` the corresponding resources, wait for reconciliation, and see that the state matches the git repository again.
+:::

docs/versioned_docs/version-1.109.x/architecture-configuration/yake-config-gitrepo.md

@@ -0,0 +1,60 @@
+---
+sidebar_position: 3
+---
+
+# The YAKE config git repository
+As already introduced in the [architecture diagram](./architecture.md), values for the helm charts deployed for the Gardener installation are configured and maintained in a GitOps workflow. For instance, your repository tree looks like this:
+```
+.
+├── config
+│   ├── cloudprofiles-values.yaml
+│   ├── dashboard-values.yaml
+│   ├── extensions-values.yaml
+│   ├── gardener-values.yaml
+│   ├── gardenlet-values.yaml
+│   ├── identity-values.yaml
+│   └── kustomization.yaml
+├── flux
+│   ├── yake-env-config.yaml
+│   └── yake-env-garden-content.yaml
+├── garden-content
+│   ├── admin-clusterrolebinding.yaml
+│   ├── kustomization.yaml
+│   ├── project-dev.yaml
+│   └── rbac.yaml
+└── kustomization.yaml
+```
+The top-level `kustomization.yaml` file contains [`Kustomization`](https://kubectl.docs.kubernetes.io/references/kustomize/kustomization/) pointing to the files in the `flux` directory. Inside the `flux` directory two flux `Kustomizations` [`Kustomization`](https://fluxcd.io/flux/components/kustomize/api/)s reside which point to the `config` directory and the `garden-content` directory.
+
+:::caution
+The top-level `kustomization.yaml` is of type `kustomize.config.k8s.io/v1beta1`, whereas the `Kustomization`s in the `flux` directory are of type `kustomize.toolkit.fluxcd.io/v1beta2`. Therefore, you will only find the `Kustomization`s defined in the `flux` directory in your base cluster, when watching `Kustomization` resources.
+:::
+
+### The `config` Directory
+In the `config` directory, you find configuration files defining values for the deployed helm charts. All files entail the same "header", and are constructed like in the following example for `cloudprofiles-values.yaml`
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+  name: cloudprofiles-values
+  namespace: flux-system
+type: Opaque
+stringData:
+  values.yaml: |
+```
+Below of the key `stringData.values.yaml` you can insert your configuration.
+
+:::tip
+As the upstream helm charts are distributed over several repositories, there is no single documentation page for possible helm chart values. You can get information on the default values by e.g.
+```sh
+helm repo add gardener-charts https://gardener-community.github.io/gardener-charts
+helm repo update
+helm show values gardener-charts/<CHART_NAME>
+```
+:::
+
+### The `garden-content` Directory
+In the `garden-content` Directory, resources to be deployed to the [virtual garden](https://github.com/gardener/garden-setup#concept-the-virtual-cluster) are defined. You can easily add some resources, if you need more than if the example from above does not fit your needs. For instance, you can create [`Project`](https://gardener.cloud/docs/gardener/api-reference/core/#core.gardener.cloud/v1beta1.Project)s or further [`Cloudprofile`](https://gardener.cloud/docs/gardener/api-reference/core/#core.gardener.cloud/v1beta1.CloudProfile)s here.
+:::note
+The `garden-content` folder also contains a `kustomization.yaml` file which just lists the resources to be deployed to the [virtual garden](https://github.com/gardener/garden-setup#concept-the-virtual-cluster). You can just comment our resources you do not want to deploy for a moment but still keep in you git repository for documentation purposes.
+:::

docs/versioned_docs/version-1.109.x/architecture-configuration/yake-config-secret.md

@@ -0,0 +1,41 @@
+---
+sidebar_position: 2
+---
+
+# The YAKE config secret
+Via the `yake-config` secret, some basic parameters for the resulting Gardener installation are configured. In particular, values which should be kept secret such as dnsprovider credentials are set in `yake-config`.
+As the `yake-config` secret serves as input values for the `configuration` helm chart (see [architecture](./architecture.md)), the secret is defined as
+
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+  name: yake-config
+  namespace: flux-system
+type: Opaque
+stringData:
+  values.yaml: |
+  ...
+```
+
+and the configuration needs to be inserted below `stringData.values.yaml`. The configuration options are listed and explained below.
+
+| Field                          | Subfield                         | Subfield                                                                                                       | Description                                                                                                       |
+| :----------------------------- | :------------------------------- | :------------------------------------------------------------------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------- |
+| `clusterIdentity` <br />string |                                  |                                                                                                                | a unique identifier for your garden cluster                                                                       |
+| `dashboard`                    |                                  |                                                                                                                |                                                                                                                   |
+|                                | `clientSecret` <br />string      |                                                                                                                | client secret e.g. some value obtained by `openssl rand -hex 20`                                                  |
+|                                | `sessionSecret` <br />string     |                                                                                                                | session secret e.g. some value obtained by `openssl rand -hex 20`                                                 |
+| `kubeApiServer`                |                                  |                                                                                                                |                                                                                                                   |
+|                                | `basicAuthPassword` <br />string |                                                                                                                | basic auth password for kubeapiserver e.g. `openssl rand -hex 20`                                                 |
+| `issuer`                       |                                  |                                                                                                                |                                                                                                                   |
+|                                | `acme`                           |                                                                                                                |                                                                                                                   |
+|                                |                                  | `email` <br />string                                                                                           | Email address used for certificate handlin                                                                        |
+|                                |                                  | `server` <br />string                                                                                          | acme server, letsencryp production by default                                                                     |
+|                                | `ca`                             |                                                                                                                | ca of the acme server, not needed when using letsencrypt production                                               |
+| `domains`                      |                                  |                                                                                                                |                                                                                                                   |
+|                                | `global`                         |                                                                                                                | global means used for ingress, gardener defaultDomain and internalDomain                                          |
+|                                |                                  | `domain` <br />string                                                                                          | domain for your gardener installation, e.g. the dashboard will appear under dashboard.domain                      |
+|                                |                                  | `provider` <br />string                                                                                        | DNS provider for your installation, e.g. azure-dns, aws-route53, openstack-designate etc.                         |
+|                                |                                  | `credentials` <br />[dnscredentials](https://github.com/gardener/external-dns-management/tree/master/examples) | DNS provider credential, see [examples](https://github.com/gardener/external-dns-management/tree/master/examples) |
+| `registryOverwrite`            |                                  |                                                                                                                | See Guide [Use different container registry](../guides/registryOverwrite.md)                                       |

docs/versioned_docs/version-1.109.x/faq.md

@@ -0,0 +1,16 @@
+---
+sidebar_position: 5
+title: FAQ
+---
+
+### Which Gardener version do I get with YAKE?
+
+We keep the pace of the Gardener upstream and release new Gardener versions with YAKE as soon as possible. This enables YAKE users the keep their installation up-to-date, and get the experience of new features in a two week rhythm.
+
+### Can I migrate from my garden-setup-based installation to YAKE?
+
+Yes, this is possible. Most probably our support is required but we are happy to help in these kind of scenarios.
+
+### Will YAKE support the Gardener operator at some day?
+
+Most likely, yes. As of writing this, there are no clear plans to integrate the Gardener operator into YAKE, as this would introduce a complex migration path. However, we are always willing to improve YAKE and once the time is ready, the Gardener operator will be introduced to manage the garden in YAKE.

docs/versioned_docs/version-1.109.x/guides/_category_.json

@@ -0,0 +1,8 @@
+{
+  "label": "Guides",
+  "position": 4,
+  "link": {
+    "type": "generated-index",
+    "description": "Advanced topics and guides"
+  }
+}

docs/versioned_docs/version-1.109.x/guides/installation.md

@@ -0,0 +1,9 @@
+---
+sidebar_position: 10
+---
+
+# Installation
+
+The process of installing YAKE can differ slightly depending on your kubernetes environment. So this section will be expanded to include more providers over time.
+
+[AKS](https://github.com/YAKEcloud/yake-install-examples/tree/main/azure)