> For the complete documentation index, see [llms.txt](https://atomoh.gitbook.io/kubernetes/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://atomoh.gitbook.io/kubernetes/jp/kuizu/quizzes/10-windows-in-kubernetes-quiz.md). # Kubernetes における Windows クイズ このクイズでは、Kubernetes で Windows node（ノード）と workload を管理するための概念的および実践的な知識を確認します。Windows container の基本、Kubernetes における Windows node 構成、networking、storage、security、monitoring などのトピックを扱います。 ## 選択問題 1. 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 バージョンとの互換性を確認することが重要です。
2. 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 でサポートされていません)。
3. 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 で使用される用語ではありません。
4. 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 では動作しない場合があります。
5. 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 があります。
6. 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 は次のとおりです。 1. **Windows Server Core** (`mcr.microsoft.com/windows/servercore`): * 中程度のサイズの image (約 2〜4GB) * ほとんどの Windows application をサポート * .NET Framework、PowerShell などを含む * 最も広く使用されている Windows base image 2. **Nano Server** (`mcr.microsoft.com/windows/nanoserver`): * 非常に小さい image (約 100〜200MB) * Windows API support は限定的 * .NET Core application に適している * 最小限の attack surface 3. **.NET Framework** (`mcr.microsoft.com/dotnet/framework/runtime`): * .NET Framework application 向けの image * Server Core をベースにしている * 特定バージョンの .NET Framework を含む 4. **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 である必要があります。
7. 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 の互換性問題は解決しません。
8. 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 でも機能します。
9. 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 つです。
10. 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 を使用して監視できます。
\## 短答問題 1. Kubernetes cluster に Windows node を追加するための主な手順と要件を説明してください。
回答を表示 **回答:** **Kubernetes Cluster に Windows Node を追加する手順:** 1. **前提条件の確認:** * Kubernetes version 1.14 以降 (最新 version 推奨) * control plane は Linux node 上で実行する必要がある * Windows Server 2019 以降 (Windows Server 2022 推奨) * 互換性のある CNI plugin (Flannel、Calico、Antrea など) 2. **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 } } ``` 3. **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 ``` 4. **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) 5. **Node の Join:** * kubeadm join command を実行するか、TLS certificates と kubeconfig を手動で構成する * node が cluster に register されたことを確認する: ```bash kubectl get nodes ``` 6. **Node Labels の追加:** * Windows node に OS label を追加する (自動で追加されない場合): ```bash kubectl label node kubernetes.io/os=windows ``` 7. **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" ``` **重要な考慮事項:** 1. **Version Compatibility:** * Windows Server version と container image version は互換性が必要です * Kubernetes version と Windows support features を確認します 2. **Networking:** * Windows node でサポートされている CNI plugin を使用します * network policy support を確認します * port requirements (kubelet、containerd、CNI など) を確認します 3. **Storage:** * Windows node でサポートされる storage driver と volume type を確認します * CSI driver compatibility を確認します 4. **Monitoring and Logging:** * Windows node に適した monitoring agents を deploy します * Windows event log collection を構成します 5. **Security:** * Windows firewall rules を構成します * 必要に応じて Group Managed Service Accounts (gMSA) を設定します * network security groups を構成します 6. **Automation:** * Windows node provisioning を自動化します (Ansible、PowerShell DSC など) * node upgrade strategy を確立します
2. Windows container と Linux container の主な違い、および Kubernetes でこれらの違いを管理する方法を説明してください。
回答を表示 **回答:** **Windows Container と Linux Container の主な違い:** 1. **Underlying Technology:** * **Linux containers**: isolation に Linux namespaces、cgroups、kernel features を使用します * **Windows containers**: Windows isolation technologies (job objects、Hyper-V isolation など) を使用します 2. **Image Structure:** * **Linux containers**: 比較的小さい size (数十〜数百 MB) * **Windows containers**: 一般的に size が大きい (数 GB)、base images が大きい 3. **Isolation Modes:** * **Linux containers**: 単一の isolation mode (namespace-based) * **Windows containers**: 2 つの mode をサポート: process isolation と Hyper-V isolation 4. **File System:** * **Linux containers**: layered file system (OverlayFS など) * **Windows containers**: NTFS-based filter driver 5. **Networking:** * **Linux containers**: さまざまな networking modes と driver support * **Windows containers**: networking modes は限定的で、特定の CNI plugin のみをサポート 6. **Resource Management:** * **Linux containers**: cgroups による細粒度の resource control * **Windows containers**: Job Objects による resource control、一部制限あり 7. **Security Context:** * **Linux containers**: さまざまな security context options (SELinux、AppArmor など) * **Windows containers**: security context options は限定的で、privileged containers はサポートされない 8. **Host OS Dependency:** * **Linux containers**: さまざまな Linux distribution で実行可能 * **Windows containers**: host OS と同じ、または互換性のある version が必要 **Kubernetes でこれらの違いを管理する方法:** 1. **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 ``` 2. **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 ``` 3. **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 ``` 4. **Image Management:** * **multi-architecture images を使用**: 同じ tag でさまざまな OS/architecture をサポート * **OS-specific image tags を使用**: `myapp:linux` と `myapp:windows` * **image pull policy を設定**: `imagePullPolicy: Always` 5. **Resource Requests and Limits:** * **各 OS に適切な resources を設定**: ```yaml resources: requests: memory: "2Gi" # Windows containers typically need more memory cpu: "500m" limits: memory: "4Gi" cpu: "1" ``` 6. **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 ``` 7. **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 ``` 8. **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 ``` 9. **Monitoring and Logging:** * **OS-specific monitoring agents を deploy** * **log collection paths を調整**: Windows (`C:\k\logs`) vs Linux (`/var/log`) 10. **CI/CD Pipelines:** * **OS-specific build and test pipelines を構成** * **multi-OS deployment strategy を確立**
3. 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 を使用する方法:** 1. **Prerequisites:** * Active Directory domain controller * Windows node は domain に join されている必要がある * Kubernetes version 1.14 以降 * containerd または Docker container runtime 2. **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" ``` 3. **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 ``` 4. **Credential Spec を Kubernetes Secret として保存:** ```bash kubectl create secret generic gmsa-k8s-secret --from-file=credspec.json=/path/to/gmsa-credspec.json ``` 5. **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 ``` 6. **gMSA Usage を確認:** ```powershell # Run inside container whoami # Output: EXAMPLE\gmsa-k8s$ nltest /sc_verify:example.com # Output: Trusted DC connections... Passed ``` **gMSA を使用する Benefits:** 1. **Enhanced Security:** * container 内の hardcoded credentials を排除 * 自動 password management と rotation * principle of least privilege の適用を可能にする 2. **Active Directory Integration:** * Windows authentication を使用する既存 application の container 化を可能にする * Kerberos と NTLM authentication をサポート * domain resources への seamless access 3. **Centralized Identity Management:** * Active Directory による unified identity management * Group policies を適用可能 * auditing と compliance の向上 4. **Application Compatibility:** * domain authentication を必要とする legacy .NET applications をサポート * Windows integrated authentication を使用する SQL Server connections をサポート * IIS web applications の Windows authentication をサポート 5. **Simplified Operations:** * automated credential management * container restart 後も credentials が保持される * 同じ identity を複数の container 間で共有可能 **gMSA 使用時の考慮事項:** 1. **Network Requirements:** * Windows node から domain controller への network connectivity が必要 * 適切な DNS configuration が必要 * 必要な port を開放する必要がある (Kerberos、LDAP など) 2. **Permission Management:** * gMSA には最小限必要な permissions のみを付与 * 適切な group memberships を構成 * 定期的な permission reviews 3. **Scalability:** * 大規模 cluster では domain controller load を考慮 * permission separation のために複数の gMSA accounts を使用 4. **Troubleshooting:** * domain connectivity issues を debug * credential spec configuration errors を確認 * container runtime logs を review
4. 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 を構成する方法:** 1. **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 ``` 2. **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 ``` 3. **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 を構成する方法:** 1. **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 ``` 2. **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 ``` 3. **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 との主な違い:** 1. **Log Storage Location:** * **Linux**: `/var/log/` directory に text files として保存 * **Windows**: Windows Event Logs (binary format) とさまざまな locations の text files 2. **Log Collection Mechanism:** * **Linux**: file-based log collection が一般的 (tail、read) * **Windows**: Windows Event Log API を通じた collection が必要 3. **Metric Collection:** * **Linux**: `/proc`、`/sys` file systems から metrics を収集 * **Windows**: WMI (Windows Management Instrumentation) または Performance Counter API を使用 4. **Container Logs:** * **Linux**: standard output/error が files に redirect される * **Windows**: ETW または file-based logging、path structure が異なる 5. **Resource Monitoring:** * **Linux**: cgroups による container resource usage monitoring * **Windows**: Job Objects による resource monitoring、一部 metrics の計算方法が異なる 6. **Monitoring Agents:** * **Linux**: さまざまな agent support (node-exporter、cAdvisor など) * **Windows**: agent support は限定的で、Windows-specific agents が必要 7. **Debugging Tools:** * **Linux**: さまざまな CLI tools (ps、top、netstat、strace など) * **Windows**: PowerShell commands、GUI tools、限定的な CLI tools **Best Practices:** 1. **Integrated Logging Solution:** * EFK (Elasticsearch、Fluent Bit、Kibana) または ELK stack を使用 * Windows node と Linux node の両方に対して separate configurations 2. **Integrated Monitoring Solution:** * Prometheus + Grafana ですべての node を監視 * OS-specific dashboards を作成 3. **Alert Configuration:** * Windows-specific events 用の alert rules を設定 * critical Windows service status を監視 4. **Log Retention Policy:** * Windows event log size と retention period を構成 * log rotation policy を構成 5. **Security Monitoring:** * Windows security event logs を収集して analyze * permission changes と login attempts を監視
5. Kubernetes の Windows container における storage options と volume mount configuration methods を説明してください。
回答を表示 **回答:** **Windows Container の Storage Options:** **1. Basic Volume Types:** 1. **emptyDir:** * Pod lifetime 中に temporary data を保存 * Windows node の local NTFS volume 上に作成 * Pod が削除されると data も削除される ```yaml volumes: - name: temp-data emptyDir: {} ``` 2. **hostPath:** * Windows node の file system への direct access * Windows path format を使用する必要がある (backslashes を escape) * data は node 間で共有できない ```yaml volumes: - name: logs hostPath: path: C:\\Logs type: DirectoryOrCreate ``` 3. **configMap and secret:** * configuration data と sensitive information を保存 * Windows container でも同じように機能 * file permission settings は Windows では異なる方法で適用される ```yaml volumes: - name: config configMap: name: app-config ``` 4. **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:** 1. **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 ``` 2. **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 ``` 3. **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 ``` 4. **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:** 1. **Volume Mount Paths:** * Windows container は Windows path format を使用 * 通常は `C:\` drive 内の path を使用 * YAML では path 内の backslashes を escape する必要がある ```yaml volumeMounts: - name: data mountPath: C:\\data ``` 2. **Read-Only Mounts:** * Windows container でサポートされる * NTFS permissions を通じて適用される ```yaml volumeMounts: - name: config mountPath: C:\\config readOnly: true ``` 3. **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:** 1. **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 ``` 2. **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 使用時の考慮事項:** 1. **Path Separators:** * Windows は backslashes (`\`) を使用するが、YAML では escaping が必要 * 代わりに forward slashes (`/`) も使用できるが、application compatibility を確認する 2. **File Permissions:** * Windows は NTFS permission model を使用 * Linux の chmod/chown のように permissions を設定できない * container 内の permissions は container user context によって決まる 3. **Performance Considerations:** * Network storage (SMB/CIFS) は latency がある場合がある * high-performance requirements には local storage または direct-attached block storage を推奨 4. **Storage Class Compatibility:** * Windows node と互換性のある storage classes を確認 * CSI drivers の Windows support を確認 5. **Backup and Recovery:** * Windows Volume Shadow Copy Service (VSS) integration を考慮 * application-consistent backup mechanisms を実装
## ハンズオン問題 1. 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 ``` **解説:** 1. **Deployment Resource**: * Windows node のみに scheduling するよう `nodeSelector` を使用 * 要件どおり replicas を 2 に設定 * IIS web server image を使用 2. **Container Configuration**: * port 80 を expose * environment variable `WEBSITE_NAME` を設定 * ConfigMap を特定の file path に mount (Windows path format を使用) 3. **Volume Configuration**: * ConfigMap を volume として mount * `subPath` を使用して ConfigMap の特定 key を file として mount 4. **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 です。
2. 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 ``` **解説:** 1. **DaemonSet for Linux Nodes**: * Linux node のみに schedule するために `nodeSelector` を使用 * Prometheus Node Exporter image を使用 * system metrics を収集するために host の `/proc`、`/sys`、`/` directories を mount * non-root user として実行するよう security context を構成 2. **DaemonSet for Windows Nodes**: * Windows node のみに schedule するために `nodeSelector` を使用 * Windows Exporter image を使用 * 収集する metric collectors を指定 * Windows-specific configuration を適用 3. **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 などの追加構成が必要です。
3. 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 ``` **解説:** 1. **gMSA Credential Spec Secret**: * Active Directory gMSA credential spec を Base64 encode して secret として保存 * この secret は Pod による domain authentication に使用される 2. **Windows Pod Configuration**: * Windows node に schedule するために `nodeSelector` を使用 * `securityContext.windowsOptions.gmsaCredentialSpecName` を使用して gMSA credential spec を参照 * .NET application image を使用 * 適切な resource requests と limits を設定 3. **Volumes and Configuration**: * ConfigMap を使用して application settings を提供 * Windows path format を使用して configuration file を mount * Windows integrated authentication を使用する SQL Server connection string を含む 4. **Service Definition**: * application に access するための ClusterIP service を作成 **gMSA Setup の Prerequisites:** 1. **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" ``` 2. **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 ``` 3. **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 を正しく使用するよう構成されている必要があります。
4. 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 ``` **解説:** 1. **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 のみを許可 2. **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 ```
5. 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: | --- # Service definition apiVersion: v1 kind: Service metadata: name: dotnet-framework-app spec: selector: app: dotnet-framework-app ports: - port: 80 targetPort: 80 type: ClusterIP ``` **解説:** 1. **Secret Configuration**: * Azure Storage connection string を Base64 encode して secret として保存 * application から environment variable として安全に access 可能 2. **PersistentVolumeClaim**: * log files 用に 10GB の persistent storage を request * Azure Disk storage class を使用 (environment に合わせて調整) * ReadWriteOnce access mode を使用 3. **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 を構成 4. **ConfigMap Configuration**: * .NET Framework application 用の web.config file を提供 * application settings と configuration を含む 5. **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 と統合する必要があります。
## 高度なトピック 1. 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 が重要な理由: 1. **Pod Networking**: pause container は Pod の network namespace を設定して維持します。Windows は Linux とは異なる networking stack を使用するため、Windows-specific pause image が必要です。 2. **OS Compatibility**: Linux pause images は Windows node では動作せず、Windows pause images は Linux node では動作しません。 3. **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 の基本動作には影響しません。
2. 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: 1. **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 を使用する必要があります)。 2. **Enhanced Security Isolation**: * 各 container は軽量な virtual machine 内で実行され、より強力な isolation を提供します。 * container 間、および container と host 間の security boundaries が強化されます。 * multi-tenant environments や untrusted code を実行する場合に有用です。 3. **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 は誤り)。
3. 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 の特徴: 1. **CNI Plugin Support**: * Windows node は Flannel、Calico、Antrea など複数の CNI plugin をサポートします。 * これらの plugin は Linux node と Windows node の両方で動作するよう設計されています。 * 各 plugin は Windows-specific components または settings を提供します。 2. **Networking Modes**: * Windows node は一般的に overlay networks (VXLAN、GENEVE など) をサポートします。 * L2bridge、L2tunnel、overlay など、さまざまな network modes をサポートします。 * Flannel の VXLAN mode は Windows node で広く使用されています。 3. **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 は誤り)。
4. 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 の特徴: 1. **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 などを制限できます。 2. **CPU Limits**: * Windows の CPU limits は CPU sharing (weights) mechanism を通じて実装されます。 * これは Linux CPU sharing に似ていますが、実装は異なります。 * Windows は CPU cores の数に基づいて CPU sharing を調整します。 3. **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 が異なる場合があります。 4. **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 を適用します。 5. **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 は誤り)。
5. 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 が不適切な理由: 1. **Privileged Mode Not Supported**: * Windows container は Linux container のような privileged mode の概念をサポートしていません。 * Windows は Linux とは異なる security model を持ち、container に host-level privileges を付与する仕組みがありません。 2. **Violates Principle of Least Privilege**: * 仮にサポートされていたとしても、すべての Pod で privileged mode を有効にすることは principle of least privilege に違反します。 * 各 workload は必要最小限の permissions のみを持つべきです。 3. **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 を実装する