네트워킹


Red Hat Advanced Cluster Management for Kubernetes 2.10

네트워킹

초록

Hub 클러스터 및 관리 클러스터의 네트워킹 요구 사항에 대해 자세히 알아보려면 자세히 알아보십시오.

1장. 네트워킹

hub 클러스터와 관리 클러스터 모두에 대한 네트워크 요구 사항에 대해 알아봅니다.

1.1. hub 클러스터 네트워크 구성

중요: 신뢰할 수 있는 CA 번들은 Red Hat Advanced Cluster Management 네임스페이스에서 사용할 수 있지만 이를 개선하려면 네트워크를 변경해야 합니다. 신뢰할 수 있는 CA 번들 ConfigMap은 기본 이름 trusted-ca-bundle 을 사용합니다. TRUSTED_CA_BUNDLE 이라는 환경 변수에 Operator에 제공하여 이 이름을 변경할 수 있습니다. 자세한 내용은 Red Hat OpenShift Container Platform의 네트워킹 섹션에서 클러스터 전체 프록시 구성 을 참조하십시오.

hub 클러스터 네트워크의 구성을 참조할 수 있습니다.

1.1.1. hub 클러스터 네트워크 구성 테이블

다음 표에서 허브 클러스터 네트워크 요구 사항을 참조하십시오.

방향프로토콜연결포트(지정된 경우)소스 주소대상 주소

관리 클러스터로의 아웃 바운드

HTTPS

관리 클러스터의 Pod에 대한 검색 콘솔에서 로그 검색은 관리 클러스터에서 실행 중인 klusterlet-addon-workmgr 서비스를 사용합니다.

443

없음

관리 클러스터 경로에 액세스하기 위한 IP 주소

관리 클러스터로의 아웃 바운드

HTTPS

klusterlet을 설치하기 위해 설치 중에 프로비저닝된 관리형 클러스터의 Kubernetes API 서버

6443

없음

Kubernetes 관리 클러스터 API 서버의 IP

채널 소스에 대한 아웃 바운드

HTTPS

애플리케이션 라이프사이클, OpenShift GitOps 또는 Argo CD를 사용하여 연결하는 경우에만 필요한 GitHub, 오브젝트 저장소, Helm 리포지토리를 포함한 채널 소스

443

없음

채널 소스의 IP

관리 클러스터에서 인바운드

HTTPS

OpenShift Container Platform 버전 4.13 이상을 실행하는 관리형 클러스터에 대해서만 수집된 메트릭 및 경고를 푸시하기 위한 관리형 클러스터

443

없음

hub 클러스터 액세스 경로로 IP 주소

관리 클러스터에서 인바운드

HTTPS

관리형 클러스터에서 변경 사항을 감시하는 허브 클러스터의 Kubernetes API Server

6443

없음

hub 클러스터 Kubernetes API 서버의 IP 주소

ObjectStore로의 아웃 바운드

HTTPS

Cluster Backup Operator가 실행 중인 경우 장기 스토리지에 대한 Observability 메트릭 데이터 전송

443

없음

ObjectStore의 IP 주소

이미지 리포지토리로의 아웃 바운드

HTTPS

OpenShift Container Platform 및 Red Hat Advanced Cluster Management의 이미지에 액세스

443

없음

이미지 리포지토리의 IP 주소

1.2. 관리형 클러스터 네트워크 구성

관리 클러스터 네트워크의 구성을 참조할 수 있습니다.

1.2.1. 관리형 클러스터 네트워크 구성 테이블

다음 표에서 관리 클러스터 네트워크 요구 사항을 참조하십시오.

방향프로토콜연결포트(지정된 경우)소스 주소대상 주소

hub 클러스터에서 인바운드

HTTPS

관리 클러스터의 Pod에 대한 검색 콘솔에서 동적으로 로그를 전송하는 경우 관리 클러스터에서 실행 중인 klusterlet-addon-workmgr 서비스를 사용합니다.

443

없음

관리 클러스터 경로에 액세스하기 위한 IP 주소

hub 클러스터에서 인바운드

HTTPS

klusterlet을 설치하기 위해 설치 중에 프로비저닝된 관리형 클러스터의 Kubernetes API 서버

6443

없음

Kubernetes 관리 클러스터 API 서버의 IP

이미지 리포지토리로의 아웃 바운드

HTTPS

OpenShift Container Platform 및 Red Hat Advanced Cluster Management의 이미지에 액세스

443

없음

이미지 리포지토리의 IP 주소

허브 클러스터로의 아웃 바운드

HTTPS

OpenShift Container Platform 버전 4.13 이상을 실행하는 관리형 클러스터에 대해서만 수집된 메트릭 및 경고를 푸시하기 위한 관리형 클러스터

443

없음

hub 클러스터 액세스 경로로 IP 주소

허브 클러스터로의 아웃 바운드

HTTPS

허브 클러스터의 Kubernetes API 서버에서 변경 사항 감시

6443

없음

hub 클러스터 Kubernetes API 서버의 IP 주소

채널 소스에 대한 아웃 바운드

HTTPS

애플리케이션 라이프사이클, OpenShift GitOps 또는 Argo CD를 사용하여 연결하는 경우에만 필요한 GitHub, 오브젝트 저장소, Helm 리포지토리를 포함한 채널 소스

443

없음

채널 소스의 IP

1.3. 고급 네트워크 구성

1.3.1. 인프라 Operator 테이블에 대한 추가 네트워킹 요구 사항

Infrastructure Operator를 사용하여 베어 메탈 관리 클러스터를 설치하는 경우 추가 네트워킹 요구 사항은 Kubernetes Operator 설명서의 다중 클러스터 엔진의 네트워크 구성 을 참조하십시오.

1.3.2. Submariner 네트워킹 요구 사항 표

Submariner를 사용하는 클러스터에는 세 개의 열린 포트가 필요합니다. 다음 표에서는 사용할 수 있는 포트를 보여줍니다.

방향프로토콜연결포트(지정된 경우)

아웃바운드 및 인바운드

UDP

각 관리 클러스터

4800

아웃바운드 및 인바운드

UDP

각 관리 클러스터

4500, 500 및 게이트웨이 노드의 IPSec 트래픽에 사용되는 기타 포트

인바운드

TCP

각 관리 클러스터

8080

1.3.3. Hive 테이블에 대한 추가 네트워킹 요구 사항

중앙 인프라 관리를 사용하는 Hive Operator를 사용하여 베어 메탈 관리 클러스터를 설치하는 경우 허브 클러스터와 libvirt 프로비저닝 호스트 간에 계층 2 또는 계층 3 포트 연결을 구성해야 합니다. 이 연결은 Hive로 기본 메탈 클러스터를 생성하는 동안 필요합니다. 자세한 내용은 다음 표를 참조하십시오.

방향프로토콜연결포트(지정된 경우)

hub 클러스터 아웃바운드 및 libvirt 프로비저닝 호스트에 인바운드

IP

베어 메탈 클러스터를 생성할 때 부트스트랩 역할을 하는 libvirt 프로비저닝 호스트에 Hive Operator가 설치된 허브 클러스터 연결

 

참고: 이러한 요구 사항은 설치할 때만 적용되며 Infrastructure Operator와 함께 설치된 클러스터를 업그레이드할 때는 필요하지 않습니다.

1.3.4. 호스팅된 컨트롤 플레인 네트워킹 요구 사항 표 (기술 프리뷰)

호스팅된 컨트롤 플레인을 사용하는 경우 HypershiftDeployment 리소스는 다음 표에 나열된 끝점에 연결되어 있어야 합니다.

방향연결포트(지정된 경우)

아웃바운드

OpenShift Container Platform control-plane 및 worker 노드

 

아웃바운드

Amazon Web Services의 호스팅 클러스터 전용: AWS API 및 S3 API에 대한 아웃 바운드 연결

 

