Bridge to Kubernetes 작동 방식

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.
• Windows 10 이상에서 실행되는 Visual Studio 2019 버전 16.7 이상. 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 port-forward를 실행하여 개발 컴퓨터의 트래픽을 클러스터에서 실행되는 원격 에이전트로 전달합니다.
• 원격 에이전트를 사용하여 클러스터에서 환경 정보를 수집합니다. 이 환경 정보에는 환경 변수, 표시되는 서비스, 볼륨 탑재, 비밀 탑재가 포함됩니다.
• 개발 컴퓨터의 서비스가 클러스터에서 실행되는 것처럼 동일한 변수에 액세스할 수 있도록 Visual Studio에서 환경을 설정합니다.
• hosts 파일을 업데이트하여 클러스터의 서비스를 개발 컴퓨터의 로컬 IP 주소에 매핑합니다. 이러한 hosts 파일 항목을 사용하면 개발 컴퓨터에서 실행되는 코드를 통해 클러스터에서 실행되는 다른 서비스에 요청을 수행할 수 있습니다. hosts 파일을 업데이트하기 위해 Bridge to Kubernetes에는 개발 컴퓨터에 대한 관리자 액세스 권한이 필요합니다.
• 개발 컴퓨터에서 코드 실행 및 디버깅을 시작합니다. 필요한 경우 Bridge to Kubernetes는 현재 개발 컴퓨터에서 필요한 포트를 사용 중인 서비스나 프로세스를 중지하여 해당 포트를 확보합니다.

Bridge to Kubernetes 사용

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

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

또한 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가 사용되는 동일한 클러스터를 보여 줍니다. 여기에서 격리 상태에서 라우팅을 지원하는 중복 서비스 및 envoy pod를 볼 수 있습니다.

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

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

Important

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

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

참고 항목

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

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

진단 및 로깅

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

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에는 다음과 같은 제한 사항이 있습니다.

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

다음 단계

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