Kubermatic

https://docs.kubermatic.com/kubermatic/
Admin
Kubermatic offers a comprehensive platform and services for automating and managing Kubernetes...
Tokens:753,259
Snippets:5,286
Trust Score:9.6
Update:9 months ago
Show doc for...
Tokens:
Raw
### Example Kubermatic Installer Output

Source: https://docs.kubermatic.com/kubermatic/v2.20/installation/install_kkp_ce_on_azure

An example of the output from the Kubermatic installer, showing initialization, validation, and potential error messages related to configuration, such as missing secrets.

```text
INFO[15:15:20] 🛫 Initializing installer…                     edition="Community Edition" version=v2.20.3
INFO[15:15:20] 🚦 Validating the provided configuration…
ERROR[15:15:20]    The provided configuration files are invalid:
ERROR[15:15:20]    KubermaticConfiguration: spec.auth.serviceAccountKey must be a non-empty secret, for example: ZPCs7_KzgJxUSA5lCk_oNzL7RQFTQ6cOnHuTLAh4pGw
ERROR[15:15:20]    Operation failed: please review your configuration and try again.

```

--------------------------------

### Kubermatic Installer Output Example

Source: https://docs.kubermatic.com/kubermatic/v2.29/installation/install-kkp-ce

An example output from the Kubermatic installer, demonstrating an error message when critical configuration values like `spec.auth.serviceAccountKey` are missing or invalid. It shows the expected format for a valid secret key.

```log
INFO[15:15:20] 🛫 Initializing installer…                     edition="Community Edition" version=v2.21.2
INFO[15:15:20] 🚦 Validating the provided configuration…
ERROR[15:15:20]    The provided configuration files are invalid:
ERROR[15:15:20]    KubermaticConfiguration: spec.auth.serviceAccountKey must be a non-empty secret, for example: ZPCs7_KzgJxUSA5lCk_oNzL7RQFTQ6cOnHuTLAh4pGw
ERROR[15:15:20]    Operation failed: please review your configuration and try again.
```

--------------------------------

### Kubermatic Installer DNS Configuration Output Example

Source: https://docs.kubermatic.com/kubermatic/v2.20/installation/install_kkp_ce_on_vsphere

Example output from the Kubermatic installer indicating the required DNS records for accessing the cluster. It shows the LoadBalancer service hostname and the corresponding A records needed for both the main domain and wildcard subdomains.

```text
INFO[13:03:33]    📝 Applying Kubermatic Configuration…
INFO[13:03:33]    ✅ Success.
INFO[13:03:33]    📡 Determining DNS settings…
INFO[13:03:33]       The main LoadBalancer is ready.
INFO[13:03:33]
INFO[13:03:33]         Service             : nginx-ingress-controller / nginx-ingress-controller
INFO[13:03:33]         Ingress via hostname: 1.2.3.4
INFO[13:03:33]
INFO[13:03:33]       Please ensure your DNS settings for "kubermatic.example.com" include the following records:
INFO[13:03:33]
INFO[13:03:33]          kubermatic.example.com.    IN  A  1.2.3.4.
INFO[13:03:33]          *.kubermatic.example.com.  IN  A  1.2.3.4.
INFO[13:03:33]
INFO[13:03:33] 🛬 Installation completed successfully. ✌
```

--------------------------------

### Installer Output Example with Configuration Errors

Source: https://docs.kubermatic.com/kubermatic/v2.21/installation/install-kkp-ce

An example of the output from the Kubermatic installer, highlighting common configuration errors. This output shows validation failures, specifically for missing or invalid secrets in the KubermaticConfiguration.

```text
INFO[15:15:20] 🛫 Initializing installer…                     edition="Community Edition" version=v2.15.11
INFO[15:15:20] 🚦 Validating the provided configuration…
ERROR[15:15:20]    The provided configuration files are invalid:
ERROR[15:15:20]    KubermaticConfiguration: spec.auth.serviceAccountKey must be a non-empty secret, for example: ZPCs7_KzgJxUSA5lCk_oNzL7RQFTQ6cOnHuTLAh4pGw
ERROR[15:15:20]    Operation failed: please review your configuration and try again.
```

--------------------------------

### Example KKP Installer Output with Errors

Source: https://docs.kubermatic.com/kubermatic/v2.20/installation/install_kkp_ce_on_gcp

