### 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: <> 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. ✌ ``` -------------------------------- ### 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: <> 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: <> 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: <> # 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: <> # 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: <> # 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: <> # 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: <> 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: <>: # 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 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: ``` -------------------------------- ### 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 ``` -------------------------------- ### Print Default KubermaticConfiguration with Addons Source: https://docs.kubermatic.com/kubermatic/v2.20/architecture/concept/kkp-concepts/addons This command uses the `kubermatic-installer` tool to output a full default `KubermaticConfiguration`. This output includes default addon configurations and serves as a starting point for customization. It requires Docker to be installed. ```bash docker run --rm quay.io/kubermatic/api:KUBERMATIC_VERSION kubermatic-installer print ```