Kommander DocumentationD2iQ® Kommander® version 2.1.1 was released on December 30, 2021.
To get started with Kommander, download and install the latest version of Kommander.
NOTE: You must be a registered user and logged on to the support portal to download this product. New customers must contact their sales representative or sales@d2iq.com before attempting to download or install Konvoy.
Release summary
This release provides new features and enhancements to improve the user experience, fix reported issues, integrate changes from previous releases, and maintain compatibility and support for other packages used in Kommander.
New features and capabilities
Ability to add catalog applications
With this release, you can now add catalog applications to your Kommander instances. Currently, we provide the following operator applications that are workspace-scoped:
- Kafka operator
- Spark operator
- Zookeeper operator
For more information, see DKP catalog applications.
Fixes and Improvements
- Fixed an issue where the
dkp deletecommand could fail with a SIGSEGV when attempting to delete a DKP cluster from AWS where you have permanent credentials. (COPS-7109) - Fixed an issue where the AWS
--regionor Azure--locationinstaller flags were not being enforced in the target cluster. (COPS-7101) - Corrected an issue where the
PreprovisionedInventoryobject and SSH key secret were not moved to the target cluster when making the cluster self-managing.(COPS-7079) - When Kommander installation is complete, you can open the Kommander dashboard and access the username and password credentials by running:
kommander open dashboard
Component updates
The following services and service components have been upgraded to the listed version:
- centralized-grafana: 18.1.1
- centralized-kubecost: 0.20.0
- cert-manager: 0.2.7
- dex: 2.9.10
- external-dns: 2.20.5
- fluent-bit: 0.16.2
- gatekeeper: 0.6.8
- grafana-logging: 6.16.14
- grafana-loki: 0.33.1
- istio: 1.9.1
- jaeger: 2.21.0
- karma: 2.0.0
- kiali: 1.29.1
- knative: 0.18.3
- kube-oidc-proxy: 0.2.5
- kube-prometheus-stack: 18.1.1
- kubecost: 0.20.0
- kubefed: 0.9.0
- kubernetes-dashboard: 5.0.2
- kubetunnel: 0.0.8
- logging-operator: 3.15.0
- metallb: 0.12.2
- minio-operator: 4.1.7
- nfs-server-provisioner: 0.6.0
- nvidia: 0.4.3
- project-grafana-logging: 6.16.14
- project-grafana-loki: 0.33.1
- project-logging: 1.0.0
- prometheus-adapter: 2.11.1
- reloader: 0.0.99
- thanos: 0.4.5
- traefik: 10.3.0
- traefik-forward-auth: 0.3.2
- velero: 3.1.3
Known Issues
The following items are known issues with this release.
Create cert-manager resources on attached clusters with cert-manager pre-installed
If you attach a cluster that already has cert-manager installed, you need to manually create the three cert-manager resources, in the yaml file, after attaching your cluster.
For example, Konvoy-created clusters that are self-managed have cert-manager already installed to the cert-manager namespace.
Verify that your cluster have cert-manager installed by:
export KUBECONFIG=<kubeconfig-path>
kubectl get pod -A | grep "cert-manager"
If your cluster does not have cert-manager installed, the output will be empty.
If your cluster has cert-manager installed, the output resembles this example:
cert-manager cert-manager-848f547974-crl47 1/1 Running 0 5m5s
cert-manager cert-manager-cainjector-54f4cc6b5-wbzvr 1/1 Running 0 5m5s
cert-manager cert-manager-webhook-7c9588c76-pdxrb 1/1 Running 0 5m4s
If your cluster has cert-manager installed, set the namespace for the workspace you attached the cluster in:
export WORKSPACE_NAMESPACE=<workspace-name-abcd>
Then, create the following yaml file:
cat << EOF > cert_manager_root-ca.yaml
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
name: kommander-bootstrap-ca-issuer
namespace: $WORKSPACE_NAMESPACE
spec:
selfSigned: {}
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: kommander-bootstrap-root-certificate
namespace: $WORKSPACE_NAMESPACE
spec:
commonName: ca.kommander-bootstrap
dnsNames:
- ca.kommander-bootstrap
duration: 8760h
isCA: true
issuerRef:
name: kommander-bootstrap-ca-issuer
secretName: kommander-bootstrap-root-ca
subject:
organizations:
- cert-manager
---
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
name: kommander-bootstrap-issuer
namespace: $WORKSPACE_NAMESPACE
spec:
ca:
secretName: kommander-bootstrap-root-ca
EOF
Next, apply this file to your cluster you are attaching to Kommander:
kubectl apply -f cert_manager_root-ca.yaml
Finally, fix the broken certificates for the attached cluster:
kubectl patch certificate -n $WORKSPACE_NAMESPACE kube-oidc-proxy --type='merge' -p '{"spec": {"issuerRef": {"kind": "Issuer", "name": "kommander-bootstrap-issuer"}}}'
kubectl patch certificate -n $WORKSPACE_NAMESPACE kommander-traefik --type='merge' -p '{"spec": {"issuerRef": {"kind": "Issuer", "name": "kommander-bootstrap-issuer"}}}'
cert-manager HelmRelease will fail to deploy due to your existing cert-manager installation. This is expected and can be ignored.
Kommander Cluster with custom SSL certificate
After attaching a cluster, the management cluster should deploy apps to managed clusters. If the management cluster was initialized using a custom SSL certificate, the managed cluster will fail cloning the manager’s service repository. Check the status of the federated git repository resource to see the error:
kubectl get gitrepo -n kommander-flux management --kubeconfig MANAGED-KUBECONFIG
[..]
unable to clone 'https://MANAGER_INGRESS_ADDRESS/dkp/kommander/git/kommander/kommander': Get "https://MANAGER_INGRESS_ADDRESS/dkp/kommander/git/kommander/kommander/info/refs?service=git-upload-pack": x509: certificate signed by unknown authority
[..]
The deployment fails because the managed cluster uses the wrong CA certificate to verify access to the management cluster’s git repository. Solve this issue by patching the gitserver-ca secret within the kommander-flux namespace on the managed cluster with the CA certificate stored in the kommander-traefik-certificate secret within the kommander namespace on the management cluster.
kubectl --kubeconfig=MANAGED_KUBECONFIG patch secret -n kommander-flux gitserver-ca -p '{"data":{"caFile":"'$(kubectl --kubeconfig=MANAGER_KUBECONFIG get secret -n kommander kommander-traefik-certificate -o go-template='{{index .data "ca.crt"}}')'"}}'
You may need to trigger a reconciliation of the flux controller on the managed cluster if you do not want to wait for its regular interval to occur. Use the flux CLI utility:
flux reconcile -n kommander-flux source git management --kubeconfig MANAGED_KUBECONFIG
► annotating GitRepository management in kommander-flux namespace
✔ GitRepository annotated
◎ waiting for GitRepository reconciliation
✔ fetched revision main/GIT_HASH
cert-manager expiration workaround
Due to an oversight, some Kommander versions do not properly handle certificate renewal for the Cluster CA and certificates that are created for Kommander applications. The cert-manager component renews all certificates 60 days after you install Kommander on your cluster. When this occurs, some Kommander applications and pods fail to receive the renewed certificate information, causing them to stop working upon expiration. This occurs 60-90 days after Kommander was installed, which normally would coincide with the date you created the cluster. While the effects can vary, the most common failure is the inability to log in to the UI due to an expired certificate in the dex-k8s-authenticator pod. You may also see issues with flux no longer being able to access the internal gitea repository.
A permanent fix for the issue requires upgrading to Kommander 2.2.1 or higher. In the meantime, a docker container is available that contains a script that extends the validity of the Cluster CA to 10 years, fixes the certificate reload issue, and restarts the affected pods once the new certificates are issued.
The docker container can be applied to the management cluster in any environment (networked, air-gapped, on-prem, etc.) and remediates the issue regardless of your CA issuer type (SelfSigned for air-gapped environments, ACME, or your own certificate issuer configured separately for your institution).
If there are any workload clusters attached to the management cluster, they will also be remediated.
Note that this container does not in any way affect, nor change certificates associated with a custom domain you may have created for the cluster.
To fix the issue on an impacted cluster, run this command:
IMPORTANT: Before running this command, you must replace <path/to/my_kubeconfig> with an absolute path of the location that contains the kubeconfig for the cluster you wish to update. It will not work properly with a relative file path. For example, use /home/example/my-kubeconfig.yaml, or `pwd`/my-kubeconfig.yaml
docker run -v <path/to/my_kubeconfig>:/kubeconfig -e KUBECONFIG=/kubeconfig mesosphere/rotate-certificate-hotfix:2.1.1
Updating override upon major version upgrade to ensure Gitea functionality
When running the kommander migrate -y function is complete, you will have to edit a Traefik Middleware object in order for Gitea to correctly perform.
To do this, edit the ConfigMap that contains the Middleware object:
kubectl edit configmap traefik-10.3.0-migration-overrides -nkommander
Search for the yaml snippet that contains the Middleware with the name stripprefixes. This will look something like this:
apiVersion: traefik.containo.us/v1alpha1
kind: Middleware
metadata:
name: stripprefixes
...
spec:
stripPrefix:
prefixes:
- /dkp/alertmanager
- /dkp/api-server
- /dkp/kommander/dashboard
- /dkp/kommander/gitserver
...
You will then need to add /dkp/kommander/git to the spec.stripPrefix.prefixes list:
apiVersion: traefik.containo.us/v1alpha1
kind: Middleware
metadata:
name: stripprefixes
...
spec:
stripPrefix:
prefixes:
- /dkp/alertmanager
- /dkp/api-server
- /dkp/kommander/dashboard
- /dkp/kommander/gitserver
- /dkp/kommander/git
Then, save this file.
Additional resources
For more information about working with native Kubernetes, see the Kubernetes documentation.