📝 Service
📌 Service object의 필요성
-
파드가 내려갔다 올라가면 IP가 변경된다. => 앞에 로드밸런서를 붙임
=> 이러한 기능을 제공하는것이 Service -
파드는 수명 주기가 짧은 일시적인 자원
이러한 상황에서파드를 외부 네트워크로 노출하려면 수명 주기에 따라 변경되는 pod의 IP주소를 찾고 파드가 구동하는 애플리케이션의 port 번호를 찾아 연결해야함 -
요청을 파드에 라우팅하는 영구적은 IP 주소와 DNS 주소가 필요
📌 service object 종류
- clusterIP
- NodePort
- LoadBalancer
📝 EKS
📌 EKS의 주요 특징
- 오픈 소스
k8s를 수정하지 않고 구동 - 4개의
마이너 버전을 지원 -> 1년 정도는 해당 버전 사용 가능, 그 이후에는 주기적으로 버전 업데이트가 필요함 (보통 3개월에 1버전 업데이트이므로 약 1년)
📌 EKS 데이터 플레인
-
API 서버는 최소 2개 이상, 안정적인 운영을 위해 3개 -
AWS가 관리하는 AWS Managed VPC, 사용자가 관리하는 Customer VPC가 있는데 서로 다른 VPC간 통신을 위해서는
EKS owner ENI사용해서 통신
📌 EKS cluster endpoint - public (defalut)
어디서든 api 서버에 접근 가능 (인증은 필요)
VPC간 통신도 외부를 통해서 접근 가능
(예를 들어 pod를 새로 생성하거나 삭제 하는 등의 .. 이런게 필요하면 외부로 api 서버 접근)
📌 EKS cluster endpoint - public + private
private host zone을 만들고 접근
같은 VPC간 통신은 내부 IP를 이용해서 접근
📌 EKS cluster endpoint - private
Baston 서버를 통해 통신
이럴 경우 내부로 나가는게 X
S3등의 서비스는 외부에 있기 때문에 Public으로만 접근해야하는데,
모든걸 private로 설정 해 버릴 경우 접근이 불가능 하다는 문제가 발생
해결방법
VPC Endpoint이용 (내부로도 S3등의 서비스를 이용 가능하게 해줌)NAT Gateway이용 (이건 내부로 접근은 불가능하고 내보내는 것은 가능 -> 따라서 보안적 측면에서 좋음)
📌 EKS 데이터 플레인 옵션
- self-managed 노드그룹
-> 최근에는 거의 사용 X
- managed 노드그룹
-> EKS 최적
- AWS fargate
-> 서버리스
📌 AWS Fargate
파드 실행 전에 Fargate의 Profile을 미리 설정해둠
pod 실행 시 Webhook이 이 pod를 가로채서 Profile에 설정해 둔 옵션에 맞게 컨테이너 실행시켜줌
여기서 EKS 실행환경은 EC2+Fargate 혼용이 가능함
📝 EKS Networking
📌 Kubernetes 네트워킹
서로 다른 워커노드간 통신을 위해 Overlay 네트워킹 사용 (VXLAN or IPIP)
📌 EKS VPC CNI 네트워킹
pod에 VPC IP를 할당해줌
-> 따라서 Overlay가 아닌 일반 VPC 네트워킹으로 서로 다른 워커노드간 통신이 가능해짐
VPC CNI 플러그인 마다 할당 받을 수 있는 최대 파드 개수가 정해져있음
Max pods = ENI X (ENI당 지원하는 IPv4 개수 -1 ) + 2
IPv4 : /28
(32비트 중 28비트가 네트워크용 adress, 나머지 4비트가 host adress)
-> 1비트당 16개..
IPv6 : /80
📌 Persistent Volume 생명주기
PV Provisioning과 Dynamic PV Provisioning으로 구분
PV Provisioning : 미리 볼륨을 만들어서 씀
Dynamic PV Provisioning : 사용할때만 볼륨을 만들어 씀 (비용 낭비 문제 해결)
📝 보안
📌 AWS EKS 책임 공유 모델
AWS 책임 영역과 고객 책임 영역으로 구분
인스턴스에 대한 장애 등은 AWS에서 커버 X
-> 따라서 책임에 대한 분배가 필요
📌 쿠버네티스 RBAC
AWS IAM과 완전 독립
쿠버네티스 리소스 접근 시 인증되는 부분
Cluster role : 클러스터 전체 권한
Role : 특정 namespace에 대한 권한
또한, pod로 실행되는 특정 애플리케이션마다 권한을 따로 부여하는것도 가능
-> Service account를 만들어서 여기에 권한 부여하는 방식
binding : 정의한 역할을 특정 사용자에게 배분
📌 EKS : IAM Authentication
관리하는 서버에 IAM Authentication가 설치
토큰을 이용해서 권한 확인.......
vi ./kube/config 명령어 실행 시 토큰 정보 등 권한 관련 내용 확인 가능
📌 pod 별 IAM 할당 (IRSA)
워커노드에 권한을 부여하는것이 아닌 Pod별로 권한을 부여
OICD ldp 등록 -> IAM role 생성 -> IAM Policy 할당 -> K8S SA 생성 -> SA Annotation 추가
📝 EKS Scaling
서비스가 잘되면 pod 뿐만 아니라 워커노드에 대한 할당도 중요해짐
- Cluster Auto-scaler : pod 배포할 워커노드 부족 시 워커노드 추가
- Horizontal pod Auto-scaler : pod 자원 부족 시 pod 추가
- 그외 하나 더..
📌 EKS 환경에서의 Auto Scaling
- Metric Server의 지표 수집를 주기적으로 수집
- HPA Controller가 계속 Mertric server를 체크하고 임계치를 넘을 경우 ReplicaSet 증가 -> 새로운 Pod 추가
이때 워커노드에 자리가 없는데 pod가 또 추가 될 경우 이건 Pending pod로 빠짐
-> Cluster auto scaler가 주기적으로 해당 상태도 체크해줌
-> auto scaling group 생성
📝 CI/CD
📌 gitOps란?
인프라가 코드로 정의되고 git 리포지토리에서 버전이 관리되며 동일한 Pull request 프로세스에 따라 프로비저닝 되는 접근 방식
-> git을 통한 모든 형상관리가 가능
버전관리, 브랜치관리 등 모든 관리를 git을 통해 관리
쿠버네티스를 위한 gitOps 도구 -> argoCD
iptables