관리 리소스

원문 보기 위키 갱신 2026.10.03

관리 리소스 (Managed Resources / MR)

관리 리소스(MR)는 Provider에서 외부 서비스를 나타내는 리소스예요. 사용자가 새 관리 리소스를 만들면 Provider가 반응해 Provider 환경 안에 외부 리소스를 만들어요. Crossplane이 관리하는 모든 외부 서비스는 관리 리소스로 매핑돼요.

Crossplane은 Kubernetes 안의 객체를 관리 리소스(managed resource)라고 부르고, Provider 안의 외부 객체를 외부 리소스(external resource)라고 불러요.

출처: 문서

본문

관리 리소스의 예는 다음과 같아요.

provider-upjet-aws에 정의된 Amazon AWS EC2 Instance
provider-upjet-gcp에 정의된 Google Cloud GKE Cluster
provider-upjet-azure에 정의된 Microsoft Azure PostgreSQL Database

관리 리소스 필드 (Managed resource fields)

Provider가 관리 리소스의 group, kind, version을 정의해요. Provider는 관리 리소스의 사용 가능한 설정도 정의해요.

Group, kind, version

각 관리 리소스는 자체 group, kind, version을 가진 고유한 API 엔드포인트예요. 예를 들어 AWS Provider는 ec2.aws.m.upbound.io 그룹의 Instance kind를 정의해요.

apiVersion: ec2.aws.m.upbound.io/v1beta1
kind: Instance

forProvider

관리 리소스의 spec.forProvider는 외부 리소스의 파라미터에 매핑돼요. 예를 들어 AWS EC2 인스턴스를 만들 때 Provider는 AWS region과 instanceType이라고 하는 VM 크기 정의를 지원해요.

Provider가 설정과 유효 값을 정의해요. Provider는 forProvider 정의에서 필수·선택 값도 정의해요. 자세한 내용은 특정 Provider의 문서를 참고하세요.

apiVersion: ec2.aws.m.upbound.io/v1beta1
kind: Instance
# Removed for brevity
spec:
  forProvider:
    region: us-west-1
    instanceType: t2.micro

Crossplane은 관리 리소스의 forProvider 필드를 외부 리소스의 "진실의 원천(source of truth)"으로 간주해요. Crossplane은 Crossplane 밖에서 외부 리소스에 가해진 모든 변경을 무시해요. 사용자가 Provider의 웹 콘솔에서 변경하면 Crossplane은 forProvider 설정의 값으로 되돌려요.

다른 리소스 참조 (Referencing other resources)

관리 리소스의 일부 필드는 다른 관리 리소스의 값에 의존할 수 있어요. 예를 들어 VM은 사용할 가상 네트워크의 이름이 필요할 수 있어요.

관리 리소스는 외부 이름, 이름 참조, 셀렉터로 다른 관리 리소스를 참조할 수 있어요.

외부 이름으로 일치 (Matching by external name) — 이름으로 리소스를 일치할 때 Crossplane은 Provider 안의 외부 리소스 이름을 찾아요. 예를 들어 my-test-vpc라는 AWS VPC 객체의 외부 이름은 vpc-01353cfe93950a8ff예요.

kubectl get vpc
NAME            READY   SYNCED   EXTERNAL-NAME           AGE
my-test-vpc     True    True     vpc-01353cfe93950a8ff   49m

VPC를 이름으로 일치시키려면 외부 이름을 사용해요. 예를 들어 이 VPC에 연결된 Subnet 관리 리소스를 만드는 경우:

apiVersion: ec2.aws.m.upbound.io/v1beta1
kind: Subnet
spec:
  forProvider:
    # Removed for brevity
    vpcId: vpc-01353cfe93950a8ff

이름 참조로 일치 (Matching by name reference) — Provider 안의 외부 리소스 이름이 아닌 관리 리소스의 이름을 기반으로 리소스를 일치시키려면 nameRef를 사용해요.

