Bridge to Kubernetes 작동 방식

아티클
01/26/2025

메모

Bridge to Kubernetes는 2025년 4월 30일에 사용 중지됩니다. 사용 중지 및 오픈 소스 대안에 대한 자세한 내용은 GitHub문제를 참조하세요.

Bridge to Kubernetes Kubernetes를 대상으로 하는 마이크로 서비스 애플리케이션을 작성하기 위한 반복적인 개발 도구입니다. Bridge to Kubernetes 확장은 Visual Studio 및 VS Code(Visual Studio Code)에 사용할 수 있습니다.

Bridge to Kubernetes를 사용하면 개발 컴퓨터에서 코드를 실행하고 디버그할 수 있습니다. 해당 컴퓨터는 여전히 나머지 애플리케이션 또는 서비스를 사용하여 Kubernetes 클러스터에 연결됩니다. 상호 종속된 서비스 및 데이터베이스가 많은 대규모 마이크로 서비스 아키텍처가 있는 경우 개발 컴퓨터에서 이러한 종속성을 복제하는 것이 어려울 수 있습니다. 각 코드 변경에 대한 코드를 빌드하고 Kubernetes 클러스터에 배포하는 것은 느리고 시간이 오래 걸리며 어려울 수 있습니다.

Bridge to Kubernetes는 개발 컴퓨터와 클러스터 간에 연결을 만듭니다. 이 방법은 코드를 빌드하고 클러스터에 배포할 필요가 없습니다. 클러스터에 연결된 컨텍스트에서 서비스를 테스트하고 개발할 수 있습니다. 이 방법을 사용하면 더 이상 Docker 또는 Kubernetes 구성을 만들지 않고 디버그할 수 있습니다.

Bridge to Kubernetes는 연결된 Kubernetes 클러스터와 개발 컴퓨터 간의 트래픽을 리디렉션합니다. Kubernetes 클러스터의 로컬 코드 및 서비스는 동일한 Kubernetes 클러스터에 있는 것처럼 통신할 수 있습니다.

Bridge to Kubernetes를 사용하면 Kubernetes 클러스터의 환경 변수 및 탑재된 볼륨을 개발 컴퓨터에 복제할 수 있습니다. 환경 변수 및 탑재된 볼륨에 액세스하면 해당 종속성을 복제하지 않고도 코드에서 작업할 수 있습니다.

요구 사항

메모

Bridge to Kubernetes는 Desktop Kubernetes 클러스터용 Docker에서 작동하지 않습니다. Bridge to Kubernetes를 사용하려면 다음 구성 중 하나가 필요합니다.

Bridge to Kubernetes 확장 설치된 VS Code입니다.
Visual Studio 2019 버전 16.7 이상은 Windows 10 이상에서 실행됩니다. ASP.NET 및 웹 개발 워크로드가 설치되어 있는지 확인합니다. Bridge to Kubernetes 확장설치합니다.

Bridge to Kubernetes를 사용하여 Kubernetes 클러스터에 대한 연결을 설정할 수 있습니다. 이 연결은 클러스터의 기존 Pod와 개발 컴퓨터 사이에서 트래픽을 양방향으로 리디렉션합니다.

메모

Bridge to Kubernetes를 사용하는 경우 개발 컴퓨터로 리디렉션할 서비스 이름을 묻는 메시지가 표시됩니다. 이 옵션은 리디렉션을 위한 pod를 식별하는 편리한 방법입니다. Kubernetes 클러스터와 개발 컴퓨터 간의 모든 리디렉션은 pod에 대한 것입니다. 자세한 내용은 서비스를 사용할 수 있게 하기를 참조하십시오..

VS Code에서 Bridge to Kubernetes는 로컬로 실행할 수 있는 한 모든 언어를 지원합니다. Visual Studio에서 Bridge to Kubernetes는 .NET Core를 지원합니다. Bridge to Kubernetes는 Windows 노드 지원이 필요하기 때문에 Visual Studio에서 .NET Framework를 지원하지 않습니다.

주의

Bridge to Kubernetes는 개발 및 테스트 시나리오에서만 사용하기 위한 것입니다. 현재 사용 중인 프로덕션 클러스터 또는 라이브 서비스에서 사용하기 위한 것이 아니거나 지원되지 않습니다.

