728x90
반응형

#1 Cluster Autoscaler 란?

Kubernetes에서 애플리케이션 수요에 맞추려면 워크로드를 실행하는 노드 수를 조정해야 할 수 있습니다. Kubernetes 사용의 가장 큰 장점 중 하나는 사용자 요구에 따라 인프라를 동적으로 확장할 수 있습니다.

(Cluster AutoScaler는 일반적으로 Cluster내 Deployment로 설치됩니다)

Cluster AutoScaler는 리소스 제약 조건으로 인해 예약할 수 없는 즉 Pending 상태의 Pod를 확인할 수 있습니다.

Cluster Autoscaler Process

문제가 발견되면 Pod 수요에 맞게 Worker Node 풀의 노드 수가 증가합니다. 또한 실행 중인 Pod가 부족한지 노드를 주기적으로 확인하고 필요에 따라 노드 수가 감소하여 WorkerNode 수를 자동으로 조정하여 노드 수를 ScaleOut 하거나 ScaleIn을 통해 효율적으로 비용 효과적인 인프라를 구성할 수 있습니다.

여러 종류의 ASG & Auto Scaling Policy

목적에 따라 다양한 ASG를 설정하고 다른 ASG Policy를 적용할 수 있습니다.

기존 Spot Instance는 On-demand 대비 80% 이상 할인률이 적용되었지만 중간에 허가 없이 종료 되지만, EKS의 Spot Interrupt Handler(DaemonSet)에 의해 정상적으로 실행 중인 Pod를 재배치 할 수 있습니다.

# Node 리소스 부족으로 Pod를 예약할 수 없는 경우

Cluster Autoscaler는 클러스터가 확장되어야 한다고 결정합니다. 확장기 인터페이스를 사용하면 다양한 포드 배치 전략을 적용할 수 있습니다. 현재 다음 전략이 지원됩니다.

  • Random – 사용 가능한 노드 그룹을 무작위로 선택합니다.
  • Most Pods – 가장 많은 노드를 예약할 수 있는 그룹을 선택합니다. 이것은 노드 그룹 간에 부하를 분산하는 데 사용할 수 있습니다.
  • Least-waste – cpu, memory가 가장 적게 남는 node group을 선택
  • price – cost가 가장 적은 node group을 선택
  • priority - 우선순위가 높은 node group을 선택

#CA는 다음 옵션에서 노드를 제거불가

  • 제한적인 PDB가 있는 포드.
  • 배포된(즉, 기본적으로 노드에서 실행되지 않거나 PDB가 없는) kube-system 네임스페이스에서 실행되는 파드.
  • 컨트롤러 객체가 지원하지 않는 포드(배포, 복제본 세트, 작업, 상태 저장 세트 등에 의해 생성되지 않음).
  • 로컬 스토리지와 함께 실행되는 포드.
  • 다양한 제약(리소스 부족, 일치하지 않는 노드 선택기 또는 선호도, 일치하는 반선호도 등)으로 인해 다른 곳으로 이동할 수 없는 실행 중인 포드.

#2 Cluster Autoscaler 설치

전제 조건

Cluster Autoscaler를 배포하려면 먼저 다음 사전 조건을 충족해야 합니다.

  • 기존 Amazon EKS 클러스터
  • 클러스터에 대한 기존 IAM OIDC 공급자입니다. 하나가 있는지 또는 생성해야 하는지 여부를 확인하려면 클러스터에 대한 IAM OIDC 공급자 생성 섹션을 참조하세요.
  • Auto Scaling 그룹 태그가 있는 노드 그룹 Cluster Autoscaler에서는 Auto Scaling 그룹에 다음과 같은 태그가 있어야 자동 검색됩니다.
    • eksctl을 사용하여 노드 그룹을 생성한 경우 이 태그는 자동으로 적용됩니다.
    • eksctl을 사용하지 않았다면 다음 태그로 Auto Scaling 그룹에 수동으로 태그를 지정해야 합니다. 자세한 내용은 Linux 인스턴스용 Amazon EC2 사용 설명서에서 Amazon EC2 리소스 태깅을 참조하세요.
    • k8s.io/cluster-autoscaler/<cluster-name> :  owned
      k8s.io/cluster-autoscaler/enabled  : TRUE