apiVersion: ec2.aws.m.upbound.io/v1beta1
kind: Subnet
spec:
  forProvider:
    # Removed for brevity
    vpcIdRef: 
      name: my-test-vpc

셀렉터로 일치 (Matching by selector) — 셀렉터로 일치하는 것은 가장 유연한 일치 방법이에요. matchLabels로 리소스에 적용된 라벨을 일치시켜요. 예를 들어 이 Subnet 리소스는 my-label: label-value 라벨이 있는 VPC 리소스만 일치해요.

apiVersion: ec2.aws.m.upbound.io/v1beta1
kind: Subnet
spec:
  forProvider:
    # Removed for brevity
    vpcIdSelector: 
      matchLabels:
        my-label: label-value

컨트롤러 참조로 일치 (Matching by controller reference) — 컨트롤러 참조 일치는 일치하는 리소스가 같은 Kubernetes 컨트롤러 참조를 갖도록 보장해요. 컨트롤러 참조 일치는 같은 컴포지트 리소스(XR)가 컴포즈하는 리소스를 일치시키는 데 유용해요. (Composite Resources에 대한 자세한 내용은 Composite Resources 섹션을 참고하세요.)

컨트롤러 참조만 일치하면 라벨이나 추가 정보 없이 일치 과정이 단순해져요. 예를 들어 AWS InternetGateway를 만들려면 VPC가 필요해요. InternetGateway는 라벨을 일치시킬 수 있지만, 이 Composition이 만든 모든 VPC는 같은 라벨을 공유해요. matchControllerRef를 사용하면 InternetGateway를 만든 것과 같은 컴포지트 리소스에서 만든 VPC만 일치해요.

불변 필드 (Immutable fields)

일부 Provider는 생성 후 일부 관리 리소스의 필드 변경을 지원하지 않아요. 예를 들어 Amazon AWS RDS Instance의 region은 변경할 수 없어요. 이 필드는 불변 필드예요. Amazon은 리소스를 삭제하고 다시 만들 것을 요구해요.

Crossplane은 관리 리소스의 불변 필드를 편집할 수 있게 허용하지만, 그 변경을 적용하지 않아요. Crossplane은 forProvider 변경을 기반으로 리소스를 삭제하지 않아요.

Crossplane은 Terraform 같은 다른 도구와 다르게 동작해요. Terraform은 불변 필드를 변경하기 위해 리소스를 삭제하고 다시 만들어요. Crossplane은 Kubernetes에서 해당 관리 리소스 객체를 삭제해야만 외부 리소스를 삭제해요.

후기 초기화 (Late initialization)

Crossplane은 기본적으로 관리 리소스를 진실의 원천으로 취급해요. spec.forProvider 아래에 선택적 값을 포함한 모든 값을 가질 것으로 기대해요. 제공되지 않으면 Crossplane은 Provider가 할당한 값으로 빈 필드를 채워요. 예를 들어 region과 availabilityZone 같은 필드를 생각해보세요. region만 지정하고 클라우드 제공자가 가용 영역을 고르게 할 수 있어요. 이 경우 Provider가 가용 영역을 할당하면 Crossplane은 그 값을 spec.forProvider.availabilityZone 필드를 채우는 데 사용해요.

managementPolicies로 이 동작을 끌 수 있어요. managementPolicies 목록에 LateInitialize 정책을 포함하지 않으면 돼요.

initProvider

관리 리소스 initProvider 옵션은 managementPolicies와 관련된 베타 기능이에요.

initProvider는 Crossplane이 새 관리 리소스를 만들 때만 적용하는 설정을 정의해요. Crossplane은 생성 후 변경되는 initProvider 필드에 정의된 설정을 무시해요.

forProvider의 설정은 Crossplane이 항상 강제해요. Crossplane은 외부 리소스의 forProvider 필드 모든 변경을 되돌려요. initProvider의 설정은 Crossplane이 강제하지 않아요. Crossplane은 외부 리소스의 initProvider 필드 변경을 무시해요.