Illustrates a typical output from the Kubermatic installer when configuration errors are detected. This example highlights a common error related to missing or invalid `spec.auth.serviceAccountKey` in the KubermaticConfiguration.

```bash
INFO[15:15:20] 🛫 Initializing installer…                     edition="Community Edition" version=v2.20.3
INFO[15:15:20] 🚦 Validating the provided configuration…
ERROR[15:15:20]    The provided configuration files are invalid:
ERROR[15:15:20]    KubermaticConfiguration: spec.auth.serviceAccountKey must be a non-empty secret, for example: ZPCs7_KzgJxUSA5lCk_oNzL7RQFTQ6cOnHuTLAh4pGw
ERROR[15:15:20]    Operation failed: please review your configuration and try again.
```

--------------------------------

### Full ApplicationInstallation Reference Example

Source: https://docs.kubermatic.com/kubermatic/v2.29/architecture/concept/kkp-concepts/applications/application-installation

This is a comprehensive example of an ApplicationInstallation resource, showcasing all possible configuration options. It includes details for application referencing, namespace configuration (annotations, creation, labels), and Helm values overrides. This serves as a template for deploying applications with specific configurations.

```yaml
apiVersion: apps.kubermatic.k8c.io/v1
kind: ApplicationInstallations
metadata:
  name: <<appInstallation-name>>
spec:
  # ApplicationRef is a reference to identify which Application should be deployed
  applicationRef:
    # Name of the Application.
    # Should be a valid lowercase RFC1123 domain name
    name: apache
    # Version of the Application. Must be a valid SemVer version
    version: 1.2.3
  # Namespace describe the desired state of the namespace where application will be created.
  namespace:
    # Annotations of the namespace
    # More info: http://kubernetes.io/docs/user-guide/annotations
    annotations:
      project-code: azerty
    # Create defines whether the namespace should be created if it does not exist. Defaults to true
    create: true
    # Labels of the namespace
    # More info: http://kubernetes.io/docs/user-guide/labels
    labels:
      env: dev
    # Name is the namespace to deploy the Application into.
    # Should be a valid lowercase RFC1123 domain name
    name: my-namespace
  # ValuesBlock specifies values overrides that are passed to helm templating. Comments are preserved.
  valuesBlock: |-
    commonLabels:
      owner: somebody
```

--------------------------------

### Example Kubermatic Installer Deployment Output

Source: https://docs.kubermatic.com/kubermatic/v2.29/tutorials-howtos/monitoring-logging-alerting/master-seed/installation

This is an example output from the Kubermatic Installer during the deployment of the Seed MLA stack. It shows the progress of deploying various components like Node Exporter, Kube State Metrics, Grafana, Prometheus, Loki, and Promtail, indicating successful installation.

```text
INFO[0000] 🚀 Initializing installer…                     edition="Community Edition" version=X.Y
INFO[0000] 🚦 Validating the provided configuration…
INFO[0000] ✅ Provided configuration is valid.
INFO[0000] 🚦 Validating existing installation…
INFO[0000] ✅ Existing installation is valid.
INFO[0000] 🛫 Deploying KKP Seed MLA Stack…
INFO[0000]    📦 Deploying Node Exporter ...
INFO[0006]    ✅ Success.
INFO[0006]    📦 Deploying Kube State Metrics…
INFO[0022]    ✅ Success.
INFO[0022]    📦 Deploying Grafana…
INFO[0055]    ✅ Success.
INFO[0055]    📦 Deploying Blackbox Exporter…
INFO[0064]    ✅ Success.
INFO[0064]    📦 Deploying Alert Manager…
INFO[0074]    ✅ Success.
INFO[0074]    📦 Deploying Prometheus…
INFO[0075]    ✅ Success.
INFO[0075]    📦 Deploying Helm Exporter…
INFO[0076]    ✅ Success.
INFO[0076]    📦 Deploying Karma…
INFO[0078]    ✅ Success.
INFO[0078]    📦 Deploying Loki…
INFO[0164]    ✅ Success.
INFO[0164]    📦 Deploying Promtail…
INFO[0166]    ✅ Success.
INFO[0166] 🛬 Installation completed successfully. Time for a break, maybe? ☺

```

--------------------------------

### Example DNS Records for Kubermatic

Source: https://docs.kubermatic.com/kubermatic/v2.21/installation/install-kkp-ce-on-azure

