📂
Amazon EKS
  • Amazon EKS
  • 워크스페이스 생성하기
    • Cloud9 IDE 환경 구성
    • IAM 역할 생성
    • SSH & CMK Key 생성하기
  • EKS 클러스터 구축
    • EKS 클러스터 만들기
  • 쿠버네티스 대시보드 배포
    • Kubernetes 공식 대시보드 배포
  • 마이크로서비스 배포
    • 예제 애플리케이션 배포
    • 서비스 스케일(Scaling)
    • 애플리케이션 정리하기
  • 애플리케이션 배포 - Helm
    • HELM 설치
    • Helm으로 Nginx 배포
    • Helm을 사용하여 마이크로서비스 배포
    • 정리하기
  • 리소스 관리 - POD 배치
    • NodeSelector
    • Affinity and Anti-affinity
    • 더 실용적인 사용 사례
    • 정리하기
  • 리소스 관리 - Health Checks
    • Liveness 프로브 구성
    • Readiness 프로브 구성
    • 정리하기
  • 리소스 관리 - AutoScaling
    • HPA 구성하기
    • CA 구성하기
    • 정리하기
  • 네트워킹 - 서비스 노출
    • 서비스와 애플리케이션 연결
    • 서비스에 접근하기
    • 서비스 노출
    • Ingress
    • Ingress Controller
    • 정리하기
  • 네트워크 - Calico 정책
    • Calico 설치하기
    • Stars Policy Demo
    • 정리하기
  • Updating 권한설정 - RBAC
    • 테스트 POD 설치
    • 사용자 생성 및 맵핑
    • 역할과 바인딩
    • 정리하기
  • Updating 권한설정 - IAM 그룹
    • IAM Role, Group & User 생성하기
    • RBAC 설정하기
    • EKS 엑세스 테스트
    • 정리하기
  • Updating 권한설정 - Service account
    • OIDC 자격 증명 공급자 생성하기
    • IAM 역할 생성 및 지정
    • 샘플 POD 배포
    • 정리하기
  • Updating - 네트워크 - POD Security Group
    • SG 생성하기
    • RDS 생성하기
    • CNI 구성하기
    • SG 정책
    • Pod 배포하기
    • 정리하기
  • Updating - 모니터링 - Prometheus and Grafana
    • Prometheus 배포하기
    • Grafana 배포하기
    • 정리하기(Optional)
  • Updating 모니터링 - X-Ray
    • X-Ray DaemonSet 배포하기
    • 샘플 마이크로서비스 배포
    • X-Ray console 확인
    • 정리하기(Optional)
  • Updating 모니터링 - Container Insights
    • 사전 준비
    • Container Insights 구성하기
    • 부하 테스트
    • Container Insights 확인하기
    • 정리하기(Optional)
  • Updating CD - Gitops with Flux
    • 사전 준비
    • Codepipeline
    • EKS에 배포
    • 정리하기
  • Updating Argo Rollouts
  • Updating Service Mesh - AWS App Mesh
    • Fargate 및 OBSERVABILITY 구성
    • Product Catalog App 배포
    • APP MESH 설치
    • Porting to APP MESH
    • Virtual Gateway 구성
    • Canary
    • Observability
  • Updating 버전 업그레이드 - EKS Cluster
    • Upgrade EKS control Plane
    • Upgrade EKS CORE ADD-ONs
    • Upgrade Managed Node Group
Powered by GitBook
On this page
  • 1. 사전 준비 사항
  • 2. Fargate Profile 추가
  • 3. 모니터링 구성
  • 3-1. Cloudwatch & Fluent
  • 3-2. Prometheus Metrics
  • 3-3. Fargate Logging

Was this helpful?

  1. Updating Service Mesh - AWS App Mesh

Fargate 및 OBSERVABILITY 구성

아래의 절차를 진행하여 환경 구성을 합니다.

  • Create Fargate Profile

  • Enable OIDC Provider

  • Create Namespace for Application Deployment

  • Create IRSA (IAM Role for Service Account) for Application Namespace prodcatalog-ns

  • Enable Observability for Logs and Metrics

1. 사전 준비 사항

AWSRegion과 AccountID 가 맞는지 확인합니다.

test -n "$AWS_REGION" && echo AWS_REGION is "$AWS_REGION" || echo AWS_REGION is not set
test -n "$ACCOUNT_ID" && echo ACCOUNT_ID is "$ACCOUNT_ID" || echo ACCOUNT_ID is not set

실습 애플리케이션을 복제 합니다.

cd ~/environment
git clone https://github.com/aws-containers/eks-app-mesh-polyglot-demo.git
cd eks-app-mesh-polyglot-demo

이제 EKS 클러스터에 Fargate Profile을 생성하여 제품 카탈로그 애플리케이션에 하나의 prodcatalog 서비스를 구축하겠습니다.

2. Fargate Profile 추가

먼저 OIDC provider를 구성합니다.