initProvider는 Provider가 자동으로 변경할 수 있는 초기 값(오토 스케일링 그룹 등)을 설정하는 데 유용해요. 예를 들어 초기 desiredSize로 NodeGroup을 만드는 경우가 있어요. 오토스케일러가 Node Group 외부 리소스를 확장하더라도 Crossplane은 desiredSize 설정을 되돌리지 않아요.

Crossplane은 initProvider 설정과 충돌을 피하려고 LateInitialize 없이 managementPolicies를 구성할 것을 권장해요.

apiVersion: eks.aws.m.upbound.io/v1beta1
kind: NodeGroup
metadata:
  namespace: default
  name: sample-eks-ng
spec:
  managementPolicies: ["Observe", "Create", "Update", "Delete"]
  initProvider:
    scalingConfig:
      desiredSize: 1
  forProvider:
    region: us-west-1
    clusterName: my-cluster
    scalingConfig:
      maxSize: 4
      minSize: 1

managementPolicies

관리 리소스 managementPolicies 옵션은 베타 기능이에요. Crossplane은 베타 기능을 기본적으로 활성화해요. Provider가 management policies 지원 여부를 결정해요. Provider가 management policies를 지원하는지는 Provider 문서를 참고하세요.

Crossplane managementPolicies는 관리 리소스와 그에 대응하는 외부 리소스에 Crossplane이 취할 수 있는 동작을 결정해요. 관리 리소스에 하나 이상의 managementPolicies를 적용해 Crossplane이 리소스에 대해 갖는 권한을 결정해요.

예를 들어 Crossplane에게 외부 리소스를 만들고 삭제할 권한을 주되 변경은 못하게 하려면 정책을 ["Create", "Delete", "Observe"]로 설정해요.

apiVersion: ec2.aws.m.upbound.io/v1beta1
kind: Subnet
spec:
  managementPolicies: ["Create", "Delete", "Observe"]
  forProvider:
    # Removed for brevity

기본 정책은 Crossplane에게 리소스에 대한 완전한 제어권을 부여해요. managementPolicies 필드를 빈 배열로 정의하면 리소스가 일시 중지돼요.

Provider가 management policies 지원 여부를 결정해요. Provider가 지원하는지는 Provider 문서를 참고하세요.

Crossplane은 다음 정책을 지원해요.

다음은 일반적인 정책 조합 목록이에요.

| Create | Delete | LateInitialize | Observe | Update | Description | | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | 기본 정책. Crossplane이 리소스에 대한 완전한 제어권을 가짐 | | ✔️ | ✔️ | ✔️ | ✔️ | | 생성 후 관리 리소스의 변경이 외부 리소스에 전달되지 않음. 불변 외부 리소스에 유용 | | ✔️ | ✔️ | | ✔️ | ✔️ | Crossplane이 관리 리소스에 정의되지 않은 설정을 관리하지 못하게 함. 외부 리소스의 불변 필드에 유용 | | ✔️ | ✔️ | | ✔️ | | Crossplane이 외부 리소스에서 설정을 가져오지 않고 관리 리소스로 변경도 푸시하지 않음. 외부 리소스가 삭제되면 Crossplane이 다시 생성 | | ✔️ | | ✔️ | ✔️ | ✔️ | 관리 리소스 삭제 시 Crossplane이 외부 리소스를 삭제하지 않음 | | ✔️ | | ✔️ | ✔️ | | 관리 리소스 삭제 시 Crossplane이 외부 리소스를 삭제하지 않음. 생성 후 외부 리소스에 변경을 적용하지 않음 | | ✔️ | | | ✔️ | ✔️ | 관리 리소스 삭제 시 Crossplane이 외부 리소스를 삭제하지 않음. 외부 리소스에서 설정을 가져오지 않음 | | ✔️ | | | ✔️ | | Crossplane이 외부 리소스를 생성하지만 외부 리소스나 관리 리소스에 변경을 적용하지 않음. Crossplane은 리소스를 삭제할 수 없음 | | | | | ✔️ | | Crossplane이 리소스를 관찰만 함 | | | | | | | 정책 없음. 리소스를 일시 중지하는 대체 방법 |

