Skip to content
dda-k8s-crate installs & configures all in one server k8s on a ubuntu system. Your setup will be reproducable and can be defined as data.
Clojure Shell Dockerfile
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Type Name Latest commit message Commit time
Failed to load latest commit information.
integration Added integration logging Sep 12, 2019
main Merge branch 'master' of… Oct 11, 2019
test/src/dda/pallet/dda_k8s_crate local data + some fixes Sep 26, 2019
uberjar First draft of implementing kubernetes installation in pallet. Aug 31, 2019
.gitignore Added viewonly Role for dashboard Mar 12, 2019
.travis.yml apply all refactorings Aug 23, 2019
k8s.edn added prod-bool to config + small fix Sep 26, 2019
project.clj deps update Sep 10, 2019


Clojars Project Build Status

Slack | | Website & Blog

This crate is part of dda-pallet.

Kubernetes setup

This crate uses Kuberentes to initialize and build a single host Kubernetes cluster.


This crate should fullfill certain requirements for the installed Kubernetes cluster

  • a small k8s all in one system for serving one application.
  • is compatible with k8s
  • providing ingress for app to be installed (replacement of traditional reverse-proxy httpd)
  • support letsencrypt (dynamic created by https) for a defined fqdn or injected static https certs.
  • exposes dashboard with users defined & disabled annonymous access.

Ingress and MetalLB

As our services need to be exposed to the outside by a URL we use Ingress to do just that. Ingress requires some sort of load balances attached in order to acquire an external IP. As we do not want to install Kubernetes on a third party cloud platform we require MetalLB to give Ingress an external IP. Ingress and MetalLB is configured in a dedicated file usually annotated with ingress_*.yml. There is a unique Ingress configuration for each type of certificate used and they can all be active at the same time and listen to different URLs. However, the config files are somewhat similar and most important config options are:

  • the name given for the ingress instance
  • the (cluster-)issuer to be used with that ingress instance
  • host(s) name and corresponding seceretName
  • the rules for redirecting and which service port to forward to

MetalLB configuration resiedes in a seperate metallb_config.yml file where the host ip needs to be changed to the actual external if of the host. metallb.yml is responsible for the installation of Metallb but does not need to be adjusted for our installation. [Ingress] [MetalLB]

Flannel networkking

Kubernetes requires a way for multiple hosts to commuicate with each other. Flanne handles the layer 3 networking of Kubernetes. We do not use any custom configuration of flannel. [Flannel] [Kubernetes Cluster Networking]

cert-manager and handling of https and certificates

Ingress together with MetalLB is not enough to handle https and ca certificates for our Kubernetes cluster. Additionally, we require cert-manager to issue certificates for us. The workflow for either letsencrypt or ca issuer requires three configs to be applied:

  • a secret representing the ca-key pairs needs to be created
  • a config file for the actual certificate needs to be created
  • an issuer of either self-signed, ca-issuer or letsencrypt issuer

The self-signed issuer does not require a secret or certificate config file. For the letsencrypt issuer we distinguish between an issuer for staging and one for production.

Nexus repository manager

The nexus repository manager is the first application we deploy on the Kubernetes cluster. It uses the lestsencrypt-prod-issuer and requires an ingress config file on its own. In addition to the ingress config file a nexus-storage.yml and nexus.yml config file are necessary. The storage is of kind PersistenVolume and differentiates the storage and actualy application of nexus in two seperate Pods.


The dashboard allows for debugging and overview of the Kubernetes cluster and should later also provide networking. To secure the dasboard, an ssh proxy is required and the dashboard can then be accessed via a http://localhost:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy in the browser.


dda-pallet is compatible to the following versions

  • pallet 0.8.x
  • clojure 1.9
  • (x)ubunutu 18.04



Watch log for debug reasons

In case of problems you may want to have a look at the log-file: less logs/pallet.log


You can define provisioning targets using the targets-schema

Domain API

You can use our conventions as a starting point: see domain reference

Infra API

Or you can build your own conventions using our low level infra API. We will keep this API backward compatible whenever possible: see infra reference


Copyright © 2018, 2019 meissa GmbH Licensed under the Apache License, Version 2.0 (the "License") Pls. find licenses of our subcomponents here

You can’t perform that action at this time.