[AWS EKS] AWS EKS 구축하기 -3

🚦시리즈로 구성됩니다.

2022.09.27 - [DevOps/[AWS]] - [AWS EKS] AWS EKS 구축하기 -1

2022.09.27 - [DevOps/[AWS]] - [AWS EKS] AWS EKS 구축하기 -2

 

INTRO

---

 

2편에서 노드 그룹을 생성하고 노드 2개가 활성화 된 것을 확인할 수 있었다.

이번 포스팅에서는 해당 노드에 dockerize된 이미지를 pod 로 올려볼것이고,

이를 위한 yaml 파일들 설정 방법에 대해 알아본다.

 

 

 

---

 

 

 

1.  namespace 생성

- 2편까지 진행했다면 현재까지 생성한 것들은 아래와 같다.

 1. 2개의 역할 생성(clusterRole, nodeRole)

 2. vpc생성(2개의 private subnet, 2개의 public subnet)

 3. 클러스터 생성

 4. 클러스터 제어를 위한 EC2 생성(aws cli, kubectl, kubeconfig로 연결)

 5. 1개의 node group과 2개의 node 생성

 

- 여기까지 진행되고, 아래 명령어를 입력하면 4개의 namespace를 확인할 수 있다.

$ kubectl get ns

 

-namespace란, 쿠버네티스에서 사용자, 네트워크, 저장공간등(총 6가지 정도 된다고 한다.)을 논리적으로 나누기 위해 사용되는 개념으로,

- AWS EKS에서는 최초 노드를 생성한 시점에 4개의 namespace가 생성된다.

 

- default 를 제외한 namespace들은 쿠버네티스의 전반적인 설정에 관련한 것들이므로, 가급적 건드리지 않는 것이 좋으며,

- 새로 namespace 를 생성할때에도 기본 namespace들의 naming rule(kube-)를 가급적 지양해야한다.

- 아래 명령어를 통해 실습에 필요한 namespace를 생성한다.

$ kubectl create ns demo-ns

 

2. 실습 환경을 위한 간략한 설명

- 하나의 도커 이미지를 아래와 같은 형상으로 배포해 볼 것이다.

출처 :https://kubernetes.io/docs/tutorials/kubernetes-basics/expose/expose-intro/

 

실제 실습해 볼 ingress를 쿠버네티스 홈페이지에서 가져온 이미지 옆에 추가했다.

 

 

 

- 대략적으로 위와 같은 AWS EKS 쿠버네티스 배포 환경을 구성하기 위해  4가지의 yaml 파일을 작성해 볼 것이다.

- app 이름은 편의상 demo로 하겠다.

- pod, deployment, service, ingress에 대한 개념들은 구글링을 하면 매우 자세하게 나와있으므로 실습 전에 공부를 조금 해보는 것을 추천한다.

 

1. 여러 개의 pod들을 관리하는 Deployment ( demo.yaml )

2. 기본 설정을 제공하는 Config Map( demo-cm.yaml )

3. 외부와 통신을 위한 ingress(기존 배포 환경에서의 Nginx 역할을 한다.) ( demo-ingress.yaml )

4. ingress로 연결 된 외부와의 통신을 pod들까지 도달할 수 있도록 해주는 service ( demo-svc.yaml )

 + 이외에도 EC2의 Volumn과 연결하여 persistence 하게 데이터를 저장할 수 있도록 하는 pvc 도 설정할 수 있으나 아직 실습을 해보지 못해봐서 건너뛰도록 하겠다...

 

 

3. yaml 작성

- yaml파일들은 계정 경로에 별도의 디렉토리 하나를 만들어서 모아놓자.

- 편의상 namespace 이름과 같은 디렉토리를 하나 생성했다.

ex) /home/ubuntu/demo-ns

- 편의상 nginx 이미지의 포트는 80으로 설정한다.

 

 

demo.yaml (Deployment)

- deployment는 replicaset 과 pod들이 있는 집합이라고 보면 된다.

출처 : https://kubernetes.io/ko/docs/concepts/workloads/controllers/deployment/

- metadata에 적힌 이름으로 deployment를 생성한다.

- app 이름은 demo 이다.

- spec은 deployment 를 구성하는 설정 값들을 선언하는 곳

