Kubernetes can be overwhelming for developers with a lot of new concepts to go through. To simplify application deployment on Kubernetes, we’re building an experience that brings together a set of tools and AKS add-ons to help you get from source code to running on an Azure Kubernetes Service (AKS) cluster using familiar tools and environments like Visual Studio Code, GitHub, and the Azure portal.
Let’s take a look.
What does it take to run an app on Kubernetes?
If you think about it, if you start from a source code of an application, say a microservice, that you want to run on Kubernetes, there are a number of steps and prerequisites:
- Have a development environment setup for your application language and framework of choice, container, and Kubernetes development. At minimum, you probably need to have Docker installed as well as the Kubernetes CLI (kubectl) in addition to some programming language specific tooling like Go, Nodejs, or .NET.
- Build and push a container image for the application. To do so, you must write a Dockerfile, which is a set of instructions to tell Docker how to package your application source code or binaries into a container image in a secure manner and according to best practices.
- Get access to a Kubernetes cluster, likely your team’s dev/test environment and write Kubernetes manifest files (YAML) to create a Deployment. You’ll need to write that file to pull images from the container registry you pushed that container image to. You’ll also need to create a Service so that Kubernetes is able to direct traffic to the pods that form your deployment.
- If you are to access this application through secure SSL/TLS endpoints, you’ll have to configure an Ingress and set it up to load your certificates through a Kubernetes Secret in addition to setting up some form of DNS resolution to be able to load the application with a nice hostname.
If you’ve done all that, I have news for you, you’re just barely getting started. When it comes to your inner developer loop on Kubernetes, you’ll either have to clone the entire application and its dependencies on your machine to iterate locally, which may be fine for small apps but can be unreasonable or even impossible for moderately complex apps, or you’ll have to resort to building and pushing a new container image for every change, which will significantly slow you down.
Beyond that, you’ll need to create a continuous integration/continuous deployment (CI/CD) pipeline to automate the building and deployment of your application across your development, staging, and production clusters.
Is there a better way?
We've been building a set of interconnected experiences to help land you in the pit of success when you're just getting started with application development on Kubernetes.
Now let’s breakdown how each of those tools and experiences work.
Inner-loop developer experience
GitHub Codespaces
GitHub Codespaces are blazing fast, cloud-powered containerized developer environments for any activity - whether it's a long-term project, or a short-term task like reviewing a pull request with up to 32 cores and 64 GB RAM. You can work with these environments from Visual Studio Code or in a browser-based editor.
Most importantly, GitHub Codespaces are fully customizable on a per project basis and they help reduce on-boarding friction by giving a standardized development environment. You can standardize things such as build tools, runtime requirements, hardware specs, extensions, and editor settings all in configuration that can be checked into your source code’s repository allowing new developers to get set up and running quickly.
You can create a GitHub Codespaces configuration that includes tools like Docker, the Kubernetes CLI (kubectl), the Azure CLI (az), Visual Studio Code extensions, and the build tools that you need for that particular project like npm, gradle, maven, or dotnet by specifying them in the .devcontainer configuration in your repository. This means that when you launch the code space, you’re good to go. You don’t need to install dependencies on your developer machine to build and run the code.
Visual Studio Code and extensions
Through the Azure extension, the Kubernetes extension, and the AKS developer extension for Visual Studio Code, you can be much more productive in a familiar environment while minimizing distractions and context switching. And the beauty of this is that you can have all these extensions pre-installed in your GitHub Codespaces environment.
The extension is aware of your Azure subscription context including AKS clusters, Azure Container Registries, and Azure Key Vaults. It is also aware of what’s running on your Kubernetes cluster such as namespaces and services. Having this context enables it to do smarter code generation. Here are some of the things you can do today through Visual Studio Code and AKS developer extension.
- Draft a Dockerfile for your application code
- Build a container image using Azure Container Registry
- Draft Kubernetes deployment and service manifests
- Draft a Kubernetes ingress that uses the Web App Routing add-on with Azure DNS and Azure Key Vault integration
- Draft a CI/CD workflow using GitHub Actions
We are also working on adding additional code generation and configuration options.
Draft
Draft is the open-source tool that is powering the code generation engine behind the Visual Studio Code extension. We created Draft with extensibility in mind through an add-on model to allow anyone to create templates for their needs. We’re excited to be working with the community to add more templates and Kubernetes resource generation options.
Bridge to Kubernetes
We created Bridge to Kubernetes as an open-source tool that works with Visual Studio, Visual Studio Code, GitHub Codespaces, as well as a standalone command line with speed and flexibility of local debugging in mind. You run your code natively in your development environment while connected to a Kubernetes cluster to test your code changes in the context of the larger application without having to deploy all the application dependencies locally. You also don’t need to build, push, and deploy a new container image for each code change. Bridge to Kubernetes has built-in routing capabilities to isolate your development traffic and only redirect requests to your development environment. This helps multiple team members to develop in isolation while avoiding disrupting other traffic in the cluster.
Continuous integration/continuous deployment (CI/CD)
Automated deployments
Automated deployments simplify the process of setting up a GitHub Action and creating an automated workflow for your code releases to your Azure Kubernetes Service (AKS) cluster. Once connected, every new commit will kick off the workflow. Setting up automated deployments through the Azure portal takes care of configuring the required permissions to allow the GitHub Actions workflow to build and push container images to your Azure Container Registry as well as to the AKS cluster.
GitHub Actions for Kubernetes
GitHub Actions connects all of your tools to automate every step of your development workflow. A workflow is an automated process that you set up in your GitHub repository. You can build, test, package, release, or deploy any project on GitHub with a workflow. With GitHub Actions for Azure, you can create workflows that you can set up in your repository to build, test, package, release, and deploy to Azure. GitHub Actions for Azure supports Azure services.
We created a set of GitHub Actions for Kubernetes that integrate with Azure Kubernetes Service and can help you automate things like baking Kubernetes manifest files, creating Kubernetes secrets, deploying Kubernetes manifests, and doing artifact substitution. The deploy Kubernetes manifest action even supports strategies for basic, canary, and blue-green deployments. When you use Draft, the Visual Studio Code extension, or the Azure portal to generate a deployment workflow, you are using these GitHub Actions to get the work done.
Unified GitOps on cloud and edge at scale
Regardless of where you run your Kubernetes clusters, on Azure Kubernetes Service (AKS) or on the edge, you can use GitOps to get a consistent deployment and workload management experience. With GitOps, you declare the desired state of your Kubernetes clusters in files in Git repositories. Kubernetes controllers run in the clusters and continually reconcile the cluster state with the desired state declared in the Git repository.
GitOps applies development practices like version control, collaboration, compliance, and continuous integration/continuous deployment (CI/CD) to infrastructure automation. Azure provides configuration management capability using GitOps in Azure Kubernetes Service (AKS) and Azure Arc-enabled Kubernetes clusters.
Because Azure Resource Manager (ARM) manages your configurations, you can automate creating the same configuration across all Azure Kubernetes Service and Azure Arc-enabled Kubernetes resources using Azure Policy, within the scope of a subscription or a resource group. This at-scale enforcement ensures that specific configurations will be applied consistently across entire groups of clusters.
Where do we go from here?
We will continue building tools and integrations to simplify your getting started experience, but we’d also like to hear from you what would you like to see to help you beyond just getting started on day zero and increase your productivity for days 2 and beyond.
Please leave a comment below or reach out over the discussion forum with your questions and feedback.
Join us on November 15th, 2022, for Ask the Experts: Discover, innovate, and scale with Azure Kubernetes as Microsoft experts Brendan Burns (co-founder of Kubernetes), Bridget Kromhout, Sean McKenna, Jorge Palma, Rita Zhang, and Lachie Evenson discuss containers, Kubernetes, and the future of cloud-native application development.
In case you missed it, take a look at what we announced at KubeCon 2022 North America.