DEVOCEAN

지난글 목록

• MSA와 DevOps를 적용하여 상용 서비스 출시를 위해 힙(Hip)한 기술 모두 사용해보기

지난번 대략적인 소개에 이어 현재 AWS에서 서비스 운영중인 환경 및 정책에 대해서 간략히 소개하고자 한다.

그전에 현재 서비스의 조건에 대해서 정보를 드리면 아래와 같다.

• 대국민 서비스 (Any Open 필요)
• 개인정보 처리 시스템 (망분리 필요)

위 조건을 바탕으로 아래와 같은 Architecture가 결정 되었다.

VPC / Subnet / EKS Cluster 정책

• Availability Zone은 3개를 할당하여 가용성을 높히기

• Public/Private Subnet 각각 3개 생성하여 Security 강화

  • Public Subnet에는 NAT Gateway, Bastion Server(Kubectl 전용)만 설치

  • EKS Cluster Node는 Private Subnet에 설치하여 모든 서비스(WEB/WAS)를 Private zone에서 운영. EKS node는 SSH 접속이 필요 없음.

• Load Balancer 분리

  • Application 전용 ALB(Application Load Balancer)를 설치하여 Any open 적용하고, 서비스만 담당

  • Management  전용 Classic Load Balancer를 설치하여 SSH 및 ArgoCD CI/CD등 Management 전용으로 운영하고, Security Group은 회사 사내 IP 대역만 연결.

서비스 도메인 DNS Setting

현재 모바일 지갑 서비스는 아래 기본 Domain에 다양한 Sub Domain을 사용하고 있다.  하지만 모든 Sub Domain은 하나의 L/B cname만 사용하고 있고, 실제 Routing은 Istio Gateway에서 처리를 한다.

실제 서비스에 적용된 Istio ingress 내부 routing을 위한 patch-istio-ingress.yaml의 Example (실제 domain name만 가상으로 변경)

Istio ingress gateway의 설정에 대한 부분은 다음 시간에 자세히 다룰예정.

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: mwp-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - www.domain.co.kr
    - admin.domain.co.kr
    - portal.domain.co.kr

---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: platform-vs
spec:
  hosts:
  - www.domain.co.kr
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: admin-vs
spec:
  hosts:
  - admin.domain.co.kr
---

domain 이후 uri를 match하여 해당 Service로 routing 기능도 가능하다. 이를 통해 back-end와 front-end를 동일한 URL로 철하고 있다.

##################################################################################################
# Platform virtual service
##################################################################################################
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: platform-vs
spec:
  hosts:
  - "*"
  gateways:
  - mwp-gateway
  http:
  # Cloud Agent Datastore
  - match:
      - uri:
          prefix: /agent/ds/
      - uri:
          prefix: /agent/ds
    rewrite:
      uri: /
    route:

Cluster 내부의 network flow를 최종 정리 하면, admin 서비스 요청이 들어왔을때 아래 그림과 같다

1. DNS에서 ALB 연결
2. ALB에서 Istio ingress gateway로 요청 전달
3. Istio gateway에서 admin virtual service로 요청 전달
4. Virtual service에서 해당 service로 요청 전달
5. 실제 pod에서 서비스 동작

Summary

• Private Subnet에 EKS node를 모두 설치하여 보안 강화. 심지어 Web service도 public이 아닌 private subnet에서 관리
• Bastion을 통해 kubectl으로 kubernetes 설정을 진행하고, SSH 사용은 안함
• 모든 domain은 하나의 cname으로 mapping 관리하고, Istio ingress에서 나머지 서비스 routing 관리하여 DNS 관리에 대한 부담 최소화

Appendix : AWS에 EKS기반 Kubernetes Cluster 생성하기

AWS 에 EKS 생성을 위한 가장 손쉬운 방법은 eksctl 을 사용하는 것이다. 그리고 eksctl cli를 실행시킬 환경은 laptop 보다는 AWS 에 bastion 서버를 만들어서 그곳에서 실행하는걸 추천한다. (laptop 에 이런 저런 환경을 옮겨가면서 작업하다보면 실수한다. 그리고 관리도 힘들다)

AWS User 생성

우선 AWS IAM 에서 programatically 사용가능하도록 admin user를 만들고 해당 user 의 AWS Access Key ID 및 AWS Secret Access Key를 획득한다.

Bastion 서버 생성

그리고 AWS에 bastion 서버를 만들자. instance type은 t2.small 이어도 충분하다. (free tier 도 상관없다) 그리고 적절히 security group 을 만들어서 서버로 들어간다.

kubectl 설치

원하는 kubernetes 버전의 kubectl 설치
https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html

$ curl -o kubectl https://amazon-eks.s3.us-west-2.amazonaws.com/1.21.2/2021-07-05/bin/linux/amd64/kubectl
$ chmod +x ./kubectl
$ mkdir -p $HOME/bin && cp ./kubectl $HOME/bin/kubectl && export PATH=$PATH:$HOME/bin
$ echo 'export PATH=$PATH:$HOME/bin' >> ~/.bashrc
$ kubectl version --short --client

AWS cli 설치

eksctl 을 사용하려면 AWS user의 credentil 설정이 필요하다. aws cli 를 설치한다.
https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html

$ sudo apt install unzip
$ curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install

AWS cli configuration 설정

이제 aws cli 에 configuration 을 설정한다. 이때 위에서 획득한 credential을 사용한다. region 은 Seoul(ap-northeast-2)을 사용
https://docs.aws.amazon.com/cli/latest/userguide/getting-started-quickstart.html

$ aws configure
AWS Access Key ID [None]: ~~~
AWS Secret Access Key [None]: ~~~
Default region name [None]: ap-northeast-2
Default output format [None]: json

eksctl cli 설치

eksctl cli 를 설치한다.
https://docs.aws.amazon.com/eks/latest/userguide/eksctl.html

$ curl --silent --location "https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz" | tar xz -C /tmp
$ sudo mv /tmp/eksctl /usr/local/bin
$ eksctl version

EKS Cluster 생성

eksctl cli로 EKS Cluster 를 생성한다.

$ eksctl create cluster \
--version 1.21 \
--name eks-demo \
--vpc-nat-mode HighlyAvailable \
--node-private-networking \
--region ap-northeast-2 \
--node-type t3.medium \
--nodes 2 \
--with-oidc \
--ssh-access \
--ssh-public-key thomas \
--managed

• version: 사용할 Kubernetes 버전

• vpc-nat-mode: kubernetes의 모든 outbound는 nat gateway를 통해 나가게 되는게 default option 은 single 이라 하나만 생성된다. 개발 환경에서는 상관없을거 같지만 운영에서는 각 subnet 마다 하나씩 만드는 HighAvailable 옵션을 사용한다.

• node-private-networking: 해당 option 이 없으면 node group 이 public subnet 에 만들어진다. 보안을 위해 private subnet 에 만들어지도록 이 옵션을 사용한다.

• node-type: 생성될 node의 instance 타입

• nodes: 생성 될 node의 갯수

cluster 가 잘 생성되었는지 확인한다.

$ kubectl get nodes -o wide

EKS 보안 관련 설정

여기까지 하면 상용에서 사용할 수 있도록 HA를 고려한 secure 한 방법으로 Kubernets cluster 가 생성된다. 하지만 보안을 위해 한가지를 더 해주어야 한다. 현재 상태는 cluster endpoint가 public 하게 허용되어 있다.
https://aws.amazon.com/blogs/containers/de-mystifying-cluster-networking-for-amazon-eks-worker-nodes/
https://docs.aws.amazon.com/eks/latest/userguide/cluster-endpoint.html

이를 제약하기 위해 private access 를 허용하고 CIDR 블록 제한으로 bastion 서버에서만 kubernetes 에 명령을 내릴 수 있도록 수정한다. bastion server의 Public IPv4 address 를 입력한다.

$ eksctl utils update-cluster-endpoints --cluster=eks-demo --private-access=true --public-access=true --approve
$ eksctl utils set-public-access-cidrs --cluster=eks-demo 1.1.1.1/32 --approve

1.1.1.1/32 는 bastion 서버의 주소를 넣는다.

사실 EKS Cluster 생성 작업은 eksctl의 --dry-run 옵션으로 yaml 파일을 만들어서 생성부터 EKS 보안 관련 설정까지 모두 옵션을 주고 한번에 만들 수도 있다.