providerConfigRef

관리 리소스의 providerConfigRef는 관리 리소스를 만들 때 사용할 ProviderConfig를 Provider에게 알려줘요. ProviderConfig를 사용해 Provider와 통신할 때 사용할 인증 방법을 정의해요.

providerConfigRef가 적용되지 않으면 Provider는 default라는 ProviderConfig를 사용해요.

예를 들어 관리 리소스가 user-keys라는 ProviderConfig를 참조해요. 이는 ProviderConfig의 name과 일치해요.

apiVersion: ec2.aws.m.upbound.io/v1beta1
kind: Instance
metadata:
  namespace: default
  name: my-instance
spec:
  forProvider:
    # Removed for brevity
  providerConfigRef:
    name: user-keys
    kind: ProviderConfig

apiVersion: aws.m.upbound.io/v1beta1
kind: ProviderConfig
metadata:
  namespace: default
  name: user-keys
# Removed for brevity

각 관리 리소스는 서로 다른 ProviderConfig를 참조할 수 있어요. 이를 통해 서로 다른 관리 리소스가 같은 Provider에 서로 다른 자격 증명으로 인증할 수 있어요.

ProviderConfig 타입 (ProviderConfig types)

AWS Provider는 두 가지 ProviderConfig 리소스 타입을 지원해요.

ProviderConfig (네임스페이스 스코프):

# ProviderConfig - only applies to MRs in same namespace
apiVersion: aws.m.upbound.io/v1beta1
kind: ProviderConfig
metadata:
  namespace: default
  name: my-config

ClusterProviderConfig (클러스터 전역):

# ClusterProviderConfig - applies to MRs across all namespaces  
apiVersion: aws.m.upbound.io/v1beta1
kind: ClusterProviderConfig
metadata:
  name: my-cluster-config

ProviderConfig를 참조할 때 관리 리소스는 name과 kind를 모두 지정해야 해요.

spec:
  providerConfigRef:
    name: my-cluster-config
    kind: ClusterProviderConfig

spec:
  providerConfigRef:
    name: my-config
    kind: ProviderConfig  # References namespaced ProviderConfig

providerConfigRef를 완전히 생략하면 다음으로 기본 설정돼요.

spec:
  providerConfigRef:
    name: default
    kind: ClusterProviderConfig

writeConnectionSecretToRef

Provider가 관리 리소스를 만들 때 사용자 이름, 비밀번호, IP 주소 같은 연결 세부 정보 같은 리소스별 상세 정보를 생성할 수 있어요. Crossplane은 이 세부 정보를 writeConnectionSecretToRef 값이 지정하는 Kubernetes Secret 객체에 저장해요.

예를 들어 Crossplane AWS Provider로 AWS RDS 데이터베이스 인스턴스를 만들면 endpoint, password, port, username 데이터를 생성해요. Provider는 이 변수들을 writeConnectionSecretToRef 필드가 참조하는 Kubernetes 시크릿 rds-secret에 저장해요.

apiVersion: rds.aws.m.upbound.io/v1beta1
kind: Instance
metadata:
  namespace: default
  name: my-rds-instance
spec:
  forProvider:
  # Removed for brevity
  writeConnectionSecretToRef:
    name: rds-secret

Secret 객체를 보면 저장된 필드를 확인할 수 있어요.

kubectl describe secret rds-secret
Name:         rds-secret
# Removed for brevity
Data
====
port:      4 bytes
username:  10 bytes
endpoint:  54 bytes
password:  27 bytes

Secret 객체에 쓰이는 데이터를 Provider가 결정해요. 생성된 Secret 데이터는 특정 Provider 문서를 참고하세요. ManagedResourceDefinitions는 관리 리소스가 제공하는 연결 상세를 문서화할 수 있지만, 대부분의 Provider는 아직 이 정보를 채우지 않아요.