Illustrates the expected output from the Kubermatic installer regarding DNS record configuration. It shows the IP address of the LoadBalancer and the required A records for the main domain and wildcard subdomains.

```text
INFO[13:03:33]    📝 Applying Kubermatic Configuration…
INFO[13:03:33]    ✅ Success.
INFO[13:03:33]    📡 Determining DNS settings…
INFO[13:03:33]       The main LoadBalancer is ready.
INFO[13:03:33]
INFO[13:03:33]         Service             : nginx-ingress-controller / nginx-ingress-controller
INFO[13:03:33]         Ingress via hostname: 1.2.3.4
INFO[13:03:33]
INFO[13:03:33]       Please ensure your DNS settings for "kubermatic.example.com" include the following records:
INFO[13:03:33]
INFO[13:03:33]          kubermatic.example.com.    IN  A  1.2.3.4
INFO[13:03:33]          *.kubermatic.example.com.  IN  A  1.2.3.4
INFO[13:03:33]
INFO[13:03:33] 🛬 Installation completed successfully. ✌
```

--------------------------------

### Templating User Cluster Annotations and Labels for Application Installations

Source: https://docs.kubermatic.com/kubermatic/v2.29/release-notes

Introduces the use of annotations and labels on user clusters to enable templating during application installations. This allows for dynamic configuration using expressions, facilitating multi-environment setups.

```go
{{- if eq (index .Cluster.Annotations "env") "dev" -}}
  custom1
{{- else -}}
  custom2
{{- end -}}
```

--------------------------------

### Determine DNS Settings from Installer Output

Source: https://docs.kubermatic.com/kubermatic/v2.20/installation/install_kkp_ce_on_azure

Example output from the Kubermatic installer indicating the required DNS records for cluster access. It shows the service name, ingress hostname, and the specific A records needed for both the main domain and wildcard subdomains.

```text
INFO[13:03:33]    📝 Applying Kubermatic Configuration…
INFO[13:03:33]    ✅ Success.
INFO[13:03:33]    📡 Determining DNS settings…
INFO[13:03:33]       The main LoadBalancer is ready.
INFO[13:03:33]
INFO[13:03:33]         Service             : nginx-ingress-controller / nginx-ingress-controller
INFO[13:03:33]         Ingress via hostname: 1.2.3.4
INFO[13:03:33]
INFO[13:03:33]       Please ensure your DNS settings for "kubermatic.example.com" include the following records:
INFO[13:03:33]
INFO[13:03:33]          kubermatic.example.com.    IN  A  1.2.3.4
INFO[13:03:33]          *.kubermatic.example.com.  IN  A  1.2.3.4
INFO[13:03:33]
INFO[13:03:33] 🛬 Installation completed successfully. ✌

```

--------------------------------

### Clone KKP Single Node Repository

Source: https://docs.kubermatic.com/kubermatic/v2.20/installation/install_kkp_on_node

This snippet shows how to clone the 'kubermatic/kkp-single-node' repository, which contains the necessary configurations for a single-node KKP installation with Kubeone. This is the first step to get started with the deployment.

```shell
git clone https://github.com/kubermatic/kkp-single-node.git
cd kkp-single-node
```

--------------------------------

### Example nginx-ingress-controller Service Output

Source: https://docs.kubermatic.com/kubermatic/v2.20/installation/install_kkp_ce

Example output from 'kubectl get services' for the nginx-ingress-controller. It shows the service type, cluster IP, and importantly, the EXTERNAL-IP, which is either an IP address or a hostname used for DNS configuration.

```text
#NAME                       TYPE           CLUSTER-IP      EXTERNAL-IP    PORT(S)                      AGE
#nginx-ingress-controller   LoadBalancer   10.47.248.232   1.2.3.4        80:32014/TCP,443:30772/TCP   449d
```

--------------------------------

### Get Azure Tenant ID using Azure CLI

Source: https://docs.kubermatic.com/kubermatic/v2.17/architecture/requirements/support_policy/provider_support_matrix/azure/azure

Retrieves the Azure tenant ID using the Azure CLI. This ID is required for configuring cloud provider credentials.

```bash
az account show --query tenantId -o json

```

--------------------------------

### Run Kubermatic Installer

Source: https://docs.kubermatic.com/kubermatic/v2.29/installation/install-kkp-ce

