# Cloud Native Operations

> Hands-on Kubernetes, Amazon EKS, and cloud-native operations guidebook —
> Linux/container foundations, Kubernetes core, EKS, networking, service mesh,
> storage, databases, data pipelines, AI/ML, security, GitOps, platform
> engineering, observability, and operations, with measured-on-AWS benchmark
> data. Korean (ko) is the primary human-edited language; English (en) mirrors
> its coverage. Full-content dumps: llms-full-ko.txt and llms-full-en.txt;
> per-section dumps (a few hundred KiB each) are listed under "Section
> bundles". Document links return raw Markdown with absolute URLs.

## Machine-readable catalog

- [Document manifest](https://www.atomai.click/kubernetes-docs/llms/manifest.json): JSON metadata with stable document IDs, language, section, canonical and Markdown URLs, update dates, byte lengths, and SHA-256 hashes for incremental LLM Wiki / RAG ingestion.

## Docs (한국어)

- [소개 · 가이드북 로드맵](https://www.atomai.click/kubernetes-docs/llms/ko/roadmap.md): 이 가이드북은 Linux 커널에서 시작해 컨테이너, Kubernetes, Amazon EKS, 네트워킹, 서비스 메시, 스토리지, 데이터베이스, 데이터 파이프라인, AI/ML, 그리고 보안·GitOps·플랫폼 엔지니어링·컨테이너 레지스트리·옵저버빌리티·운영까지 — 클라우드 네이티브…
- [소개 · LLM과 함께 읽기](https://www.atomai.click/kubernetes-docs/llms/ko/llm-guide.md): 이 가이드북은 llms.txt 제안 형식과 문서별 Markdown을 제공합니다. URL을 읽을 수 있는 AI 도구에는 색인을 전달하고, LLM Wiki나 RAG에는 문서 목록과 원문을 수집하며, 로컬 MCP 클라이언트에는 검색·본문 조회 도구를 연결할 수 있습니다.
- [소식](https://www.atomai.click/kubernetes-docs/llms/ko/news/README.md): Kubernetes, Amazon EKS와 CNCF 소식에 따른 문서 변경 이력입니다. GitHub Actions는 매주 월요일 09:00 KST에 갱신안을 만들고 품질 검사를 통과하면 PR을 엽니다. 실제 사이트에는 PR 검토·머지와 배포가 완료된 뒤 반영됩니다.
- [Linux & Container · Linux 기초](https://www.atomai.click/kubernetes-docs/llms/ko/basics/01-linux-basics.md): Kubernetes와 컨테이너 기술을 이해하기 위해서는 Linux에 대한 기본적인 이해가 필수적입니다. 이 문서에서는 Kubernetes 환경에서 특히 중요한 Linux의 핵심 개념들을 다룹니다.
- [Linux & Container · Linux 운영 기술](https://www.atomai.click/kubernetes-docs/llms/ko/basics/02-linux-advanced.md): 이 문서는 Kubernetes 환경에서 효과적으로 작업하기 위한 필수 Linux 운영 기술을 다룹니다.
- [Linux & Container · 컨테이너 기술](https://www.atomai.click/kubernetes-docs/llms/ko/basics/03-container-technology.md): 컨테이너는 애플리케이션과 그 종속성을 함께 패키징하여 다양한 환경에서 일관되게 실행할 수 있게 해주는 기술입니다. 이 문서에서는 컨테이너의 기본 개념, 작동 원리, 그리고 Kubernetes와의 관계에 대해 설명합니다.
- [Linux & Container · eBPF 기초와 실무 활용](https://www.atomai.click/kubernetes-docs/llms/ko/basics/05-ebpf-fundamentals.md): eBPF는 Linux 커널 내에서 샌드박스화된 프로그램을 실행할 수 있게 해주는 혁신적인 기술입니다. 이 문서에서는 eBPF의 기본 개념부터 Kubernetes 환경에서의 활용까지 전반적인 내용을 다룹니다.
- [Linux 커널 · Linux 커널 개요](https://www.atomai.click/kubernetes-docs/llms/ko/kernel/README.md): Kubernetes 문서는 대부분 선언적 API 위에서 설명됩니다. Pod를 만들면 컨테이너가 뜨고, Service를 만들면 트래픽이 분산되고, resource limit을 걸면 컨테이너가 그만큼만 씁니다.
- [Linux 커널 · 컨테이너를 지탱하는 커널 기능](https://www.atomai.click/kubernetes-docs/llms/ko/kernel/01-container-primitives.md): 이것이 컨테이너를 이해하는 출발점입니다. 커널에는 struct container 같은 것이 없고, 컨테이너를 만드는 단일 시스템 콜도 없습니다.
- [Linux 커널 · 커널 네트워킹 스택](https://www.atomai.click/kubernetes-docs/llms/ko/kernel/02-network-stack.md): "네트워크가 느리다"는 진단할 수 없는 문장입니다. 커널 네트워크 경로에는 각각 다른 이유로 지연과 손실이 생기는 지점이 여러 개 있고, 어느 지점인지에 따라 대응이 완전히 달라집니다.
- [Linux 커널 · EKS 노드 커널 튜닝](https://www.atomai.click/kubernetes-docs/llms/ko/kernel/03-eks-node-tuning.md): 이 문서의 가장 중요한 조언입니다.
- [Kubernetes 핵심 개념 · Kubernetes 소개](https://www.atomai.click/kubernetes-docs/llms/ko/basics/04-kubernetes-introduction.md): Kubernetes(K8s)는 컨테이너화된 애플리케이션의 배포, 확장 및 관리를 자동화하는 오픈소스 컨테이너 오케스트레이션 플랫폼입니다. 이 문서에서는 Kubernetes의 기본 개념, 아키텍처, 주요 구성 요소 및 기능에 대해 설명합니다.
- [Kubernetes 핵심 개념 · 클러스터 아키텍처](https://www.atomai.click/kubernetes-docs/llms/ko/core/01-cluster-architecture.md): 버전 헤더는 업스트림 Kubernetes 기준입니다. 2026년 9월 11일 기준 EKS 표준 지원 버전은 1.34–1.36이므로 버전 선택 전 EKS 수명 주기를 확인하세요. 아래 구성 요소 명령은 자체 관리형 클러스터 예시이며 EKS 컨트롤 플레인은 AWS가 관리합니다.
- [Kubernetes 핵심 개념 · 파드와 워크로드](https://www.atomai.click/kubernetes-docs/llms/ko/core/02-pods-and-workloads.md): 이 문서에서는 Kubernetes의 기본 실행 단위인 파드(Pod)와 이를 관리하는 다양한 워크로드 리소스에 대해 자세히 설명합니다. 파드의 개념부터 시작하여 디플로이먼트, 스테이트풀셋, 데몬셋 등 다양한 워크로드 리소스의 특징과 사용 사례를 다룹니다.
- [Kubernetes 핵심 개념 · 서비스와 네트워킹](https://www.atomai.click/kubernetes-docs/llms/ko/core/03-services-networking.md): Kubernetes에서 서비스는 포드 집합에 대한 단일 접점을 제공하는 추상화 계층입니다. 이 장에서는 다양한 서비스 유형, 인그레스, 네트워크 정책 등 Kubernetes의 네트워킹 개념에 대해 자세히 알아보겠습니다.
- [Kubernetes 핵심 개념 · 스토리지](https://www.atomai.click/kubernetes-docs/llms/ko/core/04-storage.md): Kubernetes에서 스토리지는 컨테이너화된 애플리케이션의 데이터를 저장하고 관리하는 중요한 부분입니다. 이 장에서는 볼륨, 퍼시스턴트 볼륨, 퍼시스턴트 볼륨 클레임, 스토리지 클래스 등 Kubernetes의 스토리지 개념에 대해 자세히 알아보겠습니다.
- [Kubernetes 핵심 개념 · 구성](https://www.atomai.click/kubernetes-docs/llms/ko/core/05-configuration-secrets.md): Kubernetes에서 구성 관리는 애플리케이션의 설정을 코드와 분리하여 관리하는 중요한 부분입니다. 이 장에서는 컨피그맵(ConfigMap), 시크릿(Secret), 환경 변수, 볼륨을 통한 구성 마운트 등 Kubernetes의 구성 관리 방법에 대해 자세히 알아보겠습니다.
- [Kubernetes 핵심 개념 · 보안](https://www.atomai.click/kubernetes-docs/llms/ko/core/06-security.md): Kubernetes에서 보안은 클러스터와 애플리케이션을 보호하기 위한 핵심 요소입니다. 이 장에서는 Kubernetes의 보안 개념, 인증 및 권한 부여 메커니즘, 네트워크 정책, 보안 컨텍스트, 그리고 Amazon EKS에서의 보안 강화 방법에 대해 알아보겠습니다.
- [Kubernetes 핵심 개념 · 정책](https://www.atomai.click/kubernetes-docs/llms/ko/core/07-policies.md): Kubernetes에서 정책은 클러스터와 워크로드의 동작을 제어하고 규제하는 규칙 집합입니다. 정책을 통해 보안, 리소스 사용, 네트워크 통신 등 다양한 측면을 관리할 수 있습니다.
- [Kubernetes 핵심 개념 · 스케줄링, 선점 및 축출](https://www.atomai.click/kubernetes-docs/llms/ko/core/08-scheduling-preemption-eviction.md): Kubernetes에서 스케줄링은 포드를 적절한 노드에 배치하는 과정입니다. 선점은 우선순위가 높은 포드를 위해 우선순위가 낮은 포드를 제거하는 과정이며, 축출은 파드를 종료하며 워크로드 컨트롤러가 생성한 대체 파드를 스케줄러가 별도로 배치할 수 있습니다.
- [Kubernetes 핵심 개념 · 클러스터 관리](https://www.atomai.click/kubernetes-docs/llms/ko/core/09-cluster-administration.md): Kubernetes 클러스터 관리는 클러스터의 설정, 유지 관리, 모니터링, 문제 해결 및 업그레이드를 포함하는 중요한 작업입니다. 이 장에서는 Kubernetes 클러스터 관리의 다양한 측면과 Amazon EKS에서의 클러스터 관리 모범 사례에 대해 알아보겠습니다.
- [Kubernetes 핵심 개념 · Windows in Kubernetes](https://www.atomai.click/kubernetes-docs/llms/ko/core/10-windows-in-kubernetes.md): Kubernetes는 원래 Linux 컨테이너를 위해 설계되었지만, 버전 1.14부터 Windows 컨테이너에 대한 프로덕션 지원이 추가되었습니다.
- [Kubernetes 핵심 개념 · Kubernetes 확장](https://www.atomai.click/kubernetes-docs/llms/ko/core/11-extending-kubernetes.md): Kubernetes는 확장성을 고려하여 설계된 플랫폼으로, 다양한 방법으로 기능을 확장할 수 있습니다. 이 장에서는 Kubernetes를 확장하는 다양한 방법과 Amazon EKS에서의 확장 기능 활용 방법에 대해 알아보겠습니다.
- [Kubernetes 핵심 개념 · Custom Scheduler](https://www.atomai.click/kubernetes-docs/llms/ko/scheduling/01-custom-scheduler-part1.md): Kubernetes 스케줄러는 포드를 어떤 노드에 배치할지 결정하는 중요한 구성 요소입니다. 기본 스케줄러는 대부분의 경우 잘 작동하지만, 특정 요구 사항이 있는 경우 커스텀 스케줄러를 구현할 수 있습니다. 이 장에서는 EKS에서 커스텀 스케줄러를 구현하는 방법을 알아보겠습니다.
- [Kubernetes 핵심 개념 · Part 2: 구현](https://www.atomai.click/kubernetes-docs/llms/ko/scheduling/02-custom-scheduler-part2.md): Part1의 모듈 설정과 전체 보조 스케줄러 RBAC/Deployment를 사용합니다. 아래는 해당 스케줄러의 서로 다른 두 확장 방법입니다. 예제는 로컬에서 확인하며 EKS 배포·GPU 실행·TLS 롤아웃·운영 장애 전환은 검증하지 않았습니다.
- [Kubernetes 핵심 개념 · Part 3: 고급 기능](https://www.atomai.click/kubernetes-docs/llms/ko/scheduling/03-custom-scheduler-part3.md): Part1 보조 스케줄러와 Part2 프레임워크 인터페이스를 이용한 구현 패턴 예제입니다. 운영 배포 사례나 최적화 실측 보고서가 아닙니다. 로컬 코드·스키마 검사는 GPU 실행, 애플리케이션 준비 상태, 인증서 발급 또는 운영 가용성을 검증하지 않습니다.
- [Kubernetes 핵심 개념 · KEDA](https://www.atomai.click/kubernetes-docs/llms/ko/autoscaling/01-keda.md): KEDA(Kubernetes Event-driven Autoscaling)는 Kubernetes 애플리케이션을 이벤트 기반으로 자동 확장할 수 있게 해주는 오픈 소스 프로젝트입니다.
- [Kubernetes 핵심 개념 · Karpenter](https://www.atomai.click/kubernetes-docs/llms/ko/autoscaling/02-karpenter.md): Karpenter는 오픈 소스 노드 오토스케일러입니다. 이 장은 호환 Kubernetes 워크로드에 EC2 용량을 제공하는 AWS 공급자 구현을 다룹니다. 가용성·효율은 제약 조건, 클라우드 용량, 노드 초기화와 애플리케이션 설계에 따라 달라집니다.
- [Kubernetes 핵심 개념 · Knative](https://www.atomai.click/kubernetes-docs/llms/ko/autoscaling/03-knative.md): Knative는 Kubernetes 위에서 서버리스(Serverless) 워크로드를 배포, 실행, 관리하기 위한 오픈 소스 플랫폼입니다. 2022년 CNCF Incubating 프로젝트로 승인되었으며, 2025년 9월 11일 CNCF Graduated 프로젝트로 졸업했습니다.
- [Amazon EKS · EKS 소개](https://www.atomai.click/kubernetes-docs/llms/ko/eks/01-eks-introduction.md): Amazon Elastic Kubernetes Service(EKS)는 AWS에서 Kubernetes를 실행하기 위한 관리형 서비스입니다. 이 장에서는 EKS의 기본 개념, 아키텍처, 그리고 일반 Kubernetes와의 차이점을 살펴보겠습니다.
- [Amazon EKS · EKS 클러스터 생성](https://www.atomai.click/kubernetes-docs/llms/ko/eks/02-eks-cluster-creation.md): Amazon EKS 클러스터를 생성하는 방법은 여러 가지가 있습니다. 이 장에서는 다양한 도구와 방법을 사용하여 EKS 클러스터를 생성하는 방법을 자세히 알아보겠습니다.
- [Amazon EKS · Part 1: 사전 요구 사항](https://www.atomai.click/kubernetes-docs/llms/ko/eks/02-eks-cluster-creation-part1.md): Amazon EKS 클러스터를 생성하는 방법은 여러 가지가 있습니다. 이 장에서는 다양한 도구와 방법을 사용하여 EKS 클러스터를 생성하는 방법을 알아보겠습니다.
- [Amazon EKS · Part 2: eksctl을 사용한 클러스터 생성](https://www.atomai.click/kubernetes-docs/llms/ko/eks/02-eks-cluster-creation-part2.md): Part 1 사전 준비를 완료하고 전용 교육용 계정·클러스터 및 임시 kubeconfig(EKSKUBECONFIG)를 사용합니다. 예제는 대안이며 하나의 연속 스크립트가 아닙니다.
- [Amazon EKS · Part 3: AWS Management Console 및 CLI를 사용한 클러스터 생성](https://www.atomai.click/kubernetes-docs/llms/ko/eks/02-eks-cluster-creation-part3.md): Part 1 사전 준비를 완료합니다. 예제는 과금되는 AWS 리소스를 만드는 교육용 절차이며 이번 감사에서 프로비저닝하거나 프로덕션 구성을 인증하지 않았습니다.
- [Amazon EKS · Part 4: Terraform 및 CDK를 사용한 클러스터 생성](https://www.atomai.click/kubernetes-docs/llms/ko/eks/02-eks-cluster-creation-part4.md): Terraform은 인프라를 코드로 관리합니다. 이 예제는 AWS 프로바이더 6.x와 고정된 EKS 모듈 21.25.0, VPC 모듈 5.21.0을 사용합니다.
- [Amazon EKS · Part 5: 클러스터 액세스, 검증, 업그레이드 및 삭제](https://www.atomai.click/kubernetes-docs/llms/ko/eks/02-eks-cluster-creation-part5.md): 기존 EKS 클러스터를 대상으로 하는 가이드입니다. 승인된 계정·리전과 전용 kubeconfig를 사용하세요. 현재 AWS 문서와 로컬 파서로 예제를 검토했으며 이번 감사에서 AWS 변경·클러스터 워크로드·프로덕션 복구 테스트를 실행하지 않았습니다.
- [Amazon EKS · 결론](https://www.atomai.click/kubernetes-docs/llms/ko/eks/02-eks-cluster-creation-conclusion.md): 지금까지 다양한 방법으로 EKS 클러스터를 생성하는 방법을 살펴보았습니다. 각 방법의 장단점을 비교해 보겠습니다.
- [Amazon EKS · EKS 네트워킹](https://www.atomai.click/kubernetes-docs/llms/ko/eks/03-eks-networking-part1.md): 일반 EKS 클러스터의 VPC·서브넷 계획과 보안 그룹 경로를 다룹니다. 제어 플레인은 AWS 관리 인프라에 있고 고객 VPC에는 클러스터 연결 ENI, 노드·Pod 인터페이스, 로드 밸런서·엔드포인트 리소스가 있습니다.
- [Amazon EKS · Part 2: 고급 구성](https://www.atomai.click/kubernetes-docs/llms/ko/eks/03-eks-networking-part2.md): 이 문서에서는 Amazon EKS에서의 서비스 및 로드 밸런싱, 네트워크 정책에 대해 알아보겠습니다. Kubernetes 서비스를 통해 애플리케이션을 노출하는 방법, AWS 로드 밸런서와의 통합, 그리고 네트워크 정책을 사용하여 포드 간 통신을 제어하는 방법을 다룹니다.
- [Amazon EKS · Part 3: 문제 해결](https://www.atomai.click/kubernetes-docs/llms/ko/eks/03-eks-networking-part3.md): 이 문서에서는 Amazon EKS 네트워킹의 성능 최적화, 문제 해결 방법, 그리고 고급 사용 사례에 대해 알아보겠습니다. 네트워크 성능을 최적화하는 방법, 일반적인 네트워킹 문제를 해결하는 방법, 그리고 고급 네트워킹 기능을 활용하는 방법을 다룹니다.
- [Amazon EKS · EKS 스토리지](https://www.atomai.click/kubernetes-docs/llms/ko/eks/04-eks-storage-part1.md): Amazon EKS에서 애플리케이션을 실행할 때 데이터를 저장하고 관리하기 위한 다양한 스토리지 옵션이 있습니다.
- [Amazon EKS · Part 2: 스토리지 클래스](https://www.atomai.click/kubernetes-docs/llms/ko/eks/04-eks-storage-part2.md): 이 문서는 Amazon EKS 스토리지 시리즈의 두 번째 부분으로, FSx for Lustre, Amazon S3, 스냅샷, 볼륨 확장 및 성능 최적화에 대해 다룹니다.
- [Amazon EKS · Part 3: 고급 구성](https://www.atomai.click/kubernetes-docs/llms/ko/eks/04-eks-storage-part3.md): 이 문서는 Amazon EKS 스토리지 시리즈의 세 번째이자 마지막 부분으로, 스토리지 모니터링, 문제 해결, 비용 최적화 및 보안에 대해 다룹니다.
- [Amazon EKS · EKS 보안](https://www.atomai.click/kubernetes-docs/llms/ko/eks/05-eks-security.md): Amazon EKS(Elastic Kubernetes Service)에서 워크로드를 안전하게 실행하기 위해서는 다양한 보안 계층과 모범 사례를 이해하고 구현해야 합니다. 이 문서에서는 EKS 클러스터의 보안을 강화하기 위한 주요 개념, 구성 요소 및 모범 사례를 다룹니다.
- [Amazon EKS · EKS 모니터링 및 로깅](https://www.atomai.click/kubernetes-docs/llms/ko/eks/06-eks-monitoring-logging.md): 효과적인 모니터링 및 로깅은 Amazon EKS 클러스터의 안정성, 가용성 및 성능을 유지하는 데 필수적입니다. 이 문서에서는 EKS 클러스터에서 모니터링 및 로깅을 구현하기 위한 다양한 도구, 기술 및 모범 사례를 다룹니다.
- [Amazon EKS · EKS 비용 최적화](https://www.atomai.click/kubernetes-docs/llms/ko/eks/07-eks-cost-optimization.md): Amazon EKS(Elastic Kubernetes Service)를 사용하면 컨테이너화된 애플리케이션을 쉽게 배포, 관리 및 확장할 수 있지만, 비용을 효과적으로 관리하는 것이 중요합니다. 이 문서에서는 EKS 클러스터의 비용을 최적화하기 위한 다양한 전략과 모범 사례를 다룹니다.
- [Amazon EKS · EKS 업그레이드](https://www.atomai.click/kubernetes-docs/llms/ko/eks/08-eks-upgrades.md): Amazon EKS 클러스터를 최신 상태로 유지하는 것은 보안, 안정성 및 새로운 기능을 활용하기 위해 중요합니다. 이 문서에서는 EKS 클러스터를 안전하게 업그레이드하기 위한 전략, 모범 사례 및 단계별 가이드를 제공합니다.
- [Amazon EKS · EKS 문제 해결](https://www.atomai.click/kubernetes-docs/llms/ko/eks/09-eks-troubleshooting.md): Amazon EKS 클러스터를 운영하다 보면 다양한 문제가 발생할 수 있습니다. 이 문서에서는 EKS 클러스터에서 발생할 수 있는 일반적인 문제와 그 해결 방법을 제공합니다.
- [Amazon EKS · EKS 복원력과 고가용성](https://www.atomai.click/kubernetes-docs/llms/ko/eks/10-eks-resiliency.md): Amazon EKS 클러스터의 복원력(Resilience)은 장애 발생 시 서비스 영향을 최소화하고 신속하게 복구하는 능력을 의미합니다. 이 문서에서는 EKS 환경에서 고가용성과 복원력을 구현하기 위한 전략, 아키텍처 패턴 및 모범 사례를 제공합니다.
- [Amazon EKS · EKS 고급 디버깅](https://www.atomai.click/kubernetes-docs/llms/ko/eks/11-eks-advanced-debugging.md): Amazon EKS 클러스터의 안정적인 운영을 위해서는 체계적인 장애 대응 프레임워크와 고급 디버깅 기술이 필수입니다. 이 문서에서는 프로덕션 환경에서 발생하는 복잡한 문제들을 신속하게 진단하고 해결하기 위한 실전 가이드를 제공합니다.
- [Amazon EKS · Kubernetes 버전별 신규 기능과 로드맵](https://www.atomai.click/kubernetes-docs/llms/ko/eks/12-kubernetes-version-roadmap.md): Kubernetes는 연 3회 릴리스 주기를 통해 빠르게 진화하고 있으며, 각 버전마다 중요한 기능이 추가되거나 졸업(GA)합니다.
- [Amazon EKS · EKS Hybrid Nodes](https://www.atomai.click/kubernetes-docs/llms/ko/eks-hybrid-nodes/README.md): Amazon EKS Hybrid Nodes는 고객이 운영하는 온프레미스·엣지 노드를 AWS 관리형 EKS control plane에 연결합니다. Host·OS·연결·workload 운영은 계속 사용자 책임입니다.
- [Amazon EKS · 사전 요구 사항](https://www.atomai.click/kubernetes-docs/llms/ko/eks-hybrid-nodes/01-prerequisites.md): Hybrid node join 전에 host·network·credential·cluster access를 준비합니다. 로컬 schema/crypto/input 검사는 실제 물리 네트워크·GPU runtime·프로덕션 cluster 검증이 아닙니다.
- [Amazon EKS · 네트워크 구성](https://www.atomai.click/kubernetes-docs/llms/ko/eks-hybrid-nodes/02-network-configuration.md): Routing·DNS·TLS·credential·앱 트래픽을 별도로 검증합니다. 아래는 Terraform mock provider 등을 사용해 로컬 schema/fixture로 확인한 예제이며 AWS 리소스·router·firewall·실제 cluster를 변경하지 않았습니다.
- [Amazon EKS · 에어갭 환경 구성](https://www.atomai.click/kubernetes-docs/llms/ko/eks-hybrid-nodes/03-airgap-setup.md): 이 문서는 퍼블릭 인터넷 접근을 제한한 Hybrid Nodes의 설치 준비를 다룹니다. Hybrid Nodes에는 AWS에서 실행되는 EKS 컨트롤 플레인과 자격 증명에 사용하는 AWS 서비스 연결이 계속 필요합니다.
- [Amazon EKS · 노드 부트스트랩](https://www.atomai.click/kubernetes-docs/llms/ko/eks-hybrid-nodes/04-node-bootstrap.md): 이 문서는 준비한 온프레미스 호스트를 EKS에 연결합니다. 소프트웨어 설치, AWS 신원, 초기화와 실제 워크로드 준비 확인을 구분합니다. 예제의 변경 작업에는 대상 클러스터·호스트 식별과 운영자 승인이 필요합니다.
- [Amazon EKS · GPU 서버 통합](https://www.atomai.click/kubernetes-docs/llms/ko/eks-hybrid-nodes/05-gpu-integration.md): 이 문서는 준비한 NVIDIA GPU 호스트를 EKS Hybrid Nodes에 통합하며 할당, GPU Operator 소유권, MIG와 time-slicing을 다룹니다. 이번 감사에서 GPU 실행, 드라이버 설치, 모델 다운로드, 추론 벤치마크를 수행하지 않았습니다.
- [Amazon EKS · 워크로드 배치 전략](https://www.atomai.click/kubernetes-docs/llms/ko/eks-hybrid-nodes/06-workload-placement.md): 이 문서는 Hybrid·클라우드 노드에 워크로드를 배치하고 cloud bursting과 Pod deletion cost의 한계를 설명합니다. 예제는 로컬로 검증한 구성·패치 방식입니다. 감사 중 클라우드 용량 생성, 노드 변경, 애플리케이션·GPU 워크로드 실행을 수행하지 않았습니다.
- [Amazon EKS · 노드 라이프사이클 관리](https://www.atomai.click/kubernetes-docs/llms/ko/eks-hybrid-nodes/07-node-lifecycle.md): 이 문서에서는 EKS Hybrid Nodes의 nodeadm 고급 설정, 대규모 노드 설치 자동화, 업그레이드 전략, 자격 증명 관리 및 헬스체크 자동화를 다룹니다.
- [Amazon EKS · 운영 및 유지보수](https://www.atomai.click/kubernetes-docs/llms/ko/eks-hybrid-nodes/08-operations.md): 이 문서에서는 EKS Hybrid Nodes 환경의 운영 및 유지보수 절차를 다룹니다.
- [Amazon EKS · 베어메탈 서버 OS 설치](https://www.atomai.click/kubernetes-docs/llms/ko/eks-hybrid-nodes/09-bare-metal-os-setup.md): 데이터를 지우는 OS 설치, 이미지 준비, 클러스터 가입, 읽기 전용 검증을 구분합니다. 예제에는 placeholder가 있으므로 호스트별 설치 계획이 필요합니다. 이번 검토에서는 OS 설치, Packer build, VM 생성, AWS/클러스터 작업을 실행하지 않았습니다.
- [Amazon EKS · Hybrid Nodes Gateway](https://www.atomai.click/kubernetes-docs/llms/ko/eks-hybrid-nodes/10-hybrid-nodes-gateway.md): 이 문서에서는 EKS Hybrid Nodes Gateway의 아키텍처, 설치, 구성, 운영 방법을 다룹니다.
- [Amazon EKS · EKS Auto Mode](https://www.atomai.click/kubernetes-docs/llms/ko/eks-auto-mode/README.md): Amazon EKS Auto Mode는 Kubernetes 노드 관리를 완전히 자동화하는 기능으로, 워크로드 요구 사항에 따라 자동으로 노드를 프로비저닝하고 최적화합니다. 이 가이드는 Auto Mode의 개념, 설정과 운영 시 고려 사항을 다룹니다.
- [Amazon EKS · Auto Mode 시작하기](https://www.atomai.click/kubernetes-docs/llms/ko/eks-auto-mode/01-getting-started.md): 새 클러스터 생성과 기존 클러스터의 Auto Mode 활성화를 다룹니다. 생성 방법은 하나만 선택하세요. 세 방법을 모두 실행하면 각각 과금되는 인프라가 만들어집니다. 기존 클러스터 절차는 의도한 대상 클러스터에만 적용합니다.
- [Amazon EKS · NodePool 구성](https://www.atomai.click/kubernetes-docs/llms/ko/eks-auto-mode/02-nodepool-configuration.md): AWS 관리 기본 풀, 커스텀 NodePool 제약과 AWS 전용 NodeClass API를 구분합니다. 먼저 시작하기를 완료하고 대상 계정·컨텍스트를 확인하세요. 적용 전에 모든 IAM/profile 이름과 네트워크 태그를 검토합니다.
- [Amazon EKS · 스케일링 동작](https://www.atomai.click/kubernetes-docs/llms/ko/eks-auto-mode/03-scaling-behavior.md): 프로비저닝, consolidation, drift와 expiration을 구분합니다. 시작하기에서 확인한 계정·컨텍스트를 사용하세요. Manifest는 구성된 default NodeClass를 가정하며 수명 주기 동작에 집중하도록 On-Demand 용량을 사용합니다.
- [Amazon EKS · Spot 인스턴스 전략](https://www.atomai.click/kubernetes-docs/llms/ko/eks-auto-mode/04-spot-strategies.md): Spot은 중단·용량 불확실성을 감수하는 대신 EC2 비용을 줄일 수 있는 선택지입니다. 혼합 용량, 다양화와 복제본은 복원력에 도움이 될 수 있지만 각각만으로 가용성이나 절감액을 보장하지는 않습니다. 앞 장에서 확인한 계정·컨텍스트와 NodeClass를 사용하세요.
- [Amazon EKS · 운영 및 관리](https://www.atomai.click/kubernetes-docs/llms/ko/eks-auto-mode/05-operations.md): Day-2 운영에서는 원하는 용량, 노드 수명 주기, 애플리케이션 가용성과 실제 수집되는 신호를 구분해야 합니다. 아래는 통제된 실습 구성이지 검증된 프로덕션 runbook이 아닙니다. 이번 감사에서 클라우드 리소스 변경이나 실제 노드·Pod 실행은 하지 않았습니다.
- [Amazon EKS · 비용 관리](https://www.atomai.click/kubernetes-docs/llms/ko/eks-auto-mode/06-cost-management.md): 비용 최적화에는 같은 유효 작업량을 비교하는 청구 증거가 필요합니다. 노드 개수 snapshot, 낮은 CPU 사용률이나 광고 할인율은 실측 절감액이 아닙니다. 아래 예제는 소스·스키마·CLI 계약을 로컬에서 확인했으며 구매, 클라우드 배포나 실제 청구 조회는 수행하지 않았습니다.
- [Amazon EKS · 노드 생명주기](https://www.atomai.click/kubernetes-docs/llms/ko/eks-auto-mode/07-node-lifecycle.md): Expiration, 관리형 이미지 갱신과 애플리케이션 복구는 노드 수명 주기의 서로 다른 부분입니다. Kubernetes Node 객체가 새롭다고 모든 CVE 패치나 워크로드 규정 준수가 입증되지는 않습니다.
- [Amazon EKS · 워크로드별 최적화](https://www.atomai.click/kubernetes-docs/llms/ko/eks-auto-mode/08-workload-optimization.md): 워크로드에 배치·복구 정책을 맞춘 뒤 실제 용량·성능·비용을 검증합니다. Web/batch 예제는 제한된 실습 구성입니다. GPU 예제는 비활성 구성 template이며 검증된 학습/추론 애플리케이션이 아닙니다.
- [Amazon EKS · 마이그레이션 가이드](https://www.atomai.click/kubernetes-docs/llms/ko/eks-auto-mode/09-migration-guide.md): 기존 용량 제거 전에 애플리케이션·스토리지·controller 소유권을 확인해야 합니다. 아래는 로컬 스키마/CLI fixture를 확인한 단계별 예제이며 무중단 프로덕션 검증 절차가 아닙니다. 이번 감사에서 클라우드·클러스터 변경은 수행하지 않았습니다.
- [Networking · Network Operations 개요](https://www.atomai.click/kubernetes-docs/llms/ko/networking/README.md): Kubernetes 네트워킹은 컨테이너화된 애플리케이션 간의 통신을 가능하게 하는 핵심 인프라 계층입니다.
- [Networking · 네트워크 기초 — 프로토콜 25개](https://www.atomai.click/kubernetes-docs/llms/ko/basics/06-network-fundamentals-part1.md): 브라우저 요청에는 여러 프로토콜이 협력합니다. 실제 순서는 캐시, 연결 재사용, IP 및 HTTP 버전에 따라 달라지므로 장애 분석에서는 HTTP뿐 아니라 관련 계층도 확인해야 합니다.
- [Networking · Part 2: 전송 계층과 TLS](https://www.atomai.click/kubernetes-docs/llms/ko/basics/06-network-fundamentals-part2.md): Part 1이 패킷을 목적지 호스트까지 보냈다면, 이 파트는 신뢰성 있는 스트림(TCP·QUIC)과 UDP 데이터그램을 비교하고 TLS의 통신 보호를 설명합니다. UDP 자체에는 신뢰성이나 TLS가 내장되어 있지 않습니다.
- [Networking · Part 3: 애플리케이션 프로토콜](https://www.atomai.click/kubernetes-docs/llms/ko/basics/06-network-fundamentals-part3.md): 전송 프로토콜이 제공하는 스트림·데이터그램 위에서 애플리케이션 프로토콜이 실제 서비스를 만듭니다. 이 파트는 이름 해석(DNS·DoH), 부트스트랩(DHCP), 운영 접속(SSH), 메일(SMTP), HTTP/3·WebSocket·WebRTC·gRPC·MQTT를 다룹니다.
- [Networking · Part 4: 요청의 여정과 클라우드](https://www.atomai.click/kubernetes-docs/llms/ko/basics/06-network-fundamentals-part4.md): 이 시리즈의 프로토콜·메커니즘 25개를 예시 요청으로 연결하고 AWS·쿠버네티스의 관련 역할과 비교합니다. 기능상 대응 관계이며 일대일 대체 관계는 아닙니다.
- [Networking · VPC CNI](https://www.atomai.click/kubernetes-docs/llms/ko/networking/01-vpc-cni.md): Amazon VPC CNI는 표준 EKS EC2 노드에 VPC 기반 Pod 네트워킹을 제공합니다. 이 문서의 aws-node DaemonSet 명령도 해당 설치를 대상으로 합니다.
- [Networking · Cilium 딥다이브](https://www.atomai.click/kubernetes-docs/llms/ko/networking/cilium/README.md): Cilium 네트워킹, 정책, 관측성을 다룹니다. 예제 검토 기준은 Cilium/Helm 차트 1.20.1, Cilium CLI 0.20.0, Hubble CLI 1.19.4입니다. Cilium 1.20 호환성 문서의 Kubernetes 테스트 범위는 1.33–1.36이며 업스트림 1.
- [Networking · Part 1: 소개](https://www.atomai.click/kubernetes-docs/llms/ko/networking/cilium/01-introduction.md): 격리된 준비 환경을 사용하세요. Cilium 1.20의 Kubernetes 테스트 범위는 1.33–1.36입니다. 노드는 AMD64/AArch64 Linux와 커널 5.10 이상, 또는 문서화된 동등 조건(예: RHEL 8.10의 backport된 4.18)을 충족해야 합니다.
- [Networking · Part 2: eBPF](https://www.atomai.click/kubernetes-docs/llms/ko/networking/cilium/02-ebpf.md): 유지보수되는 배포판, 아래 tracepoint, 추적 프로그램을 로드할 권한이 있는 일회용 Linux 개발 VM을 사용합니다. Cilium 설치와 별개 실습이므로 실험용 프로그램을 클러스터 노드에 로드하지 않습니다.
- [Networking · Part 3: 네트워킹](https://www.atomai.click/kubernetes-docs/llms/ko/networking/cilium/03-networking.md): 설치 가이드에 따라 일회용 클러스터와 아키텍처에 맞는 Cilium CLI를 준비합니다. kubectl은 API 서버와 한 minor 버전 이내로 맞춥니다. “v1.31 이상”만으로 호환성을 판단할 수 없습니다.
- [Networking · Part 4: IPAM 및 정책](https://www.atomai.click/kubernetes-docs/llms/ko/networking/cilium/04-ipam-policy.md): 설치 프로필과 네트워킹 조건에 따라 일회용 Linux 클러스터를 준비합니다. kubectl은 API 서버와 지원되는 버전 차이로 맞춥니다. 아래 IPAM 프로필은 설치·문서화된 마이그레이션의 선택지이며 실행 중인 클러스터에 ConfigMap을 순서대로 바꾸는 절차가 아닙니다.
- [Networking · Part 5: L2-L7 네트워킹](https://www.atomai.click/kubernetes-docs/llms/ko/networking/cilium/05-l2-l7-networking.md): 설치·네트워킹 가이드로 준비한 일회용 클러스터에서 플랫폼·커널 지원과 kubectl 버전 차이를 확인합니다. HTTP 실습에는 스케줄링 가능한 Linux 노드 두 개가 필요합니다.
- [Networking · Part 6: 보안 및 가시성](https://www.atomai.click/kubernetes-docs/llms/ko/networking/cilium/06-security-visibility.md): 스케줄링 가능한 Linux 노드가 최소 2개이고 DNS와 정책 적용이 정상인 기존 Cilium 1.20.1 테스트 클러스터를 사용합니다. EKS 제약과 검증된 CLI 다운로드를 포함한 설치 및 플랫폼 전제 조건을 먼저 확인합니다. 이 예제는 CNI를 설치하거나 교체하지 않습니다.
- [Networking · Part 7: 고급 주제](https://www.atomai.click/kubernetes-docs/llms/ko/networking/cilium/07-advanced-topics.md): 설치 전제 조건을 따르고 스케줄링 가능한 Linux 노드가 최소 2개인 폐기 가능한 테스트 클러스터를 사용합니다. 결과에는 OS, 커널, Cilium 설정, 토폴로지, MTU, 정책, 암호화와 테스트 워크로드를 기록합니다. kubectl은 API 서버의 지원 버전 차이 범위에 맞춥니다.
- [Networking · 네트워킹 개념](https://www.atomai.click/kubernetes-docs/llms/ko/networking/cilium/networking-concepts.md): 이 문서는 Cilium을 이해하는 데 필요한 핵심 네트워킹 개념에 대한 심층적인 설명을 제공합니다. 컨테이너 네트워킹, 오버레이, NAT, 라우팅, DNS, 로드 밸런싱과 정책을 다룹니다.
- [Networking · 용어집](https://www.atomai.click/kubernetes-docs/llms/ko/networking/cilium/glossary.md): Cilium, eBPF, Kubernetes와 네트워킹 용어를 알파벳순으로 정리합니다. 반복된 정의는 하나로 합쳤습니다.
- [Networking · Calico 딥다이브](https://www.atomai.click/kubernetes-docs/llms/ko/networking/calico/README.md): Calico는 Kubernetes 네트워킹과 네트워크 정책을 제공하며, 배포 방식과 제품 에디션에 따라 호스트·VM 기능도 제공합니다. 이 시리즈는 아키텍처, 캡슐화와 라우팅, BGP, 정책, eBPF, EKS 통합과 운영을 다룹니다.
- [Networking · Part 1: 소개](https://www.atomai.click/kubernetes-docs/llms/ko/networking/calico/01-introduction.md): iptables·VXLAN·Calico IPAM을 명시적으로 선택한 폐기 가능한 로컬 실습입니다. 기존 CNI를 교체하거나 EKS를 구성하는 절차가 아닙니다. 감사에서는 공개 파일과 설정을 확인했지만 클러스터 생성이나 실제 트래픽 시험은 하지 않았습니다.
- [Networking · Part 2: 아키텍처](https://www.atomai.click/kubernetes-docs/llms/ko/networking/calico/02-architecture.md): Calico의 아키텍처는 확장성, 성능, 유연성을 중심으로 설계되었습니다. 이 장에서는 각 컴포넌트의 역할, 내부 동작 방식, 그리고 컴포넌트 간 상호작용을 심층적으로 분석합니다.
- [Networking · Part 3: 네트워킹 모드](https://www.atomai.click/kubernetes-docs/llms/ko/networking/calico/03-networking-modes.md): 이 장은 Calico가 담당하는 Linux Pod 네트워킹·IPAM을 다룹니다. EKS policy-only에서는 Amazon VPC CNI가 Pod 네트워킹을 유지하며 Calico IPPool 생성만으로 오버레이로 바뀌지 않습니다.
- [Networking · Part 4: BGP 심화](https://www.atomai.click/kubernetes-docs/llms/ko/networking/calico/04-bgp-deep-dive.md): BGP(Border Gateway Protocol)는 경로 도달성 정보를 교환하는 제어 평면 프로토콜입니다. Calico는 BGP로 워크로드 경로를 배포하고 기존 routed fabric에 통합할 수 있습니다.
- [Networking · Part 5: Network Policy](https://www.atomai.click/kubernetes-docs/llms/ko/networking/calico/05-network-policy.md): Network Policy는 워크로드와 다른 endpoint 사이의 허용 연결을 제어합니다. Calico는 표준 Kubernetes API에 정책 순서, 명시적 action, 전역 범위, HostEndpoint 제어를 추가합니다. 기능은 제품과 적용 경로에 따라 다릅니다.
- [Networking · Part 6: eBPF 데이터플레인](https://www.atomai.click/kubernetes-docs/llms/ko/networking/calico/06-ebpf-dataplane.md): Calico eBPF 데이터 평면은 BPF 프로그램·맵으로 워크로드 네트워크, 정책, Kubernetes Service를 처리합니다. 적합한 경로에서 오버헤드를 줄일 수 있지만 성능은 부하와 설정에 따라 다릅니다.
- [Networking · Part 7: 고급 주제](https://www.atomai.click/kubernetes-docs/llms/ko/networking/calico/07-advanced-topics.md): 이 문서에서는 Calico의 고급 기능과 대규모 프로덕션 환경에서의 활용 방법을 다룹니다. IPAM 심화, WireGuard 암호화, Egress Gateway, 멀티 클러스터 페더레이션, Windows 지원, 그리고 대규모 클러스터 설계에 대해 상세히 알아봅니다.
- [Networking · Part 8: EKS 통합](https://www.atomai.click/kubernetes-docs/llms/ko/networking/calico/08-eks-integration.md): 이 문서는 Amazon VPC CNI를 사용하는 일반 Linux EC2 워커 노드에 Calico 정책을 적용하는 구성을 다룹니다. VPC CNI가 Pod IP 할당과 VPC 네트워킹을 담당하고, Calico는 노드 데이터플레인에 정책을 설정합니다.
- [Networking · Part 9: 운영](https://www.atomai.click/kubernetes-docs/llms/ko/networking/calico/09-operations.md): 이 문서에서는 Calico의 설치, 모니터링, 문제 해결, 업그레이드 및 백업/복구에 대한 운영 가이드를 제공합니다. 프로덕션 환경에서 Calico를 안정적으로 운영하기 위한 모범 사례를 다룹니다.
- [Networking · 용어집](https://www.atomai.click/kubernetes-docs/llms/ko/networking/calico/glossary.md): 이 문서는 Calico와 관련된 주요 용어 및 약어에 대한 설명을 제공합니다. 용어는 카테고리별로 분류되어 있으며, 각 카테고리 내에서 알파벳/가나다 순으로 정렬되어 있습니다.
- [Networking · VPC Lattice](https://www.atomai.click/kubernetes-docs/llms/ko/networking/02-vpc-lattice.md): Amazon VPC Lattice는 VPC와 AWS 계정 간 애플리케이션을 연결합니다. 이 문서는 리소스 모델, EKS 연동, 라우팅, IAM 인가, 모니터링과 문제 해결을 설명합니다.
- [Networking · AWS Load Balancer Controller](https://www.atomai.click/kubernetes-docs/llms/ko/networking/03-aws-lb-controller.md): AWS Load Balancer Controller는 Kubernetes 클러스터에서 AWS Elastic Load Balancer(ELB)를 관리하는 컨트롤러입니다.
- [Networking · Gateway API](https://www.atomai.click/kubernetes-docs/llms/ko/networking/04-gateway-api.md): Gateway API는 Kubernetes의 차세대 인그레스 API로, 기존 Ingress API의 한계를 극복하고 더 표현력 있고 확장 가능한 네트워크 라우팅 기능을 제공합니다.
- [Networking · Cross-Org VPC 연결](https://www.atomai.click/kubernetes-docs/llms/ko/networking/05-cross-org-vpc-connectivity.md): 기존 환경과 별도로 관리하는 GPU 환경처럼 서로 다른 AWS Organizations의 계정을 연결하는 다섯 패턴을 비교합니다. 표의 측정값은 이전 문서가 보고한 값을 유지합니다. 이번 검토는 AWS 동작과 산술을 확인했으며 새 실배포나 벤치마크 재현을 수행했다고 주장하지 않습니다.
- [Networking · Pod 네트워크 실측 벤치마크](https://www.atomai.click/kubernetes-docs/llms/ko/networking/06-pod-network-benchmark.md): 이 문서는 서울 리전 fsi-demo-cluster의 2026년 9월 2일 벤치마크 기록을 보존합니다. Pod 간 RTT, HTTP/gRPC 지연, iperf3 처리량과 DNS 쿼리 수를 다룹니다.
- [Service Mesh · Istio](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/istio/README.md): Amazon EKS에서 Istio Service Mesh를 활용한 실용적인 가이드입니다.
- [Service Mesh · 설치 및 초기 설정](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/istio/01-installation.md): 이 문서에서는 Amazon EKS 클러스터에 Istio를 설치하고 초기 설정하는 방법을 다룹니다.
- [Service Mesh · 기본 개념](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/istio/02-basic-concepts.md): 이 문서에서는 Istio의 핵심 개념과 아키텍처를 설명합니다. Istio를 효과적으로 사용하기 위해서는 이러한 기본 개념을 이해하는 것이 중요합니다.
- [Service Mesh · 아키텍처](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/istio/03-architecture.md): Istio의 내부 아키텍처와 네트워킹 메커니즘을 심층적으로 다룹니다.
- [Service Mesh · AWS 통합](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/istio/04-aws-integration.md): 이 문서에서는 Amazon EKS 환경에서 Istio를 AWS 서비스와 통합하는 방법을 다룹니다.
- [Service Mesh · 용어집](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/istio/glossary.md): Istio와 Service Mesh 관련 주요 용어들을 주제별 참조 섹션으로 정리한 용어집입니다.
- [Service Mesh · Traffic Management](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/istio/traffic-management/README.md): Istio의 트래픽 관리 기능은 서비스 메시 내에서 트래픽 흐름을 세밀하게 제어할 수 있게 해줍니다.
- [Service Mesh · Gateway와 VirtualService](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/istio/traffic-management/01-gateway-virtualservice.md): Gateway와 VirtualService는 Istio에서 트래픽을 관리하는 핵심 리소스입니다.
- [Service Mesh · 라우팅](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/istio/traffic-management/02-routing.md): Istio의 고급 라우팅 기능을 사용하면 요청의 다양한 속성을 기반으로 트래픽을 세밀하게 제어할 수 있습니다.
- [Service Mesh · DestinationRule](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/istio/traffic-management/03-destination-rule.md): DestinationRule은 VirtualService가 트래픽을 라우팅한 후, 해당 트래픽을 어떻게 처리할지 정의하는 Istio의 핵심 리소스입니다.
- [Service Mesh · 트래픽 분할](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/istio/traffic-management/04-traffic-splitting.md): 트래픽 분할은 Istio의 가장 강력한 기능 중 하나로, Canary 배포, A/B 테스트, Blue/Green 배포 등을 코드 변경 없이 구현할 수 있습니다.
- [Service Mesh · Retry 및 Timeout](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/istio/traffic-management/05-retry-timeout.md): Retry와 Timeout은 마이크로서비스의 복원력을 높이는 핵심 메커니즘입니다. Istio를 사용하면 애플리케이션 코드 변경 없이 이러한 정책을 설정할 수 있습니다.
- [Service Mesh · 로드 밸런싱](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/istio/traffic-management/06-load-balancing.md): Istio는 Envoy를 통해 다양한 로드 밸런싱 알고리즘을 제공하여 트래픽을 효율적으로 분산시킵니다.
- [Service Mesh · Circuit Breaker](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/istio/traffic-management/07-circuit-breaker.md): Circuit Breaker는 장애가 발생한 서비스를 자동으로 격리하여 연쇄 장애를 방지합니다.
- [Service Mesh · Fault Injection](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/istio/traffic-management/08-fault-injection.md): Fault Injection은 시스템의 복원력을 테스트하기 위해 의도적으로 장애를 주입하는 기법입니다.
- [Service Mesh · Traffic Mirroring](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/istio/traffic-management/09-traffic-mirror.md): Traffic Mirroring(또는 Shadow Traffic)은 프로덕션 트래픽을 실시간으로 복제하여 새 버전을 테스트하는 기법입니다.
- [Service Mesh · Session Affinity](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/istio/traffic-management/10-session-affinity.md): Session Affinity(또는 Sticky Session)는 같은 해시 키의 요청에 대해 느슨한 친화성을 제공하는 기법이며 영구적인 파드 고정을 보장하지 않습니다.
- [Service Mesh · Egress 제어](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/istio/traffic-management/11-egress-control.md): Egress 제어는 메시 외부로 나가는 트래픽을 관리하고 보안을 강화하는 기능입니다.
- [Service Mesh · ServiceEntry](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/istio/traffic-management/12-service-entry.md): ServiceEntry는 Istio 서비스 메시에 외부 서비스를 등록하여 메시 내부 서비스처럼 관리할 수 있게 합니다.
- [Service Mesh · WorkloadEntry](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/istio/traffic-management/13-workload-entry.md): WorkloadEntry는 Virtual Machine (VM)이나 베어메탈 서버를 Istio 서비스 메시에 등록하기 위한 리소스입니다. 이를 통해 Kubernetes 외부의 워크로드도 메시의 트래픽 관리, 보안, 관찰성 기능을 활용할 수 있습니다.
- [Service Mesh · Security](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/istio/security/README.md): Istio는 서비스 메시 내에서 강력한 보안 기능을 제공합니다. Zero Trust 보안 모델을 기반으로 서비스 간 통신을 자동으로 암호화하고, 세밀한 접근 제어를 제공합니다.
- [Service Mesh · mTLS](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/istio/security/01-mtls.md): Mutual TLS (mTLS)는 Istio의 핵심 보안 기능으로, 서비스 간 통신을 자동으로 암호화하고 인증합니다.
- [Service Mesh · 인증](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/istio/security/02-authentication.md): Istio는 서비스 간 인증(Peer Authentication)과 최종 사용자 인증(Request Authentication)을 지원합니다.
- [Service Mesh · 권한 부여](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/istio/security/03-authorization.md): AuthorizationPolicy를 사용하여 서비스 접근 권한을 세밀하게 제어할 수 있습니다.
- [Service Mesh · Observability](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/istio/observability/README.md): Istio 프록시는 관측한 트래픽의 텔레메트리를 생성합니다. 메트릭 스크레이프, access log, 추적 제공자와 저장소를 구성해야 합니다.
- [Service Mesh · 메트릭](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/istio/observability/01-metrics.md): Istio 프록시는 관측한 트래픽의 메트릭을 생성합니다. 이 문서는 사이드카/Envoy의 HTTP·TCP 메트릭과 Prometheus 또는 OpenTelemetry Collector 스크레이프를 다룹니다.
- [Service Mesh · 분산 추적](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/istio/observability/02-tracing.md): 분산 추적은 마이크로서비스 간 요청 흐름을 추적하고 시각화하여, 레이턴시 병목 지점 파악, 에러 원인 분석, 서비스 의존성 이해를 가능하게 합니다.
- [Service Mesh · 로깅](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/istio/observability/03-logging.md): 설정한 access log는 관측한 요청·연결의 메타데이터를 기록합니다. Envoy/istiod 진단·애플리케이션 로그와 별도이며 메시 전체 활동이나 요청·응답 본문 전체를 기록하지 않습니다. 예제는 사이드카 기준입니다.
- [Service Mesh · 대시보드](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/istio/observability/04-dashboards.md): Grafana·Kiali·Prometheus로 설정한 텔레메트리를 조회합니다. 예제는 공식 자료·오프라인 검증에 근거한 실습 설정이며 실제 배포·운영 부하 검증은 수행하지 않았습니다. 백엔드 가용성·인증·네임스페이스 권한·스토리지·버전 호환성이 전제 조건입니다.
- [Service Mesh · Resilience](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/istio/resilience/README.md): Istio의 복원력(Resilience) 기능은 애플리케이션 의미·용량에 맞게 설정할 때 장애 영향을 줄이는 데 도움을 줍니다.
- [Service Mesh · Outlier Detection](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/istio/resilience/01-outlier-detection.md): Outlier Detection은 비정상적으로 동작하는 서비스 인스턴스를 자동으로 감지하고 트래픽 풀에서 제외하는 Circuit Breaker 패턴의 한 형태입니다.
- [Service Mesh · Rate Limiting](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/istio/resilience/02-rate-limiting.md): Rate Limiting은 서비스를 과부하로부터 보호하고, 공정한 리소스 사용을 보장하며, 비용을 제어하기 위해 요청 속도를 제한하는 기능입니다.
- [Service Mesh · Zone Aware Routing](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/istio/resilience/03-zone-aware-routing.md): Zone Aware Routing은 Kubernetes 가용 영역(Availability Zone)을 인식하여 트래픽을 최적화하는 기능입니다. 같은 AZ 내 통신을 우선하여 지연시간을 줄이고 크로스 AZ 데이터 전송 비용을 절감합니다.
- [Service Mesh · Advanced](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/istio/advanced/README.md): Istio의 고급 기능들을 다룹니다. 이 섹션에서는 Ambient Mode, Multi-cluster, EnvoyFilter, gRPC/WebSocket 지원 등 고급 주제들을 다룹니다.
- [Service Mesh · Ambient Mode](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/istio/advanced/01-ambient-mode.md): Ambient는 2022년 실험적 preview로 소개되어 Istio 1.18에 Alpha로 처음 포함되고 1.22 Beta·1.24 core GA에 도달했습니다. Preview는 정식 1.15 릴리스의 GA 기능이 아니었습니다.
- [Service Mesh · Multi-cluster](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/istio/advanced/02-multi-cluster.md): Multi-cluster Service Mesh는 여러 Kubernetes 클러스터를 하나의 통합된 서비스 메시로 연결합니다.
- [Service Mesh · EnvoyFilter](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/istio/advanced/03-envoy-filter.md): EnvoyFilter는 Envoy 프록시의 구성을 직접 커스터마이즈할 수 있는 고급 기능입니다.
- [Service Mesh · DNS Caching](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/istio/advanced/04-dns-cache.md): Istio의 DNS 관리 기능을 통해 외부 서비스 접근 성능을 최적화하고 DNS 조회를 제어합니다.
- [Service Mesh · gRPC](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/istio/advanced/05-grpc.md): Istio는 평문 gRPC HTTP/2 요청을 RPC 경로·metadata로 라우팅하고 새 RPC를 적격 endpoint로 분산할 수 있습니다. 장시간 stream은 선택한 backend에 유지되며 복제본 확장만으로 기존 stream이 이동하지 않습니다.
- [Service Mesh · WebSocket](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/istio/advanced/06-websocket.md): Istio는 생성한 HTTP connection manager에서 WebSocket upgrade를 활성화합니다. 이 예제는 ingress gateway에서 TLS를 종료하는 HTTP/1.1 Upgrade 경로입니다.
- [Service Mesh · Sidecar Injection](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/istio/advanced/07-sidecar-injection.md): 자동 주입은 새로 생성되는 Pod를 수정하는 admission webhook입니다. 기존 실행 중인 Pod에 sidecar를 추가하거나 Deployment template 자체를 수정하지 않습니다.
- [Service Mesh · Argo Rollouts 통합](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/istio/advanced/08-argo-rollouts.md): Argo Rollouts는 progressive delivery 중 replica 선택과 Istio traffic weight를 조정합니다. Analysis를 명시적으로 설정하고 신뢰할 수 있는 관측값을 공급해야 합니다.
- [Service Mesh · Zone-Aware Argo Rollouts](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/istio/advanced/09-zone-aware-argo-rollouts.md): 이 가이드는 AZ별 독립 canary와 cross-AZ failover를 구분합니다. 본문은 client cohort가 한 zone의 stable/canary Service를 선택하는 zone 라우팅·격리 설계 예제입니다.
- [Service Mesh · AutoScaling using istio metrics](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/istio/advanced/10-keda-autoscaling.md): 이 가이드는 scaling signal과 제약을 설명하며 기존 workload·검증된 metric·충분한 cluster 용량을 가정합니다. 같은 Deployment를 대상으로 하는 예제는 대안 관계입니다.
- [Service Mesh · 비교 가이드](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/istio/comparison/README.md): 필요한 트래픽, identity, 플랫폼과 운영 조건을 비교한 뒤 mesh를 선택합니다. 조직 규모, 기능 별점이나 고정 overhead 비율만으로 적합성을 판단할 수 없습니다. 버전 지원과 release channel도 아키텍처 비교와 별도로 확인해야 합니다.
- [Service Mesh · Service Mesh 솔루션 비교](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/istio/comparison/01-service-mesh-comparison.md): 버전은 예제 검증에 사용한 출처를 식별하며 공통 Kubernetes 호환성 표나 운영 배포 검증을 뜻하지 않습니다. 원래 Istio 1.24/Linkerd 2.15/Kong Mesh 2.8/Consul 1.19 성능 수치는 아래에 과거 미검증 자료로 구분해 보존합니다.
- [Service Mesh · Istio vs VPC Lattice](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/istio/comparison/02-istio-vs-lattice.md): 앱의 통신, identity, protocol과 운영 요구사항을 비교합니다. Istio와 VPC Lattice는 배포·보안 경계가 다르며 기능 별점이나 근거 없는 “overhead 0” 주장으로 적합한 구조를 결정할 수 없습니다.
- [Service Mesh · Sidecar vs Ambient Mode 선택 가이드](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/istio/comparison/03-sidecar-vs-ambient.md): 이 문서는 보고된 mTLS, NetworkPolicy, 지연 시간, 롤아웃 측정값을 보존합니다. 전체 원시 결과와 정확한 실행 스크립트 아카이브는 첨부되지 않았으며, 이번 검토에서 AWS 클러스터를 재구성하지 않았습니다. 설정과 산술 검증은 측정 결과의 독립적인 재현이 아닙니다.
- [Service Mesh · Troubleshooting](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/istio/troubleshooting/common-errors.md): 관측한 실패, 적용된 설정과 워크로드 모드부터 확인합니다. 아래 명령은 진단 예시이며 메시 전체를 초기화하는 절차가 아닙니다. Kubernetes/EKS 버전은 설치 호환성 안내를 확인하세요.
- [Service Mesh · 모범 사례](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/istio/best-practices.md): 프로덕션 환경에서 Istio를 성공적으로 운영하기 위한 모범 사례와 권장 사항을 다룹니다.
- [Service Mesh · Linkerd](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/linkerd/README.md): Upstream 프로젝트는 edge 산출물을 배포하며 stable 배포판과 지원 수명 주기는 vendor가 제공합니다. Linkerd 2.20은 기능 milestone이지 내려받은 CLI의 보편적인 버전 문자열이 아닙니다.
- [Service Mesh · 설치](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/linkerd/01-installation.md): 통제된 Kubernetes 설치, Helm/CLI 소유권, HA, 선택적 확장, EKS 고려사항, 업그레이드와 제거를 다룹니다. Upstream은 edge 산출물을 배포하며 stable 배포판의 설치·지원은 vendor 안내를 따라야 합니다.
- [Service Mesh · 아키텍처](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/linkerd/02-architecture.md): 현재 구성 요소의 역할, identity 계층, 트래픽 캡처와 주입 수명 주기를 설명합니다. 지원 release/cluster 조합과 고정 산출물은 설치 가이드를 확인하세요. 예시는 설정 설명이며 이번 감사에서 실제 배포나 CA 회전을 수행하지 않았습니다.
- [Service Mesh · 트래픽 관리](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/linkerd/03-traffic-management.md): 현재 Linkerd 라우팅은 Gateway API 리소스와 지원되는 annotation을 사용합니다. ServiceProfile은 호환성을 위해 유지되며 TrafficSplit/linkerd-smi는 사용 중단 대상으로 지정되었습니다. 이 경로들은 서로 대체 적용되지 않습니다.
- [Service Mesh · 보안](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/linkerd/04-security.md): Linkerd는 proxy가 처리하는 트래픽에 workload 인증, 전송 암호화, inbound 인가를 제공합니다. Mesh 등록, 정책, 인증서 수명주기, 애플리케이션 보안은 별도로 설계해야 합니다.
- [Service Mesh · 관찰성](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/linkerd/05-observability.md): Linkerd는 proxy/protocol 지표를 노출하며 Viz는 Prometheus, metrics-api, tap, tap-injector, web dashboard를 추가합니다. 현재 Viz chart는 Grafana를 설치하지 않습니다.
- [Service Mesh · 멀티 클러스터](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/linkerd/06-multi-cluster.md): Linkerd는 선택한 서비스 정보를 cluster 경계 너머로 미러링합니다. Control plane의 discovery 경로와 적합한 data plane network 경로가 모두 필요합니다.
- [Service Mesh · 모범 사례](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/linkerd/07-best-practices.md): 선택한 버전과 전제 조건은 설치, 보안, 관찰성, 다중 클러스터 가이드를 따릅니다. 이 장은 해당 절차를 운영 검토로 연결하며 특정 환경의 운영 준비 완료를 인증하지 않습니다.
- [Service Mesh · Cilium Service Mesh](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/cilium-service-mesh/README.md): Cilium은 Kubernetes networking, eBPF policy/load balancing, 선택적인 application-layer proxy 기능을 결합합니다. 선택한 L7 트래픽은 Envoy 통합이 처리합니다.
- [Service Mesh · 아키텍처](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/cilium-service-mesh/01-architecture.md): Cilium은 eBPF 기반 L3/L4 데이터패스와 HTTP 등 지원되는 L7 처리를 위한 Envoy를 결합합니다. Envoy는 Agent가 관리하는 프로세스 또는 별도의 cilium-envoy DaemonSet으로 실행할 수 있습니다.
- [Service Mesh · 트래픽 관리](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/cilium-service-mesh/02-traffic-management.md): Cilium Service Mesh의 트래픽 관리는 eBPF 기반 L4 로드 밸런싱과 Envoy 기반 L7 라우팅을 결합하여 제공됩니다.
- [Service Mesh · 보안](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/cilium-service-mesh/03-security.md): 워크로드 인가, 상대 인증, 애플리케이션 데이터 암호화를 별도로 검토해야 합니다. Cilium의 out-of-band 상호 인증, WireGuard/IPsec 전송 암호화, 별도의 ztunnel mTLS 베타는 요건과 제한이 다릅니다.
- [Service Mesh · 관찰성](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/cilium-service-mesh/04-observability.md): Hubble은 Cilium이 처리한 트래픽의 관찰 결과를 제공합니다. L3/L4 이벤트는 데이터패스에서 오고, HTTP 가시성에는 지원되는 L7 프록시·정책 경로가 추가로 필요합니다.
- [Service Mesh · 인그레스 & 게이트웨이](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/cilium-service-mesh/05-ingress-gateway.md): Cilium은 Kubernetes Ingress와 Gateway API 리소스를 통해 데이터 플레인을 설정합니다. eBPF가 Service 전달과 L7 트래픽의 노드 로컬 Envoy 리다이렉션을 처리하고, Envoy가 HTTP 라우팅과 TLS 종료를 수행합니다.
- [Service Mesh · 모범 사례](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/cilium-service-mesh/06-best-practices.md): 운영 계획에서는 CNI 소유 관계, 프록시 기능, 정책 적용, 용량, 복구를 함께 검토해야 합니다. 아래 값은 특정 클러스터에 맞춰 검토할 예제이며, 프로덕션에서 검증한 사이징 보장이나 CNI 마이그레이션 절차, 완전한 EKS 설치 구성이 아닙니다.
- [Service Mesh · VPC Lattice 딥다이브](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/vpc-lattice/README.md): 이 섹션은 개념 이해를 목적으로 합니다. Lattice 리소스를 만드는 방법이나 AWS Gateway API Controller 설치 절차는 VPC Lattice 문서에 이미 있고, Istio와의 기능 대비는 Istio vs VPC Lattice에 있습니다.
- [Service Mesh · App Mesh와 VPC Lattice 아키텍처 대비](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/vpc-lattice/01-appmesh-vs-lattice.md): App Mesh와 Istio가 Pod 안에 Envoy를 넣는 이유는 애플리케이션의 컨텍스트를 알아야 하는 결정이 있기 때문입니다.
- [Service Mesh · 레이턴시 영향 분석](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/vpc-lattice/02-latency.md): 지연 변화는 워크로드마다 다릅니다. 프록시 처리·네트워크 경로·연결 재사용·서명·자격 증명 갱신·정책 평가가 모두 달라질 수 있습니다. 이 장에는 Lattice 지연 실측이 없으므로 크기나 개선 방향을 보장하지 않습니다.
- [Service Mesh · IAM 인증 절차 상세](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/vpc-lattice/03-auth-flow.md): App Mesh의 mTLS는 connection을 세울 때 한 번 서로의 인증서를 확인하고, 그 다음부터는 그 연결을 신뢰합니다. 신원이 연결에 묶여 있는 모델입니다.
- [Service Mesh · 기반 개념 — link-local과 SNI](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/vpc-lattice/04-networking-basics.md): link-local 주소는 하나의 링크(같은 브로드캐스트 도메인) 안에서만 유효한 주소 대역입니다. 라우터를 넘어가지 않는 것이 정의입니다.
- [Service Mesh · 워크로드 신원 모델 전환](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/vpc-lattice/05-spiffe-to-iam.md): 서비스 A가 서비스 B를 호출할 때 B는 "이 요청이 정말 A에서 왔는가"를 알아야 합니다. 이 문제가 어려운 이유는 증명에 필요한 비밀을 애초에 어떻게 전달하는가입니다.
- [Service Mesh · 제약사항과 의사결정 포인트](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/vpc-lattice/06-constraints.md): 제약 1·2는 현재 기능과 신뢰 경계의 선택이며 AWS가 영원히 기능을 추가할 수 없다는 예측이 아닙니다. 서비스 listener·resource connectivity·controller 지원을 구분합니다.
- [Service Mesh · 커널 데이터패스](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/vpc-lattice/07-kernel-datapath.md): 04번 문서에서 link-local 주소가 "이 패킷은 인프라가 처리한다"는 표시라고 설명했습니다. 개념으로는 그것으로 충분하지만, 전환 기간에 실제로 터지는 문제들은 커널 계층에 있습니다.
- [Storage · Storage 개요](https://www.atomai.click/kubernetes-docs/llms/ko/storage/README.md): Kubernetes 위에서 상태(state)를 다루는 순간, 스토리지는 더 이상 "붙이면 되는 것"이 아니라 성능·비용·가용성을 좌우하는 독립된 도메인이 됩니다. 이 섹션은 클라우드 스토리지를 선택 기준 → 실측 성능 → 운영의 순서로 다룹니다.
- [Storage · EBS gp2 vs gp3 실측 벤치마크](https://www.atomai.click/kubernetes-docs/llms/ko/storage/01-ebs-gp2-gp3-benchmark.md): "gp2를 gp3로 바꾸면 20% 싸지고 성능은 같거나 낫다"는 AWS 문서의 한 줄은 유명하지만, Kubernetes PVC 위에서 그 차이가 언제, 어떤 모양으로 나타나는지 직접 잰 그래프는 찾기 어렵습니다.
- [Database · Database on Kubernetes 개요](https://www.atomai.click/kubernetes-docs/llms/ko/database/README.md): "데이터베이스를 Kubernetes에서 돌려도 되는가"는 더 이상 예/아니오 질문이 아닙니다. 질문은 어떤 데이터베이스를, 어떤 운영 체계(Operator)로, 어떤 스토리지 위에서 돌릴 것인가로 바뀌었습니다. 이 섹션은 그 판단 기준과, 스펙 시트가 아닌 실측 데이터를 다룹니다.
- [Database · ClickHouse on EKS 실측 벤치마크](https://www.atomai.click/kubernetes-docs/llms/ko/database/01-clickhouse-on-eks.md): "ClickHouse는 빠르다"는 말은 벤치마크 보고서마다 나오지만, EKS의 평범한 노드 하나와 기본 gp3 볼륨에서 어느 정도인지 직접 잰 숫자는 찾기 어렵습니다.
- [블록체인 · 블록체인 개요](https://www.atomai.click/kubernetes-docs/llms/ko/blockchain/README.md): 이 레포는 Kubernetes와 EKS 학습 자료입니다. 블록체인이 여기 있는 이유는 블록체인 노드가 Kubernetes 운영자에게 특이한 워크로드이기 때문입니다.
- [블록체인 · 블록체인 기초 개념](https://www.atomai.click/kubernetes-docs/llms/ko/blockchain/01-fundamentals.md): 블록체인을 이해하는 출발점은 기술이 아니라 제약 조건입니다.
- [블록체인 · EKS에서 블록체인 노드 운영](https://www.atomai.click/kubernetes-docs/llms/ko/blockchain/02-nodes-on-eks.md): 구성을 논하기 전에 이 질문이 먼저입니다. 블록체인 노드는 Kubernetes의 강점과 잘 맞지 않는 부분이 있습니다.
- [블록체인 · Amazon Managed Blockchain](https://www.atomai.click/kubernetes-docs/llms/ko/blockchain/03-managed-blockchain.md): AMB는 하나의 서비스가 아니라 성격이 다른 구성요소들의 묶음입니다.
- [블록체인 · 금융권 관점](https://www.atomai.click/kubernetes-docs/llms/ko/blockchain/04-financial-services.md): 금융권 블록체인 검토에서 가장 자주 생기는 문제는 기술이 문제에 맞지 않는데 진행되는 것입니다. 이 문서는 그 판별부터 시작합니다.
- [Data Pipeline · Data on EKS 개요](https://www.atomai.click/kubernetes-docs/llms/ko/data-on-eks/README.md): 이 섹션은 Kafka·Spark·Airflow·Flink를 Amazon EKS에서 운영하는 방법과 AWS 관리형 서비스와의 연결을 다룹니다. 도구별 Helm chart, Kubernetes Operator, executor를 사용하되 배포·관측·확장 방식과 운영 책임은 서로 다릅니다.
- [Data Pipeline · 모던 데이터 파이프라인 해부](https://www.atomai.click/kubernetes-docs/llms/ko/data-on-eks/01-data-pipeline-anatomy.md): 소스·수집·저장·처리·소비는 설계를 설명하는 개념적 역할입니다. 제품마다 정확히 하나의 역할만 맡거나, 반드시 저장 후 처리하는 직선 순서를 따라야 한다는 뜻은 아닙니다. 스트림은 처리 후 저장할 수도 있고 웨어하우스 안에서 변환할 수도 있습니다.
- [Data Pipeline · SageMaker Unified Studio 거버넌스](https://www.atomai.click/kubernetes-docs/llms/ko/data-on-eks/sagemaker-unified-studio/README.md): Amazon SageMaker Unified Studio는 데이터·AI 팀의 협업, 도구와 catalog 자산을 관리하는 workspace입니다. EKS 데이터 파이프라인의 자산·사용자·실행 권한을 어느 domain/project에서 관리할지 설명합니다.
- [Data Pipeline · Part 4: Domain, Project, Membership 거버넌스](https://www.atomai.click/kubernetes-docs/llms/ko/data-on-eks/sagemaker-unified-studio/01-domains-projects-governance.md): Qwen 실험 기록의 세 번째 시도는 project 생성 후 caller의 membership 문제로 조회·삭제가 거부되었다고 보고합니다. 학습은 시작되지 않았습니다.
- [Data Pipeline · Kafka on EKS 딥다이브](https://www.atomai.click/kubernetes-docs/llms/ko/data-on-eks/kafka/README.md): 이 가이드는 Apache Kafka를 EKS에서 직접 운영하는 선택지로 Strimzi Operator를 사용합니다. Operator는 Pod, 스토리지, listener, 인증서와 업그레이드를 조정하지만 데이터·가용성·보안 정책의 운영 책임을 모두 대신하지 않습니다.
- [Data Pipeline · Part 1: Kafka 핵심 개념](https://www.atomai.click/kubernetes-docs/llms/ko/data-on-eks/kafka/01-kafka-fundamentals.md): Kafka는 이벤트를 파티션 로그에 저장하고 생산자와 소비자가 독립적으로 접근하게 하는 분산 이벤트 스트리밍 플랫폼입니다. 브로커는 토픽 전체가 아니라 여러 토픽의 파티션 복제본을 보관할 수 있습니다.
- [Data Pipeline · Part 2: Strimzi Operator](https://www.atomai.click/kubernetes-docs/llms/ko/data-on-eks/kafka/02-strimzi-operator.md): 이 장은 새 환경에서 controller 3개와 broker 3개를 분리해 배포하는 예제입니다. 세 AZ에 스케줄 가능한 용량과 올바른 StorageClass가 필요합니다. 기존 클러스터 업그레이드는 별도 작업입니다.
- [Data Pipeline · Part 3: Kafka 운영](https://www.atomai.click/kubernetes-docs/llms/ko/data-on-eks/kafka/03-kafka-operations.md): 이 장은 Part 2의 인증된 Kafka와 broker 전용 node pool을 기준으로 합니다. 운영 명령은 실제 파티션 이동과 리소스 변경을 일으킬 수 있으므로, 현재 설정·데이터 배치와 제안 결과를 확인한 뒤 실행합니다.
- [Data Pipeline · Part 4: 스키마 레지스트리](https://www.atomai.click/kubernetes-docs/llms/ko/data-on-eks/kafka/04-schema-registry.md): Kafka는 레코드의 키와 값을 바이트로 저장합니다. 따라서 프로듀서와 컨슈머가 데이터의 구조나 의미를 다르게 해석할 수 있습니다. 필드 추가가 항상 오류를 일으키는 것은 아닙니다. 인코딩, reader 구현, 호환성 규칙에 따라 결과가 달라집니다.
- [Data Pipeline · Part 5: Kafka Connect와 MirrorMaker](https://www.atomai.click/kubernetes-docs/llms/ko/data-on-eks/kafka/05-kafka-connect-mirrormaker.md): Kafka Connect는 Kafka와 외부 시스템 사이에서 데이터를 이동하는 플러그인을 실행합니다. 알맞은 플러그인이 이미 있고 DB·스토리지 권한, 데이터 형식과 네트워크 조건을 갖춘 경우에 설정만으로 연동할 수 있습니다.
- [Data Pipeline · Part 6: MSK 통합](https://www.atomai.click/kubernetes-docs/llms/ko/data-on-eks/kafka/06-msk-integration.md): Amazon MSK의 브로커는 EKS 밖의 AWS 관리 인프라에서 실행됩니다. Strimzi는 팀이 운영하는 Kubernetes 워크로드로 브로커를 실행합니다. 어느 쪽이든 애플리케이션, 토픽, 접근 제어, 보존과 복구 설계가 필요합니다.
- [Data Pipeline · Part 7: 모니터링](https://www.atomai.click/kubernetes-docs/llms/ko/data-on-eks/kafka/07-monitoring.md): 이 장은 jmxPrometheusExporter를 선택합니다. MBean 변환 규칙과 Prometheus의 대상 relabeling은 다른 단계입니다. strimziMetricsReporter도 지원되므로 JMX가 유일한 방법이라는 설명은 틀립니다.
- [Data Pipeline · Part 8: 모범 사례](https://www.atomai.click/kubernetes-docs/llms/ko/data-on-eks/kafka/08-best-practices.md): 앞 장의 예제를 운영에서 검증할 결정으로 정리합니다. 다음에는 벤치마크 장이 이어집니다. 체크리스트만으로 실제 부하와 장애 시험을 대신할 수는 없습니다.
- [Data Pipeline · Part 9: Kafka 실측 벤치마크](https://www.atomai.click/kubernetes-docs/llms/ko/data-on-eks/kafka/09-kafka-benchmark.md): PR #166에 보고된 단일 실행 표를 유지하면서 단위·비교 조건과 재현 절차를 검토했습니다. 원시 telemetry와 원본 payload hash는 저장소 보고서에 포함되어 있지 않습니다.
- [Data Pipeline · Spark on EKS 딥다이브](https://www.atomai.click/kubernetes-docs/llms/ko/data-on-eks/spark/README.md): Apache Spark는 배치·SQL·스트리밍 등의 분산 데이터를 처리합니다. Kubernetes 네이티브 지원은 Spark 2.3, client mode 지원은 2.4부터입니다. Spark 4.2.0 공식 문서는 Kubernetes 1.34+를 전제로 합니다.
- [Data Pipeline · Part 1: Spark on Kubernetes 기초](https://www.atomai.click/kubernetes-docs/llms/ko/data-on-eks/spark/01-spark-fundamentals.md): Kubernetes는 Spark의 두 배포 모드 모두 지원합니다. Client mode는 Spark 2.4부터 지원되며 notebook만을 위한 기능이 아닙니다.
- [Data Pipeline · Part 2: Spark Operator](https://www.atomai.click/kubernetes-docs/llms/ko/data-on-eks/spark/02-spark-operator.md): 두 프로젝트는 독립적으로 관리되며 같은 매니페스트를 서로 바꿔 사용하는 구현체가 아닙니다. 필요한 API·수명주기, 기존 리소스와 런타임 조합·운영 시험으로 선택합니다. 오래되었다거나 채택이 많다는 근거 없는 주장으로 호환성을 보장하지 않습니다.
- [Data Pipeline · Part 3: Amazon EMR on EKS](https://www.atomai.click/kubernetes-docs/llms/ko/data-on-eks/spark/03-emr-on-eks.md): EMR on EKS는 기존 EKS에 AWS가 관리하는 Spark 런타임과 제출 기능을 제공합니다. EKS control plane·노드·용량·네트워크·스토리지는 계속 운영해야 합니다. 다음 경로는 구분해야 합니다.
- [Data Pipeline · Part 4: 성능 및 비용 튜닝](https://www.atomai.click/kubernetes-docs/llms/ko/data-on-eks/spark/04-performance-tuning.md): 이 장은 Part 1의 직접 spark-submit 경로를 사용합니다. Spark 4.2는 Kubernetes 1.34+를 요구하며, EKS·kubectl·Karpenter의 호환 버전도 확인합니다.
- [Data Pipeline · Part 5: 모범 사례와 보안](https://www.atomai.click/kubernetes-docs/llms/ko/data-on-eks/spark/05-best-practices.md): Part 1의 직접 Kubernetes 제출을 기준으로 S3 임시 자격 증명, 메트릭과 event log, History Server, 통신·RBAC를 구성합니다. Spark 4.2에 맞는 Kubernetes 1.34+ 및 호환 kubectl을 사용합니다.
- [Data Pipeline · Airflow on EKS 딥다이브](https://www.atomai.click/kubernetes-docs/llms/ko/data-on-eks/airflow/README.md): Apache Airflow는 DAG로 작업 의존성을 정의하고 예약·실행·관찰하는 플랫폼입니다. EKS에서 어떤 작업이 별도 Pod로 실행되는지는 executor와 operator 선택에 달려 있습니다.
- [Data Pipeline · Part 1: Kubernetes에서의 Airflow 아키텍처](https://www.atomai.click/kubernetes-docs/llms/ko/data-on-eks/airflow/01-architecture.md): Airflow는 DAG에 정의한 의존성을 보고 task instance를 예약·실행·관찰합니다. 실제 계산은 선택한 executor의 worker, 외부 Pod 또는 호출한 외부 서비스가 수행할 수 있습니다.
- [Data Pipeline · Part 2: Helm 배포와 Executor 선택](https://www.atomai.click/kubernetes-docs/llms/ko/data-on-eks/airflow/02-helm-deployment.md): 이 문서는 Apache Airflow 저장소의 공식 chart를 사용합니다. 저장소 alias를 apache-airflow로 등록하므로 Helm 명령의 chart 이름은 apache-airflow/airflow입니다.
- [Data Pipeline · Part 3: DAG 패턴과 KubernetesPodOperator](https://www.atomai.click/kubernetes-docs/llms/ko/data-on-eks/airflow/03-dag-patterns.md): KubernetesPodOperator(KPO)는 Airflow task가 별도의 workload Pod를 생성·관찰하는 operator입니다. CeleryExecutor·KubernetesExecutor·호환되는 다른 executor에서 실행할 수 있습니다.
- [Data Pipeline · Part 4: Amazon MWAA 통합](https://www.atomai.click/kubernetes-docs/llms/ko/data-on-eks/airflow/04-mwaa-integration.md): 이 장은 environment를 만드는 provisioned Amazon MWAA에서 자체 EKS로 작업을 제출하는 방법을 다룹니다.
- [Data Pipeline · Part 5: 운영과 보안](https://www.atomai.click/kubernetes-docs/llms/ko/data-on-eks/airflow/05-operations.md): Part 2의 자체 EKS 배포를 기준으로 HA·업그레이드·시크릿·로그·관측·복구를 정리합니다. 운영 기준은 설정 존재 여부보다 장애 후 실행과 데이터·로그를 복구할 수 있는지입니다. MWAA의 환경 업그레이드와 CloudWatch 관리 절차는 Part 4의 서비스 경로를 사용합니다.
- [Data Pipeline · Flink on EKS 딥다이브](https://www.atomai.click/kubernetes-docs/llms/ko/data-on-eks/flink/README.md): Apache Flink는 유한·무한 스트림을 처리하는 분산 stateful 엔진입니다. JobManager는 실행·복구를 조정하고, TaskManager는 operator task와 데이터 교환을 담당합니다.
- [Data Pipeline · Part 1: Kubernetes에서의 Flink 아키텍처](https://www.atomai.click/kubernetes-docs/llms/ko/data-on-eks/flink/01-architecture.md): 이 장은 cluster 역할과 자원 계산을 설명합니다. 현재 지원되는 EKS/Kubernetes, 호환 kubectl, Flink 배포판과 client 접근을 준비합니다. 설치·ServiceAccount·RBAC와 Operator CR은 Part 2에서 다룹니다.
- [Data Pipeline · Part 2: Flink Kubernetes Operator](https://www.atomai.click/kubernetes-docs/llms/ko/data-on-eks/flink/02-flink-kubernetes-operator.md): Operator는 CR의 목표 상태를 관찰된 cluster/job 상태와 맞추고 upgrade·snapshot· 복구·autoscaling을 관리합니다. 모든 변경의 무중단·무손실을 보장하는 장치는 아닙니다.
- [Data Pipeline · Part 3: 상태 관리, 체크포인팅, 스트리밍 패턴](https://www.atomai.click/kubernetes-docs/llms/ko/data-on-eks/flink/03-state-checkpointing-streaming.md): State는 집계·조인·중복 제거가 기억하는 데이터입니다. 모든 윈도우 집계가 원본 레코드 전체를 보관하는 것은 아니며, SUM/COUNT 같은 증분 집계는 accumulator를 유지할 수 있습니다.
- [Data Pipeline · Part 4: 운영, 고가용성, 그리고 매니지드 Flink](https://www.atomai.click/kubernetes-docs/llms/ko/data-on-eks/flink/04-operations-ha.md): Part 3의 stateful 배포에 관측과 HA를 연결하고, 실제 장애·복구와 용량을 검증합니다. Karpenter를 반드시 사용해야 하는 것은 아니며, 기존 node capacity 운영 방식을 같이 점검합니다.
- [AI/ML · AI/ML 워크로드](https://www.atomai.click/kubernetes-docs/llms/ko/ai-ml/01-ai-ml-workloads.md): Kubernetes는 AI/ML 워크로드를 실행하기 위한 강력한 플랫폼입니다. 이 장에서는 EKS에서 AI/ML 워크로드를 실행하는 방법과 모범 사례를 알아보겠습니다.
- [AI/ML · AI 인프라스트럭처](https://www.atomai.click/kubernetes-docs/llms/ko/ai-ml/06-ai-infrastructure.md): AI 인프라는 notebook, pipeline, 분산 runtime, 장치·node, 저장소·네트워크와 인증을 함께 구성해야 합니다. 도구 이름을 모으거나 Helm release가 성공했다고 전체 플랫폼의 보안·고가용성·model 실행이 검증되지는 않습니다.
- [AI/ML · 모델 트레이닝](https://www.atomai.click/kubernetes-docs/llms/ko/ai-ml/05-model-training.md): 분산 훈련은 모델 코드, 데이터 분할, launcher, 장치 할당, 통신과 체크포인트가 함께 맞아야 합니다. Kubernetes 매니페스트가 생성되거나 Pod가 Running이라고 학습·복구가 검증된 것은 아닙니다.
- [AI/ML · 추론 프레임워크](https://www.atomai.click/kubernetes-docs/llms/ko/ai-ml/04-inference-frameworks.md): 추론 엔진, 분산 실행 계층, Kubernetes controller와 provider gateway를 구분해 선택해야 합니다. 같은 “OpenAI 호환” 표현도 지원 endpoint·요청 필드·streaming·tool call·인증이 완전히 같다는 뜻은 아닙니다.
- [AI/ML · vLLM 배포 및 최적화](https://www.atomai.click/kubernetes-docs/llms/ko/ai-ml/02-vllm-deployment.md): vLLM은 생성형 모델과 지원되는 멀티모달·pooling 모델을 서빙하는 오픈소스 추론 엔진입니다. Vector Language Model이라는 풀네임을 사용하지 않습니다.
- [AI/ML · Agentic AI 플랫폼](https://www.atomai.click/kubernetes-docs/llms/ko/ai-ml/03-agentic-ai-platform.md): Agentic AI는 단순한 질의응답을 넘어 자율적으로 계획을 세우고, 도구를 사용하며, 반복적으로 목표를 달성하는 AI 시스템입니다. 이 장에서는 EKS에서 Agentic AI 플랫폼의 구성과 운영 경계를 설계하는 방법을 알아보겠습니다.
- [AI/ML · AI/ML 모범 사례](https://www.atomai.click/kubernetes-docs/llms/ko/ai-ml/07-ai-ml-best-practices.md): 개선의 기준은 같은 workload에서 측정한 지연·성공률·처리량·비용과 복구 가능성입니다. 특정 GPU, snapshotter 또는 sharing 기능만으로 고정 절감률이나 성능 배수를 보장하지 않습니다.
- [AI/ML · LLM 게이트웨이(Inference Gateway) 딥다이브](https://www.atomai.click/kubernetes-docs/llms/ko/ai-ml/08-llm-gateway.md): 코딩 에이전트(Claude Code, OpenCode, Codex), RAG 애플리케이션, 자율 에이전트가 한 조직 안에서 동시에 여러 모델 제공자(Anthropic, Amazon Bedrock, 자체 호스팅 vLLM)를 호출하기 시작하면, "누가 어떤 모델을 얼마나 썼고, 그…
- [AI/ML · Ray on EKS 딥다이브](https://www.atomai.click/kubernetes-docs/llms/ko/ai-ml/ray/README.md): Ray는 task·actor·ObjectRef와 노드별 object store를 기반으로 Python 워크로드를 분산 실행합니다. Train·Tune·Serve는 이 기반을 사용하면서 각자의 학습·탐색·서빙 정책을 추가합니다.
- [AI/ML · Part 1: Ray Architecture](https://www.atomai.click/kubernetes-docs/llms/ko/ai-ml/ray/01-architecture.md): 로컬 예제는 Python 3.12, ray==2.58.0, numpy==2.2.6에서 확인했습니다. Task·actor·ObjectRef 예제에는 GPU나 학습 모델, Kubernetes가 필요하지 않습니다.
- [AI/ML · Part 2: The KubeRay Operator](https://www.atomai.click/kubernetes-docs/llms/ko/ai-ml/ray/02-kuberay-operator.md): 지원 중인 Kubernetes와 호환되는 kubectl, Helm 3을 준비합니다. CPU 구성 검토에는 GPU나 Karpenter가 필수가 아닙니다.
- [AI/ML · Part 3: Ray Train and Ray Tune](https://www.atomai.click/kubernetes-docs/llms/ko/ai-ml/ray/03-ray-train-tune.md): 검증 환경은 Python 3.12와 ray[train,tune]==2.58.0입니다. 이 extra는 Ray의 Train/Tune 의존성을 설치하며 PyTorch 같은 학습 framework 자체는 별도입니다.
- [AI/ML · Part 4: Ray Serve](https://www.atomai.click/kubernetes-docs/llms/ko/ai-ml/ray/04-ray-serve.md): Python 3.12와 ray[serve]==2.58.0으로 작은 CPU 응답 예제를 확인했습니다. 이 환경에서는 HAProxy 관련 module이 Jinja2를 import하지만 extra 설치에 포함되지 않아, Jinja2==3.1.6을 추가한 뒤 정상 import됐습니다.
- [AI/ML · Kubeflow on EKS 딥다이브](https://www.atomai.click/kubernetes-docs/llms/ko/ai-ml/kubeflow/README.md): Kubeflow는 ML 파이프라인, 노트북, 튜닝, 학습, 서빙을 위한 Kubernetes 기반 도구를 제공합니다. Community Distribution은 컴포넌트 리비전, 공통 서비스, 대시보드를 묶으며, 개별 프로젝트에도 자체 릴리스와 설치 조건이 있습니다.
- [AI/ML · Part 1: EKS에서의 Kubeflow 아키텍처와 설치](https://www.atomai.click/kubernetes-docs/llms/ko/ai-ml/kubeflow/01-architecture-installation.md): 설치 명령보다 먼저 배포판 릴리스를 선택하세요. EKS/Kubernetes 버전, 노드 아키텍처, CNI, StorageClass, 신원 공급자, 필요한 컴포넌트를 기록해야 합니다. Kubernetes 1.34+가 이후 모든 버전의 지원을 보장하지는 않습니다.
- [AI/ML · Part 2: Kubeflow Pipelines](https://www.atomai.click/kubernetes-docs/llms/ko/ai-ml/kubeflow/02-pipelines.md): 로컬 컴파일에는 Python과 kfp==2.16.1이 필요합니다. 이 장은 Python 3.12로 검증했습니다. 컴파일은 클러스터에 접속하지 않으며, 원격 실행에는 호환되는 KFP 백엔드, 인증된 클라이언트와 네임스페이스 권한이 필요합니다.
- [AI/ML · Part 3: Kubeflow Notebooks](https://www.atomai.click/kubernetes-docs/llms/ko/ai-ml/kubeflow/03-notebooks.md): 호환되는 Kubernetes 클러스터, Notebooks 1.11.0 컨트롤러·웹앱, 사용자 네임스페이스 권한, 스토리지·접근 경로가 필요합니다. 전체 배포판 호환성은 Part 1을 참고하세요.
- [AI/ML · Part 4: Katib — 하이퍼파라미터 튜닝과 AutoML](https://www.atomai.click/kubernetes-docs/llms/ko/ai-ml/kubeflow/04-katib.md): Katib 0.19.0 컨트롤러·DB manager·저장소, 필요한 Suggestion 이미지, Experiment를 생성할 네임스페이스 권한이 필요합니다. 전체 Kubeflow 설치의 Profile과 standalone 접근 모델은 구분하세요.
- [AI/ML · Part 5: Kubeflow Trainer와 분산 학습](https://www.atomai.click/kubernetes-docs/llms/ko/ai-ml/kubeflow/05-training-operator.md): 선택한 릴리스와 호환되는 Kubernetes, Trainer 컨트롤러·CRD, 런타임과 해당 런타임의 JobSet 등 의존성이 필요합니다. GPU는 학습 워크로드에 따라 선택하며 CPU 작업도 가능합니다.
- [AI/ML · Part 6: KServe — Kubernetes 위에서의 모델 서빙](https://www.atomai.click/kubernetes-docs/llms/ko/ai-ml/kubeflow/06-kserve.md): 선택한 KServe 릴리스와 호환되는 Kubernetes, 컨트롤러·CRD, ServingRuntime, 저장소 접근과 인증된 네트워크 경로가 필요합니다. 전체 Kubeflow는 필수가 아니며 웹앱은 선택적 UI입니다.
- [AI/ML · MLflow on EKS 딥다이브](https://www.atomai.click/kubernetes-docs/llms/ko/ai-ml/mlflow/README.md): MLflow는 실험 추적, 모델 기록·등록·버전 관리, GenAI 평가와 tracing을 제공하는 오픈소스 플랫폼입니다. Tracing은 2.14.0에서 도입됐고 3.x에서 LoggedModel·평가·UI 연계가 확장됐습니다. 3.16.0은 2026-09-04에 공개됐습니다.
- [AI/ML · Part 1: MLflow Tracking](https://www.atomai.click/kubernetes-docs/llms/ko/ai-ml/mlflow/01-tracking.md): Python 3.10 이상 환경에 mlflow==3.16.0을 설치합니다. 아래 예제는 Python 3.12에서 SQLite와 로컬 artifact 저장소로 확인했으며 GPU·학습 모델·원격 서버가 필요하지 않습니다. 팀용 HTTP 서버와 EKS 운영은 Part 3에서 다룹니다.
- [AI/ML · Part 2: MLflow Model Registry](https://www.atomai.click/kubernetes-docs/llms/ko/ai-ml/mlflow/02-model-registry.md): Python 3.10 이상과 mlflow==3.16.0을 사용합니다. Registry API는 로컬 SQLite에서도 실습할 수 있으며 별도 HTTP 서버가 필수는 아닙니다. 팀 배포는 Part 3, Tracking 설정은 Part 1을 참고합니다.
- [AI/ML · Part 3: MLflow를 EKS에 배포하기](https://www.atomai.click/kubernetes-docs/llms/ko/ai-ml/mlflow/03-eks-deployment.md): EKS의 지원 중인 Kubernetes 버전, 그 API 서버와 호환되는 kubectl, Helm 3, metadata DB와 artifact 저장소를 준비합니다. kubectl >=1.34처럼 하한만 맞추면 모든 서버와 호환되는 것은 아닙니다.
- [AI/ML · SageMaker AI Qwen PII 가이드북](https://www.atomai.click/kubernetes-docs/llms/ko/ai-ml/sagemaker-ai/README.md): 이 가이드북은 Qwen/Qwen3-30B-A3B-Instruct-2507의 QLoRA 실험을 위한 설계와 component-tested 예제 패키지를 설명합니다.
- [AI/ML · Part 1: 플랫폼 아키텍처](https://www.atomai.click/kubernetes-docs/llms/ko/ai-ml/sagemaker-ai/01-platform-architecture.md): 현재 PyTorch 2.8 DLC의 패치 지원 종료로 GPU 실행이 차단됩니다. 실행 장의 지원되는 런타임 갱신 조건을 먼저 확인합니다.
- [AI/ML · Part 2: 합성 PII 데이터와 토큰화](https://www.atomai.click/kubernetes-docs/llms/ko/ai-ml/sagemaker-ai/02-pii-data-tokenization.md): 모델 출력 계약은 한 줄당 TYPEORIGINAL입니다. 다음은 합성 예시이며 모델이 문서를 직접 다시 작성하지 않습니다.
- [AI/ML · Part 3: SageMaker AI와 MLflow 실행](https://www.atomai.click/kubernetes-docs/llms/ko/ai-ml/sagemaker-ai/03-sagemaker-mlflow-execution.md): 현재 커밋된 GPU 실행 경로는 지원 종료 이미지 때문에 차단됩니다. 예제의 PyTorch 2.8.0-gpu-py312-cu129-ubuntu22.04-sagemaker DLC는 공식 카탈로그에서 패치 지원 종료일을 2026-08-06으로 명시합니다.
- [AI/ML · Part 5: 실제 검증 결과](https://www.atomai.click/kubernetes-docs/llms/ko/ai-ml/sagemaker-ai/04-validation-results.md): 이 장은 저장소의 2026년 9월 1~2일 실험 기록을 설명합니다. 당시 로컬 검사와 AWS provisioning·부분 정리 결과를 보존한 문서이며, 현재 AWS 계정 상태를 새로 조회한 결과가 아닙니다.
- [Security & Policy · Kyverno를 사용한 정책 관리](https://www.atomai.click/kubernetes-docs/llms/ko/security/01-kyverno-policy-management.md): Kyverno는 Kubernetes 정책을 평가하고 명시적으로 구성한 mutation·generation·deletion을 수행합니다. 다음 예제는 실제 CLI와 배포된 schema/chart로 로컬 검증했습니다.
- [Security & Policy · Kubernetes 인증 및 권한 부여](https://www.atomai.click/kubernetes-docs/llms/ko/security/02-kubernetes-auth-authz.md): 인증은 요청의 신원을 확인하고, 인가는 그 신원이 수행할 수 있는 API 작업을 결정하며, 어드미션은 허용된 변경 요청에 추가 정책을 적용합니다. 아래 매니페스트는 독립적인 학습 예제이며, 네임스페이스·관리 권한·인증서·웹훅 서버를 미리 준비해야 합니다.
- [Security & Policy · Pod Security Standards](https://www.atomai.click/kubernetes-docs/llms/ko/security/03-pod-security-standards.md): Pod Security Standards(PSS)는 Kubernetes에서 Pod 보안을 위한 표준화된 정책 프레임워크입니다. 이 문서에서는 PSS의 개념, 구성 방법, 그리고 EKS 환경에서의 적용 방법을 상세히 알아봅니다.
- [Security & Policy · 네트워크 정책](https://www.atomai.click/kubernetes-docs/llms/ko/security/04-network-policies.md): Kubernetes 네트워크 정책은 Pod 간 트래픽을 제어하는 방화벽 규칙입니다. 이 문서에서는 기본 NetworkPolicy부터 Cilium과 Calico의 확장 기능까지 상세히 다룹니다.
- [Security & Policy · 시크릿 관리](https://www.atomai.click/kubernetes-docs/llms/ko/security/05-secrets-management.md): 네이티브 Secret, ESO, AWS 저장소, Sealed Secrets, Vault, SOPS의 책임과 실제 연결 조건을 구분합니다. 전체 예제 파일을 함께 사용합니다. 클러스터·AWS 설치나 실제 자격 증명 교체는 실행하지 않았습니다.
- [Security & Policy · EKS 보안 모범 사례](https://www.atomai.click/kubernetes-docs/llms/ko/security/06-eks-security-best-practices.md): Amazon EKS 환경에서의 보안 모범 사례를 다룹니다. IAM 통합부터 네트워크 보안, 런타임 보호까지 EKS 클러스터를 안전하게 운영하는 방법을 상세히 알아봅니다.
- [Security & Policy · 컨테이너 이미지 보안](https://www.atomai.click/kubernetes-docs/llms/ko/security/07-image-security.md): 이미지 보안은 빌드한 이미지, 검사한 이미지, 배포하는 이미지가 같은 artifact인지 확인하는 데서 시작합니다. 스캔은 알려진 취약점과 구성 문제를 찾고, 서명은 서명자와 digest의 연결을 검증합니다. 어느 하나도 애플리케이션이 안전하다는 보증은 아닙니다.
- [Security & Policy · 런타임 보안](https://www.atomai.click/kubernetes-docs/llms/ko/security/08-runtime-security.md): 런타임 보안은 실행 중인 프로세스·파일·네트워크 활동을 관찰하고, 검증된 정책으로 일부 동작을 제한하는 일입니다. 경보는 침해의 확정 증거가 아니며, 탐지 성공과 차단 성공은 별도로 시험해야 합니다. 이 문서는 로컬 CLI·schema·Helm·합성 이벤트로 확인했습니다.
- [Security & Policy · OPA Gatekeeper](https://www.atomai.click/kubernetes-docs/llms/ko/security/09-opa-gatekeeper.md): Gatekeeper는 Kubernetes admission과 주기적 audit에서 정책을 평가합니다. ConstraintTemplate은 로직·파라미터 schema를 정의하고 Constraint는 적용 범위·값·enforcementAction을 지정합니다.
- [Security & Policy · cert-manager](https://www.atomai.click/kubernetes-docs/llms/ko/security/10-cert-manager.md): cert-manager는 인증서 발급·갱신을 Kubernetes 리소스로 관리합니다. CA 신뢰 배포, 애플리케이션 reload, 인증서 폐기·CRL/OCSP 운영은 별도 책임입니다.
- [Security & Policy · Kubescape](https://www.atomai.click/kubernetes-docs/llms/ko/security/11-kubescape.md): Kubescape는 Kubernetes 구성과 선택한 이미지·런타임 데이터를 평가합니다. 스캔 통과는 보안 보증이나 컴플라이언스 인증이 아니며, 검사하지 못한 항목도 구분해야 합니다. 이 문서는 로컬 YAML·정책 bundle·실제 CLI·차트 렌더링을 검증했습니다.
- [Security & Policy · SPIFFE/SPIRE](https://www.atomai.click/kubernetes-docs/llms/ko/security/12-spiffe-spire.md): SPIFFE는 워크로드 신원과 자격 증명·전달·신뢰 형식을 정의하고 SPIRE는 이를 구현합니다. 신원 발급만으로 트래픽 암호화나 서비스 권한 부여가 자동 구현되지는 않습니다.
- [GitOps](https://www.atomai.click/kubernetes-docs/llms/ko/gitops/README.md): GitOps는 클라우드 네이티브 애플리케이션의 지속적 배포(Continuous Deployment)를 위한 운영 모델입니다. Git 저장소를 "진실의 원천(Single Source of Truth)"으로 사용하여 인프라와 애플리케이션 구성을 선언적으로 정의하고 관리합니다.
- [GitOps · ArgoCD](https://www.atomai.click/kubernetes-docs/llms/ko/gitops/argocd/README.md): ArgoCD는 Kubernetes를 위한 선언적 GitOps 지속적 배포(Continuous Delivery) 도구입니다. CNCF Graduated 프로젝트인 Argo의 구성 요소로, Git 저장소에 정의된 애플리케이션 상태를 Kubernetes 클러스터에 자동으로 동기화합니다.
- [GitOps · 설치 및 구성](https://www.atomai.click/kubernetes-docs/llms/ko/gitops/argocd/01-installation.md): 이 가이드는 자체 설치용입니다. EKS 관리형 Argo CD capability는 별도 생성·권한·설정 절차를 사용하며 여기에 self-managed 설치를 겹치지 않습니다. 개요의 호환성 표에서 테스트된 Kubernetes 조합과 EKS 지원 기간을 확인합니다.
- [GitOps · 애플리케이션](https://www.atomai.click/kubernetes-docs/llms/ko/gitops/argocd/02-applications.md): 예제는 독립적인 설정입니다. myorg·계정·클러스터·경로는 실제 소스와 권한으로 대체합니다. source/sources와 렌더러, destination.server/name은 사용 방식에 맞게 선택하며 모든 선택지를 동시에 활성화하지 않습니다.
- [GitOps · 동기화 전략](https://www.atomai.click/kubernetes-docs/llms/ko/gitops/argocd/03-sync-strategies.md): 예제는 독립적인 정책 조각입니다. 실제 Application의 source·destination·project를 유지하고 필요한 옵션만 선택합니다. Sync는 적용 작업이고 Refresh는 소스/캐시를 조회해 비교 상태를 갱신합니다.
- [GitOps · ApplicationSets](https://www.atomai.click/kubernetes-docs/llms/ko/gitops/argocd/04-applicationsets.md): ApplicationSet은 템플릿을 사용하여 여러 ArgoCD Application을 자동으로 생성하는 컨트롤러입니다. 대규모 배포, 멀티 클러스터 환경, 동적 환경 관리에 유용합니다.
- [GitOps · 트래픽 관리](https://www.atomai.click/kubernetes-docs/llms/ko/gitops/argocd/05-traffic-management.md): Argo Rollouts는 Kubernetes를 위한 프로그레시브 딜리버리(Progressive Delivery) 컨트롤러입니다. 블루/그린 배포, 카나리 배포, 실험, 자동 롤백 등 고급 배포 전략을 제공합니다.
- [GitOps · 프로젝트와 RBAC](https://www.atomai.click/kubernetes-docs/llms/ko/gitops/argocd/06-projects-rbac.md): AppProject는 ArgoCD에서 Application을 논리적으로 그룹화하고 접근 제어를 설정하는 리소스입니다.
- [GitOps · 보안](https://www.atomai.click/kubernetes-docs/llms/ko/gitops/argocd/07-security.md): 각 SSO 예제는 대안이며 기존 ConfigMap/Secret에 필요한 필드를 병합합니다. argocd-secret의 서버 서명키·다른 자격 증명을 덮어쓰지 않습니다.
- [GitOps · 알림](https://www.atomai.click/kubernetes-docs/llms/ko/gitops/argocd/08-notifications.md): ArgoCD Notifications Controller는 Application 이벤트를 다양한 서비스로 전송합니다.
- [GitOps · 모범 사례](https://www.atomai.click/kubernetes-docs/llms/ko/gitops/argocd/09-best-practices.md): 🔍 인터랙티브 다이어그램 보기
- [GitOps · Rollouts Experiment 심층 분석](https://www.atomai.click/kubernetes-docs/llms/ko/gitops/argocd/10-rollouts-experiment.md): Experiment는 일회성 ReplicaSet들을 만들고 분석을 실행하는 Argo Rollouts CRD입니다. baseline/canary 비교, 사전 검증, 실제 트래픽을 사용하는 실험 등에 사용할 수 있습니다.
- [GitOps · FluxCD](https://www.atomai.click/kubernetes-docs/llms/ko/gitops/02-fluxcd.md): FluxCD는 Kubernetes를 위한 개방적이고 확장 가능한 지속적 배포 및 점진적 배포 솔루션 세트입니다. FluxCD는 2022년 11월에 CNCF를 졸업하여 클라우드 네이티브 생태계에서 가장 성숙한 GitOps 도구 중 하나가 되었습니다.
- [GitOps · GitOps 도구 비교](https://www.atomai.click/kubernetes-docs/llms/ko/gitops/03-gitops-comparison.md): 이 가이드는 Kubernetes 생태계에서 가장 인기 있는 두 가지 선택인 ArgoCD와 FluxCD를 중심으로 GitOps 도구에 대한 포괄적인 비교를 제공합니다.
- [GitOps · Flagger Progressive Delivery](https://www.atomai.click/kubernetes-docs/llms/ko/gitops/04-flagger.md): Flagger는 Canary CRD로 기존 Kubernetes workload의 점진적 배포를 관리합니다. 트래픽과 버전을 제어하지만 데이터베이스 변경이나 외부 부작용을 되돌리는 트랜잭션 관리자는 아닙니다. 아래는 실습 예제이며 실제 네트워크·계측·권한·SLO에 맞게 준비해야 합니다.
- [GitOps · Feature Flags와 OpenFeature](https://www.atomai.click/kubernetes-docs/llms/ko/gitops/05-feature-flags.md): Feature Flag는 코드 배포와 기능 릴리스를 분리하여 프로덕션 환경에서 기능을 안전하게 제어할 수 있게 하는 핵심 기술입니다. 이 문서에서는 CNCF 프로젝트인 OpenFeature 표준과 Kubernetes 네이티브 Feature Flag 관리 방법을 다룹니다.
- [엔터프라이즈 클라우드 거버넌스 · 거버넌스 개요](https://www.atomai.click/kubernetes-docs/llms/ko/governance/00-governance-overview.md): 지금까지의 EKS·네트워킹·보안 문서는 "클러스터 하나, VPC 하나"를 전제로 개별 기능을 설명했습니다. 하지만 수십 개 팀과 수백 명의 엔지니어가 여러 브랜드·도메인·서비스를 운영하는 대규모 엔터프라이즈 조직에서는 질문이 달라집니다.
- [엔터프라이즈 클라우드 거버넌스 · Landing Zone, OU와 조직 Control](https://www.atomai.click/kubernetes-docs/llms/ko/governance/01-landing-zone-and-ou.md): 멀티 어카운트 환경을 표준화할 때 가장 먼저 마주치는 도구는 AWS Control Tower입니다.
- [엔터프라이즈 클라우드 거버넌스 · Account 구성과 IAM 경계](https://www.atomai.click/kubernetes-docs/llms/ko/governance/02-account-and-iam.md): Account를 나누는 축으로 가장 흔하게 등장하는 후보는 팀, 브랜드, 도메인, 환경(production/non-production)입니다. 하지만 Account는 팀 이름 자체가 아니라, 관련 워크로드가 공유하는 보안·quota·비용 책임·lifecycle로 판단해야 합니다.
- [엔터프라이즈 클라우드 거버넌스 · EKS 멀티 계정·멀티 클러스터 아키텍처](https://www.atomai.click/kubernetes-docs/llms/ko/governance/03-eks-multi-account-multi-cluster.md): 여러 팀·도메인의 워크로드를 EKS에 배치하는 방식은 크게 네 가지로 나뉩니다.
- [엔터프라이즈 클라우드 거버넌스 · Shared VPC와 Connectivity](https://www.atomai.click/kubernetes-docs/llms/ko/governance/04-shared-vpc-and-connectivity.md): Shared VPC(AWS RAM으로 subnet을 여러 Account에 공유)를 도입할 때 가장 많이 오해하는 부분은 "공유하면 양쪽이 동등하게 볼 수 있다"는 가정입니다. 실제로는 리소스별로 owner와 participant의 권한이 크게 다릅니다.
- [엔터프라이즈 클라우드 거버넌스 · Data·Security 경계](https://www.atomai.click/kubernetes-docs/llms/ko/governance/05-data-security-boundaries.md): Hybrid가 대부분의 조직에서 현실적인 시작점입니다. 다만 이 선택보다 실제 아키텍처를 더 크게 좌우하는 것은, 다음 절에서 다루는 cross-account 백업·복구의 기술적 제약입니다.
- [엔터프라이즈 클라우드 거버넌스 · 의사결정 프레임워크와 POC 설계](https://www.atomai.click/kubernetes-docs/llms/ko/governance/06-decision-framework-and-poc.md): 지금까지 다룬 Landing Zone, Account/IAM, EKS, VPC, Data/Security 경계는 각각 독립적으로 판정하되, 실제로는 하나의 판정표로 재현 가능해야 합니다. 이 문서는 그 판정표를 어떻게 설계하고, 실측이 필요한 항목을 어떻게 POC로 검증할지 다룹니다.
- [Platform Engineering · Platform Engineering 개요](https://www.atomai.click/kubernetes-docs/llms/ko/platform-engineering/00-platform-engineering-overview.md): Platform Engineering은 개발자 셀프서비스를 위한 도구, 워크플로우, 인프라를 설계하고 구축하며 운영하는 분야입니다.
- [Platform Engineering · Helm](https://www.atomai.click/kubernetes-docs/llms/ko/platform-engineering/01-helm.md): Helm은 chart를 렌더링하고 Kubernetes 리소스와 release 이력을 관리합니다. chart version, appVersion, image tag/digest, release revision은 서로 다른 값입니다.
- [Platform Engineering · AWS Controllers for Kubernetes (ACK)](https://www.atomai.click/kubernetes-docs/llms/ko/platform-engineering/02-ack.md): ACK는 Kubernetes custom resource를 AWS API에 연결하는 서비스별 controller입니다. CRD가 입력 구조를 정의하고 controller가 원하는 상태와 AWS의 관찰된 상태를 조정합니다.
- [Platform Engineering · S3 및 IAM 예제](https://www.atomai.click/kubernetes-docs/llms/ko/platform-engineering/ack/01-s3-iam.md): ACK
- [Platform Engineering · SQS 및 SNS 예제](https://www.atomai.click/kubernetes-docs/llms/ko/platform-engineering/ack/02-sqs-sns.md): ACK
- [Platform Engineering · ELBv2, Route 53, RDS 예제](https://www.atomai.click/kubernetes-docs/llms/ko/platform-engineering/ack/03-elbv2-route53-rds.md): ACK
- [Platform Engineering · Kube Resource Orchestrator (kro)](https://www.atomai.click/kubernetes-docs/llms/ko/platform-engineering/03-kro.md): kro의 공식 이름은 Kube Resource Orchestrator입니다.
- [Platform Engineering · Kubernetes 확장 메커니즘](https://www.atomai.click/kubernetes-docs/llms/ko/platform-engineering/04-kubernetes-extensions.md): Kubernetes API와 workload의 동작을 확장하는 여러 방법이 있습니다. CRD를 등록하는 것과 실제 동작을 구현하는 것은 다릅니다.
- [Platform Engineering · ExampleCorp: ACK + KRO 통합 예제](https://www.atomai.click/kubernetes-docs/llms/ko/platform-engineering/05-example-corp-app.md): ExampleCorp는 학습용 가상 조직입니다. 이 문서는 ACK가 생성한 AWS 인프라에 kro 애플리케이션 그래프를 연결하는 구성 계약이며, 동작하는 Order API 구현이나 공개 이미지를 제공하는 end-to-end 실습은 아닙니다.
- [Platform Engineering · Backstage IDP](https://www.atomai.click/kubernetes-docs/llms/ko/platform-engineering/06-backstage-idp.md): Backstage는 Spotify에서 시작된 오픈소스 개발자 포털 프레임워크이며 Apache 2.0 라이선스입니다. CNCF 프로젝트 페이지는 Incubating 상태로 안내합니다. 포털은 IDP의 사용자 접점이 될 수 있지만 인프라·배포·정책·운영 자동화 전체를 대신하지 않습니다.
- [Platform Engineering · Crossplane](https://www.atomai.click/kubernetes-docs/llms/ko/platform-engineering/07-crossplane.md): Crossplane은 Kubernetes API와 controller로 인프라 및 애플리케이션 리소스를 조정합니다. CNCF 합류는 2020년 6월 25일, Incubating은 2021년 9월 14일, Graduated는 2025년 10월 28일입니다.
- [Platform Engineering · vCluster](https://www.atomai.click/kubernetes-docs/llms/ko/platform-engineering/08-vcluster.md): vCluster는 팀별 Kubernetes API와 controller·데이터 저장소를 제공할 수 있습니다. 이 문서의 Shared Nodes 예제에서는 실제 workload가 호스트 클러스터의 노드에서 실행되므로 kernel·CNI·CSI와 자원 용량을 공유합니다.
- [Container Registry · 컨테이너 레지스트리 개요](https://www.atomai.click/kubernetes-docs/llms/ko/container-registry/README.md): 컨테이너 레지스트리는 Kubernetes 에코시스템에서 컨테이너 이미지를 저장, 관리, 배포하는 핵심 인프라입니다. 일반적인 배포는 레지스트리에서 이미지를 가져오지만, 망분리 환경 등에서는 노드에 미리 적재한 이미지를 사용할 수도 있습니다.
- [Container Registry · Docker Hub](https://www.atomai.click/kubernetes-docs/llms/ko/container-registry/01-docker-hub.md): Docker Hub는 Docker CLI에서 레지스트리를 생략할 때 사용하는 기본 이미지 레지스트리입니다. Docker Official Images, Verified Publishers, 커뮤니티 이미지를 제공하며, 개인 및 팀을 위한 프라이빗 저장소 기능도 지원합니다.
- [Container Registry · Amazon ECR](https://www.atomai.click/kubernetes-docs/llms/ko/container-registry/02-amazon-ecr.md): Amazon Elastic Container Registry(ECR)는 AWS에서 제공하는 완전관리형 컨테이너 레지스트리 서비스입니다.
- [Container Registry · Harbor](https://www.atomai.click/kubernetes-docs/llms/ko/container-registry/03-harbor.md): Harbor는 CNCF Graduated 프로젝트로, 오픈소스 컨테이너 레지스트리입니다. 보안, 정책, 역할 기반 접근 제어를 제공하며, 에어갭(폐쇄망) 환경의 내부 이미지 저장소로도 사용할 수 있습니다.
- [Container Registry · 컨테이너 레지스트리 모범 사례](https://www.atomai.click/kubernetes-docs/llms/ko/container-registry/04-best-practices.md): 이 문서는 Docker Hub, Amazon ECR, Harbor 등 컨테이너 레지스트리를 운영할 때 적용해야 할 모범 사례를 다룹니다. 태그 전략, 보안, 비용 최적화, CI/CD 통합 패턴을 포함합니다.
- [Observability · Observability 개요](https://www.atomai.click/kubernetes-docs/llms/ko/observability/README.md): 현대의 분산 시스템, 특히 Kubernetes 기반 마이크로서비스 아키텍처에서는 시스템의 내부 상태를 외부에서 관찰하고 이해하는 능력이 필수적입니다. 이를 관측성(Observability)이라고 합니다.
- [Observability · Metrics](https://www.atomai.click/kubernetes-docs/llms/ko/observability/metrics/README.md): 메트릭은 시스템의 상태와 동작을 수치로 표현합니다. 메트릭 이름과 전체 레이블 집합이 시계열을 식별하고, 각 샘플에는 값과 타임스탬프가 있습니다. 알림·장애 분석·용량 계획·성능 분석에 활용하지만 샘플링된 측정값이 개별 이벤트를 모두 보존하는 것은 아닙니다.
- [Observability · Prometheus](https://www.atomai.click/kubernetes-docs/llms/ko/observability/metrics/01-prometheus.md): Prometheus는 SoundCloud에서 시작한 CNCF 모니터링 툴킷입니다. 수치 시계열을 수집해 local TSDB에 저장하고, PromQL·recording/alert rule을 평가하며 Alertmanager에 알림을 보냅니다.
- [Observability · VictoriaMetrics](https://www.atomai.click/kubernetes-docs/llms/ko/observability/metrics/02-victoriametrics.md): VictoriaMetrics는 시계열을 저장·조회하며 수집용 vmagent, 규칙 평가용 vmalert를 별도로 제공합니다.
- [Observability · Grafana Mimir](https://www.atomai.click/kubernetes-docs/llms/ko/observability/metrics/03-mimir.md): Grafana Mimir는 테넌트별 수집·조회와 장기 블록 저장을 제공하는 Prometheus 호환 메트릭 백엔드입니다. 처리 용량·쿼리 호환성·운영 비용은 아키텍처와 설정, 실제 워크로드에 따라 달라지며 보존 기간과 확장성이 무제한인 것은 아닙니다.
- [Observability · CloudWatch Metrics](https://www.atomai.click/kubernetes-docs/llms/ko/observability/metrics/04-cloudwatch-metrics.md): CloudWatch는 저장·조회·대시보드·알람 backend를 관리합니다. 팀은 collector, workload identity, network, cardinality, retention과 장애 대응 책임을 여전히 설정해야 합니다.
- [Observability · Datadog](https://www.atomai.click/kubernetes-docs/llms/ko/observability/metrics/05-datadog.md): Datadog은 SaaS 관측 backend를 제공합니다. 팀은 collector·identity·network·계측· 데이터 공개·retention·monitor·비용을 여전히 관리합니다.
- [Observability · Logging](https://www.atomai.click/kubernetes-docs/llms/ko/observability/logging/README.md): Logging은 application 동작·인프라 event·감사 증거를 연결합니다. Event schema, 수집 소유권, 전달 실패 처리, 접근·retention·query를 함께 설계합니다.
- [Observability · Grafana Loki](https://www.atomai.click/kubernetes-docs/llms/ko/observability/logging/01-loki.md): Loki는 로그를 압축 청크로 저장하고 스트림 레이블을 인덱싱합니다. 인덱스 부담을 줄일 수 있지만 Elasticsearch/OpenSearch보다 항상 저렴하거나 빠르다는 뜻은 아닙니다.
- [Observability · OpenSearch](https://www.atomai.click/kubernetes-docs/llms/ko/observability/logging/02-opensearch.md): Amazon OpenSearch Service는 검색 클러스터를 관리하며 선택된 OpenSearch 및 legacy Elasticsearch OSS 버전을 지원합니다. 이 장은 VPC 도메인과 기존 hot/UltraWarm/cold 계층을 다룹니다.
- [Observability · CloudWatch Logs](https://www.atomai.click/kubernetes-docs/llms/ko/observability/logging/03-cloudwatch-logs.md): Amazon CloudWatch Logs는 로그 수집·저장·분석을 관리합니다. Producer, identity, 네트워크, 보존, quota와 downstream consumer는 별도로 구성해야 합니다.
- [Observability · ClickHouse](https://www.atomai.click/kubernetes-docs/llms/ko/observability/logging/04-clickhouse.md): ClickHouse는 컬럼 기반 분석 데이터베이스입니다. SQL 필터·집계·JOIN이 필요한 로그 분석에 적합할 수 있지만, 수집 스키마·보존 기간·운영 방식이 실제 workload에 맞는지 확인해야 합니다.
- [Observability · Log Collectors](https://www.atomai.click/kubernetes-docs/llms/ko/observability/logging/05-collectors.md): Fluent Bit, Grafana Alloy, OpenTelemetry Collector를 비교하고 지원 종료된 Promtail에서의 마이그레이션을 설명합니다. 고정된 메모리·초당 이벤트 순위가 아니라 실제 입력, 출력 플러그인, 배포 권한, 실패 동작으로 수집기를 선택합니다.
- [Observability · Tracing](https://www.atomai.click/kubernetes-docs/llms/ko/observability/tracing/README.md): 분산 추적은 계측한 작업을 프로세스 경계 너머로 기록하고 전파한 context로 연결합니다. 저장된 trace는 관측된 span 집합이지 모든 작업·요청을 수집했다는 증거는 아닙니다.
- [Observability · Grafana Tempo](https://www.atomai.click/kubernetes-docs/llms/ko/observability/tracing/01-tempo.md): Grafana Tempo는 오브젝트 스토리지, Parquet 블록, TraceQL로 분산 추적을 저장하고 조회합니다. TraceID로 찾을 수 있는 것은 정상 수집되어 아직 보관 중인 데이터입니다. 샘플링·전송 실패·보존 기간 만료로 사라진 스팬은 복구하지 못합니다.
- [Observability · AWS X-Ray](https://www.atomai.click/kubernetes-docs/llms/ko/observability/tracing/02-xray.md): AWS X-Ray는 분산 애플리케이션의 요청을 추적하고 분석하는 AWS 네이티브 서비스입니다. EKS 환경에서 X-Ray를 사용하면 마이크로서비스 간의 요청 흐름을 시각화하고, 성능 병목을 식별하며, 오류의 근본 원인을 파악할 수 있습니다.
- [Observability · OpenTelemetry](https://www.atomai.click/kubernetes-docs/llms/ko/observability/tracing/03-opentelemetry.md): OpenTelemetry(OTel)는 클라우드 네이티브 소프트웨어를 위한 관측성 프레임워크입니다. Traces, Metrics, Logs의 세 가지 신호를 생성, 수집, 관리하기 위한 벤더 중립적 표준을 제공합니다.
- [Observability · Dynatrace](https://www.atomai.click/kubernetes-docs/llms/ko/observability/tracing/04-dynatrace.md): Dynatrace는 애플리케이션·인프라 텔레메트리를 토폴로지 및 문제 분석과 결합합니다. OneAgent 자동 계측은 지원 런타임, 배포 모드, 권한에 따라 달라지므로 Operator 설치만으로 모든 신호가 수집되지는 않습니다.
- [Observability · Alerting](https://www.atomai.click/kubernetes-docs/llms/ko/observability/alerting/README.md): 🔍 인터랙티브 다이어그램 보기
- [Observability · Alertmanager](https://www.atomai.click/kubernetes-docs/llms/ko/observability/alerting/01-alertmanager.md): Prometheus Alertmanager는 Prometheus 서버에서 전송된 알림을 처리하는 컴포넌트입니다. 알림의 중복 제거, 그룹화, 라우팅, 억제(inhibition), 무음(silencing) 등의 기능을 제공합니다.
- [Observability · CloudWatch Alarms](https://www.atomai.click/kubernetes-docs/llms/ko/observability/alerting/02-cloudwatch-alarms.md): 이 장의 CLI·Terraform 예제는 기존 CloudWatch Metric Alarm과 Composite Alarm을 다룹니다.
- [Observability · Grafana OnCall](https://www.atomai.click/kubernetes-docs/llms/ko/observability/alerting/03-grafana-oncall.md): Grafana OnCall OSS는 2026-03-24에 보관 처리되었습니다. 저장소는 grafana-cold-storage/oncall로 이동했으며 읽기 전용입니다. 이 장은 기존 설치의 구조·API·이전 검토용이고 새로운 프로덕션 OSS 도입을 권장하는 설치 가이드가 아닙니다.
- [Observability · Grafana](https://www.atomai.click/kubernetes-docs/llms/ko/observability/grafana/README.md): Grafana는 Prometheus·Loki·Tempo·CloudWatch 같은 데이터 소스를 조회하고 대시보드와 알림을 제공합니다. Grafana의 메타데이터 DB와 메트릭·로그·추적 저장소는 역할이 다릅니다.
- [Observability · 관측성 최적화 가이드](https://www.atomai.click/kubernetes-docs/llms/ko/observability/09-observability-optimization.md): 관측성 최적화는 장애 조사에 필요한 질문, 수집 품질, 실제 비용에서 시작합니다. 노드 수만으로 수집량·조회 부하·보존 비용·운영 인력을 예측할 수 없습니다. 이 장은 완전한 설정 예제를 제공하고 클러스터 설치는 각 배포 가이드로 연결합니다.
- [Operations Guide · 운영 가이드 소개](https://www.atomai.click/kubernetes-docs/llms/ko/ops/README.md): 이 섹션은 EKS Auto Mode 기반 프로덕션 환경의 실전 운영 가이드입니다. Terraform을 사용한 인프라 프로비저닝부터 CI/CD 파이프라인, GitOps 기반 배포, 스케일링, 관측성, 리소스 최적화, 업그레이드까지 포괄합니다.
- [Operations Guide · 인프라 구성 기초](https://www.atomai.click/kubernetes-docs/llms/ko/ops/01-infrastructure-setup.md): 이 예제는 계정·환경별 상태 버킷과 한 리전의 blue/green 클러스터를 설명합니다. 기본 Auto Mode NodePool은 구성된 여러 AZ를 사용할 수 있으며, 색상 이름이나 서브넷 태그만으로 노드가 한 AZ에 고정되지 않습니다.
- [Operations Guide · 인프라 구성 고급](https://www.atomai.click/kubernetes-docs/llms/ko/ops/02-infrastructure-advanced.md): 두 구성을 구분합니다. 하나의 NLB에서 타겟 그룹 가중치를 조정하는 구성과 서로 독립적인 로드밸런서 두 개를 DNS로 선택하는 구성입니다. 같은 공유 NLB를 가리키는 DNS 이름만 둘로 나눠서는 클러스터를 독립적으로 선택할 수 없습니다.
- [Operations Guide · CI 파이프라인 구성](https://www.atomai.click/kubernetes-docs/llms/ko/ops/03-ci-pipelines.md): 이 예제는 신뢰하는 보호된 게시 작업을 위한 전용 CI 클러스터를 전제로 합니다. 아래 Docker-in-Docker는 privileged입니다. 파드가 나뉜다는 것만으로 완전한 보안 경계가 생기지는 않습니다.
- [Operations Guide · GitOps 멀티 클러스터](https://www.atomai.click/kubernetes-docs/llms/ko/ops/04-gitops-multi-cluster.md): 이 장은 관리 EKS(Hub)의 Argo CD가 두 워크로드 EKS(Spoke)를 관리하는 구성을 다룹니다. 앞 장의 CI는 승인한 이미지 digest를 만들고, 검토된 Git 변경이 배포할 digest를 선택합니다.
- [Operations Guide · GitOps 자동화](https://www.atomai.click/kubernetes-docs/llms/ko/ops/05-gitops-automation.md): 인프라 변경을 실행하는 도구와 애플리케이션을 동기화하는 도구의 소유권을 분리합니다. 같은 Terraform state를 Atlantis와 HCP Terraform에서 동시에 실행하거나, 같은 Kubernetes 필드를 Flux와 Argo CD가 동시에 관리하지 않습니다.
- [Operations Guide · 스케일링 전략](https://www.atomai.click/kubernetes-docs/llms/ko/ops/06-scaling-strategies.md): 이 장은 커스텀 메트릭 HPA, KEDA, VPA와 Spot 배치를 구분합니다. 한 워크로드의 replicas는 하나의 autoscaler가 소유해야 합니다.
- [Operations Guide · Observability 알림 설정](https://www.atomai.click/kubernetes-docs/llms/ko/ops/07-observability-alerts.md): 알림은 지표의 이름만 복사해 만들 수 없습니다. 수집 대상, metric type, label, 단위와 누락 시 동작을 먼저 확인하고, 실제 서비스 영향과 운영 팀의 대응 절차에 맞춰 임계값을 정합니다.
- [Operations Guide · Observability 분석 방법](https://www.atomai.click/kubernetes-docs/llms/ko/ops/08-observability-analysis.md): 상관 분석은 같은 시간·서비스·요청에 관한 근거를 연결하는 작업입니다. 함께 발생했다는 사실만으로 root cause가 확정되지는 않습니다. 데이터 누락·샘플링·보존 기간도 확인한 뒤 가설을 검증합니다.
- [Operations Guide · Observability 스택 구성](https://www.atomai.click/kubernetes-docs/llms/ko/ops/09-observability-stack.md): 이 장은 로그·트레이스·메트릭의 수집 경로, 저장, 권한, 보존, 조회 연결을 구성합니다. 애플리케이션의 Go/Python 계측과 Java JSON 로그는 앞 장의 실행 가능한 예제를 사용합니다. Grafana를 설치하는 것만으로 세 신호가 연결되지는 않습니다.
- [Operations Guide · 리소스 최적화](https://www.atomai.click/kubernetes-docs/llms/ko/ops/10-resource-optimization.md): 리소스 크기는 언어 이름이나 고정 비율만으로 정하지 않습니다. 대표 부하·시작·재시작·GC· 장애 상황에서 처리량과 지연 SLO를 측정하고 requests, limits, 복제본, 런타임 동시성을 함께 조정합니다. 예제의 메모리 비율과 임계값은 시험 시작점이며 성능 보장이 아닙니다.
- [Operations Guide · EKS 업그레이드 운영](https://www.atomai.click/kubernetes-docs/llms/ko/ops/11-upgrade-operations.md): 컨트롤 플레인·노드·애드온·앱·데이터를 함께 계획합니다. Auto Mode와 PDB만으로 무중단을 보장하지 않습니다. 여유 용량, readiness, 재연결, 세션, 저장 상태와 복구를 검증해 가용성 목표를 충족합니다.
- [Operations Guide · 이벤트 용량 계획 플레이북](https://www.atomai.click/kubernetes-docs/llms/ko/ops/12-event-capacity-planning.md): PM/기획자는 목표 수요·시작/종료·허용 지연·장애 시 목표를 제공하고, 운영팀은 앱/노드/DB/네트워크/큐의 처리량·한도·준비 시간을 검증합니다. 이벤트 종류만으로 “10–50배”, “30분이면 준비 완료” 같은 수치를 보장하지 않습니다.
- [Operations Guide · FinOps 비용 가시성 플랫폼](https://www.atomai.click/kubernetes-docs/llms/ko/ops/13-finops-cost-platform.md): FinOps는 엔지니어링·재무·제품·비즈니스가 기술 지출의 가치를 함께 관리하는 운영 방식입니다. 비용을 줄이는 것만으로 성공을 판단하지 않습니다. 서비스 수준, 성장, 단위 경제성과 비용 귀속의 신뢰도를 함께 봅니다.
- [Operations Guide · Tekton Pipelines](https://www.atomai.click/kubernetes-docs/llms/ko/ops/14-tekton-pipelines.md): Tekton은 Kubernetes API에 Task·Pipeline과 실행 인스턴스를 정의하는 CI/CD 프레임워크입니다. 컨트롤러, 실행 노드, 스토리지, 업그레이드와 접근 제어를 직접 운영합니다.
- [Operations Guide · Zonal 클러스터 운영 전략](https://www.atomai.click/kubernetes-docs/llms/ko/ops/15-zonal-operations-guide.md): 이 문서는 AZ별 워커를 갖는 클러스터 플릿의 트래픽 전환, 조건부 버전 롤백, 데이터 읽기의 AZ 친화성을 함께 다룹니다. Zonal 구성은 모든 팀의 기본 선택이 아닙니다. 셀별 용량·라우팅·배포·데이터 의존성을 독립적으로 운영할 수 있을 때 검토하는 장애 격리 전략입니다.
- [Operations Guide · 트러블슈팅 플레이북](https://www.atomai.click/kubernetes-docs/llms/ko/ops/16-troubleshooting-playbook.md): 새벽 3시에 알림을 받고 터미널을 열었을 때 필요한 것은 개념 설명이 아니라 지금 보이는 증상에서 다음에 칠 명령입니다. 이 문서는 개념이 아니라 증상에서 출발합니다.
- [Operations Guide · EKS Spot 운영 적용 실험과 결과 판정](https://www.atomai.click/kubernetes-docs/llms/ko/ops/17-spot-production-experiments.md): Spot 도입은 할인율보다 노드가 회수되는 동안 서비스 SLO와 데이터 정합성을 유지하는지로 판단합니다. On-Demand 기준선을 먼저 측정하고, 같은 부하에서 Spot 혼합 구성의 장애 대응과 실효 비용을 비교합니다. 1–6절의 제안 수치와 기간은 실험 설계 예시입니다.

## Docs (English)

- [Introduction · Guidebook Roadmap](https://www.atomai.click/kubernetes-docs/llms/en/roadmap.md): This guidebook tells one continuous story: from the Linux kernel through containers, Kubernetes, Amazon EKS, networking, service mesh, storage, databases, data…
- [Introduction · Reading with LLMs](https://www.atomai.click/kubernetes-docs/llms/en/llm-guide.md): This guidebook provides the proposed llms.txt format and per-document Markdown.
- [News](https://www.atomai.click/kubernetes-docs/llms/en/news/README.md): This page records documentation changes prompted by Kubernetes, Amazon EKS and CNCF news.
- [Linux & Container · Linux Basics](https://www.atomai.click/kubernetes-docs/llms/en/basics/01-linux-basics.md): Understanding Linux fundamentals is essential for comprehending Kubernetes and container technology.
- [Linux & Container · Linux Operations Skills](https://www.atomai.click/kubernetes-docs/llms/en/basics/02-linux-advanced.md): This document covers essential Linux operations skills for working effectively in Kubernetes environments.
- [Linux & Container · Container Technology](https://www.atomai.click/kubernetes-docs/llms/en/basics/03-container-technology.md): Containers are a technology that packages applications and their dependencies together, enabling consistent execution across various environments.
- [Linux & Container · eBPF Fundamentals and Practical Applications](https://www.atomai.click/kubernetes-docs/llms/en/basics/05-ebpf-fundamentals.md): eBPF is a revolutionary technology that allows sandboxed programs to run within the Linux kernel.
- [Linux Kernel · Linux Kernel Overview](https://www.atomai.click/kubernetes-docs/llms/en/kernel/README.md): Most Kubernetes documentation explains things on top of a declarative API.
- [Linux Kernel · Kernel Features Behind Containers](https://www.atomai.click/kubernetes-docs/llms/en/kernel/01-container-primitives.md): This is the starting point for understanding containers. There is no struct container, and no single syscall that creates one.
- [Linux Kernel · Kernel Networking Stack](https://www.atomai.click/kubernetes-docs/llms/en/kernel/02-network-stack.md): "The network is slow" is not a diagnosable sentence.
- [Linux Kernel · EKS Node Kernel Tuning](https://www.atomai.click/kubernetes-docs/llms/en/kernel/03-eks-node-tuning.md): This is the most important advice in this document.
- [Kubernetes Core Concepts · Introduction to Kubernetes](https://www.atomai.click/kubernetes-docs/llms/en/basics/04-kubernetes-introduction.md): Kubernetes (K8s) is an open-source container orchestration platform that automates the deployment, scaling, and management of containerized applications.
- [Kubernetes Core Concepts · Cluster Architecture](https://www.atomai.click/kubernetes-docs/llms/en/core/01-cluster-architecture.md): The version header refers to upstream Kubernetes.
- [Kubernetes Core Concepts · Pods and Workloads](https://www.atomai.click/kubernetes-docs/llms/en/core/02-pods-and-workloads.md): This document provides a detailed explanation of Pods, the basic execution unit in Kubernetes, and the various workload resources that manage them.
- [Kubernetes Core Concepts · Services and Networking](https://www.atomai.click/kubernetes-docs/llms/en/core/03-services-networking.md): In Kubernetes, a Service is an abstraction layer that provides a single access point for a set of Pods.
- [Kubernetes Core Concepts · Storage](https://www.atomai.click/kubernetes-docs/llms/en/core/04-storage.md): In Kubernetes, storage is an important part of storing and managing data for containerized applications.
- [Kubernetes Core Concepts · Configuration](https://www.atomai.click/kubernetes-docs/llms/en/core/05-configuration-secrets.md): In Kubernetes, configuration management is an important part of managing application settings separately from code.
- [Kubernetes Core Concepts · Security](https://www.atomai.click/kubernetes-docs/llms/en/core/06-security.md): In Kubernetes, security is a key element for protecting clusters and applications.
- [Kubernetes Core Concepts · Policies](https://www.atomai.click/kubernetes-docs/llms/en/core/07-policies.md): In Kubernetes, policies are sets of rules that control and regulate the behavior of clusters and workloads.
- [Kubernetes Core Concepts · Scheduling, Preemption and Eviction](https://www.atomai.click/kubernetes-docs/llms/en/core/08-scheduling-preemption-eviction.md): In Kubernetes, scheduling is the process of placing pods on appropriate nodes.
- [Kubernetes Core Concepts · Cluster Administration](https://www.atomai.click/kubernetes-docs/llms/en/core/09-cluster-administration.md): Kubernetes cluster administration is an important task that includes cluster setup, maintenance, monitoring, troubleshooting, and upgrades.
- [Kubernetes Core Concepts · Windows in Kubernetes](https://www.atomai.click/kubernetes-docs/llms/en/core/10-windows-in-kubernetes.md): Kubernetes was originally designed for Linux containers, but production support for Windows containers was added starting with version 1.14.
- [Kubernetes Core Concepts · Extending Kubernetes](https://www.atomai.click/kubernetes-docs/llms/en/core/11-extending-kubernetes.md): Kubernetes is a platform designed with extensibility in mind, allowing you to extend its functionality in various ways.
- [Kubernetes Core Concepts · Custom Scheduler](https://www.atomai.click/kubernetes-docs/llms/en/scheduling/01-custom-scheduler-part1.md): The Kubernetes scheduler is a critical component that decides which node a pod should be placed on.
- [Kubernetes Core Concepts · Part 2: Implementation](https://www.atomai.click/kubernetes-docs/llms/en/scheduling/02-custom-scheduler-part2.md): Use the Part1 module setup and complete secondary-scheduler RBAC/Deployment. These are two alternative extension methods for that scheduler.
- [Kubernetes Core Concepts · Part 3: Advanced Features](https://www.atomai.click/kubernetes-docs/llms/en/scheduling/03-custom-scheduler-part3.md): These are illustrative implementation patterns using the Part1 secondary scheduler and Part2 framework interfaces.
- [Kubernetes Core Concepts · KEDA](https://www.atomai.click/kubernetes-docs/llms/en/autoscaling/01-keda.md): KEDA (Kubernetes Event-driven Autoscaling) is an open-source project that enables event-driven autoscaling for Kubernetes applications.
- [Kubernetes Core Concepts · Karpenter](https://www.atomai.click/kubernetes-docs/llms/en/autoscaling/02-karpenter.md): Karpenter is an open-source node autoscaler. This chapter uses its AWS provider, which provisions EC2 capacity for compatible Kubernetes workloads.
- [Kubernetes Core Concepts · Knative](https://www.atomai.click/kubernetes-docs/llms/en/autoscaling/03-knative.md): Knative is a CNCF Graduated project that extends Kubernetes to provide a set of middleware components for building, deploying, and managing modern serverless…
- [Amazon EKS · Introduction to EKS](https://www.atomai.click/kubernetes-docs/llms/en/eks/01-eks-introduction.md): Amazon Elastic Kubernetes Service (EKS) is a managed service for running Kubernetes on AWS.
- [Amazon EKS · EKS Cluster Creation](https://www.atomai.click/kubernetes-docs/llms/en/eks/02-eks-cluster-creation.md): There are several ways to create an Amazon EKS cluster. In this chapter, we will learn in detail how to create an EKS cluster using various tools and methods.
- [Amazon EKS · Part 1: Prerequisites](https://www.atomai.click/kubernetes-docs/llms/en/eks/02-eks-cluster-creation-part1.md): There are several ways to create an Amazon EKS cluster. In this chapter, we will learn how to create an EKS cluster using various tools and methods.
- [Amazon EKS · Part 2: Creating Clusters with eksctl](https://www.atomai.click/kubernetes-docs/llms/en/eks/02-eks-cluster-creation-part2.md): Use the Part 1 prerequisites, a dedicated training account/cluster and a private temporary kubeconfig (EKSKUBECONFIG).
- [Amazon EKS · Part 3: Creating Clusters with AWS Management Console and CLI](https://www.atomai.click/kubernetes-docs/llms/en/eks/02-eks-cluster-creation-part3.md): Complete the Part 1 prerequisites.
- [Amazon EKS · Part 4: Creating Clusters with Terraform and CDK](https://www.atomai.click/kubernetes-docs/llms/en/eks/02-eks-cluster-creation-part4.md): Terraform manages infrastructure as code. This example uses AWS provider 6.x and pins EKS module 21.25.0 and VPC module 5.21.0.
- [Amazon EKS · Part 5: Cluster Access, Validation, Upgrade and Deletion](https://www.atomai.click/kubernetes-docs/llms/en/eks/02-eks-cluster-creation-part5.md): This guide covers an existing EKS cluster. Use the authorized account/Region and a private kubeconfig.
- [Amazon EKS · Conclusion](https://www.atomai.click/kubernetes-docs/llms/en/eks/02-eks-cluster-creation-conclusion.md): We have explored various methods for creating EKS clusters. Let's compare the advantages and disadvantages of each method.
- [Amazon EKS · EKS Networking](https://www.atomai.click/kubernetes-docs/llms/en/eks/03-eks-networking-part1.md): This chapter covers VPC/subnet planning and security-group paths for a conventional EKS cluster.
- [Amazon EKS · Part 2: Advanced Configuration](https://www.atomai.click/kubernetes-docs/llms/en/eks/03-eks-networking-part2.md): In this document, we will learn about services, load balancing, and network policies in Amazon EKS.
- [Amazon EKS · Part 3: Troubleshooting](https://www.atomai.click/kubernetes-docs/llms/en/eks/03-eks-networking-part3.md): This document covers performance optimization, troubleshooting methods, and advanced use cases for Amazon EKS networking.
- [Amazon EKS · EKS Storage](https://www.atomai.click/kubernetes-docs/llms/en/eks/04-eks-storage-part1.md): When running applications on Amazon EKS, there are various storage options for storing and managing data.
- [Amazon EKS · Part 2: Storage Classes](https://www.atomai.click/kubernetes-docs/llms/en/eks/04-eks-storage-part2.md): This document is the second part of the Amazon EKS storage series, covering FSx for Lustre, Amazon S3, snapshots, volume expansion, and performance…
- [Amazon EKS · Part 3: Advanced Configuration](https://www.atomai.click/kubernetes-docs/llms/en/eks/04-eks-storage-part3.md): This document is the third and final part of the Amazon EKS storage series, covering storage monitoring, troubleshooting, cost optimization, and security.
- [Amazon EKS · EKS Security](https://www.atomai.click/kubernetes-docs/llms/en/eks/05-eks-security.md): To securely run workloads on Amazon EKS (Elastic Kubernetes Service), you need to understand and implement various security layers and best practices.
- [Amazon EKS · EKS Monitoring and Logging](https://www.atomai.click/kubernetes-docs/llms/en/eks/06-eks-monitoring-logging.md): Effective monitoring and logging are essential for maintaining the reliability, availability, and performance of Amazon EKS clusters.
- [Amazon EKS · EKS Cost Optimization](https://www.atomai.click/kubernetes-docs/llms/en/eks/07-eks-cost-optimization.md): Amazon EKS (Elastic Kubernetes Service) makes it easy to deploy, manage, and scale containerized applications, but managing costs effectively is important.
- [Amazon EKS · EKS Upgrades](https://www.atomai.click/kubernetes-docs/llms/en/eks/08-eks-upgrades.md): Keeping your Amazon EKS cluster up to date is important for security, stability, and leveraging new features.
- [Amazon EKS · EKS Troubleshooting](https://www.atomai.click/kubernetes-docs/llms/en/eks/09-eks-troubleshooting.md): When operating Amazon EKS clusters, various issues can arise. This document provides common problems that can occur in EKS clusters and their solutions.
- [Amazon EKS · EKS Resiliency and High Availability](https://www.atomai.click/kubernetes-docs/llms/en/eks/10-eks-resiliency.md): These are configuration patterns, not a tested production platform.
- [Amazon EKS · EKS Advanced Debugging](https://www.atomai.click/kubernetes-docs/llms/en/eks/11-eks-advanced-debugging.md): For stable operation of Amazon EKS clusters, a systematic incident response framework and advanced debugging skills are essential.
- [Amazon EKS · Kubernetes Version Features and Roadmap](https://www.atomai.click/kubernetes-docs/llms/en/eks/12-kubernetes-version-roadmap.md): Kubernetes evolves rapidly, with three releases per year introducing new features, graduating existing ones, and deprecating old APIs.
- [Amazon EKS · EKS Hybrid Nodes](https://www.atomai.click/kubernetes-docs/llms/en/eks-hybrid-nodes/README.md): Amazon EKS Hybrid Nodes connects customer-operated on-premises or edge nodes to an AWS-managed EKS control plane.
- [Amazon EKS · Prerequisites](https://www.atomai.click/kubernetes-docs/llms/en/eks-hybrid-nodes/01-prerequisites.md): Prepare host, network, credentials and cluster access before joining a hybrid node.
- [Amazon EKS · Network Configuration](https://www.atomai.click/kubernetes-docs/llms/en/eks-hybrid-nodes/02-network-configuration.md): Validate routing, DNS, TLS, credentials and application traffic separately.
- [Amazon EKS · Air-Gap Environment Setup](https://www.atomai.click/kubernetes-docs/llms/en/eks-hybrid-nodes/03-airgap-setup.md): This chapter prepares Hybrid Nodes whose public internet access is restricted.
- [Amazon EKS · Node Bootstrap](https://www.atomai.click/kubernetes-docs/llms/en/eks-hybrid-nodes/04-node-bootstrap.md): This chapter connects a prepared on-premises host to EKS. It separates software installation, AWS identity, initialization and verified workload readiness.
- [Amazon EKS · GPU Server Integration](https://www.atomai.click/kubernetes-docs/llms/en/eks-hybrid-nodes/05-gpu-integration.md): This chapter integrates prepared NVIDIA GPU hosts with EKS Hybrid Nodes. It covers allocation, GPU Operator ownership, MIG and time-slicing.
- [Amazon EKS · Workload Placement Strategies](https://www.atomai.click/kubernetes-docs/llms/en/eks-hybrid-nodes/06-workload-placement.md): This chapter places workloads on Hybrid and cloud nodes and explains the limits of cloud bursting and Pod deletion cost.
- [Amazon EKS · Node Lifecycle Management](https://www.atomai.click/kubernetes-docs/llms/en/eks-hybrid-nodes/07-node-lifecycle.md): This document covers advanced nodeadm configuration, fleet installation automation, upgrade strategies, credential lifecycle management, and health monitoring…
- [Amazon EKS · Operations and Maintenance](https://www.atomai.click/kubernetes-docs/llms/en/eks-hybrid-nodes/08-operations.md): This document covers day-to-day operations and maintenance tasks for EKS Hybrid Nodes environments, including monitoring, backup procedures, and…
- [Amazon EKS · Bare Metal OS Setup](https://www.atomai.click/kubernetes-docs/llms/en/eks-hybrid-nodes/09-bare-metal-os-setup.md): This guide separates destructive OS installation, image preparation, cluster joining and read-only acceptance checks.
- [Amazon EKS · Hybrid Nodes Gateway](https://www.atomai.click/kubernetes-docs/llms/en/eks-hybrid-nodes/10-hybrid-nodes-gateway.md): EKS Hybrid Nodes Gateway is an open-source networking component that automates connectivity between your Amazon VPC and Kubernetes Pods running on Hybrid Nodes…
- [Amazon EKS · EKS Auto Mode](https://www.atomai.click/kubernetes-docs/llms/en/eks-auto-mode/README.md): Amazon EKS Auto Mode is a feature that fully automates Kubernetes node management, automatically provisioning and optimizing nodes based on workload…
- [Amazon EKS · Getting Started](https://www.atomai.click/kubernetes-docs/llms/en/eks-auto-mode/01-getting-started.md): This chapter covers new-cluster creation and enabling Auto Mode on an existing cluster.
- [Amazon EKS · NodePool Configuration](https://www.atomai.click/kubernetes-docs/llms/en/eks-auto-mode/02-nodepool-configuration.md): This chapter distinguishes AWS-managed defaults, custom NodePool constraints and the AWS-specific NodeClass API.
- [Amazon EKS · Scaling Behavior](https://www.atomai.click/kubernetes-docs/llms/en/eks-auto-mode/03-scaling-behavior.md): This chapter separates provisioning, consolidation, drift and expiration. Use the reviewed account/context from Getting Started.
- [Amazon EKS · Spot Instance Strategies](https://www.atomai.click/kubernetes-docs/llms/en/eks-auto-mode/04-spot-strategies.md): Spot trades interruption and capacity uncertainty for potentially lower EC2 prices.
- [Amazon EKS · Operations and Management](https://www.atomai.click/kubernetes-docs/llms/en/eks-auto-mode/05-operations.md): Day-2 operations must distinguish desired capacity, node lifecycle, application availability and the signals actually collected.
- [Amazon EKS · Cost Management](https://www.atomai.click/kubernetes-docs/llms/en/eks-auto-mode/06-cost-management.md): Cost optimization needs billing evidence for comparable useful work.
- [Amazon EKS · Node Lifecycle](https://www.atomai.click/kubernetes-docs/llms/en/eks-auto-mode/07-node-lifecycle.md): Expiration, managed image updates and application recovery are different parts of a node lifecycle.
- [Amazon EKS · Workload Optimization](https://www.atomai.click/kubernetes-docs/llms/en/eks-auto-mode/08-workload-optimization.md): Match placement and recovery policy to the workload, then validate actual capacity, performance and cost.
- [Amazon EKS · Migration Guide](https://www.atomai.click/kubernetes-docs/llms/en/eks-auto-mode/09-migration-guide.md): Migration requires application, storage and controller-ownership checks before old capacity is removed.
- [Networking · Networking Overview](https://www.atomai.click/kubernetes-docs/llms/en/networking/README.md): Kubernetes networking is the core infrastructure layer that enables communication between containerized applications.
- [Networking · Network Fundamentals — 25 Protocols](https://www.atomai.click/kubernetes-docs/llms/en/basics/06-network-fundamentals-part1.md): A browser request relies on several cooperating protocols.
- [Networking · Part 2: The Transport Layer and TLS](https://www.atomai.click/kubernetes-docs/llms/en/basics/06-network-fundamentals-part2.md): Part 1 delivered packets to the destination host.
- [Networking · Part 3: Application Protocols](https://www.atomai.click/kubernetes-docs/llms/en/basics/06-network-fundamentals-part3.md): Transport protocols provide streams or datagrams; application protocols turn them into services.
- [Networking · Part 4: A Request's Journey and the Cloud](https://www.atomai.click/kubernetes-docs/llms/en/basics/06-network-fundamentals-part4.md): This part connects the series’ 25 protocols and mechanisms through an illustrative request, then maps related responsibilities in AWS and Kubernetes.
- [Networking · VPC CNI](https://www.atomai.click/kubernetes-docs/llms/en/networking/01-vpc-cni.md): Amazon VPC CNI supplies VPC-native Pod networking on standard EKS EC2 nodes. This guide's aws-node DaemonSet commands target that installation.
- [Networking · Cilium Deep Dive](https://www.atomai.click/kubernetes-docs/llms/en/networking/cilium/README.md): This section covers Cilium networking, policy and observability.
- [Networking · Part 1: Introduction](https://www.atomai.click/kubernetes-docs/llms/en/networking/cilium/01-introduction.md): Use an isolated, prepared Kubernetes environment. Cilium 1.20 lists Kubernetes 1.33–1.36 as tested.
- [Networking · Part 2: eBPF](https://www.atomai.click/kubernetes-docs/llms/en/networking/cilium/02-ebpf.md): Use a disposable Linux development VM with a maintained distribution, the tracepoints used below, and permission to load tracing programs.
- [Networking · Part 3: Networking](https://www.atomai.click/kubernetes-docs/llms/en/networking/cilium/03-networking.md): Use the installation guide to prepare a disposable cluster and architecture-appropriate Cilium CLI.
- [Networking · Part 4: IPAM and Policies](https://www.atomai.click/kubernetes-docs/llms/en/networking/cilium/04-ipam-policy.md): Use the installation profiles and networking prerequisites to prepare a disposable Linux cluster. Keep kubectl within the supported API-server version skew.
- [Networking · Part 5: L2-L7 Networking](https://www.atomai.click/kubernetes-docs/llms/en/networking/cilium/05-l2-l7-networking.md): Use a disposable cluster prepared through the installation and networking guides. Check platform/kernel support and kubectl version skew.
- [Networking · Part 6: Security and Visibility](https://www.atomai.click/kubernetes-docs/llms/en/networking/cilium/06-security-visibility.md): Use an existing Cilium 1.20.1 test cluster with at least two schedulable Linux nodes, working DNS, and policy enforcement enabled.
- [Networking · Part 7: Advanced Topics](https://www.atomai.click/kubernetes-docs/llms/en/networking/cilium/07-advanced-topics.md): Use the installation prerequisites and a disposable test cluster with at least two schedulable Linux nodes.
- [Networking · Networking Concepts](https://www.atomai.click/kubernetes-docs/llms/en/networking/cilium/networking-concepts.md): This document provides in-depth explanations of core networking concepts needed to understand Cilium.
- [Networking · Glossary](https://www.atomai.click/kubernetes-docs/llms/en/networking/cilium/glossary.md): An alphabetical reference for Cilium, eBPF, Kubernetes and networking. Repeated entries are consolidated.
- [Networking · Calico Deep Dive](https://www.atomai.click/kubernetes-docs/llms/en/networking/calico/README.md): Calico provides networking and network policy for Kubernetes, with additional host and VM capabilities that depend on the deployment and product edition.
- [Networking · Part 1: Introduction](https://www.atomai.click/kubernetes-docs/llms/en/networking/calico/01-introduction.md): This disposable local lab selects iptables, VXLAN and Calico IPAM explicitly. It does not replace an existing CNI or configure EKS.
- [Networking · Part 2: Architecture](https://www.atomai.click/kubernetes-docs/llms/en/networking/calico/02-architecture.md): This section provides an in-depth exploration of Calico's architecture.
- [Networking · Part 3: Networking Modes](https://www.atomai.click/kubernetes-docs/llms/en/networking/calico/03-networking-modes.md): This chapter concerns Calico-owned Linux Pod networking and IPAM.
- [Networking · Part 4: BGP Deep Dive](https://www.atomai.click/kubernetes-docs/llms/en/networking/calico/04-bgp-deep-dive.md): Border Gateway Protocol (BGP) exchanges reachability information. Calico can use it to distribute workload routes and integrate with an existing routed fabric.
- [Networking · Part 5: Network Policy](https://www.atomai.click/kubernetes-docs/llms/en/networking/calico/05-network-policy.md): Network policies control permitted connections between workloads and other endpoints.
- [Networking · Part 6: eBPF Dataplane](https://www.atomai.click/kubernetes-docs/llms/en/networking/calico/06-ebpf-dataplane.md): Calico's eBPF dataplane uses BPF programs and maps for workload networking, policy and Kubernetes Service handling.
- [Networking · Part 7: Advanced Topics](https://www.atomai.click/kubernetes-docs/llms/en/networking/calico/07-advanced-topics.md): This chapter covers advanced Calico topics for production environments, including IPAM deep dive, WireGuard encryption, Egress Gateway, multi-cluster…
- [Networking · Part 8: EKS Integration](https://www.atomai.click/kubernetes-docs/llms/en/networking/calico/08-eks-integration.md): This guide uses Calico to enforce policy on ordinary Linux EC2 worker nodes with Amazon VPC CNI.
- [Networking · Part 9: Operations](https://www.atomai.click/kubernetes-docs/llms/en/networking/calico/09-operations.md): This chapter provides comprehensive operational guidance for Calico deployments, covering installation, monitoring, troubleshooting, upgrades, and best…
- [Networking · Glossary](https://www.atomai.click/kubernetes-docs/llms/en/networking/calico/glossary.md): This document provides definitions of key terms and concepts related to Calico networking and security.
- [Networking · VPC Lattice](https://www.atomai.click/kubernetes-docs/llms/en/networking/02-vpc-lattice.md): Amazon VPC Lattice connects applications across VPCs and AWS accounts.
- [Networking · AWS Load Balancer Controller](https://www.atomai.click/kubernetes-docs/llms/en/networking/03-aws-lb-controller.md): AWS Load Balancer Controller is a controller that manages AWS Elastic Load Balancers (ELB) for Kubernetes clusters.
- [Networking · Gateway API](https://www.atomai.click/kubernetes-docs/llms/en/networking/04-gateway-api.md): Gateway API is the next-generation ingress API for Kubernetes, designed to overcome the limitations of the existing Ingress API and provide more expressive and…
- [Networking · Cross-Org VPC Connectivity](https://www.atomai.click/kubernetes-docs/llms/en/networking/05-cross-org-vpc-connectivity.md): This chapter compares five patterns for connecting accounts in different AWS Organizations, such as an existing environment and a separately governed GPU…
- [Networking · Pod Network Benchmark](https://www.atomai.click/kubernetes-docs/llms/en/networking/06-pod-network-benchmark.md): This page preserves the September 2, 2026 benchmark report from fsi-demo-cluster (Seoul): Pod-to-Pod RTT, HTTP/gRPC latency, iperf3 throughput and DNS query…
- [Service Mesh · Istio](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/istio/README.md): A practical guide for utilizing Istio Service Mesh on Amazon EKS.
- [Service Mesh · Installation and Initial Setup](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/istio/01-installation.md): This document covers how to install and initially configure Istio on an Amazon EKS cluster.
- [Service Mesh · Basic Concepts](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/istio/02-basic-concepts.md): This document explains Istio's core concepts and architecture. Understanding these basic concepts is important for effectively using Istio.
- [Service Mesh · Architecture](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/istio/03-architecture.md): This document provides an in-depth look at Istio's internal architecture and networking mechanisms.
- [Service Mesh · AWS Integration](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/istio/04-aws-integration.md): This document covers how to integrate Istio with AWS services in an Amazon EKS environment.
- [Service Mesh · Glossary](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/istio/glossary.md): This glossary organizes key terms related to Istio and Service Mesh in grouped reference sections.
- [Service Mesh · Traffic Management](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/istio/traffic-management/README.md): Istio's traffic management capabilities allow fine-grained control over traffic flow within the service mesh.
- [Service Mesh · Gateway and VirtualService](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/istio/traffic-management/01-gateway-virtualservice.md): Gateway and VirtualService are core resources for managing traffic in Istio.
- [Service Mesh · Routing](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/istio/traffic-management/02-routing.md): Istio's advanced routing features allow fine-grained control over traffic based on various request attributes.
- [Service Mesh · DestinationRule](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/istio/traffic-management/03-destination-rule.md): DestinationRule is a core Istio resource that defines how to handle traffic after VirtualService routes it to the destination.
- [Service Mesh · Traffic Splitting](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/istio/traffic-management/04-traffic-splitting.md): Traffic Splitting is one of Istio's most powerful features, enabling Canary deployments, A/B testing, and Blue/Green deployments without code changes.
- [Service Mesh · Retry and Timeout](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/istio/traffic-management/05-retry-timeout.md): Retry and Timeout are core mechanisms for improving microservice resilience. With Istio, you can configure these policies without changing application code.
- [Service Mesh · Load Balancing](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/istio/traffic-management/06-load-balancing.md): Istio provides various load balancing algorithms through Envoy to efficiently distribute traffic.
- [Service Mesh · Circuit Breaker](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/istio/traffic-management/07-circuit-breaker.md): Circuit Breaker automatically isolates failing services to prevent cascading failures.
- [Service Mesh · Fault Injection](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/istio/traffic-management/08-fault-injection.md): Fault Injection is a technique that intentionally injects failures to test system resilience.
- [Service Mesh · Traffic Mirroring](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/istio/traffic-management/09-traffic-mirror.md): Traffic Mirroring (or Shadow Traffic) is a technique that replicates production traffic in real-time to test new versions.
- [Service Mesh · Session Affinity](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/istio/traffic-management/10-session-affinity.md): Session Affinity (or Sticky Session) is a technique that provides soft affinity for requests sharing the same hash key; it does not guarantee a permanent pod…
- [Service Mesh · Egress Control](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/istio/traffic-management/11-egress-control.md): Egress control is a feature that manages outbound traffic from the mesh and enhances security.
- [Service Mesh · ServiceEntry](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/istio/traffic-management/12-service-entry.md): ServiceEntry registers external services in the Istio service mesh, allowing them to be managed like internal services.
- [Service Mesh · WorkloadEntry](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/istio/traffic-management/13-workload-entry.md): WorkloadEntry is a resource for registering Virtual Machines (VMs) or bare-metal servers into the Istio service mesh.
- [Service Mesh · Security](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/istio/security/README.md): Istio provides robust security features within the service mesh.
- [Service Mesh · mTLS](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/istio/security/01-mtls.md): Mutual TLS (mTLS) is a core security feature of Istio that automatically encrypts and authenticates service-to-service communication.
- [Service Mesh · Authentication](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/istio/security/02-authentication.md): Istio supports service-to-service authentication (Peer Authentication) and end-user authentication (Request Authentication).
- [Service Mesh · Authorization](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/istio/security/03-authorization.md): AuthorizationPolicy allows you to finely control service access permissions.
- [Service Mesh · Observability](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/istio/observability/README.md): Istio proxies generate telemetry for traffic they observe. Metrics scraping, access logging, trace providers and storage must be configured.
- [Service Mesh · Metrics](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/istio/observability/01-metrics.md): Istio proxies generate metrics for observed traffic.
- [Service Mesh · Distributed Tracing](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/istio/observability/02-tracing.md): Distributed tracing tracks and visualizes request flows between microservices, enabling latency bottleneck identification, error root cause analysis, and…
- [Service Mesh · Logging](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/istio/observability/03-logging.md): Configured access logs record metadata for observed requests/connections.
- [Service Mesh · Dashboards](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/istio/observability/04-dashboards.md): Use Grafana, Kiali and Prometheus to inspect configured telemetry.
- [Service Mesh · Resilience](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/istio/resilience/README.md): Istio's resilience features help contain failures when configured for the application's semantics and capacity.
- [Service Mesh · Outlier Detection](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/istio/resilience/01-outlier-detection.md): Outlier Detection is a form of the Circuit Breaker pattern that automatically detects abnormally behaving service instances and removes them from the traffic…
- [Service Mesh · Rate Limiting](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/istio/resilience/02-rate-limiting.md): Rate Limiting is a feature that limits request rates to protect services from overload, ensure fair resource usage, and control costs.
- [Service Mesh · Zone Aware Routing](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/istio/resilience/03-zone-aware-routing.md): Zone Aware Routing is a feature that optimizes traffic by recognizing Kubernetes Availability Zones.
- [Service Mesh · Advanced](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/istio/advanced/README.md): This section covers advanced Istio features including Ambient Mode, Multi-cluster, EnvoyFilter, gRPC/WebSocket support, and more.
- [Service Mesh · Ambient Mode](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/istio/advanced/01-ambient-mode.md): Ambient was introduced as a 2022 experimental preview, first shipped in Istio 1.18 as Alpha, reached Beta in 1.22 and core GA in 1.24.
- [Service Mesh · Multi-cluster](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/istio/advanced/02-multi-cluster.md): Multi-cluster Service Mesh connects multiple Kubernetes clusters into a unified service mesh.
- [Service Mesh · EnvoyFilter](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/istio/advanced/03-envoy-filter.md): EnvoyFilter is an advanced feature that allows you to directly customize Envoy proxy configurations.
- [Service Mesh · DNS Caching](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/istio/advanced/04-dns-cache.md): Optimize external service access performance and control DNS lookups through Istio's DNS management features.
- [Service Mesh · gRPC](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/istio/advanced/05-grpc.md): Istio can route plaintext gRPC HTTP/2 requests by RPC path and metadata, and load-balance new RPCs across eligible endpoints.
- [Service Mesh · WebSocket](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/istio/advanced/06-websocket.md): Istio enables WebSocket upgrades in its generated HTTP connection manager. This example covers HTTP/1.1 Upgrade with TLS terminated at the ingress gateway.
- [Service Mesh · Sidecar Injection](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/istio/advanced/07-sidecar-injection.md): Automatic injection is an admission webhook that modifies newly created Pods.
- [Service Mesh · Argo Rollouts Integration](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/istio/advanced/08-argo-rollouts.md): Argo Rollouts reconciles replica selection and Istio traffic weights during progressive delivery.
- [Service Mesh · Zone-Aware Argo Rollouts](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/istio/advanced/09-zone-aware-argo-rollouts.md): This guide separates independent zonal canaries from cross-AZ failover.
- [Service Mesh · AutoScaling using istio metrics](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/istio/advanced/10-keda-autoscaling.md): This guide explains scaling signals and their limits. It assumes existing workloads, verified metrics and sufficient cluster capacity.
- [Service Mesh · Comparison Guide](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/istio/comparison/README.md): Compare the required traffic, identity, platform and operating contracts before selecting a mesh.
- [Service Mesh · Service Mesh Solution Comparison](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/istio/comparison/01-service-mesh-comparison.md): The artifact versions identify the sources used to check examples.
- [Service Mesh · Istio vs VPC Lattice](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/istio/comparison/02-istio-vs-lattice.md): Compare the communication, identity, protocol and operating requirements of the application.
- [Service Mesh · Sidecar vs Ambient Mode Selection Guide](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/istio/comparison/03-sidecar-vs-ambient.md): This document preserves the reported mTLS, NetworkPolicy, latency and rollout measurements.
- [Service Mesh · Troubleshooting](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/istio/troubleshooting/common-errors.md): Start with the observed failure, effective configuration and workload mode. The commands below are diagnostic examples, not instructions to reset the mesh.
- [Service Mesh · Best Practices](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/istio/best-practices.md): This document covers best practices and recommendations for successfully operating Istio in production environments.
- [Service Mesh · Linkerd](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/linkerd/README.md): The upstream project publishes edge artifacts; stable distributions and their support lifecycle come from vendors.
- [Service Mesh · Installation](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/linkerd/01-installation.md): This guide covers a controlled Kubernetes installation, Helm/CLI ownership, HA, optional extensions, EKS considerations, upgrades and removal.
- [Service Mesh · Architecture](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/linkerd/02-architecture.md): This chapter explains the current component roles, identity hierarchy, traffic capture and injection lifecycle.
- [Service Mesh · Traffic Management](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/linkerd/03-traffic-management.md): Current Linkerd routing uses Gateway API resources and supported annotations.
- [Service Mesh · Security](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/linkerd/04-security.md): Linkerd provides workload authentication, transport encryption and inbound authorization for traffic handled by its proxies.
- [Service Mesh · Observability](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/linkerd/05-observability.md): Linkerd exposes proxy and protocol metrics; Viz adds Prometheus, metrics-api, tap, tap-injector and the web dashboard.
- [Service Mesh · Multi-cluster](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/linkerd/06-multi-cluster.md): Linkerd mirrors selected service information across cluster boundaries.
- [Service Mesh · Best Practices](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/linkerd/07-best-practices.md): Use the installation, security, observability and multicluster guides for the selected versions and prerequisites.
- [Service Mesh · Cilium Service Mesh](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/cilium-service-mesh/README.md): Cilium combines Kubernetes networking, eBPF policy/load balancing and optional application-layer proxy features.
- [Service Mesh · Architecture](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/cilium-service-mesh/01-architecture.md): Cilium combines an eBPF L3/L4 datapath with Envoy for HTTP and other supported L7 processing.
- [Service Mesh · Traffic Management](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/cilium-service-mesh/02-traffic-management.md): Traffic management in Cilium Service Mesh combines eBPF-based L4 load balancing with Envoy-based L7 routing.
- [Service Mesh · Security](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/cilium-service-mesh/03-security.md): Evaluate three separate controls: workload authorization, peer authentication and application-data encryption.
- [Service Mesh · Observability](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/cilium-service-mesh/04-observability.md): Hubble exposes observations of traffic handled by Cilium.
- [Service Mesh · Ingress & Gateway](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/cilium-service-mesh/05-ingress-gateway.md): Cilium uses Kubernetes Ingress and Gateway API resources to configure its data plane.
- [Service Mesh · Best Practices](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/cilium-service-mesh/06-best-practices.md): An operating plan must connect CNI ownership, proxy features, policy enforcement, capacity and recovery.
- [Service Mesh · VPC Lattice Deep Dive](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/vpc-lattice/README.md): This section is about understanding concepts.
- [Service Mesh · App Mesh vs VPC Lattice Architecture](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/vpc-lattice/01-appmesh-vs-lattice.md): App Mesh and Istio put an Envoy inside the Pod because some decisions require the application's context.
- [Service Mesh · Latency Impact Analysis](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/vpc-lattice/02-latency.md): The latency impact can differ by workload. Proxy processing, network paths, connection reuse, signing, credential refresh and policy evaluation can all change.
- [Service Mesh · IAM Authentication Flow](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/vpc-lattice/03-auth-flow.md): App Mesh's mTLS checks each side's certificate once, when the connection is established, and trusts that connection from then on.
- [Service Mesh · Foundations — Link-Local and SNI](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/vpc-lattice/04-networking-basics.md): A link-local address is one from a range that is valid only within a single link (the same broadcast domain). Not crossing a router is the definition.
- [Service Mesh · Workload Identity Migration](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/vpc-lattice/05-spiffe-to-iam.md): When service A calls service B, B needs to know "did this request really come from A?" The problem is hard because of how you deliver the secret needed for the…
- [Service Mesh · Constraints and Decision Points](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/vpc-lattice/06-constraints.md): Constraints 1 and 2 are current capability and trust-boundary choices, not predictions that AWS can never add features.
- [Service Mesh · Kernel Datapath](https://www.atomai.click/kubernetes-docs/llms/en/service-mesh/vpc-lattice/07-kernel-datapath.md): Document 04 explained that a link-local address is a marker meaning "the infrastructure handles this packet." That is enough conceptually, but the problems…
- [Storage · Storage Overview](https://www.atomai.click/kubernetes-docs/llms/en/storage/README.md): The moment you run stateful workloads on Kubernetes, storage stops being "something you attach" and becomes a domain that dictates performance, cost, and…
- [Storage · EBS gp2 vs gp3 Measured Benchmark](https://www.atomai.click/kubernetes-docs/llms/en/storage/01-ebs-gp2-gp3-benchmark.md): The AWS one-liner — "move gp2 to gp3, save 20%, get equal or better performance" — is famous, but a graph showing when and in what shape that difference…
- [Database · Databases on Kubernetes Overview](https://www.atomai.click/kubernetes-docs/llms/en/database/README.md): "Should you run databases on Kubernetes?" is no longer a yes/no question.
- [Database · ClickHouse on EKS Measured Benchmark](https://www.atomai.click/kubernetes-docs/llms/en/database/01-clickhouse-on-eks.md): Every benchmark report says "ClickHouse is fast" — but it's surprisingly hard to find numbers measured on an ordinary EKS node with a default gp3 volume.
- [Blockchain · Blockchain Overview](https://www.atomai.click/kubernetes-docs/llms/en/blockchain/README.md): This repository is Kubernetes and EKS training material. Blockchain is here because a blockchain node is an unusual workload for a Kubernetes operator.
- [Blockchain · Blockchain Fundamentals](https://www.atomai.click/kubernetes-docs/llms/en/blockchain/01-fundamentals.md): The starting point for understanding blockchain is not the technology but the constraints.
- [Blockchain · Running Blockchain Nodes on EKS](https://www.atomai.click/kubernetes-docs/llms/en/blockchain/02-nodes-on-eks.md): Before discussing configuration, this question comes first. Blockchain nodes fit poorly with some of Kubernetes' strengths.
- [Blockchain · Amazon Managed Blockchain](https://www.atomai.click/kubernetes-docs/llms/en/blockchain/03-managed-blockchain.md): AMB is not one service but a bundle of components with different characters.
- [Blockchain · Financial Services Perspective](https://www.atomai.click/kubernetes-docs/llms/en/blockchain/04-financial-services.md): The most frequent problem in financial-services blockchain evaluations is proceeding when the technology does not fit the problem.
- [Data Pipeline · Data on EKS Overview](https://www.atomai.click/kubernetes-docs/llms/en/data-on-eks/README.md): This section covers operating Kafka, Spark, Airflow and Flink on Amazon EKS and connecting them with AWS managed services.
- [Data Pipeline · Anatomy of a Modern Data Pipeline](https://www.atomai.click/kubernetes-docs/llms/en/data-on-eks/01-data-pipeline-anatomy.md): Sources, ingestion, storage, processing and consumption are conceptual roles.
- [Data Pipeline · SageMaker Unified Studio Governance](https://www.atomai.click/kubernetes-docs/llms/en/data-on-eks/sagemaker-unified-studio/README.md): Amazon SageMaker Unified Studio manages collaboration, tools and catalog assets for data/AI teams.
- [Data Pipeline · Part 4: Domain, Project, and Membership Governance](https://www.atomai.click/kubernetes-docs/llms/en/data-on-eks/sagemaker-unified-studio/01-domains-projects-governance.md): The third recorded Qwen provisioning attempt reports a created project followed by read/delete denial because of caller membership. Training did not start.
- [Data Pipeline · Kafka on EKS Deep Dive](https://www.atomai.click/kubernetes-docs/llms/en/data-on-eks/kafka/README.md): This guide uses Strimzi Operator as a self-managed Kafka option on EKS.
- [Data Pipeline · Part 1: Kafka Fundamentals](https://www.atomai.click/kubernetes-docs/llms/en/data-on-eks/kafka/01-kafka-fundamentals.md): Kafka stores events in partition logs, allowing producers and consumers to progress independently.
- [Data Pipeline · Part 2: Strimzi Operator](https://www.atomai.click/kubernetes-docs/llms/en/data-on-eks/kafka/02-strimzi-operator.md): This is a new-installation example with three dedicated controllers and three brokers.
- [Data Pipeline · Part 3: Kafka Operations](https://www.atomai.click/kubernetes-docs/llms/en/data-on-eks/kafka/03-kafka-operations.md): This chapter assumes the authenticated Kafka deployment and broker-only pool from Part 2.
- [Data Pipeline · Part 4: Schema Registry](https://www.atomai.click/kubernetes-docs/llms/en/data-on-eks/kafka/04-schema-registry.md): Kafka stores record keys and values as bytes. A producer and consumer can therefore disagree about the structure or meaning of a value.
- [Data Pipeline · Part 5: Kafka Connect and MirrorMaker](https://www.atomai.click/kubernetes-docs/llms/en/data-on-eks/kafka/05-kafka-connect-mirrormaker.md): Kafka Connect runs plugins that move data between Kafka and external systems.
- [Data Pipeline · Part 6: MSK Integration](https://www.atomai.click/kubernetes-docs/llms/en/data-on-eks/kafka/06-msk-integration.md): Amazon MSK runs Kafka brokers outside your EKS cluster on AWS-managed infrastructure. Strimzi runs them as Kubernetes workloads that your team operates.
- [Data Pipeline · Part 7: Monitoring](https://www.atomai.click/kubernetes-docs/llms/en/data-on-eks/kafka/07-monitoring.md): This chapter chooses jmxPrometheusExporter. Its mapping rules are not the same thing as Prometheus target relabeling.
- [Data Pipeline · Part 8: Best Practices](https://www.atomai.click/kubernetes-docs/llms/en/data-on-eks/kafka/08-best-practices.md): This chapter turns the preceding examples into operational decisions to validate.
- [Data Pipeline · Part 9: Kafka Measured Benchmark](https://www.atomai.click/kubernetes-docs/llms/en/data-on-eks/kafka/09-kafka-benchmark.md): This page preserves the single-run tables reported in PR #166 and reviews their units, comparisons and reproduction procedure.
- [Data Pipeline · Spark on EKS Deep Dive](https://www.atomai.click/kubernetes-docs/llms/en/data-on-eks/spark/README.md): Apache Spark runs batch, SQL, streaming and other distributed data workloads.
- [Data Pipeline · Part 1: Spark on Kubernetes Fundamentals](https://www.atomai.click/kubernetes-docs/llms/en/data-on-eks/spark/01-spark-fundamentals.md): Kubernetes supports both Spark deployment modes. Client mode has been supported since Spark 2.4 and is not restricted to notebooks.
- [Data Pipeline · Part 2: Spark Operator](https://www.atomai.click/kubernetes-docs/llms/en/data-on-eks/spark/02-spark-operator.md): These are separately maintained projects, not interchangeable implementations of one manifest.
- [Data Pipeline · Part 3: Amazon EMR on EKS](https://www.atomai.click/kubernetes-docs/llms/en/data-on-eks/spark/03-emr-on-eks.md): Spark Operator support since EMR 6.10.0 does not mean StartJobRun has an option to delegate internally to that operator.
- [Data Pipeline · Part 4: Performance and Cost Tuning](https://www.atomai.click/kubernetes-docs/llms/en/data-on-eks/spark/04-performance-tuning.md): This chapter uses Part 1's direct spark-submit path. Spark 4.2 requires Kubernetes 1.34+; also check EKS, kubectl and Karpenter compatibility.
- [Data Pipeline · Part 5: Best Practices and Security](https://www.atomai.click/kubernetes-docs/llms/en/data-on-eks/spark/05-best-practices.md): This chapter builds on Part 1's direct Kubernetes submission, covering temporary S3 credentials, metrics/event logs, History Server, networking and RBAC.
- [Data Pipeline · Airflow on EKS Deep Dive](https://www.atomai.click/kubernetes-docs/llms/en/data-on-eks/airflow/README.md): Apache Airflow defines workflow dependencies as DAGs and schedules, runs and observes their tasks.
- [Data Pipeline · Part 1: Airflow Architecture on Kubernetes](https://www.atomai.click/kubernetes-docs/llms/en/data-on-eks/airflow/01-architecture.md): Airflow schedules and observes task instances according to DAG dependencies.
- [Data Pipeline · Part 2: Helm Deployment and Executor Choice](https://www.atomai.click/kubernetes-docs/llms/en/data-on-eks/airflow/02-helm-deployment.md): This guide uses the official chart in the Apache Airflow repository.
- [Data Pipeline · Part 3: DAG Patterns and KubernetesPodOperator](https://www.atomai.click/kubernetes-docs/llms/en/data-on-eks/airflow/03-dag-patterns.md): KubernetesPodOperator (KPO) lets an Airflow task create and observe a separate workload pod.
- [Data Pipeline · Part 4: Amazon MWAA Integration](https://www.atomai.click/kubernetes-docs/llms/en/data-on-eks/airflow/04-mwaa-integration.md): This chapter targets provisioned Amazon MWAA environments submitting work to customer EKS clusters.
- [Data Pipeline · Part 5: Operations and Security](https://www.atomai.click/kubernetes-docs/llms/en/data-on-eks/airflow/05-operations.md): This chapter covers HA, upgrades, secrets, logs, observability and recovery for the self-managed EKS deployment in Part 2.
- [Data Pipeline · Flink on EKS Deep Dive](https://www.atomai.click/kubernetes-docs/llms/en/data-on-eks/flink/README.md): Apache Flink is a distributed stateful engine for bounded and unbounded streams.
- [Data Pipeline · Part 1: Flink Architecture on Kubernetes](https://www.atomai.click/kubernetes-docs/llms/en/data-on-eks/flink/01-architecture.md): This chapter explains cluster roles and resource sizing.
- [Data Pipeline · Part 2: Flink Kubernetes Operator](https://www.atomai.click/kubernetes-docs/llms/en/data-on-eks/flink/02-flink-kubernetes-operator.md): The Operator reconciles desired cluster/job state and manages upgrades, snapshots, recovery and autoscaling.
- [Data Pipeline · Part 3: State, Checkpointing, and Streaming Patterns](https://www.atomai.click/kubernetes-docs/llms/en/data-on-eks/flink/03-state-checkpointing-streaming.md): State is the data remembered by aggregation, joins and deduplication.
- [Data Pipeline · Part 4: Operations, High Availability, and Managed Flink](https://www.atomai.click/kubernetes-docs/llms/en/data-on-eks/flink/04-operations-ha.md): Connect observability and HA to Part 3's stateful deployment, then validate failures, recovery and capacity.
- [AI/ML · AI/ML Workloads](https://www.atomai.click/kubernetes-docs/llms/en/ai-ml/01-ai-ml-workloads.md): Kubernetes is a powerful platform for running AI/ML workloads. In this chapter, we will learn how to run AI/ML workloads on EKS and explore best practices.
- [AI/ML · AI Infrastructure](https://www.atomai.click/kubernetes-docs/llms/en/ai-ml/06-ai-infrastructure.md): AI infrastructure combines notebooks, pipelines, distributed runtimes, devices/nodes, storage/networking and authorization.
- [AI/ML · Model Training on EKS](https://www.atomai.click/kubernetes-docs/llms/en/ai-ml/05-model-training.md): Distributed training requires compatible model code, data sharding, launchers, device allocation, communication and checkpoints.
- [AI/ML · Inference Frameworks](https://www.atomai.click/kubernetes-docs/llms/en/ai-ml/04-inference-frameworks.md): Select inference engines, distributed execution layers, Kubernetes controllers and provider gateways separately.
- [AI/ML · vLLM Deployment & Optimization](https://www.atomai.click/kubernetes-docs/llms/en/ai-ml/02-vllm-deployment.md): vLLM is an open-source inference engine for generative models and supported multimodal/pooling workloads.
- [AI/ML · Agentic AI Platform on EKS](https://www.atomai.click/kubernetes-docs/llms/en/ai-ml/03-agentic-ai-platform.md): Agentic AI goes beyond simple question-answering to autonomously create plans, use tools, and iteratively achieve goals.
- [AI/ML · AI/ML Best Practices](https://www.atomai.click/kubernetes-docs/llms/en/ai-ml/07-ai-ml-best-practices.md): Evaluate improvements using latency, success rate, throughput, cost and recovery for the same workload.
- [AI/ML · LLM Gateway (Inference Gateway) Deep Dive](https://www.atomai.click/kubernetes-docs/llms/en/ai-ml/08-llm-gateway.md): Once coding agents (Claude Code, OpenCode, Codex), RAG applications, and autonomous agents in one organization start calling several model providers at once…
- [AI/ML · Ray on EKS Deep Dive](https://www.atomai.click/kubernetes-docs/llms/en/ai-ml/ray/README.md): Ray distributes Python work using tasks, actors, ObjectRefs, and per-node object stores.
- [AI/ML · Part 1: Ray Architecture](https://www.atomai.click/kubernetes-docs/llms/en/ai-ml/ray/01-architecture.md): The local example was checked with Python 3.12, ray==2.58.0, and numpy==2.2.6.
- [AI/ML · Part 2: The KubeRay Operator](https://www.atomai.click/kubernetes-docs/llms/en/ai-ml/ray/02-kuberay-operator.md): Prepare supported Kubernetes, compatible kubectl, and Helm 3. GPU hardware and Karpenter are not prerequisites for reviewing a CPU configuration.
- [AI/ML · Part 3: Ray Train and Ray Tune](https://www.atomai.click/kubernetes-docs/llms/en/ai-ml/ray/03-ray-train-tune.md): Validation used Python 3.12 and ray[train,tune]==2.58.0. These extras install Ray's Train/Tune dependencies; frameworks such as PyTorch are separate.
- [AI/ML · Part 4: Ray Serve](https://www.atomai.click/kubernetes-docs/llms/en/ai-ml/ray/04-ray-serve.md): A small CPU response example was checked with Python 3.12 and ray[serve]==2.58.0.
- [AI/ML · Kubeflow on EKS Deep Dive](https://www.atomai.click/kubernetes-docs/llms/en/ai-ml/kubeflow/README.md): Kubeflow provides Kubernetes-based tools for ML pipelines, notebooks, tuning, training, and serving.
- [AI/ML · Part 1: Kubeflow Architecture and Installation on EKS](https://www.atomai.click/kubernetes-docs/llms/en/ai-ml/kubeflow/01-architecture-installation.md): Select a distribution release before selecting commands.
- [AI/ML · Part 2: Kubeflow Pipelines](https://www.atomai.click/kubernetes-docs/llms/en/ai-ml/kubeflow/02-pipelines.md): Local compilation requires Python and kfp==2.16.1; this chapter was checked with Python 3.12. Compilation does not contact a cluster.
- [AI/ML · Part 3: Kubeflow Notebooks](https://www.atomai.click/kubernetes-docs/llms/en/ai-ml/kubeflow/03-notebooks.md): Use a compatible Kubernetes cluster, Notebooks 1.11.0 controller/web app, namespace permissions, storage and an authenticated access path.
- [AI/ML · Part 4: Katib — Hyperparameter Tuning and AutoML](https://www.atomai.click/kubernetes-docs/llms/en/ai-ml/kubeflow/04-katib.md): Use Katib 0.19.0 controllers, DB manager/storage, required Suggestion images and namespace permissions to create Experiments.
- [AI/ML · Part 5: Kubeflow Trainer and Distributed Training](https://www.atomai.click/kubernetes-docs/llms/en/ai-ml/kubeflow/05-training-operator.md): Use compatible Kubernetes, Trainer controller/CRDs, runtimes and their dependencies such as JobSet. GPUs are workload-dependent; CPU training is possible.
- [AI/ML · Part 6: KServe — Model Serving on Kubernetes](https://www.atomai.click/kubernetes-docs/llms/en/ai-ml/kubeflow/06-kserve.md): Use compatible Kubernetes, KServe controller/CRDs, ServingRuntime, storage access and an authenticated network path.
- [AI/ML · MLflow on EKS Deep Dive](https://www.atomai.click/kubernetes-docs/llms/en/ai-ml/mlflow/README.md): MLflow provides experiment tracking, model logging and registration, version management, GenAI evaluation, and tracing.
- [AI/ML · Part 1: MLflow Tracking](https://www.atomai.click/kubernetes-docs/llms/en/ai-ml/mlflow/01-tracking.md): Install mlflow==3.16.0 with Python 3.10 or later. The example below was checked with Python 3.12, SQLite, and a local artifact store.
- [AI/ML · Part 2: MLflow Model Registry](https://www.atomai.click/kubernetes-docs/llms/en/ai-ml/mlflow/02-model-registry.md): Use Python 3.10 or later and mlflow==3.16.0. Registry APIs also work with local SQLite; a separate HTTP server is not mandatory.
- [AI/ML · Part 3: Deploying MLflow on EKS](https://www.atomai.click/kubernetes-docs/llms/en/ai-ml/mlflow/03-eks-deployment.md): Prepare a supported EKS Kubernetes version, compatible kubectl, Helm 3, metadata database, and artifact storage.
- [AI/ML · SageMaker AI Qwen PII Guidebook](https://www.atomai.click/kubernetes-docs/llms/en/ai-ml/sagemaker-ai/README.md): This guide describes a QLoRA experiment design and component-tested package for Qwen/Qwen3-30B-A3B-Instruct-2507.
- [AI/ML · Part 1: Platform Architecture](https://www.atomai.click/kubernetes-docs/llms/en/ai-ml/sagemaker-ai/01-platform-architecture.md): GPU execution is blocked because the pinned PyTorch 2.8 DLC reached end of patch.
- [AI/ML · Part 2: Synthetic PII Data and Tokenization](https://www.atomai.click/kubernetes-docs/llms/en/ai-ml/sagemaker-ai/02-pii-data-tokenization.md): These are synthetic examples. The model does not edit the source document.
- [AI/ML · Part 3: SageMaker AI and MLflow Execution](https://www.atomai.click/kubernetes-docs/llms/en/ai-ml/sagemaker-ai/03-sagemaker-mlflow-execution.md): The committed GPU execution path is currently blocked because its image reached end of patch.
- [AI/ML · Part 5: Factual Validation Results](https://www.atomai.click/kubernetes-docs/llms/en/ai-ml/sagemaker-ai/04-validation-results.md): This chapter describes the repository's September 1–2, 2026 experiment records.
- [Security & Policy · Policy Management with Kyverno](https://www.atomai.click/kubernetes-docs/llms/en/security/01-kyverno-policy-management.md): Kyverno evaluates Kubernetes policy and performs explicitly configured mutation, generation and deletion.
- [Security & Policy · Kubernetes Authentication and Authorization](https://www.atomai.click/kubernetes-docs/llms/en/security/02-kubernetes-auth-authz.md): Authentication establishes the request identity, authorization decides which API operations that identity may perform, and admission applies additional policy…
- [Security & Policy · Pod Security Standards](https://www.atomai.click/kubernetes-docs/llms/en/security/03-pod-security-standards.md): Pod Security Standards (PSS) is a standardized policy framework for Pod security in Kubernetes.
- [Security & Policy · Network Policies](https://www.atomai.click/kubernetes-docs/llms/en/security/04-network-policies.md): Kubernetes Network Policies are firewall rules that control traffic between Pods. This document covers basic NetworkPolicy and Cilium/Calico extensions.
- [Security & Policy · Secrets Management](https://www.atomai.click/kubernetes-docs/llms/en/security/05-secrets-management.md): This chapter separates the responsibilities and integration requirements of native Secrets, ESO, AWS stores, Sealed Secrets, Vault and SOPS.
- [Security & Policy · EKS Security Best Practices](https://www.atomai.click/kubernetes-docs/llms/en/security/06-eks-security-best-practices.md): This document covers security best practices for Amazon EKS environments.
- [Security & Policy · Image Security](https://www.atomai.click/kubernetes-docs/llms/en/security/07-image-security.md): Image security starts by confirming that the built, scanned, and deployed artifact is the same.
- [Security & Policy · Runtime Security](https://www.atomai.click/kubernetes-docs/llms/en/security/08-runtime-security.md): Runtime security observes process, file, and network activity and restricts selected operations through tested policies.
- [Security & Policy · OPA Gatekeeper](https://www.atomai.click/kubernetes-docs/llms/en/security/09-opa-gatekeeper.md): Gatekeeper evaluates policies during Kubernetes admission and periodic audit.
- [Security & Policy · cert-manager](https://www.atomai.click/kubernetes-docs/llms/en/security/10-cert-manager.md): cert-manager manages certificate issuance and renewal as Kubernetes resources.
- [Security & Policy · Kubescape](https://www.atomai.click/kubernetes-docs/llms/en/security/11-kubescape.md): Kubescape evaluates Kubernetes configuration and selected image/runtime data.
- [Security & Policy · SPIFFE/SPIRE](https://www.atomai.click/kubernetes-docs/llms/en/security/12-spiffe-spire.md): SPIFFE defines workload identity, credential, delivery, and trust formats; SPIRE implements them.
- [GitOps](https://www.atomai.click/kubernetes-docs/llms/en/gitops/README.md): GitOps is an operational framework that applies DevOps best practices for infrastructure automation—such as version control, collaboration, compliance, and…
- [GitOps · ArgoCD](https://www.atomai.click/kubernetes-docs/llms/en/gitops/argocd/README.md): ArgoCD is a declarative, GitOps continuous delivery tool for Kubernetes.
- [GitOps · Installation](https://www.atomai.click/kubernetes-docs/llms/en/gitops/argocd/01-installation.md): This is a self-managed installation guide.
- [GitOps · Applications](https://www.atomai.click/kubernetes-docs/llms/en/gitops/argocd/02-applications.md): Examples are independent configurations. Replace myorg/accounts/clusters/paths with actual authorized sources.
- [GitOps · Sync Strategies](https://www.atomai.click/kubernetes-docs/llms/en/gitops/argocd/03-sync-strategies.md): Examples are independent policy fragments. Keep a real Application's source/destination/project and select only needed options.
- [GitOps · ApplicationSets](https://www.atomai.click/kubernetes-docs/llms/en/gitops/argocd/04-applicationsets.md): ApplicationSet is a Kubernetes controller that adds support for generating ArgoCD Applications from templates.
- [GitOps · Traffic Management](https://www.atomai.click/kubernetes-docs/llms/en/gitops/argocd/05-traffic-management.md): Argo Rollouts is a Kubernetes controller that provides advanced deployment capabilities including blue-green deployments, canary deployments, and progressive…
- [GitOps · Projects & RBAC](https://www.atomai.click/kubernetes-docs/llms/en/gitops/argocd/06-projects-rbac.md): AppProjects provide logical grouping of Applications and define access controls for what resources can be deployed, where they can be deployed, and who can…
- [GitOps · Security](https://www.atomai.click/kubernetes-docs/llms/en/gitops/argocd/07-security.md): SSO examples are alternatives: merge required fields into existing ConfigMaps/Secrets without replacing server signing keys or other credentials in…
- [GitOps · Notifications](https://www.atomai.click/kubernetes-docs/llms/en/gitops/argocd/08-notifications.md): ArgoCD Notifications is a component that monitors ArgoCD applications and sends notifications when certain conditions are met.
- [GitOps · Best Practices](https://www.atomai.click/kubernetes-docs/llms/en/gitops/argocd/09-best-practices.md)
- [GitOps · Rollouts Experiments Deep Dive](https://www.atomai.click/kubernetes-docs/llms/en/gitops/argocd/10-rollouts-experiment.md): An Experiment is an Argo Rollouts CRD that creates ephemeral ReplicaSets and runs analyses.
- [GitOps · FluxCD](https://www.atomai.click/kubernetes-docs/llms/en/gitops/02-fluxcd.md): FluxCD is a set of continuous and progressive delivery solutions for Kubernetes that are open and extensible.
- [GitOps · GitOps Tools Comparison](https://www.atomai.click/kubernetes-docs/llms/en/gitops/03-gitops-comparison.md): This guide provides a comprehensive comparison of GitOps tools, with a focus on ArgoCD and FluxCD, the two most popular choices in the Kubernetes ecosystem.
- [GitOps · Flagger Progressive Delivery](https://www.atomai.click/kubernetes-docs/llms/en/gitops/04-flagger.md): Flagger manages progressive delivery of Kubernetes workloads through the Canary CRD.
- [GitOps · Feature Flags and OpenFeature](https://www.atomai.click/kubernetes-docs/llms/en/gitops/05-feature-flags.md): Feature flags separate code deployment from runtime feature exposure.
- [Enterprise Cloud Governance · Governance Overview](https://www.atomai.click/kubernetes-docs/llms/en/governance/00-governance-overview.md): The EKS, networking, and security documents so far assumed "one cluster, one VPC" and explained individual features on top of that.
- [Enterprise Cloud Governance · Landing Zone, OUs, and Organizational Control](https://www.atomai.click/kubernetes-docs/llms/en/governance/01-landing-zone-and-ou.md): When standardizing a multi-account environment, AWS Control Tower is usually the first tool you reach for.
- [Enterprise Cloud Governance · Account Structure and IAM Boundaries](https://www.atomai.click/kubernetes-docs/llms/en/governance/02-account-and-iam.md): The most common candidates for how to split Accounts are team, brand, domain, and environment (production/non-production).
- [Enterprise Cloud Governance · Multi-Account, Multi-Cluster EKS Architecture](https://www.atomai.click/kubernetes-docs/llms/en/governance/03-eks-multi-account-multi-cluster.md): There are four broad ways to place workloads from multiple teams/domains onto EKS.
- [Enterprise Cloud Governance · Shared VPC and Connectivity](https://www.atomai.click/kubernetes-docs/llms/en/governance/04-shared-vpc-and-connectivity.md): When adopting a Shared VPC (sharing subnets across Accounts via AWS RAM), the most common misconception is that "sharing means both sides see things equally."…
- [Enterprise Cloud Governance · Data and Security Boundaries](https://www.atomai.click/kubernetes-docs/llms/en/governance/05-data-security-boundaries.md): Hybrid is a realistic starting point for most organizations.
- [Enterprise Cloud Governance · Decision Framework and PoC Design](https://www.atomai.click/kubernetes-docs/llms/en/governance/06-decision-framework-and-poc.md): The Landing Zone, Account/IAM, EKS, VPC, and Data/Security boundaries covered so far should each be judged independently — but in practice, they all need to be…
- [Platform Engineering · Platform Engineering Overview](https://www.atomai.click/kubernetes-docs/llms/en/platform-engineering/00-platform-engineering-overview.md): Platform Engineering is the discipline of designing, building, and operating tools, workflows, and infrastructure for developer self-service.
- [Platform Engineering · Helm](https://www.atomai.click/kubernetes-docs/llms/en/platform-engineering/01-helm.md): Helm renders charts and manages Kubernetes resources and release history. Chart version, appVersion, image tag/digest and release revision are different values.
- [Platform Engineering · AWS Controllers for Kubernetes (ACK)](https://www.atomai.click/kubernetes-docs/llms/en/platform-engineering/02-ack.md): ACK connects Kubernetes custom resources to AWS APIs through service-specific controllers.
- [Platform Engineering · S3 and IAM Examples](https://www.atomai.click/kubernetes-docs/llms/en/platform-engineering/ack/01-s3-iam.md): ACK
- [Platform Engineering · SQS and SNS Examples](https://www.atomai.click/kubernetes-docs/llms/en/platform-engineering/ack/02-sqs-sns.md): ACK
- [Platform Engineering · ELBv2, Route 53, RDS Examples](https://www.atomai.click/kubernetes-docs/llms/en/platform-engineering/ack/03-elbv2-route53-rds.md): ACK
- [Platform Engineering · Kube Resource Orchestrator (kro)](https://www.atomai.click/kubernetes-docs/llms/en/platform-engineering/03-kro.md): The official name is Kube Resource Orchestrator, a Kubernetes SIG Cloud Provider subproject.
- [Platform Engineering · Kubernetes Extension Mechanisms](https://www.atomai.click/kubernetes-docs/llms/en/platform-engineering/04-kubernetes-extensions.md): Kubernetes offers several ways to extend APIs and workload behavior. Registering a CRD is different from implementing its behavior.
- [Platform Engineering · ExampleCorp: ACK + KRO Integration Example](https://www.atomai.click/kubernetes-docs/llms/en/platform-engineering/05-example-corp-app.md): ExampleCorp is fictional. This guide defines an integration contract connecting a kro application graph to ACK-managed infrastructure.
- [Platform Engineering · Backstage IDP](https://www.atomai.click/kubernetes-docs/llms/en/platform-engineering/06-backstage-idp.md): Backstage is an open-source developer portal framework originating at Spotify, licensed under Apache 2.0. CNCF lists it as Incubating.
- [Platform Engineering · Crossplane](https://www.atomai.click/kubernetes-docs/llms/en/platform-engineering/07-crossplane.md): Crossplane reconciles infrastructure and application resources through Kubernetes APIs and controllers.
- [Platform Engineering · vCluster](https://www.atomai.click/kubernetes-docs/llms/en/platform-engineering/08-vcluster.md): vCluster can provide separate Kubernetes APIs, controllers and data stores for tenants.
- [Container Registry · Container Registry Overview](https://www.atomai.click/kubernetes-docs/llms/en/container-registry/README.md): Container registries are fundamental infrastructure components in the Kubernetes ecosystem, serving as centralized repositories for storing, managing, and…
- [Container Registry · Docker Hub](https://www.atomai.click/kubernetes-docs/llms/en/container-registry/01-docker-hub.md): Docker Hub is the default registry for the Docker CLI when no registry is specified.
- [Container Registry · Amazon ECR](https://www.atomai.click/kubernetes-docs/llms/en/container-registry/02-amazon-ecr.md): Amazon Elastic Container Registry (ECR) is a fully managed container registry service provided by AWS.
- [Container Registry · Harbor](https://www.atomai.click/kubernetes-docs/llms/en/container-registry/03-harbor.md): Harbor is an open-source, cloud-native container registry that provides enterprise-grade features for storing, signing, and scanning container images.
- [Container Registry · Container Registry Best Practices](https://www.atomai.click/kubernetes-docs/llms/en/container-registry/04-best-practices.md): This document consolidates best practices for container registry management across Docker Hub, Amazon ECR, and Harbor.
- [Observability · Observability Overview](https://www.atomai.click/kubernetes-docs/llms/en/observability/README.md): In modern distributed systems, especially Kubernetes-based microservices architectures, the ability to observe and understand the internal state of systems…
- [Observability · Metrics](https://www.atomai.click/kubernetes-docs/llms/en/observability/metrics/README.md): Metrics describe system state and behavior numerically.
- [Observability · Prometheus](https://www.atomai.click/kubernetes-docs/llms/en/observability/metrics/01-prometheus.md): Prometheus is the CNCF monitoring toolkit originally developed at SoundCloud.
- [Observability · VictoriaMetrics](https://www.atomai.click/kubernetes-docs/llms/en/observability/metrics/02-victoriametrics.md): VictoriaMetrics stores and queries time series, with separate tools for collection (vmagent) and rule evaluation (vmalert).
- [Observability · Grafana Mimir](https://www.atomai.click/kubernetes-docs/llms/en/observability/metrics/03-mimir.md): Grafana Mimir is a Prometheus-compatible metrics backend with tenant-aware ingestion, querying and long-term block storage.
- [Observability · CloudWatch Metrics](https://www.atomai.click/kubernetes-docs/llms/en/observability/metrics/04-cloudwatch-metrics.md): CloudWatch manages storage, query, dashboards and alarms.
- [Observability · Datadog](https://www.atomai.click/kubernetes-docs/llms/en/observability/metrics/05-datadog.md): Datadog supplies a SaaS observability backend.
- [Observability · Logging](https://www.atomai.click/kubernetes-docs/llms/en/observability/logging/README.md): Logging connects application behavior, infrastructure events and audit evidence.
- [Observability · Grafana Loki](https://www.atomai.click/kubernetes-docs/llms/en/observability/logging/01-loki.md): Loki stores logs as compressed chunks and indexes stream labels.
- [Observability · OpenSearch](https://www.atomai.click/kubernetes-docs/llms/en/observability/logging/02-opensearch.md): Amazon OpenSearch Service manages search clusters and supports selected OpenSearch and legacy Elasticsearch OSS versions.
- [Observability · CloudWatch Logs](https://www.atomai.click/kubernetes-docs/llms/en/observability/logging/03-cloudwatch-logs.md): Amazon CloudWatch Logs manages log ingestion, storage and analysis.
- [Observability · ClickHouse](https://www.atomai.click/kubernetes-docs/llms/en/observability/logging/04-clickhouse.md): ClickHouse is a columnar analytical database.
- [Observability · Log Collectors](https://www.atomai.click/kubernetes-docs/llms/en/observability/logging/05-collectors.md): This guide compares Fluent Bit, Grafana Alloy and the OpenTelemetry Collector, and explains migration from retired Promtail installations.
- [Observability · Tracing](https://www.atomai.click/kubernetes-docs/llms/en/observability/tracing/README.md): Distributed tracing records instrumented operations across process boundaries and relates them through propagated context.
- [Observability · Grafana Tempo](https://www.atomai.click/kubernetes-docs/llms/en/observability/tracing/01-tempo.md): Grafana Tempo stores and queries distributed traces using object storage, Parquet blocks and TraceQL.
- [Observability · AWS X-Ray](https://www.atomai.click/kubernetes-docs/llms/en/observability/tracing/02-xray.md): AWS X-Ray is an AWS native service for tracing and analyzing requests in distributed applications.
- [Observability · OpenTelemetry](https://www.atomai.click/kubernetes-docs/llms/en/observability/tracing/03-opentelemetry.md): OpenTelemetry (OTel) is an observability framework for cloud-native software.
- [Observability · Dynatrace](https://www.atomai.click/kubernetes-docs/llms/en/observability/tracing/04-dynatrace.md): Dynatrace combines application and infrastructure telemetry with topology and problem analysis.
- [Observability · Alerting](https://www.atomai.click/kubernetes-docs/llms/en/observability/alerting/README.md): 🔍 View interactive diagram
- [Observability · Alertmanager](https://www.atomai.click/kubernetes-docs/llms/en/observability/alerting/01-alertmanager.md): Prometheus Alertmanager is a component that processes alerts sent from Prometheus servers.
- [Observability · CloudWatch Alarms](https://www.atomai.click/kubernetes-docs/llms/en/observability/alerting/02-cloudwatch-alarms.md): The CLI and Terraform examples cover classic CloudWatch metric alarms and composite alarms.
- [Observability · Grafana OnCall](https://www.atomai.click/kubernetes-docs/llms/en/observability/alerting/03-grafana-oncall.md): Grafana OnCall OSS was archived on 2026-03-24. Its repository moved to grafana-cold-storage/oncall and is read-only.
- [Observability · Grafana](https://www.atomai.click/kubernetes-docs/llms/en/observability/grafana/README.md): Grafana queries Prometheus, Loki, Tempo, CloudWatch and other data sources, and provides dashboards and alerting.
- [Observability · Observability Optimization Guide](https://www.atomai.click/kubernetes-docs/llms/en/observability/09-observability-optimization.md): Optimize observability around incident questions, collection quality and measured cost.
- [Operations Guide](https://www.atomai.click/kubernetes-docs/llms/en/ops/README.md): This section provides a production operations guide for EKS Auto Mode environments.
- [Operations Guide · Infrastructure Setup](https://www.atomai.click/kubernetes-docs/llms/en/ops/01-infrastructure-setup.md): This example describes an account/environment-specific state bucket and blue/green clusters in one Region.
- [Operations Guide · Infrastructure Advanced](https://www.atomai.click/kubernetes-docs/llms/en/ops/02-infrastructure-advanced.md): This guide separates two traffic designs: one NLB with weighted target groups, and DNS selection between two independent load balancers.
- [Operations Guide · CI Pipelines](https://www.atomai.click/kubernetes-docs/llms/en/ops/03-ci-pipelines.md): This guide uses a dedicated CI cluster for trusted, protected publish jobs. Docker-in-Docker below is privileged.
- [Operations Guide · GitOps Multi-Cluster](https://www.atomai.click/kubernetes-docs/llms/en/ops/04-gitops-multi-cluster.md): This chapter uses Argo CD on a management EKS cluster (hub) to manage two workload clusters (spokes).
- [Operations Guide · GitOps Automation](https://www.atomai.click/kubernetes-docs/llms/en/ops/05-gitops-automation.md): Separate infrastructure execution from application reconciliation.
- [Operations Guide · Scaling Strategies](https://www.atomai.click/kubernetes-docs/llms/en/ops/06-scaling-strategies.md): Separate custom-metric HPA, KEDA, VPA and Spot placement. One autoscaler must own a workload's replica count.
- [Operations Guide · Observability Alerts](https://www.atomai.click/kubernetes-docs/llms/en/ops/07-observability-alerts.md): Alerting requires more than copying metric names.
- [Operations Guide · Observability Analysis](https://www.atomai.click/kubernetes-docs/llms/en/ops/08-observability-analysis.md): Correlation connects evidence about the same time, service and request. Coincidence alone does not establish root cause.
- [Operations Guide · Observability Stack](https://www.atomai.click/kubernetes-docs/llms/en/ops/09-observability-stack.md): This chapter configures collection, storage, permissions, retention and cross-signal navigation.
- [Operations Guide · Resource Optimization](https://www.atomai.click/kubernetes-docs/llms/en/ops/10-resource-optimization.md): Do not size workloads from a language name or fixed percentage alone.
- [Operations Guide · Upgrade Operations](https://www.atomai.click/kubernetes-docs/llms/en/ops/11-upgrade-operations.md): Plan the control plane, nodes, add-ons, applications and data together. Auto Mode and PDBs alone do not guarantee uninterrupted service.
- [Operations Guide · Event Capacity Planning](https://www.atomai.click/kubernetes-docs/llms/en/ops/12-event-capacity-planning.md): PMs/planners supply demand, timing, latency and failure objectives.
- [Operations Guide · FinOps Cost Visibility Platform](https://www.atomai.click/kubernetes-docs/llms/en/ops/13-finops-cost-platform.md): FinOps brings engineering, finance, product and business teams together to manage the value of technology spending.
- [Operations Guide · Tekton Pipelines](https://www.atomai.click/kubernetes-docs/llms/en/ops/14-tekton-pipelines.md): Tekton defines Tasks, Pipelines and their executions through the Kubernetes API.
- [Operations Guide · Zonal Cluster Operations](https://www.atomai.click/kubernetes-docs/llms/en/ops/15-zonal-operations-guide.md): This guide combines traffic shifting across clusters with AZ-local workers, conditional version rollback, and AZ-aware data reads.
- [Operations Guide · Troubleshooting Playbook](https://www.atomai.click/kubernetes-docs/llms/en/ops/16-troubleshooting-playbook.md): When the pager goes off at 3 a.m.
- [Operations Guide · EKS Spot Production Experiments and Result Assessment](https://www.atomai.click/kubernetes-docs/llms/en/ops/17-spot-production-experiments.md): Assess Spot adoption by whether service SLOs and data correctness survive node reclamation, then by savings.

## Section bundles (한국어)

- [소개](https://www.atomai.click/kubernetes-docs/llms-full-ko-intro.txt): 2 pages concatenated, each preceded by a "Source:" block
- [소식](https://www.atomai.click/kubernetes-docs/llms-full-ko-news.txt): 1 page concatenated, each preceded by a "Source:" block
- [Linux & Container](https://www.atomai.click/kubernetes-docs/llms-full-ko-basics.txt): 4 pages concatenated, each preceded by a "Source:" block
- [Linux 커널](https://www.atomai.click/kubernetes-docs/llms-full-ko-kernel.txt): 4 pages concatenated, each preceded by a "Source:" block
- [Kubernetes 핵심 개념](https://www.atomai.click/kubernetes-docs/llms-full-ko-core.txt): 18 pages concatenated, each preceded by a "Source:" block
- [Amazon EKS](https://www.atomai.click/kubernetes-docs/llms-full-ko-eks.txt): 43 pages concatenated, each preceded by a "Source:" block
- [Networking](https://www.atomai.click/kubernetes-docs/llms-full-ko-networking.txt): 32 pages concatenated, each preceded by a "Source:" block
- [Service Mesh](https://www.atomai.click/kubernetes-docs/llms-full-ko-service-mesh.txt): 73 pages concatenated, each preceded by a "Source:" block
- [Storage](https://www.atomai.click/kubernetes-docs/llms-full-ko-storage.txt): 2 pages concatenated, each preceded by a "Source:" block
- [Database](https://www.atomai.click/kubernetes-docs/llms-full-ko-database.txt): 2 pages concatenated, each preceded by a "Source:" block
- [블록체인](https://www.atomai.click/kubernetes-docs/llms-full-ko-blockchain.txt): 5 pages concatenated, each preceded by a "Source:" block
- [Data Pipeline](https://www.atomai.click/kubernetes-docs/llms-full-ko-data-on-eks.txt): 31 pages concatenated, each preceded by a "Source:" block
- [AI/ML](https://www.atomai.click/kubernetes-docs/llms-full-ko-ai-ml.txt): 29 pages concatenated, each preceded by a "Source:" block
- [Security & Policy](https://www.atomai.click/kubernetes-docs/llms-full-ko-security.txt): 12 pages concatenated, each preceded by a "Source:" block
- [GitOps](https://www.atomai.click/kubernetes-docs/llms-full-ko-gitops.txt): 16 pages concatenated, each preceded by a "Source:" block
- [엔터프라이즈 클라우드 거버넌스](https://www.atomai.click/kubernetes-docs/llms-full-ko-governance.txt): 7 pages concatenated, each preceded by a "Source:" block
- [Platform Engineering](https://www.atomai.click/kubernetes-docs/llms-full-ko-platform-engineering.txt): 12 pages concatenated, each preceded by a "Source:" block
- [Container Registry](https://www.atomai.click/kubernetes-docs/llms-full-ko-container-registry.txt): 5 pages concatenated, each preceded by a "Source:" block
- [Observability](https://www.atomai.click/kubernetes-docs/llms-full-ko-observability.txt): 24 pages concatenated, each preceded by a "Source:" block
- [Operations Guide](https://www.atomai.click/kubernetes-docs/llms-full-ko-ops.txt): 18 pages concatenated, each preceded by a "Source:" block

## Section bundles (English)

- [Introduction](https://www.atomai.click/kubernetes-docs/llms-full-en-intro.txt): 2 pages concatenated, each preceded by a "Source:" block
- [News](https://www.atomai.click/kubernetes-docs/llms-full-en-news.txt): 1 page concatenated, each preceded by a "Source:" block
- [Linux & Container](https://www.atomai.click/kubernetes-docs/llms-full-en-basics.txt): 4 pages concatenated, each preceded by a "Source:" block
- [Linux Kernel](https://www.atomai.click/kubernetes-docs/llms-full-en-kernel.txt): 4 pages concatenated, each preceded by a "Source:" block
- [Kubernetes Core Concepts](https://www.atomai.click/kubernetes-docs/llms-full-en-core.txt): 18 pages concatenated, each preceded by a "Source:" block
- [Amazon EKS](https://www.atomai.click/kubernetes-docs/llms-full-en-eks.txt): 43 pages concatenated, each preceded by a "Source:" block
- [Networking](https://www.atomai.click/kubernetes-docs/llms-full-en-networking.txt): 32 pages concatenated, each preceded by a "Source:" block
- [Service Mesh](https://www.atomai.click/kubernetes-docs/llms-full-en-service-mesh.txt): 73 pages concatenated, each preceded by a "Source:" block
- [Storage](https://www.atomai.click/kubernetes-docs/llms-full-en-storage.txt): 2 pages concatenated, each preceded by a "Source:" block
- [Database](https://www.atomai.click/kubernetes-docs/llms-full-en-database.txt): 2 pages concatenated, each preceded by a "Source:" block
- [Blockchain](https://www.atomai.click/kubernetes-docs/llms-full-en-blockchain.txt): 5 pages concatenated, each preceded by a "Source:" block
- [Data Pipeline](https://www.atomai.click/kubernetes-docs/llms-full-en-data-on-eks.txt): 31 pages concatenated, each preceded by a "Source:" block
- [AI/ML](https://www.atomai.click/kubernetes-docs/llms-full-en-ai-ml.txt): 29 pages concatenated, each preceded by a "Source:" block
- [Security & Policy](https://www.atomai.click/kubernetes-docs/llms-full-en-security.txt): 12 pages concatenated, each preceded by a "Source:" block
- [GitOps](https://www.atomai.click/kubernetes-docs/llms-full-en-gitops.txt): 16 pages concatenated, each preceded by a "Source:" block
- [Enterprise Cloud Governance](https://www.atomai.click/kubernetes-docs/llms-full-en-governance.txt): 7 pages concatenated, each preceded by a "Source:" block
- [Platform Engineering](https://www.atomai.click/kubernetes-docs/llms-full-en-platform-engineering.txt): 12 pages concatenated, each preceded by a "Source:" block
- [Container Registry](https://www.atomai.click/kubernetes-docs/llms-full-en-container-registry.txt): 5 pages concatenated, each preceded by a "Source:" block
- [Observability](https://www.atomai.click/kubernetes-docs/llms-full-en-observability.txt): 24 pages concatenated, each preceded by a "Source:" block
- [Operations Guide](https://www.atomai.click/kubernetes-docs/llms-full-en-ops.txt): 18 pages concatenated, each preceded by a "Source:" block

## Optional

- [Quizzes (한국어)](https://www.atomai.click/kubernetes-docs/ko/quizzes/)
- [Labs (한국어)](https://www.atomai.click/kubernetes-docs/ko/labs/)
- [Quizzes (English)](https://www.atomai.click/kubernetes-docs/en/quizzes/)
- [Labs (English)](https://www.atomai.click/kubernetes-docs/en/labs/)