Skip to main content
본 한국어 번역은 사용자 편의를 위해 제공되는 기계 번역입니다. 영어 버전과 한국어 버전이 서로 어긋나는 경우에는 언제나 영어 버전이 우선합니다.

앱 관리를 시작합니다

기여자
PDF

먼저 해 "Astra Control 관리에 클러스터를 추가합니다", 클러스터(Astra Control 외부)에 앱을 설치한 다음 Astra Control의 애플리케이션 페이지로 이동하여 앱과 리소스를 정의할 수 있습니다.

실행 중인 Pod가 있는 스토리지 리소스가 포함된 앱 또는 실행 중인 Pod 없이 스토리지 리소스가 포함된 앱을 정의하고 관리할 수 있습니다. 실행 중인 Pod가 없는 앱을 데이터 전용 애플리케이션이라고 합니다.

설명합니다

Astra Control에는 다음과 같은 애플리케이션 관리 요구 사항이 있습니다.

  • * 라이선스 *: Astra Control Center를 사용하여 애플리케이션을 관리하려면 Astra Control Center 평가판 라이센스 또는 전체 라이센스가 필요합니다.

  • * 네임스페이스 *: Astra Control을 사용하여 단일 클러스터에서 하나 이상의 지정된 네임스페이스 내에서 응용 프로그램을 정의할 수 있습니다. 앱은 동일한 클러스터 내에서 여러 네임스페이스에 걸쳐 있는 리소스를 포함할 수 있습니다. Astra Control은 여러 클러스터에서 앱을 정의하는 기능을 지원하지 않습니다.

  • * 스토리지 클래스 *: 스토리지 클래스가 명시적으로 설정된 애플리케이션을 설치하고 앱을 복제해야 하는 경우 클론 작업의 타겟 클러스터에 원래 지정된 스토리지 클래스가 있어야 합니다. 명시적으로 설정된 스토리지 클래스를 가진 애플리케이션을 동일한 스토리지 클래스가 없는 클러스터로 클론 복제하면 실패합니다.

  • * Kubernetes 리소스 *: Astra Control에서 수집하지 않은 Kubernetes 리소스를 사용하는 애플리케이션에는 전체 앱 데이터 관리 기능이 없을 수 있습니다. Astra Control은 다음과 같은 Kubernetes 리소스를 수집합니다.

    ClusterRole

    ClusterRoleBinding

    ConfigMap

    CronJob

    CustomResourceDefinition

    CustomResource

    DaemonSet

    DeploymentConfig

    HorizontalPodAutoscaler

    Ingress

    MutatingWebhook

    NetworkPolicy

    PersistentVolumeClaim

    Pod

    PodDisruptionBudget

    PodTemplate

    ReplicaSet

    Role

    RoleBinding

    Route

    Secret

    Service

    ServiceAccount

    StatefulSet

    ValidatingWebhook

지원되는 앱 설치 방법

Astra Control은 다음과 같은 응용 프로그램 설치 방법을 지원합니다.

  • * 매니페스트 파일 *: Astra Control은 kubctl을 사용하여 매니페스트 파일에서 설치된 앱을 지원합니다. 예를 들면 다음과 같습니다.

    kubectl apply -f myapp.yaml

  • * Helm 3 *: Helm을 사용하여 앱을 설치하는 경우 Astra Control에 Helm 버전 3이 필요합니다. Helm 3(또는 Helm 2에서 Helm 3으로 업그레이드)과 함께 설치된 앱의 관리 및 클론 생성이 완벽하게 지원됩니다. Helm 2가 설치된 앱 관리는 지원되지 않습니다.

  • * 운용자 구축 앱 *: Astra Control은 네임스페이스 범위 연산자로 설치된 앱을 지원합니다. 일반적으로 "pass-by-reference" 아키텍처가 아니라 "pass-by-value"로 설계되었습니다. 운영자와 설치하는 앱은 동일한 네임스페이스를 사용해야 합니다. 운영자의 배포 YAML 파일을 수정해야 이 문제가 발생할 수 있습니다.

    다음은 이러한 패턴을 따르는 일부 운영자 앱에 대한 설명입니다.

    • "아파치 K8ssandra"

      참고 K8ssandra 의 경우 현재 위치 복원 작업이 지원됩니다. 새 네임스페이스 또는 클러스터에 대한 복원 작업을 수행하려면 응용 프로그램의 원래 인스턴스를 중단해야 합니다. 이는 이월된 피어 그룹 정보가 인스턴스 간 통신으로 이어지지 않도록 하기 위한 것입니다. 앱 복제는 지원되지 않습니다.

    • "젠킨스 CI"

    • "Percona XtraDB 클러스터"

    Astra Control은 "pass-by-reference" 아키텍처(예: CockroachDB 운영자)로 설계된 운영자를 복제하지 못할 수 있습니다. 이러한 유형의 클론 복제 작업 중에 클론 복제 운영자는 클론 복제 프로세스의 일부로 고유한 새로운 암호가 있음에도 불구하고 소스 운영자의 Kubernetes 암호를 참조하려고 합니다. Astra Control이 소스 운영자의 Kubernetes 암호를 모르기 때문에 클론 작업이 실패할 수 있습니다.

