'Server/AWS'에 해당하는 글 40건

EKS 무중단 배포

Server/AWS 2022. 1. 11. 19:57

 

$ kubectl get pods -o wide -w -n exapi
NAME                         READY   STATUS    RESTARTS   AGE   IP            NODE                                                     NOMINATED NODE                                READINESS GATES
oauth-b88bb75fb-cbpfb        1/1     Running             0          12m     10.1.19.219   fargate-ip-10-1-19-219.ap-northeast-2.compute.internal   <none>                                        1/1
oauth-b88bb75fb-cbpfb        1/1     Running             0          12m     10.1.19.219   fargate-ip-10-1-19-219.ap-northeast-2.compute.internal   <none>                                        1/1
oauth-b88bb75fb-zx68l        1/1     Running             0          9m47s   10.1.27.53    fargate-ip-10-1-27-53.ap-northeast-2.compute.internal    <none>                                        1/1
oauth-b88bb75fb-zx68l        1/1     Running             0          9m47s   10.1.27.53    fargate-ip-10-1-27-53.ap-northeast-2.compute.internal    <none>                                        1/1
oauth-6889b9d9d8-89f8d       0/1     Pending             0          0s      <none>        <none>                                                   <none>                                        0/1
oauth-6889b9d9d8-89f8d       0/1     Pending             0          1s      <none>        <none>                                                   3e4a3b4284-f3a1e8e9245847e19d248aa203cec099   0/1
oauth-6889b9d9d8-89f8d       0/1     Pending             0          65s     <none>        fargate-ip-10-1-22-204.ap-northeast-2.compute.internal   3e4a3b4284-f3a1e8e9245847e19d248aa203cec099   0/1
oauth-6889b9d9d8-89f8d       0/1     ContainerCreating   0          65s     <none>        fargate-ip-10-1-22-204.ap-northeast-2.compute.internal   <none>                                        0/1
oauth-6889b9d9d8-89f8d       1/1     Running             0          100s    10.1.22.204   fargate-ip-10-1-22-204.ap-northeast-2.compute.internal   <none>                                        0/1
oauth-6889b9d9d8-89f8d       1/1     Running             0          101s    10.1.22.204   fargate-ip-10-1-22-204.ap-northeast-2.compute.internal   <none>                                        0/1
oauth-6889b9d9d8-89f8d       1/1     Running             0          102s    10.1.22.204   fargate-ip-10-1-22-204.ap-northeast-2.compute.internal   <none>                                        0/1
oauth-6889b9d9d8-89f8d       1/1     Running             0          2m11s   10.1.22.204   fargate-ip-10-1-22-204.ap-northeast-2.compute.internal   <none>                                        0/1
oauth-6889b9d9d8-89f8d       1/1     Running             0          3m34s   10.1.22.204   fargate-ip-10-1-22-204.ap-northeast-2.compute.internal   <none>                                        1/1
oauth-6889b9d9d8-89f8d       1/1     Running             0          3m34s   10.1.22.204   fargate-ip-10-1-22-204.ap-northeast-2.compute.internal   <none>                                        1/1
oauth-b88bb75fb-zx68l        1/1     Terminating         0          14m     10.1.27.53    fargate-ip-10-1-27-53.ap-northeast-2.compute.internal    <none>                                        1/1
oauth-6889b9d9d8-89f8d       1/1     Running             0          3m34s   10.1.22.204   fargate-ip-10-1-22-204.ap-northeast-2.compute.internal   <none>                                        1/1
oauth-6889b9d9d8-8n2mf       0/1     Pending             0          0s      <none>        <none>                                                   <none>                                        0/1
oauth-6889b9d9d8-8n2mf       0/1     Pending             0          1s      <none>        <none>                                                   16625974aa-a093eb0abc954f958086de0c456c0ea2   0/1
oauth-b88bb75fb-zx68l        0/1     Terminating         0          14m     10.1.27.53    fargate-ip-10-1-27-53.ap-northeast-2.compute.internal    <none>                                        1/1
oauth-b88bb75fb-zx68l        0/1     Terminating         0          14m     10.1.27.53    fargate-ip-10-1-27-53.ap-northeast-2.compute.internal    <none>                                        1/1
oauth-b88bb75fb-zx68l        0/1     Terminating         0          14m     10.1.27.53    fargate-ip-10-1-27-53.ap-northeast-2.compute.internal    <none>                                        1/1
oauth-6889b9d9d8-8n2mf       0/1     Pending             0          50s     <none>        fargate-ip-10-1-18-160.ap-northeast-2.compute.internal   16625974aa-a093eb0abc954f958086de0c456c0ea2   0/1
oauth-6889b9d9d8-8n2mf       0/1     ContainerCreating   0          50s     <none>        fargate-ip-10-1-18-160.ap-northeast-2.compute.internal   <none>                                        0/1
oauth-6889b9d9d8-8n2mf       1/1     Running             0          85s     10.1.18.160   fargate-ip-10-1-18-160.ap-northeast-2.compute.internal   <none>                                        0/1
oauth-6889b9d9d8-8n2mf       1/1     Running             0          86s     10.1.18.160   fargate-ip-10-1-18-160.ap-northeast-2.compute.internal   <none>                                        0/1
oauth-6889b9d9d8-8n2mf       1/1     Running             0          87s     10.1.18.160   fargate-ip-10-1-18-160.ap-northeast-2.compute.internal   <none>                                        0/1
oauth-6889b9d9d8-8n2mf       1/1     Running             0          116s    10.1.18.160   fargate-ip-10-1-18-160.ap-northeast-2.compute.internal   <none>                                        0/1
oauth-6889b9d9d8-8n2mf       1/1     Running             0          3m19s   10.1.18.160   fargate-ip-10-1-18-160.ap-northeast-2.compute.internal   <none>                                        1/1
oauth-6889b9d9d8-8n2mf       1/1     Running             0          3m19s   10.1.18.160   fargate-ip-10-1-18-160.ap-northeast-2.compute.internal   <none>                                        1/1
oauth-6889b9d9d8-8n2mf       1/1     Running             0          3m19s   10.1.18.160   fargate-ip-10-1-18-160.ap-northeast-2.compute.internal   <none>                                        1/1
oauth-b88bb75fb-cbpfb        1/1     Terminating         0          20m     10.1.19.219   fargate-ip-10-1-19-219.ap-northeast-2.compute.internal   <none>                                        1/1
oauth-b88bb75fb-cbpfb        0/1     Terminating         0          20m     10.1.19.219   fargate-ip-10-1-19-219.ap-northeast-2.compute.internal   <none>                                        1/1
oauth-b88bb75fb-cbpfb        0/1     Terminating         0          20m     10.1.19.219   fargate-ip-10-1-19-219.ap-northeast-2.compute.internal   <none>                                        1/1
oauth-b88bb75fb-cbpfb        0/1     Terminating         0          20m     10.1.19.219   fargate-ip-10-1-19-219.ap-northeast-2.compute.internal   <none>                                        1/1

 

