Kubernetes, and the containers within, provide a powerful and intriguing way of organizing high-scale infrastructure. Exposing that infrastructure to the Internet can be a complicated endeavour. Within this article we'll briefly introduce Kubernetes, see how one might expose it to the wild over SSL, then consider a scenario that includes the open-source reverse-proxy Wormhole.
Developed by Google and released as open-source under the Apache License 2.0, Kubernetes is an orchestration framework for containers. Google developed Kubernetes to be portable, extensible and self-healing.
Being portable, Kubernetes can be public, private, cloud-based, multi-cloud, and anywhere it between. It's extensible: it's modular and hackable; you can plunk Kubernetes in configuration management and modify it. Finally, it's self-healing: Kubernetes can place new containers, restart suffering ones and replicate and scale containers when required.
Containers are a big leap in organized and efficient infrastructure deployments. What you might have once done in a 3GB Virtual Machine, you can now accomplish with a 300mb container. Choosing to virtualize from the operating system level instead of from the underlying hardware, containers allow developers to eviscerate the heavy cruft that would become entangled within a deployments' libraries and configurations. Managing a fleet of them can be a challenging task, which is where Kubernetes and Wormhole enter.
Container orchestration is a weighty concept. It refers to managing a cluster of containers by...
- scheduling them
- scaling them horizontally
- replicating instances
- load balancing
- rolling updates
- monitoring resources
- and more!
...There are many, many goodies included in orchestration.
Now that we've at least been introduced to Kubernetes, let's look at how Fly and Wormhole can play a part in exposing your cluster over SSL and simplifying your Kubernetes configuration.
There are many different approaches to Kubernetes hosting and even more ways that you can expose it to the greater Internet. Exposure is the act of taking a cluster that's within a VPC or private premises and making it available via a public-facing IP address.
A typical AWS configuration might look something like this:
You have a single, region-bound VPC. You have a public and private subnet. The public subnet hosts an Elastic Load Balancer that manages SSL certificates and SSL termination, and a NAT host or two. Your private subnet is inhabited by your Kubernetes services and your internal Elastic Load Balancer. You have an Internet Gateway to receive the initial connection, a route-table, a security group, and a Network ACL that manage secure and sane access amongst your subnets, ELBs, and services.
Wormhole was built to slash this complexity and provide an easier way to expose frameworks like Kubernetes to the world. Consider a default VPC wherein your EC2 instance is running Kubernetes. You enable your Internet Gateway so that your VPC is open. Next, you apply a security group, choosing to only allow egress traffic from a port of your choosing. You don't need to accept any ingress traffic. You don't need to wrangle any SSL certificates.
Wormhole is a secure way of connecting two separate endpoints. In this case, you'd circumvent the need for public exposure through AWS and have your Kubernetes endpoints connect through a secure tunnel to the Fly Application Delivery Network. If you use GCP or host on-premises, you can apply the equivalent, limited port-opening procedure to a small set of outbound-only ports.
Our traffic flow now looks like this:
Client connects to the closest Fly edge-server over HTTPS.
SSL terminates. Encrypted backhaul to local Wormhole server.
Local wormhole server -> encrypted tunnel to Wormhole client.
Wormhole client securely tunneled to local Kubernetes end-point, port:80.
Your users enjoy a faster connection to your application. Terminating at the topographically nearest edge-server significantly reduces the penalty of the cumulative SSL-handshake roundtrip. Factor in cacheing and HTTP/2 and things are looking speedy.
An example Kubernetes configuration containing Wormhole looks might look like this:
spec: containers: - name: "sample-app-wormhole" image: "flyio/wormhole:0.5.35" env: - name: FLY_TOKEN valueFrom: secretKeyRef: name: sample-app-secrets key: fly-token - name: FLY_LOCAL_ENDPOINT value: "127.0.0.1:9797" - name: "sample-app" image: "path/to/docker_image:tag" env: - name: PORT value: "9797"
Our Wormhole port is
9797. We'd now ensure that this is the only port that's allowed to leave our VPC via the Security Group. Clean and simple!
... But, we've just attached our Kubernetes cluster to a mysterious thing called Wormhole. Let's see what the other side looks like while running through a Fly site setup, to paint the whole picture.
Upon logging in or creating an account you're asked to create a site. Your first step is to provide a hostname:
onehostname.com. Next, you'd configure a self-hosted site. This leads you into attaching Wormhole to Kubernetes.
Each backend provides a unique
FLY_TOKEN, which we've accounted for in our sample configuration above:
Once Fly begins to detect Wormhole instances, you'll see them arrive within the Backends' page:
Now, the last step is to create an
CNAME DNS record for the hostname that you've associated with your backend. Once configured, your hostname is now attached to Fly through Wormhole, connecting through a secure tunnel to your Kubernetes cluster at the port you specified.
Fly is a global network of intelligent edge-server proxies. You have full control over routing rules, and load balance traffic heading to your cluster with the Power of 2 Random Choices. In addition to Kubernetes, you can host all of your other third-party services like ReadMe.io for
/docs/, GitHub Pages for your marketing site at
/, a Ghost Blog for your
/blog/ - all from one easily configured, SEO-wise hostname.
The best part? No muddling about with exposure rules or excessive SSL load balancing, firewall-ruling, or NAT configurations within your Kubernetes host: GCP, AWS, on-premises -- no matter the host, you can keep your accessibility simply and securely limited.
Fly started when we wondered "what would a programmable edge look like"? Developer workflows work great for infrastructure like CDNs and optimization services. You should really see for yourself, though.