클러스터에 앱을 설치합니다

먼저 해 "클러스터가 추가되었습니다" Astra Control은 클러스터에서 앱을 설치하거나 기존 앱을 관리할 수 있습니다. 하나 이상의 네임스페이스로 범위가 지정된 모든 앱을 관리할 수 있습니다.

앱 정의

Astra Control이 클러스터에서 네임스페이스를 검색한 후 관리할 애플리케이션을 정의할 수 있습니다. 선택할 수 있습니다 하나 이상의 네임스페이스를 포괄하는 응용 프로그램을 관리합니다 또는 전체 네임스페이스를 단일 애플리케이션으로 관리합니다. 데이터 보호 작업에 필요한 세분화 수준으로 세분화됩니다.

Astra Control을 사용하면 계층 구조의 수준(네임스페이스 및 해당 네임스페이스 또는 스패닝 네임스페이스의 응용 프로그램)을 별도로 관리할 수 있지만 가장 좋은 방법은 하나 또는 다른 수준을 선택하는 것입니다. 작업이 네임스페이스 및 앱 수준에서 동시에 발생하면 Astra Control에서 수행하는 작업이 실패할 수 있습니다.

팁 예를 들어, "Maria"에 대해 주간 백업 주기를 갖는 백업 정책을 설정할 수 있지만 "MariaDB"(동일한 네임스페이스)를 더 자주 백업해야 할 수 있습니다. 이러한 요구사항에 따라 단일 네임스페이스 앱이 아니라 앱을 별도로 관리해야 합니다.
시작하기 전에
이 작업에 대해
애플리케이션 관리 옵션

앱으로 관리할 리소스를 정의합니다

를 지정할 수 있습니다 "앱을 구성하는 Kubernetes 리소스" Astra Control을 통해 관리하고자 하는 것입니다. 앱을 정의하면 Kubernetes 클러스터의 요소를 단일 애플리케이션으로 그룹화할 수 있습니다. 이 Kubernetes 리소스 모음은 네임스페이스 및 레이블 선택기 기준에 따라 구성됩니다.

앱을 정의하면 클론, 스냅샷, 백업을 비롯한 Astra Control 작업에 포함할 항목을 보다 세부적으로 제어할 수 있습니다.

경고 앱을 정의할 때 보호 정책이 있는 여러 앱에 Kubernetes 리소스를 포함하지 않아야 합니다. Kubernetes 리소스의 보호 정책이 중복되어 데이터 충돌이 발생할 수 있습니다. 예를 들어, 자세한 내용을 읽어보십시오.
앱 네임스페이스에 클러스터 범위 리소스를 추가하는 방법에 대한 자세한 내용은 을(를) 참조하십시오.

Namespace 리소스와 연결된 클러스터 리소스 및 자동으로 포함된 Astra Control을 가져올 수 있습니다. 특정 그룹, 종류, 버전 및 레이블(선택 사항)의 리소스를 포함할 규칙을 추가할 수 있습니다. Astra Control에 자동으로 포함되지 않는 리소스가 있는 경우 이 작업을 수행할 수 있습니다.

Astra Control에 의해 자동으로 포함되는 클러스터 범위 리소스는 제외할 수 없습니다.

다음을 추가할 수 있습니다 apiVersions (API 버전과 결합된 그룹):

자원 종류 apiVersions(그룹 + 버전)

ClusterRole

rbac.authorization.k8s.io/v1

ClusterRoleBinding

rbac.authorization.k8s.io/v1

CustomResource

apiextensions.k8s.io/v1, apiextensions.k8s.io/v1beta1

CustomResourceDefinition

apiextensions.k8s.io/v1, apiextensions.k8s.io/v1beta1

MutatingWebhookConfiguration

Admissions registration.k8s.io/v1

ValidatingWebhookConfiguration