현재 기능 및 향후 계획은 Bridge to Kubernetes 로드맵참조하세요.

연결 설정

Bridge to Kubernetes가 클러스터에 대한 연결을 설정하는 경우 다음 작업을 수행합니다.

클러스터에서 바꿀 서비스, 코드에 사용할 개발 컴퓨터의 포트 및 코드의 시작 작업을 일회성 작업으로 구성하라는 메시지가 표시됩니다.
클러스터의 Pod에 있는 컨테이너를 개발 컴퓨터로 트래픽을 리디렉션하는 원격 에이전트 컨테이너로 바꿉니다.
개발 컴퓨터에서 kubectl 포트 포워드 명령 을(를) 실행하여 개발 컴퓨터의 트래픽을 클러스터에서 실행 중인 원격 에이전트에 전달합니다.
원격 에이전트를 사용하여 클러스터에서 환경 정보를 수집합니다. 이 환경 정보에는 환경 변수, 표시되는 서비스, 볼륨 탑재 및 비밀 탑재가 포함됩니다.
개발 컴퓨터의 서비스가 클러스터에서 실행 중인 것처럼 동일한 변수에 액세스할 수 있도록 Visual Studio에서 환경을 설정합니다.
호스트 파일을 업데이트하여 클러스터의 서비스를 개발 컴퓨터의 로컬 IP 주소에 매핑합니다. 이러한 호스트 파일 항목을 사용하면 개발 컴퓨터에서 실행되는 코드가 클러스터에서 실행되는 다른 서비스에 대한 요청을 할 수 있습니다. 호스트 파일을 업데이트하려면 Bridge to Kubernetes는 개발 컴퓨터에서 관리자 액세스 권한이 필요합니다.
개발 컴퓨터에서 코드 실행 및 디버깅을 시작합니다. 필요한 경우 Bridge to Kubernetes는 현재 해당 포트를 사용하는 서비스 또는 프로세스를 중지하여 개발 컴퓨터에서 필요한 포트를 해제합니다.

Bridge to Kubernetes 사용

클러스터에 대한 연결을 설정한 후 컨테이너화 없이 컴퓨터에서 기본적으로 코드를 실행하고 디버그합니다. 코드는 클러스터와 상호 작용합니다. 원격 에이전트가 수신하는 모든 네트워크 트래픽은 연결 중에 지정된 로컬 포트로 리디렉션됩니다. 고유하게 실행되는 코드는 해당 트래픽을 수락하고 처리할 수 있습니다. 클러스터의 환경 변수, 볼륨 및 비밀은 개발 컴퓨터에서 실행되는 코드에 사용할 수 있습니다.

Bridge to Kubernetes는 파일 항목 및 포트 전달을 호스트를 개발자 컴퓨터에 추가합니다. 코드는 클러스터의 서비스 이름을 사용하여 클러스터에서 실행되는 서비스에 네트워크 트래픽을 보낼 수 있습니다. 해당 트래픽은 클러스터에서 실행 중인 서비스로 전달됩니다. 트래픽은 연결된 전체 시간 동안 개발 컴퓨터와 클러스터 간에 라우팅됩니다.

또한 Bridge to Kubernetes는 KubernetesLocalProcessConfig.yaml 파일을 통해 개발 컴퓨터의 클러스터에서 Pod에 사용할 수 있는 환경 변수 및 탑재된 파일을 복제하는 방법을 제공합니다. 이 파일을 사용하여 새 환경 변수 및 볼륨 탑재를 만들 수도 있습니다.

메모

클러스터에 대한 연결 기간과 15분 동안 Bridge to Kubernetes는 로컬 컴퓨터에 대한 관리자 권한으로 EndpointManager 프로세스를 실행합니다.

여러 서비스를 사용하여 병렬로 디버그할 수 있습니다. 디버그하려는 서비스만큼 Visual Studio 인스턴스를 시작합니다. 서비스가 로컬로 다른 포트에서 수신 대기하는지 확인합니다. 별도로 구성하고 디버그합니다. 이 시나리오에서는 격리가 지원되지 않습니다.