IAM 정책 및 역할 생성

  1. IAM 정책을 생성합니다.
  • 다음 콘텐츠를 cluster-autoscaler-policy.json이라는 파일에 저장합니다. 기존 노드 그룹이 eksctl을 사용하여 생성되었고 -asg-access 옵션을 사용했다면 이 정책이 이미 존재하며 2단계로 건너뛸 수 있습니다.
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "autoscaling:DescribeAutoScalingGroups",
                "autoscaling:DescribeAutoScalingInstances",
                "autoscaling:DescribeLaunchConfigurations",
                "autoscaling:DescribeTags",
                "autoscaling:SetDesiredCapacity",
                "autoscaling:TerminateInstanceInAutoScalingGroup",
                "ec2:DescribeLaunchTemplateVersions"
            ],
            "Resource": "*",
            "Effect": "Allow"
        }
    ]
}

다음 명령을 사용하여 정책을 생성합니다. policy-name의 값을 변경할 수 있습니다.

aws iam create-policy \
    --policy-name AmazonEKSClusterAutoscalerPolicy \
    --policy-document file://cluster-autoscaler-policy.json
  1. iamserviceaccount 생성

eksctl을 사용하여 Amazon EKS 클러스터를 생성한 경우 다음 명령을 실행합니다. -asg-access 옵션을 사용하여 노드 그룹을 생성한 경우 <AmazonEKSClusterAutoscalerPolicy>eksctl이 생성한 IAM 정책의 이름으로 바꿉니다. 정책 이름은 eksctl-<cluster-name>-nodegroup-ng-<xxxxxxxx>-PolicyAutoScaling과 유사합니다.

eksctl create iamserviceaccount \
  --cluster=<my-cluster> \
  --namespace=kube-system \
  --name=cluster-autoscaler \
  --attach-policy-arn=arn:aws:iam::<AWS_ACCOUNT_ID>:policy/<AmazonEKSClusterAutoscalerPolicy> \
  --override-existing-serviceaccounts \
  --approve
  • asg-access 옵션을 사용하여 노드 그룹을 생성한 경우 eksctl이 생성하여 해당 eksctl이 노드 그룹에 대해 생성한 Amazon EKS 노드 IAM 역할에 연결한 IAM 정책을 분리합니다. Cluster Autoscaler가 제대로 작동하도록 노드 IAM 역할에서 정책을 분리합니다. 정책을 분리해도 노드의 다른 포드에는 정책의 권한이 부여되지 않습니다.
  1. 생성 확인

다음 명령어로 iamserviceaccount 의 생성을 확인하고,
AWS Management Console IAM Role ARN 을 확인합니다. (Cluster Autoscaler에서 사용)

kubectl get sa -n kube-system | grep -i cluster-autoscaler


Cluster Autoscaler 배포

  1. Cluster Autoscaler YAML 파일을 다운로드합니다.
  2. curl -o cluster-autoscaler-autodiscover.yaml https://raw.githubusercontent.com/kubernetes/autoscaler/master/cluster-autoscaler/cloudprovider/aws/examples/cluster-autoscaler-autodiscover.yaml
  3. YAML 파일을 수정하고 을 클러스터 이름으로 바꿉니다.

  1. YAML 파일을 클러스터에 적용합니다.
kubectl apply -f cluster-autoscaler-autodiscover.yaml
  1. 이전에 생성한 IAM 역할의 ARN을 사용하여 cluster-autoscaler 서비스 계정에 주석을 지정합니다. <example values>를 위에 생성한 역할의 ARN 값으로 바꿉니다.
kubectl annotate serviceaccount cluster-autoscaler \
  -n kube-system \
  eks.amazonaws.com/role-arn=arn:aws:iam::<ACCOUNT_ID>:role/<AmazonEKSClusterAutoscalerRole>

ServiceAccount - cluster-autoscaler Annotation 변경을 확인합니다.

$ kubectl describe sa -n kube-system cluster-autoscaler
========================================================
Name:                cluster-autoscaler
Namespace:           kube-system
Labels:              k8s-addon=cluster-autoscaler.addons.k8s.io
                     k8s-app=cluster-autoscaler
Annotations:         eks.amazonaws.com/role-arn: arn:aws:iam::279424994673:role/eksctl-EKS-Project-addon-iamserviceaccount-k-Role1-13DTLSGQPNNJB
Image pull secrets:  <none>
Mountable secrets:   cluster-autoscaler-token-6x8mg
Tokens:              cluster-autoscaler-token-6x8mg
Events:              <none>
  1. 다음 명령으로 배포를 패치하여 cluster-autoscaler.kubernetes.io/safe-to-evict 주석을 Cluster Autoscaler 포드에 추가합니다. CA가 자체 포드가 실행 중인 노드를 제거하는 것을 방지하기 위해 false로 설정합니다. 해당 주석의 값이 True인 경우 ClusterAutoscaler가 노드를 제거할 수 없습니다.
kubectl patch deployment cluster-autoscaler \
  -n kube-system \
  -p '{"spec":{"template":{"metadata":{"annotations":{"cluster-autoscaler.kubernetes.io/safe-to-evict": "false"}}}}}'

  1. 다음 명령을 사용하여 Cluster Autoscaler 배포를 편집합니다.
kubectl -n kube-system edit deployment.apps/cluster-autoscaler

추가할 Flag

  • balance-similar-node-groups
  • skip-nodes-with-system-pods=false
spec:
      containers:
      - command:
        - ./cluster-autoscaler
        - --v=4
        - --stderrthreshold=info
        - --cloud-provider=aws
        - --skip-nodes-with-local-storage=false
        - --expander=least-waste
        - --node-group-auto-discovery=asg:tag=k8s.io/cluster-autoscaler/enabled,k8s.io/cluster-autoscaler/<YOUR CLUSTER NAME>
        - --balance-similar-node-groups
        - --skip-nodes-with-system-pods=false

파일을 저장한 다음 종료하여 변경 사항을 적용합니다

  1. 웹 브라우저의 GitHub에서 Cluster Autoscaler [릴리스(releases)] 페이지를 열고 클러스터의 Kubernetes 메이저 및 마이너 버전과 일치하는 최신 Cluster Autoscaler 버전을 검색합니다. 예를 들어 클러스터의 Kubernetes 버전이 1.21이라면 1.21로 시작하는 최신 Cluster Autoscaler 릴리스를 검색합니다. 다음 단계에서 사용할 수 있도록 이 릴리스의 의미 체계 버전(1.21.*n*)을 적어 둡니다.

(해당 부분 유의 Version에 따라 호환성)

  1. 다음 명령을 사용하여 Cluster Autoscaler 이미지 태그를 이전 단계에서 적어 둔 버전으로 설정합니다. 1.21.n을 사용자의 고유한 값으로 교체하고 확인합니다.
kubectl set image deployment cluster-autoscaler \
  -n kube-system \
  cluster-autoscaler=k8s.gcr.io/autoscaling/cluster-autoscaler:v1.21.2

#3 동작 검증

테스트용 Nginx Deployment 생성

cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  replicas: 5
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 1
            memory: 1Gi
          limits:
            cpu: 2
            memory: 2Gi
EOF

주목하여야 할 부분은 spec.spec.containers.resource 부분이다.

resources:
requests:
cpu: 1
memory: 1Gi
limits:
cpu: 2
memory: 2Gi

리소스의 요청이 노드의 자원을 초과하므로 ClusterAutocaler는 AWS ASG를 통해 노드를 추가합니다.

Untitled

노드가 추가된 후 Pod의 Pending 상태가 Running으로 변경됩니다.

Untitled

# 4 참고문서

Cluster Autoscaler 배포를 최적화하기 위한 고려 사항

Cluster Autoscaler 공식 가이드

Cluster Autoscaler 에 대한 이해

728x90
300x250
728x90
반응형

AWS LoadBalancer Controller

#1. AWS LoadBalancer Controller 란?

AWS LoadBalancer Controller는 Kubernetes 클러스터의 Elastic Load Balancer(NLB or ALB)를 관리하는 데 Ingress.yaml 템플릿에 명시 된 Rule을 통해 LoadBalancer를 관리하는 컨트롤러 입니다.
(Application Load Balancer & Network Load Balancer를 모두 지원합니다)

Kubernetes Application은 외부 트래픽에 노출 되어야 하며, EKS Client는 ELB를 사용하여 태스크를 수행합니다.