Admissions registration.k8s.io/v1
단계

  1. 응용 프로그램 페이지에서 * 정의 * 를 선택합니다.

  2. 응용 프로그램 정의 * 창에서 응용 프로그램 이름을 입력합니다.

  3. 응용 프로그램이 실행되는 클러스터를 * 클러스터 * 드롭다운 목록에서 선택합니다.

  4. Namespace* 드롭다운 목록에서 응용 프로그램의 네임스페이스를 선택합니다.

    참고 Astra Control을 사용하여 단일 클러스터에서 하나 이상의 지정된 네임스페이스 내에서 앱을 정의할 수 있습니다. 앱은 동일한 클러스터 내에서 여러 네임스페이스에 걸쳐 있는 리소스를 포함할 수 있습니다. Astra Control은 여러 클러스터에서 앱을 정의하는 기능을 지원하지 않습니다.

  5. (선택 사항) 각 네임스페이스에서 Kubernetes 리소스에 대한 레이블을 입력합니다. 단일 레이블 또는 레이블 선택 조건(쿼리)을 지정할 수 있습니다.

    팁 Kubernetes 레이블에 대해 자세히 알아보려면 "Kubernetes 공식 문서를 참조하십시오".

  6. (선택 사항) * 네임스페이스 추가 * 를 선택하고 드롭다운 목록에서 네임스페이스를 선택하여 앱에 대한 네임스페이스를 추가합니다.

  7. (선택 사항) 추가하는 모든 추가 네임스페이스에 대한 단일 레이블 또는 레이블 선택기 조건을 입력합니다.

  8. (선택 사항) Astra Control에 자동으로 포함되는 리소스 외에 클러스터 범위 리소스를 포함하려면 * 추가 클러스터 범위 리소스 포함 * 을 선택하여 다음을 완료합니다.

    1. 포함 규칙 추가 * 를 선택합니다.

    2. * Group *: 드롭다운 목록에서 리소스의 API 그룹을 선택합니다.

    3. * Kind *: 드롭다운 목록에서 개체 스키마의 이름을 선택합니다.

    4. * 버전 *: API 버전을 입력합니다.

    5. * 라벨 선택기 *: 규칙에 추가할 라벨을 선택적으로 포함합니다. 이 레이블은 이 레이블과 일치하는 리소스만 검색하는 데 사용됩니다. 레이블을 제공하지 않으면 Astra Control은 해당 클러스터에 대해 지정된 리소스 유형의 모든 인스턴스를 수집합니다.

    6. 항목에 따라 만들어진 규칙을 검토합니다.

    7. 추가 * 를 선택합니다.

      팁 클러스터 범위의 리소스 규칙을 원하는 만큼 만들 수 있습니다. 규칙은 애플리케이션 요약 정의에 나타납니다.

  9. 정의 * 를 선택합니다.

  10. 정의 * 를 선택한 후 필요에 따라 다른 앱에 대해 프로세스를 반복합니다.

앱 정의를 마치면 앱이 에 나타납니다 Healthy 응용 프로그램 페이지의 응용 프로그램 목록에서 상태를 지정합니다. 이제 클론을 생성하고 백업과 스냅샷을 생성할 수 있습니다.

참고 방금 추가한 앱에는 Protected(보호) 열 아래에 백업이 없고 아직 백업이 예약되지 않았음을 나타내는 경고 아이콘이 있을 수 있습니다.
팁 특정 앱의 세부 정보를 보려면 앱 이름을 선택합니다.

이 앱에 추가된 리소스를 보려면 * 리소스 * 탭을 선택하십시오. 리소스 열에서 리소스 이름 뒤의 숫자를 선택하거나 검색 에 리소스 이름을 입력하여 추가 클러스터 범위 리소스가 포함되도록 합니다.

앱으로 관리할 네임스페이스를 정의합니다

네임스페이스의 리소스를 애플리케이션으로 정의하여 Astra Control 관리에 네임스페이스의 모든 Kubernetes 리소스를 추가할 수 있습니다. 이 방법은 특정 네임스페이스의 모든 리소스를 비슷한 방식으로 일정한 간격으로 관리하고 보호하려는 경우 앱을 개별적으로 정의하는 것이 좋습니다.

