無知

갈 길이 먼 공부 일기

기술 공부/일반 트렌드

DevOps (2) | ALB, NLB, AWS Load Balancer Controller

moozii 2022. 3. 26. 22:52

배경

service.beta.kubernetes.io/aws-load-balancer-type 등, NLB를 활용한 인프라를 운용 중에, helm 차트 상의 컨트롤러 관련 어노테이션에 오류가 확인되어, 이와 관련된 구체적인 스펙을 확인해보는 리서치를 진행해 정리한다.

 

 

 

 

리서치 내용

https://no-easy-dev.tistory.com/entry/AWS-ALB%EC%99%80-NLB-%EC%B0%A8%EC%9D%B4%EC%A0%90

1. ALB VS NLB

 

** 두 가지 유형의 로드 밸런싱 간의 차이점에 대한 자세히 알아보려면 AWS 웹 사이트에서 Elastic Load Balancing 기능 섹션을 참조하세요. https://aws.amazon.com/ko/elasticloadbalancing/features/

 

네트워크 트래픽 분산 - Elastic Load Balancing - Amazon Web Services

 

aws.amazon.com

 

ALB NLB
L7단의 로드 밸런서를 지원합니다. L4단의 로드 밸런서를 지원합니다.
HTTP/HTTPS 프로토콜의 헤더를 보고 적절한 패킷으로 전송합니다. TCP/IP 프로토콜의 헤더를 보고 적절한 패킷으로 전송합니다.
IP주소 + 포트번호 + 패킷 내용을 보고 스위칭합니다. IP + 포트번호를 보고 스위칭합니다.
IP 주소가 변동되기 때문에 Client에서 Access 할 ELB의 DNS Name을 이용해야 합니다. NLB는 할당한 Elastic IP를 Static IP로 사용이 가능하여 DNS Name과 IP주소 모두 사용이 가능합니다.
L7단을 지원하기 때문에 SSL 적용이 가능합니다. NLB는 SSL 적용이 인프라 단에서 불가능하여 애플리케이션에서 따로 적용해 주어야 합니다.
[출처] https://no-easy-dev.tistory.com/entry/AWS-ALB%EC%99%80-NLB-%EC%B0%A8%EC%9D%B4%EC%A0%90

 

 

 

2. K8S Admission Controller

 

https://kubernetes.io/ko/docs/concepts/security/controlling-access/

어드미션 제어 모듈은 요청을 수정하거나 거부할 수 있는 소프트웨어 모듈이다. 인가 모듈에서 사용할 수 있는 속성 외에도 어드미션 제어 모듈은 생성되거나 수정된 오브젝트 내용에 접근할 수 있다.

 

어드미션 컨트롤러는 오브젝트를 생성, 수정, 삭제 또는 (프록시에) 연결하는 요청에 따라 작동한다. 어드미션 컨트롤러는 단순히 오브젝트를 읽는 요청에는 작동하지 않는다. 여러 개의 어드미션 컨트롤러가 구성되면 순서대로 호출된다.

https://kubernetes.io/ko/docs/concepts/security/controlling-access/

 

쿠버네티스 API 접근 제어하기

이 페이지는 쿠버네티스 API에 대한 접근 제어의 개요를 제공한다. 사용자는 kubectl, 클라이언트 라이브러리 또는 REST 요청을 통해 API에 접근한다. 사용자와 쿠버네티스 서비스 어카운트 모두 API

kubernetes.io

 

An admission controller is a piece of code that intercepts requests to the Kubernetes API server prior to persistence of the object, but after the request is authenticated and authorized. The controllers consist of the list below, are compiled into the kube-apiserver binary, and may only be configured by the cluster administrator. In that list, there are two special controllers: MutatingAdmissionWebhook and ValidatingAdmissionWebhook. These execute the mutating and validating (respectively) admission control webhooks which are configured in the API.

 

Admission controllers limit requests to create, delete, modify objects or connect to proxy. They do not limit requests to read objects.

The admission control process proceeds in two phases. In the first phase, mutating admission controllers are run. In the second phase, validating admission controllers are run. Note again that some of the controllers are both.

https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/

 

Using Admission Controllers

This page provides an overview of Admission Controllers. What are they? An admission controller is a piece of code that intercepts requests to the Kubernetes API server prior to persistence of the object, but after the request is authenticated and authoriz