This command initiates the Kubermatic installer, which validates configuration files and deploys the necessary components. It accepts arguments for specifying the StorageClass, the main configuration file (`kubermatic.yaml`), and Helm values (`values.yaml`). An optional `--helm-binary` flag can be used to specify a custom Helm executable path.

```bash
./kubermatic-installer deploy \
  # uncomment the line below after updating it to your respective provider; remove flag if provider is not supported (see above)
  # --storageclass aws \
  --config kubermatic.yaml \
  --helm-values values.yaml

```

--------------------------------

### Get Azure Subscription ID using Azure CLI

Source: https://docs.kubermatic.com/kubermatic/v2.17/architecture/requirements/support_policy/provider_support_matrix/azure/azure

Retrieves the current Azure subscription ID using the Azure CLI. This ID is crucial for defining resource scopes.

```bash
az account show --query id -o json

```

--------------------------------

### Deploy Seed Cluster MLA Stack Components

Source: https://docs.kubermatic.com/kubermatic/v2.20/tutorials_howtos/monitoring_logging_alerting/user_cluster/admin_guide

Deploys all MLA stack components using a helper script. This script installs components with default settings, suitable for smaller setups. Customizations can be made by manually reproducing the script's steps with modified Helm values.

```bash
./hack/deploy-seed.sh

```

--------------------------------

### Full ApplicationInstallation Reference Example (Kubernetes YAML)

Source: https://docs.kubermatic.com/kubermatic/v2.21/tutorials-howtos/applications/add-applications-to-cluster

An extensive example of the ApplicationInstallation resource, demonstrating all possible configuration options including application reference, namespace settings, and value overrides.

```yaml
apiVersion: apps.kubermatic.k8c.io/v1
kind: ApplicationInstallations
metadata:
  name: <<appInstallation-name>>
spec:
  # ApplicationRef is a reference to identify which Application should be deployed
  applicationRef:
    # Name of the Application.
    # Should be a valid lowercase RFC1123 domain name
    name: apache
    # Version of the Application. Must be a valid SemVer version
    version: 1.2.3
  # Namespace describe the desired state of the namespace where application will be created.
  namespace:
    annotations:
      project-code: azerty
    create: true
    labels:
      env: dev
    name: my-namespace
  # Values describe overrides for manifest-rendering. It's a free yaml field.
  values:
    commonLabels:
      owner: somebody

```

--------------------------------

### ApplicationDefinition Example with Git Source

Source: https://docs.kubermatic.com/kubermatic/v2.21/tutorials-howtos/applications/create-application-catalogue

This example demonstrates the structure of an ApplicationDefinition resource in Kubermatic, specifically configured to install applications using Helm charts fetched from a Git repository. It includes detailed options for specifying Git credentials (password, token, SSH key, username) and their corresponding secret references.

```yaml
apiVersion: apps.kubermatic.k8c.io/v1
kind: ApplicationDefinitions
metadata:
  name: <<appdef-name>>
spec:
  # Description of the application. what is its purpose
  description: ""
  # Method used to install the application
  method: helm
  # Available version for this application
  versions:
    - # Template defines how application is installed (source provenance, Method...)
      template:
        # Defined how the source of the application (e.g Helm chart) is retrieved.
        # Exactly one type of source must be defined.
        source:
          # Install application from a Git repository
          git:
            # Credentials are optional and holds the git credentials
            credentials:
              # Authentication method. Either password or token or ssh-key.
              # If method is password then username and password must be defined.
              # If method is token then token must be defined.
              # If method is ssh-key then ssh-key must be defined.
              method: password || token || ssh-key
              # Password holds the ref and key in the secret for the Password credential.
              # The Secret must exist in the namespace where KKP is installed (default is "kubermatic").
              # The Secret must be annotated with `apps.kubermatic.k8c.io/secret-type:` set to "helm" or "git".
              password:
                # The key of the secret to select from. Must be a valid secret key.
                key: pass
                # Name of the referent.
                # This field is effectively required, but due to backwards compatibility is
                # allowed to be empty. Instances of this type with an empty value here are
                # almost certainly wrong.
                # More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
                name: <<secret-name>>
                # Specify whether the Secret or its key must be defined
                optional: false
              # SSHKey holds the ref and key in the secret for the SshKey credential.
              # The Secret must exist in the namespace where KKP is installed (default is "kubermatic").
              # The Secret must be annotated with `apps.kubermatic.k8c.io/secret-type:` set to "helm" or "git".
              sshKey:
                # The key of the secret to select from. Must be a valid secret key.
                key: private-key
                # Name of the referent.
                # This field is effectively required, but due to backwards compatibility is
                # allowed to be empty. Instances of this type with an empty value here are
                # almost certainly wrong.
                # More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
                name: <<secret-name>>
                # Specify whether the Secret or its key must be defined
                optional: false
              # Token holds the ref and key in the secret for the token credential.
              # The Secret must exist in the namespace where KKP is installed (default is "kubermatic").
              # The Secret must be annotated with `apps.kubermatic.k8c.io/secret-type:` set to "helm" or "git".
              token:
                # The key of the secret to select from. Must be a valid secret key.
                key: token
                # Name of the referent.
                # This field is effectively required, but due to backwards compatibility is
                # allowed to be empty. Instances of this type with an empty value here are
                # almost certainly wrong.
                # More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
                name: <<secret-name>>
                # Specify whether the Secret or its key must be defined
                optional: false
              # Username holds the ref and key in the secret for the username credential.
              # The Secret must exist in the namespace where KKP is installed (default is "kubermatic").
              # The Secret must be annotated with `apps.kubermatic.k8c.io/secret-type:` set to "helm" or "git".
              username:
                # The key of the secret to select from. Must be a valid secret key.
                key: user
                # Name of the referent.
                # This field is effectively required, but due to backwards compatibility is
                # allowed to be empty. Instances of this type with an empty value here are
                # almost certainly wrong.
                # More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
                name: <<secret-name>>
                # Specify whether the Secret or its key must be defined
                optional: false

```

--------------------------------

### Verify KKP Master Setup with kubectl

Source: https://docs.kubermatic.com/kubermatic/v2.20/installation/install_kkp_on_node

These `kubectl` commands are used to validate the KKP Master setup by checking the status of deployments and pods within the 'kubermatic' namespace, as well as monitoring certificate statuses across all namespaces. This helps ensure that KKP components are running correctly.

```shell
kubectl -n kubermatic get deployments,pods
```

```shell
kubectl get certificates -A -w
```

--------------------------------

### Configure AWS Credentials and SSH Keys for KKP Setup

Source: https://docs.kubermatic.com/kubermatic/v2.20/installation/install_kkp_on_node

This code block configures essential environment variables for the KKP single-node setup on AWS. It includes setting AWS access keys and paths to SSH private and public keys, which are crucial for infrastructure provisioning and node access.

```shell
export AWS_ACCESS_KEY_ID=xxxxxxxxxxxxxxx
export AWS_SECRET_ACCESS_KEY=xxxxxxxxxxxxxxxxxxxx
# Path to your private SSH key. This is only used to configure SSH agent on your local machine.
export K1_SSH_PRIVATE_KEY_PATH=~/.ssh/id_rsa
# Path to your public SSH key, copied over to the nodes for SSH access
export K1_SSH_PUBLIC_KEY_PATH=~/.ssh/id_rsa.pub
```

--------------------------------

### Kubermatic Seed Configuration Example (YAML)

Source: https://docs.kubermatic.com/kubermatic/v2.20/tutorials_howtos/project_and_cluster_management/seed_cluster

This YAML snippet illustrates a complete example of a Kubermatic Seed resource. It includes configurations for datacenter settings, node-specific options like HTTP proxy and insecure registries, and detailed specifications for multiple cloud providers (Alibaba, AWS, Azure, GCP, Hetzner, DigitalOcean, Anexia, BringYourOwn).

