If you're a little bit confused about all of the terminology and tools surrounding containers, or if you're interested in better understanding how to operationalize AKS, I have some thoughts.
Why Containers?
Containers give you an isolated, deployable "box" containing just your application and the dependencies necessary to run your application. This "box" can be shipped anywhere and run, and the application that you boxed up should Just Work. Need a new version of your application? Make a new box and replace the old one.
This gives you a great way to rapidly develop, test, and deploy your application code. But operationalizing it is another story...
Why Kubernetes?
Kubernetes gives you a platform for orchestrating complex multi-container deployments. Kubernetes controls the deployment, isolation, and networking of containers, as well as handling zero-downtime rollout (and rollback), and automatically scaling up to meet demand. This is a must if you're heading down the road of microservice architectures.
However, Kubernetes is no picnic to install and maintain...
Why AKS?
AKS is Kubernetes-as-a-service. Instead of going down the road of creating and installing all of the Kubernetes software on virtual machines, AKS manages creating a Kubernetes instance and the appropriate nodes, as well as automatically handles scaling up and scaling out a Kubernetes deployment to meet your needs. It accelerates the process of getting Kubernetes up and running.
Sounds great! What's challenges are left?
Surprisingly, a lot! Once you have some containers and a Kubernetes cluster running in AKS, there are still gaps left to fill.
- Governance (who has access to Kubernetes? Who has access to the Azure resources? How do these things get created and maintained?)
- Proper deployment and organization of AKS (How many clusters should you have? How big should those clusters be?)
- Automation of build and deploy processes around containers, including versioning and automated testing
- Getting applications containerized
- Getting containers running in Kubernetes according to best practices
Tackling Governance
Governance (i.e. who owns and has access) of AKS and Kubernetes is critical. If you open up Kubernetes to all the developers and ops folks, it's going to quickly get out of control and be unmanageable.- On the Azure side of things, be sure to employ RBAC and Azure Policy to limit access. Ideally, no one makes changes to any Azure infrastructure except via some sort of automation pipeline that's triggered from a code change. No Wild West stuff allowed!
- On the Kubernetes side of things, you can also use its native RBAC to define roles and permissions. A lot of this boils down to how you organize your application workloads across clusters, but a very similar maxim should apply: No one should be changing critical workloads manually.
AKS Cluster Sizing
Cluster sizing and scaling is one of those things that's just as much gut instinct and experience as it is hard numbers. Some general guidelines to follow:- Don't use a single cluster. We like to split workloads up between dev-test and production clusters.
- If you have a very large, very critical application, consider giving that application its very own cluster.
- Start small. AKS makes it easy to scale up and scale out later.
Container Management Strategies
Container management is a huge topic -- I could easily write a series of blog posts just about this topic.- Containers should be versioned. You never want to be deploying an image tagged "latest" to your clusters -- this reduces visibility into your deployment history and limits your ability to roll back.
- Versioning should take place via CI pipelines. No manual tagging. You have a process for building and deploying software (right?) -- use it!
- Build containers for speed. Baseline containers are awesome. Have a big nom or NuGet restore? Build a base image that has those packages already restored. No one wants a container to take 45 minutes to build!
- Build containers for size, too. Don't use an "sdk" container that has build tools on it to run your application (unless you need those tools to run, of course). Use multi-stage containers to build in an SDK container, then copy the outputs to a lean, mean runtime container.
- Don't put secrets in containers. Use key vault. Use environment variables. Use mounted volumes. Anything but hard-coded secrets. Your security auditors will thank you.
General Kubernetes Tips
- Make sure to put resource limits on your pods. They can be high limits, but you don't want one runaway pod to starve your cluster.
- Hook your applications up to App Insights / Azure Monitor. The ability to easily visualize and troubleshoot applications is very valuable.
Closing Thoughts
Entering the world of AKS can feel daunting. There are a lot of new concepts, new tools, and new challenges. It's worth it, it just takes some patience and tenacity.
Learn More...
