Kubernetes for developers

Follow the recorded Azure portal wizard to configure an AKS cluster, including node pools, identity, networking, and optional integrations. Review how these choices affect cluster access and supporting Azure resources. Treat the demo's simplified access settings as examples, not a production security baseline.

Inspect the AKS-managed resource group in the Azure portal to identify node instances, managed identities, the load balancer, and networking resources. Retrieve the cluster credentials with Azure CLI and use kubectl to list nodes, relating their addresses and configuration back to the portal.

Inspect existing namespaces and system workloads before creating an NGINX Pod. Generate a Pod manifest with kubectl run in client dry-run mode, review its metadata and container specification, then apply the YAML and inspect the running Pod's IP address and assigned node.

Generate and apply an NGINX Deployment manifest using kubectl, with a desired replica count instead of a standalone Pod. Examine the Deployment's selectors and Pod template, then list Deployments and Pods to inspect the resulting replicas, their addresses, and their placement across nodes.

Open an interactive shell inside the NGINX container using kubectl exec and inspect its Linux filesystem. Run curl from that shell to reach another Pod by its cluster IP address, using the demo to explore Pod-to-Pod connectivity and the role of network policies in restricting it.

Change the NGINX Deployment's replica count with kubectl scale and observe Kubernetes adding or removing Pods. Verify the results with Deployment and Pod listings, while distinguishing this manual workload scaling from changing the number of virtual machines in the cluster.

Generate and apply a ClusterIP Service for the NGINX Deployment, matching its selector to the Pods' labels. Inspect the Service endpoints with kubectl describe, then use its DNS name from another Pod to reach the application without depending on an individual Pod's changing IP address.

Use kubectl edit to change the existing NGINX Service from ClusterIP to LoadBalancer. Watch for its external IP address, compare the public endpoint with the retained cluster IP, and open the NGINX page from a browser to verify access from outside the cluster.

Review the created Services, Deployments, and Pods through the AKS views in the Azure portal, including namespace filtering. Inspect the managed resource group and load balancer frontend configuration to connect the public Kubernetes Service with the Azure public IP resource created for it.

Follow the recorded Visual Studio project-creation workflow to start the ASP.NET Core MVC application used in the course. Select the MVC template with Linux Docker support, examine the generated project, and run the starter site locally before adding the product features.

Create a Product model with identifier and name properties, then use Visual Studio's MVC scaffolding with Entity Framework to generate a controller and views. Configure the model and data context selections, and see how the generated pieces support create, read, update, and delete operations.

Run the scaffolded MVC app and exercise its product-list, create, edit, details, and delete pages. Update the shared layout to add a Products navigation link, then correct the controller reference and verify that the menu opens the intended view.

Open the linked ProductsStoreOnKubernetes GitHub repository to obtain the application source. Explore it alongside the demonstrations to relate the MVC app to the container and Kubernetes deployment workflow.

Walk through the generated multi-stage Dockerfile for the MVC app in the recorded project. Understand how the SDK stage restores dependencies and builds the application, how publishing prepares the deployable files, and how the final runtime image starts the app through its entry point.

Build a Docker image for the MVC app using the recorded VS Code Docker command-palette workflow. Adjust the Dockerfile's build-context paths and exposed port, run the resulting image with port mapping, and check the application in a local browser.

Tag the MVC application's image with a Docker Hub account namespace using the recorded VS Code command-palette workflow. Push the tagged image to Docker Hub, then check the repository and image tag in the registry so the image can be referenced by Kubernetes.

Review the roles of kubectl and minikube in the recorded local Kubernetes setup. Follow the demonstrated startup and Dashboard launch sequence to understand how the local cluster is prepared before deploying the app; installation details and interfaces may differ in current tooling.

Follow the recorded Kubernetes Dashboard form to deploy the MVC image from Docker Hub with multiple replicas and a Service. Change the pending LoadBalancer Service to NodePort for the local setup, open the web app, and identify why its Products page still needs a database.

Adapt a sample Deployment manifest in VS Code to reference the published MVC image, its tag, labels, and desired replicas. Apply the YAML with kubectl and compare the resulting Deployment and Pod status in the command line and the Dashboard shown in the recording.

Add a NodePort Service to the MVC Deployment file as a separate YAML document. Match the selector to the app's labels, configure the Service and target ports, then apply the manifest and use the local cluster address and node port to reach the web app.

Create a SQL Server Deployment and NodePort Service from YAML in the recorded local-cluster demo. Review the required startup environment variables, apply the manifest with kubectl, and test connectivity using SQL Operations Studio; persistent storage and improved credential handling are introduced in later lessons.

Override the MVC app's database connection string through a Deployment environment variable rather than rebuilding the image. Use ASP.NET Core's double-underscore configuration convention and the SQL Server Service name, then verify that product records are created and visible in the database.

Define a local hostPath PersistentVolume and matching PersistentVolumeClaim, then mount the claim into the SQL Server container. Follow the recorded minikube workflow to move database files outside the container's writable layer and observe the application using the newly mounted storage.

Extract the demo's connection-string configuration into a ConfigMap and reference its key with configMapKeyRef in the MVC Deployment. Apply the configuration and updated Deployment, inspect the stored values, and verify the app; recognize that ConfigMaps hold plain-text configuration rather than protecting credentials.