자알 돌아간다~ 정상적인 것처럼 보이나...

 

 

 

다른분들 시간 낭비하지 않도록 결론부터 얘기한다. 무중단 배포 실패!

EKS 에서 Rolling update 가 무중단 배포가 아니라니... 겉보기에는 잘 작동하는 것처럼 보이나 배포시 약 5초간 502 Gateway Error 뒤에 504 Gateway Time-out 이 발생한다. 후... 

 

우선 502 에러가 발생하는 시점을 찾아봤다.

 

쿠버네티스에서 kubectl rollout restart 명령으로 배포할 경우, 새 pod 가 추가되고 Running 상태가 되면 기존 포드가 삭제되는 식이다. 확인 결과 pod 가 Terminating 되는 순간에 502 에러가 발생했다. ALB 의 Target 이 동시에 draining 되는 시점이기도 하다. 인터넷을 후벼파본 결과, 502 에러를 최소화 할 수 있는 몇가지 방법만 있을 뿐. 완벽한 무중단배포는 결국 찾지 못했다.

 

 

 

502 Gateway Error / 504 Gateway Time-out Error 최소화

 

1. ingress : connection-draining 설정

 

ALB 에 connection-draining 관련 옵션을 주어 기존 연결에 대한 처리를 유지한다. (이미 기본값으로 동작중. 효과없음.)

 

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  ...
  annotations:
    ...
    service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled: "true"
    service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout: "30"

 

 

