YWS 문서
YWS 콘솔로 이동
네트워크/네트워크

네트워크

네트워크 캔버스

"네트워크" 탭은 EC2/Lambda/로드밸런서/DB를 드래그해서 배치하고 선(엣지)으로 연결하는 시각적 방화벽 관리 도구입니다. 엣지 하나 = NetworkPolicy 오브젝트 하나(포트 범위 + 방향 지정 가능).

왼쪽 패널: 맨 위 + 로드밸런서 추가(캔버스에 새로 만듦), 그 아래 EC2 / Lambda / DB 칸이 따로 있고 칸마다 아직 캔버스에 없는 내 리소스와 + 추가 버튼. 좁은 화면의 목록 보기도 같은 구성입니다.

DB 연결 (EC2 → DB)

내가 만든 DB도 캔버스에 올릴 수 있습니다. DB 노드는 점선 테두리에 "외부 접근 불가" 표시.

  • DB는 인터넷에서 절대 접근할 수 없음 — 도메인/인바운드, 로드밸런서 멤버, 인터넷 설정이 없고, DB에서 나가는 연결도 못 만듦

  • EC2의 ●를 DB로 끌어 이으면 그 EC2만 그 DB의 서버(PostgreSQL 5432 / MySQL 3306 / Redis 6379)에 접속 가능 — 포트를 묻지 않고 바로 연결됨 (점선 화살표). DB 노드에 종류가 표시됨

  • 이은 순간 그 EC2 안에 ~/.yws/databases/DB이름.env 파일이 생김 (DATABASE_URL과 종류별 변수 — PostgreSQL PG*, MySQL MYSQL_*, Redis REDIS_URL·REDISCLI_AUTH, 권한 600):

    set -a; . ~/.yws/databases/my_db.env; set +a
psql                       # PostgreSQL (sudo apt install postgresql-client)
redis-cli -u "$REDIS_URL"  # Redis (sudo apt install redis-tools)
python app.py              # 앱은 os.environ["DATABASE_URL"]만 읽으면 됨

  • 연결선을 누르면 "접속 정보 다시 쓰기"(EC2가 꺼져 있을 때 이었거나 파일을 지웠을 때) / "연결 끊기"

  • DB 비밀번호를 재발급하면 이어진 EC2들의 파일도 자동 갱신. 연결을 끊거나 EC2/DB/네트워크를 지우면 접속이 다시 막히고 파일도 지워짐

  • Lambda는 이을 필요 없이 바로 접속 가능 (그래서 Lambda → DB 선은 만들지 않음)

  • 주의: 파일에 비밀번호가 들어 있어서, 그 EC2를 공유받은 사람도 읽을 수 있음

  • 구현: 선마다 정책을 만들지 않고, DB 서버마다 "그 종류의 DB로 선이 이어진 EC2 전체"로 db 네임스페이스의 network-db-access-<종류> 정책 하나를 매번 다시 씀 (app/db_links.py, provisioning.sync_db_access_policy). 이어진 EC2가 하나도 없으면 정책 자체를 지움 — 빈 허용 목록이 "전부 허용"으로 뒤집히는 NetworkPolicy 함정 때문. DB마다의 격리는 네트워크가 아니라 DB 계정·비밀번호가 담당 (같은 서버의 다른 DB는 접속 권한 자체가 없음)

NetworkPolicy 모델 (3단 구조)

  1. 기본 정책 (EC2 생성 시 자동 부여): 인바운드는 집 LAN에서 오는 SSH(2222)만 허용, 아웃바운드는 기본 전체 허용
  2. 인바운드 정책: 도메인 연결(도메인 / 인바운드 참고)로 Traefik이 그 EC2에 닿을 수 있게 해주는 정책, 활성 포트가 바뀔 때마다 통째로 재생성
  3. 엣지 정책: 네트워크 캔버스에서 그은 선 하나당 하나, 다른 EC2/로드밸런서 pod를 선택자로 지정

이 세 종류는 전부 같은 pod에 누적 적용됩니다 (k8s NetworkPolicy는 여러 개 붙어도 OR로 합쳐짐).

로드밸런서 — Pod 재시작 없는 멤버 관리

로드밸런서에 EC2를 넣고 빼는 건 원래 "멤버 공용 라벨을 Pod 템플릿에 패치"하는 방식이었는데, 이러면 Deployment 템플릿이 바뀌어서 멤버가 바뀔 때마다 그 EC2의 Pod가 강제로 재시작됐습니다 (수동으로 켠 프로세스가 죽는 부작용 실제 발견).

지금은 selector 없는 Service + 직접 관리하는 Endpoints 방식으로 바꿔서, 멤버 추가/제거가 Pod를 전혀 건드리지 않습니다. 대신 k8s가 자동으로 해주던 Endpoint 정합성 관리를 포털이 직접 책임져야 해서, 30초마다 도는 백그라운드 리컨사일 잡이 멤버들의 실제 Pod IP를 다시 확인해서 동기화합니다.