어노테이션 (Annotations)

Crossplane은 관리 리소스에 표준 Kubernetes annotations 집합을 적용해요.

외부 리소스 이름 지정 (Naming external resources)

기본적으로 Provider는 외부 리소스에 Kubernetes 객체와 같은 이름을 부여해요. 예를 들어 my-rds-instance라는 관리 리소스는 Provider 환경 안의 외부 리소스로 my-rds-instance 이름을 가져요.

apiVersion: rds.aws.m.upbound.io/v1beta1
kind: Instance
metadata:
  namespace: default
  name: my-rds-instance

kubectl get instance
NAME                 READY   SYNCED   EXTERNAL-NAME        AGE
my-rds-instance      True    True     my-rds-instance      11m

이미 제공된 crossplane.io/external-name 어노테이션으로 만든 관리 리소스는 그 어노테이션 값을 외부 리소스 이름으로 사용해요. 예를 들어 Provider는 my-rds-instance라는 관리 리소스를 만들지만 AWS 안의 외부 리소스 이름은 my-custom-name을 사용해요.

apiVersion: rds.aws.m.upbound.io/v1beta1
kind: Instance
metadata:
  namespace: default
  name: my-rds-instance  
  annotations: 
    crossplane.io/external-name: my-custom-name

kubectl get instance
NAME                 READY   SYNCED   EXTERNAL-NAME        AGE
my-rds-instance      True    True     my-custom-name       11m

생성 어노테이션 (Creation annotations)

AWS 같은 외부 시스템이 비결정적(nondeterministic) 리소스 이름을 생성하면 Provider가 리소스를 만들었지만 그것을 기록하지 못할 수 있어요. 이 경우 Provider는 리소스를 관리할 수 없어요.

Crossplane은 Provider가 만들지만 관리하지 않는 리소스를 **leaked resources(누출된 리소스)**라고 불러요. Provider는 누출된 리소스를 피하고 감지하기 위해 세 가지 생성 어노테이션을 설정해요.

crossplane.io/external-create-pending — Provider가 리소스를 만들려던 마지막 시각
crossplane.io/external-create-succeeded — Provider가 리소스를 성공적으로 만든 마지막 시각
crossplane.io/external-create-failed — Provider가 리소스 생성에 실패한 마지막 시각

kubectl get로 관리 리소스의 어노테이션을 볼 수 있어요. 예를 들어 AWS VPC 리소스:

$ kubectl get -o yaml vpc my-vpc
apiVersion: ec2.aws.m.upbound.io/v1beta1
kind: VPC
metadata:
  namespace: default
  name: my-vpc
  annotations:
    crossplane.io/external-name: vpc-1234567890abcdef0
    crossplane.io/external-create-pending: "2023-12-18T21:48:06Z"
    crossplane.io/external-create-succeeded: "2023-12-18T21:48:40Z"

Provider는 crossplane.io/external-name 어노테이션을 사용해 외부 시스템에서 관리 리소스를 조회해요. Provider는 외부 시스템에서 리소스를 조회해 존재하는지, 관리 리소스의 원하는 상태와 일치하는지 확인해요. 리소스를 찾지 못하면 생성해요.

일부 외부 시스템은 Provider가 리소스를 만들 때 이름을 지정하게 하지 않아요. 대신 외부 시스템이 비결정적 이름을 생성하고 Provider에 반환해요. 외부 시스템이 리소스 이름을 생성하면 Provider는 그것을 관리 리소스의 crossplane.io/external-name 어노테이션에 저장하려 해요. 저장하지 못하면 리소스를 누출해요.

Provider는 어노테이션 저장을 보장할 수 없어요. Provider는 리소스 생성과 어노테이션 저장 사이에 재시작하거나 네트워크 연결을 잃을 수 있어요.

Provider는 리소스를 누출했을 수 있음을 감지할 수 있어요. Provider가 리소스를 누출했을 수 있다고 생각하면, 안전하게 진행해도 된다고 사용자에게 알릴 때까지 그것의 리컨사일을 중지해요.

