Keep in mind that some things may not work out of the box, and you’ll probably require a lot of try & errors. Kubernetes is complex. Also, I’m not a power user of kubernetes, so there may be things that can be done in a better way. Hey, I did all of this by try & error too. What are the goals This guide will walk you through the process of creating a self-hosted kubernetes cluster with the following features:

References   How To Run OpenVPN in a Docker Container on Ubuntu 14.04 | DigitalOcean   Running Docker Containers with Systemd Because we are installing our cluster bare metal on servers exposed on the Internet, we’ll need a way to secure all of our network traffic around the critical parts of kubernetes. To do so, we’ll use OpenVPN to create a virtual secured network where all of our nodes will work.

References   https://docs.kublr.com/logging/logging-api-audit/   Logging in Kubernetes with Elasticsearch, Kibana, and Fluentd   Auditing | Kubernetes Note : Even if this part is not required, you should not ignore it on dev environment and should really really REALLY not skip it for production. In fact, it can contain useful debug informations and security traces to see what is going on in your kubernetes cluster, and even on your whole server(s).

Create the cluster config file References   kubernetes - kubeadm init --apiserver-advertise-address flag equivalent in config file - Stack Overflow We are now going to configure the cluster. For the sake of traceability, this configuration won’t be done via CLI flags, but via  a configuration file. The path of the cluster config file will later be referenced as the {{cluster.configFile}}, and should be inside /etc/kubernetes.

References   Add OpenAPI v3 schemas to CRDs by jrostand · Pull Request #157 · traefik/traefik-helm-chart · GitHub Start by creating traefik required resources. You can directly use resources from the  kubernetes/traefik templates: it does not contain variables. Those are taken from  traefik docs mixed up with  this PR for kubernetes 1.19 support and schemas. Please look forward for  this issue in traefik about official v1.

Now that you have a router installed, you have to pass requests on your server to it. This setup use a single entry point directly binding some ports on the host server. 1. Make a static and previsible configuration As you may have noticed in the step  Kickstart the cluster, the metallb configuration use only dynamic adresses. But for the reverse proxy to work, we’ll need to be sure that our traefik router has a constant IP in your VPN.

References   Persistent Volumes | Kubernetes   Dynamic Volume Provisioning | Kubernetes   Storage Classes | Kubernetes   Kubernetes Volumes explained | Persistent Volume, Persistent Volume Claim & Storage Class - YouTube As you may know, docker (and thus, kubernetes) does not persist anything by default. That means that everytime you restart a pod (container), it is in the exact same state as it was at its first execution, except for the mount points.

Well, things are getting real and are on the point to become quite complex. So we’ll setup (super unsafe) dashboards to see what is going on easily. After all, we have nothing critical for now, but we might get troubles soon. And, don’t worry, we’ll make it safe just after that. 1. Traefik dashboard: monitoring routes The traefik dashboard will help us in the diagnostics of our ingress routes and traefik-related stuff.

Here is a graph of the RBAC setup we are going to implement: 1. Setup keycloak We’ll use keycloak to proxy our authentication for all monitors, using a single realm. You may use several realms in real-life situations. This is probably the tough part, and you may tweak heavily the following guide. Moreover, I may forgot to write some instructions, or somes are heavily linked to your very own setup.

Create the realm and the client References   engineering-notes/kubernetes-keycloak-integration.md at master · zufardhiyaulhaq/engineering-notes · GitHub 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 REALM_URL="https://keycloak.{{cluster.baseHostName}}/auth/realms/{{apiServer.realmName}}" # Log in TOKEN_RESPONSE="$(curl \ -d "grant_type=password" \ -d "client_id={{apiServer.clientId}}" \ -d "client_secret={{apiServer.clientSecret}}" \ -d "username=admin-user" \ -d "password=admin-user" \ $REALM_URL/protocol/openid-connect/token)" # Extract the access token ACCESS_TOKEN="$(echo "$TOKEN_RESPONSE" | jq '.

Now that we have our authentication service up and running, we can protect our dashboards installed in the step  06 - Monitoring: See what is going on using our Keycloak OpenID Connect provider. Here is a diagram on how authorization will be managed: Traefik dashboard TODO Kibana TODO Kube dashboard References   Protect Kubernetes Dashboard with OpenID Connect | by Hidetake Iwata | ITNEXT Again, we are going to set up a new instance of  louketo-proxy.