Controller를 통해 External Access Allow

Controller를 통해 만들면 Ingress Annotation 값 확인하여, Controller가 LoadBalancer를 대신 만들어 주는 형태입니다.

이때 사용되는 인그레스(Ingress) 는 L7 영역의 요청을 처리합니다.

주로 클러스터 외부에서 쿠버네티스 내부로 접근할 때, 요청들을 어떻게 처리할지 정의해놓은 규칙이자 리소스 오브젝트입니다. 한마디로 외부의 요청이 내부로 접근하기 위한 관문의 역할을 하는 것이죠.

Ingress를 AWS Loadbalancer Controller를 통해 ALB로 선언

외부 요청에 대한 로드 밸런싱, TLS/SSL 인증서 처리, HTTP 경로에 대한 라우팅 등을 설정할 수 있습니다.

NLB는 LoadBalancer 유형의 Kubernetes 서비스에 대한 응답으로 생성되며, 초당 수백만 건의 요청으로 확장할 수 있는 고성능 트래픽 서비스를 제공합니다.

EC2 Loadbalancer 항목에서 추가 됨

AWS Loadbalancer Controller는 Kubernetes Ingress 객체에 대한 반응으로 Application Load Balancer를 자동으로 프로비저닝 합니다.

  • TIP과거 "AWS ALB Ingress Controller"로 알려졌으며 "AWS Load Balancer Controller"로 브랜드를 변경했습니다.

Application LoadBalancer 의 Traffic Mode Option

AWS Load Balancer Controller에서 지원하는 Traffic Mode는 Default Instance를 대상으로 Cluster 내 node를 ALB 대상으로 등록하는 방법은 ALB에 도달하는 트래픽은 NodePort로 Routing 된 다음 Pod로 프록시 하거나 IP기반으로 Pod를 IP대상으로 등록하는 방법이 있습니다.

ALB에 도달하는 트래픽은 Pod로 직접 Routing되며, 해당 트래픽 모드를 사용하기 위해 ‘ingress.yaml’파일에 Annotation을 사용하여 지정해야 합니다.

728x90

ALB가 생성되면서 각 Application 별 PATH 기반 트래픽 분기

쿠버네티스에서 서비스 타입 중, NodePort 혹은 LoadBalancer로도 외부로 노출할 수 있지만
인그레스 없이 서비스를 사용할 경우, 모든 서비스에게 라우팅 규칙 및 TLS/SSL 등의 상세한 옵션들을 적용해야합니다. 그래서 인그레스가 필요합니다.

Pod형태로 LoadBalancer Controller의 Running 상태

#2. 설치방법

1. Service Account 에 대한 IAM 역할 설정

  1. AWS Load Balancer 컨트롤러를 배포하기 전,
    클러스터에 대한 IAM OIDC(OpenID Connect identity Provider)를 생성합니다.
    쿠버네티스가 직접 관리하는 사용자 계정을 의미하는 service account에 IAM role을 연결하기 위해, 클러스터에 IAM OIDC provider가 존재해야 합니다.
eksctl utils associate-iam-oidc-provider \
    --region ${AWS_REGION} \
    --cluster CLUSTER-NAME \
    --approve

(참고) 생성한 IAM OIDC 자격 증명 공급자는 IAM 콘솔 Identity providers 메뉴 혹은 아래의 명령어를 통해 확인할 수 있습니다. 클러스터의 OIDC provider URL을 아래의 명령어들을 통해 확인합니다.

aws eks describe-cluster --name CLUSTER-NAME --query "cluster.identity.oidc.issuer" --output text

명령어 결과 나오는 값은 아래와 같은 형식을 가지고 있습니다

https://oidc.eks.ap-northeast-2.amazonaws.com/id/8A6E78112D7F1C4DC352B1B511DD13CF

위의 결과 값에서 /id/ 뒤에 있는 값을 복사한 후, 아래와 같이 명령어를 수행합니다.

aws iam list-open-id-connect-providers | grep 8A6E78112D7F1C4DC352B1B511DD13CF

결과 값이 출력되면 IAM OIDC identity provider가 클러스터에 생성이 된 것이고,
아무 값도 나타나지 않으면 생성 작업을 수행해야 합니다.


b. AWS 로드 밸런서 컨트롤러에 대한 IAM 정책 다운로드

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

c. AWSLoadBalancerControllerIAMPolicy라는 IAM 정책 생성

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

반환된 정책 ARN을 기록해 둡니다.

d. AWS Load Balancer 컨트롤러에 대한 IAM 역할 및 ServiceAccount를 eksctl를 통해 생성하고
위 단계의 ARN을 붙여 넣습니다.

eksctl create iamserviceaccount \
--cluster=<cluster-name> \
--namespace=kube-system \
--name=aws-load-balancer-controller \
--attach-policy-arn=arn:aws:iam::<AWS_ACCOUNT_ID>:policy/AWSLoadBalancerControllerIAMPolicy \
--override-existing-serviceaccounts \
--region <region-code> \
--approve

또한, 아래의 명령어를 통해, service account가 생성된 것을 확인할 수 있습니다.

kubectl get sa aws-load-balancer-controller -n kube-system -o yaml

2-1 클러스터에 컨트롤러 추가 (helm 사용)

  1. helm에 EKS 차트 리포지토리 추가
helm repo add eks https://aws.github.io/eks-charts

b. helm upgrade 차트를 통해 업그레이드 한다면 TargetGroupBinding CRD를 설치합니다

kubectl apply -k "github.com/aws/eks-charts/stable/aws-load-balancer-controller//crds?ref=master"

c. 서비스 계정에 IAM 역할을 사용하는 helm 차트를 설치합니다.

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

helm을 사용하여 load-balancer-controller를 생성할 경우, 기본값으로 Replicas: 2 desired 이며
두 개의 파드가 작동합니다.

2-2 클러스터에 컨트롤러 추가 (Yaml Manifest 사용)

(Fargate에서 컨트롤러를 실행하려면 cert-manager에 의존하지 않는 Helm 차트를 사용하세요.)

  1. 먼저, 인증서 구성을 웹훅에 삽입할 수 있도록 cert-manager를 설치합니다. Cert-manager는 쿠버네티스 클러스터내에서 TLS인증서를 자동으로 프로비저닝 및 관리하는 오픈 소스입니다.
kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v1.5.3/cert-manager.yaml

b. Load balancer controller YAML 다운로드합니다.

wget https://github.com/kubernetes-sigs/aws-load-balancer-controller/releases/download/v2.3.1/v2_3_1_full.yaml

c. 텍스트 편집기를 통해 저장된 YAML 파일을 편집합니다.

Deployment.spec.args의 --cluster-name의 EKS클러스터 이름을 수정합니다.

apiVersion: apps/v1
kind: Deployment
. . .
name: aws-load-balancer-controller
namespace: kube-system
spec:
    . . .
    template:
        spec:
            containers:
                - args:
                    - --cluster-name=<INSERT_CLUSTER_NAME> # 생성한 클러스터 이름을 입력

d. 이전에 ServiceAccount를 생성하였으므로 해당 섹션을 전부 삭제합니다.
이렇게 하면 eksctl에서 생성한 iamserviceaccount가 유지됩니다.

apiVersion: v1
kind: ServiceAccount

e. YAML 파일 적용

kubectl apply -f v2_3_1_full.yaml

3. 검증

전제 조건

ALB에는 가용 영역에 걸쳐 최소 2개의 서브넷이 필요하고 NLB에는 1개의 서브넷이 필요합니다.


Subnet Auto Discovery

자동 검색이 작동하려면 서브넷에 적절하게 태그를 지정해야 합니다.
구성한 서브넷에 다음 태그를 포함해야 합니다.

공통 태그

  • kubernetes.io/cluster/$CLUSTER_NAME프라이빗 서브넷
  • $CLUSTER_NAME 지정한 클러스터 이름과 동일하게 입력합니다.
    AWS LoadBalancer Controller 버전 v2.1.1 이하에서는 퍼블릭 서브넷과 프라이빗 서브넷 모두 다음과 같이 클러스터 이름으로 태그를 지정해야 합니다.
  • kubernetes.io/role/internal-elb1퍼블릭 서브넷
  • 내부 로드 밸런서의 경우 1 또는 빈 태그 값 으로 설정해야 합니다 .
  • kubernetes.io/role/elb1
  • 인터넷 연결 로드 밸런서의 경우 1 또는 빈 태그 값 으로 설정해야 합니다 .

EKS-Project 이름의 클러스터에 대한 올바른 태그가 있는 퍼블릭 서브넷의 예는 다음과 같습니다.

Subnet Discovery에 대한 자세한 내용은 아래 링크에서 확인 하실 수 있습니다.

https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.3/deploy/subnet_discovery/


  1. 모든 echoserver 리소스(네임스페이스, 서비스, 배포) 배포
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.0.0/docs/examples/echoservice/echoserver-namespace.yaml &&\
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.0.0/docs/examples/echoservice/echoserver-service.yaml &&\
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.0.0/docs/examples/echoservice/echoserver-deployment.yaml

각 yaml 파일의 내용은 다음과 같습니다.

echoserver-namespace.yaml
---
apiVersion: v1
kind: Namespace
metadata:
  name: echoserver

---
echoserver-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: echoserver
  namespace: echoserver
spec:
  ports:
    - port: 80
      targetPort: 8080
      protocol: TCP
  type: NodePort
  selector:
    app: echoserver

---
echoserver-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: echoserver
  namespace: echoserver
spec:
  selector:
    matchLabels:
      app: echoserver
  replicas: 1
  template:
    metadata:
      labels:
        app: echoserver
    spec:
      containers:
      - image: gcr.io/google_containers/echoserver:1.4
        imagePullPolicy: Always
        name: echoserver
        ports:
        - containerPort: 8080

b. echoserver Ingress 매니페스트를 로컬로 다운로드합니다.

wget https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.0.0/docs/examples/echoservice/echoserver-ingress.yaml

c. echoserver-ingress.yaml 분석

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
    name: echoserver
    namespace: echoserver
    annotations:
        alb.ingress.kubernetes.io/scheme: internet-facing # internal 시 내부 로드 밸런서
        alb.ingress.kubernetes.io/subnets: subnet-05e1c98ed0f5b109e,subnet-07f5bb81f661df61b 두 개 이상의 서브넷을 포함 하도록 Annotation을 편집합니다 .
        alb.ingress.kubernetes.io/tags: Environment=dev,Team=test # LoadBalancer - Target Group에 태그 추가
spec:
    rules:
    - host: echoserver.chnam.link  # 외부 DNS를 사용하려면 해당 필드를 Route 53에서 소유한 도메인으로 변경
        http:
        paths:

## 아래 부분은 경로 설정에 대한 예시입니다. 현재는 입력하지 않습니다.
          - path: /503
            backend:
              serviceName: response-503
              servicePort: use-annotation
          - path: /eks
            backend:
              serviceName: redirect-to-eks
              servicePort: use-annotation
          - path: /path1
            backend:
              serviceName: forward-single-tg
              servicePort: use-annotation
          - path: /path2
            backend:
              serviceName: forward-multiple-tg
              servicePort: use-annotation

ngress annotations에 대한 관련 정보는 아래에서 확인하실 수 있습니다.

https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.3/guide/ingress/annotations/

d. kubectl apply -f echoserver-ingress.yaml 명령어를 통해 Ingress 적용

e. Ingress Event 확인 kubectl describe ing -n echoserver echoserver

Name:             echoserver
Labels:           <none>
Namespace:        echoserver
Address:          k8s-echoserv-echoserv-d6f0e2ff88-151887753.ap-northeast-2.elb.amazonaws.com
Default backend:  default-http-backend:80 (<error: endpoints "default-http-backend" not found>)
Rules:
  Host                   Path  Backends
  ----                   ----  --------
  echoserver.chnam.link
                         /   echoserver:80 (10.0.1.218:8080)
Annotations:             alb.ingress.kubernetes.io/scheme: internet-facing
                         alb.ingress.kubernetes.io/subnets: subnet-060ac246c10fc60bb,subnet-088233ffcd75a6151
                         alb.ingress.kubernetes.io/tags: Environment=dev,Team=test
                         kubernetes.io/ingress.class: alb
Events:
  Type    Reason                  Age                From     Message
  ----    ------                  ----               ----     -------
  Normal  SuccessfullyReconciled  26m (x2 over 35m)  ingress  Successfully reconciled

f. 해당 호스트 도메인에 ingress 작동이 잘 수행되었는지 확인합니다.

검증 과정은 아래의 링크를 참조하였습니다.

https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.3/examples/echo_server/#deploy-ingress-for-echoserver

https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.3/examples/echo_server/#deploy-ingress-for-echoserver

AWS LoadBalancer Controller-Amazon EKS

NLB Target Group Binding 추가

728x90
300x250
728x90
반응형

개요

보안을 위해 프로그램용 IAM 사용자나 역할에 터치되는 권한에서 S3 삭제 권한을 제외합니다.

(프로그램에서 S3로 파일 삭제하는 처리가 있는 경우 S3 삭제 권한을 제한하지 않습니다.)

 

설정

버킷에 액세스할 정책 작성

예 : test-alpha

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "s3:ListAllMyBuckets"
            ],
            "Resource": [
                "*"
            ],
            "Effect": "Allow"
        },
        {
            "Action": [
                "s3:*"
            ],
            "Resource": [
                "arn:aws:s3:::test-alpha",
                "arn:aws:s3:::test-alpha/*"
            ],
            "Effect": "Allow"
        }
    ]
}

프로그램용 IAM 사용자 역할에 정책 어태치

 

예: 정책명 : deny_delete-s3

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "s3:Delete*"
            ],
            "Effect": "Deny",
            "Resource": "*"
        }
    ]
}
728x90
300x250

'IT > AWS' 카테고리의 다른 글

AWS Client VPN 인증서 준비  (0) 2021.08.12
AWS Client VPN 증명서 갱신  (0) 2021.08.12
Amazon EC2 API Tools  (0) 2021.08.09
AWS Python에 의한 관리  (0) 2021.08.09
aws-elb-reg ELB 등록 해제 스크립트  (0) 2021.08.09
728x90
반응형

aws-elb-reg

ELB에 등록 해제를 하는 스크립트

Init Script이므로 EC2인스턴스에 chkconfig on로 세팅하면 인스턴스 정지·기동시에 자동으로 할 수 있다.

 

Management Console로 설정

EC2->Instances->대상 인스턴스를 선택->Tags->Add/Edit Tags

 

Key / Value

elb 등록하는 ELB의 이름(복수의 경우 감마 분리)

kr-mi-ap, kr-mi-apws

서버에서 설정

boto라이브러리가 필요하므로 넣어 둔다.

# pip install boto
# yum install --enablerepo=test aws-elb-reg

/etc/sysconfig/aws-elb-reg 에 액세스 키와 비밀 키를 설정한다.

# AWS Security Credentials
AWS_API_ACCESS_KEY='XXXXXXXXXXXXXXXXXXXX'
AWS_API_SECRET_KEY='xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
 
# ELB informational tag name
TAG_ELB='elb'

기동시에 자동 실행시킨다

chkconfig aws-elb-reg on
service aws-elb-reg start
 cat /etc/systemd/system/aws-elb-reg.service
[Unit]
Description=ELB Registration
After=network.target httpd.service

[Service]
Type=oneshot
RemainAfterExit=yes
EnvironmentFile=/etc/sysconfig/aws-elb-reg
#ExecStart=/usr/sbin/aws-elb-reg add $TAG_ELB $AWS_API_ACCESS_KEY $AWS_API_SECRET_KEY
#ExecStop=/usr/sbin/aws-elb-reg delete $TAG_ELB $AWS_API_ACCESS_KEY $AWS_API_SECRET_KEY
ExecStart=/bin/bash -l -c "/usr/sbin/aws-elb-reg start"
ExecStop=/bin/bash -l -c "/usr/sbin/aws-elb-reg stop"

[Install]
WantedBy=multi-user.target

 

동작 확인

service aws-elb-reg status

ELB의 이름이 출력되면 정상적으로 설정되어 있습니다.

 

 

sudo설정

ap 사용자로 aws-elb-reg을 조작할 수 있도록 한다. 

/etc/sudoers.d/01-test를 새로 작성하고 아래 4개를 기술한다.

Defaults:test !requiretty
test ALL=(ALL) NOPASSWD: /sbin/service aws-elb-reg start
test ALL=(ALL) NOPASSWD: /sbin/service aws-elb-reg stop
test ALL=(ALL) NOPASSWD: /sbin/service aws-elb-reg status

 

 

 