- 컨테이너 이미지로 nginx:1.14.2 이미지를 사용할 것이다.

 

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo
  namespace: demo-ns
  labels:
    app: demo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo
  template:
    metadata:
      labels:
        app: demo
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: kubernetes.io/arch
                operator: In
                values:
                - amd64
                - arm64
      containers:
      - name: demo
        image: nginx:1.14.2
        ports:
        - name: http
          containerPort: 80
        imagePullPolicy: Always
        env:
          - name: PROFILE
            valueFrom:
              configMapKeyRef:
                name: demo-cm
                key: PROFILE

 

 

demo-cm.yaml (Config Map)

- configmap은 개발할 때 dev, prod와 같이 개발/운영 환경을 나누기 위해 환경변수 등을 사용하는 것과 같은 목적이다.

- 전역적으로 관리되는 항목들을 관리하기 위해 사용된다.

- 잘 사용하면 이식이 쉬워진다.

출처 : https://kubernetes.io/ko/docs/concepts/configuration/configmap/

apiVersion: v1
kind: ConfigMap
metadata:
  name: demo-cm
  namespace: demo-ns
data:
  PROFILE: dev

 

 

demo-ingress.yaml (Ingress)

- ingress는 외부에서 서비스로 접속하기 위해서 거쳐가는 역할을 한다.

- 외부로 URL을 노출시켜줘서 정상적인 외부 통신이 가능하게 한다.

출처 : https://kubernetes.io/ko/docs/concepts/services-networking/ingress/

- 공식 홈페이지의 설명으로는, ingress는 리소스 오브젝트만 있어서는 동작이 불가하고, ingress controller가 있어야 한다고 한다.

- AWS EKS에서는 이 역할을 AWS Application Load Balancer가 해준다.

- 따라서 ingress를 생성하면 알아서 로드밸런서가 생성되는 것을 볼 수 있다.

 

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: demo-ingress
  namespace: demo-ns
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
spec:
  rules:
  - http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: demo-svc
            port:
              number: 80

- annotations key 값이 EKS에서의 Application loadbalancer를 설정해주기 위한 값들이다.

- 위에서 ingress를 생성하면 알아서 로드밸런서가 생성된다고 했는데

- 이 기능을 작동하게 하기 위해서는 LoadBalancer Controller라는 것을 추가해줘야하고.

- 이걸 동작하게 하기 위해서 IAM Management 페이지에서 자격 증명 공급자를 설정해줘야한다.

 

ingress-1 : LoadBalancer Controller 추가

-https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/aws-load-balancer-controller.html

AWS Load Balancer Controller 추가 기능 설치 - Amazon EKS

- 우선 controller 설치를 위해 LoadBalancerControllerIAMPolicy 정책을 추가해줘야한다.

- 정책 설정이 담긴 .json 설치

$ curl -o iam_policy.json https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.4.3/docs/install/iam_policy.json

- .json 파일을 이용한 정책 생성

$ aws iam create-policy \
    --policy-name AWSLoadBalancerControllerIAMPolicy \
    --policy-document file://iam_policy.json

 

- 이후 가이드문서에서는 controller 설치를 2가지 방법으로 소개한다.

- 첫 번째는 helm을 이용한 설치

- 두 번째는 kubectl 을 이용한 설치이다.

- 두 번째 방법으로 시도했다가 클러스터를 다시 생성하는 불상사가 있었다..

(설치 후 ingress 를 apply 했더니 아래 오류 발생)

Internal error occurred: failed calling webhook "vingress.elbv2.k8s.aws": the server could not find the requested resource

- 원인은 정상적으로 설치가 되지 않아 AWS의 Loadbalancer와 정상적으로 연결되지 않은 것 같다.

- 로그나 이런걸 좀 봤어야했는데 무지성으로 클러스터와 관련 서비스들을 다 제거했다..

 

- Helm을 이용한 설치로 진행하겠다.

- 우선 Helm을 설치해야한다.

$ curl https://baltocdn.com/helm/signing.asc | sudo apt-key add -
$ echo "deb https://baltocdn.com/helm/stable/debian/ all main" | sudo tee /etc/apt/sources.list.d/helm-stable-debian.list
$ sudo apt-get install helm

- 이후 Helm저장소 등록

$ helm repo add eks https://aws.github.io/eks-charts

- 저장소 업데이트

$ helm repo update

- controller 설치

- 여기서 본인의 클러스터 이름, region , vpc-id를 입력해주자.

- 602401143452 라는 계정의 ECR에서 이미지를 받아와 설치하는 것으로 보인다.(AWS에서 쉬운 설치를 위해 제공하는 듯)