kubernetes.io

 

 

 

3. K8S Ingress Controller

 

인그레스

클러스터 내의 서비스에 대한 외부 접근을 관리하는 API 오브젝트이며, 일반적으로 HTTP를 관리함.인그레스는 부하 분산, SSL 종료, 명칭 기반의 가상 호스팅을 제공할 수 있다.

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

출처: https://medium.com/google-cloud

Service는 클러스터 외부로 PORT를 노출하는 기능과 부하분산기능을 수행합니다.
그리고 이점은 Ingress 도 동일합니다. 차이점은 Ingress는 L7이고 Service 는 L4라는 점입니다.

https://danawalab.github.io/kubernetes/2020/01/23/kubernetes-service-ingress.html

 

 

인그레스 컨트롤러

인그레스 리소스가 작동하려면, 클러스터는 실행 중인 인그레스 컨트롤러가 반드시 필요하다.

kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의 다른 타입과 달리 인그레스 컨트롤러는 클러스터와 함께 자동으로 실행되지 않는다. 클러스터에 가장 적합한 인그레스 컨트롤러 구현을 선택하는데 이 페이지를 사용한다.

프로젝트로서 쿠버네티스는 AWS, GCE와 nginx 인그레스 컨트롤러를 지원하고 유지한다.

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

https://github.com/kubernetes-sigs/aws-load-balancer-controller#readme

 

 

 

4. AWS ALB ingress controller에서 AWS Load Balancer Controller로

 

AWS ALB ingress controller는 AWS Load Balancer Controller의 전신

The AWS ALB ingress controller allows you to easily provision an AWS Application Load Balancer (ALB) from a Kubernetes ingress resource. Kubernetes users have been using it in production for years and it’s a great way to expose your Kubernetes services in AWS.

We are pleased to announce that the ALB ingress controller is now the AWS Load Balancer Controller with added functionality and features such as:

  • Network Load Balancers (NLB) for Kubernetes services
  • Share ALBs with multiple Kubernetes ingress rules
  • New TargetGroupBinding custom resource
  • Support for fully private clusters

 

Ingress controllers in AWS use ELB to expose the ingress controller to outside traffic. They have added benefits such as advanced routing rules (e.g. path-based routing /service2) and consolidating services to a single entry point for lower cost and centralized configuration.

 

The ALB ingress controller is a popular way to expose Kubernetes services using Kubernetes ingress rules to create an ALB. The following diagram is from the original ALB ingress controller announcement to show benefits such as ingress path-based routing and the ability to route directly to pods in Kubernetes instead of relying on internal service IPs and kube-proxy.

 

 

Network Load Balancers for Kubernetes services

The new Load Balancer Controller allows you to create NLBs for your Fargate pods with a simple annotation on the service.

kind: Service
apiVersion: v1
metadata:
  name: nlb-ip-svc
  annotations:
    # route traffic directly to pod IPs
    service.beta.kubernetes.io/aws-load-balancer-type: "nlb-ip"

[출처] https://aws.amazon.com/blogs/containers/introducing-aws-load-balancer-controller/

[출처_2] https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.4/deploy/upgrade/migrate_v1_v2/

[출처_3] https://aws.amazon.com/ko/about-aws/whats-new/2020/10/introducing-aws-load-balancer-controller/

 

 

 

5. AWS LoadBalancer Controller

AWS Load Balancer Controller is a controller to help manage Elastic Load Balancers for a Kubernetes cluster.

  • It satisfies Kubernetes Ingress resources by provisioning Application Load Balancers.
  • It satisfies Kubernetes Service resources by provisioning Network Load Balancers.

This project was formerly known as "AWS ALB Ingress Controller", we rebranded it to be "AWS Load Balancer Controller".

https://github.com/kubernetes-sigs/aws-load-balancer-controller#readme

 

GitHub - kubernetes-sigs/aws-load-balancer-controller: A Kubernetes controller for Elastic Load Balancers

A Kubernetes controller for Elastic Load Balancers - GitHub - kubernetes-sigs/aws-load-balancer-controller: A Kubernetes controller for Elastic Load Balancers

github.com

 

 

 

6. AWS LoadBalancer Controller Annotation Solution

 