외부 시스템이 리소스 이름을 생성할 때마다 Provider가 리소스를 누출할 위험이 있어요. Provider가 리소스를 누출했을 수 있음을 감지했을 때 가장 안전한 행동은 중지하고 인간의 개입을 기다리는 것이에요. 이는 Provider가 누출된 리소스의 복제본을 만들지 않도록 보장해요. 중복 리소스는 비용이 들고 위험할 수 있어요.

Provider가 리소스를 누출했을 수 있다고 생각하면 관리 리소스와 연관된 cannot determine creation result 이벤트를 만들어요. kubectl describe로 그 이벤트를 확인해요.

kubectl describe queue my-sqs-queue

# Removed for brevity

Events:
  Type     Reason                           Age                 From                                 Message
  ----     ------                           ----                ----                                 -------
  Warning  CannotInitializeManagedResource  29m (x19 over 19h)  managed/queue.sqs.aws.m.crossplane.io  cannot determine creation result - remove the crossplane.io/external-create-pending annotation if it is safe to proceed

Provider는 생성 어노테이션을 사용해 리소스를 누출했을 수 있음을 감지해요. Provider가 관리 리소스를 리컨사일할 때마다 리소스의 생성 어노테이션을 확인해요. Provider가 create pending 시각이 가장 최근의 create succeeded 또는 create failed 시각보다 더 최근임을 보면, 리소스를 누출했을 수 있음을 알아요.

Provider는 생성 어노테이션을 제거하지 않아요. 그들은 타임스탬프를 사용해 어느 것이 가장 최근인지 결정해요. 관리 리소스에 여러 생성 어노테이션이 있는 것은 정상이에요.

Provider가 리소스를 누출했을 수 있음을 아는 이유는 모든 리소스의 어노테이션을 동시에 업데이트하기 때문이에요. Provider가 리소스를 생성한 후 생성 어노테이션을 업데이트할 수 없었다면 crossplane.io/external-name 어노테이션도 업데이트할 수 없었던 것이에요.

cannot determine creation result 오류가 있는 리소스는 외부 시스템을 조사해보세요. crossplane.io/external-create-pending 어노테이션의 타임스탬프를 사용해 Provider가 리소스를 누출했을 수 있는 시점을 결정해요. 이 시점에 생성된 리소스를 찾아보세요. 누출된 리소스를 찾았고 안전하다면 외부 시스템에서 삭제해요.

누출된 리소스가 없다고 확신한 뒤 관리 리소스에서 crossplane.io/external-create-pending 어노테이션을 제거해요. 이는 Provider에게 리컨사일을 재개하고 관리 리소스를 다시 만들라고 알려줘요.

Provider는 생성 어노테이션을 사용해 리소스 누출을 피하기도 해요. Provider가 crossplane.io/external-create-pending 어노테이션을 쓸 때 자신이 관리 리소스의 최신 버전을 리컨사일하고 있음을 알아요. Provider가 관리 리소스의 오래된 버전을 리컨사일하고 있었다면 그 쓰기는 실패했을 거예요.

Provider가 오래된 crossplane.io/external-name 어노테이션이 있는 오래된 버전을 리컨사일했다면 리소스가 존재하지 않는다고 잘못 판단할 수 있어요. Provider는 새 리소스를 만들고 기존 것을 누출했을 거예요.

일부 외부 시스템은 Provider가 리소스를 만든 시점과 시스템이 존재를 보고하는 시점 사이에 지연이 있어요. Provider는 가장 최근의 create succeeded 시각을 사용해 이 지연을 고려해요. Provider가 지연을 고려하지 않았다면 리소스가 존재하지 않는다고 잘못 판단해 새 리소스를 만들고 기존 것을 누출했을 거예요.

일시 중지 (Paused)

crossplane.io/paused 어노테이션을 수동으로 적용하면 Provider가 관리 리소스의 리컨사일을 중지해요. 리소스 일시 중지는 Provider를 수정하거나 Kubernetes 객체를 편집할 때 경쟁 조건(race-condition)을 방지할 때 유용해요.