```yaml
apiVersion: kubermatic.k8c.io/v1
kind: Seed
metadata:
  name: <<exampleseed>>
  namespace: kubermatic
spec:
  # Optional: Country of the seed as ISO-3166 two-letter code, e.g. DE or UK.
  # For informational purposes in the Kubermatic dashboard only.
  country: ""
  # Datacenters contains a map of the possible datacenters (DCs) in this seed.
  # Each DC must have a globally unique identifier (i.e. names must be unique
  # across all seeds).
  datacenters:
    <<exampledc>>:
      # Optional: Country of the seed as ISO-3166 two-letter code, e.g. DE or UK.
      # For informational purposes in the Kubermatic dashboard only.
      country: ""
      # Optional: Detailed location of the cluster, like "Hamburg" or "Datacenter 7".
      # For informational purposes in the Kubermatic dashboard only.
      location: ""
      # Node holds node-specific settings, like e.g. HTTP proxy, Docker
      # registries and the like. Proxy settings are inherited from the seed if
      # not specified here.
      node:
        # Optional: If set, this proxy will be configured for both HTTP and HTTPS.
        httpProxy: ""
        # Optional: These image registries will be configured as insecure
        # on the container runtime.
        insecureRegistries: []
        # Optional: If set this will be set as NO_PROXY environment variable on the node;
        # The value must be a comma-separated list of domains for which no proxy
        # should be used, e.g. "*.example.com,internal.dev".
        # Note that the in-cluster apiserver URL will be automatically prepended
        # to this value.
        noProxy: ""
        # Optional: Translates to --pod-infra-container-image on the kubelet.
        # If not set, the kubelet will default it.
        pauseImage: ""
        # Optional: These image registries will be configured as registry mirrors
        # on the container runtime.
        registryMirrors: []
      # Spec describes the cloud provider settings used to manage resources
      # in this datacenter. Exactly one cloud provider must be defined.
      spec:
        alibaba:
          # Region to use, for a full list of regions see
          # https://www.alibabacloud.com/help/doc-detail/40654.htm
          region: ""
        anexia:
          # LocationID the location of the region
          locationID: ""
        aws:
          # List of AMIs to use for a given operating system.
          # This gets defaulted by querying for the latest AMI for the given distribution
          # when machines are created, so under normal circumstances it is not necessary
          # to define the AMIs statically.
          images:
            amzn2: ""
            centos: ""
            flatcar: ""
            rhel: ""
            sles: ""
            ubuntu: ""
          # The AWS region to use, e.g. "us-east-1". For a list of available regions, see
          # https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html
          region: ""
        azure:
          # Region to use, for example "westeurope". A list of available regions can be
          # found at https://azure.microsoft.com/en-us/global-infrastructure/locations/
          location: ""
        # BringYourOwn contains settings for clusters using manually created
        # nodes via kubeadm.
        bringyourown: {}
        digitalocean:
          # Datacenter location, e.g. "ams3". A list of existing datacenters can be found
          # at https://www.digitalocean.com/docs/platform/availability-matrix/
          region: ""
        # EnforceAuditLogging enforces audit logging on every cluster within the DC,
        # ignoring cluster-specific settings.
        enforceAuditLogging: false
        # EnforcePodSecurityPolicy enforces pod security policy plugin on every clusters within the DC,
        # ignoring cluster-specific settings
        enforcePodSecurityPolicy: false
        gcp:
          # Region to use, for example "europe-west3", for a full list of regions see
          # https://cloud.google.com/compute/docs/regions-zones/
          region: ""
          # Optional: Regional clusters spread their resources across multiple availability zones.
          # Refer to the official documentation for more details on this:
          # https://cloud.google.com/kubernetes-engine/docs/concepts/regional-clusters
          regional: false
          # List of enabled zones, for example [a, c]. See the link above for the available
          # zones in your chosen region.
          zoneSuffixes: []
        hetzner:
          # Datacenter location, e.g. "nbg1-dc3". A list of existing datacenters can be found
          # at https://wiki.hetzner.de/index.php/Rechenzentren_und_Anbindung/en
          datacenter: ""
          # Optional: Detailed location of the datacenter, like "Hamburg" or "Datacenter 7".
          # For informational purposes only.

```

--------------------------------

### Uninstall Cortex Component using Helm (Shell)

Source: https://docs.kubermatic.com/kubermatic/v2.20/tutorials_howtos/monitoring_logging_alerting/user_cluster/admin_guide

This command demonstrates how to uninstall a specific component, 'cortex', from the 'mla' namespace using Helm. This is an example of removing individual MLA stack components.

```shell
helm delete cortex -n mla

```

--------------------------------

### Example MinIO 'xl-single' Format JSON

Source: https://docs.kubermatic.com/kubermatic/v2.29/installation/upgrading/upgrade-from-2.24-to-2

An example of the format.json content indicating that MinIO is using the 'xl-single' storage driver, which is compatible with recent upgrades and requires no migration.