2. pod : readiness-gate 설정

 

readiness-gate 옵션을 활성화 하여 새로운 target 이 healthy 상태로 연결되기 전까지 기존 target 을 종료하지 않음. (마찬가지로 502 에러는 발생하나, ALB 내의 target 이 healthy 상태가 한개도 유지되지 않는 어이없는 상황은 막을 수 있음). 반드시 필요!

 

$ kubectl label namespace {mynamespace} elbv2.k8s.aws/pod-readiness-gate-inject=enabled

 

apiVersion: apps/v1
kind: Deployment
metadata:
spec:
  template:
    spec:
      containers:
      - name: api
      readinessGates:
      - conditionType: target-health.alb.ingress.k8s.aws/api-ingress_api-nodeport_80

 

readiness-gate 옵션을 활성화할 namespace 에 레이블을 설정하고, target-health.alb.ingress.k8s.aws/{ingress-name}_{service-name}_{port} 를 위처럼 삽입한다. 설정이 올바르지 않으면 ALB 에서 target 그룹을 인식하지 못할 수도 있으니 주의!

 

 

3. pod : preStop 설정

 

life-cycle hooks 에서 pod 가 중지되기 전에(preStop) 딜레이를 가지며 기존 연결을 마저 처리한다. 새로운 연결을 이루어지지 않는다. (가장 좋아요가 많으나, 502 에러는 마찬가지임)

 

kind: Deployment
spec:
  ...
  template:
    ...
    spec:
      containers:
      - name: api
        lifecycle:
          preStop:
            exec:
              command: ["sleep", "60"]

 

 

4. pod : terminationGracePeriodSeconds 설정

 

preStop 가 실패했을 때 대신 컨테이너를 종료시킨다. (502 에러 변함없음)

 

kind: Deployment
spec:
  ...
  template:
    ...
    spec:
      containers:
      - name: web-api
      ...
      terminationGracePeriodSeconds: 70

 

 

5. pod livenessProbe / readinessProbe 설정

 

pod 의 활성화 상태를 나타내는 livenessProbe 가 실패하면 재시작 정책의 대상이 된다. pod 준비 상태를 나타내는 readinessProbe 가 실패하면 해당 pod 는 모든 엔드포인트에서 제거된다. (두 방법 모두 비정상 pod 에 연결을 못받게 하여 502 에러를 줄인다고는 하는데 효과는 잘 모르겠음.)

 

kind: Deployment
spec:
  ...
  template:
    ...
    spec:
      containers:
      - name: api
      ...
        livenessProbe:
          httpGet:
            path: /
            port: 80
          periodSeconds: 4
          timeoutSeconds: 5
          failureThreshold: 3
        readinessProbe:
          httpGet:
            path: /
            port: 80
            scheme: HTTP
          initialDelaySeconds: 30
          periodSeconds: 10

 

 


 

정리

 

이 정도가 구글링 싹다 한 결과이다. 말 그대로 502 에러가 발생할 확률을 줄여주는 것이지, 지금 내 상황을 해결해 줄 것들은 아니다. 물론 잘된다는 사람도 있긴한데 믿음이 가진 않고...; 다시 한번 정리하자면,

 

ALB draning = POD terminating

pod 가 먼저 terminating 상태에 돌입하고, 그를 인지한 로드밸런서가 draning 상태로 변경하는데 이미 로드밸런서를 통과한 연결이 terminating 인 pod 를 만나 에러가 발생했고, 그 상황을 방지하기 위해 나는 preStop hook 로 실질적인 terminating 을 딜레이 시켰는데 쌩까고 502 에러가 계속 난다는...

 

그나마 건진건 readiness-gate 하나. 거의 이틀동안 rolling update 로 테스트해 볼만한건 다 해봤다. 그나마 이틀만에 이렇게 포기할 수 있게 해줘서 감사할따름. EKS 를 사용하는 모든 사용자들이 502 를 마주하지는 않을텐데, rolling update 를 손절해야 하나. 하... 모르겠다...

 

 

 


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

EKS ingress https

Server/AWS 2021. 12. 28. 23:37

EKS 에서 http 를 https 로 리다이렉트 시켜주는 ALB 가 필요하다면, 아래와 같은 ingress 를 구성한다.

 - 사전에 ACM 의 인증서 arn 이 필요하다.

 