관리 리소스에 crossplane.io/paused: "true" 어노테이션을 적용해 리컨사일을 일시 중지해요.

값 "true"만 리컨사일을 일시 중지해요.

apiVersion: ec2.aws.m.upbound.io/v1beta1
kind: Instance
metadata:
  namespace: default
  name: my-rds-instance
  annotations:
    crossplane.io/paused: "true"
spec:
  forProvider:
    region: us-west-1
    instanceType: t2.micro

어노테이션을 제거해 리컨사일을 재개해요.

Kubernetes와 Crossplane은 paused 어노테이션이 있는 리소스를 kubectl delete로도 삭제할 수 없어요. 자세한 내용은 Crossplane discussion #4839를 읽어보세요.

Poll 간격 (Poll interval)

crossplane.io/poll-interval 어노테이션은 특정 관리 리소스의 기본 --poll-interval을 재정의해요. 일부 리소스는 잦은 드리프트 감지가 필요하고 다른 리소스는 안정적이어서 잦은 API 호출이 필요 없을 때 이 어노테이션을 사용해요.

이 어노테이션은 30m, 1h, 24h 같은 유효한 Go duration 문자열을 허용해요.

apiVersion: rds.aws.m.upbound.io/v1beta1
kind: Instance
metadata:
  namespace: default
  name: my-rds-instance
  annotations:
    crossplane.io/poll-interval: "24h"
spec:
  forProvider:
    region: us-west-1
    instanceType: t2.micro

Crossplane은 유효하지 않은 Go duration 값을 무시하고 컨트롤러 기본값으로 되돌려요. 컨트롤러는 --min-poll-interval 플래그(기본값 1s)보다 낮은 값을 구성된 최소값으로 올려요.

어노테이션을 제거해 기본 --poll-interval로 되돌아가요.

리컨사일 요청 (Reconcile request)

crossplane.io/reconcile-requested-at 어노테이션은 값이 변경될 때 즉시 리컨사일을 촉발해요. 이는 Flux CD의 reconcile.fluxcd.io/requestedAt이 만든 패턴을 따르는 것이에요.

타임스탬프나 고유 식별자 같은 어떤 값이든 어노테이션을 설정해 리컨사일을 촉발해요.

apiVersion: rds.aws.m.upbound.io/v1beta1
kind: Instance
metadata:
  namespace: default
  name: my-rds-instance
  annotations:
    crossplane.io/reconcile-requested-at: "2024-01-15T10:30:00Z"
spec:
  forProvider:
    region: us-west-1
    instanceType: t2.micro

리컨사일러는 처리된 토큰을 status.lastHandledReconcileAt에 기록해 운영자가 컨트롤러가 요청을 처리했는지 확인할 수 있게 해줘요.

# Request reconciliation
kubectl annotate instance my-rds-instance \
  crossplane.io/reconcile-requested-at="$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
  --overwrite

# Verify it was handled
kubectl get instance my-rds-instance \
  -o jsonpath='{.status.lastHandledReconcileAt}'

어노테이션 값이 마지막 처리 값과 일치하면 리컨사일이 다시 촉발되지 않아요.

Finalizers

Crossplane은 관리 리소스의 삭제를 제어하기 위해 관리 리소스에 Finalizer를 적용해요. (Kubernetes는 Finalizer가 있는 객체는 삭제할 수 없어요.)

Crossplane이 관리 리소스를 삭제하면 Provider가 외부 리소스 삭제를 시작하지만, 외부 리소스가 완전히 삭제될 때까지 관리 리소스는 남아 있어요. 외부 리소스가 완전히 삭제되면 Crossplane이 Finalizer를 제거하고 관리 리소스 객체를 삭제해요.

조건 (Conditions)

Crossplane은 관리 리소스에 표준 Conditions 집합을 가져요. kubectl describe로 관리 리소스의 Conditions를 확인해요. (Provider는 자체 커스텀 Conditions를 정의할 수도 있어요.)

