Kubernetes is hard. Getting started and set up for the first time can take weeks to get right. Managing deployments on a fleet of Kubernetes clusters on the edge brings even more challenges.
Kubernetes in Codespaces (KiC) is a game-changer
for the end-to-end Kubernetes development lifecycle from a local cluster to deployments on the edge. KiC reduces the initial friction and empowers the developer to get started and deployed to a dev/test environment within minutes. The pre-configured Codespaces environment includes a Kubernetes
cluster and a custom CLI (kic
) that help streamline the initial Kubernetes learning curve.
These labs walks through the rich end-to-end developer experience of KiC. The labs start by walking you through creating, building, testing, and deploying an application on a local cluster running inside Codespaces (inner-loop) with a complete CNCF observability stack (Grafana, Prometheus, and Fluent Bit).
- GitHub Codespaces access
- You should have this as a member of cse-labs/res-edge-labs
- Ping bartr if you have access issues
Codespaces allows you to develop in a secure, configurable, and dedicated development environment in the cloud that works how and where you want it to
- GitHub Codespaces Overview
- GitHub Codespaces is available to all GitHub users and organizations
- For more information, see "GitHub's products"
We use GitHub Codespaces for our inner-loop
and outer-loop
Developer Experiences. While other DevX are available, currently, we only support GitHub Codespaces.
Best Practice: as you begin projects, ensure that you have Codespaces and Azure subscriptions with proper permissions
inner-loop
refers to the tasks that developers do every day as part of their development process- Generally,
inner-loop
happens on the individual developer workstation- For KiC, the inner-loop and developer workstation is Codespaces
- When a developer creates a Codespace, that is their "personal development workstation in the cloud"
- Generally,
- As part of KiC, we have automated the creation of the developer workstation using a repeatable, consistent, Infrastructure as Code approach
- We have an advanced workshop planned for customizing the Codespaces experience for your project
- With the power of Codespaces, a developer can create a consistent workstation with a few clicks in less than a minute
outer-loop
refers to the tasks that developers and DevOps do as they move from dev to test to pre-prod to production- Generally
outer-loop
happens on shared compute outside of the developer workstation - For KiC, outer-loop uses a combination of Codespaces and
dev/test clusters
in Azure
- Generally
- As part of KiC, we have automated the creation of dev/test clusters using a repeatable, consistent, Infrastructure as Code approach
- Create a Codespace from the repo you created. You can use the same Codespace for any of the labs.
Note: make sure you create a codespace from the created repo, not the template repo.
- Click the
<> Code
button- Make sure the Codespaces tab is active
- Click
Create Codespace on main
- After about 5 minutes, you will have a GitHub Codespace running with a complete Kubernetes Developer Experience!
Many of these labs use environment variables, using the export functionality. If you wish, you can edit the kic.env file to persist exported environment variables across terminal sessions. Just add the same "export FOO=BAR" lines to your kic.env file.
code ~/kic.env
# reload kic.env
source "$HOME/kic.env"
The first lab is an inner-loop
lab that introduces Codespaces and the various pre-installed components and tools
The lab is the basis for all future labs, so you should go through the lab a few times until you're comfortable with Codespaces and the tools
- Create a K8s cluster in the Codespace
- Build, deploy, and test a new application
- Deploy a CNCF observability stack
- Fluent Bit (log forwarding)
- Prometheus (metrics)
- Grafana (dashboards)
- Generate and observe synthetic load
- Run and observe load tests
Lab: Introduction to Kubernetes in Codespaces
This lab is a prerequisite for future labs
Resilient Edge (Res-Edge) is a composition of tools designed to streamline application manageability across a highly distributed application platform. The objective is to leverage a small platform team to support a highly distributed ecosystem of clusters and apps. We will step through how Resilient Edge (Res-Edge) addresses the following capabilities:
- Managing Clusters at Scale
- Matching Applications and Clusters
- Configuration Proliferation
- Connectivity
Lab: Deploy Resilient Edge Data Service to Codespaces
- This is work in progress
- run
.devcontainer/deploy-res-edge.sh --force
from the root of the repo - Click on the
Ports
tab - Open port 30080 in your browser
- Login with any valid username and the password
bar
- Login will eventually be integraded with Active Directory
- run
This lab is a prerequisite for the Kustomize lab
- Res-Edge uses
Groups
to allow applying Kubernetes manifests to multipleClusters
at the same time - In order for a
Namespace
and associatedApplication(s)
to deploy to aCluster
, you mustassign
aGroup(s)
to theNamespace
- This lab will demonstrate:
- Assigning the
store Group
to theimdb Namespace
- Running cicd locally
- Reviewing, committing, and pushing the changes to your GitHub repo
- Assigning the
You can do this from the UI by updating the
expression
on theimdb Namespace
to/g/stores
Lab: Assign a Group to a Namespace
Application teams often want to deploy new versions of their app(s) to a growing subset of clusters. Res-Edge uses Kustomize, Groups
, Namespaces
, and Applications
to provide ring deployments
. This lab demonstrates ring deployment using Res-Edge and Kustomize.
Lab: Ring deployment with Res-Edge and Kustomize
Application teams need to register new Namespaces and Applications in the Res-Edge Data Service in order to deploy their apps.
- In this lab, we will register a new Namespace and two new Applications to the Data Service
Lab: Register a new Namespace and Applications
- In this lab, we will use GitOps (Flux) to deploy the Namespaces and Applications assigned to a Cluster
Lab: Deploy via GitOps
This project uses GitHub Issues to track bugs and feature requests. Please search the existing issues before filing new issues to avoid duplicates. For new issues, file your bug or feature request as a new issue.
This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.opensource.microsoft.com.
When you submit a pull request, a CLA bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., status check, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.
This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact [email protected] with any additional questions or comments.
This project may contain trademarks or logos for projects, products, or services. Authorized use of Microsoft trademarks or logos is subject to and must follow Microsoft's Trademark & Brand Guidelines. Use of Microsoft trademarks or logos in modified versions of this project must not cause confusion or imply Microsoft sponsorship. Any use of third-party trademarks or logos are subject to those third-party's policies.