$ vi ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  namespace: example
  name: example-ingress
  annotations:
    # Ingress Core Settings
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/target-group-attributes: stickiness.enabled=true,stickiness.lb_cookie.duration_seconds=60
    # SSL Settings
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS":443}]'
    alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:ap-northeast-2:111122223333:certificate/11fceb32-9cc2-4b45-934f-c8903e4f9e12
    alb.ingress.kubernetes.io/ssl-redirect: '443'
spec:
  rules:
    - http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: example-nodeport
                port:
                  number: 80

 

기존 http 구성에 # SSL Setting 아래 3줄만 추가하였음.

기존 ingress 삭제하고 다시 생성.

 

$ kubectl delete -f ingress.yaml
ingress.networking.k8s.io "example-ingress" deleted

$ kubectl apply -f ingress.yaml
ingress.networking.k8s.io/example-ingress created

 

alb-redirect

 

 


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

CodeBuild / CodePipeline

Server/AWS 2021. 12. 18. 00:09

aws-eks-ci-cd

 

EKS 에서의 CI / CD 를 고민중이다. AWS 리소스만을 이용하는 방법, 범용적인 CI/CD 를 사용하는 방법... ArgoCD, TerraForm, Jenkins 등 뭐가 많지만 되도록 AWS 리소스를 사용해 보기로 했다. 예전에 ECS 배포할 때는 gradle 에서 Docker 이미지 생성 / ECR 업로드 / 배포까지... 전부 해결했었다. 로컬에서 태스크만 실행하면 되니 build.gradle 만 기다랗게 작성하는 것 빼고는 별 문제가 없었다. 그 때의 애로사항은 배포하려는 개발자의 PC 에 Docker 가 실행되고 있어야 한다는 점. ECR 인증키가 git 에 포함된다는 점. 배포시 오류가 발생한다면 즉시 파악이 어려운 점... 트집을 잡자면 그 정도. 하지만 대부분의 개발자가 docker 를 사용하고, git 도 프라이빗, 배포시 오류는 알림으로 처리했었고... 라며 흡족하게는 썼었지만, 이번엔 왠지 도구를 이용해야만 할 것 같은 느낌적인 느낌. 시간 있으면 이것저것 다 써보는게 좋은거지. 싶어서 CodeCommit, CodeBuild, CodePipeline 을 사용해 보았다.

 

 

사용할 AWS CI/CD Resource

 

  • CodeCommit
    - git 저장소 / 소스 위치
  • CodeBuild
    - 소스코드를 가져와 Test/Build 실행.
    - 자체 컴퓨팅으로 docker 이미지 생성, ECR 이미지 업로드, EKS 배포에 관한 빌드사양 파일 작성(buildspec.yml)
  • CodePipeline
    - git 저장소에 소스코드 변경이 감지되었을 때, source 아티팩트 S3 업로드 후 CodeBuild 실행

 

 

CodeBuild 생성

 

AWS 관리콘솔에서 빌드 프로젝트 만들기

  • 관리형 이미지 컴퓨팅 선택
  • 역할 이름 : 여러 빌드 프로젝트를 관리한다면 하나로 재사용
  • 권한이 있음(privileged) : 도커 이미지를 빌드하거나 빌드의 권한을 승격시 필요
  • VPC / 컴퓨터 유형 선택 : 빌드 성능 결정
  • 환경 변수 : buildspec 에 노출하고 싶지 않은 키/값 지정
  • Buildspec 이름 : 실제 buildspec 파일의 경로 지정
  • 캐시 유형 : 로컬 (DockerLayerCache, SourceCache, CustomCache)
  • 나머지 기본값

 

 

buildspec.yml 파일 작성

 

빌드 프로젝트 생성시 설정한 경로에서 buildspec.yml 를 작성한다. 기본적으로 4개의 페이즈가 있다.

  • install : 빌드 환경 구성
  • pre_build : 빌드에 필요한 ECR 로그인이나 패키지 종속성 설치 등
  • build : 빌드 실행
  • post_build : 빌드 결과물 처리, ECR 이미지 푸시, 빌드 알림 등

 

페이즈 마다의 규칙이 있지는 않지만, 추후 구간별 처리 속도를 알 수 있으므로 구분하여 사용자 정의.

 