참고

# cat l7off.sh
#!/bin/sh
touch /tmp/service-check.stop
mv /home/www/staticweb/monitor/l7check.nhn  /home/www/staticweb/monitor/l7check.nhn.ori
sudo service aws-elb-reg stop


# cat l7on.sh
#!/bin/sh
mv /home/www/staticweb/monitor/l7check.nhn.ori  /home/www/staticweb/monitor/l7check.nhn
sudo service aws-elb-reg start
rm /tmp/service-check.stop
728x90
300x250

'IT > AWS' 카테고리의 다른 글

Amazon EC2 API Tools  (0) 2021.08.09
AWS Python에 의한 관리  (0) 2021.08.09
AWS CLI 기본 사용방법  (0) 2021.08.09
AWS CLI 로컬에서 S3로 복사  (0) 2021.08.09
AWS CLI 보안그룹 추가하기  (0) 2021.08.09
728x90
반응형

개요

  • 외부에서 S3 버킷 직접 액세스를 제한하고, CDN 통해서만 액세스 하도록 보안을 강화하기 위함
  • Access Key와 Secret Key를 알고 있는 사람의 한해(내부직원) 접근 가능

설정

1. CloudFront에 접속하여 해당 Origin Edit로 수정합니다.

 

2. 위와 같이 2가지 옵션에 대해 체크 후 설정

 

3. Principal에 OAI Key값과 IAM 계정에 대한 설정을 합니다.

 

{
    "Version": "2008-10-17",
    "Statement": [
        {
            "Sid": "AddPerm",
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity 1234565",
                    "arn:aws:iam::1234:user/s3_test1",
                    "arn:aws:iam::1234:user/s3_test2"
                ]
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::test/*"
        },
        {
            "Sid": "2",
            "Effect": "Deny",
            "Principal": {
                "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity 123456"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::test/특정경로/"
        }
    ]
}

 4. 위와 같이 설정을 진행하고, 외부 공개되어서는 안되는 Log에 대해서는 특별히 Deny처리 까지 진행합니다.

728x90
300x250

'IT > AWS' 카테고리의 다른 글

AWS CLI 로컬에서 S3로 복사  (0) 2021.08.09
AWS CLI 보안그룹 추가하기  (0) 2021.08.09
AutoRecovery  (0) 2021.08.09
AWS CloudWatch 모니터링 값  (0) 2021.07.30
AWS Extend Switch Roles 설정  (0) 2021.07.01
728x90
반응형

개요

  • AWS Organization 많아지면서 역할 전환할 때 새로 추가를 해 줘야 하는 번거로움이 생겼습니다. (기본적으로 AWS Console에서 역할 기록남는건 3~4개 밖에 안되서 새로 기록을 해줘야 합니다)
    이런 번거로움을 위해 AWS에서 브라우저 확장 앱으로 'AWS Extend Switch Roles' 라는 앱을 제공합니다.
    해당 기능으로 역할 전환을 편리하게 전환 할 수 있으며, 해당 기능은 AWS Console 접속 시에만 사용 가능합니다.

설정

  1. 브라우저의 확장앱을 통하여 AWS Extend Switch Roles를 설치 합니다.

  • 브라우저의 우측 상단 Key 모양 아이콘을 클릭합니다.

  • Configuration 을 클릭합니다.

  • 안에 내용을 기입하고 Save를 선택합니다.

  • 설정이 완료 되면 위와 같이 설정한 Organization 리스트를 확인 및 전환 할 수 있습니다.

 

 

[profile test]
region = us-west-1
role_arn = arn:aws:iam::1234:role/testadmin
color = 0040ff
 
[profile test2]
region = ap-northeast-2
role_arn = arn:aws:iam::4567:role/test2admin
color = 00fffb
  • Configuration 내용
728x90
300x250

'IT > AWS' 카테고리의 다른 글

AWS CLI 로컬에서 S3로 복사  (0) 2021.08.09
AWS CLI 보안그룹 추가하기  (0) 2021.08.09
AutoRecovery  (0) 2021.08.09
AWS CloudWatch 모니터링 값  (0) 2021.07.30
AWS S3 OAI 설정 및 ClientLog 쪽 Deny 처리  (0) 2021.07.22

+ Recent posts