Kubernetes における Windows クイズ

このクイズでは、Kubernetes で Windows node（ノード）と workload を管理するための概念的および実践的な知識を確認します。Windows container の基本、Kubernetes における Windows node 構成、networking、storage、security、monitoring などのトピックを扱います。

選択問題

Kubernetes の Windows node でサポートされている container runtime はどれですか？
- A) Docker と containerd
- B) CRI-O と Docker
- C) containerd と CRI-O
- D) Docker、containerd、gVisor

回答を表示

回答: A) Docker と containerd

解説: Kubernetes の Windows node で公式にサポートされている container runtime は Docker と containerd です。

Docker: Docker は、Windows 上で Windows container を実行するための従来の選択肢でした。ただし、Kubernetes における Docker のサポートは徐々に縮小しており、containerd への移行が推奨されます。
containerd: これは現在 Windows node に推奨されている container runtime です。containerd は軽量で安定した runtime であり、Kubernetes 1.20 以降の Windows node を公式にサポートしています。

CRI-O は Windows node では公式にサポートされていません。CRI-O は主に Linux container 向けの Container Runtime Interface (CRI) 実装です。

gVisor は container 分離のための sandbox runtime ですが、現在 Windows node ではサポートされていません。

Windows node で container runtime を設定する際は、Kubernetes バージョンとの互換性を確認することが重要です。

Kubernetes で Windows node と Linux node が混在する cluster を構成する場合、どの network solution が必要ですか？
- A) すべての CNI plugin が Windows node と Linux node の両方をサポートする
- B) Flannel、Calico、Antrea など、Windows をサポートする CNI plugin
- C) Windows node は CNI plugin なしで kubenet のみを使用する必要がある
- D) Windows node は常に host network mode のみを使用する必要がある

回答を表示

回答: B) Flannel、Calico、Antrea など、Windows をサポートする CNI plugin

解説: Kubernetes で Windows node と Linux node が混在する cluster を構成する場合、Windows をサポートする特定の CNI (Container Network Interface) plugin を使用する必要があります。すべての CNI plugin が Windows をサポートしているわけではありません。

Windows node をサポートする主な CNI plugin は次のとおりです。

Flannel: overlay network mode (vxlan) で Windows node をサポートします。
Calico: Windows node をサポートし、BGP mode と VXLAN mode の両方をサポートします。
Antrea: OVS (Open vSwitch) を使用して Windows node をサポートします。

さらに、Azure CNI、OVN-Kubernetes なども Windows node をサポートしています。

Windows node で CNI plugin を設定する際の考慮事項:

Windows node は Linux node とは異なる networking stack を持っています。
一部の networking 機能は Windows で制限される場合があります。
CNI plugin の Windows サポートバージョンと構成要件を確認する必要があります。

kubenet は Windows node ではサポートされておらず、Windows node は host network mode を使用できません (HostNetwork=true は Windows pods でサポートされていません)。

Windows container のデフォルトの isolation mode は何ですか？
- A) Hyper-V isolation
- B) Process isolation
- C) Virtual machine isolation
- D) Sandbox isolation

回答を表示

回答: B) Process isolation

解説: Windows container のデフォルトの isolation mode は Process Isolation です。この mode では、Windows container は host operating system の kernel を共有し、各 container は分離された process group として実行されます。

process isolation mode の特徴:

host OS と同じ kernel version を使用する必要があります。
resource 使用量が少なく、起動時間が短くなります。
Linux container の一般的な isolation model に似ています。

Windows は Hyper-V Isolation という代替の isolation mode も提供しています。

各 container は軽量な virtual machine 内で実行されます。
host OS とは異なる kernel version を使用できます。
より高いレベルの isolation を提供しますが、overhead が増えます。

Kubernetes で Hyper-V isolation を使用するには、次の annotation を pod spec に追加します。

yaml

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

Virtual machine isolation は Windows container の公式な isolation mode ではなく、sandbox isolation は Windows container で使用される用語ではありません。

Kubernetes で Windows node を使用する際の制限として正しくないものはどれですか？
- A) privileged container を使用できない
- B) HostPath volume を使用できない
- C) Pod の SecurityContext 機能は一部のみサポートされる
- D) pod network namespace を共有できない

回答を表示

回答: B) HostPath volume を使用できない

解説: HostPath volume は Windows node で使用できます。したがって、「HostPath volume を使用できない」という記述は正しくありません。

Windows node で HostPath volume を使用する場合は、Windows path format に従う必要があります。

yaml

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

Kubernetes で Windows node を使用する際の実際の制限は次のとおりです。

Privileged containers: Privileged container は Windows node では使用できません。これは、Windows には Linux の privileged mode に相当する概念がないためです。
SecurityContext limitations: Windows node では一部の SecurityContext 機能のみがサポートされます。たとえば、runAsUser、runAsGroup、fsGroup、seccomp、SELinux などはサポートされていません。
Pod network namespace sharing: Windows node では Pod 間で network namespace を共有できません。これは hostNetwork: true、dnsPolicy: ClusterFirstWithHostNet、Pod 内 container 間の localhost 通信などに影響します。

Windows node のその他の制限:

DaemonSets をすべての node (Linux と Windows) で実行したい場合は、nodeSelector を使用する必要があります。
一部の storage driver と volume type は制限される場合があります。
Linux 固有の alpha/beta 機能は Windows node では動作しない場合があります。

Kubernetes で Windows node を識別するために使用される node label は何ですか？
- A) kubernetes.io/os=windows
- B) beta.kubernetes.io/os=windows
- C) node.kubernetes.io/windows=true
- D) kubernetes.io/windows=enabled

回答を表示

回答: A) kubernetes.io/os=windows

解説: Kubernetes で Windows node を識別するために使用される標準の node label は kubernetes.io/os=windows です。この label は node の operating system type を示し、Kubernetes scheduler が Pod を適切な node に配置するために使用されます。

Windows Pod を Windows node に schedule するには、次のように nodeSelector を使用します。

yaml

nodeSelector:
  kubernetes.io/os: windows

または node affinity を使用できます。

yaml

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

beta.kubernetes.io/os=windows は以前の Kubernetes バージョンで使用されていましたが、現在は非推奨です。

node.kubernetes.io/windows=true と kubernetes.io/windows=enabled は標準の Kubernetes label ではありません。

注: Linux node には kubernetes.io/os=linux label があります。

Windows node で container image を pull する際に使用されるデフォルトの base image は何ですか？
- A) mcr.microsoft.com/windows/servercore
- B) mcr.microsoft.com/windows/nanoserver
- C) mcr.microsoft.com/dotnet/framework/runtime
- D) mcr.microsoft.com/powershell

回答を表示

回答: A) mcr.microsoft.com/windows/servercore

解説: Windows container の最も一般的な base image は mcr.microsoft.com/windows/servercore です。この image は Windows Server Core installation をベースにしており、ほとんどの Windows application を実行するために必要な core component を含んでいます。

Windows container で利用可能な主な base image は次のとおりです。

Windows Server Core (mcr.microsoft.com/windows/servercore):
- 中程度のサイズの image (約 2〜4GB)
- ほとんどの Windows application をサポート
- .NET Framework、PowerShell などを含む
- 最も広く使用されている Windows base image
Nano Server (mcr.microsoft.com/windows/nanoserver):
- 非常に小さい image (約 100〜200MB)
- Windows API support は限定的
- .NET Core application に適している
- 最小限の attack surface
.NET Framework (mcr.microsoft.com/dotnet/framework/runtime):
- .NET Framework application 向けの image
- Server Core をベースにしている
- 特定バージョンの .NET Framework を含む
PowerShell (mcr.microsoft.com/powershell):
- PowerShell script を実行するための image
- Nano Server または Server Core ベースの version が利用可能

Windows container image を選択する際は、次を考慮してください。

Application requirements (必要な Windows APIs)
Image size と startup time
Security requirements
Windows version compatibility (image tag の version number を確認)

Windows container image は host OS と同じ version、または互換性のある version である必要があります。

Kubernetes で Windows node と Linux node が混在する cluster に DaemonSets を deploy する推奨方法は何ですか？
- A) 単一の DaemonSet を使用してすべての node に deploy する
- B) OS ごとに個別の DaemonSets を作成し、nodeSelector を使用する
- C) Windows node には DaemonSet の代わりに StatefulSet を使用する
- D) すべての DaemonSets に tolerations を追加する

回答を表示

回答: B) OS ごとに個別の DaemonSets を作成し、nodeSelector を使用する

解説: Kubernetes で Windows node と Linux node が混在する cluster に DaemonSets を deploy する推奨方法は、OS ごとに個別の DaemonSets を作成し、nodeSelector を使用することです。

この approach が必要な理由:

Windows container と Linux container は異なる image format を使用します。
同じ application でも OS ごとに異なる configuration が必要になる場合があります。
一部の機能は特定の OS でのみ利用できる場合があります。

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

単一の DaemonSet を使用すると、container image の互換性問題により、一部の node で Pod の起動に失敗する可能性があります。

DaemonSets は Windows node で使用できるため、StatefulSets に置き換える必要はありません。

すべての DaemonSets に tolerations を追加すると、taint された node に Pod を schedule するのに役立ちますが、OS の互換性問題は解決しません。

Windows node 上の Pod の DNS configuration について正しい記述はどれですか？
- A) DNS configuration は Windows node でサポートされていない
- B) Windows node は CoreDNS の代わりに Windows DNS Server を使用する必要がある
- C) Windows node は Linux node と同じ DNS configuration を使用できる
- D) Windows node では Pod ごとに個別の DNS server configuration が必要である

回答を表示

回答: C) Windows node は Linux node と同じ DNS configuration を使用できる

解説: Windows node は Linux node と同じ DNS configuration を使用できます。Kubernetes DNS service (通常は CoreDNS) は Windows Pod に対しても同じように機能します。

Windows Pod の DNS configuration:

/etc/resolv.conf に相当する configuration が Windows Pod 内に自動的に作成されます。
Pod は cluster の DNS service (CoreDNS) を使用して service name を解決できます。
dnsPolicy と dnsConfig field を使用して 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"

Windows node で DNS を使用する際の考慮事項:

Windows container 内の DNS client behavior は Linux とわずかに異なる場合があります。
一部の DNS 関連 tool (例: nslookup、Resolve-DnsName) は Windows container でデフォルトで利用できます。
network plugin が DNS resolution を正しくサポートしていることを確認する必要があります。

Windows node で個別の DNS server を構成したり、Windows DNS Server を使用したりする必要はありません。Kubernetes の標準 DNS mechanism は Windows Pod でも機能します。

Windows node 上の pod-to-pod communication について正しい記述はどれですか？
- A) pod-to-pod communication は Windows node でサポートされていない
- B) Windows node 上の Pod は同じ node 上の Pod としか通信できない
- C) Windows node 上の Pod は Linux node 上の Pod と通信できない
- D) Windows node 上の Pod は CNI plugin を通じて他のすべての Pod と通信できる

回答を表示

回答: D) Windows node 上の Pod は CNI plugin を通じて他のすべての Pod と通信できる

解説: Windows node 上の Pod は、適切な CNI (Container Network Interface) plugin を通じて cluster 内の他のすべての Pod と通信できます。これには、同じ Windows node 上の Pod、他の Windows node 上の Pod、Linux node 上の Pod が含まれます。

Windows node 上の pod-to-pod communication の主な特徴:

Windows node 上の Pod は cluster 内の service を name で discovery し、access できます。
Windows node 上の Pod には cluster IP address range 内の一意の IP address が割り当てられます。
pod-to-pod communication は、選択した CNI plugin の実装に従って行われます。

Windows node 上の pod-to-pod communication をサポートする CNI plugin:

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

たとえば、Flannel を使用する場合:

Windows node 上の Pod は VXLAN encapsulation を通じて他の node 上の Pod と通信します。
各 Pod には cluster CIDR range 内の IP address が割り当てられます。
routing table は Pod IP address を適切な node に route するよう構成されます。

Windows node 上の pod-to-pod communication に関する考慮事項:

一部の advanced networking features は Windows で制限される場合があります。
NetworkPolicy support は CNI plugin によって異なる場合があります。
Windows firewall rules が Pod communication を妨げないようにする必要があります。

Windows node 上の Pod は Linux node 上の Pod と問題なく通信でき、これは Kubernetes の core feature の 1 つです。

Kubernetes における Windows container の resource limits について正しい記述はどれですか？
- A) Windows container は resource limits をサポートしていない
- B) CPU limits はサポートされるが memory limits はサポートされない
- C) Memory limits はサポートされるが CPU limits はサポートされない
- D) CPU と memory limits の両方がサポートされる

回答を表示

回答: D) CPU と memory limits の両方がサポートされる

解説: Kubernetes の Windows container は CPU と memory の resource limits の両方をサポートしています。Windows node は Linux node と同様の方法で container resource の limit と request を設定できます。

Windows container の resource limits の例:

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"

Windows container の resource management の特徴:

CPU limits: Windows は container 間の CPU resource allocation を管理するために CPU sharing と limits を実装しています。
Memory limits: Windows は container の memory usage を制限し、超過時に OOM (Out of Memory) termination を実行します。
Resource monitoring: kubelet は Windows container の resource usage を監視し、Kubernetes API に報告します。

Windows container の resource management に関する考慮事項:

Windows container の default resource overhead は Linux container より大きい場合があります。
resource limits の正確な実装は Windows version によって異なる場合があります。
memory limits を低く設定しすぎると、Windows container が正常に動作しない場合があります。
Hyper-V isolation mode を使用する場合は追加の resource overhead が発生します。

Windows node の resource usage は kubectl top pods と kubectl top nodes commands を使用して監視できます。

## 短答問題

Kubernetes cluster に Windows node を追加するための主な手順と要件を説明してください。

回答を表示

回答:

Kubernetes Cluster に Windows Node を追加する手順:

前提条件の確認:
- Kubernetes version 1.14 以降 (最新 version 推奨)
- control plane は Linux node 上で実行する必要がある
- Windows Server 2019 以降 (Windows Server 2022 推奨)
- 互換性のある CNI plugin (Flannel、Calico、Antrea など)

Networking の構成:

Windows node をサポートする CNI plugin を install する
cluster CIDR と 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
      }
    }

Windows Node の準備:

Windows Server を install して update する

必要な Windows features を有効化する:

powershell

Install-WindowsFeature -Name Containers
Restart-Computer -Force

container runtime を install する (containerd 推奨):

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

kubelet と kube-proxy の install:

Kubernetes binaries を download する:

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

kubelet configuration file を作成する:

powershell

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

kubelet service を register して start する:

powershell

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

kube-proxy を構成して start する (通常は DaemonSet として deploy)

Node の Join:
- kubeadm join command を実行するか、TLS certificates と kubeconfig を手動で構成する
- node が cluster に register されたことを確認する:
  bash
```
kubectl get nodes
```
Node Labels の追加:
- Windows node に OS label を追加する (自動で追加されない場合):
  bash
```
kubectl label node <windows-node-name> kubernetes.io/os=windows
```

Test Workload の Deploy:

Windows container を実行する簡単な Pod を deploy する:

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"

重要な考慮事項:

Version Compatibility:
- Windows Server version と container image version は互換性が必要です
- Kubernetes version と Windows support features を確認します
Networking:
- Windows node でサポートされている CNI plugin を使用します
- network policy support を確認します
- port requirements (kubelet、containerd、CNI など) を確認します
Storage:
- Windows node でサポートされる storage driver と volume type を確認します
- CSI driver compatibility を確認します
Monitoring and Logging:
- Windows node に適した monitoring agents を deploy します
- Windows event log collection を構成します
Security:
- Windows firewall rules を構成します
- 必要に応じて Group Managed Service Accounts (gMSA) を設定します
- network security groups を構成します
Automation:
- Windows node provisioning を自動化します (Ansible、PowerShell DSC など)
- node upgrade strategy を確立します

Windows container と Linux container の主な違い、および Kubernetes でこれらの違いを管理する方法を説明してください。

回答を表示

回答:

Windows Container と Linux Container の主な違い:

Underlying Technology:
- Linux containers: isolation に Linux namespaces、cgroups、kernel features を使用します
- Windows containers: Windows isolation technologies (job objects、Hyper-V isolation など) を使用します
Image Structure:
- Linux containers: 比較的小さい size (数十〜数百 MB)
- Windows containers: 一般的に size が大きい (数 GB)、base images が大きい
Isolation Modes:
- Linux containers: 単一の isolation mode (namespace-based)
- Windows containers: 2 つの mode をサポート: process isolation と Hyper-V isolation
File System:
- Linux containers: layered file system (OverlayFS など)
- Windows containers: NTFS-based filter driver
Networking:
- Linux containers: さまざまな networking modes と driver support
- Windows containers: networking modes は限定的で、特定の CNI plugin のみをサポート
Resource Management:
- Linux containers: cgroups による細粒度の resource control
- Windows containers: Job Objects による resource control、一部制限あり
Security Context:
- Linux containers: さまざまな security context options (SELinux、AppArmor など)
- Windows containers: security context options は限定的で、privileged containers はサポートされない
Host OS Dependency:
- Linux containers: さまざまな Linux distribution で実行可能
- Windows containers: host OS と同じ、または互換性のある version が必要

Kubernetes でこれらの違いを管理する方法:

Node Selection and Scheduling:

node labels を使用: kubernetes.io/os=windows または kubernetes.io/os=linux

nodeSelector を使用:

yaml

nodeSelector:
  kubernetes.io/os: windows

node affinity を使用:

yaml

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

Workload Separation:

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:

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:
- multi-architecture images を使用: 同じ tag でさまざまな OS/architecture をサポート
- OS-specific image tags を使用: myapp:linux と myapp:windows
- image pull policy を設定: imagePullPolicy: Always

Resource Requests and Limits:

各 OS に適切な resources を設定:

yaml

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

Networking:

互換性のある CNI plugin を選択: Flannel、Calico、Antrea など

network policies を適用する際に OS を考慮:

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:

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:

各 OS に適切な security settings を適用:

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:
- OS-specific monitoring agents を deploy
- log collection paths を調整: Windows (C:\k\logs) vs Linux (/var/log)
CI/CD Pipelines:
- OS-specific build and test pipelines を構成
- multi-OS deployment strategy を確立

Windows container で Group Managed Service Accounts (gMSA) を使用する方法とその benefits を説明してください。

回答を表示

回答:

Group Managed Service Accounts (gMSA) 概要:

Group Managed Service Accounts (gMSA) は、Windows domain environment における service authentication のための特別な種類の Active Directory account です。Kubernetes の Windows container で gMSA を使用すると、domain authentication を必要とする application を実行でき、特に次の scenarios で有用です。

Active Directory integration を必要とする .NET applications
Windows authentication を使用する SQL Server connections
Kerberos authentication を必要とする services
domain resources への access が必要な applications

Windows Containers で gMSA を使用する方法:

Prerequisites:
- Active Directory domain controller
- Windows node は domain に join されている必要がある
- Kubernetes version 1.14 以降
- containerd または Docker container runtime

Active Directory で gMSA を設定:

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"

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

Credential Spec を Kubernetes Secret として保存:

bash

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

Pod Definition に gMSA Configuration を追加:

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

gMSA Usage を確認:

powershell

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

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

gMSA を使用する Benefits:

Enhanced Security:
- container 内の hardcoded credentials を排除
- 自動 password management と rotation
- principle of least privilege の適用を可能にする
Active Directory Integration:
- Windows authentication を使用する既存 application の container 化を可能にする
- Kerberos と NTLM authentication をサポート
- domain resources への seamless access
Centralized Identity Management:
- Active Directory による unified identity management
- Group policies を適用可能
- auditing と compliance の向上
Application Compatibility:
- domain authentication を必要とする legacy .NET applications をサポート
- Windows integrated authentication を使用する SQL Server connections をサポート
- IIS web applications の Windows authentication をサポート
Simplified Operations:
- automated credential management
- container restart 後も credentials が保持される
- 同じ identity を複数の container 間で共有可能

gMSA 使用時の考慮事項:

Network Requirements:
- Windows node から domain controller への network connectivity が必要
- 適切な DNS configuration が必要
- 必要な port を開放する必要がある (Kerberos、LDAP など)
Permission Management:
- gMSA には最小限必要な permissions のみを付与
- 適切な group memberships を構成
- 定期的な permission reviews
Scalability:
- 大規模 cluster では domain controller load を考慮
- permission separation のために複数の gMSA accounts を使用
Troubleshooting:
- domain connectivity issues を debug
- credential spec configuration errors を確認
- container runtime logs を review

Kubernetes の Windows node に対する logging と monitoring の構成方法、および Linux node との違いを説明してください。

回答を表示

回答:

Windows Node の Logging と Monitoring の構成:

1. Logging Configuration:

Windows Node の主な Logging Sources:

Windows Event Logs (System、Application、Security)
ETW (Event Tracing for Windows) events
Application log files (通常は C:\ drive 内)
kubelet と container runtime logs (通常は C:\k\logs または類似の paths)

Windows Node Logging を構成する方法:

Fluent Bit または 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 または Windows Event Log

2. Monitoring Configuration:

Windows Node Monitoring の主な Metrics:

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

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:
- Windows node metrics 用の dedicated dashboards を作成
- Windows-specific panels (例: page file usage、service status など) を追加

3. Troubleshooting Tools:

Windows Node Troubleshooting 用 Tools:

PowerShell commands (Get-Process、Get-Service、Get-EventLog)
Windows Performance Monitor (PerfMon)
Event Viewer
kubectl debug command (Windows node では support が限定的)

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

Linux Node との主な違い:

Log Storage Location:
- Linux: /var/log/ directory に text files として保存
- Windows: Windows Event Logs (binary format) とさまざまな locations の text files
Log Collection Mechanism:
- Linux: file-based log collection が一般的 (tail、read)
- Windows: Windows Event Log API を通じた collection が必要
Metric Collection:
- Linux: /proc、/sys file systems から metrics を収集
- Windows: WMI (Windows Management Instrumentation) または Performance Counter API を使用
Container Logs:
- Linux: standard output/error が files に redirect される
- Windows: ETW または file-based logging、path structure が異なる
Resource Monitoring:
- Linux: cgroups による container resource usage monitoring
- Windows: Job Objects による resource monitoring、一部 metrics の計算方法が異なる
Monitoring Agents:
- Linux: さまざまな agent support (node-exporter、cAdvisor など)
- Windows: agent support は限定的で、Windows-specific agents が必要
Debugging Tools:
- Linux: さまざまな CLI tools (ps、top、netstat、strace など)
- Windows: PowerShell commands、GUI tools、限定的な CLI tools

Best Practices:

Integrated Logging Solution:
- EFK (Elasticsearch、Fluent Bit、Kibana) または ELK stack を使用
- Windows node と Linux node の両方に対して separate configurations
Integrated Monitoring Solution:
- Prometheus + Grafana ですべての node を監視
- OS-specific dashboards を作成
Alert Configuration:
- Windows-specific events 用の alert rules を設定
- critical Windows service status を監視
Log Retention Policy:
- Windows event log size と retention period を構成
- log rotation policy を構成
Security Monitoring:
- Windows security event logs を収集して analyze
- permission changes と login attempts を監視

Kubernetes の Windows container における storage options と volume mount configuration methods を説明してください。

回答を表示

回答:

Windows Container の Storage Options:

1. Basic Volume Types:

emptyDir:
- Pod lifetime 中に temporary data を保存
- Windows node の local NTFS volume 上に作成
- Pod が削除されると data も削除される
yaml
```
volumes:
- name: temp-data
  emptyDir: {}
```
hostPath:
- Windows node の file system への direct access
- Windows path format を使用する必要がある (backslashes を escape)
- data は node 間で共有できない
yaml
```
volumes:
- name: logs
  hostPath:
    path: C:\\Logs
    type: DirectoryOrCreate
```
configMap and secret:
- configuration data と sensitive information を保存
- Windows container でも同じように機能
- file permission settings は Windows では異なる方法で適用される
yaml
```
volumes:
- name: config
  configMap:
    name: app-config
```
persistentVolumeClaim (PVC):
- persistent storage を request
- Windows-compatible storage class が必要
- CSI driver support の確認が必要
yaml
```
volumes:
- name: data
  persistentVolumeClaim:
    claimName: windows-pvc
```

2. Windows Containers をサポートする Storage Solutions:

Azure Disk/File (AKS):

Azure Kubernetes Service は Windows node をサポート
SMB protocol-based Azure Files を使用可能
Azure Disk CSI driver をサポート

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 が利用可能
access は単一 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:

Windows environment に適した network file system
FlexVolume または CSI driver が必要
複数 Pod にまたがる ReadWriteMany access をサポート

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:

Windows node 上で iSCSI initiator configuration が必要
block storage access を提供
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. Windows Container の Volume Mount Configuration:

Volume Mount Paths:
- Windows container は Windows path format を使用
- 通常は C:\ drive 内の path を使用
- YAML では path 内の backslashes を escape する必要がある
yaml
```
volumeMounts:
- name: data
  mountPath: C:\\data
```
Read-Only Mounts:
- Windows container でサポートされる
- NTFS permissions を通じて適用される
yaml
```
volumeMounts:
- name: config
  mountPath: C:\\config
  readOnly: true
```
Subpath Mounts:
- volume の特定の subpath のみを mount 可能
- 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. Windows Container Storage 使用時の考慮事項:

Path Separators:
- Windows は backslashes (\) を使用するが、YAML では escaping が必要
- 代わりに forward slashes (/) も使用できるが、application compatibility を確認する
File Permissions:
- Windows は NTFS permission model を使用
- Linux の chmod/chown のように permissions を設定できない
- container 内の permissions は container user context によって決まる
Performance Considerations:
- Network storage (SMB/CIFS) は latency がある場合がある
- high-performance requirements には local storage または direct-attached block storage を推奨
Storage Class Compatibility:
- Windows node と互換性のある storage classes を確認
- CSI drivers の Windows support を確認
Backup and Recovery:
- Windows Volume Shadow Copy Service (VSS) integration を考慮
- application-consistent backup mechanisms を実装

ハンズオン問題

Windows node と Linux node が混在する Kubernetes cluster 向けに、次の要件を満たす Deployment manifest を作成してください:
- 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: ConfigMap "web-config" を C:\inetpub\wwwroot\web.config にマウント

回答を表示

回答:

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

解説:

Deployment Resource:
- Windows node のみに scheduling するよう nodeSelector を使用
- 要件どおり replicas を 2 に設定
- IIS web server image を使用
Container Configuration:
- port 80 を expose
- environment variable WEBSITE_NAME を設定
- ConfigMap を特定の file path に mount (Windows path format を使用)
Volume Configuration:
- ConfigMap を volume として mount
- subPath を使用して ConfigMap の特定 key を file として mount
Service Definition:
- application に access するための ClusterIP service を作成
- port 80 経由で access 可能

