재밌는 Coding

1. 시험환경

    · AWS EKS : v1.30

    · kubectl : v1.33.2

    · aws-load-balancer-controller : v2.7.2

    · cert-manager : v1.13.5

2. 목적

    · AWS EKS 환경에서 aws-load-balancer-controller 설치시 활성화가 되지 않았던 문제를 해결한다.

3. 적용

    ① aws-load-balancer-controller 설치 후 kubectl 명령어로 deployment 상태 정보를 확인한다.

        - $ kubectl  get  deployment  -n  kube-system  aws-load-balancer-controller

    ② pod의 status 정보를 확인한다.

        - $ kubectl  get  pods  -n  kube-system  -l  app.kubernetes.io/name=aws-load-balancer-controller

        - 6번 재시작 후 CrashLoopBackOff 상태로 비활성화 상태임을 확인할 수 있다.

    ③ pod 로그 정보를 확인한다.

        - $ kubectl  logs  -n  kube-system  [pod-name]

        - "--aws-vpc-id" 파라미터를 명시하라는 로그를 확인 하였다.

    ④ 배포된 pod의 편집모드로 진입하여 "--aws-vpc-id" 파라미터를 추가 및 적용한다.

        - $ kubectl edit deployment -n kube-system aws-load-balancer-controller

4. 결과

    · 서비스 배포 상태를 다시 확인한다.

        - $ kubectl  get  deployment  -n  kube-system  aws-load-balancer-controller

1. 시험환경

    · AWS EKS

    · kubectl

2. 목적

    · AWS EKS 환경에서 Application 배포시 발생한 에러를 확인하는 명령어를 알아보자.

3. 적용

    ① pod 로그 확인을 위한 kubectl 명령어

        - kubectl  logs  -n  [namespace]  [pod]

        예시) kubectl  logs  -n  kube-system  deploy/aws-load-balancer-controller

    ② deployment 상태 확인을 위한 kubectl 명령어

        - kubectl  describe  deployment  -n  [namespace]  [pod]

        예시) kubectl  describe  deployment  -n  kube-system  aws-load-balancer-controller

    ③ ReplicaSet 및 Pods 상태 확인을 위한 kubectl 명령어

        - kubectl  get  replicaset  -n  [namespace]  -l  app.kubernetes.io/name=aws-load-balancer-controller
        - kubectl  describe  pod  -n  kube-system  [pod-name]

    ④ 특정 namespace(deployment, ReplicaSet 및 Pods)에서 발생하는 이벤트 로그 확인을 위한 kubectl 명령어

        - kubectl  get  events  -n  [namespace]

        예시) kubectl  get  events  -n  kube-system  

1. 시험환경

    ˙ AWS EKS

    ˙ AWS Web Console

2. 목적

    ˙ AWS 웹 콘솔에 접속하여 EKS Cluster를 설치한다.

3. 적용

    ① EKS Control Plane에서 사용할 역할(Role)을 생성한다.

        - 참고 : https://languagestory.tistory.com/275

    ② EKS Control Plane에서 사용할 보안그룹(Security Group)을 생성한다.

        - 참고 : https://languagestory.tistory.com/277

    ③ EKS Cluster 이름 / 버전 / 역할 등 구성정보를 입력한다.

    ④ EKS NodeGroup이 위치할 VPC / 서비스 / 보안그룹 등을 설정한다.

        - 서브넷은 반드시 2개의 이상의 Multi AZ로 구성해야 EKS Cluster가 생성된다.

        - production에서는 보통 private Subnet으로 운영한다.
        - 여기서는, 테스트 목적이므로 public subnet 사용한다.

    ⑤ EKS Cluster 엔드포인트를 설정한다.

        - EKS ControlPlane ENI를 "Public Subnet"으로 설정한 경우,

        - "퍼블릭 및 프라이빗"으로 허용하는 것이 NodeGroup과 통신할 때 원활하다.

    ⑥ 로깅을 구성한다.

        - ControlPlane의 로그를 CloudWatch로 전송 설정

        - EKS Cluster가 생성되면 Container를 배포하고 실행시키는 Data-Plane 뿐만 아니라,
        - EKS Cluster를 기동 및 운영하기 위한 요소들이 AWS에서 자체적으로 관리되어 사용자들에게는 접속 및 접근이 제한된

           Control-Plane 영역으로 분리 되어 있다.

        - Control-Plane에서 장애가 발생하면 AWS에서 자동적으로 조치되는 경우도 있지만,
           일반 사용자는 조치가 어렵기 때문에 AWS에 Case-Open 요청을 위해 로깅 부분을 활성화한다.

        - 여기서는 비용 문제로 비활성화 상태로 설정한다.

    ⑦ 추가 기능을 선택한다.

    ⑧ 선택한 추가기능의 버전을 선택한다.

    ⑨ 현재까지 구성한 설정정보 검토 및 EKS Cluster를 생성한다.

    ⑩ EKS Cluster 생성을 완료하려면 10분 이상 소요된다.

4. 결과

    ˙ EKS Cluster가 활성화된 것을 확인한다.

1. 시험환경

    ˙ AWS EKS

    ˙ AWS Web Console

2. 목적

    ˙ AWS EKS Cluster 설치를 위한 사전 작업을 준비한다.

    ˙ EKS Cluster의 Control Plane이 사용할 Service Role 생성한다.

    ˙ 생성한 IAM Service Role에 정책(policy)을 부여한다.

         - arn:aws:iam::aws:policy/AmazonEKSClusterPolicy
         - arn:aws:iam::aws:policy/AmazonEKSVPCResourceController

3. 적용

    ① IAM 역할을 생성한다.

    ② 신뢰할 수 있는 엔터티 유형을 설정한다.

        - 방법 1) "AWS 서비스" → 사용 사례로 "EKS" 선택

        - 방법 2) "사용자 지정 신뢰 정책" → 직접 입력

    ③ EKS 선택시 기본적으로 추가된 Policy를 확인한다.

    ④ Role 이름을 부여한다.

    ⑤ 생성된 역할(Role)을 클릭한다.

    ⑥ "정책(policy) 연결"을 클릭한다.

    ⑦ "AmazonEKSVPCResourceController" 정책을 추가한다.

4. 결과

    ˙ 역할에 부여된 정책(policy)을 확인한다.

        - arn:aws:iam::aws:policy/AmazonEKSClusterPolicy
        - arn:aws:iam::aws:policy/AmazonEKSVPCResourceController