아웃바운드

Microsoft Azure 클라우드 서비스의 호스트 클러스터 전용: Azure API에 대한 아웃 바운드 연결

 

아웃바운드

coreOS의 ISO 이미지와 OpenShift Container Platform Pod의 이미지 레지스트리를 저장하는 OpenShift Container Platform 이미지 리포지토리

 

아웃바운드

호스팅 클러스터에서 klusterlet의 로컬 API 클라이언트는 HyperShift 호스팅 클러스터의 API와 통신합니다.

 

1.3.5. 애플리케이션 배포 네트워크 요구 사항 표

일반적으로 애플리케이션 배포 통신은 관리 클러스터에서 허브 클러스터로 한 가지 방법입니다. 연결에서는 관리 클러스터의 에이전트에 의해 구성된 kubeconfig 를 사용합니다. 관리 클러스터의 애플리케이션 배포는 hub 클러스터의 다음 네임스페이스에 액세스해야 합니다.

  • 채널 리소스의 네임스페이스
  • 관리 클러스터의 네임스페이스

1.3.6. 네임스페이스 연결 네트워크 요구 사항 표

  • 애플리케이션 라이프사이클 연결:

    • 네임스페이스 open-cluster-management 는 포트 4000의 콘솔 API에 액세스해야 합니다.
    • open-cluster-management 네임스페이스는 포트 3001에 애플리케이션 UI를 노출해야 합니다.
  • 애플리케이션 라이프사이클 백엔드 구성 요소(Pod)

    허브 클러스터에서 모든 애플리케이션 라이프사이클 Pod는 다음 Pod를 포함하여 open-cluster-management 네임스페이스에 설치됩니다.

    • multicluster-operators-hub-subscription
    • multicluster-operators-standalone-subscription
    • multicluster-operators-channel
    • multicluster-operators-application
    • multicluster-integrations

      이러한 Pod는 open-cluster-management 네임스페이스에 있습니다.

    • 네임스페이스 open-cluster-management 는 포트 6443의 Kube API에 액세스해야 합니다.

    관리 클러스터에서 klusterlet-addon-appmgr 애플리케이션 라이프사이클 Pod만 open-cluster-management-agent-addon 네임스페이스에 설치됩니다.

    • 네임스페이스 open-cluster-management-agent-addon 은 포트 6443의 Kube API에 액세스해야 합니다.
  • 거버넌스 및 위험:

    허브 클러스터에서는 다음 액세스가 필요합니다.

    • 네임스페이스 open-cluster-management 는 포트 6443의 Kube API에 액세스해야 합니다.
    • 네임스페이스 open-cluster-management 는 포트 5353에서 OpenShift DNS에 액세스해야 합니다.

    관리 클러스터에서는 다음 액세스가 필요합니다.

    • 네임스페이스 open-cluster-management-addon 은 포트 6443의 Kube API에 액세스해야 합니다.

1.4. Submariner 다중 클러스터 네트워킹 및 서비스 검색

