온프레미스 인프라 구현 예시

• 하나의 클러스터 안에 3대의 노드들 (마스터 1대, NFS용 Worker 1대, DB용 Worker 1대)
• 마스터 노드엔 API

aws에도 클러스터 하나 = 총 2개 클러스터 사용 예

Tailscale : vm과 aws vpc 양쪽에 설치하면 서로 같은 로컬망에 있는 것처럼 묶어버리는 오버레이 VPN 메쉬

현재 주의주인 애로 사항

• k8s로 온프레미스 구현
• 깃허브와 노트북의 버츄얼박스 간의 연결을 위해 공유기에서 노트북으로 포트포워딩을 설정하거나, Cloudflare Tunnels 같은 터널링 서비스를 이용해 노트북 내부의 k8s ingress를 임시 퍼블릭 도메인으로 뚫어줘야 함 → 고정 도메인을 만들려면 Cloudflare 계정과 도메인이 있어야 함
• AWS DMS와 노트북 안의 Mysql 데이터를 실시간으로 퍼가야 하고 (CDC), DR 발생 시 네트워크가 aws로 넘어가야 하는데 정석적인 AWS Site-to-Site VPN은 온프레미스 라우터에 공인 ip 하나가 고정되어 있어야 됨. AWS와 노트북 간 통신을 위해 VM과 AWS 안에 Tailscale 설치가 필요함 → → 먼저 버츄얼박스 마스터 노드에 Tailscale 설치. aws에 바스티온 역할 겸으로 아주 작은 ec2 하나를 띄우고 여기에도 Tailscale을 설치하여 서브넷 라우터 역할을 부여함 : 노트북 안의 k3s pod들이 AWS RDS와 서로 내부 ip로 통신되어 노트북 DB를 퍼갈 수 있게 됨
• k3s의 온프레미스와 EKS의 클라우드 동시 운영 시 문제
  1. 스토리지 불일치 - 개발자가 한 기능을 가진 YAML 파일을 만들 때 스토리지 클래스 이름을 지정해야 하는데 이를 k3s 스토리지 이름과 EBS 이름 둘 다 지정이 불가능함 → k3s 전용 파일 하나, EKS 전용 파일 하나 두 개를 만들어야 되는 불편함
  • k3s : 로컬 디스크 or NFS 스토리지 사용
  • EKS : RDS or EBS(AWS 블록 스토리지) 사용
  • 이것 외에 야말 파일 작성 시 주석 값이 다르다든지 양쪽 클러스터가 트래픽을 받는 문법 자체가 다른 문제 발생 → 이를 위해 Helm or Kustomize 을 사용함 : 온프레미스에만 적용할 스토리지와 로드밸런서 설정 따로, EKS에만 적용할 스토리지와 로드밸런서 설정 따로 이렇게 구분해주는 매니페스트 관리 도구 → 보통 헬름 사용한다고 함
  • aws에서 대기하고 있는 노드 1개에는 온프레미스에서 돌고있는 것과 똑같은 웹 서버가 설치되어 있어야 함. (nginx 등) 그래야 이 하나가 서비스 실행을 일단 받아서 응답하므로 콜드 스타트가 일어나지 않음
• API Server: 공장의 '안내 데스크'입니다. 이미지 왼쪽의 [3]번을 보면 인프라 엔지니어가 이곳으로 접속해서 "서버 3개 띄워!" 같은 명령을 내리는 것을 볼 수 있습니다.
• ETCD: 공장의 '기억 장치(DB)'입니다. "지금 우리 공장에 웹 서버가 3대 돌아가고 있어야 해"라는 모든 상태 정보가 여기에 저장됩니다.
• Pods (파드): K8s에서 가장 작은 단위로, 실제 여러분의 'Docker 컨테이너(웹 애플리케이션)'가 들어가서 실행되는 방입니다.
• Kubelet & K-Proxy: Kubelet은 마스터 노드의 지시를 받는 '작업반장'이고, K-Proxy는 파드들끼리 통신할 수 있게 길을 뚫어주는 '통신병'입니다.
• ING Controller (인그레스 컨트롤러): 외부에서 들어오는 트래픽(손님)을 알맞은 Pod(방)로 안내해 주는 **'정문 수위 아저씨(라우터)'**입니다.
• Deployment : 여러 노드에 레플리카셋 수만 큼 동일한 파드를 설치할 수 있음
• Deployment 예시