'subnet'에 해당하는 글 2건

aws-nlb

 

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

 

 

NLB 구동 테스트

 

NLB 를 사용할 계획은 아니지만 샘플이 간단해서 기록해 본다. NLB 를 통해 nginx 의 첫화면을 확인하는 샘플. 어플리케이션 정상 배포 확인하고, NLB 정상 구동 확인하고, 브라우저에서 nginx 확인하고...

 

 

1. Sample namespace

 

$ kubectl create namespace nlb-sample-app

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

 

 

2. nginx 어플리케이션 배포

 

$ vi sample-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nlb-sample-app
  namespace: nlb-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
$ kubectl apply -f sample-deployment.yaml
Deployment/nlb-sample-app created

 

 

3. NLB 생성

 

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

 

$ 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
$ kubectl apply -f sample-service.yaml
Service/nlb-sample-service created

 

 

4. 서비스 확인

 

$ kubectl get svc nlb-sample-service -n nlb-sample-app
NAME            TYPE           CLUSTER-IP         EXTERNAL-IP                                                                    PORT(S)        AGE
sample-service  LoadBalancer   10.100.240.137   k8s-nlbsampl-nlbsampl-xxxxxxxxxx-xxxxxxxxxxxxxxxx.elb.us-west-2.amazonaws.com   80:32400/TCP   16h

 

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

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

 

nlb

 

 

5. 결과 확인

 

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

 

$ curl k8s-nlbsampl-nlbsampl-xxxxxxxxxx-xxxxxxxxxxxxxxxx.elb.us-west-2.amazonaws.com

 

nginx

 

 

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

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

 


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

,

AWS VPC 시나리오

Server/AWS 2019. 5. 17. 11:54

AWS 에서 VPC 마법사로 생성할 수 있는 VPC 시나리오로 다음의 4가지를 제공한다.

public 서브넷만 있는 VPC

public 및 private 서브넷이 있는 VPC

public 및 private 서브넷이 있고 VPN 액세스를 제공하는 VPC

private 서브넷만 있고 VPN 액세스를 제공하는 VPC


이 4가지의 VPC 구성을 알고나면 어떤 커스텀 VPC 구성도 가능하다. 하나씩 살펴보자.



1. public 서브넷만 있는 VPC


위 그림에는 다음 정보가 포함된다.

vpc : 10.0.0.0/16

public subnet : 10.0.0.0/24

ec2 : 10.0.0.6 (EIP: 198.51.100.2)

router : 10.0.0.0/16(local), 0.0.0.0/0(igw-id)

internet gateway

ec2 가 인터넷에 오픈되어 있는 웹서비스 등에 알맞는 구성이다. 서브넷은 모두 private 형태이므로 외부와의 통신이 가능하려면 internet gateway 를 두어야 하며, 나가는 트래픽에 대하여 routing table 에 올바르게 설정해야 한다. 10.0.0.0/16(local) 은 해당 vpc 의 다른 서브넷으로의 통신을 가능하게 하며, 0.0.0.0/0(igw-id) 는 외부 모든 트래픽은 igw-id 로 보낸다는 설정이다. 외부에서 해당 서비스(EC2 등) 에 접근할 수 있도록 Public IP 주소도 연결해야 한다. Public IP 주소가 없다면 외부로부터 요청을 받을 수가 없을 것이고, router 에 igw 로의 설정이 없다면 외부로 응답이나 요청을 할 수 없을 것이다. 보안적인 측면에서 보안그룹(security group) 과 network acl 로도 ip/port 에 대하여 허용/거부를 설정할 수 있는데 network acl 은 보통 다 열어놓고 보안그룹만 이용한다. 모든 포트가 차단된 상태에서 웹서비스시 80, 443 포트로 들어오는 요청은 모두 열어주고, 22 포트는 개발자 ip 정도만 열어주는 형태를 추천한다. 이것이 일반적인 public 서브넷의 형태이다. 



2. public 및 private 서브넷이 있는 VPC


위 그림에는 다음 정보가 포함된다.

vpc : 10.0.0.0/16

public subnet : 10.0.0.0/24

private subnet : 10.0.1.0/24

ec2(web) : 10.0.0.5~7 (EIP: 198.51.100.1~3)

ec2(db) : 10.0.1.5~7

router1 : 10.0.0.0/16(local), 0.0.0.0/0(igw-id)

router2 : 10.0.0.0/16(local), 0.0.0.0/0(nat-gw-id)

internet gateway

nat gateway

프론트엔드와 백엔드로 나누어 일반적으로 웹서버만 public 서브넷에 두고 DB 는 private 서브넷에 두어, 외부에서는 웹서버와 접근 가능하게 하고 DB 는 웹서버에서만 접근 가능하게 하는 구성이다. 굳이 노출할 필요없는 백엔드를 외부와 차단시키는 것에 중점을 둔 구성이다. public/private 구분을 위해 igw(인터넷 게이트웨이) 로 향하지 않도록 router 를 하나 더 추가해야 한다. 옵션이지만 private 서브넷에서 일방적으로 외부와 통신을 해야 한다면 nat 게이트웨이를 생성하고 router 에 nat 게이트웨이로 트래픽을 보내도록 routing 을 추가한다. igw 가 public 서브넷과 외부와의 양방향 통신이 가능하게 한다면, nat 게이트웨이는 public 서브넷에 위치하면서 private 서브넷에 대하여 외부로 단방향 통신(요청/응답) 이 가능하게 하며 응답을 받을 수 있도록 public IP 할당이 필요하다. 외부에서는 여전히 nat 게이트웨이로 서브넷과 통신할 수 없다. (nat 게이트웨이는 유료) 웹서버의 보안그룹 설정은 시나리오1과 동일, DB 보안그룹 설정은 웹서버 보안그룹ID 로부터 오는 해당 DB 전용포트만 열어주면 된다. 예로 mysql 의 경우 3306 포트.



3. public 및 private 서브넷이 있고 VPN 액세스를 제공하는 VPC


위 그림에는 다음 정보가 포함된다.

vpc : 10.0.0.0/16

public subnet : 10.0.0.0/24

private subnet : 10.0.1.0/24

ec2(web) : 10.0.0.5~7 (EIP: 198.51.100.1~3)

ec2(db) : 10.0.1.5~7

router1 : 10.0.0.0/16(local), 0.0.0.0/0(igw-id)

router2 : 10.0.0.0/16(local), 0.0.0.0/0(vgw-id)

internet gateway

vpn (virtual private gateway, customer gateway)

시나리오2번과 비슷하지만 private subnet 을 외부는 여전히 차단하고 특정 네트워크(customer gateway)와만 통신할 수 있도록 하는 구성이다. vpn 이라고 하는 가상 비공개 네트워크를 구현하여 vpn 에 연결되어야만 private subnet 과의 통신이 가능하다. vpc 콘솔에서 private 서브넷과 연결할 네트워크(customer gateway) 를 ip 와 함께 지정하고 virtual private gateway 생성, 그리고 그 둘을 이어주는 Site-to-Site VPN 연결을 구성하면 된다. (vpn 도 역시 유료) 서브넷의 보안그룹 설정은 vpn 으로 연결되는 네트워크 ip 대역으로부터 필요한 포트만 열어주면 된다.



4. private 서브넷만 있고 VPN 액세스를 제공하는 VPC


위 그림에는 다음 정보가 포함된다.

vpc : 10.0.0.0/16

private subnet : 10.0.0.0/24

ec2(web) : 10.0.0.5~7 (EIP: 198.51.100.1~3)

router : 10.0.0.0/16(local), 0.0.0.0/0(vgw-id)

vpn (virtual private gateway, customer gateway)

시나리오3번에서 public 서브넷만 제외한 구성이다. public 서브넷이 없으므로 igw 도 없다. vpn 과 연결된 특정 네트워크에서만 private 서브넷과 통신이 가능하며, 외부가 차단된 구성이다보니 서비스보다는 사내 인트라넷이나 개발 서버 등이 필요할 때 사용 가능한 구성이다.


이 중에 그나마 유용하게 쓸 수 있는 것이 2번이나 3번 시나리오 이다. 내가 선호하는 구성은 소규모 웹서비스의 경우 2번과 흡사하게. 더 큰규모의 웹서비스는 3번 시나리오에서 public subnet 에는 elb 만 두고 모든 자원을 private 서브넷으로, private 서브넷은 vpn 연결로 관리하는 것이 즐겨 사용하는 시나리오 이다. ^^


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

,