$ vi buildspec.yml

version: 0.2

phases:
  install:
    runtime-versions:
      java: corretto11
    commands:
      - curl -o kubectl https://amazon-eks.s3-us-west-2.amazonaws.com/1.21.2/2021-07-05/bin/linux/amd64/kubectl
      - chmod +x ./kubectl
      - mv ./kubectl /usr/local/bin/kubectl
      - aws --version
      - aws eks update-kubeconfig --region ap-northeast-2 --name example-cluster
      - kubectl get po -n exapi
  pre_build:
    commands:
      - echo pre_build Logging in to Amazon ECR...
      - $(aws ecr get-login --region $AWS_DEFAULT_REGION --no-include-email)
      - REPOSITORY_URI=${REPO_ECR}
      - COMMIT_HASH=$(echo $CODEBUILD_RESOLVED_SOURCE_VERSION | cut -c 1-7)
      - IMAGE_TAG=${COMMIT_HASH:=latest}
  build:
    commands:
      - echo Build started on `date`
      - gradle --version
      - chmod +x gradlew
      - ./gradlew :ApiFacility:build
      - docker build -t $REPOSITORY_URI:latest ./Api
      - docker tag $REPOSITORY_URI:latest $REPOSITORY_URI:$IMAGE_TAG
  post_build:
    commands:
      - echo Build completed on `date`
      - echo Pushing the Docker images...
      - docker push -a $REPOSITORY_URI
      #- kubectl apply -f ./AWS/example-deployment.yaml
      - kubectl rollout restart -f ./AWS/example-deployment.yaml

 

위에 정의한 사양은,

  • install : 자바환경, kubectl 설치, kubeconfig 구성
  • pre_build : ECR 로그인, ECR 경로, 이미지 태그명 정의
  • build : gradle 빌드, docker 이미지 생성
  • post_build : ECR 이미지 푸시, eks deployment 롤링 업데이트

 

또한, 위 사양처럼 REPO_ECR 등의 프라이빗 정보들은 빌드 프로젝트 구성시 환경변수로 지정한 변수명으로 사용할 수 도 있다. echo 나 이미지 태깅 관리 때문에 조금 길어지긴 했는데 필요에 맞게 사용자 정의...

 

 

CodePipeline 생성

 

AWS 관리콘솔에서 파이프라인 생성

  • 역할 이름 : 여러 파이프라인을 관리한다면 하나로 재사용
  • 아티팩트가 업로드 될 버킷 위치 수동 지정시
  • 소스 스테이지 : CloudWatch 로 변경 감지, 출력 아티팩트 형식은 기본값을 사용하여 zip 형식의 데이터를 사용해도 무방하지만 간단히 메타데이터만 전달하는 전체 복제 선택.(gitpull 권한 추가 필요)
  • 빌드 스테이지 추가 후 배포 스테이지 건너뛰기

 

 

배포 테스트

 

CodePipeline 이 생성되면 즉시 실행이 되는데, 아니면 수동으로 빌드하던지, git 소스를 푸시하던지... 해서 배포 롤링 업데이트 확인까지. 이제부터는 에러의 향연이다. CodeBuild 의 플로우를 보면 거의 모든 단계에 해당 리소스에 대한 권한이 필요하므로 생성한/된 codebuildrole 에 각 권한을 추가해 주면 된다. 

 

[에러 모음 링크]

 

마치 일부러 에러를 찾아내려는 듯한 치밀한 실수들이 많았다; awscli 버전이 1.2 라 추후 문제가 있을수도 있지 않을까 하는 걱정도 되고... CodeCommit, CodeBuild, CodePipeline, ECR, EKS 등 AWS 리소스 만으로 CI/CD 를 구성해 본 느낌은... 그냥 그렇다.ㅋ 뭔가 자동화 스러우면서도, 관리 포인트가 점점 늘어나는 찝찝한 느낌... 남은건 구성 완료에 대한 약간의 성취감? ㅋ


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

CodeBuild error

Server/AWS 2021. 12. 17. 22:56

 

CodeBuild 빌드 중에 발생한 에러 모음이다.

 

빌드 프로젝트 구성 validation