```json
{"version":"1","format":"xl-single","id":"5dc676ac-92f3-4c19-81d0-2304b366293c","xl":{"version":"3","this":"888f699a-2f22-402a-9e49-2e0fc9abd5c5","sets":[["888f699a-2f22-402a-9e49-2e0fc9abd5c5"]],"distributionAlgo":"SIPMOD+PARITY"}}
```

--------------------------------

### Commit and Push Git Repository

Source: https://docs.kubermatic.com/kubermatic/v2.20/installation/start_kkp/guides/setup_repository

This snippet demonstrates the standard Git commands to initialize a repository, create a new branch, add all files, commit them with a message, set a remote origin, and push the changes to the remote repository.

```bash
git init
git checkout -b main
git add .
git commit -m "Initial setup for KKP on Autopilot"
git remote add origin <your-git-repository-remote>
git push -u origin main

```

--------------------------------

### Example Certificate Status Output

Source: https://docs.kubermatic.com/kubermatic/v2.29/installation/install-kkp-ce

Illustrates the expected output when watching certificate acquisition progress, showing the certificate name, readiness status, associated secret, and age.

```bash
#NAME         READY   SECRET           AGE
#kubermatic   True    kubermatic-tls   1h
```

--------------------------------

### Rate-Limiting Configuration

Source: https://docs.kubermatic.com/kubermatic/v2.21/tutorials-howtos/monitoring-logging-alerting/user-cluster/admin-guide

Configures rate-limits for the write and read paths of the User Cluster MLA stack to prevent denial-of-service attacks. These endpoints allow for getting, creating, updating, and deleting admin settings for rate-limiting.

```APIDOC
## Rate-Limiting

### Description
Configures rate-limits for the write and read paths of the User Cluster MLA stack.

### Method
GET
### Endpoint
`/api/v2/projects/{project_id}/clusters/{cluster_id}/mlaadminsetting`

### Description
Retrieves the admin settings for rate-limiting.

### Method
POST
### Endpoint
`/api/v2/projects/{project_id}/clusters/{cluster_id}/mlaadminsetting`

### Description
Creates admin settings for rate-limiting.

### Method
PUT
### Endpoint
`/api/v2/projects/{project_id}/clusters/{cluster_id}/mlaadminsetting`

### Description
Updates admin settings for rate-limiting.

### Method
DELETE
### Endpoint
`/api/v2/projects/{project_id}/clusters/{cluster_id}/mlaadminsetting`

### Description
Deletes admin settings for rate-limiting.

### Rate-Limiting Options for Metrics

| Option             | Direction   | Enforced by   | Description                                                                 |
|--------------------|-------------|---------------|-----------------------------------------------------------------------------|
| `ingestionRate`    | Write path  | Cortex        | Ingestion rate limit in samples per second (Cortex `ingestion_rate`).       |
| `ingestionBurstSize`| Write path  | Cortex        | Maximum number of series per metric (Cortex `max_series_per_metric`).       |
| `maxSeriesPerMetric`| Write path  | Cortex        | Maximum number of series per this user cluster (Cortex `max_series_per_user`).|
| `maxSeriesTotal`   | Write path  | Cortex        | Maximum number of series per this user cluster (Cortex `max_series_per_user`).|
| `queryRate`        | Read path   | MLA Gateway   | Query request rate limit per second (NGINX `rate` in `r/s`).                |
| `queryBurstSize`   | Read path   | MLA Gateway   | Query burst size in number of requests (NGINX `burst`).                     |
| `maxSamplesPerQuery`| Read path   | Cortex        | Maximum number of samples during a query (Cortex `max_samples_per_query`).    |
| `maxSeriesPerQuery`| Read path   | Cortex        | Maximum number of timeseries during a query (Cortex `max_series_per_query`).  |

### Rate-Limiting Options for Logs

| Option             | Direction   | Enforced by   | Description                                                                 |
|--------------------|-------------|---------------|-----------------------------------------------------------------------------|
| `ingestionRate`    | Write path  | MLA Gateway   | Ingestion rate limit in requests per second (NGINX `rate` in `r/s`).        |
| `ingestionBurstSize`| Write path  | MLA Gateway   | Ingestion burst size in number of requests (NGINX `burst`).                 |
| `queryRate`        | Read path   | MLA Gateway   | Query request rate limit per second (NGINX `rate` in `r/s`).                |
| `queryBurstSize`   | Read path   | MLA Gateway   | Query burst size in number of requests (NGINX `burst`).                     |
```