추가 구성

KubernetesLocalProcessConfig.yaml 파일을 사용하면 클러스터의 Pod에서 사용할 수 있는 환경 변수 및 탑재된 파일을 복제할 수 있습니다. Visual Studio를 사용하는 경우 KubernetesLocalConfig.yaml 파일은 서비스에 대한 프로젝트 파일과 동일한 디렉터리에 있어야 합니다. 자세한 내용은 Bridge to Kubernetes구성을 참조하세요.

격리된 개발을 위한 라우팅 기능 사용

기본적으로 Bridge to Kubernetes는 서비스의 모든 트래픽을 개발 컴퓨터로 리디렉션합니다. 대신 라우팅 기능을 사용하여 하위 도메인의 요청만 개발 컴퓨터로 리디렉션할 수 있습니다. 이러한 라우팅 기능을 사용하면 Bridge to Kubernetes를 사용하여 격리된 상태로 개발하고 클러스터의 다른 트래픽을 방해하지 않도록 할 수 있습니다.

다음 애니메이션에서는 동일한 클러스터에서 격리된 상태로 작업하는 두 명의 개발자를 보여 줍니다.

애니메이션은 두 명의 개발자가 동일한 클러스터로 작업하는 격리를 보여 줍니다.

격리된 작업을 사용하도록 설정하면 Bridge to Kubernetes는 Kubernetes 클러스터에 연결하는 것 외에도 다음 작업을 수행합니다.

Kubernetes 클러스터에 Azure Dev Spaces가 사용하도록 설정되어 있지 않은지 확인합니다.
동일한 네임스페이스의 클러스터에서 선택한 서비스를 복제하고 routing.visualstudio.io/route-from=SERVICE_NAME 레이블 및 routing.visualstudio.io/route-on-header=kubernetes-route-as=GENERATED_NAME 주석을 추가합니다.
Kubernetes 클러스터의 동일한 네임스페이스에서 라우팅 관리자를 구성하고 시작합니다. 라우팅 관리자는 레이블 선택기를 사용하여 네임스페이스에서 라우팅을 구성할 때 routing.visualstudio.io/route-from=SERVICE_NAME 레이블 및 routing.visualstudio.io/route-on-header=kubernetes-route-as=GENERATED_NAME 주석을 찾습니다.

메모

Bridge to Kubernetes는 Kubernetes 클러스터에서 Azure Dev Spaces를 사용할 수 있는지 여부를 확인합니다. Bridge to Kubernetes를 사용하기 전에 Azure Dev Spaces를 사용하지 않도록 설정하라는 메시지가 표시됩니다.

라우팅 관리자는 시작할 때 다음 작업을 수행합니다.

하위 도메인을 위해 GENERATED_NAME을 사용하여 네임스페이스 내에 있는 로드 밸런서 인그레스를 포함한 모든 인그레스를 복제합니다.
GENERATED_NAME 하위 도메인을 사용하는 중복된 인그레스와 연결된 각 서비스에 envoy Pod를 만듭니다.
당신이 격리된 상태에서 작업 중인 서비스에 대한 또 다른 Envoy Pod를 만듭니다. 이 구성을 사용하면 하위 도메인이 있는 요청을 개발 컴퓨터로 라우팅할 수 있습니다.
하위 도메인을 사용하여 서비스에 대한 라우팅을 처리하도록 각 Envoy Pod에 대한 라우팅 규칙을 구성합니다.

다음 다이어그램에서는 Bridge to Kubernetes가 클러스터에 연결되기 전에 Kubernetes 클러스터를 보여 줍니다.

Bridge to Kubernetes가 없는 클러스터 다이어그램입니다.

다음 다이어그램에서는 격리 모드에서 Bridge to Kubernetes가 활성화된 동일한 클러스터를 보여 줍니다. 여기서는 격리된 라우팅을 지원하는 중복 서비스와 엔보이 포드를 볼 수 있습니다.

Bridge to Kubernetes를 사용하도록 설정된 클러스터 다이어그램입니다.

