-
Notifications
You must be signed in to change notification settings - Fork 0
KR_AWS_Ingress
somaz edited this page Mar 30, 2026
·
1 revision
- AWS에서 ingress group은 여러 개의 ingress 리소스를 하나의 로드 밸런서(ALB)로 통합하여 관리할 수 있게 해주는 기능이다.
- 이를 통해 여러 Kubernetes 네임스페이스나 서로 다른 팀의 애플리케이션들이 같은 ALB를 공유하면서도 각기 다른 Ingress 규칙을 설정할 수 있다.
- ingress group을 사용하면 네트워크 리소스를 절약하고 관리 효율성을 높일 수 있다.
- 기본적으로 ingress는 ingress group에 속하지 않으며, ingress는 "implicit IngressGroup" 이며 즉, 독립적인 엔터티로 존재한다.
-
alb.ingress.kubernetes.io/group.name어노테이션을 사용하여 그룹 이름을 정의한다. - 동일한 그룹 이름을 가진 ingress 리소스는 하나의 ALB를 공유하게 된다.
- ingress group에 할당된 ALB는
ingress.k8s.aws/stack이이는 AWS 태그를 검색하여 찾는다.(리스너 규칙의 태그로 되어있음) 이 태그의 값으로 IngressGroup의 이름을 가지게 된다. - ingress group을 사용하지 않은 리소스들은 태그 값은
namespace/ingressname형식으로 설정한다. - ingress 리소스에 할당된 groupName을 변경하면, Ingress는 기존 그룹에서 새로운 IngressGroup으로 이동하게 되며, 새로운 IngressGroup의 ALB에서 관리된다.
- 만약 새로운 IngressGroup에 ALB가 없다면, 새로운 ALB가 자동으로 생성된다.
- ingress group의 ALB는 ingress group의 이름을 값으로 하는 AWS 태그
ingress.k8s.aws/스택 태그를 검색하여 찾을 수 있다. - example:
alb.ingress.kubernetes.io/group.name: my-team.awesome-group
-
alb.ingress.kubernetes.io/group.order어노테이션을 사용해 순서를 지정할 수 있다. - 낮은 숫자의 order 값을 가진 ingress 규칙이 우선 적용되며, 동일한 path나 host에 대해 특정 우선순위를 지정할 수 있다.
- example:
alb.ingress.kubernetes.io/group.order: 10
아래 예시에서 두 개의 ingress 리소스가 my-shared-group 이라는 그룹을 공유하게 되어 하나의 ALB에서 요청을 처리한다.
# Ingress for Service A
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: service-a-ingress
annotations:
alb.ingress.kubernetes.io/group.name: "my-shared-group"
alb.ingress.kubernetes.io/group.order: "10"
spec:
rules:
- host: "service-a.example.com"
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: service-a
port:
number: 80
# Ingress for Service B
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: service-b-ingress
annotations:
alb.ingress.kubernetes.io/group.name: "my-shared-group"
alb.ingress.kubernetes.io/group.order: "20"
spec:
rules:
- host: "service-b.example.com"
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: service-b
port:
number: 80-
service-a와service-b가 각각 ingress 그룹my-shared-group에 속하게 되며,service-a가order10으로 우선 적용된다.
- ALB가 수신하는 포트를 지정한다.
- Example:
alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS": 443}, {"HTTP": 8080}, {"HTTPS": 8443}]' - IngressGroup 내의 모든 Ingress에 적용되므로 각 Ingress는 고유한 포트를 정의할 수 있으며 규칙은 각 Ingress에 지정된 포트에만 적용된다.
- 동일한 수신 포트가 IngressGroup 내의 여러 Ingress에 의해 정의된 경우 IngressGroup의 순서에 따라 적용된다.
- 기본값:
listen-ports가 지정되지 않은 경우 인증서가 사용되지 않으면 기본값은{"HTTP": 80}이고 인증서가 제공되면{"HTTPS": 443}이다. - 경고: 동일한 그룹 내에서는 중복된 로드 밸런서 포트를 가질 수 없다. (예외 :
alb.ingress.kubernetes.io/group.order: 10지정) - ALB가 그룹의 모든 Ingress에 대해 이러한 설정을 통합하므로 IngressGroup 내 하나의 Ingress에서
listen-ports를 정의하는 것으로 충분하다.
- HTTP 트래픽이 리디렉션되는 포트(일반적으로 HTTPS 포트 443)를 지정하여 SSL 리디렉션을 활성화한다.
- Example:
alb.ingress.kubernetes.io/ssl-redirect: '443' - SSL 리디렉션(ssl-redirect)는 IngressGroup에 정의된 경우 그룹 내의 모든 Ingress에 영향을 준다.
- SSL 리디렉션이 활성화되면 모든 HTTP listener는 기본적으로 다른 HTTP 규칙을 무시하고 HTTPS로 리디렉션하도록 구성된다.
-
alb.ingress.kubernetes.io/ip-address-type- ALB가 IPv4 및 IPv6 트래픽 지원을 위해
ipv4또는dualstack을 사용해야 하는지 여부를 지정할 수 있다. - Example:
alb.ingress.kubernetes.io/ip-address-type: ipv4 or dualstack - ipv4: IPv4 주소만 사용하도록 ALB를 구성합니다. 즉, IPv4 트래픽을 독점적으로 처리한다.
- dualstack: ALB가 IPv4 및 IPv6 트래픽을 모두 지원할 수 있다.
dualstack으로 설정된 경우 ALB는 IPv4 및 IPv6 주소를 갖게 되어 두 주소 유형 모두에서 트래픽을 라우팅할 수 있다.
- ALB가 IPv4 및 IPv6 트래픽 지원을 위해
-
alb.ingress.kubernetes.io/customer-owned-ipv4-pool- Outpost 환경을 사용할 때 ALB에 대한 고객 소유 IPv4 주소 풀을 지정한다.
- 경고: 이 주석은 변경할 수 없다. 이를 변경하거나 제한하려면 Ingress를 다시 생성해야 한다.
- Example:
alb.ingress.kubernetes.io/customer-owned-ipv4-pool: ipv4pool-coip-xxxxxxx
-
alb.ingress.kubernetes.io/load-balancer-name- IngressGroup 내의 모든 Ingress는 동일한 load balancer 이름을 사용해야 한다.
- 이름은 32자를 초과할 수 없으며, 초과 시 오류가 발생한다.
-
alb.ingress.kubernetes.io/target-type-
instance모드는 서비스를 위해 열린 NodePort의 클러스터 내 모든 ec2 인스턴스로 트래픽을 라우팅한다. -
instance모드 사용시에는 서비스는 반드시NodePortorLoadbalancertype을 사용해야 한다. -
ip모드는 모든 트래픽을 pod로 라우팅한다. - 네트워크 플러그인은 pod IP가
ip모드를 사용하려면 ENI의 보조 IP 주소를 사용해야 한다. - amazon-vpc-cni-k8s
- sticky session이 애플리케이션 로드 밸런서와 함께 작동하려면
ip모드가 필요하다. ip 모드를 사용할 때 서비스 유형은 중요하지 않다.
-
-
alb.ingress.kubernetes.io/target-node-labels- 인스턴스 대상 유형의 target group 등록에 포함할 노드를 지정한다.
- Example:
alb.ingress.kubernetes.io/target-node-labels: label1=value1, label2=value2
-
alb.ingress.kubernetes.io/backend-protocol- 트래픽을 파드로 라우팅할 때 사용하는 프로토콜을 지정한다.
-
alb.ingress.kubernetes.io/backend-protocol-version- 트래픽을 포드로 라우팅하는 데 사용되는 애플리케이션 프로토콜을 지정한다. HTTP 또는 HTTPS가 백엔드 프로토콜로 사용될 때만 유효하다.
- Example:
alb.ingress.kubernetes.io/backend-protocol-version: HTTP2alb.ingress.kubernetes.io/backend-protocol-version: GRPC
-
alb.ingress.kubernetes.io/actions.${action-name}- redirection 작업과 같이 loadbalancer listener 규칙을 구성하는 방법을 제공한다.
- annotation의 serviceName은 ingress rule의 serviceName과 일치해야 하며, servicePort는 무조건
use-annotation을 줘야 한다.
-
alb.ingress.kubernetes.io/conditions.${conditions-name}- ingress의 호스트/경로 조건 외에 라우팅 조건을 지정하는 방법을 제공한다.
- annotation의 serviceName은 ingress rule의 serviceName과 일치해야 하며, servicePort는 무조건
use-annotation을 줘야 한다.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
namespace: default
name: ingress
annotations:
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/actions.rule-path1: >
{"type":"fixed-response","fixedResponseConfig":{"contentType":"text/plain","statusCode":"200","messageBody":"Host is www.example.com OR anno.example.com"}}
alb.ingress.kubernetes.io/conditions.rule-path1: >
[{"field":"host-header","hostHeaderConfig":{"values":["anno.example.com"]}}]
alb.ingress.kubernetes.io/actions.rule-path2: >
{"type":"fixed-response","fixedResponseConfig":{"contentType":"text/plain","statusCode":"200","messageBody":"Path is /path2 OR /anno/path2"}}
alb.ingress.kubernetes.io/conditions.rule-path2: >
[{"field":"path-pattern","pathPatternConfig":{"values":["/anno/path2"]}}]
alb.ingress.kubernetes.io/actions.rule-path3: >
{"type":"fixed-response","fixedResponseConfig":{"contentType":"text/plain","statusCode":"200","messageBody":"Http header HeaderName is HeaderValue1 OR HeaderValue2"}}
alb.ingress.kubernetes.io/conditions.rule-path3: >
[{"field":"http-header","httpHeaderConfig":{"httpHeaderName": "HeaderName", "values":["HeaderValue1", "HeaderValue2"]}}]
alb.ingress.kubernetes.io/actions.rule-path4: >
{"type":"fixed-response","fixedResponseConfig":{"contentType":"text/plain","statusCode":"200","messageBody":"Http request method is GET OR HEAD"}}
alb.ingress.kubernetes.io/conditions.rule-path4: >
[{"field":"http-request-method","httpRequestMethodConfig":{"Values":["GET", "HEAD"]}}]
alb.ingress.kubernetes.io/actions.rule-path5: >
{"type":"fixed-response","fixedResponseConfig":{"contentType":"text/plain","statusCode":"200","messageBody":"Query string is paramA:valueA1 OR paramA:valueA2"}}
alb.ingress.kubernetes.io/conditions.rule-path5: >
[{"field":"query-string","queryStringConfig":{"values":[{"key":"paramA","value":"valueA1"},{"key":"paramA","value":"valueA2"}]}}]
alb.ingress.kubernetes.io/actions.rule-path6: >
{"type":"fixed-response","fixedResponseConfig":{"contentType":"text/plain","statusCode":"200","messageBody":"Source IP is 192.168.0.0/16 OR 172.16.0.0/16"}}
alb.ingress.kubernetes.io/conditions.rule-path6: >
[{"field":"source-ip","sourceIpConfig":{"values":["192.168.0.0/16", "172.16.0.0/16"]}}]
alb.ingress.kubernetes.io/actions.rule-path7: >
{"type":"fixed-response","fixedResponseConfig":{"contentType":"text/plain","statusCode":"200","messageBody":"multiple conditions applies"}}
alb.ingress.kubernetes.io/conditions.rule-path7: >
[{"field":"http-header","httpHeaderConfig":{"httpHeaderName": "HeaderName", "values":["HeaderValue"]}},{"field":"query-string","queryStringConfig":{"values":[{"key":"paramA","value":"valueA"}]}},{"field":"query-string","queryStringConfig":{"values":[{"key":"paramB","value":"valueB"}]}}]
spec:
ingressClassName: alb
rules:
- host: www.example.com
http:
paths:
- path: /path1
pathType: Exact
backend:
service:
name: rule-path1
port:
name: use-annotation
- path: /path2
pathType: Exact
backend:
service:
name: rule-path2
port:
name: use-annotation
- path: /path3
pathType: Exact
backend:
service:
name: rule-path3
port:
name: use-annotation
- path: /path4
pathType: Exact
backend:
service:
name: rule-path4
port:
name: use-annotation
- path: /path5
pathType: Exact
backend:
service:
name: rule-path5
port:
name: use-annotation
- path: /path6
pathType: Exact
backend:
service:
name: rule-path6
port:
name: use-annotation
- path: /path7
pathType: Exact
backend:
service:
name: rule-path7
port:
name: use-annotation-
alb.ingress.kubernetes.io/scheme- AWS Application Load Balancer(ALB)와 함께 Kubernetes Ingress 구성에서 로드 밸런서 Access 유형을 정의하는 데 사용한다. 이 주석은 ALB가 인터넷 연결(퍼블릭)인지 내부(프라이빗)인지 여부를 AWS에 알려준다.
-
internet-facing: 인터넷을 통해 ALB에 공개적으로 액세스할 수 있도록 한다. -
internal: ALB가 VPC 또는 연결된 네트워크 내에서만 액세스 가능하도록 제한하여 비공개로 만든다.
-
alb.ingress.kubernetes.io/inbound-cidrs- 지정된 IP 범위(CIDR)만 연결하도록 허용하여 ALB에 대한 액세스를 제한한다.
- ALB에 액세스할 수 있는 IP 범위를 제한하여 개인 애플리케이션 또는 내부 리소스에 대한 액세스를 제어하는 데 특히 유용하다.
- Ingress가 IngressGroup의 일부인 경우
inbound-cidrs주석은 그룹의 모든 Ingress 리소스에 적용된다. - 그러나
inbound-cidrs은 해당 Ingress에 정의된 포트에만 적용된다. - 따라서 여러 인그레스가 동일한 수신 포트를 공유하는 경우 충돌을 방지하려면 해당 인그레스 중 하나에만
inbound-cidrs을 정의해야 한다. - Ingress에서
alb.ingress.kubernetes.io/security-groups을 지정하면 inbound-cidrs 주석이 무시된다. -
inbound-cidrs주석을 지정하지 않은 경우:- ALB의 IPAddressType 이 ipv4로 설정된 경우 0.0.0.0/0 (모든 IPv4 주소)가 허용된다.
- ALB의 IPAddressType 이 dualstack으로 설정된 경우 0.0.0.0/0 및 ::/0 (모든 IPv4 및 IPv6 주소)가 허용된다.
-
alb.ingress.kubernetes.io/security-groups- 로드밸런서에 연결할 보안 그룹을 지정한다.
- 해당 annotation이 없으면 컨트롤러가 자동으로 하나의 보안 그룹을 생성하고 보안 그룹이 로드밸런서에 연결되며
inbound-cidrs과security-group-prefix-lists에listen-ports액세스를 허용한다. 또한 Node/Pod 보안 그룹은 이 보안 그룹에서 인바운드 트래픽을 허용하도록 수정한다. 즉, 내가 생성한 보안그룹을 Pod와 Node에 적용하고 싶으면 사용하면 된다. - Example:
alb.ingress.kubernetes.io/security-groups: sg-xxxx, nameOfSg1, nameOfSg2
-
alb.ingress.kubernetes.io/manage-backend-security-group-rules- 보안 그룹을 지정할 때 트래픽 액세스를 위해 컨트롤러가 Node/Pod에 보안 그룹 규칙을 구성할지 여부를 지정한다.
-
alb.ingress.kubernetes.io/security-groups을 통해 보안 그룹을 지정한 경우에만 적용된다. - Example:
alb.ingress.kubernetes.io/manage-backend-security-group-rules: "true"