sudo docker run --name kublr -d --restart=unless-stopped -p 9080:9080 kublr/kublr:1.22.3
Follow the full instructions in Quick start for Kublr Demo/Installer.
The Kublr Demo/Installer is a lightweight, dockerized, limited-functionality Kublr Platform which can be used to:
The Kublr Demo/Installer stores all of the data about the created clusters inside the Docker container. If you delete the Docker container you will lose all data about the created clusters and the Kublr platforms. However, you will not lose the clusters and the platforms themselves.
We recommend using the Kublr Demo/Installer to verify if a Kubernetes cluster can be created in your environment and to experiment with it. To manage a real cluster and experience all features, you can create a full-featured Kublr Platform in a cloud or on-premise.
The Kublr 1.22.3 patch release includes bug fixes in Kublr agents for NVIDIA GPU support on AWS P and G instance types. In addition Kublr v1.22.3 includes security fixes for base docker images e.g. alpine, as well as Kublr Team starting publishing current vulnerability lists and switching to two weeks security fix timeline.
Additionally, you need to download the BASH scripts from https://repo.kublr.com
You also need to download Helm package archives and Docker images:
https://repo.kublr.com/repository/arc/agent/1.22.10/kublr-agent-load-gobins-1.22.10-17.sh
https://dl.kublr.com/agent/1.22.10/kublr-agent-1.22.10-17.tar.gz
https://repo.kublr.com/repository/arc/agent/1.22.10/kublr-agent-load-images-1.22.2-17.sh
(optional if the control plane 1.22.3 images are imported already)
https://dl.kublr.com/agent/1.22.10/kublr-agent-images-1.22.10-17.tar.gz
(optional if the control plane 1.22.3 images are imported already)
| Component | Version | Kublr Agent | Notes |
|---|---|---|---|
| Kubernetes | 1.22 | 1.22.10-17 | default v1.22.10 |
| 1.21 | 1.21.13-31 | ||
| 1.20 | 1.20.14-35 | ||
| 1.19 | 1.19.16-64 | Deprecated in 1.23.0 |
| Component | Version |
|---|---|
| Kublr Operator | 1.22.3-13 |
| Kublr Control Plane | 1.22.3-72 |
| Component | Version |
|---|---|
| Kubernetes | |
| Dashboard | v2.2.0 |
| Cluster autoscaller | 1.8.4 |
| Kublr System | 1.22.3-10 |
| LocalPath Provisioner (helm chart version) | 0.0.12-9 |
| Ingress | 1.22.3-12 |
| nginx ingress controller (helm chart version) | 4.0.10 |
| cert-manager (helm chart version) | 1.5.3 |
| Centralized Logging | 1.22.3-38 |
| ElasticSearch | 7.10.2 |
| Kibana | 7.10.2 |
| SearchGuard | 52.7.0 |
| SearchGuard Kibana plugin | 51.0.0 |
| SearchGuard Admin | 7.10.2-52.7.0 |
| RabbitMQ | 3.9.5 |
| Curator | 5.8.1 |
| Logstash | 7.10.2 |
| Fluentd | 3.3.0 |
| Fluentbit | 1.8.10 |
| Centralized Monitoring | 1.22.3-18 |
| Prometheus | 2.28.1 |
| Kube State Metrics (helm chart version) | 3.4.2 |
| AlertManager | 0.22.0 |
| Grafana | 7.5.10 |
| Victoria Metrics | |
| Cluster | 0.8.2 |
| Agent | 0.6.5 |
| Alert | 0.3.5 |
| Kublr KubeDB (Deprecated in 1.22.0, End of support in 1.23.0) | 1.22.3-6 |
| kubedb (helm chart version) | v0.14.0-alpha.2 |
Kublr feature Ingress 1.22.2-9 included in Kublr 1.22 only supports Kubernetes v1.19 and above, so for Kubernetes v1.18 clusters please use Kublr feature Ingress 1.21.2-24 (the version can be overridded in the custom cluster spec).
Kublr feature KubeDB reaches end of support in Kublr v1.22.0 and is not supported on Kubernetes v1.22 and above. Please remove the feature from the cluster specification after Kublr Control Plane upgrade:
spec:
features:
kubedb:
enabled: false
When upgrading a Kubernetes v1.22, Kublr feature Ingress must first be upgraded to v1.22.1-7.
If applications deployed to the cluster are using Kublr-managed ingress controller, review their ingress rules
before upgrading and make sure that spec.ingressClassName proerty is set to nginx.
Upgrading to the new Kublr Logging version will override kublr predefined SearchGuard roles (kublr:*, sg_kublr_kibana_user, sg_curator, sg_hooks, sg_kublr_logstash, sg_monitor) and role mappings (kublr:*, sg_kublr_logstash, sg_kublr_kibana_user, sg_curator, sg_hooks, sg_monitor, SGS_KIBANA_SERVER, SGS_LOGSTASH, SGS_ALL_ACCESS, SGS_KIBANA_USER).
Please refer to support portal howto backups existing customization before upgrading.
Kublr feature logging with fluentbit log collector uses new Elasticsearch index template named kublr-logs instead of the legacy kublr-index-template. By default ES index templates are updated by Kublr once every 24 hours, so when plannig to switch from fluentd to fluentbit, it is recommended to first upgrade the control plane, and perform the switch 24 hours later.
Nvidia GPU support feature by default relies on the latest nvidia driver version included in nvidia, so if the latest driver version published by Nvidia does not support the GPU hardware present in the system, enabling GPU support will require specifying exact driver version in the Kublr cluster specification.
Notably, this is the case for most AWS GPU accelerated instance types such as p2.*, p3.*, g5.*, g4dn.*, g3(s).*.
GPU hardware provided by AWS on these instance types (Nvidia K80, Nidia Tesla V100, Nvidia A10G Tensor Core, Nvidia T4 Tensor Core,
and Nvidia Tesla M60 correspondingly) is not supported by the default latest version of Nvidia GPU drivers provided by Nvidia.
As a result an earlier version driver must be specified explicitely in the Kublr cluster spec for a corresponding worker node
group in kublrAgentConfig section property kublr.features.nvidia_devices.driver.
Driver nvidia-driver-470-server is tested to support GPU devices provided in all the above instance types on Ubuntu 18.04 and
Ubuntu 20.04 images.
When RHEL or Centos images are used, the driver nvidia-driver-branch-470 is known to work well.
Additionally for RHEL backed instances it is important to use Docker CE instead of default docker provided with the OS. This is due to the fact that RHEL provided version of Docker is based on quite old Docker CE version and does not work well with Nvidia container runtime that is required for Nvidia GPU integration.
The following is an example of a Kublr cluster spec snippet that configures Nvidia driver version 470 on an Ubuntu backed worker node group.
spec:
...
nodes:
- autoscaling: false
kublrVariant: aws-ubuntu-20.04
...
name: group1
# this "kublrAgentConfig" section allows customizing Kublr agent running on this
# worker node group; in this case setting a specific version of nvidia driver.
kublrAgentConfig:
kublr:
features:
nvidia_devices:
driver: [nvidia-driver-470-server]
The following example of a Kublr cluster spec snippet shows Nvidia driver version 470 and docker configuration on an RHEL backed worker node group.
spec:
...
nodes:
- autoscaling: false
kublrVariant: aws-redhat-8
...
name: group1
# this "kublrAgentConfig" section allows customizing Kublr agent running on this
# worker node group; in this case setting a specific version of nvidia driver and
# Docker CE preference.
kublrAgentConfig:
kublr:
features:
nvidia_devices:
driver: [nvidia-driver-branch-470]
setup:
docker:
edition_fallback_order: 'ce,os'