--------------------------------

### Custom Addon Dockerfile Example

Source: https://docs.kubermatic.com/kubermatic/v2.17/guides/addons

A Dockerfile example for creating a custom addon image for Kubermatic. It uses a base image and copies custom addon manifests into the appropriate directory.

```dockerfile
FROM quay.io/kubermatic/addons:YOUR_KUBERMATIC_VERSION

ADD ./ /addons/

```

--------------------------------

### Deploy KKP Master using Kubermatic Installer

Source: https://docs.kubermatic.com/kubermatic/v2.29/installation/upgrading/upgrade-from-2.24-to-2

This command initiates the deployment of the KKP Master using the kubermatic-installer. It requires a Helm values file that has been adjusted for the target version, and the KubermaticConfiguration is no longer needed unless modified.

```bash
./kubermatic-installer deploy kubermatic-master --helm-values path/to/values.yaml
```

--------------------------------

### Create Kubernetes Cluster with KKP Addon using Kubeone

Source: https://docs.kubermatic.com/kubermatic/v2.20/installation/install_kkp_on_node

This command utilizes Kubeone to create the Kubernetes cluster and simultaneously applies the prepared KKP master addon configuration. It ensures that KKP is installed as part of the cluster bootstrapping process.

```shell
make k1-apply PROVIDER=aws
```

--------------------------------

### Create Grafana Dashboard ConfigMap Example

Source: https://docs.kubermatic.com/kubermatic/v2.20/tutorials_howtos/monitoring_logging_alerting/user_cluster/admin_guide

This YAML defines a Kubernetes ConfigMap used to provide Grafana dashboards to the MLA stack. The configmap should be named with the prefix 'grafana-dashboards' and placed in the 'mla' namespace. The dashboard JSON data is stored in the 'data' section.

```yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: grafana-dashboards-example
  namespace: mla
data:
  example-dashboard.json: <your-dashboard-json-data>
```

--------------------------------

### Run Local KKP Installation (Shell)

Source: https://docs.kubermatic.com/kubermatic/v2.29/installation/local-installation

Executes the `kubermatic-installer local kind` command to initiate the local installation of Kubermatic Kubernetes Platform using `kind`. This command automates the creation of a `kind` cluster and deploys KKP, KubeVirt, and CDI.

```shell
./kubermatic-installer local kind
```

--------------------------------

### Node Affinity Example

Source: https://docs.kubermatic.com/kubermatic/v2.21/architecture/supported-providers/kubevirt/kubevirt

An example of node affinity configuration using preferred scheduling. This allows specifying preferences for scheduling pods onto nodes that match certain labels.

```yaml
nodeAffinity:
  preferredDuringSchedulingIgnoredDuringExecution:
    nodeSelectorTerms:
    - matchExpressions:
      - key: foo
        operator: In
        values:
        - bar

```

--------------------------------

### Example MinIO 'fs' Format JSON

Source: https://docs.kubermatic.com/kubermatic/v2.29/installation/upgrading/upgrade-from-2.24-to-2

An example of the format.json content indicating that MinIO is using the legacy 'fs' storage driver. This format is not supported in newer MinIO versions and requires migration or data wiping.

```json
{"version":"1","format":"fs","id":"baa787b5-43b6-4bcb-b1d7-acf46bcc0a05","fs":{"version":"2"}}
```

--------------------------------

### Configure Default Application Definition (YAML)

Source: https://docs.kubermatic.com/kubermatic/v2.29/tutorials-howtos/applications/default-enforced-applications

Defines an application to be automatically installed in new clusters. Users can manage these applications after installation. This example uses Helm for deployment.

```yaml
apiVersion: apps.kubermatic.k8c.io/v1
kind: ApplicationDefinition
metadata:
  name: apache
spec:
  description: Apache HTTP Server is an open-source HTTP server for modern operating systems
  method: helm
  default: true
  versions:
    - template:
        source:
          helm:
            chartName: apache
            chartVersion: 9.2.9
            url: https://charts.bitnami.com/bitnami
      version: 9.2.9
    - template:
        source:
          git:
            path: bitnami/apache
            ref:
              branch: main
            remote: https://github.com/bitnami/charts.git
      version: 2.4.55-git

```
Tokens:
Raw