You can use IP targets with pods deployed to Amazon EC2 nodes or Fargate. Your Kubernetes service must be created as type LoadBalancer. For more information, see Type LoadBalancer in the Kubernetes documentation.

 

To create a load balancer that uses IP targets, add the following annotations to a service manifest and deploy your service. The external value for aws-load-balancer-type is what causes the AWS Load Balancer Controller, rather than the AWS cloud provider load balancer controller, to create the Network Load Balancer. You can view a sample service manifest with the annotations.

 

service.beta.kubernetes.io/aws-load-balancer-type: "external"
service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: "ip"

 

……

 

The service.beta.kubernetes.io/aws-load-balancer-type: "nlb-ip" annotation is still supported for backwards compatibility. However, we recommend using the previous annotations for new load balancers instead of service.beta.kubernetes.io/aws-load-balancer-type: "nlb-ip".

https://docs.aws.amazon.com/eks/latest/userguide/network-load-balancing.html

 

Network load balancing on Amazon EKS - Amazon EKS

If you're load balancing to IPv6 pods, add the following annotation. You can only load balance over IPv6 to IP targets, not instance targets. Without this annotation, load balancing is over IPv4. service.beta.kubernetes.io/aws-load-balancer-ip-address-type

docs.aws.amazon.com

 

The service resources of type LoadBalancer also get reconciled by the kubernetes controller built into the cloudprovider component of the kube-controller-manager or the cloud-controller-manager aka the in-tree controller. The AWS in-tree controller ignores those services resources that have the service.beta.kubernetes.io/aws-load-balancer-type annotation as external. The AWS Load balancer controller support for NLB is based on the in-tree cloud controller ignoring the service resources, so it is very important to apply the following annotation on the service resource during creation:

service.beta.kubernetes.io/aws-load-balancer-type: "external"

 

This externalvalue to the above annotation causes the in-tree controller to not process the service resource and thus pass it on to the external controller.

 

……

 

NLB IP mode is determined based on the service.beta.kubernetes.io/aws-load-balancer-nlb-target-type annotation. If the annotation value is ip, then NLB will be provisioned in IP mode. Here is the manifest snippet:

 

    metadata:
      name: my-service
      annotations:
        service.beta.kubernetes.io/aws-load-balancer-type: "external"
        service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: "ip"

 

backwards compatibility : For backwards compatibility, controller still supports the nlb-ip as the type annotation. For example, if you specify

 

service.beta.kubernetes.io/aws-load-balancer-type: nlb-ip

 

the controller will provision NLB in IP mode. With this, the service.beta.kubernetes.io/aws-load-balancer-nlb-target-type annotation gets ignored.

https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.4/guide/service/nlb/

 

NLB - AWS Load Balancer Controller

Network Load Balancer AWS Load Balancer Controller supports Network Load Balancer (NLB) with instance or IP targets through Kubernetes service of type LoadBalancer with proper annotations. Instance mode Instance target mode supports pods running on AWS EC2

kubernetes-sigs.github.io

 

 

Deprecated from Version 2.3

service.beta.kubernetes.io/aws-load-balancer-type specifies the load balancer type. This controller reconciles those service resources with this annotation set to either nlb-ip or external.

 

……

 

  • [Deprecated] For type nlb-ip, the controller will provision an NLB with targets registered by IP address. This value is supported for backwards compatibility.
  • For type external, the NLB target type depends on the nlb-target-type annotation.

 

limitations : This annotation should not be modified after service creation.

service.beta.kubernetes.io/aws-load-balancer-type: external

https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.4/guide/service/annotations/#lb-type

 

Annotations - AWS Load Balancer Controller

Annotations Service annotations Annotation keys and values can only be strings. All other types below must be string-encoded, for example: boolean: "true" integer: "42" stringList: "s1,s2,s3" stringMap: "k1=v1,k2=v2" json: "{ \"key\": \"value\" }" Annotati

kubernetes-sigs.github.io

 

 

Current Suggestions

  • 1안 ) AWS LoadBalancer Controller v2.4 버전으로 최신화
    + service.beta.kubernetes.io/aws-load-balancer-type: external
    + service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip
  • 2안) AWS LoadBalancer Controller v2.2 버전으로 사용
    + service.beta.kubernetes.io/aws-load-balancer-type: nlb-ip
    - service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip