InfoGrab Docs

GitLab 관리형 클러스터 (deprecated)

요약

GitLab Self-Managed에서 이 기능은 기본적으로 사용할 수 없습니다. GitLab이 클러스터를 관리하도록 선택할 수 있습니다. 이 기능은 GitLab 14.5에서 deprecated됨. 자체 클러스터를 관리하도록 선택하면 프로젝트별 리소스가 자동으로 생성되지 않습니다.

히스토리
Feature flag

GitLab Self-Managed에서 이 기능은 기본적으로 사용할 수 없습니다. 사용 가능하게 하려면 관리자가 certificate_based_clusters라는 기능 플래그를 활성화할 수 있습니다.

GitLab이 클러스터를 관리하도록 선택할 수 있습니다. 클러스터가 GitLab에 의해 관리되면 프로젝트에 대한 리소스가 자동으로 생성됩니다. 생성된 리소스에 대한 자세한 내용은 액세스 제어 섹션을 참조하세요.

Warning

이 기능은 GitLab 14.5에서 deprecated됨. 클러스터를 GitLab에 연결하려면 Kubernetes용 GitLab 에이전트를 사용하세요. 애플리케이션을 관리하려면 Cluster Project Management Template을 사용하세요.

자체 클러스터를 관리하도록 선택하면 프로젝트별 리소스가 자동으로 생성되지 않습니다. Auto DevOps를 사용하는 경우 배포 job이 사용할 KUBE_NAMESPACE 배포 변수를 명시적으로 제공해야 합니다. 그렇지 않으면 네임스페이스가 자동으로 생성됩니다.

Warning

네임스페이스 및 서비스 계정과 같이 GitLab이 생성한 리소스를 수동으로 관리하면 예상치 못한 오류가 발생할 수 있습니다. 이런 경우 클러스터 캐시 초기화를 시도해 보세요.

클러스터 캐시 초기화#

GitLab이 클러스터를 관리하도록 허용하면 GitLab은 프로젝트를 위해 생성하는 네임스페이스와 서비스 계정의 캐시된 버전을 저장합니다. 클러스터에서 이러한 리소스를 수동으로 수정하면 이 캐시가 클러스터와 동기화되지 않을 수 있습니다. 이로 인해 배포 job이 실패할 수 있습니다.

캐시를 초기화하려면:

  1. 프로젝트의 Operate > Kubernetes clusters 페이지로 이동하여 클러스터를 선택합니다.
  2. Advanced settings 섹션을 펼칩니다.
  3. Clear cluster cache를 선택합니다.

기본 도메인#

기본 도메인을 지정하면 KUBE_INGRESS_BASE_DOMAIN이 배포 변수로 자동 설정됩니다. Auto DevOps를 사용하는 경우 이 도메인이 다양한 Stage에서 사용됩니다. 예를 들어 Auto Review Apps 및 Auto Deploy에서 사용됩니다.

도메인은 Ingress IP 주소로 와일드카드 DNS가 구성되어 있어야 합니다. 다음 중 하나를 선택할 수 있습니다:

  • 도메인 제공자에서 Ingress IP 주소를 가리키는 A 레코드를 생성합니다.
  • nip.io 또는 xip.io와 같은 서비스를 사용하여 와일드카드 DNS 주소를 입력합니다. 예를 들어 192.168.1.1.xip.io.

외부 Ingress IP 주소 또는 외부 Ingress 호스트명을 확인하려면:

  • 클러스터가 GKE에 있는 경우:

    1. Advanced settings의 Google Kubernetes Engine 링크를 선택하거나 Google Kubernetes Engine 대시보드로 직접 이동합니다.
    2. 적절한 프로젝트와 클러스터를 선택합니다.
    3. Connect를 선택합니다.
    4. 로컬 터미널 또는 Cloud Shell을 사용하여 gcloud 명령을 실행합니다.

  • 클러스터가 GKE에 없는 경우: Kubernetes 제공자별 지침에 따라 올바른 자격 증명으로 kubectl을 구성합니다. 다음 예시의 출력은 클러스터의 외부 엔드포인트를 보여줍니다. 이 정보를 사용하여 외부 액세스를 허용하는 DNS 항목과 전달 규칙을 설정할 수 있습니다.

Ingress에 따라 외부 IP 주소를 다양한 방법으로 검색할 수 있습니다. 이 목록은 일반적인 솔루션과 일부 GitLab 전용 접근 방식을 제공합니다:

  • 일반적으로 다음을 실행하여 모든 로드 밸런서의 IP 주소를 나열할 수 있습니다:

    kubectl get svc --all-namespaces -o jsonpath='{range.items[?(@.status.loadBalancer.ingress)]}{.status.loadBalancer.ingress[*].ip} '

  • Applications를 사용하여 Ingress를 설치한 경우 다음을 실행합니다:

    kubectl get service --namespace=gitlab-managed-apps ingress-nginx-ingress-controller -o jsonpath='{.status.loadBalancer.ingress[0].ip}'

  • Amazon EKS와 같은 일부 Kubernetes 클러스터는 대신 호스트명을 반환합니다. 이런 플랫폼의 경우 다음을 실행합니다:

    kubectl get service --namespace=gitlab-managed-apps ingress-nginx-ingress-controller -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'

    EKS를 사용하는 경우 Elastic Load Balancer도 생성되며 추가 AWS 비용이 발생합니다.

  • Istio/Knative는 다른 명령을 사용합니다. 다음을 실행합니다:

    kubectl get svc --namespace=istio-system istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip} '

일부 Kubernetes 버전에서 끝에 %가 표시되면 포함하지 마세요.

GitLab 관리형 클러스터 (deprecated)

Tier: Free, Premium, Ultimate
Offering: GitLab.com, GitLab Self-Managed
원문 보기
요약

GitLab Self-Managed에서 이 기능은 기본적으로 사용할 수 없습니다. GitLab이 클러스터를 관리하도록 선택할 수 있습니다. 이 기능은 GitLab 14.5에서 deprecated됨. 자체 클러스터를 관리하도록 선택하면 프로젝트별 리소스가 자동으로 생성되지 않습니다.

히스토리
Feature flag

GitLab Self-Managed에서 이 기능은 기본적으로 사용할 수 없습니다. 사용 가능하게 하려면 관리자가 certificate_based_clusters라는 기능 플래그를 활성화할 수 있습니다.

GitLab이 클러스터를 관리하도록 선택할 수 있습니다. 클러스터가 GitLab에 의해 관리되면 프로젝트에 대한 리소스가 자동으로 생성됩니다. 생성된 리소스에 대한 자세한 내용은 액세스 제어 섹션을 참조하세요.

Warning

이 기능은 GitLab 14.5에서 deprecated됨. 클러스터를 GitLab에 연결하려면 Kubernetes용 GitLab 에이전트를 사용하세요. 애플리케이션을 관리하려면 Cluster Project Management Template을 사용하세요.

자체 클러스터를 관리하도록 선택하면 프로젝트별 리소스가 자동으로 생성되지 않습니다. Auto DevOps를 사용하는 경우 배포 job이 사용할 KUBE_NAMESPACE 배포 변수를 명시적으로 제공해야 합니다. 그렇지 않으면 네임스페이스가 자동으로 생성됩니다.

Warning

네임스페이스 및 서비스 계정과 같이 GitLab이 생성한 리소스를 수동으로 관리하면 예상치 못한 오류가 발생할 수 있습니다. 이런 경우 클러스터 캐시 초기화를 시도해 보세요.

클러스터 캐시 초기화#

GitLab이 클러스터를 관리하도록 허용하면 GitLab은 프로젝트를 위해 생성하는 네임스페이스와 서비스 계정의 캐시된 버전을 저장합니다. 클러스터에서 이러한 리소스를 수동으로 수정하면 이 캐시가 클러스터와 동기화되지 않을 수 있습니다. 이로 인해 배포 job이 실패할 수 있습니다.

캐시를 초기화하려면:

  1. 프로젝트의 Operate > Kubernetes clusters 페이지로 이동하여 클러스터를 선택합니다.
  2. Advanced settings 섹션을 펼칩니다.
  3. Clear cluster cache를 선택합니다.

기본 도메인#

기본 도메인을 지정하면 KUBE_INGRESS_BASE_DOMAIN이 배포 변수로 자동 설정됩니다. Auto DevOps를 사용하는 경우 이 도메인이 다양한 Stage에서 사용됩니다. 예를 들어 Auto Review Apps 및 Auto Deploy에서 사용됩니다.

도메인은 Ingress IP 주소로 와일드카드 DNS가 구성되어 있어야 합니다. 다음 중 하나를 선택할 수 있습니다:

  • 도메인 제공자에서 Ingress IP 주소를 가리키는 A 레코드를 생성합니다.
  • nip.io 또는 xip.io와 같은 서비스를 사용하여 와일드카드 DNS 주소를 입력합니다. 예를 들어 192.168.1.1.xip.io.

외부 Ingress IP 주소 또는 외부 Ingress 호스트명을 확인하려면:

  • 클러스터가 GKE에 있는 경우:

    1. Advanced settings의 Google Kubernetes Engine 링크를 선택하거나 Google Kubernetes Engine 대시보드로 직접 이동합니다.
    2. 적절한 프로젝트와 클러스터를 선택합니다.
    3. Connect를 선택합니다.
    4. 로컬 터미널 또는 Cloud Shell을 사용하여 gcloud 명령을 실행합니다.

  • 클러스터가 GKE에 없는 경우: Kubernetes 제공자별 지침에 따라 올바른 자격 증명으로 kubectl을 구성합니다. 다음 예시의 출력은 클러스터의 외부 엔드포인트를 보여줍니다. 이 정보를 사용하여 외부 액세스를 허용하는 DNS 항목과 전달 규칙을 설정할 수 있습니다.

Ingress에 따라 외부 IP 주소를 다양한 방법으로 검색할 수 있습니다. 이 목록은 일반적인 솔루션과 일부 GitLab 전용 접근 방식을 제공합니다:

  • 일반적으로 다음을 실행하여 모든 로드 밸런서의 IP 주소를 나열할 수 있습니다:

    kubectl get svc --all-namespaces -o jsonpath='{range.items[?(@.status.loadBalancer.ingress)]}{.status.loadBalancer.ingress[*].ip} '

  • Applications를 사용하여 Ingress를 설치한 경우 다음을 실행합니다:

    kubectl get service --namespace=gitlab-managed-apps ingress-nginx-ingress-controller -o jsonpath='{.status.loadBalancer.ingress[0].ip}'

  • Amazon EKS와 같은 일부 Kubernetes 클러스터는 대신 호스트명을 반환합니다. 이런 플랫폼의 경우 다음을 실행합니다:

    kubectl get service --namespace=gitlab-managed-apps ingress-nginx-ingress-controller -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'

    EKS를 사용하는 경우 Elastic Load Balancer도 생성되며 추가 AWS 비용이 발생합니다.

  • Istio/Knative는 다른 명령을 사용합니다. 다음을 실행합니다:

    kubectl get svc --namespace=istio-system istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip} '

일부 Kubernetes 버전에서 끝에 %가 표시되면 포함하지 마세요.