The following components are installed when leveraging KubePlatform.

Ingress Controller

The nginx-ingress controller is used for routing incoming traffic. By using ingresses for exposing services to external traffic, only one load balancer is provisioned per ingress controller. This approach does save not only costs billed by the infrastructure provider but also provides more fine-grained control over routing. The route configuration is made via annotations of the ingress object. For more details on the nginx-ingress controller configuration, see the documentation.


For collecting and analyzing logs, the EFK Stack is used, consisting of Elasticsearch, Fluentd, and Kibana. Elasticsearch stores logs emitted by pods. With Fluentd logs are collected and transformed into the JSON format for Elasticsearch to consume. It is deployed as a DeamonSet and has permission to collect logs from every pod on every node. Those logs are then submitted to Elasticsearch for storage. Data from the logs can be queried and visualized with Kibana.

Monitoring, Alerting

Prometheus is used to collect and store metrics for monitoring. The Kube-State-Metrics add-on generates metrics from the Kubernetes API to monitor deployed workloads. Metrics about Kubernetes nodes are collected via the node-exporter. Additionally, the Prometheus Alert Manager triggers notifications for services such as Pagerduty and Slack by using webhooks. Grafana serves as time series analytics tool for Prometheus provided metrics. Additionally, Grafana provides a UI to define alert rules and to create dashboards.

TLS Certificate Management

The cert-manager is installed for automatically issuing tls certificates via Let’s Encrypt. Annotations to the service’s ingress indicate the need for a tls certificate to be fetched by the cert-manager. For more information about the cert-manager, reference to the documentation.

# ingress.yaml
annotations: "letsencrypt-prod" http01

DNS Management

The DNS server configuration tool External DNS communicates with the infrastructure provider to configure DNS entries. Applying domain mappings through a Kubernetes ingress leads to an actual configuration via the IaaS providers API where your Kubernetes cluster is running on. This approach does only apply if the same provider your cluster is running on manages the domain’s nameservers. The credentials for communicating with the IaaS providers API need to be provided upon installation with KubePlatform. Usually, those credentials can be generated via CLI or the IaaS providers user interface. External DNS is a self-service tool so that it acts autonomously when valid credentials where provided. For more details, see the documentation of External DNS.

Identity Management

Keycloak manages authentication and authorization of applications and users. Every application can be secured with Keycloak, not only the Monitoring and CI/CD user interfaces which are installed with KubePlatform. See the Keycloak documentation for reference.

OAuth-based Authentication

When not using Keycloak for identity management the oauth2-proxy can be leveraged to connect with an other auth provider. By default, oauth2-proxy supports OAuth with providers such as Google, Azure, Facebook, GitHub, GitLab, and LinkedIn. For configuration consult the GitHub repository of oauth2-proxy.

CI/CD Tooling

argo is a collection of Kubernetes-native automation tools for building workflow pipelines. KubePlatform installs the argo workflow engine, along with argo events. These components enable to create build pipelines or to automate any other workflow.

Consult argos’ project repository, to learn more about their workflow automation tools. For running basic workflows refer to the demos page. For using it for CI, refer to this example.