AltSchool Of Engineering Tinyuka’24 10개월 3주
Source: Dev.to
If you missed our previous session, you can catch up here. This week, we took a deep dive into Terraform, exploring what it is, why it matters, and what makes it such a powerful tool in modern cloud engineering.
컨테이너 기술 및 쿠버네티스 설명
1. 컨테이너란? (기술 세계가 이를 사랑하는 이유)
A container is a lightweight, self‑contained package that includes everything an application needs to run:
- 애플리케이션 코드
- 의존성
- 런타임 환경
- 시스템 라이브러리
Think of a container like a sealed food pack you can heat anywhere—whether you’re in Lagos or London, the food tastes exactly the same.
실제 예시
If your Python app requires Python 3.10, Flask, and specific system libraries, a container ensures it runs the same way on:
- Your laptop
- Your team’s machines
- Production
- The cloud
Gone are the days of “Works on my machine.”
2. 컨테이너 기술 (전체를 작동하게 하는 생태계)
a) 컨테이너 엔진 / 런타임
Low‑level component that actually runs the container.
containerd(used by Docker and Kubernetes)CRI‑O(lightweight runtime used in many Kubernetes environments)runc(executes containers according to OCI specs)
b) 컨테이너 클라이언트 도구
Tools developers interact with.
- Docker CLI →
docker build,docker run - Podman → daemonless alternative to Docker
- Buildah → for building images
- Skopeo → for managing container images in registries
c) 컨테이너 레지스트리
Places to store and share container images.
- Docker Hub
- GitHub Container Registry
- AWS ECR
- GCP Container Registry
- Azure Container Registry
These registries function like “app stores,” but for infrastructure. → 이러한 레지스트리는 인프라용 “앱 스토어”와 같은 역할을 합니다.
3. 컨테이너 런타임 (엔진의 내부)
A container runtime manages:
- 컨테이너 생성
- 컨테이너 실행
- 컨테이너 수명 주기 관리
- 보안 격리 적용
Kubernetes no longer manages Docker directly; it uses the Container Runtime Interface (CRI) to communicate with runtimes such as containerd, CRI‑O, or any other CRI‑compatible implementation. This makes Kubernetes more modular, faster, and cloud‑agnostic. → 쿠버네티스는 이제 Docker를 직접 관리하지 않고 Container Runtime Interface (CRI) 를 사용해 containerd, CRI‑O 등 CRI와 호환되는 런타임과 통신합니다. 이를 통해 쿠버네티스는 더 모듈화되고, 빠르며, 클라우드에 구애받지 않게 됩니다.
4. 컨테이너 오케스트레이션 (Docker보다 큰 무언가가 필요한 이유)
Running one container is easy. Running hundreds or thousands across multiple servers is not. Orchestration tools handle:
- 자동 배포
- 컨테이너 자동 스케일링(업/다운)
- 롤아웃 및 롤백
- 로드 밸런싱
- 자체 복구 컨테이너
- 컨테이너 상태 모니터링
Leading platforms:
- Kubernetes (industry standard) → Kubernetes (업계 표준)
- Docker Swarm
- Nomad by HashiCorp
Kubernetes reigns supreme. → 쿠버네티스가 절대적인 위치를 차지합니다.
5. 쿠버네티스 (K8s): 클라우드의 운영 체제
Kubernetes treats containers like tiny workers and coordinates them intelligently, ensuring apps run smoothly, reliably, and scalably even under heavy traffic.
Why companies love Kubernetes
- 높은 확장성
- 모든 클라우드에서 동작 (AWS, GCP, Azure, DigitalOcean)
- 자체 복구
- 자동 배포
- 고가용성
- 방대한 커뮤니티 및 생태계
From Netflix to Spotify to banks and telecom providers, Kubernetes powers mission‑critical systems globally.
6. 쿠버네티스 클러스터 구성 요소 (쿠버네티스가 실제로 작동하는 방식)
A. Control Plane Components (the “brain”)
-
API Server – gateway for all Kubernetes operations; every CLI, UI, or automation request goes through it.
Example:kubectl apply -f app.yamlfirst hits the API server. → API 서버 – 모든 쿠버네티스 작업의 관문; 모든 CLI, UI, 자동화 요청은 여기로 들어갑니다. 예시:kubectl apply -f app.yaml은 먼저 API 서버에 도달합니다. -
etcd – distributed key‑value store that holds the cluster state (the “memory” of Kubernetes). → etcd – 클러스터 상태를 보관하는 분산 키‑값 저장소(쿠버네티스의 “메모리”).
-
Scheduler – assigns pods to appropriate worker nodes based on CPU, RAM, node capacity, affinity rules, etc. → 스케줄러 – CPU, RAM, 노드 용량, 친화성 규칙 등을 기준으로 파드를 적절한 워커 노드에 할당합니다.
-
Controller Manager – runs long‑running control loops such as node controller, replication controller, endpoint controller, and service‑account token controller. → 컨트롤러 매니저 – 노드 컨트롤러, 복제 컨트롤러, 엔드포인트 컨트롤러, 서비스 계정 토큰 컨트롤러 등 장기 실행 제어 루프를 실행합니다.
B. Worker Node Components (where containers actually run)
-
Kubelet – agent that runs on every worker node, ensuring containers are running as instructed and communicating with the container runtime. → Kubelet – 각 워커 노드에서 실행되는 에이전트로, 컨테이너가 지시대로 실행되는지 확인하고 컨테이너 런타임과 통신합니다.
-
Kube‑Proxy – handles networking across nodes, ensuring routing between services and pods. → Kube‑Proxy – 노드 간 네트워킹을 담당하며 서비스와 파드 간 라우팅을 보장합니다.
-
Container Runtime – actually launches containers (e.g.,
containerd). → 컨테이너 런타임 – 실제로 컨테이너를 시작합니다(예:containerd).
7. How It All Works Together – Example Workflow
Deploy a containerised Flask app with Kubernetes:
# 1. Write a deployment manifest (deployment.yaml)
kubectl apply -f deployment.yaml # 2. Sends request to API Server
# 3. Scheduler picks the best worker node
# 4. Kubelet tells the container runtime to start the container
# 5. Kube‑Proxy sets up networking & load balancing
# 6. Controllers maintain the desired replica count
# 7. If a pod fails → Kubernetes automatically restarts itThis automation and intelligence make Kubernetes the backbone of cloud‑native computing.
8. Why Containers + Kubernetes Matter Today
They help organisations:
- 더 빠른 배포
- 비용 절감
- 신뢰성 향상
- 손쉬운 확장
- 개발 표준화
- 멀티‑클라우드 전략 단순화
Industries leveraging this stack include FinTech, e‑commerce, banking, telecom, energy, government, and healthcare. → 이 스택을 활용하는 산업에는 핀테크, 전자상거래, 은행, 통신, 에너지, 정부, 의료 등이 포함됩니다.
Containers changed how we package applications. → 컨테이너는 애플리케이션을 패키징하는 방식을 바꾸었습니다.
Kubernetes changed how we run them at scale. → 쿠버네티스는 대규모로 실행하는 방식을 바꾸었습니다.
Together, they form the foundation of modern cloud infrastructure powering the apps we use every day. → 함께, 이들은 매일 사용하는 앱에 전력을 공급하는 현대 클라우드 인프라의 기반을 이룹니다.