Submariner는 Red Hat Advanced Cluster Management for Kubernetes와 함께 사용하여 온프레미스 또는 클라우드에서 사용자의 환경의 두 개 이상의 관리 클러스터 간에 직접 네트워킹 및 서비스 검색을 제공할 수 있는 오픈 소스 툴입니다. Submariner는 Multi-Cluster Services API (Kubernetes 기능 강화 Proposal #1645)와 호환됩니다. Submariner에 대한 자세한 내용은 Submariner 사이트를 참조하십시오.

자동화된 콘솔 배포를 지원하거나 수동 배포 가 필요한 공급자를 포함하여 인프라 공급자의 지원 수준에 대한 자세한 내용은 Red Hat Advanced Cluster Management 지원 매트릭스 를 참조하십시오.

Submariner 사용 방법에 대한 자세한 내용은 다음 항목을 참조하십시오.

1.4.1. 연결이 끊긴 클러스터에 Submariner 배포

연결이 끊긴 클러스터에 Submariner를 배포하면 클러스터의 외부 공격 위험을 줄임으로써 보안 문제를 해결할 수 있습니다. 연결이 끊긴 클러스터에서 Red Hat Advanced Cluster Management for Kubernetes를 사용하여 Submariner를 배포하려면 먼저 연결이 끊긴 네트워크 환경에 설치하는 단계를 완료해야 합니다.

1.4.1.1. 연결이 끊긴 클러스터에서 Submariner 구성

연결이 끊긴 네트워크 환경에서 설치 단계를 완료한 후 연결이 끊긴 클러스터에 대한 배포를 지원하도록 설치 중에 Submariner를 구성합니다.

다음 단계를 완료합니다.

  1. 연결이 끊긴 클러스터에 Submariner 를 배포하기 전에 로컬 레지스트리에 Submariner 이미지를 미러링합니다.
  2. Red Hat Advanced Cluster Management 버전과 호환되는 Submariner Operator 버전을 선택합니다. 예를 들어 Red Hat Advanced Cluster Management 버전 2.10에 0.17.0 을 사용합니다.
  3. catalogSource 이름을 사용자 지정합니다. 기본적으로 submariner-addon 은 이름이 redhat-operatorscatalogSource 를 검색합니다. 다른 이름으로 catalogSource 를 사용하는 경우 관리 클러스터와 연결된 SubmarinerConfig.Spec.subscriptionConfig.Source 매개변수 값을 catalogSource 의 사용자 지정 이름으로 업데이트해야 합니다.
  4. Red Hat Advanced Cluster Management for Kubernetes 콘솔의 관리 클러스터에 submariner-addon 을 설치하는 경우 Submarinerer가 외부 서버에 API 쿼리를 수행하지 않도록 Disconnected 클러스터 옵션을 선택할 수 있습니다.

참고: API를 사용하여 Submariner를 설치하는 경우 관리형 클러스터와 연결된 SubmarinerConfig 에서 airGappedDeployment 매개변수를 true 로 설정해야 합니다.

1.4.2. Submariner 구성

Red Hat Advanced Cluster Management for Kubernetes는 Submariner를 hub 클러스터의 애드온으로 제공합니다. Submariner 구성 방법을 알아보려면 다음 항목을 참조하십시오.

1.4.2.1. 사전 요구 사항

Submariner를 사용하기 전에 다음 사전 요구 사항이 있는지 확인하십시오.

  • cluster-admin 권한으로 hub 클러스터에 액세스할 수 있는 인증 정보입니다.
  • 게이트웨이 노드 간에 IP 연결을 구성해야 합니다. 두 클러스터를 연결하는 경우 게이트웨이 노드에 지정된 공용 또는 개인 IP 주소를 사용하여 하나 이상의 클러스터에 게이트웨이 노드에 액세스할 수 있어야 합니다. 자세한 내용은 Submariner NAT tr versal을 참조하십시오.
  • OVN Kubernetes를 사용하는 경우 클러스터는 Red Hat OpenShift Container Platform 버전 4.13 이상이어야 합니다.
  • Red Hat OpenShift Container Platform 클러스터에서 OpenShift SDN CNI를 사용하는 경우 관리형 클러스터의 모든 노드의 방화벽 구성이 두 방향 모두에서 4800/UDP를 허용해야 합니다.
  • 방화벽 구성에서 게이트웨이 노드에서 4500/UDP 및 4490/UDP를 허용해야 관리 클러스터 간에 터널을 설정할 수 있습니다.
  • OpenShift Container Platform ARM 배포의 경우 c6g.large instanceType 또는 기타 사용 가능한 인스턴스 유형을 사용해야 합니다.
  • 에서 NAT가 없는 개인 IP를 통해 게이트웨이 노드에 직접 연결할 수 있는 경우 방화벽 구성이 게이트웨이 노드에서 ESP 프로토콜을 허용하는지 확인합니다.

    참고: 클러스터가 Amazon Web Services, Google Cloud Platform, Microsoft Azure 또는 Red Hat OpenStack 환경에 배포된 경우 자동으로 설정되지만 프라이빗 클라우드를 보호하는 방화벽과 다른 환경의 클러스터에 대해 수동으로 구성해야 합니다.

  • managedcluster 이름은 RFC 1123에 정의된 DNS 라벨 표준을 따르고 다음 요구 사항을 충족해야 합니다.

    • 63자 미만을 포함합니다.
    • 소문자 영숫자 또는 '-'만 포함합니다.
    • 영숫자 문자로 시작
    • 영숫자 문자로 끝납니다.
1.4.2.2. Submariner 포트 테이블

다음 표를 보고 활성화해야 하는 Submariner 포트를 확인합니다.

이름기본값사용자 정의 가능선택 사항 또는 필수

IPsec NATT

4500/UDP

제공됨

필수 항목

VXLAN

4800/UDP

없음

필수 항목

NAT 검색 포트

4490/UDP

없음

필수 항목

1.4.2.3. 기존 VPC의 Submariner 구성

AWS(Amazon Web Services)의 기존 Amazon VPC(Virtual Private Cloud)에 클러스터를 설치한 경우 Subarminer를 구성하려면 다음 단계를 완료해야 합니다.

  1. 다음 명령을 실행하여 SubmarinerConfig 파일을 열고 편집합니다. 필요한 경우 값을 바꿉니다.

    oc edit submarinerconfig -n <managed-cluster-ns> submariner
  2. metadata 필드에 다음 주석을 추가합니다. 필요한 경우 값을 바꿉니다.

    참고: 추가할 모든 ID는 영숫자입니다.

    annotations:
      submariner.io/control-plane-sg-id: <control-plane-group-id> 1
      submariner.io/subnet-id-list: <subnet-id-list> 2
      submariner.io/vpc-id: <custom-vpc-id> 3
      submariner.io/worker-sg-id: <worker-security-group-id> 4
    1
    을 컨트롤 플레인 보안 그룹 ID로 바꿉니다. 일반적으로 < infra-id>-master-sg>와 유사한 이름이 있는 컨트롤 플레인 보안 그룹에서 ID를 찾을 수 있습니다.
    2
    사용자 정의 VPC에서 쉼표로 구분된 공용 서브넷 ID 목록으로 바꿉니다.
    3
    사용자 정의 VPC ID로 바꿉니다.
    4
    을 작업자 보안 그룹 ID로 바꿉니다. 일반적으로 < infra-id>-worker-sg와 유사한 이름이 있는 작업자 보안 그룹에서 ID를 찾을 수 있습니다.
1.4.2.4. Globalnet

Globalnet은 기존 클러스터의 CIDR을 변경하지 않고 중복되는 Classless Inter-Domain Routings(CIDR)로 클러스터를 연결할 수 있는 Submariner 애드온 기능입니다. Globalnet은 첫 번째 관리 클러스터를 클러스터 세트에 추가할 때 선택할 수 있는 클러스터 세트 구성입니다.

Globalnet을 활성화하면 모든 관리 클러스터에서 클러스터 간 통신을 용이하게 하는 데 사용되는 가상 글로벌 프라이빗 네트워크에서 글로벌 CIDR을 수신합니다.

중요: 클러스터 세트의 클러스터에 겹치는 CIDR이 있을 수 있는 경우 Globalnet을 활성화해야 합니다.

ClusterAdmin 은 클러스터 세트의 클러스터에 대해 Submariner 애드온을 활성화할 때 옵션 Enable Globalnet 옵션을 선택하여 콘솔에서 Globalnet을 활성화할 수 있습니다. 활성화한 후 Globalnet을 비활성화하려면 먼저 클러스터 세트에서 모든 관리 클러스터를 제거해야 합니다.

1.4.2.4.1. submariner-broker 오브젝트를 생성하여 Globalnet 활성화

Red Hat Advanced Cluster Management API를 사용하는 경우 ClusterAdmin 은 < ManagedClusterSet > -broker 네임스페이스에 하위mariner-broker 오브젝트를 생성하여 Globalnet을 활성화할 수 있습니다.

ClusterAdmin 역할에는 브로커 네임스페이스에서 submariner-broker 오브젝트를 생성하는 데 필요한 권한이 있습니다. 클러스터 세트의 프록시 관리자 역할을 수행하도록 생성되는 ManagedClusterSetAdmin 역할에는 필요한 권한이 없습니다.

필요한 권한을 제공하려면 ClusterAdmin 에서 access-to-brokers-submariner-crd 에 대한 역할 권한을 ManagedClusterSetAdmin 사용자에게 연결해야 합니다.

submariner-broker 오브젝트를 생성하여 Globalnet을 활성화하려면 다음 단계를 완료합니다.

  1. 다음 명령을 실행하여 < broker-namespace >를 검색합니다.

    oc get ManagedClusterSet <cluster-set-name> -o jsonpath="{.metadata.annotations['cluster\.open-cluster-management\.io/submariner-broker-ns']}"
  2. submariner-broker 라는 YAML 파일을 생성하여 Globalnet 구성을 지정하는 submariner-broker 오브젝트를 생성합니다. YAML 파일에 다음 행과 유사한 콘텐츠를 추가합니다.

    apiVersion: submariner.io/v1alpha1
    kind: Broker
    metadata:
      name: submariner-broker 1
      namespace: broker-namespace 2
    spec:
      globalnetEnabled: true-or-false 3
    1
    이름은 submariner-broker 여야 합니다.
    2
    broker-namespace 를 브로커 네임스페이스의 이름으로 교체합니다.
    3
    true-or-falsetrue 로 교체하여 Globalnet을 활성화합니다.
  3. 다음 명령을 실행하여 파일을 적용합니다.

    oc apply -f submariner-broker.yaml
1.4.2.4.2. 글로벌 IP 수 구성

ClusterGlobalEgressIP 리소스에서 numberOfIPs 필드 값을 변경하여 구성 가능한 글로벌 IP를 할당할 수 있습니다. 기본값은 8입니다. 다음 예제를 참조하십시오.

apiVersion: submariner.io/v1
kind: ClusterGlobalEgressIP
metadata:
  name: cluster-egress.submariner.io
spec:
  numberOfIPs: 8
1.4.2.4.3. 추가 리소스

1.4.3. subctl 명령 유틸리티 설치

subctl 유틸리티는 Red Hat Developers 페이지에 게시됩니다. 하위ctl 유틸리티를 로컬로 설치하려면 다음 단계를 완료합니다.

  1. 하위ctl 게시 디렉터리 로 이동합니다.
  2. 사용 중인 Submariner 버전과 일치하는 폴더를 클릭합니다.
  3. 사용 중인 플랫폼의 tar.xz 아카이브를 클릭하여 하위 구문 바이너리의 압축 버전을 다운로드합니다.

    1. 플랫폼이 나열되지 않은 경우 Red Hat Ecosystem Catalog 하위 역할 페이지로 이동하여 관련 이미지에서 subctl 을 추출합니다. 예를 들어 arm64 subctl 이미지에서 macos-arm64 바이너리를 추출할 수 있습니다.
  4. 다음 명령을 입력하여 subctl 유틸리티의 압축을 풉니다. & lt;name >을 다운로드한 아카이브 이름으로 바꿉니다.

    tar -C /tmp/ -xf <name>.tar.xz
  5. 다음 명령을 입력하여 subctl 유틸리티를 설치합니다. & lt;name >을 다운로드한 아카이브의 이름으로 바꿉니다. & lt;version >을 다운로드한 하위 브릿지 버전으로 바꿉니다.

    install -m744 /tmp/<version>/<name> /$HOME/.local/bin/subctl

참고:

  • subctl 및 Submariner 버전이 일치하는지 확인합니다.
  • 연결이 끊긴 환경의 경우 하위marine r-nettest 이미지를 미러링해야 합니다.
1.4.3.1. subctl 명령 사용

경로에 유틸리티를 추가한 후 사용 가능한 명령에 대한 간략한 설명은 다음 표를 참조하십시오.

내보내기 서비스

지정된 서비스에 대한 ServiceExport 리소스를 생성하여 Submariner 배포의 다른 클러스터에서 해당 서비스를 검색할 수 있습니다.

내보내기되지 않은 서비스

지정된 서비스에 대한 ServiceExport 리소스를 제거하여 Submariner 배포의 다른 클러스터가 해당 서비스를 검색하지 못하도록 합니다.

표시

Submariner 리소스에 대한 정보를 제공합니다.

확인

Submariner가 한 쌍의 클러스터에 걸쳐 구성된 경우 연결, 서비스 검색 및 기타 Submariner 기능을 확인합니다.

benchmark

Submariner 또는 단일 클러스터 내에서 활성화되는 한 쌍의 클러스터에서 처리량 및 대기 시간을 벤치마크합니다.

진단

검사를 실행하여 Submariner 배포가 제대로 작동하지 않는 문제를 식별합니다.

gather

하위 배포 문제를 해결하기 위해 클러스터에서 정보를 수집합니다.

version

subctl 바이너리 툴의 버전 세부 정보를 표시합니다.

참고: subctl 의 Red Hat 빌드에는 Red Hat Advanced Cluster Management for Kubernetes와 관련된 명령만 포함됩니다. subctl 유틸리티 및 해당 명령에 대한 자세한 내용은 Submariner 문서의subctl 을 참조하십시오.

1.4.4. 콘솔을 사용하여 Submariner 배포

Red Hat Advanced Cluster Management for Kubernetes를 사용하여 Submariner를 배포하기 전에 호스팅 환경에서 클러스터를 준비해야 합니다. SubmarinerConfig API 또는 Kubernetes 콘솔용 Red Hat Advanced Cluster Management를 사용하여 다음 공급자에서 Red Hat OpenShift Container Platform 클러스터를 자동으로 준비할 수 있습니다.

  • Amazon Web Services
  • Google Cloud Platform
  • IBM Power Systems Virtual Server
  • Red Hat OpenShift on IBM Cloud (기술 프리뷰)
  • Red Hat OpenStack Platform
  • Microsoft Azure
  • VMware vSphere

참고:

  • 비NSX 배포만 VMware vSphere에서 지원됩니다.
  • IBM Cloud에서 Red Hat OpenShift를 사용하는 경우 클러스터에 Calico API 서버 를 설치해야 합니다. 또는 Submariner 업스트림 문서의 CAL Cryostat CNI 항목에 따라 클러스터 간 통신에 필요한 IP 풀을 수동으로 생성할 수 있습니다.

다른 공급자에 Submariner를 배포하려면 수동으로 Submariner 배포 의 지침을 따르십시오.

Red Hat Advanced Cluster Management for Kubernetes 콘솔을 사용하여 Submariner를 배포하려면 다음 단계를 완료합니다.

필수 액세스: 클러스터 관리자

  1. 콘솔에서 Infrastructure > Clusters 를 선택합니다.
  2. Clusters 페이지에서 Cluster sets 탭을 선택합니다. Submariner를 사용하여 활성화할 클러스터는 동일한 클러스터 세트에 있어야 합니다.
  3. Submariner를 배포하려는 클러스터가 이미 동일한 클러스터 세트에 있는 경우 5 단계로 건너뜁니다.
  4. Submariner를 배포하려는 클러스터가 동일한 클러스터 세트에 없는 경우 다음 단계를 완료하여 해당 클러스터 세트를 생성합니다.

    1. 클러스터 세트 생성 을 선택합니다.
    2. 클러스터 세트의 이름을 지정하고 생성 을 선택합니다.
    3. 클러스터 세트에 클러스터를 할당할 리소스 할당 관리를 선택합니다.
    4. Submariner와 연결할 관리형 클러스터를 선택하여 클러스터 세트에 추가합니다.
    5. 검토 를 선택하여 선택한 클러스터를 보고 확인합니다.
    6. 저장을 선택하여 클러스터 세트를 저장하고 결과 클러스터 세트 페이지를 확인합니다.
  5. 클러스터 세트 페이지에서 Submariner 애드온 탭을 선택합니다.
  6. Install Submariner 애드온 을 선택합니다.
  7. Submariner를 배포할 클러스터를 선택합니다.
  8. 다음 표의 필드를 확인하고 Install Submariner add-ons 편집기에 필요한 정보를 입력합니다.

    필드참고

    AWS 액세스 키 ID

    AWS 클러스터를 가져올 때만 표시됩니다.

    AWS 시크릿 액세스 키

    AWS 클러스터를 가져올 때만 표시됩니다.

    기본 도메인 리소스 그룹 이름

    Azure 클러스터를 가져올 때만 표시됩니다.

    클라이언트 ID

    Azure 클러스터를 가져올 때만 표시됩니다.

    클라이언트 시크릿

    Azure 클러스터를 가져올 때만 표시됩니다.

    서브스크립션 ID

    Azure 클러스터를 가져올 때만 표시됩니다.

    테넌트 ID

    Azure 클러스터를 가져올 때만 표시됩니다.

    Google Cloud Platform 서비스 계정 JSON 키

    Google Cloud Platform 클러스터를 가져올 때만 표시됩니다.

    인스턴스 유형

    관리 클러스터에서 생성된 게이트웨이 노드의 인스턴스 유형입니다.

    IPsec NAT-T 포트

    IPsec NAT traversal 포트의 기본값은 포트 4500 입니다. 관리되는 클러스터 환경이 VMware vSphere인 경우 이 포트가 방화벽에서 열려 있는지 확인합니다.

    게이트웨이 수

    관리 클러스터에 배포할 게이트웨이 노드 수입니다. AWS, GCP, Azure 및 OpenStack 클러스터의 경우 전용 게이트웨이 노드가 배포됩니다. VWware 클러스터의 경우 기존 작업자 노드에 게이트웨이 노드로 태그가 지정됩니다. 기본값은 1 입니다. 값이 1보다 크면 Submariner 게이트웨이 HA(고가용성)가 자동으로 활성화됩니다.

    Cable 드라이버

    클러스터 간 터널을 유지 관리하는 Submariner 게이트웨이 케이블 엔진 구성 요소입니다. 기본값은 Libreswan IPsec 입니다.

    연결이 끊긴 클러스터

    활성화된 경우 Submariner에게 공용 IP 확인을 위해 외부 서버에 액세스하지 않도록 지시합니다.

    Globalnet CIDR

    클러스터 세트에서 Globalnet 구성이 선택된 경우에만 표시됩니다. 관리 클러스터에 사용할 Globalnet CIDR입니다. 비워 두면 클러스터 세트 풀에서 CIDR이 할당됩니다.

  9. 편집기 끝에 있는 다음을 선택하여 다음 클러스터의 편집기로 이동하고 선택한 나머지 클러스터 각각에 대한 편집기를 완료합니다.
  10. 각 관리 클러스터에 대한 구성을 확인합니다.
  11. 설치를 클릭하여 선택한 관리 클러스터에 Submariner를 배포합니다.

    설치 및 구성을 완료하는 데 몇 분이 걸릴 수 있습니다. Submariner 애드온 탭의 목록에서 Submariner 상태를 확인할 수 있습니다.

    • 연결 상태는 관리 클러스터에서 설정된 하위 계층 연결 수를 나타냅니다.
    • 에이전트 상태는 Submariner가 관리 클러스터에 성공적으로 배포되었는지 여부를 나타냅니다. 콘솔은 설치 및 구성될 때까지 Degraded 상태를 보고할 수 있습니다.
    • 레이블이 지정된 게이트웨이 노드 는 관리되는 클러스터의 게이트웨이 노드 수를 나타냅니다.

이제 Submariner가 선택한 클러스터에 배포됩니다.

1.4.5. 수동으로 Submariner 배포

Red Hat Advanced Cluster Management for Kubernetes를 사용하여 Submariner를 배포하기 전에 연결을 위해 호스팅 환경에서 클러스터를 준비해야 합니다. 콘솔을 사용하여 지원되는 클러스터에 Submariner를 자동으로 배포하는 방법을 알아보려면 콘솔을 사용하여 Submariner 배포를 참조하십시오.

클러스터가 자동 Submariner 배포를 지원하지 않는 공급자에서 호스팅되는 경우 다음 섹션을 참조하여 인프라를 수동으로 준비합니다. 각 공급자에는 준비에 필요한 고유한 단계가 있으므로 올바른 공급자를 선택해야 합니다.

1.4.5.1. Submariner를 위한 베어 메탈 준비

Submariner 배포를 위해 베어 메탈 클러스터를 준비하려면 다음 단계를 완료합니다.

  1. 방화벽이 게이트웨이 노드에 대해 4500/UDP 및 4490/UDP 포트의 외부 클라이언트에 대한 인바운드/outbound 트래픽을 허용하는지 확인합니다. 또한 클러스터가 OpenShiftSDN CNI와 함께 배포된 경우 로컬 클러스터 노드 내에서 인바운드/outbound UDP/4800 트래픽을 허용합니다.
  2. 다음 예와 유사한 YAML 콘텐츠를 사용자 지정하고 적용합니다.

    apiVersion: submarineraddon.open-cluster-management.io/v1alpha1
    kind: SubmarinerConfig
    metadata:
        name: submariner
        namespace: <managed-cluster-namespace>
    spec:
        gatewayConfig:
          gateways: 1

    managed-cluster-namespace 를 관리 클러스터 이름으로 교체합니다. SubmarinerConfig 의 이름은 예제와 같이 잠수함 이어야 합니다.

    이 구성에서는 작업자 노드 중 하나에 베어 메탈 클러스터의 Submariner 게이트웨이로 레이블을 지정합니다.

    기본적으로 Submariner는 IP 보안(IPsec)을 사용하여 게이트웨이 노드의 클러스터 간에 보안 터널을 설정합니다. 기본 IPsec NATT 포트를 사용하거나 구성한 다른 포트를 지정할 수 있습니다. IPsec NATT 포트를 지정하지 않고 이 절차를 실행하면 연결에 4500/UDP가 사용됩니다.

  3. Submariner에서 구성한 게이트웨이 노드를 식별하고 방화벽 구성을 활성화하여 외부 트래픽에 대해 IPsec NATT(UDP/4500) 및 나트Discovery(UDP/4490) 포트를 허용합니다.

사용자 지정 옵션에 대한 정보는 Submariner 배포 사용자 지정을 참조하십시오.

1.4.5.2. 명령줄 인터페이스를 사용하여 Microsoft Azure Red Hat OpenShift for Submariner 준비

Microsoft Azure Red Hat OpenShift 서비스는 컨테이너 기반 애플리케이션 빌드 프로세스를 단순화하는 데 사용할 수 있는 다양한 툴과 리소스를 결합합니다. 명령줄 인터페이스를 사용하여 Submariner 배포를 위해 Azure Red Hat OpenShift 클러스터를 준비하려면 다음 단계를 완료하십시오.

  1. Azure CLI 를 설치합니다.
  2. Azure CLI에서 다음 명령을 실행하여 확장을 설치합니다.

    az extension add --upgrade -s <path-to-extension>

    path-to-extension.whl 확장자 파일을 다운로드한 경로로 바꿉니다.

  3. 다음 명령을 실행하여 CLI 확장이 사용 중인지 확인합니다.

    az extension list

    확장을 사용하는 경우 출력은 다음 예와 유사할 수 있습니다.

    "experimental": false,
    "extensionType": "whl",
    "name": "aro",
    "path": "<path-to-extension>",
    "preview": true,
    "version": "1.0.x"
  4. Azure CLI에서 다음 명령을 실행하여 프리뷰 기능을 등록합니다.

    az feature registration create --namespace Microsoft.RedHatOpenShift --name AdminKubeconfig
  5. 다음 명령을 실행하여 관리자 kubeconfig 를 검색합니다.

    az aro get-admin-kubeconfig -g <resource group> -n <cluster resource name>

    참고: az aro 명령은 kubeconfig 를 로컬 디렉터리에 저장하고 이름 kubeconfig 를 사용합니다. 이를 사용하려면 파일 경로와 일치하도록 환경 변수 KUBECONFIG 를 설정합니다. 다음 예제를 참조하십시오.

    export KUBECONFIG=<path-to-kubeconfig>
    oc get nodes
  6. Azure Red Hat OpenShift 클러스터를 가져옵니다. 클러스터 가져오기에 대한 자세한 내용은 클러스터 가져오기 소개 를 참조하십시오.
1.4.5.2.1. API를 사용하여 Microsoft Azure Red Hat OpenShift for Submariner 준비

API를 사용하여 Submariner 배포를 위해 Azure Red Hat OpenShift 클러스터를 준비하려면 다음 예와 유사한 YAML 콘텐츠를 사용자 지정하고 적용합니다.

apiVersion: submarineraddon.open-cluster-management.io/v1alpha1
kind: SubmarinerConfig
metadata:
    name: submariner
    namespace: <managed-cluster-namespace>
spec:
    loadBalancerEnable: true

managed-cluster-namespace 를 관리 클러스터 이름으로 교체합니다.

SubmarinerConfig 의 이름은 예제와 같이 잠수함 이어야 합니다.

이 구성에서는 작업자 노드 중 하나에 Azure Red Hat OpenShift 클러스터의 Submariner 게이트웨이로 레이블을 지정합니다.

기본적으로 Submariner는 IP 보안(IPsec)을 사용하여 게이트웨이 노드의 클러스터 간에 보안 터널을 설정합니다. 기본 IPsec NATT 포트를 사용하거나 구성한 다른 포트를 지정할 수 있습니다. IPsec NATT 포트를 지정하지 않고 이 절차를 실행하면 연결에 포트 4500/UDP가 사용됩니다.

사용자 지정 옵션에 대한 정보는 Submariner 배포 사용자 지정을 참조하십시오.

1.4.5.3. 명령줄 인터페이스를 사용하여 AWS에서 Red Hat OpenShift Service 준비

Red Hat OpenShift Service on AWS는 애플리케이션 개발 및 현대화를 위한 안정적이고 유연한 플랫폼을 제공합니다. Submariner 배포를 위해 AWS 클러스터에서 OpenShift Service를 준비하려면 다음 단계를 완료합니다.

  1. 다음 명령을 실행하여 AWS의 OpenShift Service에 로그인합니다.

    rosa login
    oc login <rosa-cluster-url>:6443 --username cluster-admin --password <password>
  2. 다음 명령을 실행하여 AWS 클러스터에서 OpenShift 서비스에 대한 kubeconfig 를 생성합니다.

    oc config view --flatten=true > rosa_kube/kubeconfig
  3. AWS 클러스터에서 OpenShift 서비스를 가져옵니다. 클러스터 가져오기에 대한 자세한 내용은 클러스터 가져오기 소개 를 참조하십시오.
1.4.5.3.1. API를 사용하여 Red Hat OpenShift Service on AWS for Submariner 준비

API를 사용하여 Submariner 배포를 위해 AWS 클러스터에서 OpenShift Service를 준비하려면 다음 예와 유사한 YAML 콘텐츠를 사용자 지정하고 적용합니다.

apiVersion: submarineraddon.open-cluster-management.io/v1alpha1
kind: SubmarinerConfig
metadata:
    name: submariner
    namespace: <managed-cluster-namespace>
spec:
    loadBalancerEnable: true

managed-cluster-namespace 를 관리 클러스터 이름으로 교체합니다.

SubmarinerConfig 의 이름은 예제와 같이 잠수함 이어야 합니다.

기본적으로 Submariner는 IP 보안(IPsec)을 사용하여 게이트웨이 노드의 클러스터 간에 보안 터널을 설정합니다. 기본 IPsec NATT 포트를 사용하거나 구성한 다른 포트를 지정할 수 있습니다. IPsec NATT 포트를 지정하지 않고 이 절차를 실행하면 연결에 포트 4500/UDP가 사용됩니다.

사용자 지정 옵션에 대한 정보는 Submariner 배포 사용자 지정을 참조하십시오.

1.4.5.4. ManagedClusterAddOn API를 사용하여 Submariner 배포

선택한 호스팅 환경을 수동으로 준비한 후 다음 단계를 완료하여 ManagedClusterAddOn API를 사용하여 Submariner를 배포할 수 있습니다.

  1. ManagedClusterSet 설명서에 제공된 지침을 사용하여 hub 클러스터에 ManagedClusterSet 리소스를 생성합니다. ManagedClusterSet 의 항목이 다음 콘텐츠와 유사한지 확인합니다.

    apiVersion: cluster.open-cluster-management.io/v1beta2
    kind: ManagedClusterSet
    metadata:
      name: <managed-cluster-set-name>

    managed-cluster-set-name 을 생성 중인 ManagedClusterSet 의 이름으로 교체합니다.

    중요: Kubernetes 네임스페이스의 최대 문자 길이는 63자입니다. < managed-cluster-set-name>에 사용할 수 있는 최대 문자 길이는 56자입니다. < managed-cluster-set-name >의 문자 길이가 56자를 초과하면 < managed-cluster-set-name >이 헤드에서 삭제됩니다.

    ManagedClusterSet 이 생성되면 submariner-addon 은 < managed-cluster-set-name>-broker 라는 네임스페이스를 생성하고 Submariner 브로커를 배포합니다.

  2. 다음 예와 유사한 YAML 콘텐츠를 사용자 정의하고 적용하여 < managed-cluster-set-name>-broker 네임스페이스의 hub 클러스터에 Broker 구성을 생성합니다.

    apiVersion: submariner.io/v1alpha1
    kind: Broker
    metadata:
         name: submariner-broker
         namespace: <managed-cluster-set-name>-broker
         labels:
             cluster.open-cluster-management.io/backup: submariner
    spec:
         globalnetEnabled: <true-or-false>

    managed-cluster-set-name 을 관리 클러스터 이름으로 교체합니다.

    ManagedClusterSet 에서 Submariner Globalnet을 활성화하려면 globalnetEnabled 의 값을 true 로 설정합니다.

  3. 다음 명령을 실행하여 ManagedClusterSet 에 하나의 관리 클러스터를 추가합니다.

    oc label managedclusters <managed-cluster-name> "cluster.open-cluster-management.io/clusterset=<managed-cluster-set-name>" --overwrite

    & lt;managed-cluster-name >을 ManagedClusterSet 에 추가할 관리 클러스터의 이름으로 바꿉니다.

    & lt;managed-cluster-set-name >을 관리 클러스터를 추가할 ManagedClusterSet 의 이름으로 바꿉니다.

  4. 다음 예와 유사한 YAML 콘텐츠를 사용자 지정하고 적용합니다.

    apiVersion: submarineraddon.open-cluster-management.io/v1alpha1
    kind: SubmarinerConfig
    metadata:
        name: submariner
        namespace: <managed-cluster-namespace>
    spec:{}

    managed-cluster-namespace 를 관리 클러스터의 네임스페이스로 교체합니다.

    참고: SubmarinerConfig 의 이름은 예와 같이 잠수함 이어야 합니다.

  5. 다음 예와 유사한 YAML 콘텐츠를 사용자 정의하고 적용하여 관리 클러스터에 Submariner를 배포합니다.

    apiVersion: addon.open-cluster-management.io/v1alpha1
    kind: ManagedClusterAddOn
    metadata:
         name: submariner
         namespace: <managed-cluster-name>
    spec:
         installNamespace: submariner-operator

    managed-cluster-name 을 Submariner와 함께 사용하려는 관리 클러스터의 이름으로 교체합니다.

    ManagedClusterAddOn 사양의 installNamespace 필드는 Submariner를 설치하는 관리형 클러스터의 네임스페이스입니다. 현재 Submariner -operator 네임 스페이스에 Submariner 를 설치해야 합니다.

    ManagedClusterAddOn 이 생성되면 submariner-addon 이 관리 클러스터의 submariner-operator 네임스페이스에 Submariner를 배포합니다. 이 ManagedClusterAddOn 의 상태에서 Submariner의 배포 상태를 볼 수 있습니다.

    참고: ManagedClusterAddOn 의 이름은 submariner 여야 합니다.

  6. Submariner를 활성화하려는 모든 관리 클러스터에 대해 3, 4, 5단계를 반복합니다.
  7. Submariner를 관리 클러스터에 배포한 후 다음 명령을 실행하여 submariner ManagedClusterAddOn 의 상태를 확인하여 Submariner 배포 상태를 확인할 수 있습니다.

    oc -n <managed-cluster-name> get managedclusteraddons submariner -oyaml

    managed-cluster-name 을 관리 클러스터의 이름으로 교체합니다.

    Submariner ManagedClusterAddOn 의 상태에서 세 가지 조건은 Submariner의 배포 상태를 나타냅니다.

    • SubmarinerGatewayNodesLabeled 조건은 관리 클러스터에 Submariner 게이트웨이 노드가 레이블이 있는지 여부를 나타냅니다.
    • SubmarinerAgentDegraded 조건은 Submariner가 관리 클러스터에 성공적으로 배포되었는지 여부를 나타냅니다.
    • SubmarinerConnectionDegraded 조건은 관리 클러스터에서 Submariner를 사용하여 설정된 연결 수를 나타냅니다.

1.4.6. 하위 배포 사용자 정의

NATT(Network Address Translation-Traversal) 포트, 게이트웨이 노드 수, 게이트웨이 노드의 인스턴스 유형을 포함하여 Submariner 배포의 일부 설정을 사용자 지정할 수 있습니다. 이러한 사용자 지정은 모든 공급자에서 일관되게 유지됩니다.

1.4.6.1. NATT 포트

NATT 포트를 사용자 지정하려면 공급자 환경에 다음 YAML 콘텐츠를 사용자 지정하고 적용합니다.

apiVersion: submarineraddon.open-cluster-management.io/v1alpha1
kind: SubmarinerConfig
metadata:
    name: submariner
    namespace: <managed-cluster-namespace>
spec:
    credentialsSecret:
      name: <managed-cluster-name>-<provider>-creds
    IPSecNATTPort: <NATTPort>
  • managed-cluster-namespace 를 관리 클러스터의 네임스페이스로 교체합니다.
  • managed-cluster-name 을 관리 클러스터 이름으로 교체

    • AWS: 공급자aws 로 바꿉니다. < managed-cluster-name>-aws-creds 의 값은 허브 클러스터의 클러스터 네임스페이스에서 찾을 수 있는 AWS 인증 정보 시크릿 이름입니다.
    • GCP: 공급자gcp 로 바꿉니다. < managed-cluster-name>-gcp-creds 의 값은 허브 클러스터의 클러스터 네임스페이스에서 찾을 수 있는 Google Cloud Platform 인증 정보 시크릿 이름입니다.
    • OpenStack: 공급자osp 로 바꿉니다. < managed-cluster-name>-osp-creds 의 값은 허브 클러스터의 클러스터 네임스페이스에서 찾을 수 있는 Red Hat OpenStack Platform 인증 정보 시크릿 이름입니다.
    • Azure: 공급자azure 로 바꿉니다. < managed-cluster-name>-azure-creds 의 값은 허브 클러스터의 클러스터 네임스페이스에서 찾을 수 있는 Microsoft Azure 인증 정보 시크릿 이름입니다.
  • managed-cluster-namespace 를 관리 클러스터의 네임스페이스로 교체합니다.
  • managed-cluster-name 을 관리 클러스터 이름으로 교체합니다. managed-cluster-name-gcp-creds 의 값은 허브 클러스터의 클러스터 네임스페이스에서 찾을 수 있는 Google Cloud Platform 인증 정보 시크릿 이름입니다.
  • NATTPort 를 사용하려는 NATT 포트로 교체합니다.

참고: SubmarinerConfig 의 이름은 예와 같이 잠수함 이어야 합니다.

1.4.6.2. 게이트웨이 노드 수

게이트웨이 노드 수를 사용자 지정하려면 다음 예와 유사한 YAML 콘텐츠를 사용자 지정하고 적용합니다.

apiVersion: submarineraddon.open-cluster-management.io/v1alpha1
kind: SubmarinerConfig
metadata:
   name: submariner
   namespace: <managed-cluster-namespace>
spec:
   credentialsSecret:
     name: <managed-cluster-name>-<provider>-creds
  gatewayConfig:
      gateways: <gateways>
  • managed-cluster-namespace 를 관리 클러스터의 네임스페이스로 교체합니다.
  • managed-cluster-name 을 관리 클러스터 이름으로 교체합니다.

    • AWS: 공급자aws 로 바꿉니다. < managed-cluster-name>-aws-creds 의 값은 허브 클러스터의 클러스터 네임스페이스에서 찾을 수 있는 AWS 인증 정보 시크릿 이름입니다.
    • GCP: 공급자gcp 로 바꿉니다. < managed-cluster-name>-gcp-creds 의 값은 허브 클러스터의 클러스터 네임스페이스에서 찾을 수 있는 Google Cloud Platform 인증 정보 시크릿 이름입니다.
    • OpenStack: 공급자osp 로 바꿉니다. < managed-cluster-name>-osp-creds 의 값은 허브 클러스터의 클러스터 네임스페이스에서 찾을 수 있는 Red Hat OpenStack Platform 인증 정보 시크릿 이름입니다.
    • Azure: 공급자azure 로 바꿉니다. < managed-cluster-name>-azure-creds 의 값은 허브 클러스터의 클러스터 네임스페이스에서 찾을 수 있는 Microsoft Azure 인증 정보 시크릿 이름입니다.
  • 게이트웨이 를 사용하려는 게이트웨이 수로 바꿉니다. 값이 1보다 크면 Submariner 게이트웨이는 고가용성을 자동으로 활성화합니다.

참고: SubmarinerConfig 의 이름은 예와 같이 잠수함 이어야 합니다.

1.4.6.3. 게이트웨이 노드의 인스턴스 유형

게이트웨이 노드의 인스턴스 유형을 사용자 지정하려면 다음 예와 유사한 YAML 콘텐츠를 사용자 지정하고 적용합니다.

apiVersion: submarineraddon.open-cluster-management.io/v1alpha1
kind: SubmarinerConfig
metadata:
   name: submariner
   namespace: <managed-cluster-namespace>
spec:
   credentialsSecret:
     name: <managed-cluster-name>-<provider>-creds
  gatewayConfig:
      instanceType: <instance-type>
  • managed-cluster-namespace 를 관리 클러스터의 네임스페이스로 교체합니다.
  • managed-cluster-name 을 관리 클러스터 이름으로 교체합니다.

    • AWS: 공급자aws 로 바꿉니다. < managed-cluster-name>-aws-creds 의 값은 허브 클러스터의 클러스터 네임스페이스에서 찾을 수 있는 AWS 인증 정보 시크릿 이름입니다.
    • GCP: 공급자gcp 로 바꿉니다. < managed-cluster-name>-gcp-creds 의 값은 허브 클러스터의 클러스터 네임스페이스에서 찾을 수 있는 Google Cloud Platform 인증 정보 시크릿 이름입니다.
    • OpenStack: 공급자osp 로 바꿉니다. < managed-cluster-name>-osp-creds 의 값은 허브 클러스터의 클러스터 네임스페이스에서 찾을 수 있는 Red Hat OpenStack Platform 인증 정보 시크릿 이름입니다.
    • Azure: 공급자azure 로 바꿉니다. < managed-cluster-name>-azure-creds 의 값은 허브 클러스터의 클러스터 네임스페이스에서 찾을 수 있는 Microsoft Azure 인증 정보 시크릿 이름입니다.
  • 인스턴스 유형을 사용하려는 AWS 인스턴스 유형으로 교체합니다.

참고: SubmarinerConfig 의 이름은 예와 같이 잠수함 이어야 합니다.

1.4.6.4. Cable 드라이버

Submariner Gateway Engine 구성 요소는 다른 클러스터에 대한 보안 터널을 생성합니다. 케이블 드라이버 구성 요소는 게이트웨이 엔진 구성 요소에서 플러그형 아키텍처를 사용하여 터널을 유지 관리합니다. 케이블 엔진 구성 요소의 cableDriver 구성에 Libreswan 또는 VXLAN 구현을 사용할 수 있습니다. 다음 예제를 참조하십시오.

apiVersion: submarineraddon.open-cluster-management.io/v1alpha1
kind: SubmarinerConfig
metadata:
   name: submariner
   namespace: <managed-cluster-namespace>
spec:
   cableDriver: vxlan
   credentialsSecret:
     name: <managed-cluster-name>-<provider>-creds

모범 사례: 공용 네트워크에서 VXLAN 케이블 드라이버를 사용하지 마십시오. VXLAN 케이블 드라이버는 암호화되지 않습니다. 사설 네트워크에서 불필요한 이중 암호화를 방지하려면 VXLAN만 사용하십시오. 예를 들어 일부 온프레미스 환경에서는 전용 라인 수준 하드웨어 장치를 사용하여 터널의 암호화를 처리할 수 있습니다.

1.4.6.5. 사용자 지정 Submariner 서브스크립션 사용

Submariner 애드온은 Submariner에 대한 서브스크립션을 자동으로 구성합니다. 이렇게 하면 설치된 Red Hat Advanced Cluster Management 버전에 적합한 Submariner 버전이 설치되고 최신 상태로 유지됩니다. 이 동작을 변경하거나 Submariner 업그레이드를 수동으로 제어하려는 경우 Submariner 서브스크립션을 사용자 지정할 수 있습니다.

사용자 지정 Submariner 서브스크립션을 사용하는 경우 다음 필드를 완료해야 합니다.

  • Source: Submariner 서브스크립션에 사용할 카탈로그 소스입니다. 예를 들면 redhat-operators 입니다.
  • 소스 네임스페이스: 카탈로그 소스의 네임스페이스입니다. 예를 들면 openshift-marketplace 입니다.
  • 채널: 서브스크립션을 팔로우할 채널입니다. 예를 들어 Red Hat Advanced Cluster Management 2.10의 경우 stable-0.17 입니다.
  • CSV 시작(선택 사항): 초기 ClusterServiceVersion.
  • 계획 승인 설치: 설치 계획을 수동으로 또는 자동으로 승인합니다.

참고: 설치 계획을 수동으로 승인하려면 사용자 지정된 Submariner 서브스크립션을 사용해야 합니다.

1.4.7. Submariner의 서비스 검색 관리

Submariner를 관리 클러스터와 동일한 환경에 배포하면 관리 클러스터 세트의 클러스터 전체의 Pod와 서비스 간의 보안 IP 라우팅을 위해 경로가 구성됩니다.

1.4.7.1. Submariner에 대한 서비스 검색 활성화

관리 클러스터 세트의 다른 클러스터에 대해 클러스터에서 서비스를 표시하고 검색할 수 있도록 하려면 ServiceExport 오브젝트를 생성해야 합니다. ServiceExport 오브젝트로 서비스를 내보낸 후 <service>.< namespace>.svc.clusterset.local 형식으로 서비스에 액세스할 수 있습니다. 여러 클러스터에서 이름이 동일하고 동일한 네임스페이스에서 서비스를 내보내는 경우 다른 클러스터에서 해당 서비스를 단일 논리 서비스로 인식합니다.

이 예제에서는 default 네임스페이스의 nginx 서비스를 사용하지만 Kubernetes ClusterIP 서비스 또는 헤드리스 서비스를 검색할 수 있습니다.

  1. 다음 명령을 입력하여 ManagedClusterSet 에 있는 관리형 클러스터에 nginx 서비스의 인스턴스를 적용합니다.

    oc -n default create deployment nginx --image=nginxinc/nginx-unprivileged:stable-alpine
    oc -n default expose deployment nginx --port=8080
  2. 다음 명령과 유사한 하위 툴로 명령을 입력하여 ServiceExport 항목을 생성하여 서비스를 내보냅니다.

    subctl export service --namespace <service-namespace> <service-name>

    service-namespace 를 서비스가 있는 네임스페이스의 이름으로 교체합니다. 이 예에서는 기본값 입니다.

    service-name 을 내보내는 서비스 이름으로 교체합니다. 이 예에서는 nginx 입니다.

    사용 가능한 다른 플래그에 대한 자세한 내용은 Submariner 문서의 내보내기 를 참조하십시오.

  3. 다른 관리 클러스터에서 다음 명령을 실행하여 nginx 서비스에 액세스할 수 있는지 확인합니다.

    oc -n default run --generator=run-pod/v1 tmp-shell --rm -i --tty --image quay.io/submariner/nettest -- /bin/bash curl nginx.default.svc.clusterset.local:8080

이제 nginx 서비스 검색이 Submariner에 대해 구성됩니다.

1.4.7.2. Submariner에 대한 서비스 검색 비활성화

서비스를 다른 클러스터로 내보내지 않도록 비활성화하려면 nginx 에 대해 다음 예와 유사한 명령을 입력합니다.

subctl unexport service --namespace <service-namespace> <service-name>

service-namespace 를 서비스가 있는 네임스페이스의 이름으로 교체합니다.

service-name 을 내보내는 서비스 이름으로 교체합니다.

사용 가능한 다른 플래그에 대한 자세한 내용은 Submariner 문서의 내보내기 를 참조하십시오.

이 서비스는 더 이상 클러스터에서 검색할 수 없습니다.

1.4.8. Submariner 제거

Kubernetes 콘솔 또는 명령줄에 Red Hat Advanced Cluster Management를 사용하여 클러스터에서 Submariner 구성 요소를 제거할 수 있습니다. 0.12 이전의 Submariner 버전의 경우 모든 데이터 플레인 구성 요소를 완전히 제거하려면 추가 단계가 필요합니다. Submariner uninstall은 idempotent이므로 문제 없이 단계를 반복할 수 있습니다.

1.4.8.1. 콘솔을 사용하여 Submariner 설치 제거

콘솔을 사용하여 클러스터에서 Submariner를 설치 제거하려면 다음 단계를 완료하십시오.

  1. 콘솔 탐색에서 Infrastructure > Clusters 를 선택하고 Cluster sets 탭을 선택합니다.
  2. Submariner 구성 요소를 제거할 클러스터가 포함된 클러스터 세트를 선택합니다.
  3. Submariner Add-ons 탭을 선택하여 Submariner가 배포된 클러스터 세트의 클러스터를 확인합니다.
  4. Submariner를 제거하려는 클러스터의 작업 메뉴에서 애드온 제거를 선택합니다.
  5. Submariner를 제거하려는 클러스터의 작업 메뉴에서 클러스터 세트 삭제 를 선택합니다.
  6. Submariner를 제거하는 다른 클러스터에 대해 해당 단계를 반복합니다.

    팁: 여러 클러스터를 선택하고 작업을 클릭하여 동일한 클러스터의 여러 클러스터에서 Submariner 애드온을 제거할 수 있습니다. Uninstall Submariner 애드온 을 선택합니다.

제거 중인 Submariner 버전이 버전 0.12 이전 버전인 경우 수동으로 Submariner 제거를 계속합니다. Submariner 버전이 0.12 이상이면 Submariner가 제거됩니다.

중요: 클라우드 공급자의 추가 비용을 방지하기 위해 모든 클라우드 리소스가 클라우드 공급자에서 제거되었는지 확인합니다. 자세한 내용은 Submariner 리소스 제거 확인을 참조하십시오.

1.4.8.2. CLI를 사용하여 Submariner 설치 제거

명령줄을 사용하여 Submariner를 제거하려면 다음 단계를 완료하십시오.

  1. 다음 명령을 실행하여 클러스터의 Submariner 배포를 제거합니다.

    oc -n <managed-cluster-namespace> delete managedclusteraddon submariner

    managed-cluster-namespace 를 관리 클러스터의 네임스페이스로 교체합니다.

  2. 다음 명령을 실행하여 클러스터의 클라우드 리소스를 제거합니다.

    oc -n <managed-cluster-namespace> delete submarinerconfig submariner

    managed-cluster-namespace 를 관리 클러스터의 네임스페이스로 교체합니다.

  3. 다음 명령을 실행하여 브로커 세부 정보를 제거하도록 클러스터 세트를 삭제합니다.

    oc delete managedclusterset <managedclusterset>

    managedclusterset 을 관리 클러스터 세트의 이름으로 교체합니다.

제거 중인 Submariner 버전이 버전 0.12 이전 버전인 경우 수동으로 Submariner 제거를 계속합니다. Submariner 버전이 0.12 이상이면 Submariner가 제거됩니다.

중요: 클라우드 공급자의 추가 비용을 방지하기 위해 모든 클라우드 리소스가 클라우드 공급자에서 제거되었는지 확인합니다. 자세한 내용은 Submariner 리소스 제거 확인을 참조하십시오.

1.4.8.3. 수동으로 Submariner 설치 제거

버전 0.12 미만의 Submariner 버전을 제거하는 경우 Submariner 문서의 수동 설치 제거 섹션에서 5-8 단계를 완료합니다.

이러한 단계를 완료하면 하위 구성 요소가 클러스터에서 제거됩니다.

중요: 클라우드 공급자의 추가 비용을 방지하기 위해 모든 클라우드 리소스가 클라우드 공급자에서 제거되었는지 확인합니다. 자세한 내용은 Submariner 리소스 제거 확인을 참조하십시오.

1.4.8.4. Submariner 리소스 제거 확인

Submariner를 제거한 후 모든 Submariner 리소스가 클러스터에서 제거되었는지 확인합니다. 클러스터가 클러스터에 남아 있으면 일부 리소스는 인프라 공급자의 비용이 계속 발생합니다. 다음 단계를 완료하여 클러스터에 추가 Submariner 리소스가 없는지 확인합니다.

  1. 다음 명령을 실행하여 클러스터에 남아 있는 Submariner 리소스를 나열합니다.

    oc get cluster <CLUSTER_NAME> grep submariner

    CLUSTER_NAME 을 클러스터 이름으로 바꿉니다.

  2. 다음 명령을 입력하여 목록의 리소스를 제거합니다.

    oc delete resource <RESOURCE_NAME> cluster <CLUSTER_NAME>

    RESOURCE_NAME 을 삭제하려는 Submariner 리소스의 이름으로 교체합니다.

  3. 검색에서 리소스를 식별할 때까지 각 클러스터에 대해 1-2단계를 반복합니다.

Submariner 리소스가 클러스터에서 제거됩니다.

법적 공지

Copyright © 2024 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.