Windows in Kubernetes Quiz

This quiz tests your conceptual and practical knowledge about managing Windows nodes and workloads in Kubernetes. It covers topics such as Windows container basics, Windows node configuration in Kubernetes, networking, storage, security, and monitoring.

Multiple Choice Questions

What container runtimes are supported for Windows nodes in Kubernetes?
- A) Docker and containerd
- B) CRI-O and Docker
- C) containerd and CRI-O
- D) Docker, containerd, and gVisor

Show Answer

Answer: A) Docker and containerd

Explanation: The officially supported container runtimes for Windows nodes in Kubernetes are Docker and containerd.

Docker: Docker was the traditional option for running Windows containers on Windows. However, Docker support in Kubernetes is gradually decreasing, and transitioning to containerd is recommended.
containerd: This is the currently recommended container runtime for Windows nodes. containerd is a lightweight and stable runtime that has official support for Windows nodes in Kubernetes 1.20 and later.

CRI-O is not officially supported on Windows nodes. CRI-O is primarily a Container Runtime Interface (CRI) implementation for Linux containers.

gVisor is a sandbox runtime for container isolation but is not currently supported on Windows nodes.

When setting up container runtimes on Windows nodes, it's important to verify compatibility with the Kubernetes version.

What network solution is required when configuring a cluster with mixed Windows and Linux nodes in Kubernetes?
- A) All CNI plugins support both Windows and Linux nodes
- B) CNI plugins that support Windows, such as Flannel, Calico, and Antrea
- C) Windows nodes must use only kubenet without CNI plugins
- D) Windows nodes must always use host network mode only

Show Answer

Answer: B) CNI plugins that support Windows, such as Flannel, Calico, and Antrea

Explanation: When configuring a cluster with mixed Windows and Linux nodes in Kubernetes, you must use specific CNI (Container Network Interface) plugins that support Windows. Not all CNI plugins support Windows.

The main CNI plugins that support Windows nodes are:

Flannel: Supports Windows nodes in overlay network mode (vxlan).
Calico: Provides support for Windows nodes, supporting both BGP mode and VXLAN mode.
Antrea: Provides support for Windows nodes, using OVS (Open vSwitch).

Additionally, Azure CNI, OVN-Kubernetes, and others support Windows nodes.

Considerations when setting up CNI plugins on Windows nodes:

Windows nodes have a different networking stack than Linux nodes.
Some networking features may be limited on Windows.
You should verify the Windows support version and configuration requirements of the CNI plugin.

kubenet is not supported on Windows nodes, and Windows nodes cannot use host network mode (HostNetwork=true is not supported for Windows pods).

What is the default isolation mode for Windows containers?
- A) Hyper-V isolation
- B) Process isolation
- C) Virtual machine isolation
- D) Sandbox isolation

Show Answer

Answer: B) Process isolation

Explanation: The default isolation mode for Windows containers is Process Isolation. In this mode, Windows containers share the host operating system's kernel, and each container runs as an isolated process group.

Characteristics of process isolation mode:

Must use the same kernel version as the host OS.
Lower resource usage and faster startup time.
Similar to the typical isolation model of Linux containers.

Windows also provides an alternative isolation mode called Hyper-V Isolation:

Each container runs in a lightweight virtual machine.
Can use different kernel versions than the host OS.
Provides a higher level of isolation but has more overhead.

To use Hyper-V isolation in Kubernetes, add the following annotation to the pod spec:

yaml

annotations:
  io.kubernetes.cri-containerd.isolation: hyperv

Virtual machine isolation is not an official isolation mode for Windows containers, and sandbox isolation is not a term used for Windows containers.

Which of the following is NOT a correct limitation when using Windows nodes in Kubernetes?
- A) Cannot use privileged containers
- B) Cannot use HostPath volumes
- C) Only some SecurityContext features are supported for pods
- D) Cannot share pod network namespace

Show Answer

Answer: B) Cannot use HostPath volumes

Explanation: HostPath volumes can be used on Windows nodes. Therefore, the statement "Cannot use HostPath volumes" is incorrect.

When using HostPath volumes on Windows nodes, you must follow the Windows path format:

yaml

volumes:
- name: data
  hostPath:
    path: C:\\data

The actual limitations when using Windows nodes in Kubernetes are:

Privileged containers: Privileged containers cannot be used on Windows nodes. This is because there is no equivalent concept to Linux's privileged mode on Windows.
SecurityContext limitations: Only some SecurityContext features are supported on Windows nodes. For example, runAsUser, runAsGroup, fsGroup, seccomp, SELinux, etc. are not supported.
Pod network namespace sharing: Network namespaces cannot be shared between pods on Windows nodes. This affects hostNetwork: true, dnsPolicy: ClusterFirstWithHostNet, localhost communication between containers in a pod, etc.

Other limitations of Windows nodes:

If you want DaemonSets to run on all nodes (Linux and Windows), you must use nodeSelector.
Some storage drivers and volume types may be limited.
Linux-specific alpha/beta features may not work on Windows nodes.

What node label is used to identify Windows nodes in Kubernetes?
- A) kubernetes.io/os=windows
- B) beta.kubernetes.io/os=windows
- C) node.kubernetes.io/windows=true
- D) kubernetes.io/windows=enabled

Show Answer

Answer: A) kubernetes.io/os=windows

Explanation: The standard node label used to identify Windows nodes in Kubernetes is kubernetes.io/os=windows. This label indicates the node's operating system type and is used by the Kubernetes scheduler to place pods on appropriate nodes.

To schedule Windows pods to Windows nodes, use nodeSelector as follows:

yaml

nodeSelector:
  kubernetes.io/os: windows

Or you can use node affinity:

yaml

affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/os
          operator: In
          values:
          - windows

beta.kubernetes.io/os=windows was used in previous versions of Kubernetes but is now deprecated.

node.kubernetes.io/windows=true and kubernetes.io/windows=enabled are not standard Kubernetes labels.

Note: Linux nodes have the kubernetes.io/os=linux label.

What is the default base image used when pulling container images on Windows nodes?
- A) mcr.microsoft.com/windows/servercore
- B) mcr.microsoft.com/windows/nanoserver
- C) mcr.microsoft.com/dotnet/framework/runtime
- D) mcr.microsoft.com/powershell

Show Answer

Answer: A) mcr.microsoft.com/windows/servercore

Explanation: The most common base image for Windows containers is mcr.microsoft.com/windows/servercore. This image is based on a Windows Server Core installation and includes the core components needed to run most Windows applications.

The main base images available for Windows containers are:

Windows Server Core (mcr.microsoft.com/windows/servercore):
- Medium-sized image (approximately 2-4GB)
- Supports most Windows applications
- Includes .NET Framework, PowerShell, etc.
- Most widely used Windows base image
Nano Server (mcr.microsoft.com/windows/nanoserver):
- Very small image (approximately 100-200MB)
- Limited Windows API support
- Suitable for .NET Core applications
- Minimal attack surface
.NET Framework (mcr.microsoft.com/dotnet/framework/runtime):
- Image for .NET Framework applications
- Based on Server Core
- Includes specific versions of .NET Framework
PowerShell (mcr.microsoft.com/powershell):
- Image for running PowerShell scripts
- Available in Nano Server or Server Core based versions

When selecting a Windows container image, consider:

Application requirements (required Windows APIs)
Image size and startup time
Security requirements
Windows version compatibility (check version number in image tag)

Windows container images must be the same version as or compatible with the host OS.

What is the recommended method for deploying DaemonSets in a cluster with mixed Windows and Linux nodes in Kubernetes?
- A) Use a single DaemonSet and deploy to all nodes
- B) Create separate DaemonSets for each OS and use nodeSelector
- C) Use StatefulSet instead of DaemonSet for Windows nodes
- D) Add tolerations to all DaemonSets

Show Answer

Answer: B) Create separate DaemonSets for each OS and use nodeSelector

Explanation: The recommended method for deploying DaemonSets in a cluster with mixed Windows and Linux nodes in Kubernetes is to create separate DaemonSets for each OS and use nodeSelector.

Reasons why this approach is necessary:

Windows containers and Linux containers use different image formats.
The same application may require different configurations for each OS.
Some features may only be available on specific OSes.

Windows DaemonSet example:

yaml

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: windows-agent
spec:
  selector:
    matchLabels:
      app: monitoring-agent
  template:
    metadata:
      labels:
        app: monitoring-agent
    spec:
      nodeSelector:
        kubernetes.io/os: windows
      containers:
      - name: agent
        image: contoso/windows-monitoring-agent:v1

Linux DaemonSet example:

yaml

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: linux-agent
spec:
  selector:
    matchLabels:
      app: monitoring-agent
  template:
    metadata:
      labels:
        app: monitoring-agent
    spec:
      nodeSelector:
        kubernetes.io/os: linux
      containers:
      - name: agent
        image: contoso/linux-monitoring-agent:v1

Using a single DaemonSet may cause pods to fail to start on some nodes due to container image compatibility issues.

DaemonSets can be used on Windows nodes, so there is no need to replace them with StatefulSets.

Adding tolerations to all DaemonSets can help schedule pods on tainted nodes, but it does not solve OS compatibility issues.

Which statement about DNS configuration for pods on Windows nodes is correct?
- A) DNS configuration is not supported on Windows nodes
- B) Windows nodes must use Windows DNS Server instead of CoreDNS
- C) Windows nodes can use the same DNS configuration as Linux nodes
- D) Windows nodes require separate DNS server configuration for each pod

Show Answer

Answer: C) Windows nodes can use the same DNS configuration as Linux nodes

Explanation: Windows nodes can use the same DNS configuration as Linux nodes. Kubernetes DNS service (typically CoreDNS) works the same way for Windows pods.

DNS configuration for Windows pods:

Configuration equivalent to /etc/resolv.conf is automatically created inside Windows pods.
Pods can use the cluster's DNS service (CoreDNS) to resolve service names.
The dnsPolicy and dnsConfig fields can be used to configure DNS settings.

Example:

yaml

apiVersion: v1
kind: Pod
metadata:
  name: windows-pod
spec:
  nodeSelector:
    kubernetes.io/os: windows
  containers:
  - name: windows-container
    image: mcr.microsoft.com/windows/servercore:ltsc2019
    command:
    - powershell.exe
    - -Command
    - "Start-Sleep -Seconds 3600"
  dnsPolicy: ClusterFirst
  dnsConfig:
    nameservers:
    - 8.8.8.8
    searches:
    - example.com
    options:
    - name: ndots
      value: "5"

Considerations when using DNS on Windows nodes:

DNS client behavior inside Windows containers may be slightly different from Linux.
Some DNS-related tools (e.g., nslookup, Resolve-DnsName) are available by default in Windows containers.
You should verify that the network plugin correctly supports DNS resolution.

There is no need to configure a separate DNS server or use Windows DNS Server on Windows nodes. Kubernetes' standard DNS mechanism works for Windows pods.

Which statement about pod-to-pod communication on Windows nodes is correct?
- A) Pod-to-pod communication is not supported on Windows nodes
- B) Pods on Windows nodes can only communicate with pods on the same node
- C) Pods on Windows nodes cannot communicate with pods on Linux nodes
- D) Pods on Windows nodes can communicate with all other pods through CNI plugins

Show Answer

Answer: D) Pods on Windows nodes can communicate with all other pods through CNI plugins

Explanation: Pods on Windows nodes can communicate with all other pods in the cluster through appropriate CNI (Container Network Interface) plugins. This includes pods on the same Windows node, pods on other Windows nodes, and pods on Linux nodes.

Key characteristics of pod-to-pod communication on Windows nodes:

Pods on Windows nodes can discover and access services in the cluster by name.
Pods on Windows nodes are assigned unique IP addresses within the cluster IP address range.
Pod-to-pod communication occurs according to the implementation of the selected CNI plugin.

CNI plugins that support pod-to-pod communication on Windows nodes:

Flannel (VXLAN mode)
Calico
Antrea
Azure CNI
OVN-Kubernetes

For example, when using Flannel:

Pods on Windows nodes communicate with pods on other nodes through VXLAN encapsulation.
Each pod is assigned an IP address within the cluster CIDR range.
Routing tables are configured to route pod IP addresses to the appropriate nodes.

Considerations for pod-to-pod communication on Windows nodes:

Some advanced networking features may be limited on Windows.
NetworkPolicy support may vary depending on the CNI plugin.
Windows firewall rules should not interfere with pod communication.

Pods on Windows nodes can communicate perfectly with pods on Linux nodes, which is one of Kubernetes' core features.

Which statement about resource limits for Windows containers in Kubernetes is correct?
- A) Windows containers do not support resource limits
- B) CPU limits are supported but memory limits are not
- C) Memory limits are supported but CPU limits are not
- D) Both CPU and memory limits are supported

Show Answer

Answer: D) Both CPU and memory limits are supported

Explanation: Windows containers in Kubernetes support both CPU and memory resource limits. Windows nodes can limit and request container resources in a similar way to Linux nodes.

Example of resource limits for Windows containers:

yaml

apiVersion: v1
kind: Pod
metadata:
  name: windows-resource-demo
spec:
  nodeSelector:
    kubernetes.io/os: windows
  containers:
  - name: windows-container
    image: mcr.microsoft.com/windows/servercore:ltsc2019
    resources:
      requests:
        memory: "128Mi"
        cpu: "100m"
      limits:
        memory: "256Mi"
        cpu: "500m"

Characteristics of resource management for Windows containers:

CPU limits: Windows implements CPU sharing and limits to manage CPU resource allocation between containers.
Memory limits: Windows limits memory usage of containers and performs OOM (Out of Memory) termination when exceeded.
Resource monitoring: kubelet monitors resource usage of Windows containers and reports to the Kubernetes API.

Considerations for resource management of Windows containers:

Default resource overhead for Windows containers may be greater than Linux containers.
The exact implementation of resource limits may vary depending on the Windows version.
Setting memory limits too low may prevent Windows containers from working properly.
Additional resource overhead occurs when using Hyper-V isolation mode.

You can monitor resource usage on Windows nodes using kubectl top pods and kubectl top nodes commands.

## Short Answer Questions

Explain the main steps and requirements for adding Windows nodes to a Kubernetes cluster.

Show Answer

Answer:

Steps for Adding Windows Nodes to a Kubernetes Cluster:

Verify Prerequisites:
- Kubernetes version 1.14 or later (latest version recommended)
- Control plane must run on Linux nodes
- Windows Server 2019 or later (Windows Server 2022 recommended)
- Compatible CNI plugin (Flannel, Calico, Antrea, etc.)

Configure Networking:

Install CNI plugin that supports Windows nodes
Configure cluster CIDR and service CIDR

Example (Flannel configuration):

yaml

kind: ConfigMap
apiVersion: v1
metadata:
  name: kube-flannel-cfg
  namespace: kube-system
data:
  cni-conf.json: |
    {
      "name": "cbr0",
      "plugins": [
        {
          "type": "flannel",
          "delegate": {
            "hairpinMode": true,
            "isDefaultGateway": true
          }
        },
        {
          "type": "portmap",
          "capabilities": {
            "portMappings": true
          }
        }
      ]
    }
  net-conf.json: |
    {
      "Network": "10.244.0.0/16",
      "Backend": {
        "Type": "vxlan",
        "VNI": 4096,
        "Port": 4789
      }
    }

Prepare Windows Node:

Install and update Windows Server

Enable required Windows features:

powershell

Install-WindowsFeature -Name Containers
Restart-Computer -Force

Install container runtime (containerd recommended):

powershell

# Download and install containerd
curl.exe -L https://github.com/containerd/containerd/releases/download/v1.6.8/containerd-1.6.8-windows-amd64.tar.gz -o containerd.tar.gz
tar.exe xvf containerd.tar.gz
mkdir -p $env:ProgramFiles\containerd
Copy-Item -Path ".\bin\*" -Destination "$env:ProgramFiles\containerd" -Recurse -Force

# Register containerd service
& $env:ProgramFiles\containerd\containerd.exe config default | Out-File $env:ProgramFiles\containerd\config.toml -Encoding ascii
# Edit configuration file (add Windows-related settings)

# Register and start service
& $env:ProgramFiles\containerd\containerd.exe --register-service
Start-Service containerd

Install kubelet and kube-proxy:

Download Kubernetes binaries:

powershell

curl.exe -L https://dl.k8s.io/v1.26.0/kubernetes-node-windows-amd64.tar.gz -o kubernetes-node-windows-amd64.tar.gz
tar.exe xvf kubernetes-node-windows-amd64.tar.gz
mkdir -p $env:ProgramFiles\Kubernetes\bin
Copy-Item -Path "kubernetes\node\bin\*" -Destination "$env:ProgramFiles\Kubernetes\bin" -Recurse -Force

Create kubelet configuration file:

powershell

New-Item -Path "$env:ProgramFiles\Kubernetes\kubelet-config.yaml" -ItemType File -Force
# Add configuration file contents

powershell

& $env:ProgramFiles\Kubernetes\bin\kubelet.exe --windows-service --config=$env:ProgramFiles\Kubernetes\kubelet-config.yaml
Start-Service kubelet

Configure and start kube-proxy (typically deployed as DaemonSet)

Join Node:
- Run kubeadm join command or manually configure TLS certificates and kubeconfig
- Verify that the node has registered with the cluster:
  bash
```
kubectl get nodes
```
Add Node Labels:
- Add OS label to Windows node (if not automatically added):
  bash
```
kubectl label node <windows-node-name> kubernetes.io/os=windows
```

Deploy Test Workload:

Deploy a simple pod running a Windows container:

yaml

apiVersion: v1
kind: Pod
metadata:
  name: windows-test-pod
spec:
  nodeSelector:
    kubernetes.io/os: windows
  containers:
  - name: windows-server
    image: mcr.microsoft.com/windows/servercore:ltsc2019
    command:
    - powershell.exe
    - -Command
    - "Start-Sleep -Seconds 3600"

Key Considerations:

Version Compatibility:
- Windows Server version and container image version must be compatible
- Verify Kubernetes version and Windows support features
Networking:
- Use CNI plugins supported on Windows nodes
- Verify network policy support
- Verify port requirements (kubelet, containerd, CNI, etc.)
Storage:
- Verify storage drivers and volume types supported on Windows nodes
- Verify CSI driver compatibility
Monitoring and Logging:
- Deploy monitoring agents suitable for Windows nodes
- Configure Windows event log collection
Security:
- Configure Windows firewall rules
- Set up Group Managed Service Accounts (gMSA) if needed
- Configure network security groups
Automation:
- Automate Windows node provisioning (Ansible, PowerShell DSC, etc.)
- Establish node upgrade strategy

Explain the main differences between Windows containers and Linux containers, and how to manage these differences in Kubernetes.

Show Answer

Answer:

Main Differences Between Windows Containers and Linux Containers:

Underlying Technology:
- Linux containers: Use Linux namespaces, cgroups, and kernel features for isolation
- Windows containers: Use Windows isolation technologies (job objects, Hyper-V isolation, etc.)
Image Structure:
- Linux containers: Relatively small size (tens to hundreds of MB)
- Windows containers: Generally larger size (several GB), base images are larger
Isolation Modes:
- Linux containers: Single isolation mode (namespace-based)
- Windows containers: Two modes supported: process isolation and Hyper-V isolation
File System:
- Linux containers: Layered file system (OverlayFS, etc.)
- Windows containers: NTFS-based filter driver
Networking:
- Linux containers: Various networking modes and driver support
- Windows containers: Limited networking modes, only specific CNI plugins supported
Resource Management:
- Linux containers: Fine-grained resource control through cgroups
- Windows containers: Resource control through Job Objects, with some limitations
Security Context:
- Linux containers: Various security context options (SELinux, AppArmor, etc.)
- Windows containers: Limited security context options, privileged containers not supported
Host OS Dependency:
- Linux containers: Can run on various Linux distributions
- Windows containers: Require same or compatible version as host OS

How to Manage These Differences in Kubernetes:

Node Selection and Scheduling:

Use node labels: kubernetes.io/os=windows or kubernetes.io/os=linux

Use nodeSelector:

yaml

nodeSelector:
  kubernetes.io/os: windows

Use node affinity:

yaml

affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/os
          operator: In
          values:
          - windows

Workload Separation:

Create OS-specific Deployments:

yaml

# Deployment for Windows workloads
apiVersion: apps/v1
kind: Deployment
metadata:
  name: windows-app
spec:
  selector:
    matchLabels:
      app: myapp
      os: windows
  template:
    metadata:
      labels:
        app: myapp
        os: windows
    spec:
      nodeSelector:
        kubernetes.io/os: windows
      containers:
      - name: windows-app
        image: myregistry/windows-app:latest

# Deployment for Linux workloads
apiVersion: apps/v1
kind: Deployment
metadata:
  name: linux-app
spec:
  selector:
    matchLabels:
      app: myapp
      os: linux
  template:
    metadata:
      labels:
        app: myapp
        os: linux
    spec:
      nodeSelector:
        kubernetes.io/os: linux
      containers:
      - name: linux-app
        image: myregistry/linux-app:latest

DaemonSet Management:

Create OS-specific DaemonSets:

yaml

# DaemonSet for Windows nodes
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: windows-agent
spec:
  selector:
    matchLabels:
      app: monitoring-agent
  template:
    metadata:
      labels:
        app: monitoring-agent
    spec:
      nodeSelector:
        kubernetes.io/os: windows
      containers:
      - name: agent
        image: myregistry/windows-agent:latest

Image Management:
- Use multi-architecture images: Support various OS/architectures with the same tag
- Use OS-specific image tags: myapp:linux and myapp:windows
- Set image pull policy: imagePullPolicy: Always

Resource Requests and Limits:

Set appropriate resources for each OS:

yaml

resources:
  requests:
    memory: "2Gi"  # Windows containers typically need more memory
    cpu: "500m"
  limits:
    memory: "4Gi"
    cpu: "1"

Networking:

Select compatible CNI plugin: Flannel, Calico, Antrea, etc.

Consider OS when applying network policies:

yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-specific-traffic
spec:
  podSelector:
    matchLabels:
      app: myapp
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend

Storage:

Use OS-compatible storage classes:

yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: windows-pvc
spec:
  storageClassName: windows-storage  # Windows node compatible storage class
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

Security Context:

Apply appropriate security settings for each OS:

yaml

# Security context for Linux pods
securityContext:
  runAsUser: 1000
  runAsGroup: 3000
  fsGroup: 2000

# Windows pods ignore the above settings and use different security mechanisms

Monitoring and Logging:
- Deploy OS-specific monitoring agents
- Adjust log collection paths: Windows (C:\k\logs) vs Linux (/var/log)
CI/CD Pipelines:
- Configure OS-specific build and test pipelines
- Establish multi-OS deployment strategy

Explain how to use Group Managed Service Accounts (gMSA) in Windows containers and their benefits.

Show Answer

Answer:

Group Managed Service Accounts (gMSA) Overview:

Group Managed Service Accounts (gMSA) are a special type of Active Directory account for service authentication in Windows domain environments. Using gMSA in Windows containers in Kubernetes allows running applications that require domain authentication, and is particularly useful in the following scenarios:

.NET applications requiring Active Directory integration
SQL Server connections using Windows authentication
Services requiring Kerberos authentication
Applications that need to access domain resources

How to Use gMSA in Windows Containers:

Prerequisites:
- Active Directory domain controller
- Windows nodes must be joined to the domain
- Kubernetes version 1.14 or later
- containerd or Docker container runtime

Set up gMSA in Active Directory:

powershell

# 1. Create KDS root key (run on domain controller)
Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)

# 2. Create gMSA account
New-ADServiceAccount -Name "gmsa-k8s" -DnsHostName "gmsa-k8s.example.com" -ServicePrincipalNames "host/gmsa-k8s", "host/gmsa-k8s.example.com" -PrincipalsAllowedToRetrieveManagedPassword "Domain Computers"

Create gMSA Credential Spec:

yaml

apiVersion: windows.k8s.io/v1
kind: GMSACredentialSpec
metadata:
  name: gmsa-k8s-credspec
credspec:
  ActiveDirectoryConfig:
    GroupManagedServiceAccounts:
    - Name: gmsa-k8s
      Scope: EXAMPLE
  CmsPlugins:
  - ActiveDirectory
  DomainJoinConfig:
    DnsName: example.com
    DnsTreeName: example.com
    Guid: 12345678-1234-1234-1234-123456789012
    MachineAccountName: gmsa-k8s
    NetBiosName: EXAMPLE

Store Credential Spec as Kubernetes Secret:

bash

kubectl create secret generic gmsa-k8s-secret --from-file=credspec.json=/path/to/gmsa-credspec.json

Add gMSA Configuration to Pod Definition:

yaml

apiVersion: v1
kind: Pod
metadata:
  name: iis-gmsa
  labels:
    app: iis-gmsa
spec:
  securityContext:
    windowsOptions:
      gmsaCredentialSpecName: gmsa-k8s-credspec
  nodeSelector:
    kubernetes.io/os: windows
  containers:
  - name: iis
    image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
    ports:
    - containerPort: 80

Verify gMSA Usage:

powershell

# Run inside container
whoami
# Output: EXAMPLE\gmsa-k8s$

nltest /sc_verify:example.com
# Output: Trusted DC connections... Passed

Benefits of Using gMSA:

Enhanced Security:
- Eliminates hardcoded credentials inside containers
- Automatic password management and rotation
- Enables applying principle of least privilege
Active Directory Integration:
- Enables containerizing existing applications using Windows authentication
- Supports Kerberos and NTLM authentication
- Seamless access to domain resources
Centralized Identity Management:
- Unified identity management through Active Directory
- Group policies can be applied
- Improved auditing and compliance
Application Compatibility:
- Supports legacy .NET applications requiring domain authentication
- Supports SQL Server connections using Windows integrated authentication
- Supports Windows authentication for IIS web applications
Simplified Operations:
- Automated credential management
- Credentials persist across container restarts
- Same identity can be shared across multiple containers

Considerations When Using gMSA:

Network Requirements:
- Network connectivity from Windows nodes to domain controllers required
- Proper DNS configuration required
- Required ports must be open (Kerberos, LDAP, etc.)
Permission Management:
- Grant only minimum required permissions to gMSA
- Configure appropriate group memberships
- Regular permission reviews
Scalability:
- Consider domain controller load in large clusters
- Use multiple gMSA accounts for permission separation
Troubleshooting:
- Debug domain connectivity issues
- Verify credential spec configuration errors
- Review container runtime logs

Explain how to configure logging and monitoring for Windows nodes in Kubernetes and the differences from Linux nodes.

Show Answer

Answer:

Configuring Logging and Monitoring for Windows Nodes:

1. Logging Configuration:

Main Logging Sources for Windows Nodes:

Windows Event Logs (System, Application, Security)
ETW (Event Tracing for Windows) events
Application log files (typically within the C:\ drive)
kubelet and container runtime logs (typically C:\k\logs or similar paths)

Methods for Configuring Windows Node Logging:

Fluent Bit or Fluentd Setup:

yaml

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluent-bit-windows
  namespace: logging
spec:
  selector:
    matchLabels:
      app: fluent-bit-windows
  template:
    metadata:
      labels:
        app: fluent-bit-windows
    spec:
      nodeSelector:
        kubernetes.io/os: windows
      containers:
      - name: fluent-bit
        image: fluent/fluent-bit:windows-latest
        volumeMounts:
        - name: config
          mountPath: C:/fluent-bit/conf/
        - name: windows-logs
          mountPath: C:/Windows/System32/winevt/Logs
          readOnly: true
      volumes:
      - name: config
        configMap:
          name: fluent-bit-windows-config
      - name: windows-logs
        hostPath:
          path: C:/Windows/System32/winevt/Logs

Windows Event Log Collection Configuration:

ini

# Fluent Bit Windows configuration
[INPUT]
    Name            winlog
    Channels        System,Application,Security
    Interval_Sec    1
    DB              C:\\fluent-bit\\winlog.db

[OUTPUT]
    Name            elasticsearch
    Match           *
    Host            elasticsearch-master
    Port            9200
    Index           windows_logs
    Type            _doc

Container Log Collection:
- containerd log path: C:\ProgramData\containerd\root\containers
- kubelet log path: C:\k\logs or Windows Event Log

2. Monitoring Configuration:

Main Metrics for Windows Node Monitoring:

CPU, memory, disk usage
Network traffic
Process count
Page file usage
Container resource usage

Methods for Configuring Windows Node Monitoring:

Prometheus Windows Exporter Setup:

yaml

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: windows-exporter
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app: windows-exporter
  template:
    metadata:
      labels:
        app: windows-exporter
    spec:
      nodeSelector:
        kubernetes.io/os: windows
      containers:
      - name: windows-exporter
        image: prometheuscommunity/windows-exporter:latest
        args:
        - --collectors.enabled=cpu,memory,disk,net,service,os,system,container
        ports:
        - containerPort: 9182
          name: metrics
          protocol: TCP

Prometheus Scraping Configuration:

yaml

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: windows-exporter
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app: windows-exporter
  endpoints:
  - port: metrics
    interval: 30s

Grafana Dashboard Setup:
- Create dedicated dashboards for Windows node metrics
- Add Windows-specific panels (e.g., page file usage, service status, etc.)

3. Troubleshooting Tools:

Tools for Windows Node Troubleshooting:

PowerShell commands (Get-Process, Get-Service, Get-EventLog)
Windows Performance Monitor (PerfMon)
Event Viewer
kubectl debug command (limited support on Windows nodes)

Windows Node Troubleshooting Examples:

powershell

# Check kubelet logs
Get-EventLog -LogName Application -Source kubelet -Newest 50

# Check containerd status
Get-Service containerd

# Verify network connectivity
Test-NetConnection -ComputerName api.kubernetes.cluster -Port 443

Key Differences from Linux Nodes:

Log Storage Location:
- Linux: Stored as text files in /var/log/ directory
- Windows: Windows Event Logs (binary format) and text files in various locations
Log Collection Mechanism:
- Linux: File-based log collection is typical (tail, read)
- Windows: Requires collection through Windows Event Log API
Metric Collection:
- Linux: Collect metrics from /proc, /sys file systems
- Windows: Use WMI (Windows Management Instrumentation) or Performance Counter API
Container Logs:
- Linux: Standard output/error redirected to files
- Windows: ETW or file-based logging, different path structure
Resource Monitoring:
- Linux: Container resource usage monitoring through cgroups
- Windows: Resource monitoring through Job Objects, some metrics calculated differently
Monitoring Agents:
- Linux: Various agent support (node-exporter, cAdvisor, etc.)
- Windows: Limited agent support, Windows-specific agents required
Debugging Tools:
- Linux: Various CLI tools (ps, top, netstat, strace, etc.)
- Windows: PowerShell commands, GUI tools, limited CLI tools

Best Practices:

Integrated Logging Solution:
- Use EFK (Elasticsearch, Fluent Bit, Kibana) or ELK stack
- Separate configurations for both Windows and Linux nodes
Integrated Monitoring Solution:
- Monitor all nodes with Prometheus + Grafana
- Create OS-specific dashboards
Alert Configuration:
- Set up alert rules for Windows-specific events
- Monitor critical Windows service status
Log Retention Policy:
- Configure Windows event log size and retention period
- Configure log rotation policy
Security Monitoring:
- Collect and analyze Windows security event logs
- Monitor permission changes and login attempts

Explain the storage options and volume mount configuration methods for Windows containers in Kubernetes.

Show Answer

Answer:

Storage Options for Windows Containers:

1. Basic Volume Types:

emptyDir:
- Stores temporary data during pod lifetime
- Created on local NTFS volume of Windows node
- Data is deleted when pod is deleted
yaml
```
volumes:
- name: temp-data
  emptyDir: {}
```
hostPath:
- Direct access to Windows node's file system
- Must use Windows path format (escape backslashes)
- Data cannot be shared across nodes
yaml
```
volumes:
- name: logs
  hostPath:
    path: C:\\Logs
    type: DirectoryOrCreate
```
configMap and secret:
- Store configuration data and sensitive information
- Works the same way for Windows containers
- File permission settings are applied differently on Windows
yaml
```
volumes:
- name: config
  configMap:
    name: app-config
```
persistentVolumeClaim (PVC):
- Request persistent storage
- Requires Windows-compatible storage class
- Need to verify CSI driver support
yaml
```
volumes:
- name: data
  persistentVolumeClaim:
    claimName: windows-pvc
```

2. Storage Solutions Supporting Windows Containers:

Azure Disk/File (AKS):

Azure Kubernetes Service supports Windows nodes
Can use SMB protocol-based Azure Files
Azure Disk CSI driver supported

yaml

# Azure File PVC
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: azure-file-pvc
spec:
  accessModes:
  - ReadWriteMany
  storageClassName: azurefile-csi
  resources:
    requests:
      storage: 100Gi

AWS EBS (EKS):

Amazon EKS Windows node support
EBS CSI driver available
Access limited within single AZ

yaml

# AWS EBS PVC
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ebs-windows-pvc
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: ebs-sc
  resources:
    requests:
      storage: 50Gi

SMB/CIFS Volumes:

Network file system suitable for Windows environments
Requires FlexVolume or CSI driver
Supports ReadWriteMany access across multiple pods

yaml

# SMB CSI driver example
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: smb-windows-pvc
spec:
  accessModes:
  - ReadWriteMany
  storageClassName: smb-csi
  resources:
    requests:
      storage: 100Gi

iSCSI:

Requires iSCSI initiator configuration on Windows node
Provides block storage access
Suitable for high-performance requirements

yaml

# iSCSI PV example
apiVersion: v1
kind: PersistentVolume
metadata:
  name: iscsi-windows-pv
spec:
  capacity:
    storage: 100Gi
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  iscsi:
    targetPortal: 192.168.1.10:3260
    iqn: iqn.2000-01.com.example:storage.kube.sys1.xyz
    lun: 0
    fsType: ntfs
    readOnly: false

3. Volume Mount Configuration for Windows Containers:

Volume Mount Paths:
- Windows containers use Windows path format
- Typically use paths within the C:\ drive
- Backslashes in paths need escaping in YAML
yaml
```
volumeMounts:
- name: data
  mountPath: C:\\data
```
Read-Only Mounts:
- Supported for Windows containers
- Applied through NTFS permissions
yaml
```
volumeMounts:
- name: config
  mountPath: C:\\config
  readOnly: true
```
Subpath Mounts:
- Can mount only specific subpaths of volumes
- Note Windows path separators
yaml
```
volumeMounts:
- name: shared-data
  mountPath: C:\\app\\logs
  subPath: logs
```

4. Windows Container Storage Configuration Examples:

Web Application Configuration:

yaml

apiVersion: v1
kind: Pod
metadata:
  name: windows-web-app
spec:
  nodeSelector:
    kubernetes.io/os: windows
  containers:
  - name: web
    image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
    volumeMounts:
    - name: website
      mountPath: C:\\inetpub\\wwwroot
    - name: logs
      mountPath: C:\\inetpub\\logs
    - name: config
      mountPath: C:\\config
      readOnly: true
  volumes:
  - name: website
    persistentVolumeClaim:
      claimName: website-content-pvc
  - name: logs
    emptyDir: {}
  - name: config
    configMap:
      name: web-config

Database Configuration:

yaml

apiVersion: v1
kind: Pod
metadata:
  name: windows-sql
spec:
  nodeSelector:
    kubernetes.io/os: windows
  containers:
  - name: sql
    image: mcr.microsoft.com/mssql/server:2019-latest
    env:
    - name: ACCEPT_EULA
      value: "Y"
    - name: SA_PASSWORD
      valueFrom:
        secretKeyRef:
          name: sql-credentials
          key: sa-password
    volumeMounts:
    - name: data
      mountPath: C:\\var\\opt\\mssql\\data
    - name: backup
      mountPath: C:\\var\\opt\\mssql\\backup
  volumes:
  - name: data
    persistentVolumeClaim:
      claimName: sql-data-pvc
  - name: backup
    persistentVolumeClaim:
      claimName: sql-backup-pvc

5. Considerations When Using Windows Container Storage:

Path Separators:
- Windows uses backslashes (\) but escaping is needed in YAML
- Alternatively, forward slashes (/) can be used but verify application compatibility
File Permissions:
- Windows uses NTFS permission model
- Cannot set permissions like chmod/chown in Linux
- Permissions inside containers are determined by container user context
Performance Considerations:
- Network storage (SMB/CIFS) may have latency
- Local storage or direct-attached block storage recommended for high-performance requirements
Storage Class Compatibility:
- Verify storage classes compatible with Windows nodes
- Verify Windows support of CSI drivers
Backup and Recovery:
- Consider Windows Volume Shadow Copy Service (VSS) integration
- Implement application-consistent backup mechanisms

Hands-on Questions

Write a Deployment manifest that meets the following requirements for a mixed Windows and Linux node Kubernetes cluster:
- Application name: web-app
- Windows container image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
- Replicas: 2
- Port: 80
- Environment variable: WEBSITE_NAME=MyWindowsApp
- Volume: Mount ConfigMap "web-config" to C:\inetpub\wwwroot\web.config

Show Answer

Answer:

yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
  labels:
    app: web-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
    spec:
      nodeSelector:
        kubernetes.io/os: windows
      containers:
      - name: iis
        image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
        ports:
        - containerPort: 80
        env:
        - name: WEBSITE_NAME
          value: "MyWindowsApp"
        volumeMounts:
        - name: config-volume
          mountPath: C:\inetpub\wwwroot\web.config
          subPath: web.config
      volumes:
      - name: config-volume
        configMap:
          name: web-config
---
apiVersion: v1
kind: Service
metadata:
  name: web-app
spec:
  selector:
    app: web-app
  ports:
  - port: 80
    targetPort: 80
  type: ClusterIP

Explanation:

Deployment Resource:
- Uses nodeSelector to specify scheduling only to Windows nodes
- Sets 2 replicas as required
- Uses IIS web server image
Container Configuration:
- Exposes port 80
- Sets environment variable WEBSITE_NAME
- Mounts ConfigMap to specific file path (using Windows path format)
Volume Configuration:
- Mounts ConfigMap as volume
- Uses subPath to mount specific key from ConfigMap as file
Service Definition:
- Creates ClusterIP service for accessing the application
- Accessible through port 80

Notes:

In Windows paths, backslashes (\) are treated as escape characters in YAML, so be careful. This example uses regular backslashes, but for more complex paths, double backslashes (\\) or forward slashes (/) can be used.
Windows containers may have higher resource requirements than Linux containers, so it's good practice to set appropriate resource requests and limits in production environments.

Write DaemonSet manifests for deploying monitoring agents that run on both Windows and Linux nodes. Each OS should use appropriate images and configurations.

Show Answer

Answer:

yaml

# DaemonSet for Linux nodes
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: monitoring-agent-linux
  namespace: monitoring
  labels:
    app: monitoring-agent
    os: linux
spec:
  selector:
    matchLabels:
      app: monitoring-agent
      os: linux
  template:
    metadata:
      labels:
        app: monitoring-agent
        os: linux
    spec:
      nodeSelector:
        kubernetes.io/os: linux
      containers:
      - name: agent
        image: prom/node-exporter:latest
        ports:
        - containerPort: 9100
          name: metrics
        volumeMounts:
        - name: proc
          mountPath: /host/proc
          readOnly: true
        - name: sys
          mountPath: /host/sys
          readOnly: true
        - name: root
          mountPath: /host/root
          readOnly: true
        args:
        - --path.procfs=/host/proc
        - --path.sysfs=/host/sys
        - --path.rootfs=/host/root
        securityContext:
          runAsNonRoot: true
          runAsUser: 65534
      volumes:
      - name: proc
        hostPath:
          path: /proc
      - name: sys
        hostPath:
          path: /sys
      - name: root
        hostPath:
          path: /
---
# DaemonSet for Windows nodes
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: monitoring-agent-windows
  namespace: monitoring
  labels:
    app: monitoring-agent
    os: windows
spec:
  selector:
    matchLabels:
      app: monitoring-agent
      os: windows
  template:
    metadata:
      labels:
        app: monitoring-agent
        os: windows
    spec:
      nodeSelector:
        kubernetes.io/os: windows
      containers:
      - name: agent
        image: prometheuscommunity/windows-exporter:latest
        ports:
        - containerPort: 9182
          name: metrics
        args:
        - --collectors.enabled=cpu,memory,disk,net,service,os,system,container
---
# Service for monitoring agents
apiVersion: v1
kind: Service
metadata:
  name: monitoring-agent
  namespace: monitoring
  labels:
    app: monitoring-agent
spec:
  type: ClusterIP
  ports:
  - name: linux-metrics
    port: 9100
    targetPort: 9100
    protocol: TCP
  - name: windows-metrics
    port: 9182
    targetPort: 9182
    protocol: TCP
  selector:
    app: monitoring-agent

Explanation:

DaemonSet for Linux Nodes:
- Uses nodeSelector to schedule only to Linux nodes
- Uses Prometheus Node Exporter image
- Mounts host's /proc, /sys, / directories to collect system metrics
- Security context configured to run as non-root user
DaemonSet for Windows Nodes:
- Uses nodeSelector to schedule only to Windows nodes
- Uses Windows Exporter image
- Specifies metric collectors to collect
- Windows-specific configuration applied
Common Service:
- Creates service selecting pods from both DaemonSets
- Exposes both Linux and Windows metrics ports
- Prometheus can scrape metrics through this service

Notes:

It's important to use appropriate images and configurations for each OS.
Since metric collection methods differ between Linux and Windows nodes, they are separated into different DaemonSets.
Using labels to distinguish OS types is useful for filtering and visualizing metrics in the monitoring system.
In production environments, additional configuration of resource requests and limits, security contexts, service accounts, etc. is needed.

Write a pod manifest for deploying a .NET application that uses Active Directory authentication in a Windows container. Group Managed Service Accounts (gMSA) must be used.

Show Answer

Answer:

yaml

# Secret for gMSA credential spec
apiVersion: v1
kind: Secret
metadata:
  name: gmsa-credential-spec
  namespace: default
type: Opaque
data:
  credspec.json: BASE64_ENCODED_CREDENTIAL_SPEC_HERE
---
# Windows pod using gMSA
apiVersion: v1
kind: Pod
metadata:
  name: ad-auth-app
  labels:
    app: ad-auth-app
spec:
  nodeSelector:
    kubernetes.io/os: windows
  securityContext:
    windowsOptions:
      gmsaCredentialSpecName: gmsa-credential-spec
  containers:
  - name: dotnet-app
    image: myregistry/ad-auth-app:latest
    ports:
    - containerPort: 80
    env:
    - name: ASPNETCORE_ENVIRONMENT
      value: "Production"
    volumeMounts:
    - name: app-config
      mountPath: C:\app\appsettings.json
      subPath: appsettings.json
    resources:
      requests:
        memory: "2Gi"
        cpu: "500m"
      limits:
        memory: "4Gi"
        cpu: "1000m"
  volumes:
  - name: app-config
    configMap:
      name: ad-auth-app-config
---
# ConfigMap for application configuration
apiVersion: v1
kind: ConfigMap
metadata:
  name: ad-auth-app-config
data:
  appsettings.json: |
    {
      "Logging": {
        "LogLevel": {
          "Default": "Information",
          "Microsoft": "Warning"
        }
      },
      "ConnectionStrings": {
        "DefaultConnection": "Server=sql-server;Database=AppDB;Integrated Security=True;"
      },
      "ActiveDirectory": {
        "Domain": "example.com",
        "UseWindowsAuthentication": true
      }
    }
---
# Service definition
apiVersion: v1
kind: Service
metadata:
  name: ad-auth-app
spec:
  selector:
    app: ad-auth-app
  ports:
  - port: 80
    targetPort: 80
  type: ClusterIP

Explanation:

gMSA Credential Spec Secret:
- Active Directory gMSA credential spec is Base64 encoded and stored as a secret
- This secret is used by pods for domain authentication
Windows Pod Configuration:
- Uses nodeSelector to schedule to Windows nodes
- References gMSA credential spec using securityContext.windowsOptions.gmsaCredentialSpecName
- Uses .NET application image
- Appropriate resource requests and limits set
Volumes and Configuration:
- Provides application settings using ConfigMap
- Configuration file mounted using Windows path format
- Includes SQL Server connection string using Windows integrated authentication
Service Definition:
- Creates ClusterIP service for accessing the application

Prerequisites for gMSA Setup:

Active Directory Domain Controller Setup:

powershell

# Create KDS root key (run on domain controller)
Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)

# Create gMSA account
New-ADServiceAccount -Name "k8s-gmsa" -DnsHostName "k8s-gmsa.example.com" -ServicePrincipalNames "host/k8s-gmsa", "host/k8s-gmsa.example.com" -PrincipalsAllowedToRetrieveManagedPassword "Domain Computers"

Create Credential Spec:

powershell

# Run on Windows node
Import-Module ActiveDirectory
$CredSpec = New-CimInstance -Namespace root/Microsoft/Windows/CredentialSpecification -ClassName Win32_CredentialSpecification -Property @{Name = "k8s-gmsa"; ActiveDirectoryCredentialSpec = Get-CredentialSpec -Name k8s-gmsa -Json}

# Verify credential spec contents
Get-CredentialSpec -Name k8s-gmsa -Json

Convert Credential Spec to Kubernetes Secret:

bash

# Base64 encode credential spec JSON
cat credspec.json | base64 -w 0

# Add encoded value to secret YAML

Notes:

Windows nodes must be joined to the Active Directory domain.
containerd or Docker must be configured to support gMSA.
In real environments, credential spec contents must be managed securely.
The application must be configured to correctly use Windows authentication.

Write NetworkPolicy manifests that meet the following requirements in a cluster with mixed Windows and Linux nodes:
- Windows web application pods (label: app=windows-web) can only access Linux database pods (label: app=linux-db)
- Database pods allow access only on port 3306
- Web application pods are accessible from external on port 80

Show Answer

Answer:

yaml

# NetworkPolicy for Windows web application
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: windows-web-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: windows-web
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - ports:
    - port: 80
      protocol: TCP
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: linux-db
    ports:
    - port: 3306
      protocol: TCP
---
# NetworkPolicy for Linux database
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: linux-db-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: linux-db
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: windows-web
    ports:
    - port: 3306
      protocol: TCP

Explanation:

Windows Web Application NetworkPolicy:
- Applies to pods with label app=windows-web
- Ingress rule: Allows access from all sources on port 80
- Egress rule: Allows access only to port 3306 on pods with label app=linux-db
Linux Database NetworkPolicy:
- Applies to pods with label app=linux-db
- Ingress rule: Allows access only from pods with label app=windows-web on port 3306

Notes:

Network policies require a CNI plugin that supports NetworkPolicy (e.g., Calico, Antrea) to function.
NetworkPolicy support on Windows nodes may vary depending on the CNI plugin.
This example assumes the default namespace, but appropriate namespaces should be specified in real environments.
In production environments, additional egress rules may be needed for DNS lookups, external service access, etc.

Deployment Examples:

Windows web application pods:

yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: windows-web
spec:
  replicas: 2
  selector:
    matchLabels:
      app: windows-web
  template:
    metadata:
      labels:
        app: windows-web
    spec:
      nodeSelector:
        kubernetes.io/os: windows
      containers:
      - name: web
        image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
        ports:
        - containerPort: 80

Linux database pods:

yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: linux-db
spec:
  replicas: 1
  selector:
    matchLabels:
      app: linux-db
  template:
    metadata:
      labels:
        app: linux-db
    spec:
      nodeSelector:
        kubernetes.io/os: linux
      containers:
      - name: mysql
        image: mysql:8.0
        ports:
        - containerPort: 3306
        env:
        - name: MYSQL_ROOT_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-secret
              key: password

Write a Deployment manifest for a .NET Framework application running on Windows nodes. The application requires a connection string as an environment variable to access Azure Blob Storage. Also configure a persistent volume for logs.

Show Answer

Answer:

yaml

# Secret for Azure Storage connection string
apiVersion: v1
kind: Secret
metadata:
  name: azure-storage-secret
type: Opaque
data:
  connection-string: QWNjb3VudE5hbWU9bXlzdG9yYWdlYWNjb3VudDtBY2NvdW50S2V5PW15YWNjb3VudGtleTtFbmRwb2ludFN1ZmZpeD1jb3JlLndpbmRvd3MubmV0
---
# PersistentVolumeClaim for logs
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: windows-logs-pvc
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: managed-premium  # Azure Disk storage class example
  resources:
    requests:
      storage: 10Gi
---
# .NET Framework application Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: dotnet-framework-app
  labels:
    app: dotnet-framework-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: dotnet-framework-app
  template:
    metadata:
      labels:
        app: dotnet-framework-app
    spec:
      nodeSelector:
        kubernetes.io/os: windows
      containers:
      - name: dotnet-app
        image: myregistry/dotnet-framework-app:latest
        ports:
        - containerPort: 80
        env:
        - name: AZURE_STORAGE_CONNECTION_STRING
          valueFrom:
            secretKeyRef:
              name: azure-storage-secret
              key: connection-string
        - name: LOG_LEVEL
          value: "Information"
        - name: ASPNET_ENVIRONMENT
          value: "Production"
        volumeMounts:
        - name: logs-volume
          mountPath: C:\app\logs
        - name: config-volume
          mountPath: C:\app\web.config
          subPath: web.config
        resources:
          requests:
            memory: "2Gi"
            cpu: "500m"
          limits:
            memory: "4Gi"
            cpu: "1000m"
        readinessProbe:
          httpGet:
            path: /health
            port: 80
          initialDelaySeconds: 30
          periodSeconds: 10
        livenessProbe:
          httpGet:
            path: /health
            port: 80
          initialDelaySeconds: 60
          periodSeconds: 15
      volumes:
      - name: logs-volume
        persistentVolumeClaim:
          claimName: windows-logs-pvc
      - name: config-volume
        configMap:
          name: dotnet-app-config
---
# ConfigMap for application configuration
apiVersion: v1
kind: ConfigMap
metadata:
  name: dotnet-app-config
data:
  web.config: |
    <?xml version="1.0" encoding="utf-8"?>
    <configuration>
      <system.web>
        <compilation debug="false" targetFramework="4.8" />
        <httpRuntime targetFramework="4.8" />
      </system.web>
      <system.webServer>
        <handlers>
          <remove name="ExtensionlessUrlHandler-Integrated-4.0" />
          <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
        </handlers>
      </system.webServer>
      <appSettings>
        <add key="BlobContainerName" value="appdata" />
        <add key="LogDirectory" value="C:\app\logs" />
      </appSettings>
    </configuration>
---
# Service definition
apiVersion: v1
kind: Service
metadata:
  name: dotnet-framework-app
spec:
  selector:
    app: dotnet-framework-app
  ports:
  - port: 80
    targetPort: 80
  type: ClusterIP

Explanation:

Secret Configuration:
- Azure Storage connection string is Base64 encoded and stored as secret
- Accessible securely from application as environment variable
PersistentVolumeClaim:
- Requests 10GB persistent storage for log files
- Uses Azure Disk storage class (adjust for your environment)
- Uses ReadWriteOnce access mode
Deployment Configuration:
- Uses nodeSelector to schedule only to Windows nodes
- Uses .NET Framework application image
- Provides Azure Storage connection string through environment variables
- Mounts persistent volume for log directory
- Mounts web.config file from ConfigMap
- Appropriate resource requests and limits set
- Readiness and liveness probes configured for health checking
ConfigMap Configuration:
- Provides web.config file for .NET Framework application
- Includes application settings and configuration
Service Definition:
- Creates ClusterIP service for accessing the application

Notes:

In real environments, image registry addresses, storage classes, resource requirements, etc. should be adjusted for your environment.
.NET Framework applications must use Windows Server Core based images.
In production environments, external access can be configured through ingress controllers or load balancers.
Sensitive information like Azure Storage connection strings should be integrated with external secret management systems like Azure Key Vault.

Advanced Topics

What is the most important setting when configuring containerd as the container runtime for Windows nodes in Kubernetes?
- A) sandbox_image setting
- B) Log level and log path
- C) Memory limits and CPU sharing
- D) Image pull policy and registry configuration

Show Answer

Answer: A) sandbox_image setting

Explanation: The most important setting when configuring containerd as the container runtime for Windows nodes in Kubernetes is the sandbox_image setting. This setting specifies the image to use as the pod infrastructure container (pause container) on Windows nodes.

Why the sandbox_image setting is important for Windows nodes in containerd configuration:

Pod Networking: The pause container sets up and maintains the network namespace for pods. Since Windows uses a different networking stack than Linux, a Windows-specific pause image is required.
OS Compatibility: Linux pause images do not work on Windows nodes, and Windows pause images do not work on Linux nodes.
Version Compatibility: You must select an appropriate pause image compatible with the Windows version (e.g., Windows Server 2019, Windows Server 2022).

Example containerd configuration for Windows nodes:

toml

[plugins."io.containerd.grpc.v1.cri".containerd]
  default_runtime_name = "microsoft/windows"

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes."microsoft/windows"]
  runtime_type = "io.containerd.runhcs.v1"

[plugins."io.containerd.grpc.v1.cri"]
  sandbox_image = "mcr.microsoft.com/oss/kubernetes/pause:3.6-windows-ltsc2019"

Commonly used Windows pause images:

Windows Server 2019 LTSC: mcr.microsoft.com/oss/kubernetes/pause:3.6-windows-ltsc2019
Windows Server 2022: mcr.microsoft.com/oss/kubernetes/pause:3.6-windows-ltsc2022

Other options are also important, but sandbox_image is the most critical:

Log level and log path are useful for debugging but are not functionally essential.
Memory limits and CPU sharing are important for performance tuning but do not affect basic functionality.
Image pull policy and registry configuration are important for image management but do not affect basic operation of the container runtime.

What is the main benefit of using Hyper-V isolation mode in Windows containers?
- A) Better performance and lower resource usage
- B) Ability to run containers with different Windows versions than the host OS
- C) Improved network communication speed between containers
- D) Support for more Windows APIs and features

Show Answer

Answer: B) Ability to run containers with different Windows versions than the host OS

Explanation: The main benefit of using Hyper-V isolation mode in Windows containers is the ability to run containers with different Windows versions than the host OS. This is one of the important characteristics of Windows containers and is particularly useful when running legacy applications on modern infrastructure.

Main benefits of Hyper-V isolation mode:

Version Compatibility:
- Resolves version mismatch issues between host OS and container OS.
- For example, you can run Windows Server 2019-based containers on a Windows Server 2022 host.
- This is not possible in process isolation mode (process isolation requires the host and container to use the same kernel version).
Enhanced Security Isolation:
- Each container runs in a lightweight virtual machine providing stronger isolation.
- Security boundaries between containers and between containers and the host are strengthened.
- Useful in multi-tenant environments or when running untrusted code.
Kernel-Level Isolation:
- Each container has its own Windows kernel instance.
- This provides kernel-level isolation so that kernel issues in one container do not affect other containers or the host.

To use Hyper-V isolation mode in Kubernetes, add the following annotation to the pod spec:

yaml

apiVersion: v1
kind: Pod
metadata:
  name: iis-hyper-v
  annotations:
    io.kubernetes.cri-containerd.isolation: "hyperv"
spec:
  nodeSelector:
    kubernetes.io/os: windows
  containers:
  - name: iis
    image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019

Disadvantages of Hyper-V isolation mode:

Uses more resources (memory, CPU).
Longer startup time.
Requires Hyper-V feature enabled on the host.