eksctl utils associate-iam-oidc-provider \
    --region ${AWS_REGION} \
    --cluster eksworkshop-eksctl \
    --approve

네임스페이스 prodcatalog-ns 및 IRSA를 생성하여 X-Ray, AppMesh 및 Cloudwatch Logs 정책에 대한 권한을 부여합니다.

kubectl create namespace prodcatalog-ns

cd eks-app-mesh-polyglot-demo
aws iam create-policy \
    --policy-name ProdEnvoyNamespaceIAMPolicy \
    --policy-document file://deployment/envoy-iam-policy.json

eksctl create iamserviceaccount --cluster eksworkshop-eksctl \
  --namespace prodcatalog-ns \
  --name prodcatalog-envoy-proxies \
  --attach-policy-arn arn:aws:iam::$ACCOUNT_ID:policy/ProdEnvoyNamespaceIAMPolicy \
  --override-existing-serviceaccounts \
  --approve 
  

IAM 역할이 Kubernetes 서비스 계정과 연결되었습니다. 다음 명령으로 생성된 서비스 계정의 세부 정보를 볼 수 있습니다.

kubectl describe sa prodcatalog-envoy-proxies -n prodcatalog-ns

관리자는 Fargate 프로파일을 사용하여 Fargate에서 실행되는 Pod를 선언할 수 있습니다. 각 프로필에는 네임스페이스 및 optional labels을 포함하는 최대 5개의 selector가 있을 수 있습니다. 모든 selector에 대해 네임스페이스를 반드시 정의해야 합니다. 레이블 필드는 여러 개의 선택적 키-값 쌍으로 구성됩니다. selector에 지정된 모든 레이블과 네임스페이스가 일치하는 Pod는 Fargate로 스케줄 됩니다.

아래 명령어를 수행하여 Fargate profile을 생성합니다.

cd ~/environment/eks-app-mesh-polyglot-demo
envsubst < ./deployment/clusterconfig.yaml | eksctl create fargateprofile -f -

EKS 클러스터가 Fargate에서 Pod를 예약할 때 Pod는 Amazon ECR에서 컨테이너 이미지를 꺼내기 위해 사용자를 대신하여 AWS API call을 해야 합니다. Fargate Pod Execution Role은 IAM에서 이를 수행할 수 있는 권한을 제공합니다. 이 IAM 역할은 위의 명령에 의해 자동으로 생성됩니다.

Fargate 프로필 작성에는 최대 몇 분이 걸릴 수 있습니다.

eksctl get fargateprofile --cluster eksworkshop-eksctl -o yaml

콘솔에 로그인하고 Amazon EKS -> 클러스터 -> eksworkshop-eksctl -> 구성 -> 컴퓨팅을 클릭하십시오. 새로 만든 Fargate Profile fargate 제품 카탈로그를 볼 수 있습니다.

프로필에 EKS 클러스터의 private 서브넷이 포함되어 있습니다. Fargate에서 실행되는 포드에는 공인 IP 주소가 할당되지 않으므로 Fargate 프로파일을 만들 때 인터넷 게이트웨이에 대한 직접 경로가 없는 private 서브넷만 지원됩니다. 따라서 EKS 클러스터를 프로비저닝하는 동안 생성하는 VPC에 하나 이상의 private 서브넷이 포함되어 있는지 확인해야 합니다. eksctl 유틸리티로 EKS 클러스터를 만들면 이러한 요구 사항을 충족하는 VPC가 생성됩니다.

3. 모니터링 구성

3-1. Cloudwatch & Fluent

Cloudwatch-agent 서비스 어카운트 IAM role 및 Fluent service account IAM role 을 생성합니다.

eksctl create iamserviceaccount \
  --cluster eksworkshop-eksctl \
  --namespace amazon-cloudwatch \
  --name cloudwatch-agent \
  --attach-policy-arn  arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy \
  --override-existing-serviceaccounts \
  --approve
eksctl create iamserviceaccount \
  --cluster eksworkshop-eksctl \
  --namespace amazon-cloudwatch \
  --name fluentd \
  --attach-policy-arn  arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy \
  --override-existing-serviceaccounts \
  --approve

그리고 Managed Nodegroup에 대한 Container Insight를 배포합니다.

curl -s https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/daemonset/container-insights-monitoring/quickstart/cwagent-fluentd-quickstart.yaml | sed "s/{{cluster_name}}/eksworkshop-eksctl/;s/{{region_name}}/${AWS_REGION}/" | kubectl apply -f -    

위 명령어는 아래의 내용을 수행합니다.

  • amazon-cloudwatch 네임스페이스 생성.

  • 두 DaemonSet에 대한 모든 보안 객체(Security Object)를 생성.

    • SecurityAccount.

    • ClusterRole.

    • ClusterRoleBinding.

  • Cloudwatch-Agent를 DaemonSet 으로 배포.

  • fluentd를 DaemonSet으로 배포.

  • 두 DaemonSets에 대한 ConfigMap 구성을 배포.

DaemonSet이 정상적으로 구성되었는지 확인합니다.

kubectl -n amazon-cloudwatch get daemonsets

3-2. Prometheus Metrics

Prometheus service account 에 대한 IAM Role을 생성합니다.

eksctl create iamserviceaccount \
  --cluster eksworkshop-eksctl \
  --namespace amazon-cloudwatch \
  --name cwagent-prometheus \
  --attach-policy-arn  arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy \
  --override-existing-serviceaccounts \
  --approve
  

Prometheus Agent를 설치합니다.

kubectl apply -f https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/service/cwagent-prometheus/prometheus-eks.yaml

Prometheus Agent가 정상적으로 동작하는지 확인합니다.

kubectl get pod -l "app=cwagent-prometheus" -n amazon-cloudwatch

3-3. Fargate Logging

Fargate를 사용하는 Amazon EKS는 built-in log router를 지원하는데, 이것은 설치 또는 유지할 사이드카 컨테이너가 없음을 의미합니다. 컨테이너 로그를 발송할 위치를 정의하는 Fluent Conf 데이터 값을 사용하여 ConfigMap을 Amazon EKS 클러스터에 적용합니다. 이 로깅 ConfigMap은 aws-observability라는 고정 네임스페이스에서 사용해야 하므로 클러스터 전체의 효과가 있습니다. 즉, 모든 네임스페이스의 모든 애플리케이션에서 로그를 보낼 수 있습니다. 이 워크샵에서는 Cloudwatch_logs를 사용하여 Fargate 클러스터의 EKS에서 실행되는 워크로드에서 CloudWatch로 로그를 전송하는 방법에 대해 설명합니다.

먼저 전용 aws-observability 네임스페이스와 ConfigMap for Fluent Bit를 생성합니다.

eks-app-mesh-polyglot-demo -> deployment -> fluentbit-config.yaml 파일을 아래와 같이 수정합니다.

kind: ConfigMap
apiVersion: v1
metadata:
  name: aws-logging
  namespace: aws-observability
  labels:
data:
  output.conf: |
    [OUTPUT]
        Name cloudwatch_logs
        Match   *
        region ${AWS_REGION}
        log_group_name fluent-bit-cloudwatch
        log_stream_prefix from-fluent-bit-
        auto_create_group true
cd eks-app-mesh-polyglot-demo
envsubst < ./deployment/fluentbit-config.yaml | kubectl apply -f -

Fluent Bit ConfigMap 배포를 확인합니다.

kubectl -n aws-observability get cm

Fluent Bit를 설정하면 다음에 CloudWatch에 쓸 수 있는 권한을 부여해야 합니다. 먼저 정책을 로컬에서 다운로드하여 이 작업을 수행합니다.

curl -o permissions.json \
     https://raw.githubusercontent.com/aws-samples/amazon-eks-fluent-logging-examples/mainline/examples/fargate/cloudwatchlogs/permissions.json

IAM Policy를 생성합니다.

aws iam create-policy \
        --policy-name FluentBitEKSFargate \
        --policy-document file://permissions.json 

그런 다음 정책을 Fargate 클러스터에서 EKS의 Pod Execution Role에 연결합니다.

export PodRole=$(aws eks describe-fargate-profile --cluster-name eksworkshop-eksctl --fargate-profile-name fargate-productcatalog --query 'fargateProfile.podExecutionRoleArn' | sed -n 's/^.*role\/\(.*\)".*$/\1/ p')
aws iam attach-role-policy \
        --policy-arn arn:aws:iam::${ACCOUNT_ID}:policy/FluentBitEKSFargate \
        --role-name ${PodRole}
echo $PodRole

콘솔 EKS -> Cluster -> Configuration-> Compute, select fargate-productcatalog Fargate Profile을 선택합니다.

Pod Execution Role을 클릭하여 FluentBitEKSFargate 정책이 연결되어 있는지 확인합니다.

PreviousUpdating Service Mesh - AWS App MeshNextProduct Catalog App 배포

Last updated 3 years ago

Was this helpful?

IRSA()에 대한 자세한 내용은 Amazon EKS 문서를 참고 합니다.

이제 을 생성합니다.

일반적으로 사용자 애플리케이션 워크로드를 Kube-system 또는 default 이외의 네임스페이스로 배포하여 EKS에 배포된 Pod 간의 상호 작용을 보다 세분화된 기능으로 관리하는 것이 좋습니다. 이 장에서는 app: prodcatalog레 이블을 갖고 있는 prodcatalog-ns 네임스페이스로 예정된 모든 포드를 대상으로 하는 fargate-productcatalog 라는 새로운 Fargate 프로파일을 작성하겠습니다. 에서 아래 Fargate 프로파일 구성을 볼 수 있습니다.

관련 내용과 매뉴얼 설치 절차는 확인할 수 있습니다.

IAM Roles for Service Accounts
Fargate profile
clusterconfig.yaml
여기서