Notes:

Windows paths では backslashes (\) が YAML の escape characters として扱われるため注意してください。この例では通常の backslashes を使用していますが、より複雑な path では double backslashes (\\) または forward slashes (/) を使用できます。
Windows container は Linux container より resource requirements が高い場合があるため、production environment では適切な resource requests と limits を設定することが good practice です。

Windows node と Linux node の両方で実行される monitoring agent を deploy する DaemonSet manifest を作成してください。各 OS は適切な image と configuration を使用する必要があります。

回答を表示

回答:

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

解説:

DaemonSet for Linux Nodes:
- Linux node のみに schedule するために nodeSelector を使用
- Prometheus Node Exporter image を使用
- system metrics を収集するために host の /proc、/sys、/ directories を mount
- non-root user として実行するよう security context を構成
DaemonSet for Windows Nodes:
- Windows node のみに schedule するために nodeSelector を使用
- Windows Exporter image を使用
- 収集する metric collectors を指定
- Windows-specific configuration を適用
Common Service:
- 両方の DaemonSets の Pod を select する service を作成
- Linux と Windows の metrics ports の両方を expose
- Prometheus はこの service 経由で metrics を scrape 可能

Notes:

各 OS に適した images と configurations を使用することが重要です。
Linux node と Windows node では metric collection methods が異なるため、異なる DaemonSets に分離しています。
labels を使用して OS types を区別すると、monitoring system で metrics を filter したり visualize したりする際に便利です。
production environment では、resource requests と limits、security contexts、service accounts などの追加構成が必要です。

Windows container で Active Directory authentication を使用する .NET application を deploy する Pod manifest を作成してください。Group Managed Service Accounts (gMSA) を使用する必要があります。

回答を表示

回答:

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

解説:

gMSA Credential Spec Secret:
- Active Directory gMSA credential spec を Base64 encode して secret として保存
- この secret は Pod による domain authentication に使用される
Windows Pod Configuration:
- Windows node に schedule するために nodeSelector を使用
- securityContext.windowsOptions.gmsaCredentialSpecName を使用して gMSA credential spec を参照
- .NET application image を使用
- 適切な resource requests と limits を設定
Volumes and Configuration:
- ConfigMap を使用して application settings を提供
- Windows path format を使用して configuration file を mount
- Windows integrated authentication を使用する SQL Server connection string を含む
Service Definition:
- application に access するための ClusterIP service を作成

gMSA Setup の Prerequisites:

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"

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

Credential Spec を Kubernetes Secret に変換:

bash

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

# Add encoded value to secret YAML

Notes:

Windows node は Active Directory domain に join されている必要があります。
containerd または Docker は gMSA をサポートするよう構成されている必要があります。
実際の environment では、credential spec contents を安全に管理する必要があります。
application は Windows authentication を正しく使用するよう構成されている必要があります。

Windows node と Linux node が混在する cluster で、次の要件を満たす NetworkPolicy manifest を作成してください:
- Windows web application pods (label: app=windows-web) は Linux database pods (label: app=linux-db) のみに access できる
- Database pods は port 3306 の access のみを許可する
- Web application pods は外部から port 80 で access 可能

回答を表示

回答:

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

解説:

Windows Web Application NetworkPolicy:
- label app=windows-web を持つ Pod に適用
- Ingress rule: port 80 で全 source からの access を許可
- Egress rule: label app=linux-db を持つ Pod の port 3306 への access のみを許可
Linux Database NetworkPolicy:
- label app=linux-db を持つ Pod に適用
- Ingress rule: label app=windows-web を持つ Pod から port 3306 への access のみを許可

Notes:

Network policies が機能するには、NetworkPolicy をサポートする CNI plugin (例: Calico、Antrea) が必要です。
Windows node 上の NetworkPolicy support は CNI plugin によって異なる場合があります。
この例では default namespace を想定していますが、実際の environment では適切な namespaces を指定してください。
production environment では、DNS lookups、external service access などのために追加の egress rules が必要になる場合があります。

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

Windows node 上で実行される .NET Framework application の Deployment manifest を作成してください。この application は Azure Blob Storage に access するために connection string を environment variable として必要とします。また、logs 用の persistent volume も構成してください。

回答を表示

回答:

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

解説:

Secret Configuration:
- Azure Storage connection string を Base64 encode して secret として保存
- application から environment variable として安全に access 可能
PersistentVolumeClaim:
- log files 用に 10GB の persistent storage を request
- Azure Disk storage class を使用 (environment に合わせて調整)
- ReadWriteOnce access mode を使用
Deployment Configuration:
- Windows node のみに schedule するために nodeSelector を使用
- .NET Framework application image を使用
- Azure Storage connection string を environment variables 経由で提供
- log directory 用に persistent volume を mount
- ConfigMap から web.config file を mount
- 適切な resource requests と limits を設定
- health checking 用に readiness と liveness probes を構成
ConfigMap Configuration:
- .NET Framework application 用の web.config file を提供
- application settings と configuration を含む
Service Definition:
- application に access するための ClusterIP service を作成

Notes:

実際の environment では、image registry addresses、storage classes、resource requirements などを environment に合わせて調整する必要があります。
.NET Framework applications は Windows Server Core based images を使用する必要があります。
production environment では、ingress controllers または load balancers を通じて external access を構成できます。
Azure Storage connection strings のような sensitive information は Azure Key Vault のような external secret management systems と統合する必要があります。

高度なトピック

Kubernetes の Windows node で containerd を container runtime として構成する際に最も重要な setting は何ですか？
- A) sandbox_image setting
- B) Log level と log path
- C) Memory limits と CPU sharing
- D) Image pull policy と registry configuration

回答を表示

回答: A) sandbox_image setting

解説: Kubernetes の Windows node で containerd を container runtime として構成する際に最も重要な setting は sandbox_image setting です。この setting は、Windows node 上の pod infrastructure container (pause container) として使用する image を指定します。

containerd configuration において Windows node で sandbox_image setting が重要な理由:

Pod Networking: pause container は Pod の network namespace を設定して維持します。Windows は Linux とは異なる networking stack を使用するため、Windows-specific pause image が必要です。
OS Compatibility: Linux pause images は Windows node では動作せず、Windows pause images は Linux node では動作しません。
Version Compatibility: Windows version (例: Windows Server 2019、Windows Server 2022) と互換性のある適切な pause image を選択する必要があります。

Windows node 用 containerd configuration の例:

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"

よく使用される 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

他の options も重要ですが、sandbox_image が最も critical です。

Log level と log path は debugging に有用ですが、機能上必須ではありません。
Memory limits と CPU sharing は performance tuning に重要ですが、基本機能には影響しません。
Image pull policy と registry configuration は image management に重要ですが、container runtime の基本動作には影響しません。

Windows container で Hyper-V isolation mode を使用する主な benefit は何ですか？
- A) より高い performance と低い resource usage
- B) host OS とは異なる Windows version の container を実行できること
- C) container 間の network communication speed の向上
- D) より多くの Windows APIs と features のサポート

回答を表示

回答: B) host OS とは異なる Windows version の container を実行できること

解説: Windows container で Hyper-V isolation mode を使用する主な benefit は、host OS とは異なる Windows version の container を実行できることです。これは Windows container の重要な特徴の 1 つであり、modern infrastructure 上で legacy applications を実行する際に特に有用です。

Hyper-V isolation mode の主な benefits:

Version Compatibility:
- host OS と container OS の version mismatch issues を解決します。
- たとえば、Windows Server 2022 host 上で Windows Server 2019-based container を実行できます。
- これは process isolation mode では不可能です (process isolation では host と container が同じ kernel version を使用する必要があります)。
Enhanced Security Isolation:
- 各 container は軽量な virtual machine 内で実行され、より強力な isolation を提供します。
- container 間、および container と host 間の security boundaries が強化されます。
- multi-tenant environments や untrusted code を実行する場合に有用です。
Kernel-Level Isolation:
- 各 container は独自の Windows kernel instance を持ちます。
- これにより kernel-level isolation が提供され、1 つの container の kernel issues が他の container や host に影響しません。

Kubernetes で Hyper-V isolation mode を使用するには、次の annotation を 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

Hyper-V isolation mode の disadvantages:

より多くの resources (memory、CPU) を使用します。
startup time が長くなります。
host で Hyper-V feature が有効である必要があります。

他の options の問題:

Hyper-V isolation は実際には performance が低く、resource usage が高くなります (A は誤り)。
container 間の network communication は実際には process isolation mode の方が速くなります (C は誤り)。
Windows API と feature support は container OS version に依存し、Hyper-V isolation 自体がより多くの APIs を提供するわけではありません (D は誤り)。

Kubernetes で Windows node を使用する場合の pod networking について正しい記述はどれですか？
- A) Windows node は CNI plugin を使用せず、独自の networking stack を使用する
- B) Windows node は Linux node と同じ CNI plugin を使用するが、configuration は異なる
- C) Windows node は常に host network mode を使用する必要がある
- D) Windows node は overlay networks をサポートしない

回答を表示

回答: B) Windows node は Linux node と同じ CNI plugin を使用するが、configuration は異なる

解説: Kubernetes の Windows node は Linux node と同じ CNI (Container Network Interface) plugin を使用できますが、Windows は異なる networking stack を持つため configuration は異なります。これにより、各 OS の特性を考慮しながら、mixed OS cluster で一貫した networking model を実現できます。

Windows node 上の Pod networking の特徴:

CNI Plugin Support:
- Windows node は Flannel、Calico、Antrea など複数の CNI plugin をサポートします。
- これらの plugin は Linux node と Windows node の両方で動作するよう設計されています。
- 各 plugin は Windows-specific components または settings を提供します。
Networking Modes:
- Windows node は一般的に overlay networks (VXLAN、GENEVE など) をサポートします。
- L2bridge、L2tunnel、overlay など、さまざまな network modes をサポートします。
- Flannel の VXLAN mode は Windows node で広く使用されています。
Configuration Differences:
- Windows node は HNS (Host Network Service) を使用して network configuration を管理します。
- network endpoint の作成と管理方法は Linux と異なります。
- 一部の advanced networking features は 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
      }
    }

Windows node では追加 configuration が必要になる場合があります:

powershell

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

他の options の問題:

Windows node は CNI plugin を使用し、独自の networking stack のみを使用するわけではありません (A は誤り)。
Windows node は host network mode をサポートしません。hostNetwork: true は Windows Pod では動作しません (C は誤り)。
Windows node は overlay networks (VXLAN など) をサポートします (D は誤り)。

Kubernetes の Windows node における resource management について正しい記述はどれですか？
- A) Windows node は resource limits をサポートしない
- B) Windows node は Linux node より正確な resource limits を提供する
- C) Windows node は Job Objects を使用して resource limits を実装する
- D) Windows node は cgroups を使用して resource limits を実装する

回答を表示

回答: C) Windows node は Job Objects を使用して resource limits を実装する

解説: Kubernetes の Windows node は、Windows operating system の機能である Job Objects を使用して container の resource limits を実装します。これは cgroups を使用する Linux node とは対照的です。

Windows node 上の resource management の特徴:

Job Objects:
- Windows は Job Objects を使用して process groups の resource usage を制限します。
- Container runtime (containerd または Docker) は Job Objects API を使用して CPU と memory limits を適用します。
- Job Objects は process groups に対して CPU time、memory usage、work time などを制限できます。
CPU Limits:
- Windows の CPU limits は CPU sharing (weights) mechanism を通じて実装されます。
- これは Linux CPU sharing に似ていますが、実装は異なります。
- Windows は CPU cores の数に基づいて CPU sharing を調整します。
Memory Limits:
- Windows container の memory limits は Job Objects の memory limiting feature を通じて実装されます。
- container が memory limits を超えると、OOM (Out of Memory) termination が発生します。
- Windows memory management は Linux と異なるため、同じ memory limit value でも実際の behavior が異なる場合があります。
Resource Request and Limit Configuration:
- Windows Pod は Linux Pod と同じ方法で resource requests と limits を指定します:
  yaml
```
resources:
  requests:
    memory: "2Gi"
    cpu: "500m"
  limits:
    memory: "4Gi"
    cpu: "1"
```
- kubelet はこれらの values を Windows container runtime に渡し、runtime は Job Objects を使用して limits を適用します。
Monitoring and Reporting:
- kubelet は Windows performance counters を使用して container resource usage を監視します。
- この情報は kubectl top pods と kubectl top nodes commands を通じて確認できます。
- Metrics server はこの情報を収集し、Kubernetes API を通じて提供します。

Windows node 上の resource management に関する考慮事項:

Windows container は一般的に Linux container より多くの default resources を使用します。
Windows container の memory overhead は大きい場合があるため、十分な memory headroom を確保してください。
resource limits の正確な behavior は Windows version によって異なる場合があります。

他の options の問題:

Windows node は resource limits をサポートします (A は誤り)。
Windows node は一般的に Linux node より resource limits の精度が低くなります (B は誤り)。
Windows node は cgroups ではなく Job Objects を使用します (D は誤り)。

Kubernetes で Windows node を使用する際の security best practice として適切でないものはどれですか？
- A) security vulnerabilities を解決するために container images を定期的に scan して update する
- B) すべての Windows Pod で privileged mode を有効にする
- C) Active Directory integration のために gMSA (Group Managed Service Accounts) を使用する
- D) pod-to-pod communication を制限するために network policies を使用する

回答を表示

回答: B) すべての Windows Pod で privileged mode を有効にする

解説: 「すべての Windows Pod で privileged mode を有効にする」ことは、Kubernetes で Windows node を使用する際の適切な security best practice ではありません。実際には、Windows container は privileged mode をサポートしておらず、これを設定しようとすると Pod creation は失敗します。

この option が不適切な理由:

Privileged Mode Not Supported:
- Windows container は Linux container のような privileged mode の概念をサポートしていません。
- Windows は Linux とは異なる security model を持ち、container に host-level privileges を付与する仕組みがありません。
Violates Principle of Least Privilege:
- 仮にサポートされていたとしても、すべての Pod で privileged mode を有効にすることは principle of least privilege に違反します。
- 各 workload は必要最小限の permissions のみを持つべきです。
Increased Security Risk:
- privileged mode は container が host system に access することを許可し、security risks を大きく高めます。
- container escape vulnerability が発生した場合、host system 全体が risk にさらされる可能性があります。

他のすべての options は適切な security best practices です。

A) security vulnerabilities を解決するために container images を定期的に scan して update する:

image scanning は既知の vulnerabilities を特定して解決するために重要です。
Windows images は定期的な security updates を受ける必要があります。
image scanning tools を CI/CD pipelines に統合することは good practice です。

C) Active Directory integration のために gMSA (Group Managed Service Accounts) を使用する:

gMSA により、Windows container は Active Directory services に安全に authenticate できます。
hardcoded credentials の代わりに gMSA を使用すると security が向上します。
automatic password management と rotation functionality を提供します。

D) pod-to-pod communication を制限するために network policies を使用する:

network policies は network communication に principle of least privilege を適用します。
pod-to-pod communication を必要な場合のみに制限することで attack surface を減らします。
network segmentation は lateral movement attacks の防止に役立ちます。

Windows node security を強化するための追加 best practices:

Windows node を最新の security patches で最新状態に保つ
不要な Windows features と roles を無効化する
Windows firewall rules を適切に構成する
strong authentication mechanisms を使用する
container images から不要な tools と components を削除する
runtime security monitoring を実装する

エンドツーエンドのオブザーバビリティラボ

ArgoCD の詳細クイズ

Istio の詳細クイズ

Linkerd の詳細クイズ

Cilium サービスメッシュの詳細クイズ

Cilium 詳説

Calico 詳説

メトリクス

ログ記録

トレーシング

アラート通知

可観測性の演習

ArgoCD

トラフィック管理

セキュリティ

可観測性

レジリエンス

高度な設定

比較ガイド

メトリクス

ログ記録

トレーシング

アラート通知

Kubernetes における Windows クイズ ​

選択問題 ​

ハンズオン問題 ​

高度なトピック ​

Kubernetes における Windows クイズ

選択問題

ハンズオン問題

高度なトピック