단계

  1. 클러스터 페이지에서 클러스터를 선택합니다.

  2. Namespaces* 탭을 선택합니다.

  3. 관리하려는 앱 리소스가 포함된 네임스페이스의 작업 메뉴를 선택하고 * 응용 프로그램으로 정의 * 를 선택합니다.

    팁 여러 응용 프로그램을 정의하려면 네임스페이스 목록에서 선택하고 왼쪽 위 모서리에 있는 * 작업 * 버튼을 선택한 다음 * 응용 프로그램으로 정의 * 를 선택합니다. 이렇게 하면 개별 네임스페이스에 여러 개의 개별 응용 프로그램이 정의됩니다. 다중 네임스페이스 응용 프로그램의 경우 를 참조하십시오 앱으로 관리할 리소스를 정의합니다.
    참고 기본적으로 앱 관리에 사용되지 않는 시스템 네임스페이스를 표시하려면 * Show system namespaces * 확인란을 선택합니다. Namespaces 탭에서 사용할 수 있는 * Show system namespaces * 옵션을 보여 주는 스크린샷 "자세히 보기".

프로세스가 완료되면 해당 네임스페이스와 연결된 응용 프로그램이 '연결된 응용 프로그램' 열에 나타납니다.

[기술 미리보기] Kubernetes 맞춤형 리소스를 사용하여 애플리케이션을 정의합니다

Astra Control을 통해 관리할 Kubernetes 리소스를 사용자 지정 리소스(CR)를 사용하여 애플리케이션으로 정의하여 지정할 수 있습니다. 예를 들어, 특정 네임스페이스의 모든 리소스를 비슷한 방식으로 공통 간격으로 관리 및 보호하려는 경우, 해당 리소스를 개별적으로 또는 모든 Kubernetes 리소스를 네임스페이스에서 관리하려는 경우 클러스터 범위 리소스를 추가할 수 있습니다.

단계

  1. 사용자 정의 리소스(CR) 파일을 만들고 이름을 지정합니다(예: astra_mysql_app.yaml)를 클릭합니다.

  2. 애플리케이션 이름을 에 지정합니다 metadata.name.

  3. 관리할 애플리케이션 리소스 정의:

    spec.includedClusterScopedResources

    Astra Control에 자동으로 포함되는 리소스 유형 외에 클러스터 범위 리소스 유형 포함

    • spec.includedClusterScopedResources: _ (선택 사항) _ 포함할 클러스터 범위 리소스 유형의 목록입니다.

      • groupVersionKind:_(선택 사항) _ 종류를 명확하게 식별합니다.

        • * group *: _ (groupVersionKind가 사용되는 경우 필수) _ 포함할 리소스의 API 그룹입니다.

        • * VERSION *: _ (groupVersionKind를 사용하는 경우 필수) _ 포함할 리소스의 API 버전입니다.

        • * kind *: _ (groupVersionKind를 사용하는 경우 필수) _ 포함할 리소스의 종류.

      • * labelSelector *: _ (선택 사항) _ 리소스 집합에 대한 레이블 쿼리입니다. 레이블과 일치하는 리소스만 검색하는 데 사용됩니다. 레이블을 제공하지 않으면 Astra Control은 해당 클러스터에 대해 지정된 리소스 유형의 모든 인스턴스를 수집합니다. MatchLabels 및 MatchExpressions의 결과는 ANDed입니다.

        • * matchLabels *: _ (선택 사항) _ {key, value} 쌍의 맵입니다. matchLabels 맵의 단일 {key,value}은 키 필드가 "key"이고 연산자는 "in"이고 값 배열만 포함하는 matchExpressions의 요소와 같습니다. 요구 사항은 ANDed입니다.

        • * matchExpressions *:_(선택 사항) _ 라벨 선택기 요구 사항 목록입니다. 요구 사항은 ANDed입니다.

          • * key *: _ (matchExpressions를 사용하는 경우 필수) _ 라벨 선택기와 관련된 라벨 키입니다.

          • * operator *: _ (matchExpressions를 사용하는 경우 필수) _ 값 집합에 대한 키의 관계를 나타냅니다. 유효한 연산자는 다음과 같습니다 In, NotIn, Exists 및 DoesNotExist.

          • * values *: _ (matchExpressions를 사용하는 경우 필수) _ 문자열 값의 배열입니다. 오퍼레이터가 인 경우 In 또는 NotIn`값 배열은 반드시 _not_이어야 합니다. 오퍼레이터가 인 경우 `Exists 또는 `DoesNotExist`값 배열은 비어 있어야 합니다.

    spec.includedNamespaces

    응용 프로그램의 해당 리소스 내에 네임스페이스와 리소스를 포함합니다.

    • spec.includedNamespaces: _ (필수) _ 리소스 선택을 위한 네임스페이스 및 선택적 필터를 정의합니다.

      • * namespace *: _ (필수) _ Astra Control을 사용하여 관리하려는 앱 리소스가 포함된 네임스페이스입니다.

      • * labelSelector *: _ (선택 사항) _ 리소스 집합에 대한 레이블 쿼리입니다. 레이블과 일치하는 리소스만 검색하는 데 사용됩니다. 레이블을 제공하지 않으면 Astra Control은 해당 클러스터에 대해 지정된 리소스 유형의 모든 인스턴스를 수집합니다. MatchLabels 및 MatchExpressions의 결과는 ANDed입니다.

        • * matchLabels *: _ (선택 사항) _ {key, value} 쌍의 맵입니다. matchLabels 맵의 단일 {key,value}은 키 필드가 "key"이고 연산자는 "in"이고 값 배열만 포함하는 matchExpressions의 요소와 같습니다. 요구 사항은 ANDed입니다.

        • * matchExpressions *:_(선택 사항) _ 라벨 선택기 요구 사항 목록입니다. key 및 operator 필수 항목입니다. 요구 사항은 ANDed입니다.

          • * key *: _ (matchExpressions를 사용하는 경우 필수) _ 라벨 선택기와 관련된 라벨 키입니다.

          • * operator *: _ (matchExpressions를 사용하는 경우 필수) _ 값 집합에 대한 키의 관계를 나타냅니다. 유효한 연산자는 다음과 같습니다 In, NotIn, Exists 및 DoesNotExist.

          • * values *: _ (matchExpressions를 사용하는 경우 필수) _ 문자열 값의 배열입니다. 오퍼레이터가 인 경우 In 또는 NotIn`값 배열은 반드시 _not_이어야 합니다. 오퍼레이터가 인 경우 `Exists 또는 `DoesNotExist`값 배열은 비어 있어야 합니다.

    YAML 예:

    apiVersion: astra.netapp.io/v1