클러스터가 GENERATED_NAME 하위 도메인을 사용하여 요청을 받으면 요청에 kubernetes-route-as=GENERATED_NAME 헤더를 추가합니다. envoy Pod는 해당 요청을 클러스터의 적절한 서비스로 라우팅하는 것을 처리합니다. 격리된 상태로 작업 중인 서비스에 대한 요청의 경우 클러스터는 원격 에이전트를 통해 개발 컴퓨터로 요청을 리디렉션합니다.

클러스터가 GENERATED_NAME 하위 도메인 없이 요청을 받으면 요청에 헤더를 추가하지 않습니다. envoy Pod는 해당 요청을 클러스터의 적절한 서비스로 라우팅하는 것을 처리합니다. 교체되는 서비스에 대한 요청의 경우 Pod는 원격 에이전트 대신 원래 서비스로 라우팅합니다.

중요하다

클러스터의 각 서비스는 추가 요청을 할 때 kubernetes-route-as=GENERATED_NAME 헤더를 전달해야 합니다. 예를 들어 serviceA이 요청을 받으면, 응답을 반환하기 전에 serviceB에 요청을 합니다. 이 예제에서 serviceA는 kubernetes-route-as=GENERATED_NAME 헤더를 자신의 요청에 포함하여 serviceB로 전달해야 합니다. ASP.NET같은 일부 언어에는 헤더 전파를 처리하는 메서드가 있을 수 있습니다.

클러스터에서 연결을 끊으면 기본적으로 Bridge to Kubernetes는 모든 envoy Pod 및 중복 서비스를 제거합니다.

메모

라우팅 관리자 배포 및 서비스는 네임스페이스에서 계속 실행됩니다. 배포 및 서비스를 제거하려면 네임스페이스에 대해 다음 명령을 실행합니다.

kubectl delete deployment routingmanager-deployment -n NAMESPACE
kubectl delete service routingmanager-service -n NAMESPACE

진단 및 로깅

Bridge to Kubernetes를 사용하여 클러스터에 연결하는 경우 컴퓨터는 진단을 기록합니다. 개발 컴퓨터의 TEMP 디렉터리에 Bridge to Kubernetes 폴더에 저장합니다.

Kubernetes RBAC 권한 부여

Kubernetes는 사용자 및 그룹에 대한 권한을 관리하는 RBAC(역할 기반 액세스 제어)를 제공합니다. 자세한 내용은 Kubernetes 설명서참조하세요. YAML 파일을 만들고 kubectl 사용하여 RBAC 사용 클러스터에 대한 권한을 설정하여 클러스터에 적용할 수 있습니다.

클러스터에 대한 권한을 설정하려면 permissions.yml같은 YAML 파일을 만들거나 수정합니다. <namespace> 및 액세스가 필요한 사용자 및 그룹을 위해 당신의 네임스페이스를 사용하세요.

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: bridgetokubernetes-<namespace>
  namespace: development
subjects:
  - kind: User
    name: jane.w6wn8.k8s.ginger.eu-central-1.aws.gigantic.io
    apiGroup: rbac.authorization.k8s.io
  - kind: Group
    name: dev-admin
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: admin
  apiGroup: rbac.authorization.k8s.io

다음 명령을 사용하여 사용 권한을 적용합니다.

kubectl -n <namespace> apply -f <yaml file name>

제한

Bridge to Kubernetes에는 다음과 같은 제한 사항이 있습니다.

Pod에는 Bridge to Kubernetes가 성공적으로 연결하기 위해 해당 Pod에서 실행되는 단일 컨테이너만 있을 수 있습니다.
현재 Bridge to Kubernetes Pod는 Linux 컨테이너여야 합니다. Windows 컨테이너는 지원되지 않습니다.
Bridge to Kubernetes는 호스트 파일을 편집하기 위해 개발 컴퓨터에서 실행할 수 있는 상승된 권한이 필요합니다.
Azure Dev Spaces를 사용하도록 설정된 클러스터에서는 Bridge to Kubernetes를 사용할 수 없습니다.

다음 단계

Bridge to Kubernetes를 사용하여 로컬 개발 컴퓨터를 클러스터에 연결하려면, Bridge to Kubernetes (VS) 사용 방법 또는 Bridge to Kubernetes (VS Code) 사용 방법을 참조하세요.

다음을 통해 공유