chapter 1

posts/week1/chapter1.md

@@ -0,0 +1,158 @@
+# Container
+
+# VM과 컨테이너
+
+### VM
+
+**가상 머신** (  VM)은 하나의 서버를 여러 서버로 바꾸는 물리적 하드웨어의 추상화입니다.
+
+프로그램을 실행하고 앱을 배포하기 위해 물리적 컴퓨터 대신 소프트웨어를 사용하는 컴퓨팅 리소스입니다. 하나 이상의 가상 "게스트" 머신이 물리적 "호스트" 머신에서 실행됩니다.
+
+**하이퍼바이저 유형**
+
+|  | **1형 하이퍼바이저** | **2형 하이퍼바이저** |
+| --- | --- | --- |
+| AKA | 베어메탈 하이퍼바이저. | 호스트형 하이퍼바이저. |
+| 실행 환경 | 기본 물리적 호스트 머신 하드웨어. | 기본 운영 체제(호스트 OS) |
+| 전용 리소스를 조정 | 예. | 아니요. |
+| 예시 | VMware ESXi, Microsoft Hyper-V, KVM. | Oracle VM VirtualBox, VMware Workstation, Microsoft Virtual PC. |
+
+### 컨테이너
+
+컨테이너는 코드와 종속성을 함께 패키징하는 앱 계층의 추상화입니다. 
+
+여러 컨테이너가 동일한 머신에서 실행되고 다른 컨테이너와 OS 커널을 공유할 수 있으며, 각각은 사용자 공간에서 격리된 프로세스로 실행됩니다. 
+
+컨테이너는 VM보다 공간을 적게 차지하고(컨테이너 이미지는 일반적으로 수십 MB 크기임), 더 많은 애플리케이션을 처리할 수 있으며 더 적은 VM과 운영 체제가 필요합니다.
+
+![image.png](image.png)
+
+[https://www.docker.com/resources/what-container/](https://www.docker.com/resources/what-container/)
+
+- Kernel namespaces (ipc, uts, mount, pid, network and user)
+- Apparmor and SELinux profiles
+- Seccomp policies
+- Chroots (using pivot_root)
+- Kernel capabilities
+- CGroups (control groups)
+
+다양한 격리들을 통해 호스트의 커널을 공유하면서도, 자원 자체의 격리나 보안을 구현하는 방식으로 설계
+
+레이어가 적어, 오버헤드가 적은만큼 속도와 자원에서의 이점
+
+### VM과 컨테이너 비교
+
+| 구분 | VM(가상 머신) | 컨테이너 |
+| --- | --- | --- |
+| 부팅 속도 | 별도의 게스트 OS 부팅 필요로 인해 느림 | 호스트 OS 커널 공유로 즉각적인 애플리케이션 기동 가능 |
+| 자원 활용 효율성 | 각 VM마다 OS 이미지를 포함해 비교적 무거움(일반적으로 수 GB 단위) | 공통 커널 사용으로 경량, 수십 MB 수준의 이미지로 자원 활용 효율적 |
+| 보안 및 격리 | 하이퍼바이저를 통한 하드웨어 레벨 격리로 높은 격리 보장 | 커널 네임스페이스, cgroups 등을 통한 프로세스 레벨 격리, 상대적으로 낮은 격리 수준 |
+| 사용 사례 | 독립적인 OS 환경이 필요한 경우나 레거시 애플리케이션 지원에 유리 | 마이크로서비스, CI/CD 파이프라인 등 빠른 배포와 스케일링이 필요한 모던 애플리케이션에 유리 |
+
+## **리눅스 컨테이너(LXC)와 도커(Docker) 등장**:
+
+![[https://en.wikipedia.org/wiki/Docker_(software)](https://en.wikipedia.org/wiki/Docker_(software))](image1.png)
+
+[https://en.wikipedia.org/wiki/Docker_(software)](https://en.wikipedia.org/wiki/Docker_(software))
+
+- 리눅스 커널 기반의 `cgroup`과 `namespace` 기술을 활용한 프로세스 격리 등장(LXC).
+- Docker는 단순한 런타임뿐 아니라 이미지 빌드, 레지스트리 관리까지 포함한 올인원 솔루션으로 컨테이너 생태계 대중화.
+- 이 시기에 “이미지를 어떻게 표준화할 것인가”, “컨테이너를 어떻게 표준 인터페이스로 실행할 것인가”에 대한 요구 증가.
+
+## **OCI(Open Container Initiative) 표준화**
+
+![[https://naleejang.tistory.com/228](https://naleejang.tistory.com/228)](image2.png)
+
+[https://naleejang.tistory.com/228](https://naleejang.tistory.com/228)
+
+- Docker 독자 규격에서 벗어나 **OCI 이미지 스펙 및 런타임 스펙**이 등장.
+
+![[https://www.samsungsds.com/kr/insights/docker.html](https://www.samsungsds.com/kr/insights/docker.html)](image3.png)
+
+[https://www.samsungsds.com/kr/insights/docker.html](https://www.samsungsds.com/kr/insights/docker.html)
+
+- 이를 통해 `containerd`, `CRI-O` 등 다양한 런타임이 표준 인터페이스를 기반으로 상호호환성을 확보.
+
+![image.png](image4.png)
+
+- OCI github : [https://github.com/opencontainers](https://github.com/opencontainers)
+- image-spec : [https://github.com/opencontainers/image-spec/blob/main/spec.md](https://github.com/opencontainers/image-spec/blob/main/spec.md)
+- runtime-spec : [https://github.com/opencontainers/runtime-spec/blob/master/spec.md](https://github.com/opencontainers/runtime-spec/blob/master/spec.md)
+- distribution-spec : [https://github.com/opencontainers/distribution-spec/blob/main/spec.md](https://github.com/opencontainers/distribution-spec/blob/main/spec.md)
+
+# 컨테이너 구성요소
+
+## 컨테이너 런타임 (Container Runtime)
+
+- **Docker**: 초기 컨테이너 기술의 대명사 역할. Image 빌드, 이미지 레지스트리, 런타임까지 올인원 제공.
+- **Containerd**: Docker 런타임을 분리한 컨테이너 런타임. 경량화되고 Kubernetes CRI(Container Runtime Interface)와 호환성이 좋음.
+- **CRI-O**: Kubernetes 전용으로 개발된 런타임. Open Container Initiative(OCI) 규격을 따르는 이미지 및 런타임과 쉽게 연동.
+
+### 이미지(Image)의 구성
+
+- 컨테이너는 특정 애플리케이션을 실행하기 위한 패키지입니다.
+- Docker 이미지는 "컨테이너를 만들기 위한 청사진"으로, 애플리케이션 실행에 필요한 코드, 라이브러리, 설정을 모두 포함합니다.
+- **이미지 레이어**: 컨테이너 이미지는 여러 개의 읽기 전용 레이어로 구성, 재사용을 통해 빌드 및 배포 효율성을 극대화.
+- **OCI 이미지 규격**: 컨테이너 이미지 표준 규격을 통해 Docker뿐 아니라 다양한 런타임에서 호환성 확보.
+
+### 레이어(Layer)란?
+
+![[https://www.springcloud.io/post/2022-02/docker-layer-spring-boot/#gsc.tab=0](https://www.springcloud.io/post/2022-02/docker-layer-spring-boot/#gsc.tab=0)](image5.png)
+
+[https://www.springcloud.io/post/2022-02/docker-layer-spring-boot/#gsc.tab=0](https://www.springcloud.io/post/2022-02/docker-layer-spring-boot/#gsc.tab=0)
+
+- Docker 이미지는 여러 개의 **읽기 전용 레이어**가 쌓여있는 구조입니다.
+- Dockerfile에 정의된 각 명령(`FROM`, `RUN`, `COPY` 등)이 새로운 레이어를 만듭니다.
+- 동일한 레이어는 캐시를 통해 재사용하므로, 빌드 시간을 단축하고 저장공간을 절약할 수 있습니다.
+
+### 컨테이너 네트워킹과 스토리지
+
+- **네트워크** : 호스트 네임스페이스를 활용한 격리, 가상 NIC, 브릿지 네트워크, Overlay 네트워크 등을 통한 유연한 네트워킹 제공.
+- 
+- **스토리지**: 컨테이너 파일 시스템은 휘발성(Ephemeral)이며, Stateful 애플리케이션을 위해 Volume 을 활용.
+
+### 컨테이너 런타임 (Container Runtime) 개념 등장
+
+**런타임 필요성**:
+
+컨테이너를 실행하기 위해서는 “어떻게 프로세스를 격리하고, 네임스페이스와 cgroup을 구성하며, 이미지를 어떻게 마운트할 것인지”와 같은 구체적 동작이 필요합니다. 이를 담당하는 소프트웨어가 바로 **컨테이너 런타임**입니다.
+
+**초기 등장 - Docker**:
+
+- Docker는 컨테이너 이미지 빌드, 실행, 레지스트리 관리까지 올인원으로 제공함으로써 초기 컨테이너 생태계 확장에 큰 기여를 했습니다.
+- 이후 성능 및 상호 운용성, 표준화 요구가 높아지며 Docker 런타임으로부터 분리된 `containerd`, Kubernetes 친화적 런타임인 `CRI-O` 등이 등장했습니다.
+
+### 4. 컨테이너 이미지의 표준화와 OCI
+
+**이미지 개념 등장**:
+
+컨테이너 이미지는 “애플리케이션 실행에 필요한 모든 것을 포함한 패키지”입니다. 이 이미지를 표준화하면, 특정 런타임에 종속되지 않고도 어디에서나 실행 가능한 컨테이너를 만들 수 있습니다.
+
+**OCI (Open Container Initiative) 규격**:
+
+도커 초창기에는 Docker 고유 형식만 있었으나, 이후 컨테이너 생태계가 커지면서 표준 이미지 /포맷과 런타임 사양이 필요해졌습니다. 이에 OCI에서 이미지와 런타임에 대한 공개 표준을 정의, `Docker`, `containerd`, `CRI-O` 모두 이 규격에 맞추어 상호호환성 확보가 가능해졌습니다.
+
+## 컨테이너 네트워크와 스토리지
+
+### 네트워크 인터페이스 표준화 (CNI)
+
+1. **초창기 네트워킹**:
+    - Docker 초기에는 자체 브릿지 네트워크(docker0), 호스트 네트워크, 포트 맵핑 등 단순한 구조.
+    - 컨테이너 증가에 따라 서로 다른 호스트에 분산된 컨테이너를 하나의 논리 네트워크로 묶기 위한 Overlay 네트워크, SDN, 플러그인 형태 솔루션(Flannel, Calico, Weave 등) 등장.
+2. **CNI(Container Network Interface) 등장**:
+    - Kubernetes와 같은 오케스트레이션 환경에서는 다양한 네트워크 솔루션을 유연하게 붙일 수 있는 공통 규격 필요.
+    - CNI는 컨테이너 네트워크를 설정하고 삭제하기 위한 표준 인터페이스 정의.
+    - 이를 통해 다양한 네트워크 플러그인이 공통된 방식으로 컨테이너 네트워크를 관리 가능해짐.
+
+### 스토리지 인터페이스 표준화 (CSI)
+
+1. **초창기 스토리지 접근**:
+    - Docker 볼륨, 바인드 마운트 등 호스트 종속적이며 특정 스토리지 기술에 종속된 방식 활용.
+    - 클러스터 환경, 멀티노드 환경 확대에 따라 외부 스토리지(블록, 파일, 오브젝트)와 컨테이너 간의 일관된 연동 필요성 증가.
+2. **CSI(Container Storage Interface) 탄생**:
+    - Kubernetes를 비롯한 컨테이너 오케스트레이션 환경에서 표준화된 스토리지 플러그인 인터페이스 필요성 대두.
+    - CSI를 통해 다양한 스토리지 벤더(클라우드 EBS, Ceph, NFS, GlusterFS 등)가 공통 규격으로 컨테이너에 스토리지 제공 가능.
+    - 이를 통해 특정 런타임이나 특정 플랫폼에 종속되지 않고, 다양한 스토리지를 일관성 있게 다룰 수 있게 됨.
+
+출처 : 
+VM 개념 : https://www.vmware.com/topics/virtual-machine

posts/week2/About_Kubernetes.md

@@ -0,0 +1,84 @@
+# About Kubernetes
+
+## 쿠버네티스 소개
+
+### 쿠버네티스(Kubernetes)란 무엇인가?
+
+- **컨테이너 오케스트레이션 툴**: 다수의 컨테이너를 효율적으로 자동화(배포, 스케일링, 업데이트, 복구)하는 플랫폼.
+- **CNCF(Could Native Computing Foundation)에서 관리하는 오픈소스 프로젝트**: 구글 내부의 Borg/Omega 시스템 경험을 바탕으로 개발.
+- **클러스터 기반 아키텍처**: 여러 노드(Node)로 이루어진 클러스터에서 애플리케이션 컨테이너를 효율적으로 관리.
+- **거대한 API 기반의 자동화 시스템**: 사용자는 선언적 구성(YAML 등)을 API를 통해 제출하고, 쿠버네티스는 이를 바탕으로 '원하는 상태(Desired State)'를 유지. 즉, Kubernetes API를 통해 리소스를 정의하면, 내부 컨트롤러들이 이 요청을 처리하고 클러스터 상태를 유지
+
+## 아키텍처 개요
+
+## 구성요소
+
+### 컨트롤 플레인(Control Plane)
+
+- **API 서버(kube-apiserver)**: 모든 요청이 통하는 중앙 게이트웨이. 사용자가 YAML로 정의한 리소스를 제출하면 API 서버가 이를 etcd에 반영하고 컨트롤러 및 스케줄러와 연계.
+- **etcd**: 클러스터 상태 정보 저장소. 모든 리소스(파드, 서비스, 컨피그 등)의 원본 데이터가 여기 기록.
+- **컨트롤러 매니저(kube-controller-manager)**: 디플로이먼트, 레플리카셋 등 다양한 컨트롤러들이 주기적으로 실제 상태를 원하는 상태로 맞추도록 동작.
+- **스케줄러(kube-scheduler)**: 새 파드를 배치할 노드를 결정.
+
+API 서버를 중심으로 상호작용하며, etcd에 기록된 상태 정보를 기반으로 지속적으로 클러스터 상태를 원하는 방향으로 조정.
+
+### 워커 노드(Worker Nodes)
+
+- **kubelet**: 해당 노드에 배치된 파드가 API 서버에서 정의한 상태대로 동작하도록 컨테이너 런타임(Docker, containerd 등)과 통신.
+- **kube-proxy**: 서비스(로드밸런싱) 트래픽을 처리하고 파드 간 네트워크 통신을 관리.
+- **컨테이너 런타임**: 파드를 구성하는 컨테이너를 실제로 구동.
+
+워커 노드는 kubelet을 통해 API 서버에 지속적으로 상태 정보를 보고하며, 
+
+스케줄러나 컨트롤러 매니저가 내린 결정에 따라 파드를 생성, 제거, 업데이트함.
+
+## 주요 개념
+
+- **파드(Pod)**: 하나 이상의 컨테이너를 묶은 최소 배포 단위. 동일한 네트워크 네임스페이스를 공유하며 함께 스케일링, 롤링 업데이트됨.
+- **서비스(Service)**: 파드 집합에 대한 일관된 접근점을 제공. 파드가 동적으로 변하더라도 클라이언트는 같은 IP/엔드포인트로 접근 가능.
+- **디플로이먼트(Deployment)**: 파드 템플릿과 스케일 정보 등을 선언적으로 정의한 상위 리소스. 롤링 업데이트, 롤백 등이 손쉽게 가능.
+- **레플리카셋(ReplicaSet)**: 지정한 파드 개수를 항상 유지하도록 하는 리소스. 디플로이먼트 내부적으로 레플리카셋을 활용.
+
+### 쿠버네티스의 이점
+
+- 자원 통합 : 컨테이너, 네트워킹, 스토리지, 보안, 설정 관리, 노드 자원 등을 API로 추상화
+
+    ![image.png](image.png)
+
+- **선언적 배포(Declarative Deployment)**: 원하는 상태(Desired State)를 YAML 등으로 정의하면, 쿠버네티스가 이를 만족하도록 자동 조정.
+- **자동화된 스케일링(Auto Scaling)**: CPU, 메모리 사용량 기반의 Horizontal Pod Autoscaler를 통해 자원 사용량에 따라 파드를 자동으로 증가(Horizontal Pod Autoscaler) 또는 감소.
+- **자체 치유(Self-Healing)**: 비정상 파드 자동 재시작, 노드 장애시 파드 재스케줄링, 헬스 체크(Health Check)로 인한 자동 롤링 업데이트 및 롤백 기능으로 애플리케이션 가용성을 극대화.
+
+- **보안 및 인증/인가 강화**
+    - Role-Based Access Control(RBAC), Network Policies, Admission Controller, Pod Security Standards 등 다층적인 보안 정책 적용.
+    - TLS 기반 API 서버 접근, 서비스 계정(ServiceAccount), 비밀 정보(Secrets) 관리, Vault 연동 등을 통해 민감 정보나 접근 권한을 철저히 관리할 수 있음.
+    - **역할 기반 접근 제어(RBAC, Role-Based Access Control)**
+        - 쿠버네티스 API 접근을 특정 사용자나 서비스 계정이 어떤 리소스에 대해 어떤 동작(읽기, 쓰기, 업데이트 등)을 할 수 있는지 명확히 정의 가능.
+    - **네임스페이스(Namespace)**
+        - 쿠버네티스 클러스터 내 리소스들을 논리적으로 격리하기 위한 이름공간.
+        - 애플리케이션, 팀, 환경(개발/스테이징/프로덕션)별로 네임스페이스를 분리함으로써 리소스 충돌을 방지하고, 접근 제어나 할당 자원 관리에도 유용.
+        - RBAC나 네트워크 정책, 리소스 쿼터(Quota) 등을 네임스페이스 단위로 적용할 수 있어, 체계적인 멀티테넌트(Multi-Tenant) 환경 구축에 기여.
+    - **네트워크 정책(Network Policy)**
+        - 파드(Pod) 수준의 네트워크 트래픽 흐름을 제어하는 규칙 세트.
+    - **정책 엔진(Admission Controller)**
+        - 쿠버네티스 API 서버로 들어오는 요청을 사전 검증/변환/거부하기 위한 플러그인 구조체.
+
+        - **Validating Admission Controller**: 리소스가 특정 규칙에 맞는지 확인하고, 위배 시 요청 거부.
+        - **Mutating Admission Controller**: 리소스를 동적으로 변환(레이블 추가, sidecar 삽입 등).
+    - **AppArmor, Linux Capabilities 등 호스트 수준 보안 강화**
+        - **AppArmor**: 파드 내 컨테이너 프로세스에 대해 추가적인 보안 프로파일을 적용해 파일 접근, 네트워크 사용 등을 제한.
+        - **Linux Capabilities**: 컨테이너 런타임 수준에서 필요한 최소한의 권한만 할당해, 불필요한 루트 권한이나 시스템 콜 사용을 억제.
+
+- **커스텀 리소스(CR) 기반 확장**
+    - CRD를 통해 쿠버네티스 API를 확장하여 조직만의 맞춤형 리소스를 정의하고, 이를 오퍼레이터 패턴(Operator Pattern)으로 자동 관리.
+    - CPU, 메모리 외에도 HugePage나 GPU, FPGA 같은 특수 하드웨어 리소스를 Device Plugin을 통해 노출하고 관리 가능.
+    - 이를 통해 쿠버네티스는 단순 컨테이너 오케스트레이션을 넘어, 다양한 워크로드(데이터베이스, 머신러닝, 고성능 연산 등)에 최적화된 플랫폼으로 발전할 수 있음.
+
+- **다양한 오픈소스 생태계 및 확장성**
+    - Helm을 통한 패키지 관리로 복잡한 애플리케이션 스택을 쉽게 배포하고 업그레이드 가능.
+    - CNI(Container Network Interface), CSI(Container Storage Interface) 같은 표준 인터페이스 덕분에 다양한 네트워크 및 스토리지 플러그인을 손쉽게 연동할 수 있으며, ISTIO와 같은 서비스 메쉬(Service Mesh)나 Calico, Cilium 등의 네트워크 플러그인을 통해 고도의 네트워킹 정책 구현 가능.
+    - KEDA, Argo CD, Prometheus, Vault 등 수많은 CNCF 및 오픈소스 프로젝트와 자연스럽게 연계되어 DevOps, Observability, 보안 강화, Secret 관리 등 다양한 운영 영역을 확장 가능.
+
+![[https://landscape.cncf.io/](https://landscape.cncf.io/)](image1.png)
+
+[https://landscape.cncf.io/](https://landscape.cncf.io/)