Issues with other options:

Hyper-V isolation actually has lower performance and higher resource usage (A is incorrect).
Network communication between containers is actually faster in process isolation mode (C is incorrect).
Windows API and feature support depends on the container OS version, Hyper-V isolation itself does not provide more APIs (D is incorrect).

Which statement about pod networking when using Windows nodes in Kubernetes is correct?
- A) Windows nodes do not use CNI plugins and use their own networking stack
- B) Windows nodes use the same CNI plugins as Linux nodes but with different configuration
- C) Windows nodes must always use host network mode
- D) Windows nodes do not support overlay networks

Show Answer

Answer: B) Windows nodes use the same CNI plugins as Linux nodes but with different configuration

Explanation: Windows nodes in Kubernetes can use the same CNI (Container Network Interface) plugins as Linux nodes, but the configuration is different because Windows has a different networking stack. This allows for a consistent networking model in mixed OS clusters while considering the characteristics of each OS.

Pod networking characteristics on Windows nodes:

CNI Plugin Support:
- Windows nodes support several CNI plugins including Flannel, Calico, and Antrea.
- These plugins are designed to work on both Linux and Windows nodes.
- Each plugin provides Windows-specific components or settings.
Networking Modes:
- Windows nodes generally support overlay networks (VXLAN, GENEVE, etc.).
- Support various network modes including L2bridge, L2tunnel, overlay, etc.
- Flannel's VXLAN mode is widely used on Windows nodes.
Configuration Differences:
- Windows nodes use HNS (Host Network Service) to manage network configuration.
- Network endpoint creation and management methods differ from Linux.
- Some advanced networking features may be limited on Windows.

Example - Flannel CNI configuration:

yaml

# Flannel ConfigMap for both Linux and Windows nodes
kind: ConfigMap
apiVersion: v1
metadata:
  name: kube-flannel-cfg
  namespace: kube-system
data:
  cni-conf.json: |
    {
      "name": "cbr0",
      "cniVersion": "0.3.1",
      "plugins": [
        {
          "type": "flannel",
          "delegate": {
            "hairpinMode": true,
            "isDefaultGateway": true
          }
        },
        {
          "type": "portmap",
          "capabilities": {
            "portMappings": true
          }
        }
      ]
    }
  net-conf.json: |
    {
      "Network": "10.244.0.0/16",
      "Backend": {
        "Type": "vxlan",
        "VNI": 4096,
        "Port": 4789
      }
    }

Additional configuration may be needed on Windows nodes:

powershell

# Script running on Windows nodes
$env:KUBE_NETWORK = "cbr0"
$networkName = "vxlan0"
$networkMode = "overlay"

Issues with other options:

Windows nodes use CNI plugins and do not use only their own networking stack (A is incorrect).
Windows nodes do not support host network mode. hostNetwork: true does not work for Windows pods (C is incorrect).
Windows nodes support overlay networks (VXLAN, etc.) (D is incorrect).

Which statement about resource management on Windows nodes in Kubernetes is correct?
- A) Windows nodes do not support resource limits
- B) Windows nodes provide more accurate resource limits than Linux nodes
- C) Windows nodes implement resource limits using Job Objects
- D) Windows nodes implement resource limits using cgroups

Show Answer

Answer: C) Windows nodes implement resource limits using Job Objects

Explanation: Windows nodes in Kubernetes use Job Objects, a Windows operating system feature, to implement resource limits for containers. This contrasts with Linux nodes which use cgroups.

Resource management characteristics on Windows nodes:

Job Objects:
- Windows uses Job Objects to limit resource usage of process groups.
- Container runtimes (containerd or Docker) use the Job Objects API to apply CPU and memory limits.
- Job Objects can limit CPU time, memory usage, work time, etc. for process groups.
CPU Limits:
- CPU limits on Windows are implemented through a CPU sharing (weights) mechanism.
- This is similar to Linux CPU sharing but implemented differently.
- Windows adjusts CPU sharing based on the number of CPU cores.
Memory Limits:
- Memory limits for Windows containers are implemented through Job Objects' memory limiting feature.
- When containers exceed memory limits, OOM (Out of Memory) termination occurs.
- Windows memory management works differently from Linux, so the actual behavior may differ even with the same memory limit value.
Resource Request and Limit Configuration:
- Windows pods specify resource requests and limits the same way as Linux pods:
  yaml
```
resources:
  requests:
    memory: "2Gi"
    cpu: "500m"
  limits:
    memory: "4Gi"
    cpu: "1"
```
- kubelet passes these values to the Windows container runtime, and the runtime uses Job Objects to apply the limits.
Monitoring and Reporting:
- kubelet monitors container resource usage using Windows performance counters.
- This information can be viewed through kubectl top pods and kubectl top nodes commands.
- Metrics server collects this information and provides it through the Kubernetes API.

Considerations for resource management on Windows nodes:

Windows containers generally use more default resources than Linux containers.
Memory overhead for Windows containers may be greater, so ensure sufficient memory headroom.
Exact behavior of resource limits may vary depending on Windows version.

Issues with other options:

Windows nodes support resource limits (A is incorrect).
Windows nodes generally provide less accurate resource limits than Linux nodes (B is incorrect).
Windows nodes use Job Objects, not cgroups (D is incorrect).

Which of the following is NOT an appropriate security best practice when using Windows nodes in Kubernetes?
- A) Regularly scan and update container images to resolve security vulnerabilities
- B) Enable privileged mode for all Windows pods
- C) Use gMSA (Group Managed Service Accounts) for Active Directory integration
- D) Use network policies to restrict pod-to-pod communication

Show Answer

Answer: B) Enable privileged mode for all Windows pods

Explanation: "Enable privileged mode for all Windows pods" is NOT an appropriate security best practice when using Windows nodes in Kubernetes. In fact, Windows containers do not support privileged mode, and attempting to set this will cause pod creation to fail.

Reasons why this option is inappropriate:

Privileged Mode Not Supported:
- Windows containers do not support the concept of privileged mode like Linux containers.
- Windows has a different security model from Linux and has no mechanism to grant host-level privileges to containers.
Violates Principle of Least Privilege:
- Even if it were supported, enabling privileged mode for all pods violates the principle of least privilege.
- Each workload should have only the minimum permissions needed.
Increased Security Risk:
- Privileged mode allows containers to access the host system, greatly increasing security risks.
- If a container escape vulnerability occurs, the entire host system could be exposed to risk.

All other options are appropriate security best practices:

A) Regularly scan and update container images to resolve security vulnerabilities:

Image scanning is important for identifying and resolving known vulnerabilities.
Windows images should receive regular security updates.
It's good practice to integrate image scanning tools into CI/CD pipelines.

C) Use gMSA (Group Managed Service Accounts) for Active Directory integration:

gMSA allows Windows containers to securely authenticate to Active Directory services.
Using gMSA instead of hardcoded credentials improves security.
Provides automatic password management and rotation functionality.

D) Use network policies to restrict pod-to-pod communication:

Network policies apply the principle of least privilege to network communication.
Restricting pod-to-pod communication to only necessary cases reduces the attack surface.
Network segmentation helps prevent lateral movement attacks.

Additional best practices for strengthening Windows node security:

Keep Windows nodes updated with latest security patches
Disable unnecessary Windows features and roles
Configure Windows firewall rules appropriately
Use strong authentication mechanisms
Remove unnecessary tools and components from container images
Implement runtime security monitoring

Traffic Management

Security

Observability

Resilience

Advanced

Comparison Guide

ArgoCD

Metrics

Logging

Tracing

Alerting

Observability End-to-End Labs

Cilium Deep Dive

Calico Deep Dive

Istio Detailed Quiz

Linkerd Detailed Quiz

Cilium Service Mesh Detailed Quiz

ArgoCD Detailed Quiz

Metrics

Logging

Tracing

Alerting

Observability Labs

Windows in Kubernetes Quiz ​

Multiple Choice Questions ​

Hands-on Questions ​

Advanced Topics ​

Windows in Kubernetes Quiz

Multiple Choice Questions

Hands-on Questions

Advanced Topics