Create a Secret manifest for the demo connection string and reference it through secretKeyRef in the MVC Deployment. Apply the Secret before the dependent workload and verify the app can read its configuration. Understand that base64 encodes the value; it does not encrypt it.

Follow the recorded Azure portal workflow for creating the AKS cluster used to host the MVC app and SQL Server containers. Review cluster and node settings, authentication choices, and monitoring options, then inspect the resources created for the application migration.

Follow the historical AKS connection workflow shown in the Azure portal, using Azure CLI sign-in, az aks get-credentials, and the recorded Dashboard access command. Check the active Kubernetes context and list nodes with kubectl, distinguishing the demonstrated Dashboard integration from current cluster-access options.

Use kubelogin to convert kubeconfig for an Azure AD-integrated AKS cluster and authenticate through an existing Azure CLI session. Inspect the resulting exec-based configuration, verify access with kubectl, and compare the additional service-principal and managed-identity authentication approaches discussed for automation.

Adapt the local storage manifest to the recorded AKS workflow by defining an Azure Disk StorageClass and a PersistentVolumeClaim. Trace how the claim selects the storage class and how its name must match the SQL Server Deployment's volume reference.

Prepare a separate Azure-oriented manifest for the MVC app by changing its Service from NodePort to LoadBalancer and removing the nodePort setting. Compare the local and AKS files to see how external access configuration changes while the application container remains the same.

Check that kubectl targets the AKS context before applying the storage manifest, respecting the application's deployment dependencies. Inspect the PersistentVolumeClaim from the command line, then find the provisioned Azure Disk in the managed resource group through the Azure portal.

Apply the existing Secret manifest to the AKS cluster with kubectl before deploying the MVC app that depends on it. Verify the Secret object was created using the command line and the Dashboard shown in the recording.

Deploy the SQL Server manifest to AKS using kubectl apply. Inspect the Deployment's status from the command line and the recorded Dashboard, distinguishing resource creation from workload readiness while the container image is downloaded and started.

Apply the Azure-specific MVC manifest to create the web Deployment and its LoadBalancer Service in AKS. Check Deployment and Service status with kubectl and the recorded Dashboard while the application image starts and external access is provisioned.

Open the deployed MVC app through its Service endpoint and create a product to exercise the database connection. Trace the configured SQL Server Service name, Secret-based connection string, and mounted Azure Disk to understand how the web and database workloads fit together in AKS.

Deploy an NGINX DaemonSet and inspect how its Pods are distributed across eligible AKS worker nodes. Investigate why a tainted system node is skipped, add a matching toleration, and reapply the manifest to observe the DaemonSet extending to that node.

Compare StatefulSets with Deployments, DaemonSets, and standalone Pods, focusing on stable Pod identities and stateful workloads. Examine a SQL Server manifest that combines a headless Service with volumeClaimTemplates for per-Pod storage, while recognizing that database replication requires separate application-level configuration.

Deploy the demonstrated web app and SQL Server StatefulSet, then inspect the headless Service, storage claims, and Azure Disks. Use kubectl exec and DNS lookups to examine database files and Pod identities, and scale the StatefulSet to observe ordered Pod creation and separate storage claims, not automatic database replication.

Explore how pods and automation use Kubernetes service accounts to access the API server. Learn how a Role defines allowed resources and verbs, how a RoleBinding assigns those permissions within a namespace, and why a workload identity does not automatically grant API access.

Compare password-based service principals, managed identities, and OIDC-based workload identity for applications accessing Azure resources. Trace the service account and token-exchange flow, and understand why avoiding stored application passwords is different from simply placing credentials in a Kubernetes Secret.

Follow the recorded AKS demo connecting a Kubernetes service account to a user-assigned managed identity through an OIDC federated credential. See how a Go application uses Microsoft Authentication Library to read an Azure Key Vault secret, with access granted separately through the demo's Key Vault access policy.

Prepare the application's source code and Kubernetes YAML manifests for automated pipelines by publishing them to GitHub. Follow the Git initialization, staging, commit, remote-linking, and push workflow, then reorganize deployment files at the repository root.

Configure a classic Azure DevOps build pipeline that retrieves the project from GitHub and builds its Docker image. Connect to Docker Hub through a registry service connection, then use the same build-specific image tag for both the build and push tasks.

Pass Kubernetes deployment manifests from the build pipeline to the release pipeline using a published build artifact. Select the Azure-specific YAML files, copy them into the artifact staging directory, and publish that directory as the drop artifact for later deployment.

Keep the deployment manifest aligned with the image produced by each build instead of leaving an older tag hard-coded. Configure the demonstrated Replace Tokens extension to substitute the build ID in the target YAML file before copying and publishing the release artifact.

Create a classic Azure DevOps release pipeline that consumes the build pipeline's published YAML artifact. Configure the Azure connection, resource group, AKS cluster, and target namespace, then use the Kubernetes task to apply configuration files from the downloaded drop artifact.

Refine the release pipeline into separate kubectl apply tasks for individual manifest files. Follow the demonstrated dependency order for configuration, secrets, storage, database, and web application resources, and give each task a clear name to make the deployment workflow easier to inspect.

Trace an application change from Git commit and push through the configured build and release pipelines. Inspect the new registry image and deployed Kubernetes resources, then open the application's public endpoint and add a product to check the web application's database connection.