kind: Application
metadata:
  name: astra_mysql_app
spec:
  includedNamespaces:
    - namespace: astra_mysql_app
      labelSelector:
        matchLabels:
          app: nginx
          env: production
        matchExpressions:
          - key: tier
            operator: In
            values:
              - frontend
              - backend

  4. 를 채운 후 astra_mysql_app.yaml 올바른 값이 있는 파일에 CR을 적용합니다.

    kubectl apply -f astra_mysql_app.yaml -n astra-connector

시스템 네임스페이스는 어떻습니까?

Astra Control은 Kubernetes 클러스터에서 시스템 네임스페이스를 검색합니다. 기본적으로 이러한 시스템 네임스페이스는 표시되지 않습니다. 시스템 앱 리소스를 백업해야 하는 경우는 드뭅니다.

선택한 클러스터의 Namespaces 탭에서 * Show system namespaces * 확인란을 선택하여 시스템 네임스페이스를 표시할 수 있습니다.

Namespaces 탭에서 사용할 수 있는 * Show system namespaces * 옵션을 보여 주는 스크린샷

팁 Astra Control Center는 기본적으로 관리할 수 있는 애플리케이션으로 표시되지 않지만 다른 Astra Control Center 인스턴스를 사용하여 Astra Control Center 인스턴스를 백업 및 복원할 수 있습니다.

예: 다른 릴리즈에 대한 별도의 보호 정책

이 예제에서 DevOps 팀은 "카나리아" 릴리스 배포를 관리합니다. 팀의 클러스터에는 Nginx를 실행하는 3개의 포드가 있습니다. 포드 중 2개는 안정적인 릴리스 전용입니다. 세 번째 포드는 카나리 해제 시 사용합니다.

DevOps 팀의 Kubernetes 관리자가 안정적인 릴리즈 포드에 'duekment=stable'이라는 레이블을 추가합니다. 개발 팀은 카나리 릴리즈 포드에 'deement=canary' 레이블을 추가합니다.

이 팀의 안정적인 릴리즈에는 시간별 스냅샷 및 일일 백업에 대한 요구 사항이 포함됩니다. 카나리아 릴리스는 수명이 길기 때문에 '배포 = 카나리'라고 표시된 모든 것에 대해 공격적이고 단기적인 보호 정책을 만들고자 합니다.

데이터 충돌을 방지하기 위해 관리자는 "Canary" 릴리스용 앱과 "Stable" 릴리즈용 앱을 두 개 만듭니다. 이렇게 하면 두 Kubernetes 객체 그룹에 대해 백업, 스냅샷 및 클론 작업이 분리됩니다.

자세한 내용을 확인하십시오