{"id":1213,"date":"2023-01-02T14:34:50","date_gmt":"2023-01-02T11:34:50","guid":{"rendered":"https:\/\/www.bandidor.info\/wp\/?p=1213"},"modified":"2023-01-02T22:46:15","modified_gmt":"2023-01-02T19:46:15","slug":"camunda-8-on-k0s-the-zero-friction-kubernetes","status":"publish","type":"post","link":"https:\/\/www.bandidor.info\/wp\/?p=1213","title":{"rendered":"Camunda 8 on k0s – the zero friction Kubernetes"},"content":{"rendered":"\n

What’s this all about?<\/h2>\n\n\n\n

The goal is to migrate the process automation project (see my previous article Docker, Kubernetes, and Co. \u2013 part II<\/a>) to the new Camunda flagship – Camunda 8. I’ll skip k0s installation entirely; it’s already up and running on my local machine. For details, see https:\/\/docs.k0sproject.io\/<\/a><\/p>\n\n\n\n

Let’s get it running<\/h2>\n\n\n\n

Here is the documentation: https:\/\/docs.camunda.io\/docs\/self-managed\/about-self-managed\/<\/a>. Following the documentation, I’ll install Camunda 8 Helm chart and see if it works just out of the box.<\/p>\n\n\n\n

First caveat encountered – repository name already in use<\/h3>\n\n\n\n

Obviously, my fault; after I’d done some work with Camunda 7, I already had the respective repository in my Helm repository list, so I had to give it a different name – c8:<\/p>\n\n\n\n

helm repo add c8 https:\/\/helm.camunda.io<\/code><\/p>\n\n\n\n

Now my repository list looks like this:<\/p>\n\n\n\n

olegme@master-node:~$ helm repo list\nNAME                           \tURL                                                                         \nnfs-subdir-external-provisioner\thttps:\/\/kubernetes-sigs.github.io\/nfs-subdir-external-provisioner\/          \npostgres-operator-charts       \thttps:\/\/opensource.zalando.com\/postgres-op...   \npostgres-operator-ui-charts    \thttps:\/\/opensource.zalando.com\/postgres-op...\ncamunda                        \thttps:\/\/helm.camunda.cloud                                                  \nc8                             \thttps:\/\/helm.camunda.io    <\/code><\/pre>\n\n\n\n
Second caveat encountered – it takes time<\/h3>\n\n\n\n
Following the documentation from Camunda, I used the nice –atomic feature of Helm, but after several attempts realized that on my machine, it doesn’t finish on time and gets removed, so this is the command that worked at the end:<\/p>\n\n\n\n
 helm install c8 --atomic --timeout 20m0s --debug c8\/camunda-platform -n c8<\/code><\/p>\n\n\n\n
The above command sets the timeout to 20 minutes and the namespace to c8. After that – happiness:<\/p>\n\n\n\n
NAME                                READY   STATUS    RESTARTS       AGE\nc8-identity-54c6559c86-b6m96        1\/1     Running   0              107m\nc8-keycloak-0                       1\/1     Running   0              107m\nc8-operate-846bdf577b-vqm86         1\/1     Running   1 (104m ago)   107m\nc8-optimize-745bc47ff6-85pxc        1\/1     Running   0              107m\nc8-postgresql-0                     1\/1     Running   1 (35m ago)    107m\nc8-tasklist-6bc5cc4c44-n864z        1\/1     Running   1 (104m ago)   107m\nc8-zeebe-0                          1\/1     Running   0              107m\nc8-zeebe-gateway-86885f7fcb-8ptqf   1\/1     Running   0              107m\nelasticsearch-master-0              1\/1     Running   0              107m<\/code><\/pre>\n\n\n\n
A critical message – the Helm chart does not control physical volumes and physical volume claims, so they have to be manually removed every time before re-deployment. <\/p>\n\n\n\n
What’s next?<\/h2>\n\n\n\n
Accordingly to the documentation (and to the installation script’s lengthy output), now it’s time to run several kubectl port-forward<\/code> commands to make the components of the installation accessible from the outside of our k0s Cloud. But I don’t like the idea, so – let’s get cracking!<\/p>\n\n\n\n
Let’s customize the chart<\/h2>\n\n\n\n
The way to customize a help chart is simple; we pass an additional manifest file to the Helm install command, like here:<\/p>\n\n\n\n
helm install c8 c8\/camunda-platform -n c8 -f manifests\/values_c8_small.yaml<\/code><\/p>\n\n\n\n
Now comes the funny part: What do we put into this file? The first idea would be to reduce the amount of resources to allocate. It will help the deployment time and also eliminate possible deployment failures in case of resource shortage, like too weak local hardware.<\/p>\n\n\n\n
Make it smaller<\/h3>\n\n\n\n
Two ideas here, let’s have fewer zeebe engines and let’s reduce our elasticsearch instance.<\/p>\n\n\n\n
zeebe:\n  clusterSize: 1\n  partitionCount: 1\n  replicationFactor: 1\n  pvcSize: 10Gi<\/code><\/pre>\n\n\n\n
Here we reduce the cluster size to just one zeebe instance.<\/p>\n\n\n\n
And the smaller elasticsearch instance:<\/p>\n\n\n\n
  # Allocate smaller chunks of memory per pod.\n  resources:\n    requests:\n      cpu: \"100m\"\n      memory: \"512M\"\n    limits:\n      cpu: \"1000m\"\n      memory: \"512M\"\n\n  # Request smaller persistent volumes.\n  volumeClaimTemplate:\n    accessModes: [ \"ReadWriteOnce\" ]\n    storageClassName: \"nfs-client\"\n    resources:\n      requests:\n        storage: 15Gi<\/code><\/pre>\n\n\n\n
Please note that the complete resource file will be posted below.<\/p>\n\n\n\n
Port forward, Ingres, load balancer… WTF?<\/h3>\n\n\n\n
When the helm deployment finishes, it will suggest using a number of kubectl port-forward<\/code> commands to access your Camunda 8 installation. I didn’t like it and decided to look for a better solution. I played around using separate IP addresses for different PODs that need a connection to the outside world but dropped the idea as I found it too complicated. Finally, I decided to go with what is described here https:\/\/docs.camunda.io\/docs\/self-managed\/platform-deployment\/helm-kubernetes\/guides\/ingress-setup\/#separated-ingress-setup<\/a> as a Separated Ingress Setup.<\/p>\n\n\n\n
Ingress setup<\/h3>\n\n\n\n
There is one pre-condition<\/strong>, an ingress controller has to be already installed in our Kubernetes cluster. Then the necessary configuration will be applied automatically during the installation process of other components. Here is a link to learn more about an NGINX-based ingress controller: https:\/\/www.nginx.com\/products\/nginx-ingress-controller\/<\/a>. There are other implementations out there, but this is the simplest one.<\/p>\n\n\n\n
When everything is deployed, there will be a server (NGINX) listening on the external IP address of our cluster master-node, which will forward incoming connections to the respective PODs depending on the URL.<\/p>\n\n\n\n
Cheating on the DNS resolution<\/h3>\n\n\n\n
To enable the above, the simplest way on my local laptop<\/s> machine is to manipulate the DNS resolution to create a few DNS records pointing to the same IP address. Namely, the one of my master-node (controller). In my particular case, I decided to edit my hosts<\/code> file located in C:\\Windows\\System32\\drivers\\etc<\/code>. I added a few more records to it:<\/p>\n\n\n\n
192.168.2.241 camunda-example \n192.168.2.241 identity.camunda-example\n192.168.2.241 keycloak.camunda-example\n192.168.2.241 operate.camunda-example\n192.168.2.241 optimize.camunda-example\n192.168.2.241 tasklist.camunda-example\n192.168.2.241 zeebe.camunda-example<\/code><\/pre>\n\n\n\n
192.168.2.241 is the IP address of my master-node (controller), and these hostnames can actually be anything; they just need to match the configuration in the helm chart used to deploy Camunda 8. BTW, a reboot is not required after the changes to hosts file; they<\/code> will be picked up automatically by almost everything.<\/p>\n\n\n\n
Almost there…<\/h3>\n\n\n\n
And, finally, the chart. The one we will be used to modify the default values. <\/p>\n\n\n
\nglobal:\n  identity:\n    auth:\n      publicIssuerUrl: "http:\/\/keycloak.camunda-example\/auth\/realms\/camunda-platform"\n      operate:\n        redirectUrl: "http:\/\/operate.camunda-example"\n      tasklist:\n        redirectUrl: "http:\/\/tasklist.camunda-example"\n      optimize:\n        redirectUrl: "http:\/\/optimize.camunda-example"\n\nidentity:\n  ingress:\n    enabled: true\n    className: nginx\n    host: "identity.camunda-example"\n  fullURL: "http:\/\/identity.camunda-example"\n  \n  keycloak:\n    ingress:\n      enabled: true\n      ingressClassName: nginx\n      hostname: "keycloak.camunda-example"  \n\noperate:\n  ingress:\n    enabled: true\n    className: nginx\n    host: "operate.camunda-example"\n\noptimize:\n  ingress:\n    enabled: true\n    className: nginx\n    host: "optimize.camunda-example"\n\ntasklist:\n  ingress:\n    enabled: true\n    className: nginx\n    host: "tasklist.camunda-example"\n\n# Reduce for Zeebe and Gateway the configured replicas and with that the required resources\n# to get it running locally\nzeebe:\n  clusterSize: 1\n  partitionCount: 1\n  replicationFactor: 1\n  pvcSize: 10Gi\n\nzeebe-gateway:\n  replicas: 1\n  ingress:\n    enabled: true\n    className: nginx\n    host: "zeebe.camunda-example"\n\n# Configure elastic search to make it running for local development\nelasticsearch:\n  replicas: 1\n  minimumMasterNodes: 1\n  # Allow no backup for single node setups\n  clusterHealthCheckParams: "wait_for_status=yellow&timeout=1s"\n\n  # Allocate smaller chunks of memory per pod.\n  resources:\n    requests:\n      cpu: "100m"\n      memory: "512M"\n    limits:\n      cpu: "1000m"\n      memory: "512M"\n\n  # Request smaller persistent volumes.\n  volumeClaimTemplate:\n    accessModes: [ "ReadWriteOnce" ]\n    storageClassName: "nfs-client"\n    resources:\n      requests:\n        storage: 15Gi\n<\/pre><\/div>\n\n\n
What does it do? It configures the ingress controller to provide access to different PODs under different URLs. And this is it.<\/p>\n\n\n\n
Access our new shiny Camunda cluster<\/h3>\n\n\n\n
This is easy. After we run <\/p>\n\n\n\n
helm install c8 c8\/camunda-platform -n c8 -f manifests\/values_c8_small.ya<\/code>ml<\/code><\/pre>\n\n\n\n
and wait some 5<\/s> 10 minutes, we can see all PODs up and running:<\/p>\n\n\n\n
olegme@master-node:~$ kubectl get pods -n c8 -o=custom-columns='NAME:metadata.name,STATUS:.status.phase,IP:.status.podIP,NODE:.spec.nodeName'\nNAME                                STATUS    IP             NODE\nc8-identity-54c6559c86-b6m96        Running   10.244.2.25    slave-node2\nc8-keycloak-0                       Running   10.244.2.26    slave-node2\nc8-operate-846bdf577b-vqm86         Running   10.244.0.215   slave-node3\nc8-optimize-745bc47ff6-85pxc        Running   10.244.0.214   slave-node3\nc8-postgresql-0                     Running   10.244.1.36    slave-node1\nc8-tasklist-6bc5cc4c44-n864z        Running   10.244.3.20    slave-node4\nc8-zeebe-0                          Running   10.244.2.27    slave-node2\nc8-zeebe-gateway-86885f7fcb-8ptqf   Running   10.244.1.34    slave-node1\nelasticsearch-master-0              Running   10.244.1.35    slave-node1\n<\/code><\/pre>\n\n\n\n
Actually, the one which takes the longest time is Keycloack. It needs PostgreSQL, which takes time and, in some rare cases, fails to be installed properly. Still, I saw just one reason for failure – not properly discarding PVC and the respective volumes. <\/p>\n\n\n\n
And here is the respective ingress configuration:<\/p>\n\n\n\n
olegme@master-node:~$ kubectl get ing -n c8\nNAME               CLASS   HOSTS                      ADDRESS         PORTS   AGE\nc8-identity        nginx   identity.camunda-example   192.168.2.241   80      3h50m\nc8-keycloak        nginx   keycloak.camunda-example   192.168.2.241   80      3h50m\nc8-operate         nginx   operate.camunda-example    192.168.2.241   80      3h50m\nc8-optimize        nginx   optimize.camunda-example   192.168.2.241   80      3h50m\nc8-tasklist        nginx   tasklist.camunda-example   192.168.2.241   80      3h50m\nc8-zeebe-gateway   nginx   zeebe.camunda-example      192.168.2.241   80      3h50m\n<\/code><\/pre>\n\n\n\n
Let’s use it…<\/h3>\n\n\n\n
Actually, we won’t be using it for real just yet; let’s leave it to the following article. Here we provide just some screenshots. As we kept the demo\/demo user on our helm chart, we can use it at the beginning.<\/p>\n\n\n\n
Operate<\/h4>\n\n\n\n
Obviously, we go to http:\/\/operate.camunda-example<\/a><\/p>\n\n\n
\n
\"\"<\/a><\/figure>\n<\/div>\n\n\n
Optimize<\/h4>\n\n\n\n
Similarly: http:\/\/optimize.camunda-example<\/a>. Well, that’s boring…<\/p>\n\n\n
\n
\"\"<\/a><\/figure>\n<\/div>\n\n\n
Identity<\/h4>\n\n\n\n
Same as before: http:\/\/identity.camunda-example<\/a><\/p>\n\n\n
\n
\"\"<\/a><\/figure>\n<\/div>\n\n\n
Note an additional user I created just for fun. Still, it had to be created using the keycloack administrative UI. Camunda 8 Identity application cannot do it yet.<\/p>\n\n\n\n
Keycloack admin UI<\/h4>\n\n\n\n
Accessible here: http:\/\/keycloak.camunda-example\/. Admin credentials are created automatically; the user name is admin, the password is random and must be retrieved from the keycloack POD environment variables. <\/p>\n\n\n\n
\"\"<\/a><\/figure>\n\n\n\n
Some useful commands<\/h3>\n\n\n\n
Install chart:<\/p>\n\n\n\n
helm install c8 c8\/camunda-platform -n c8 -f manifests\/values_c8_small.yaml<\/code><\/pre>\n\n\n\n
Uninstall:<\/p>\n\n\n\n
helm uninstall c8  -n c8<\/code><\/pre>\n\n\n\n
Delete the respective Persistent Volume Claims that are not getting deleted automatically:<\/p>\n\n\n\n
kubectl delete pvc --all -n c8<\/code><\/pre>\n\n\n\n
Discussion<\/h2>\n\n\n\n
We got it up and running; that’s it. Let’s proceed to the next part – make use of it. Here you go – Make use of my local Camunda 8 cluster<\/a><\/p>\n\n\n\n
One last thing to note – we are doing all this in a local environment, which is not accessible from the outside of the local network. All used IPs are non-routable\/private IPs per RFC 1918, and that’s why I haven’t paid any attention to the security of my setup.<\/p>\n","protected":false},"excerpt":{"rendered":"
What’s this all about? The goal is to migrate the process automation project (see my previous article Docker, Kubernetes, and Co. \u2013 part II) to the new Camunda flagship – Camunda 8. I’ll skip k0s installation entirely; it’s already up and running on my local machine. For details, see https:\/\/docs.k0sproject.io\/ Let’s get it running Here…<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"ngg_post_thumbnail":0,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2},"jetpack_post_was_ever_published":false},"categories":[43,34,55,39],"tags":[35],"class_list":["post-1213","post","type-post","status-publish","format-standard","hentry","category-bpmn","category-camunda","category-camunda-8","category-kubernetes","tag-camunda"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p2EszU-jz","_links":{"self":[{"href":"https:\/\/www.bandidor.info\/wp\/index.php?rest_route=\/wp\/v2\/posts\/1213","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.bandidor.info\/wp\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.bandidor.info\/wp\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.bandidor.info\/wp\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.bandidor.info\/wp\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1213"}],"version-history":[{"count":23,"href":"https:\/\/www.bandidor.info\/wp\/index.php?rest_route=\/wp\/v2\/posts\/1213\/revisions"}],"predecessor-version":[{"id":1313,"href":"https:\/\/www.bandidor.info\/wp\/index.php?rest_route=\/wp\/v2\/posts\/1213\/revisions\/1313"}],"wp:attachment":[{"href":"https:\/\/www.bandidor.info\/wp\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1213"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.bandidor.info\/wp\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1213"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.bandidor.info\/wp\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1213"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}