# Kubernetes／Private AI CURRENT_STATUS: UNKNOWN OBSERVATION: SPEC_ONLY FRESHNESS: UNKNOWN PAGE_TYPE: reference CANONICAL_URL: /tools/ea-087-kubernetes-private-ai CLAIM_IDS: none EVIDENCE_IDS: EVD-EA-087-URL-D03FC373D69B, EVD-EA-087-URL-953450B4076F, EVD-EA-087-URL-72EE73FD95E8, EVD-EA-087-URL-D7631603C516, EVD-EA-087-URL-2FFF647653E4, EVD-EA-087-URL-88607476C706, EA-087-R11-RESEARCH, EA-087-R11-WEB-READBACK UNKNOWN_IDS: EA-087-UNKNOWN-01, EA-087-UNKNOWN-CURRENTNESS OPS_IDS: none ## Summary 「KubernetesはPrivate AIの共通control planeになり得、KServe等によりLLMを含むmodel servingを構成できる。ただしGPU driver/device plugin、network enforcement、model/runtime互換性、capacity、patching、observabilityは組織側の責任となる。『private』は配置場所ではなく、identity・network・data flow・supply chainを含む検証可能な運用境界として扱う。」 ## Current judgment 1. KubernetesはGPUをnative hardware abstractionだけで完結させない。administratorがvendor driverとdevice pluginを導入し、custom resourceとしてscheduleする。従って「Kubernetes対応＝GPU ready」ではない。 2. Private AIのsecurityはcluster内だから自動的に成立しない。Kubernetes NetworkPolicyは対応CNI/pluginがなければ作成してもenforcementされず、policy不在時はpod ingress/egressが既定でnon-isolatedである。 3. KServe v0.20は2026-08-06公開で、generative inferenceにvLLM/llm-d、LLMInferenceService、traffic splitting/canary、KV cache offload、tracing、DRA等を提供する実装例である。これはKubernetes上でLLM servingがproduction-oriented OSS stackとして成立している証拠だが、個別clusterのSLO/securityを保証しない。 4. generative workloadはpredictive serverlessと同じdeployment profileではない。KServe admin guide自身がgenerative workloadにより高いcompute/memory、streaming、GPUを挙げ、Standard Kubernetes Deployment/Gateway APIを推奨している。 5. Private AIの主要trade-offはdata localityだけではなく責任移転である。model image/weights、driver/CUDA等のcompatibility、Kubernetes/KServe/runtime upgrade、GPU capacity、autoscaling、network segmentation、secret/IAM、telemetry、backup、incident responseを組織側が所有する。 ## Scope Enterprise AI Core / infrastructure / implementation / organization overlay / governance / security / operability / non-LLM component ## Confirmed - KubernetesはGPUをnative hardware abstractionだけで完結させない。administratorがvendor driverとdevice pluginを導入し、custom resourceとしてscheduleする。従って「Kubernetes対応＝GPU ready」ではない。 - Private AIのsecurityはcluster内だから自動的に成立しない。Kubernetes NetworkPolicyは対応CNI/pluginがなければ作成してもenforcementされず、policy不在時はpod ingress/egressが既定でnon-isolatedである。 - KServe v0.20は2026-08-06公開で、generative inferenceにvLLM/llm-d、LLMInferenceService、traffic splitting/canary、KV cache offload、tracing、DRA等を提供する実装例である。これはKubernetes上でLLM servingがproduction-oriented OSS stackとして成立している証拠だが、個別clusterのSLO/securityを保証しない。 - generative workloadはpredictive serverlessと同じdeployment profileではない。KServe admin guide自身がgenerative workloadにより高いcompute/memory、streaming、GPUを挙げ、Standard Kubernetes Deployment/Gateway APIを推奨している。 - Private AIの主要trade-offはdata localityだけではなく責任移転である。model image/weights、driver/CUDA等のcompatibility、Kubernetes/KServe/runtime upgrade、GPU capacity、autoscaling、network segmentation、secret/IAM、telemetry、backup、incident responseを組織側が所有する。 ## UNKNOWN - EA-087-UNKNOWN-01: upstream vLLM exact current stable tag/commit（今回検索では派生hardware plugin情報が混在したため未固定）、Kubernetes current support window、主要CNIのNetworkPolicy feature差、KServe v0.20の各backend/hardware compatibility matrix。STOP_CONDITION: Kubernetes GPU scheduling、network enforcement boundary、KServe v0.20 generative serving、Private AI responsibility shiftが一次/author-maintained資料で確立したため初回bounded packetは完了。 --- - EA-087-UNKNOWN-CURRENTNESS: 外部根拠の再確認日がcanonical body/control-planeで確定していないため、currentnessはUNKNOWNとして保持する。日付を推測補完しない。 ## Evidence - EVD-EA-087-URL-D03FC373D69B (RESEARCH): 1. official project docs | Schedule GPUs | Kubernetes | — https://kubernetes.io/docs/tasks/manage-gpus/scheduling-gpus/ - EVD-EA-087-URL-953450B4076F (RESEARCH): 2. official project docs | Network Policies | Kubernetes | — https://kubernetes.io/docs/concepts/services-networking/network-policies/ - EVD-EA-087-URL-72EE73FD95E8 (RESEARCH): 3. author-maintained release/docs | Announcing KServe v0.20 | KServe | — https://github.com/kserve/website/blob/main/blog/2026-08-06-KServe-0.20-release.md - EVD-EA-087-URL-D7631603C516 (RESEARCH): 4. official project docs | Runtime Overview | KServe | — https://kserve.github.io/website/docs/model-serving/generative-inference/overview - EVD-EA-087-URL-2FFF647653E4 (RESEARCH): 5. official project docs | Understanding LLMInferenceService | KServe | — https://kserve.github.io/website/docs/model-serving/generative-inference/llmisvc/llmisvc-overview - EVD-EA-087-URL-88607476C706 (RESEARCH): 6. official project docs | KServe Administrator Guide | KServe | — https://kserve.github.io/website/docs/admin-guide/overview - EA-087-R11-RESEARCH (RESEARCH): EA-087 監査済みresearch / canonical revision binding - EA-087-R11-WEB-READBACK (IMPL): EA-087 Web body identity / canonical readback ## Failure / limits cluster内配置だけではdata residency、confidentiality、tenant isolation、egress controlの証明にならない。 ## Failure / limits NetworkPolicy YAMLの存在だけではenforcement証明にならない。CNI/plugin capabilityと実測が必要。 ## Failure / limits GPU resourceがschedule可能でもmodelがVRAMへ収まる、driver/runtime互換、期待throughputを満たすことは別問題。 ## Failure / limits KServe/vLLMの機能存在を任意model/hardware/backendの互換性へ一般化しない。 ## Failure / limits self-hostingはprovider outage依存を減らし得るが、patch lag、supply-chain、capacity shortage、operator errorを新たなfailure surfaceとして持つ。 ## Failure / limits OpenAI-compatible APIはsemantic/behavioral equivalenceを意味しない。 ## Practice Kubernetes version / CNI and NetworkPolicy enforcement / GPU vendor-driver-device-plugin / container runtime / node OS/kernel / CUDA-ROCm-XPU等runtime / KServe version / vLLM/backend compatibility / model license and weight access / registry access / storage class / Gateway/API / observability stack / secret/KMS / air-gap level / cluster capacity。 ## Practice OBSERVED_EXTERNALではなくOSS_PRACTICEとして、Kubernetes GPU scheduling + KServe v0.20 generative servingを確認。PROPOSAL: `PRIVATE_AI_DEPLOYMENT_CONTRACT` をCore候補とする。fields: cluster/version, node image/kernel, accelerator/driver/plugin, model ID/revision/license/hash, inference runtime/version/image digest, serving CRD/config, quantization, replicas/parallelism, storage/weight source, ingress/gateway, authn/authz, NetworkPolicy+CNI enforcement evidence, egress policy, secrets/KMS, telemetry destinations, autoscaling/capacity, upgrade/rollback, SBOM/signature, backup/restore, SLO and incident owner。 ## Practice TEST_PROFILE（未実施）: single-node/multi-node、cold model load、steady concurrency、burst、node drain、pod restart、GPU loss/OOM、network partition、registry unavailable、model storage unavailable、CNI deny/allow fixture、unauthorized namespace access、upgrade/canary/rollbackを実施。TTFT、tokens/s、throughput/GPU、VRAM headroom、queue time、recovery time、failed request rate、cross-namespace unauthorized reachability、egress leakage、rollout error、cost/GPU-hour、operator toilを別軸化。 ## Practice Security: default-deny ingress/egress、service identity/RBAC、network enforcement実測、signed image/SBOM、secret rotation、model weight accessを要求。Privacy: telemetry/log/traces/KV cache/vector DBへのdata spillを対象化。Audit: model hash、container digest、cluster config、policy、request traceを結ぶ。Cost: GPU purchase/reservation/idle、storage/network、operator/SRE、upgrade/test costを含むTCOで比較。Operability: capacity planning、driver/runtime matrix、canary、rollback、backup/restore、security patch SLAが必須。 ## Practice EA-088 GPU/NPU Capacity Planningへ、accelerator/driver/runtime/model compatibility matrixとthroughput/VRAM測定を引き渡す。 ## Practice EA-090 Air-gapped AIではregistry/model/OS/package/update経路を切断した場合のartifact promotionとpatch運用を追加採集する。 ## Practice KServe/vLLM exact current release、Kubernetes current supported minor、CNI実装差は公開後更新時に再pinする。 ## Practice managed Kubernetes/private cloud/on-premを同義にせずorganization overlayで分離する。 ## WHY_THIS_MATTERS_TO_UPDATE Private AIは「クラウドを使わない」ことではなく、model weights、inference runtime、retrieval store、network、identity、telemetry、upgradeを組織側がより多く管理する運用形態である。Kubernetesはその共通control planeになり得るが、GPU plugin、model serving、network policy、storage、supply chain、observabilityまで責任が組織へ戻る。 ## SCOPE_ROUTING Enterprise AI Core / infrastructure / implementation / organization overlay / governance / security / operability / non-LLM component ## CLAIM_OR_RESEARCH_QUESTION KubernetesをPrivate AIの共通substrateとして採用する際、何がplatform capabilityで、何が追加component/organization responsibilityか。KServe/vLLM等のmodel servingを含め、private deploymentを「安全・可用」と断定しないための境界は何か。 ## EVIDENCE TABLE 1. official project docs | Schedule GPUs | Kubernetes | https://kubernetes.io/docs/tasks/manage-gpus/scheduling-gpus/ | accessed 2026-09-16 | GPU scheduling stable since Kubernetes v1.26 | locator: GPU access via device plugins; vendor drivers/device plugin must be installed by administrator; GPU custom resources exposed to pods | VERIFIED_SPEC | support + implementation limit 2. official project docs | Network Policies | Kubernetes | https://kubernetes.io/docs/concepts/services-networking/network-policies/ | accessed 2026-09-16 | current docs | locator: NetworkPolicy requires network plugin that enforces it; without implementation resource has no effect; default pods are non-isolated absent policy | VERIFIED_SPEC | support + security limit 3. author-maintained release/docs | Announcing KServe v0.20 | KServe | https://github.com/kserve/website/blob/main/blog/2026-08-06-KServe-0.20-release.md | published 2026-08-06 | v0.20 | locator: confidential model serving, traffic splitting, canary, KV cache offloading, distributed tracing, managed DRA | OSS_PRACTICE / PRODUCT_VOLATILE | support 4. official project docs | Runtime Overview | KServe | https://kserve.github.io/website/docs/model-serving/generative-inference/overview | accessed 2026-09-16 | v0.20 docs | locator: Hugging Face runtime uses vLLM; supports generation, embeddings, reranking; OpenAI-compatible endpoints; continuous batching/PagedAttention etc. | OSS_PRACTICE | support 5. official project docs | Understanding LLMInferenceService | KServe | https://kserve.github.io/website/docs/model-serving/generative-inference/llmisvc/llmisvc-overview | accessed 2026-09-16 | v0.20 | locator: Kubernetes CRD; vLLM/llm-d; intelligent routing, disaggregated prefill-decode, distributed inference, monitoring/RBAC/storage integration | OSS_PRACTICE | support + context 6. official project docs | KServe Administrator Guide | KServe | https://kserve.github.io/website/docs/admin-guide/overview | accessed 2026-09-16 | v0.20 | locator: Standard InferenceService recommended for GPU/production; Knative/serverless mode for predictive scale-to-zero; LLMInferenceService for advanced generative workloads | OSS_PRACTICE | context + limit ## FINDINGS 1. KubernetesはGPUをnative hardware abstractionだけで完結させない。administratorがvendor driverとdevice pluginを導入し、custom resourceとしてscheduleする。従って「Kubernetes対応＝GPU ready」ではない。 2. Private AIのsecurityはcluster内だから自動的に成立しない。Kubernetes NetworkPolicyは対応CNI/pluginがなければ作成してもenforcementされず、policy不在時はpod ingress/egressが既定でnon-isolatedである。 3. KServe v0.20は2026-08-06公開で、generative inferenceにvLLM/llm-d、LLMInferenceService、traffic splitting/canary、KV cache offload、tracing、DRA等を提供する実装例である。これはKubernetes上でLLM servingがproduction-oriented OSS stackとして成立している証拠だが、個別clusterのSLO/securityを保証しない。 4. generative workloadはpredictive serverlessと同じdeployment profileではない。KServe admin guide自身がgenerative workloadにより高いcompute/memory、streaming、GPUを挙げ、Standard Kubernetes Deployment/Gateway APIを推奨している。 5. Private AIの主要trade-offはdata localityだけではなく責任移転である。model image/weights、driver/CUDA等のcompatibility、Kubernetes/KServe/runtime upgrade、GPU capacity、autoscaling、network segmentation、secret/IAM、telemetry、backup、incident responseを組織側が所有する。 ## LIMITS / COUNTEREVIDENCE / FAILURE ENVELOPE - cluster内配置だけではdata residency、confidentiality、tenant isolation、egress controlの証明にならない。 - NetworkPolicy YAMLの存在だけではenforcement証明にならない。CNI/plugin capabilityと実測が必要。 - GPU resourceがschedule可能でもmodelがVRAMへ収まる、driver/runtime互換、期待throughputを満たすことは別問題。 - KServe/vLLMの機能存在を任意model/hardware/backendの互換性へ一般化しない。 - self-hostingはprovider outage依存を減らし得るが、patch lag、supply-chain、capacity shortage、operator errorを新たなfailure surfaceとして持つ。 - OpenAI-compatible APIはsemantic/behavioral equivalenceを意味しない。 ## AVAILABILITY_GATES Kubernetes version / CNI and NetworkPolicy enforcement / GPU vendor-driver-device-plugin / container runtime / node OS/kernel / CUDA-ROCm-XPU等runtime / KServe version / vLLM/backend compatibility / model license and weight access / registry access / storage class / Gateway/API / observability stack / secret/KMS / air-gap level / cluster capacity。 ## IMPLEMENTATION_STATE OBSERVED_EXTERNALではなくOSS_PRACTICEとして、Kubernetes GPU scheduling + KServe v0.20 generative servingを確認。PROPOSAL: `PRIVATE_AI_DEPLOYMENT_CONTRACT` をCore候補とする。fields: cluster/version, node image/kernel, accelerator/driver/plugin, model ID/revision/license/hash, inference runtime/version/image digest, serving CRD/config, quantization, replicas/parallelism, storage/weight source, ingress/gateway, authn/authz, NetworkPolicy+CNI enforcement evidence, egress policy, secrets/KMS, telemetry destinations, autoscaling/capacity, upgrade/rollback, SBOM/signature, backup/restore, SLO and incident owner。 ## BENCHMARK_OR_EVAL TEST_PROFILE（未実施）: single-node/multi-node、cold model load、steady concurrency、burst、node drain、pod restart、GPU loss/OOM、network partition、registry unavailable、model storage unavailable、CNI deny/allow fixture、unauthorized namespace access、upgrade/canary/rollbackを実施。TTFT、tokens/s、throughput/GPU、VRAM headroom、queue time、recovery time、failed request rate、cross-namespace unauthorized reachability、egress leakage、rollout error、cost/GPU-hour、operator toilを別軸化。 ## SECURITY / PRIVACY / AUDIT / COST / OPERABILITY Security: default-deny ingress/egress、service identity/RBAC、network enforcement実測、signed image/SBOM、secret rotation、model weight accessを要求。Privacy: telemetry/log/traces/KV cache/vector DBへのdata spillを対象化。Audit: model hash、container digest、cluster config、policy、request traceを結ぶ。Cost: GPU purchase/reservation/idle、storage/network、operator/SRE、upgrade/test costを含むTCOで比較。Operability: capacity planning、driver/runtime matrix、canary、rollback、backup/restore、security patch SLAが必須。 ## SAFE_WORDING_FOR_FUTURE_BOOK 「KubernetesはPrivate AIの共通control planeになり得、KServe等によりLLMを含むmodel servingを構成できる。ただしGPU driver/device plugin、network enforcement、model/runtime互換性、capacity、patching、observabilityは組織側の責任となる。『private』は配置場所ではなく、identity・network・data flow・supply chainを含む検証可能な運用境界として扱う。」 ## UPDATE_WORK_HANDOFF 1. EA-088 GPU/NPU Capacity Planningへ、accelerator/driver/runtime/model compatibility matrixとthroughput/VRAM測定を引き渡す。 2. EA-090 Air-gapped AIではregistry/model/OS/package/update経路を切断した場合のartifact promotionとpatch運用を追加採集する。 3. KServe/vLLM exact current release、Kubernetes current supported minor、CNI実装差は公開後更新時に再pinする。 4. managed Kubernetes/private cloud/on-premを同義にせずorganization overlayで分離する。 ## OPEN_UNKNOWN upstream vLLM exact current stable tag/commit（今回検索では派生hardware plugin情報が混在したため未固定）、Kubernetes current support window、主要CNIのNetworkPolicy feature差、KServe v0.20の各backend/hardware compatibility matrix。STOP_CONDITION: Kubernetes GPU scheduling、network enforcement boundary、KServe v0.20 generative serving、Private AI responsibility shiftが一次/author-maintained資料で確立したため初回bounded packetは完了。 --- NEXT: /agent/start.json STOP: This is a knowledge projection, not an execution order.