: 빌드 프로젝트 새로 구성시 한번이라도 validation 에 실패하면 재검증시 터무니없는 메시지가 출력됨. 사실 권한 및 정책이 검증과정에서 이미 생성되는데 같은 이름의 권한 및 정책이 존재한다는 메시지가 올바르나... 아무튼 자동 생성된 권한 및 정책을 삭제해도 마찬가지이고... 권한 및 삭제 뒤 빌드 프로젝트를 한번에 새로 구성하면 해결; (한번이라도 검증 실패시 아래 메시지 조우)

 

서비스 역할 이름이 잘못되었습니다. 유효한 문자는 꼬부랑꼬부랑 !@#$ㄲㅉㄸㄲㅉ

 

 

S3 소스 다운로드시 권한 없음

: AmazonS3ReadOnlyAccess 권한 추가로 해결

 

Waiting for DOWNLOAD_SOURCE
AccessDenied: Access Denied
    status code: 403, request id: VX7AKNM69P3N7123, host id: 123y3WpjIvTzVViVzHclfn4F3UfDg4mJA++8BSY6q0jQyEPCWr4cohc0dVJ+q08N/123LMNToEI= for primary source and source version arn:aws:s3:::source-artifact-temp/example/SourceArti/BwUEum1

 

 

buildspec.yml 경로 에러 발생

: 경로 확인으로 해결

 

Phase context status code: YAML_FILE_ERROR Message: stat /codebuild/output/src123816321/src/git-codecommit.ap-northeast-2.amazonaws.com/v1/repos/example/Api/buildspec.yml: no such file or directory

 

 

ecr 로그인 에러

: AmazonEC2ContainerRegistryPowerUser 권한 추가로 해결

 

Running command aws --version
aws-cli/1.20.58 Python/3.9.5 Linux/4.14.252-195.483.amzn2.x86_64 exec-env/AWS_ECS_EC2 botocore/1.21.58

Running command $(aws ecr get-login --region $AWS_DEFAULT_REGION --no-include-email)

An error occurred (AccessDeniedException) when calling the GetAuthorizationToken operation: User: arn:aws:sts::123151105123:assumed-role/exampleCodeBuildServiceRole/AWSCodeBuild-ccf3e123-4123-4123-9ba1-1231fc6797b8 is not authorized to perform: ecr:GetAuthorizationToken on resource: * because no identity-based policy allows the ecr:GetAuthorizationToken action

Command did not exit successfully $(aws ecr get-login --region $AWS_DEFAULT_REGION --no-include-email) exit status 255
Phase complete: PRE_BUILD State: FAILED
Phase context status code: COMMAND_EXECUTION_ERROR Message: Error while executing command: $(aws ecr get-login --region $AWS_DEFAULT_REGION --no-include-email). Reason: exit status 255

 

 

gradle 구문 에러

: 기본 gradle 버전 호환 오류로 스크립트 수정으로 해결 gradle build -> ./gradlew build

 

Running command gradle --version
------------------------------------------------------------
Gradle 5.6.4
------------------------------------------------------------
...
* What went wrong:
An exception occurred applying plugin request [id: 'org.springframework.boot', version: '2.6.0']
> Failed to apply plugin [id 'org.springframework.boot']
   > Spring Boot plugin requires Gradle 6.8.x, 6.9.x, or 7.x. The current version is Gradle 5.6.4

Command did not exit successfully gradle :Api:build exit status 1
Phase complete: BUILD State: FAILED
Phase context status code: COMMAND_EXECUTION_ERROR Message: Error while executing command: gradle :Api:build. Reason: exit status 1

 

 

Dockerfile 경로 에러

: 경로 수정으로 해결 . -> ./AWS/Dockerfile

 

Running command docker build -t $REPOSITORY_URI:latest .
unable to prepare context: unable to evaluate symlinks in Dockerfile path: lstat /codebuild/output/src368940192/src/git-codecommit.ap-northeast-2.amazonaws.com/v1/repos/kps/Dockerfile: no such file or directory

 

 

eks cluster 조회 권한 에러

: AmazonEKSWorkerNodePolicy 권한 수정 및 바인딩 추가로 해결

 

Running command aws eks update-kubeconfig --region ap-northeast-2 --name example

