This guide will walk you through the process of creating a self-hosted kubernetes cluster with the following features:
kubectl authentication through OpenID Connect
I’ll try to use as few 3rd party tools outside of kubernetes, except helm (to deploy complex apps more easily) and krew (to add some features to kubectl). But we’ll get to that later. The goal is that you use as much kubernetes itself as possible so that you can get used to it, understand it, and thus, be able to troubleshoot if you have problems later. If you’re a kubernetes power-user, 1. what are you doing here ? and 2. you might find other guides more applicable to your needs.
Other similar guides you might prefer:
Those tutorials are for bare-metal cluster initialization, but without the extra security of running kubernetes only through a VPN. You’re welcome to get the best of both worlds tho. Plus, the author, Alex Ellis is a professional of Cloud Native solutions, so you should better trust a pro than me doing this as experiments.
I’ll provide you explanations on each steps we are doing together, & give you templates that you can use with the bare minimum working configuration.
Templates contains placeholders for variables that you will need to replace. If I didn’t broke anything in the meantime, you should be able to fill those vars using the sidebar. Keep in mind that those settings are probably unsafe, or not totally OK for your particular settings. Thus, I highly recommend you to 📚 RTFM for each of the containers & tools we set up to tweak things.
Kubernetes configurations are meant to be versionned. So, I recommend you to init a repository and commit after each steps. For sensible data such as private keys, tokens or OpenID client secrets, .
Kubernetes ecosystem & docker images evolve pretty fast, so this guide may become obsolete. Check regularly if new docker images aren’t available, and how their interactions or configurations evolve.
For security reasons, I highly recommend you to start doing all your stuffs with domain name aliases until your setup is safe enough to be publicly exposed. We are going to setup dashboards & logging tools without authentication in a first time, so this is important that nobody else than you can access them. Because all of those services will run behind a router that routes based on domain name, using a forced DNS resolution instead of a public A record will prevent your router to route things to your apps.
This is not safe, I know. But this is temporary. I will tell you when you can change your host names.
Kubernetes is huge. Really. And if you have no specialization in system administration, you will have pretty often bad times. Knowing my background as a software engineer, this guide took me more than 6 weeks of searches, experimentations, trial and errors, and frustration. I learned a huge lot of things that you will require to learn and understand too if you encounter the same problems than me during your setup.
I don’t have special knowing in neither system security nor load management, so I must have done critical errors in some places; thus, don’t take my words as granted. Take this document series as a global guide to kickstart a setup you must adapt and figure out yourself.
Again, if you’re not super determined in learning a lot, you are putting your systems at risks by trying to use this directly in production.
Please, please do comments, post issues, and make pull requests in order to improve this document serie. I will open source as much prod-ready settings as possible (without compromising my own security), and contributing might improve the performance and safety of all futur readers. So, in advance, thank you.
I’ll assume that:
|
|
|
|
kubectl, kubeadm) v1.20.2 or above.
|
|
Ready ?
