25.10.16 요약

EKS

 

 Packaging -> Distribution -> Immutable Infrastructure

 

Registry

컨테이너 이미지 저장소

 

컨트롤 플레인 (마스터노드)

Deploy, Scheduling, Scaling, 컨테이너 응용 프로그램의 관리

 

데이터 플레인 (워커노드)

컨테이너의 실행 환경

 

kubectl 명령어

• get
• create
• describe
• delete
• apply etc

리소스 종류

• Pod
• Replicaset
• Deployment
• Job
• CronJob
• StatefuleSet

pod의 컨테이너는 localhost에서 통신 가능

 

Replicaset

count =3             ->        pod가 3개 생성

 

Deployment        ->        replicaset 을 통합 관리 해줌

 

Deamon set  (반드시 하나의 서비스가 돌아야 함) -> 모니터링 용도로 사용

 

Job과 ReplicaSet 차이 (개념적으로는 같으나 쓰임이 다름)

• ReplicaSet (계속 켜져 있어야 함) -> 연속 성
• Job (종료가 예정되어있는 Pod) -> 배치 성

 

Ingress ( 7계층 : 애플리케이션 계층 ) : 라우팅 테이블 ( 3계층 : 네트워크 계층 )

처럼 어디로 갈지 방향을 정해줌 하지만 계층이 다름 라우팅 테이블은 IP기반으로 어디에 접근할지 정하지만 Ingress는 HTTP 주소를 확인하고 어떤 서비스에 접근할지 정함.

 

kubernetes 는 중앙 관리형 시스템 마스터 노드가 깨지면 워커 노드도 다 망가지기 때문에 컨트롤 플레인은 AWS 자체 내에서 관리하고 클라이언트는 접근이 불가능 (특정 정보 : IP 같은 건 볼 수 있음)

 

🔸 주요 CNI 플러그인 비교 요약표

CNI 플러그인	주요 사용 환경	IP 부여 방식	장점	단점
Amazon VPC CNI	✅ EKS 기본	Pod가 EC2의 ENI(Elastic Network Interface)를 직접 사용	AWS VPC와 완전 통합, Pod가 VPC 네이티브 IP 사용	ENI/IP 제한으로 확장성 제약 (IP 고갈 가능)
Calico	EKS, 온프레미스	자체 IPAM or AWS VPC	NetworkPolicy(보안 정책) 강력, eBPF 지원	설정 복잡도 높음, AWS 통합성 낮음
Cilium	EKS, GKE 등 클라우드	eBPF 기반 동적 라우팅	고성능, 보안/관찰성 우수 (L7 정책 가능)	구성 복잡, eBPF 커널 요구
Weave Net	온프레미스, 개발용	자체 IPAM	간단한 설치, 자동 mesh 네트워크	대규모 환경에서 성능 떨어짐
Flannel	간단한 Kubernetes 실습용	VXLAN 기반 overlay	단순하고 빠른 설치	L3 단위 통신만 지원, NetworkPolicy 미지원
Canal	Calico + Flannel 혼합형	Overlay	NetworkPolicy + 간단한 배포 둘 다 가능	설정 다소 복잡