본문 바로가기

EKS/EKS Cluster

EKS Cluster 구축 - 4. Pod 배포하기

kubenetes는 사용자가 kubectl을 통해 API을 Kubernetes Mater Node에 콜하게 되면,

마스터노드는 yaml 파일을 가지고 정의된 대로 Object를 생성하고 Worker Node에 이를 구축하게 되는 형태입니다.

 

따라서 yaml파일 작성하는 방법에 대해 완벽하게 이해할 수록 좋습니다.

공식 다큐 링크들을 참고하시면 도움이 많이 됩니다.

https://kubernetes.io/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/

 

쿠버네티스 오브젝트 이해하기

 

kubernetes.io

https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md

 

kubernetes/community

Kubernetes community content. Contribute to kubernetes/community development by creating an account on GitHub.

github.com


간단하게 yaml에서 핵심 요소들이 무엇을 의미하는지 알아보도록 하겠습니다.

  • apiVersion - 이 오브젝트를 생성하기 위해 사용하고 있는 쿠버네티스 API 버전이 어떤 것인지
  • kind - 어떤 종류의 오브젝트를 생성하고자 하는지
  • metadata - 이름 문자열, UID, 그리고 선택적인 네임스페이스 를 포함하여 오브젝트를 유일하게 구분지어 줄 데이터
  • spec - 오브젝트에 대해 어떤 상태를 의도하는지

해당 요소들이 의미하는 바를 정확히 알아두면, 어디에 어떤 내용들이 들어가있는지 빠르게 파악 할 수 있습니다.

따라서 위의 내용은 꼭 숙지하시기를 바라며, 이제 구축한 Kubernetes에 서비스를 띄워보도록 하겠습니다.

 

먼저 AWS에서 네트워크 대역을 서브넷으로 나누고 라우팅을 통해 접근을 IP대역으로 구분을 했다면,

쿠버네티스에서는 Namespace를 통해서 구역을 나누고, Traffic에 대한 제한을 둘 수 있습니다.

 

먼저 다음과 같이 namespace.yaml을 만들어주겠습니다.

cat > namespace.yaml << EOF
apiVersion: v1
kind: Namespace
metadata:
  name: prd-api
EOF

 

그리고 실제 Container 이미지를 가져와서 Pod를 띄울 deployment.yaml을 정의해주겠습니다.

여기서 replicas는 띄워놓을 Pod수를 정의하는 것이며, 파드가 죽더라도 이 Repliacas 수에 맞게 다시 살아나게 됩니다.

cat > deployment.yaml << EOF
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: cb-test-api
  namespace: prd-api
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: cb-test-api
    spec:
      containers:
      - image: {account-number}.dkr.ecr.ap-northeast-2.amazonaws.com/cb-test-api:latest
        imagePullPolicy: Always
        name: cb-test-api       
        ports:
        - containerPort: 9000
EOF

 

마지막으로, 실제 트래픽을 외부에서 들여오게하기 위해 service.yaml을 정의해주겠습니다.

cat > service.yaml << EOF
apiVersion: v1
kind: Service
metadata:
  name: cb-test-api
  namespace: prd-api
spec:
  ports:
    - port: 80
      name: http
      protocol: TCP
  selector:
    app: cb-test-api
EOF

 

Service의 Type에 따라서 어떤 형태로 노출되는지가 정해집니다.

이에 대해서 간략하게 말씀드리면 다음과 같습니다. 저는 상위 세개만 사용하여서 구성하는 예제를 포스팅 할 예정입니다.

  • ClusterIP (기본값)
    클러스터 내에서 내부 IP 에 대해 서비스를 노출해준다. 이 방식은 오직 클러스터 내에서만 서비스가 접근될 수 있도록 해준다.
  • NodePort (ALB사용 시)
    NAT가 이용되는 클러스터 내에서 각각 선택된 노드들의 동일한 포트에 서비스를 노출시켜준다. 
    <NodeIP>:<NodePort>를 이용하여 클러스터 외부로부터 서비스가 접근할 수 있도록 해준다. CluserIP의 상위 집합이다.
  • LoadBalancer (CLB 사용 시)
    기존 클라우드에서 외부용 로드밸런서를 생성하고 서비스에 고정된 공인 IP를 할당해준다. NodePort의 상위 집합이다.
  • ExternalName (AWS ALB를 사용하실 경우 ingress.yaml에서 정의해 매핑시켜줍니다)
    이름으로 CNAME 레코드를 반환함으로써 임의의 이름(스펙에서 externalName으로 명시)을 이용하여 서비스를 노출시켜준다.
    프록시는 사용되지 않는다. 이 방식은 kube-dns 버전 1.7 이상에서 지원 가능하다.

자 이렇게 구성한 후 다음 CLI를 통해 Pod 및 서비스를 띄우고 체크해보도록 하겠습니다.

kubectl apply -f namespace.yaml
kubectl apply -f deployment.yaml
kubectl apply -f service.yaml
kubectl get all -n prd-api

 

 

그리고 위와 같이 화면이 띄워졌다면, 프록시를 통해 curl로 제대로 서비스가 구동되고 있는지 확인해보겠습니다.

kubectl port-forward cb-test-api-75f7fd5cf9-bqrts 9000:9000 -n prd-api

 

 

curl loaclhost:9000에서 아래와 같은 html이 보인다면, 정상적으로 서비스가 구동되고 있는 것 입니다.

 

 

다음 포스트부터는 각 카테고리별로 LoadBalancer, Route53-DNS 등등 여러 구성을 진행해보겠습니다.