In part one, we created a service and we learned how to connect to our service from inside the cluster, and how to connect to it from outside the cluster with with port forwarding - how would we go about exposing this service on the Internet?
The answer is a Kubernetes resource called an Ingress, which describes how traffic gets into your cluster and which services traffic gets routed to. There are lots of different kinds of Ingress to choose from - you get to pick one and install it on your cluster. What an Ingress looks like in terms of network architecture will depend very much on which Ingress you choose.
If you were to install ingress-nginx, for example, then your ingress would consist of nginx running in several pods within your cluster (and then some method for getting all inbound traffic to those nginx pods, so it can distribute it to your services). Traefik-ingress is another popular choice, because of it’s built in support for fetching certificates from LetsEncrypt. In this tutorial, we’re going to use AWS and EKS, so we’re going to go the simple route and install the AWS load balancer controller, which will create ALBs for our ingress traffic.
In order to do that, we’re going to set up a cluster on AWS’s EKS service, then we’re going to learn probably more than we want to know about security and Service Accounts, and we’ll learn how to set up an Ingress. We’ll also look at how to automatically configure a DNS entry for our service in Route 53 and setup SSL with a certificate from AWS.
This series is a practical introduction to Kubernetes and Amazon’s EKS. I come from the developer side of things, rather than the ops side of things, so this is written from that perspective. In this first tutorial, we’re going to discuss some basic Kubernetes concepts and play around with a local cluster running in a VM. This tutorial assumes you are already somewhat familiar with Docker - if you know how to write a Dockerfile, and run an application in Docker, (or at least understand what those concepts are) you should be good.
In this post, we’re going to develop a state management library for React, which is similar in many ways to the popular MobX library, but which uses immutable data structures. The upside is that this library is increadibly small and easy to use, and you don’t need to worry about wrapping your React components with
I’ve spent some time playing with a couple of different tools for organizing my MP3 collection. If you have a large music collection, you probably have some old songs in there you ripped from CDs, and they might have some metadata that’s not quite up-to-snuff. There’s probably some spelling mistakes in there, and maybe you have some files where the artist is “Blink 182” and some are “blink-182” - things like this. What we want is some automated way of fixing all this metadata, and sorting files into the correct folder based on their metadata. Beets is very popular program for this, but it’s not being actively maintained. MusicBrainz Picard has a nice UI and is pretty easy to use.
The Synology now comes with a built in “Let’s Encrypt” client, but unforunately it only supports HTTP-01 challenge, which means if you want to use it you need to open up your Synology to the Internet. The Internet is a scary place, so we’re going to use the DNS-01 challenge to validate we own our domain name.
subscribe via RSS