Available

Reason: Available은 Provider가 관리 리소스를 만들었고 사용 준비가 됐음을 나타내요.

Conditions:
  Type:                  Ready
  Status:                True
  Reason:                Available

Creating

Reason: Creating은 Provider가 관리 리소스를 만들려 시도 중임을 나타내요.

Conditions:
  Type:                  Ready
  Status:                False
  Reason:                Creating

Deleting

Reason: Deleting은 Provider가 관리 리소스를 삭제하려 시도 중임을 나타내요.

Conditions:
  Type:                  Ready
  Status:                False
  Reason:                Deleting

ReconcilePaused

Reason: ReconcilePaused은 관리 리소스에 Pause 어노테이션이 있음을 나타내요.

Conditions:
  Type:                  Synced
  Status:                False
  Reason:                ReconcilePaused

ReconcileError

Reason: ReconcileError는 Crossplane이 관리 리소스를 리컨사일하는 동안 오류를 만났음을 나타내요. Condition의 Message: 값이 Crossplane 오류를 식별하는 데 도움을 줘요.

Conditions:
  Type:                  Synced
  Status:                False
  Reason:                ReconcileError

ReconcileSuccess

Reason: ReconcileSuccess는 Provider가 관리 리소스를 만들고 모니터링하고 있음을 나타내요.

Conditions:
  Type:                  Synced
  Status:                True
  Reason:                ReconcileSuccess

Unavailable

Reason: Unavailable은 Crossplane이 관리 리소스가 사용 가능할 것으로 예상하지만 Provider가 리소스가 비정상이라고 보고함을 나타내요.

Conditions:
  Type:                  Ready
  Status:                False
  Reason:                Unavailable

Unknown

Reason: Unknown은 Provider가 관리 리소스에 예상치 못한 오류가 있음을 나타내요. conditions.message가 무슨 일이 잘못됐는지 더 많은 정보를 제공해요.

Conditions:
  Type:                  Unknown
  Status:                False
  Reason:                Unknown

Upjet Provider 조건 (Upjet Provider conditions)

Upjet(Crossplane Provider를 생성하는 오픈소스 도구)도 표준 Conditions 집합을 가져요.

AsyncOperation

일부 리소스는 만드는 데 1분 이상 걸릴 수 있어요. Upjet 기반 Provider는 비동기 작업을 사용해 관리 리소스를 만들기 전에 Kubernetes 명령을 완료할 수 있어요.

Finished — Reason: Finished는 비동기 작업이 성공적으로 완료됐음을 나타내요.

Conditions:
  Type:                  AsyncOperation
  Status:                True
  Reason:                Finished

Ongoing — Reason: Ongoing은 관리 리소스 작업이 여전히 진행 중임을 나타내요.

Conditions:
  Type:                  AsyncOperation
  Status:                True
  Reason:                Ongoing

LastAsyncOperation

Upjet Type: LastAsyncOperation은 이전 비동기 작업 상태를 Success 또는 실패 Reason으로 포착해요.

ApplyFailure — Reason: ApplyFailure는 Provider가 관리 리소스에 설정을 적용하지 못했음을 나타내요. conditions.message가 무슨 일이 잘못됐는지 더 많은 정보를 제공해요.

Conditions:
  Type:                  LastAsyncOperation
  Status:                False
  Reason:                ApplyFailure

DestroyFailure — Reason: DestroyFailure는 Provider가 관리 리소스를 삭제하지 못했음을 나타내요. conditions.message가 무슨 일이 잘못됐는지 더 많은 정보를 제공해요.

Conditions:
  Type:                  LastAsyncOperation
  Status:                False
  Reason:                DestroyFailure

Success — Reason: Success는 Provider가 관리 리소스를 비동기적으로 성공적으로 만들었음을 나타내요.

Conditions:
  Type:                  LastAsyncOperation
  Status:                True
  Reason:                Success