구름 쿠버네티스 전문가 과정 6기 - 50일차

리뷰 (Review)

ReplicaSet

• ReplicaSet reference
• ReplicationController reference
• Pod를 정해진 수만큼 복제하고 관리
• 사용자가 요구하는 상태가 되도록 Pod를 관리
• spec.replicas - 동일한 Pod 유지할 개수
• spec.selector.matchLabels - label 체크 조건, ReplicaSet이 검색하는 Pod label
• spec.template - 생성할 Pod 명시

 

Deployment

• Kubernetes에서 가장 많이 사용되는 Object
• ReplicaSet을 관리하는 Controller 역할
• ReplicaSet을 이용하여 Pod를 Update 하고 이력을 관리하여 Rollback 하거나 Revision 기능 제공
• Deployment는 ReplicaSet을 제어하여 Pod를 관리

 

Application 무중단 배포 (update) 방식

• Rolling Update
  • 사용 중인 인스턴스 내에서 새 버전을 점진적으로 교체
  • 무중단 방식의 가장 기본적인 방식
• Blue / Green Deployment
  • 운영 중인 구버전과 동일한 신버전의 인스턴스를 구성
  • Load Balancer를 통해 모든 트래픽을 한번에 구버전에서 신버전 쪽으로 전환하는 방식
  • 구버전의 인스턴스가 그대로 남아있어서 손쉬운 Rollback이 가능한 장점
  • 시스템 자원이 두 배로 필요한 단점
• Canary Release
  • 신버전을 소수의 사용자에게 배포해서 문제가 없는지 확인한 후 점차 사용자를 늘려 배포하는 기법
  • 트래픽을 한 번에 바꾸는 것이 아니라 단계적으로 전환하므로 Blue / Green Deployment와 차이가 있다.
  • 부정적 영향을 최소화하고 트래픽 양을 조절하여 Rollback 할 수 있다.

---

Service

 

Service Object

• 참고 자료
• Pod들을 통해 실행되고 있는 Application을 네트워크에 노출 (expose) 시키는 가상의 Component
  • Pod는 무언가 구동 중인 상태를 유지하기 위해 동원되는 일회성 자원으로 언제든 다른 node로 옮겨지거나 삭제될 수 있다.
  • Pod는 생성될 때마다 새로운 내부 IP를 부여받으므로 cluster 내/외부 통신을 계속 유지하기 어렵다.
• Service는 Pod가 외부와 통신할 수 있도록 cluster 내부에서 고정적인 IP를 갖도록 하는 역할
• Service는 Deployment나 Stateful set처럼 같은 Application을 구동하도록 구성된 여러 Pod들에게 단일한 네트워크
  진입점 부여 역할
• Service를 정의하고 생성할 때는 spec.ports 속성 아래에 연결하고자 하는 항목 별로 2개씩의 Port 지정
  • targetPort
    • Pod의 Application 쪽에서 열려있는 Port 의미
    • Service로 들어온 트래픽은 해당 Pod의 <클러스터 내부 IP>:<target Port>로 넘어가게 된다.
  • port
    • Service 쪽에서 해당 Pod를 향해 열려있는 Port 의미

 

Kubernetes Network 구조

• Dcoker Network 구조
  • Docker는 Bridge 타입의 Network 구조
  • docker0 - 호스트 네트워크 네임스페이스
  • veth (Virtual Ethernet) - 컨테이너 네트워크 인터페이스

---

• Kubernetes Pod 네트워킹
  • Kubernetes cluster 상에서 Pod에 개별 IP 부여
  • Pod에는 여러 개의 container가 동작할 수 있고 Pod에 부여된 IP Address를 container가 공유
  • Pod가 생성되면 Pause container의 네트워크 네임스페이스를 갖게 되고 Pod 내의 container 간 127.0.0.1로
    port를 구분하여 통신 가능

---

• 하나의 node(Worker node)의 Pod to Pod 통신
  • 네트워크 인터페이스(Kubernetes 또는 CNI)를 통하여 Pod에 할당되어 있는 고유 IP로 통신
  • Kubernetes는 기본적으로 kubelet이라는 네트워크 플러그인 제공
  • kubelet은 크로스 노드 네트워킹이나 네트워크 정책 결정과 같은 네트워크 고급 기능은 구현되어 있지 않다.
  • CNI 스펙을 준수하는 Weave net과 같은 네트워크 플러그인을 따로 사용

---

• 여러 node(Worker node)간의 Pod to Pod 통신
  • 오버레이 네트워크 기능을 구현하기 위해 CNI를 설치하고 라우터를 경유하여 통신
  • Pod0 → veth0 → CNI → eth0 → 라우터(VPC) → eth1 → CNI → veth1 → Pod1

---

Service 유형

• 참고 자료
• Cluster IP (default)
  • Pod들이 cluster 내부의 다른 리소스들과 통신할 수 있도록 해주는 가상 cluster 전용 IP
  • cluster 내부에서만 접근 가능
  • spec.slector에 지정된 label로 여러 Pod들이 존재할 경우 Service는 그 Pod들의 외부 요청(request)을
    전달할 endpoint로 선택하여 트래픽을 분배 (LoadBalancing)
  • endpoint를 수동으로 직접 지정해줄때는 Endpoints 객체를 이용하여 Service와 mapping 한다.
    주의점은 endpoint를 명시할 IP는 loopback이면 안된다. 

apiVersion: v1
kind: Service
metadata: 
  name: my-internal-service
spec:
  selector:			# Service가 적용될 Pod 정보
    app: my-app
  type: ClusterIP		# 생략 가능
  ports: 
  - name: http
    port: 80			# Service를 노출하는 Port
    targetPort: 80		# Pod (Application)을 노출하는 Port
    protocol: TCP

apiVersion: v1
kind: Service
metadata:
  name: myapp-service
spec:
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376
---
apiVersion: v1
kind: Endpoints
metadata:
  name: myapp-service		# 연결할 서비스와 동일한 name을 메타데이터로 입력
subsets:			# 해당 서비스로 가리킬 endpoint를 명시
  - addresses:
      - ip: 192.0.2.42
    ports:
      - port: 9376

---

• NodePort
  • 외부에서 node IP의 특정 Port(<Node IP>:<Node Port>)로 들어오는 요청을 감지하여 해당 port와
    연결된 Pod로 트래픽 전달
  • spec.ports에 nodePort를 추가로 지정
    • nodePort는 외부에서 node 안의 특정 서비스로 접근할 수 있도록 지정된 node의 특정 port 의미
    • nodePort의 범위는 30,000 ~ 32,767, 미지정시 임의의 Port 부여
  • spec.selector에 해당하는 모든 Pod들에 NodePort에 의해 동일한 LoadBalancing이 적용된다.

apiVersion: v1
kind: Service
metadata: 
 name: my-nodeport-service
spec:
 selector:   
   app: my-app
 type: NodePort
 ports: 
 - name: http
   port: 80			# Service에 노출되는 Port
   targetPort: 80		# Pod(Application)을 노출하는 Port
   nodePort: 30036		# 외부 사용자가 Application에 접근하기 위한 Port
   protocol: TCP

---

• LoadBalancer
  • 별도 외부 LoadBalancer를 제공하는 cloud (AWS, GCP, Azure 등) 환경을 고려하여 해당 LoadBalancer를
    cluster의 Service로 프로비저닝할 때 사용
  • Service를 cloud 제공자 측의 자체 LoadBalancer로 노출시키며, 필요한 NodePort와 ClusterIP는 자동 생성
  • 프로비저닝 된 LoadBalancer 정보는 Service의 status.loadBalancer 속성에 기재
  • 외부 LoadBalancer를 통해 들어온 트래픽이 Server 설정값을 따라 해당되는 Pod로 연결되며 트래픽이 어떻게
    LoadBalancing이 될 지는 cloud 제공자의 설정에 따라 다르다.
  • LoadBalancer 프로비저닝을 지원하지 않는 환경에서는 이 유형은 NodePort와 동일 방식으로 동작

apiVersion: v1
kind: Service
metadata:
  name: myapp-service
spec:
  type: LoadBalancer
  ports:
    - protocol: TCP
      port: 80			# 서비스를 노출하는 포트
      targetPort: 80		# 애플리케이션(파드)를 노출하는 포트
  clusterIP: 10.0.171.239	# 클러스터 IP
  selector:
    app: myapp
    type: frontend
status:
  loadBalancer:			# 프로비저닝된 로드 밸런서 정보
    ingress:
      - ip: 192.0.2.127

---

• ExternelName
  • Service에 selector 대신 name을 직접 명시하고자 할 때 사용
  • spec.externalName 속성에 필요한 DNS 주소 기입하면 cluster의 DNS 서비스가 해당 주소에 대한 CNAME
    레코드 반환

apiVersion: v1
kind: Service
metadata:
  name: myapp-service
  namespace: prod
spec:
  type: ExternalName
    externalName: my.database.example.com

 

CLI 명령어로 Pod에 Service 적용하기

• kubectl create service <Service 유형>

kubectl create service clusterip redis --tcp=6379:6379

kubectl run custom-nginx --image=nginx --port=8080 &&
kubectl expose ppod custom-nginx

• kubectl expose pod

kubectl expose pod redis --port=6379 --name redis-service

 

외부 IP 주소를 노출하여 cluster의 Application 접속하기 예제

• https://kubernetes.io/ko/docs/tutorials/stateless-application/expose-external-ip-address/

 

Service Object를 외부에서 cluster 내로 진입할 때 항상 Port 번호를 지정해야 한다.

• curl http://<external-ip>:<port>

---

Ingress

 

Ingress

• Kubernetes cluster 외부에서 내부로 들어오는 트래픽에 대해 어떻게 처리할지 정의하는 규칙
• Ingress는 외부에서 Kubernetes cluster에서 실행 중인 Deployment와 Service에 접근하기 위한 일종의
  Gateway 같은 역할 담당

 

• Service object 사용과 Ingress object 사용 차이
  • Service object를 이용하여 cluster 외부와 연결하는 방식은 4계층 (전송 계층) 기반을 사용함으로
    실제 Application 작성 시 직접적인 처리를 적용해야 한다.
  • Ingress object를 이용하여 cluster 외부와 연결하는 방식은 7계층 (Application 계층) 기반을 사용함으로
    Application 계층의 다양한 프로토콜을 적용할 수 있다.

 

Ingress와 Ingress contoller

• Ingress
  • YAML 파일을 통해 Ingress (inbound) 규칙 정의
  • Ingress object 생성 하더라도 실질적인 동작은 없다.
  • Ingress reference

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: my-ingress
spec:
  backend:
    serviceName: other
    servicePort: 8080
  rules:
  - host: foo.mydomain.com
    http:
      paths:
      - backend:
          serviceName: foo
          servicePort: 8080
  - host: mydomain.com
    http:
      paths:
      - path: /bar/*
        backend:
          serviceName: bar
          servicePort: 8080

 

• Ingress controller
  • Ingress에 의해 정해진 규칙에 따라 실제 외부 요청을 실질적으로 처리하는 특수한 서버 container
  • Ingress Controller - NginX
  • Ingress Controller는 LoadBalancer와 연결하여 동작한다.

 

kubectl을 통한 Ingress 배포 예제

• https://guide.ncloud-docs.com/docs/k8s-k8sexamples-ingress

---

Amazon EKS

 

참고 자료

• https://aws.amazon.com/ko/eks/
• https://aws.amazon.com/ko/kubernetes/

 

Amazon EKS (Elastic Kubernetes Service)

• 직접 Kubernetes의 Control plane과 node를 구성하지 않고 AWS 환경에서 Kubernetes Cluster를 구성할 수 있는
  완전 관리형 서비스

 

Amazon EKS k8s Cluster 구성을 위한 client 구성 및 Cluster 구성

• AWS CLI 설치
  • 설치 가이드
  • 설치 후 aws configure 명령으로 환경 설정
• Eksctl 설치
  • Eksctl - Amazon EKS Cluster 구성을 위한 CLI 명령
  • 설치 가이드
• kubectl 설치
  • 설치 가이드
• Amazon EKS를 이용한 Cluster 구성
  • eksctl 명령 이용하여 Amazon EKS를 이용한 Cluster 구성

eksctl create cluster \
   --name k8s-demo \
   --region ap-northeast-2 \
   --with-oidc \
   --ssh-access \
   --ssh-public-key <aws--login-key> \
   --nodes 3 \
   --node-type t3.medium \
   --node-volume-size=20 \
   --managed

 

생성된 Cluster 삭제는 CloudFormation에서 진행

---

TIF

다음 주에는 CKA 자격증을 위한 수업과 간단한 미니 프로젝트가 진행된다고 하고,

그 다음 주부터는 보충 수업과 파이널 프로젝트를 병행한다.

 

책이나 블로그 등을 보면서 용어들만 봐도 머리가 아팠는데, 이제는 어느 정도 이해를 하면서 볼 수 있게 되었다.

 

 

2022. 10. 14 에 작성된 글입니다.