An error occurred (AccessDeniedException) when calling the DescribeCluster operation: User: arn:aws:sts::123151105123:assumed-role/exampleCodeBuildServiceRole/AWSCodeBuild-123e955a-545c-42c6-8d21-67215aef0123 is not authorized to perform: eks:DescribeCluster on resource: arn:aws:eks:ap-northeast-2:123151105123:cluster/example

Command did not exit successfully aws eks update-kubeconfig --region ap-northeast-2 --name example exit status 255
Phase complete: INSTALL State: FAILED
Phase context status code: COMMAND_EXECUTION_ERROR Message: Error while executing command: aws eks update-kubeconfig --region ap-northeast-2 --name example. Reason: exit status 255

 

 

kubectl 권한 에러

: 사용자나 역할에 대한 aws-auth ConfigMap 수정으로 해결

 

Running command kubectl get po -n namespace1
error: You must be logged in to the server (Unauthorized)

Command did not exit successfully kubectl get po -n namespace1 exit status 1
Phase complete: INSTALL State: FAILED
Phase context status code: COMMAND_EXECUTION_ERROR Message: Error while executing command: kubectl get po -n namespace1. Reason: exit status 1
Error from server (Forbidden): error when retrieving current configuration of:
Resource: "apps/v1, Resource=deployments", GroupVersionKind: "apps/v1, Kind=Deployment"
Name: "my-deploy", Namespace: "namespace1"
from server for: "./AWS/example-deployment.yaml": deployments.apps "my-deploy" is forbidden: User "system:node:AWSCodeBuild-fccb1123-1235-49c9-1238-b11cf05bc0c8" cannot get resource "deployments" in API group "apps" in the namespace "namespace1"
Running command kubectl rollout restart -n example-namespace deployment my-deploy
error: failed to patch: deployments.apps "my-deploy" is forbidden: User "system:node:AWSCodeBuild-a0f27123-b1fc-4e12-1e3f-0eac123f5123" cannot patch resource "deployments" in API group "apps" in the namespace "namespace1"

Command did not exit successfully kubectl rollout restart -n namespace1 deployment my-deploy exit status 1
Phase complete: POST_BUILD State: FAILED
Phase context status code: COMMAND_EXECUTION_ERROR Message: Error while executing command: kubectl rollout restart -n namespace1 deployment my-deploy. Reason: exit status 1

 

- codebuild 에 사용된 역할 추가

$ kubectl edit configmap aws-auth -n kube-system

mapRoles: |
...
  - rolearn: arn:aws:iam::123151105123:role/exampleCodeBuildServiceRole
    username: system:node:{{SessionName}}
    groups:
    - system:bootstrappers
    - system:nodes
    - eks-console-dashboard-full-access-group

 

- 클러스터 역할 바인딩 생성

$ vi eks-console-full-access.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: eks-console-dashboard-full-access-clusterrole
rules:
- apiGroups:
  - ""
  resources:
  - nodes
  - namespaces
  - pods
  verbs:
  - get
  - list
  - patch
- apiGroups:
  - apps
  resources:
  - deployments
  - daemonsets
  - statefulsets
  - replicasets
  verbs:
  - get
  - list
  - patch
- apiGroups:
  - batch
  resources:
  - jobs
  verbs:
  - get
  - list
  - patch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: eks-console-dashboard-full-access-binding
subjects:
- kind: Group
  name: eks-console-dashboard-full-access-group
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: eks-console-dashboard-full-access-clusterrole
  apiGroup: rbac.authorization.k8s.io

 

$ kubectl apply -f eks-console-full-access.yaml
clusterrole.rbac.authorization.k8s.io/eks-console-dashboard-full-access-clusterrole created
clusterrolebinding.rbac.authorization.k8s.io/eks-console-dashboard-full-access-binding created

 

 

codebuild

 


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

aws-alb

 

AWS 로드 밸런서 컨트롤러로부터 생성/관리 되는 로드 밸런서: NLB / ALB

 

NLB(Network Load Balancing)

 

  • 네트워크 트래픽을 OSI 모델의 L4 에서 로드 밸런싱
  • k8s 에서 LoadBalancer 타입의 Service 생성시 프로비저닝됨
  • 초당 수백만 개의 요청 처리 가능
  • 고정 IP 등록 가능
  • IP / Port 지정으로 타겟그룹 등록 가능

 

ALB(Application Load Balancing)

 

  • 어플리케이션 트래픽을 OSI 모델의 L7 에서 로드 밸런싱
  • k8s 에서 ingress 리소스 생성시 프로비저닝됨
  • 여러 도메인, 호스트, 경로 기반의 라우팅 가능
  • 한 URL에서 다른 URL로 요청을 리디렉션 가능

 

NLB / ALB 서브넷 설정

 

  • 방법1. Service 구성시 서브넷 ID 명시
  • 방법2. private/public 서브넷에 태그 설정
    - public : kubernetes.io/cluster/cluster-name : shared, kubernetes.io/role/elb : 1
    - private : kubernetes.io/cluster/cluster-name : shared, kubernetes.io/role/internal-elb : 1

 

 

ALB 구동 테스트

 

ALB 생성 역시 NLB 와 흡사하지만 ingress 리소스를 생성해야 하고, NodePort 나 LoadBalancer 타입의 Service 를 생성하는 것이 다르다. 마찬가지로 nginx 의 첫화면을 확인하는 샘플. 어플리케이션 배포는 NLB 테스트에 사용한 것과 동일, ALB / NodePort 정상 구동 확인하고, 브라우저에서 nginx 확인하고...

 

 

1. Sample namespace

 

$ kubectl create namespace alb-sample-app

& 해당 namespace 로 fargate 프로파일도 작성

 

 

2. nginx Application, NLB 생성

 

로드밸런서의 타입인 Instance 와 IP 중 Fargate 는 IP 타겟만 지정 가능하다. Instance 는 node 로, IP 는 pod 로 라우팅된다. 아래 스크립트는 선택기가 app=nginx 인 pod 로 라우팅하는 ALB 를 생성한다.

 

$ vi sample-alb.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: sample-app
  namespace: alb-sample-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: public.ecr.aws/nginx/nginx:1.21
          ports:
            - name: tcp
              containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  namespace: alb-sample-app
  name: sample-service-nodeport
spec:
  ports:
    - port: 80
      targetPort: 80
      protocol: TCP
  type: NodePort
  selector:
    app: nginx
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  namespace: alb-sample-app
  name: sample-ingress
  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: sample-service-nodeport
                port:
                  number: 80
$ kubectl apply -f sample.yaml
Deployment/sample-app created
Service/sample-service-nodeport created
Ingress/sample-ingress created

 

 

3. 서비스 확인

 

$ kubectl get svc sample-service-nodeport -n alb-sample-app
NAME                      TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
sample-service-nodeport   NodePort   172.20.23.108   <none>        80:31517/TCP   4s

$ kubectl get ingress sample-ingress -n alb-sample-app
NAME             CLASS    HOSTS   ADDRESS                                                               PORTS   AGE
sample-ingress   <none>   *       k8s-samplein-1234d81632-1363801234.ap-northeast-2.elb.amazonaws.com   80      3h43m

 

여기까지 진행하였으면, AWS 관리콘솔에서 [로드밸런서] 와 [대상 그룹] 이 정상적으로 구동되었는지 확인한다.

  • 로드밸런서 : DNS 이름 / application 유형 / internet-facing 체계
  • 대상그룹 : 80 port / HTTP protocal / IP target / Health status

 

 

4. 결과 확인

 

상단 ingress DNS 주소로 curl 이나 browser 를 사용하여 nginx 첫 페이지를 확인한다.

 

$ curl k8s-samplein-1234d81632-1363801234.ap-northeast-2.elb.amazonaws.com

 

nginx

 

* ALB 에서 80 port 접속시 container 의 8080 port 로 라우팅 하려면...

  • Ingress Service port: 80
  • Service port:80, targetPort: 8080
  • Deployment containerPort: 8080

 

* NodePort 가 아닌 LoadBalancer(NLB) 서비스를 사용할 경우, 내부 트래픽만 가능하도록 기존 NLB 생성했던 내용에서 internet-facing 만 삭제. (default: internal)

 

$ vi sample-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: nlb-sample-service
  namespace: nlb-sample-app
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: external
    service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip
    #service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
spec:
  ports:
    - port: 80
      targetPort: 80
      protocol: TCP
  type: LoadBalancer
  selector:
    app: nginx

 

 


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret