신규 개발 쿠버네티스 서버 구축과 기존 개발 클러스터 연동 방안

신규 개발 쿠버네티스 서버 구축과 기존 개발 클러스터 연동 방안

신규 개발용 New Vector 쿠버네티스 서버를 구축하고, 기존 개발 쿠버네티스 환경과 통신할 수 있도록 연결하는 작업은 단순한 서버 추가가 아니라 이미지 업로드 경로, 클러스터 간 네트워크, 접근 권한, 운영 검증까지 함께 설계해야 하는 작업이다. 이번 구성의 핵심 목적은 신규 쿠버네티스 환경에서 기존 개발 쿠버네티스 이미지 업로드 흐름을 사용할 수 있도록 안정적인 통신 구조를 만드는 데 있다.

구축 목적

기존 개발 환경에는 이미 쿠버네티스 클러스터가 구성되어 있으며, 해당 환경은 worker, master, session 영역으로 운영되고 있다. 여기에 신규 개발용 New Vector 쿠버네티스 서버를 추가로 구성하고, 기존 개발 쿠버네티스와 상호 통신이 가능하도록 연결하는 것이 이번 작업의 주요 목표다.

특히 신규 개발 쿠버네티스 서버는 별도의 Docker Repository 환경을 보유하고 있으며, 기존 개발 쿠버네티스에서 사용하는 이미지 업로드 흐름과 연결되어야 한다. 따라서 단순히 신규 서버를 생성하는 수준을 넘어, 기존 클러스터의 각 구성 요소와 신규 클러스터가 필요한 포트와 경로로 통신할 수 있는지 확인해야 한다.

구분	내용
기존 환경	개발 쿠버네티스 클러스터, worker·master·session 구성 포함
신규 환경	New Vector 개발 쿠버네티스 서버 신규 생성
저장소	신규 개발 서버에서 사용할 Docker Repository 구성
연동 범위	기존 worker, master, session 전체와 통신 연결
주요 목적	신규 쿠버네티스에서 기존 개발 쿠버네티스 이미지 업로드 경로 사용

전체 구성 방향

신규 개발 쿠버네티스 서버는 기존 개발 쿠버네티스와 분리된 환경으로 생성하되, 이미지 업로드와 배포 흐름에 필요한 통신만 명확하게 허용하는 방식으로 구성하는 것이 적절하다. 모든 포트를 무조건 개방하기보다는 Docker Repository, 쿠버네티스 API, 내부 서비스 호출, 세션 관련 통신에 필요한 경로를 기준으로 접근 범위를 정리해야 한다.

실무 기준으로 보면 신규 클러스터 구축에서 가장 중요한 부분은 통신 범위 정의다.
기존 개발 쿠버네티스의 worker, master, session 전체와 연결해야 하더라도 모든 접근을 열어두면 관리 위험이 커진다.
신규 New Vector 쿠버네티스 서버가 이미지 업로드에 필요한 대상만 접근하도록 방화벽, 라우팅, 인증정보를 함께 정리하는 것이 좋다.
관리자 입장에서는 통신 허용 목록과 실제 배포 흐름이 일치하는지 검증하는 과정이 필수다.

구성은 크게 네 단계로 나눌 수 있다. 첫째, 신규 개발 쿠버네티스 서버와 Docker Repository를 준비한다. 둘째, 기존 개발 쿠버네티스의 worker, master, session 구간과 네트워크 통신을 연결한다. 셋째, 이미지 업로드와 Pull 흐름을 검증한다. 넷째, 로그와 접근 권한을 기준으로 운영 안정성을 확인한다.

신규 New Vector 쿠버네티스 서버 생성

신규 개발 서버는 New Vector 전용 개발 환경으로 사용될 예정이므로, 기존 개발 쿠버네티스와 동일한 기준의 기본 운영 구성을 맞추는 것이 좋다. 쿠버네티스 버전, 컨테이너 런타임, 네트워크 플러그인, DNS 설정, 인증서 관리 방식이 기존 개발 환경과 크게 다르면 통신 검증 과정에서 예외가 늘어날 수 있다.

Docker Repository가 이미 준비되어 있다면, 신규 쿠버네티스에서 해당 저장소로 이미지 Push와 Pull이 가능한지 먼저 확인해야 한다. 이후 기존 개발 쿠버네티스에서 사용하던 이미지 업로드 경로와 신규 저장소 경로를 연결해 이미지가 어느 위치에서 생성되고, 어느 저장소에 올라가며, 어떤 클러스터에서 가져가는지 흐름을 명확히 해야 한다.

신규 서버 준비 시 확인 항목

• 신규 New Vector 개발 서버의 IP, 호스트명, 도메인 설정
• 쿠버네티스 master 또는 control plane 구성 방식
• worker node 등록 여부와 리소스 할당 기준
• Docker Repository 접근 주소와 인증 방식
• 이미지 Push, Pull에 필요한 계정과 Secret 구성
• 기존 개발 쿠버네티스와 통신할 네트워크 대역 확인

기존 개발 쿠버네티스와 통신 연결

신규 개발 New Vector 쿠버네티스는 기존 개발 쿠버네티스의 worker, master, session 전체와 통신할 수 있어야 한다. 이때 통신 목적이 이미지 업로드와 배포 연동에 있으므로, 각 구간에서 필요한 접근 방향을 먼저 정리하는 것이 중요하다.

연동 대상	통신 목적	확인 사항
기존 master	클러스터 제어, API 접근, 배포 상태 확인	API 서버 접근 가능 여부, 인증서 또는 토큰 권한 확인
기존 worker	이미지 Pull, 컨테이너 실행, 내부 서비스 연결	Repository 접근 가능 여부, 노드 방화벽 정책 확인
기존 session	세션 기반 서비스 호출 또는 개발 환경 연동	세션 서비스 포트, 내부 DNS, 라우팅 정책 확인
신규 Docker Repository	이미지 업로드 및 배포 이미지 제공	Push 권한, Pull 권한, TLS 인증서, 저장소 주소 확인

네트워크 연결은 양방향 통신이 필요한 구간과 단방향 통신만 필요한 구간을 분리해 설계해야 한다. 예를 들어 신규 쿠버네티스에서 기존 Repository로 이미지를 업로드해야 한다면 신규 서버에서 저장소로 나가는 통신이 필요하다. 반대로 기존 개발 쿠버네티스가 신규 Repository에서 이미지를 가져가야 한다면 기존 worker node에서 신규 Repository로 접근하는 경로가 열려 있어야 한다.

이미지 업로드 흐름 설계

이번 연동의 핵심은 신규 쿠버네티스 환경이 기존 개발 쿠버네티스의 이미지 업로드 흐름과 연결되는 것이다. 따라서 이미지를 빌드하는 위치, 저장하는 위치, 배포 시 가져가는 위치를 명확히 구분해야 한다.

단계	처리 내용	점검 포인트
1단계	신규 개발 서버에서 이미지 빌드	Dockerfile, 태그 규칙, 빌드 권한 확인
2단계	Docker Repository로 이미지 업로드	Push 인증정보, 저장소 주소, 네트워크 접근 확인
3단계	기존 개발 쿠버네티스에서 이미지 Pull	worker node의 Repository 접근 가능 여부 확인
4단계	기존 또는 신규 클러스터에 배포 반영	Deployment, Pod 상태, 이미지 태그 일치 여부 확인
5단계	서비스 동작 검증	session 연동, 내부 호출, 로그 이상 여부 확인

이미지 업로드 흐름에서 반드시 정리해야 할 기준
이미지 태그는 개발 환경에서 추적 가능하도록 날짜, 브랜치, 빌드 번호 중 하나를 포함하는 것이 좋다.
동일한 latest 태그만 반복 사용하면 장애 발생 시 어떤 이미지가 배포됐는지 확인하기 어렵다.
Repository 인증정보는 클러스터 Secret으로 관리하고, 계정 권한은 Push 전용과 Pull 전용으로 분리하는 것이 안전하다.
실제 사용 시에는 신규 쿠버네티스와 기존 쿠버네티스 모두 동일한 저장소 주소를 바라보는지 확인해야 한다.

방화벽과 권한 설정 기준

신규 개발 쿠버네티스와 기존 개발 쿠버네티스가 연결되면 편의성은 높아지지만, 동시에 공격 표면도 넓어질 수 있다. 따라서 이미지 업로드와 배포에 필요한 최소 범위만 허용하는 방식으로 방화벽과 권한을 설정해야 한다.

• 신규 쿠버네티스에서 Docker Repository로 Push 가능한지 확인
• 기존 worker node에서 Docker Repository로 Pull 가능한지 확인
• 기존 master API 접근은 필요한 계정과 대역에서만 허용
• session 구간은 필요한 서비스 포트만 제한적으로 허용
• Repository 계정은 관리자 권한 대신 Push, Pull 목적별 권한으로 분리
• 외부에서 Repository 관리 화면에 직접 접근하지 못하도록 제한

특히 master 영역은 클러스터 제어 권한과 연결되므로 접근 대상을 명확하게 제한해야 한다. worker 영역은 이미지 Pull과 서비스 통신이 정상적으로 되는지 확인하되, 불필요한 포트를 열어두지 않는 것이 좋다. session 영역은 개발 서비스 특성에 따라 내부 호출이 많을 수 있으므로 어떤 서비스가 어떤 방향으로 호출되는지 사전에 목록화해야 한다.

구축 후 검증 절차

서버 생성과 네트워크 연결이 완료되면 실제 이미지 업로드부터 배포까지 전체 흐름을 한 번에 검증해야 한다. 단순히 ping이나 포트 연결만 확인하는 것보다, 실제 개발 이미지가 빌드되고 Repository에 업로드된 뒤 기존 개발 쿠버네티스에서 정상적으로 가져가는지 확인하는 것이 중요하다.

검증 항목	정상 기준
네트워크 연결	신규 쿠버네티스에서 기존 master, worker, session 대상 통신 가능
Repository 접근	이미지 Push와 Pull이 인증 오류 없이 처리
이미지 배포	Deployment 반영 후 Pod가 정상 Running 상태로 전환
서비스 호출	session 관련 서비스와 내부 API 호출이 정상 처리
로그 확인	인증 실패, 이미지 Pull 실패, DNS 실패 로그가 반복되지 않음

검증 과정에서 이미지 Pull 오류가 발생한다면 Repository 주소, Secret 설정, 인증 계정 권한, worker node의 네트워크 경로를 순서대로 확인해야 한다. API 접근 오류가 발생한다면 master 접근 제어, kubeconfig 권한, 인증서 만료 여부를 함께 점검하는 것이 좋다.

운영 안정성을 위한 관리 포인트

신규 개발 New Vector 쿠버네티스 서버가 기존 개발 쿠버네티스와 연결되면 이후에는 변경 관리가 중요해진다. 이미지 태그 규칙, Repository 계정 관리, 네트워크 허용 정책, 클러스터 접근 권한이 문서화되어 있어야 담당자가 바뀌거나 장애가 발생해도 빠르게 원인을 추적할 수 있다.

또한 기존 개발 쿠버네티스의 worker, master, session 중 어느 구간에서 장애가 발생했는지 구분할 수 있도록 로그 확인 기준을 마련해야 한다. 이미지 업로드 실패인지, 이미지 Pull 실패인지, 배포 실패인지, 서비스 통신 실패인지에 따라 점검 위치가 달라지기 때문이다.

최종적으로 이번 구성은 신규 개발 환경과 기존 개발 환경의 연결 지점을 명확히 만드는 작업이다.
New Vector 쿠버네티스 서버는 독립적으로 생성하되, 이미지 업로드와 배포에 필요한 경로는 기존 쿠버네티스와 연결한다.
worker, master, session 전체 통신은 허용하되 목적별로 접근 권한을 제한한다.
Docker Repository는 이미지 흐름의 중심이므로 인증정보, 태그 규칙, 접근 로그를 함께 관리해야 한다.

정리

신규 개발 쿠버네티스 서버 구축은 단순히 클러스터를 하나 더 만드는 작업이 아니다. 기존 개발 쿠버네티스의 worker, master, session 구성과 통신해야 하고, 신규 Docker Repository를 통해 이미지 업로드와 배포 흐름까지 연결되어야 한다.

따라서 구축 단계에서는 서버 생성, 네트워크 연결, Repository 인증, 이미지 업로드, 기존 클러스터 Pull, 서비스 검증을 하나의 흐름으로 설계해야 한다. 이 기준을 갖추면 신규 New Vector 개발 환경에서도 기존 개발 쿠버네티스와 안정적으로 연동하며 이미지 배포와 테스트를 진행할 수 있다.