$ helm install aws-load-balancer-controller eks/aws-load-balancer-controller -n kube-system \
--set clusterName={cluster-name} \ 
--set serviceAccount.create=false \ 
--set serviceAccount.name=aws-load-balancer-controller \ 
--set image.repository=602401143452.dkr.ecr.{region}.amazonaws.com/amazon/aws-load-balancer-controller \
--set region={region} \
--set vpcid={클러스터 생성에 사용한 vpc-id}

- 설치 후 아래와 같이 로드밸런서 컨트롤러가 kube-system 이라는 네임스페이스에 deployment로 잘 떠있는 것을 확인할 수 있다.

$ kubectl get deployment -n kube-system

 

 

 

ingress-2: 자격 증명 공급자 추가 추가

- 우선 EKS 에 접속하여 본인의 클러스터의 Open ID Connection 공급자 URL을 복사해야 한다.

- EKS -> 클러스터 -> 개요 탭에 있다.

- IAM 에 자격증명공급자 탭 접속-> 자격증명공급자 추가

 

- OpenID Connect 선택 후 공급자 URL에 아까 복사해 온 OpenID를 입력하고 지문 가져오기

- 대상에는 sts.amazonaws.com 입력 후 공급자 추가 버튼 클릭

- 여기까지 진행했다면 이제 Ingress를 등록할 경우 로드밸런서까지 자동으로 생성되는 플로우를 탈 수 있다.

 

 

 

 

demo-svc.yaml (service)

- service는 pod 집합에서 실행되고있는 application 들을 외부로 노출시켜 주는 역할을 한다.

- ingress는 외부 인터넷과의 연결을 담당한다고 한다면,

- svc 는 application 들간의 연결 + Ingress와의 연결을 담당한다고 생각하면 될 것 같다.

- 일반적으로 app - app 통신이나 frontend - backend간 통신도 service를 통해 연결한다고 보면 된다.

출처 : https://kubernetes.io/ko/docs/concepts/services-networking/service/

 

apiVersion: v1
kind: Service
metadata:
  name: demo-svc
  namespace: demo-ns
spec:
  selector:
    app: demo
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

 

 

 

 

 

4.  Apply & Deploy

- 여기까지 진행했다면 pod들을 생성하고 배포할 준비가 된 것이다.

- 아래 명령어를 통해 kubernetes에 yaml들을 배포해보자

kubectl apply -f <yaml> -n <mamespace>

 

- configmap 배포

$ kubectl apply -f demo-cm.yaml -n demo-ns

configmap/demo-cm created

 

- 아래 명령어를 입력하면 현재 배포 된 configmap  object의 정보를 볼 수 있다.

- 또한 수정도 가능하다.

$ kubectl edit configmap -n demo-ns

 

 

 

 

- service 배포

$ kubectl apply -f demo-svc.yaml  -n demo-ns

service/demo-svc created

- 마찬가지로 아래 명령어를 입력하면 현재 배포 된 service object의 정보를 볼 수 있다.

- 또한 수정도 가능하다.

$ kubectl edit svc -n demo-ns

 

- ingress 배포

$ kubectl apply -f demo-ingress.yaml -n demo-ns

$ kubectl edit ingress -n demo-ns

- 마찬가지로 명령어를 입력하면 현재 배포 된 ingress object의 정보를 볼 수 있다.

- 또한 AWS console -> 로드밸런서에 접속해보면 로드밸런서 하나가 생성되고 있는 것을 볼 수 있다.

- 이제 이 로드밸런서를 통해 클러스터에 접속이 가능해진다.

 

- deployment 배포

$ kubectl apply -f demo.yaml -n demo-ns

$ kubectl edit deployment demo -n demo-ns

 

- 이제 deployment가 생성되고 application 들이 배포되기 시작한다.

- edit 명령어를 통해 deployment 를 확인해보면 replicaset 갯수, 정책 등을 확인할 수 있다.

 

 

 

5. application 접속해보기

- ingress 생성을 통해 생성된 loadbalancer 의 url로 접속해보자

- 이제 이 쿠버네티스 환경은 yaml에 작성한대로 pod/node들을 늘리거나 줄이면서

- 원활한 배포 환경을 제공할것이다.

 

 

 

 

마무리

여기까지 pod와 deployment, ingress, service 들을 생성해보았다.

다음 포스팅에서는 helm 을 연동하여 위에서 각각 작업한 배포환경들 apply를 일괄적으로 적용해 볼 것이다.

 

 

 

-퍼가실 때는 출처를 꼭 같이 적어서 올려주세요!