Providers
Providers (Packages)
Provider는 Crossplane이 외부 서비스에서 인프라를 프로비저닝할 수 있게 해줘요. Provider는 새로운 Kubernetes API를 만들고 그것을 외부 API에 매핑해요.
Provider는 비-Kubernetes 리소스에 연결하는 모든 측면을 담당해요. 여기에는 인증, 외부 API 호출, 외부 리소스에 대한 Kubernetes 컨트롤러 로직 제공이 포함돼요.
출처: 문서
본문
Provider의 예는 다음과 같아요.
- Provider AWS
- Provider Azure
- Provider GCP
- Provider Kubernetes
Provider는 만들 수 있는 모든 외부 리소스를 Kubernetes API 엔드포인트로 정의해요. 이 엔드포인트들이 Managed Resources예요.
Provider 설치 (Install a provider)
Provider를 설치하면 Provider의 API를 나타내는 새 Kubernetes 리소스가 생성돼요. Provider 설치 시 Provider의 API를 Kubernetes 클러스터로 리컨사일하는 Provider 파드도 만들어져요. Provider는 원하는 관리 리소스의 상태를 지속적으로 감시하고 부족한 외부 리소스를 만들어요.
Provider는 Crossplane Provider 객체로 설치하며, spec.package 값을 Provider 패키지의 위치로 설정해요. 예를 들어 AWS Provider를 설치하려면 다음과 같이 해요.
apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
name: crossplane-contrib-provider-aws-s3-s3
spec:
package: xpkg.crossplane.io/crossplane-contrib/provider-aws-s3:v2.0.0
기본적으로 Provider 파드는 Crossplane과 같은 네임스페이스(crossplane-system)에 설치돼요.
Providers는
pkg.crossplane.io그룹의 일부예요.meta.pkg.crossplane.io그룹은 Provider 패키지를 만드는 데 쓰여요. Provider 구축 지침은 이 문서의 범위 밖이에요. 자세한 내용은 Crossplane contributing Provider Development Guide를 읽어보세요. Provider 패키지 명세는 Crossplane Provider Package specification을 참고하세요.
apiVersion: meta.pkg.crossplane.io/v1
kind: Provider
metadata:
name: crossplane-contrib-provider-aws-s3
spec:
# Removed for brevity
Helm으로 설치 (Install with Helm)
Crossplane은 Crossplane Helm 차트로 초기 Crossplane 설치 중 Provider 설치를 지원해요. helm install에 --set provider.packages 인자를 사용해요. 예를 들어 AWS S3 Provider를 설치하려면:
helm install crossplane \
crossplane-stable/crossplane \
--namespace crossplane-system \
--create-namespace \
--set provider.packages='{xpkg.crossplane.io/crossplane-contrib/provider-aws-s3:v2.0.0}'
오프라인 설치 (Install offline)
Crossplane Providers를 오프라인으로 설치하려면 Provider 패키지를 호스팅할 Harbor 같은 로컬 컨테이너 레지스트리가 필요해요. Crossplane은 컨테이너 레지스트리에서만 Provider 패키지 설치를 지원해요. Crossplane은 Kubernetes 볼륨에서 직접 Provider 패키지 설치를 지원하지 않아요.
설치 옵션 (Installation options)
Provider는 설치 관련 설정을 바꾸는 여러 구성 옵션을 지원해요.
Crossplane은 결정적이고 반복 가능한 설치를 위해 태그 대신 이미지 다이제스트로 설치를 지원해요.
apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
name: crossplane-contrib-provider-aws-s3
spec:
package: xpkg.crossplane.io/crossplane-contrib/provider-aws-s3@sha256:ee6bece46dbb54cc3f0233961f5baac317fa4e4a81b41198bdc72fc472d113d0
Provider pull 정책 (Provider pull policy)
packagePullPolicy를 사용해 Crossplane이 Provider 패키지를 로컬 Crossplane 패키지 캐시로 다운로드해야 하는 시점을 정의해요.
packagePullPolicy 옵션:
IfNotPresent(기본값) — 캐시에 없을 때만 패키지 다운로드Always— 매분 새 패키지 확인, 캐시에 없는 일치 패키지 다운로드Never— 패키지를 절대 다운로드하지 않음. 로컬 패키지 캐시에서만 패키지 설치
Crossplane packagePullPolicy는 Kubernetes 컨테이너 이미지 pull 정책처럼 동작해요. Crossplane은 Kubernetes 이미지처럼 태그와 패키지 다이제스트 해시 사용을 지원해요.
예를 들어 주어진 Provider 패키지를 Always 다운로드하려면 packagePullPolicy: Always 구성을 사용해요.
apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
name: crossplane-contrib-provider-aws-s3
spec:
packagePullPolicy: Always
# Removed for brevity
리비전 활성화 정책 (Revision activation policy)
Active 패키지 리비전은 리소스를 적극적으로 리컨사일하는 패키지 컨트롤러예요. 기본적으로 Crossplane은 가장 최근에 설치된 패키지 리비전을 Active로 설정해요.
revisionActivationPolicy로 Provider 업그레이드 동작을 제어해요.
revisionActivationPolicy 옵션:
Automatic(기본값) — 마지막으로 설치된 Provider를 자동으로 활성화Manual— Provider를 자동으로 활성화하지 않음
예를 들어 수동 업그레이드를 요구하도록 업그레이드 동작을 변경하려면 revisionActivationPolicy: Manual을 설정해요.
apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
name: crossplane-contrib-provider-aws-s3
spec:
revisionActivationPolicy: Manual
# Removed for brevity
패키지 리비전 이력 제한 (Package revision history limit)
Crossplane이 같은 Provider 패키지의 다른 버전을 설치하면 새 리비전을 만들어요. 기본적으로 Crossplane은 비활성 리비전 하나를 유지해요. (Provider upgrade 섹션에서 패키지 리비전 사용에 대한 더 많은 정보를 읽어보세요.)
Provider Package revisionHistoryLimit로 Crossplane이 유지하는 리비전 수를 변경해요. revisionHistoryLimit 필드는 정수예요. 기본값은 1이에요. revisionHistoryLimit을 0으로 설정하면 리비전 저장을 비활성화해요.
예를 들어 기본 설정을 바꿔 10개 리비전을 저장하려면 revisionHistoryLimit: 10을 사용해요.
apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
name: crossplane-contrib-provider-aws-s3
spec:
revisionHistoryLimit: 10
# Removed for brevity
프라이빗 레지스트리에서 Provider 설치 (Install a provider from a private registry)
Kubernetes가 imagePullSecrets로 프라이빗 레지스트리에서 이미지를 설치하는 것처럼, Crossplane은 packagePullSecrets로 프라이빗 레지스트리에서 Provider 패키지를 설치해요. packagePullSecrets를 사용해 Provider 패키지 다운로드 시 인증에 사용할 Kubernetes 시크릿을 제공해요.
Kubernetes 시크릿은 Crossplane과 같은 네임스페이스에 있어야 해요.
packagePullSecrets는 시크릿 목록이에요. 예를 들어 example-secret이라는 시크릿을 사용하려면 packagePullSecrets를 구성해요.
apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
name: crossplane-contrib-provider-aws-s3
spec:
packagePullSecrets:
- name: example-secret
# Removed for brevity
구성된
packagePullSecrets는 Provider 패키지 의존성에 전달되지 않아요.
의존성 무시 (Ignore dependencies)
기본적으로 Crossplane은 Provider 패키지에 나열된 모든 의존성을 설치해요. Crossplane은 skipDependencyResolution으로 Provider 패키지의 의존성을 무시할 수 있어요. 예를 들어 의존성 해석을 비활성화하려면 skipDependencyResolution: true를 구성해요.
apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
name: crossplane-contrib-provider-aws-s3
spec:
skipDependencyResolution: true
# Removed for brevity
의존성 버전 자동 업데이트 (Automatically update dependency versions)
Crossplane은 패키지의 의존성 버전을 모든 제약을 만족하는 최소 유효 버전으로 자동 업그레이드할 수 있어요. 이는 알파 기능이며 --enable-dependency-version-upgrades 플래그로 활성화해야 해요.
때로 Crossplane은 설치를 진행하기 위해 의존성 버전 다운그레이드가 필요해요. >=v0.0.0 제약으로 패키지 X에 의존하는 구성 A가 컨트롤 플레인에 설치된다고 해볼게요. 이 경우 패키지 매니저는 패키지 X의 최신 버전(예: v3.0.0)을 설치해요. 나중에 패키지 X에 다른 제약으로 의존하는 구성 B를 설치하기로 결정했다고 해요. 자동 의존성 버전 다운그레이드를 위해 packageManager.enableAutomaticDependencyDowngrade=true라는 Helm 값으로 구성 옵션이 있어요.
패키지 다운그레이드는 예상치 못한 동작을 유발할 수 있으므로 Crossplane은 기본적으로 이 옵션을 비활성화해요. 이 옵션을 활성화하면 패키지 매니저가 패키지의 의존성 버전을 제약을 만족하는 최대 유효 버전으로 자동 다운그레이드해요.
이 구성은
--enable-dependency-version-upgrades플래그가 필요해요. 자세한 내용은 Crossplane Install 섹션의 configuration options와 feature flags를 참고하세요.
자동 의존성 다운그레이드를 활성화하면 예상치 못한 결과가 있을 수 있어요:
- 다운그레이드된 버전에 CRD가 없어, 그것을 리컨사일할 컨트롤러 없는 고아 MR이 남을 수 있음
- 다운그레이드된 CRD 버전이 이전에 설정한 필드를 누락하면 데이터 손실
- CRD 저장 버전 변경으로 패키지 버전 업데이트가 막힐 수 있음
Crossplane 버전 요구사항 무시 (Ignore Crossplane version requirements)
Provider 패키지는 설치 전 특정 또는 최소 Crossplane 버전을 요구할 수 있어요. 기본적으로 Crossplane 버전이 요구 버전을 충족하지 않으면 Crossplane은 Provider를 설치하지 않아요.
Crossplane은 ignoreCrossplaneConstraints로 요구 버전을 무시할 수 있어요. 예를 들어 지원되지 않는 Crossplane 버전에 Provider 패키지를 설치하려면 ignoreCrossplaneConstraints: true를 구성해요.
apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
name: crossplane-contrib-provider-aws-s3
spec:
ignoreCrossplaneConstraints: true
# Removed for brevity
의존성 관리 (Manage dependencies)
Provider 패키지는 Configurations나 다른 Providers를 포함한 다른 패키지에 대한 의존성을 포함할 수 있어요. Crossplane이 Provider 패키지의 의존성을 충족하지 못하면 Provider는 HEALTHY를 False로 보고해요.
예를 들어 이 Getting Started Configuration 설치의 HEALTHY가 False예요.
kubectl get providers
NAME INSTALLED HEALTHY PACKAGE AGE
crossplane-contrib-provider-aws-s3 True False xpkg.crossplane.io/crossplane-contrib/provider-aws-s3:v2.0.0 12s
Provider가 왜 HEALTHY가 아닌지 더 자세히 보려면 kubectl describe providerrevisions를 사용해요.
kubectl describe providerrevisions
Name: provider-aws-s3-92206523fff4
API Version: pkg.crossplane.io/v1
Kind: ProviderRevision
Spec:
Desired State: Active
Image: xpkg.crossplane.io/crossplane-contrib/provider-aws-s3:v2.0.0
Revision: 1
Status:
Conditions:
Last Transition Time: 2023-10-10T21:06:39Z
Reason: UnhealthyPackageRevision
Status: False
Type: Healthy
Controller Ref:
Name:
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning LintPackage 41s (x3 over 47s) packages/providerrevision.pkg.crossplane.io incompatible Crossplane version: package isn't compatible with Crossplane version (v1.10.0)
Events는 현재 Crossplane 버전이 Configuration 패키지 요구사항을 충족하지 못한다는 메시지의 Warning을 보여줘요.
Provider 업그레이드 (Upgrade a provider)
기존 Provider를 업그레이드하려면 새 Provider 매니페스트를 적용하거나 kubectl edit providers로 설치된 Provider Package를 편집해요. Provider의 spec.package에서 버전 번호를 업데이트하고 변경을 적용해요. Crossplane은 새 이미지를 설치하고 새 ProviderRevision을 만들어요.
ProviderRevision은 Crossplane이 결정한 후까지 사용되지 않는 Provider CRD를 제거하지 않고 저장할 수 있게 해줘요.
kubectl get providerrevisions로 ProviderRevisions를 확인해요.
kubectl get providerrevisions
NAME HEALTHY REVISION IMAGE STATE DEP-FOUND DEP-INSTALLED AGE
provider-aws-s3-dbc7f981d81f True 1 xpkg.crossplane.io/crossplane-contrib/provider-aws-s3:v2.0.0 Active 1 1 10d
provider-nop-552a394a8acc True 2 xpkg.crossplane.io/crossplane-contrib/provider-nop:v0.3.0 Active 11d
provider-nop-7e62d2a1a709 True 1 xpkg.crossplane.io/crossplane-contrib/provider-nop:v0.2.0 Inactive 13d
crossplane-contrib-provider-family-aws-710d8cfe9f53 True 1 xpkg.crossplane.io/crossplane-contrib/provider-family-aws:v2.0.0 Active 10d
기본적으로 Crossplane은 단일 Inactive Provider를 유지해요. 기본값을 변경하려면 revision history limit 섹션을 읽어보세요. Provider의 리비전은 한 번에 하나만 Active예요.
Provider 제거 (Remove a provider)
kubectl delete provider로 Provider 객체를 삭제해 Provider를 제거해요.
Provider의 관리 리소스를 먼저 제거하지 않고 Provider를 제거하면 리소스가 버려질(abandoned) 수 있어요. 외부 리소스는 삭제되지 않아요. Provider를 먼저 제거하면 클라우드 제공자를 통해 외부 리소스를 수동으로 삭제해야 해요. 관리 리소스는 finalizer를 제거해 수동으로 삭제해야 해요.
버려진 리소스 삭제에 대한 자세한 내용은 Crossplane troubleshooting guide를 읽어보세요.
Provider 삭제 보호 (Provider deletion protection)
Provider 삭제 보호는 알파 기능이에요. Crossplane은 알파 기능을 기본적으로 비활성화해요.
--enable-provider-deletion-protection기능 플래그로 Provider 삭제 보호를 활성화해요. 이 기능은 Usages도 필요로 해요(기본적으로 켜짐).
helm upgrade --install crossplane crossplane-stable/crossplane \
--namespace crossplane-system \
--set args='{"--enable-provider-deletion-protection"}'
Provider 삭제 보호가 있으면 Crossplane은 여전히 활성 관리 리소스가 있는 Provider의 삭제를 방지해요. 이는 Provider를 제거하고 그 관리 리소스를 고아로 만드는 것을 방지해요.
Crossplane은 각 Provider와 연관된 관리 리소스를 감시해요. 관리 리소스가 존재하면 Crossplane은 소유 Provider의 삭제를 차단하는 ClusterUsage를 만들어요. ClusterUsage는 여전히 활성인 관리 리소스 타입을 나타내는 설명적 이유를 포함해요. 예: "Provider has active managed resources of type VPC.ec2.aws.upbound.io".
특정 타입의 관리 리소스를 모두 삭제하면 Crossplane은 해당 ClusterUsage를 자동으로 제거해 Provider를 삭제할 수 있게 해요.
crossplane.io/provider-protection=true 라벨로 모든 Provider 보호 ClusterUsages를 나열해요.
kubectl get clusterusages -l crossplane.io/provider-protection=true
NAME DETAILS READY AGE
provider-protection-0d9403ef4e758ec5ee89d2773d0b356af7635adc37548b0eaabb Provider has active managed resources of type VPC.ec2.aws.m.upbound.io True 22s
provider-protection-3da1709122b36532e8cbdedbcabde45947f99dd33d931eb682ee Provider has active managed resources of type Subnet.ec2.aws.m.upbound.io True 7s
provider-protection-774712aa693d57a5e7ce09a7754d53f3ca5cc59f417083756b2a Provider has active managed resources of type SecurityGroup.ec2.aws.m.upbound.io True 7s
Crossplane은 ManagedResourceDefinition 이름의 해시로 ClusterUsage 이름을 생성해요. crossplane.io/provider-protection=true 라벨로 찾아보세요. 각 ClusterUsage는 Provider 이름(pkg.crossplane.io/package)과 MRD 이름(apiextensions.crossplane.io/mrd) 라벨도 가져요.
특정 ClusterUsage를 검사해 어떤 Provider를 보호하는지, 왜인지 확인해요.
apiVersion: protection.crossplane.io/v1beta1
kind: ClusterUsage
metadata:
name: provider-protection-a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6
labels:
crossplane.io/provider-protection: "true"
pkg.crossplane.io/package: crossplane-contrib-provider-aws-s3
apiextensions.crossplane.io/mrd: buckets.s3.aws.upbound.io
spec:
of:
apiVersion: pkg.crossplane.io/v1
kind: Provider
resourceRef:
name: crossplane-contrib-provider-aws-s3
reason: "Provider has active managed resources of type Bucket.s3.aws.upbound.io"
활성 관리 리소스가 있는 Provider를 삭제하려 하면 Usage admission webhook에서 오류가 반환돼요.
kubectl delete provider.pkg.crossplane.io/provider-aws-ec2
Error from server (This resource is in-use by 3 usage(s), including the
*v1beta1.ClusterUsage "provider-protection-774712aa693d57a5e7ce09a7754d53f3
ca5cc59f417083756b2a" with reason: "Provider has active managed resources of
type SecurityGroup.ec2.aws.m.upbound.io".): admission webhook
"nousages.protection.crossplane.io" denied the request: This resource is
in-use by 3 usage(s), including the *v1beta1.ClusterUsage
"provider-protection-774712aa693d57a5e7ce09a7754d53f3ca5cc59f417083756b2a"
with reason: "Provider has active managed resources of type
SecurityGroup.ec2.aws.m.upbound.io".
보호된 Provider를 삭제하려면 먼저 모든 관리 리소스를 제거하거나, 그것을 보호하는 ClusterUsage 리소스를 수동으로 삭제해요.
Provider 검증 (Verify a Provider)
Provider는 지원하는 관리 리소스를 나타내는 자체 API를 설치해요. Provider는 Deployments, Service Accounts, RBAC 구성도 만들 수 있어요.
kubectl get providers로 Provider 상태를 확인해요. 설치 중에는 Provider가 INSTALLED를 True로, HEALTHY를 Unknown으로 보고해요.
kubectl get providers
NAME INSTALLED HEALTHY PACKAGE AGE
crossplane-contrib-provider-aws-s3 True Unknown xpkg.crossplane.io/crossplane-contrib/provider-aws-s3:v2.0.0 63s
Provider 설치가 완료되고 사용 준비가 되면 HEALTHY 상태가 True를 보고해요.
kubectl get providers
NAME INSTALLED HEALTHY PACKAGE AGE
crossplane-contrib-provider-aws-s3 True True xpkg.crossplane.io/crossplane-contrib/provider-aws-s3:v2.0.0 88s
일부 Provider는 수백 개의 Kubernetes CustomResourceDefinitions(CRD)를 설치해요. 이는 작은 API 서버에 상당한 부담이 되어 Provider 설치 시간에 영향을 줄 수 있어요. Crossplane 커뮤니티는 CRD 스케일링에 대한 더 자세한 내용을 제공해요.
Provider 조건 (Provider conditions)
Crossplane은 Provider에 표준 Conditions 집합을 사용해요. Provider의 조건은 kubectl describe provider로 Status 아래에서 볼 수 있어요.
kubectl describe provider
Name: my-provider
API Version: pkg.crossplane.io/v1
Kind: Provider
# Removed for brevity
Status:
Conditions:
Reason: HealthyPackageRevision
Status: True
Type: Healthy
Reason: ActivePackageRevision
Status: True
Type: Installed
# Removed for brevity
Types
Provider Conditions는 두 가지 Types를 지원해요.
Type: Installed— Provider 패키지가 설치됐지만 사용 준비는 안 됨Type: Healthy— Provider 패키지가 사용 준비 완료
Reasons
각 Reason은 특정 Type과 Status와 관련돼요. Crossplane은 Provider Conditions에 다음 Reasons를 사용해요.
InactivePackageRevision — Reason: InactivePackageRevision은 Provider Package가 비활성 Provider Package Revision을 사용 중임을 나타내요.
Type: Installed
Status: False
Reason: InactivePackageRevision
ActivePackageRevision — Provider Package가 현재 Package Revision이지만, Crossplane이 Package Revision 설치를 아직 끝내지 않았어요.
이 상태에 갇힌 Provider는 Package Revisions 문제 때문이에요. 자세한 내용은
kubectl describe providerrevisions를 사용해요.
Type: Installed
Status: True
Reason: ActivePackageRevision
HealthyPackageRevision — Provider가 완전히 설치되고 사용할 준비가 됐어요.
Reason: HealthyPackageRevision은 정상 동작하는 Provider의 정상 상태예요.
Type: Healthy
Status: True
Reason: HealthyPackageRevision
UnhealthyPackageRevision — Provider Package Revision 설치에 오류가 있어 Crossplane이 Provider Package 설치를 방해했어요.
Package Revision이 실패한 이유에 대한 상세는
kubectl describe providerrevisions를 사용해요.
Type: Healthy
Status: False
Reason: UnhealthyPackageRevision
UnknownPackageRevisionHealth — Provider Package Revision의 상태가 Unknown이에요. Package Revision이 설치 중이거나 문제가 있을 수 있어요.
Package Revision이 실패한 이유에 대한 상세는
kubectl describe providerrevisions를 사용해요.
Type: Healthy
Status: Unknown
Reason: UnknownPackageRevisionHealth
Provider 구성 (Configure a Provider)
Provider는 두 가지 유형의 구성을 가져요.
- 런타임 구성(Runtime configuration) — Kubernetes 클러스터 안에서 실행되는 Provider 파드의 설정을 변경. 예: Provider 파드에 톨러레이션(toleration) 설정
- Provider 구성(Provider configuration) — 외부 Provider와 통신할 때 사용하는 설정을 변경. 예: 클라우드 제공자 인증
런타임 구성 (Runtime configuration)
DeploymentRuntimeConfigs는 베타 기능이에요. 기본적으로 켜져 있으며--enable-deployment-runtime-configs=false를 Crossplane deployment에 전달해 비활성화할 수 있어요.
런타임 구성은 런타임이 있는 Crossplane 패키지, 즉 Providers와 Functions의 런타임을 구성하는 일반화된 메커니즘이에요.
기본 구성에서 Crossplane은 Kubernetes Deployments를 사용해 패키지 런타임을 배포해요. 더 구체적으로는 Provider의 컨트롤러 또는 Function의 gRPC 서버를 배포해요. DeploymentRuntimeConfig를 적용하고 Provider 또는 Function 객체에서 참조해 런타임 매니페스트를 구성할 수 있어요.
예를 들어 Provider에 대한 외부 시크릿 저장소 알파 기능을 활성화하려면 컨트롤러에 --enable-external-secret-stores 인자를 추가하면 되는데, 다음과 같이 적용할 수 있어요.
apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
name: provider-gcp-iam
spec:
package: xpkg.crossplane.io/crossplane-contrib/provider-gcp-iam:v2.0.0
runtimeConfigRef:
name: enable-ess
---
apiVersion: pkg.crossplane.io/v1beta1
kind: DeploymentRuntimeConfig
metadata:
name: enable-ess
spec:
deploymentTemplate:
spec:
selector: {}
template:
spec:
containers:
- name: package-runtime
args:
- --enable-external-secret-stores
패키지 매니저는 런타임 컨테이너 이름으로 package-runtime을 사용한다는 점을 알아두세요. 다른 컨테이너 이름을 사용하면 패키지 매니저는 패키지 런타임 컨테이너를 수정하는 대신 그것을 사이드카 컨테이너로 도입해요.
패키지 매니저는 런타임이 동작하도록 보장하기 위해 일부 필드에 대해 의견(opinionated)을 가지며, 런타임 구성의 값 위에 그것들을 오버레이해요. 예를 들어 설정하지 않으면 replica 수를 1로 기본 설정하고 Deployment와 Service가 일치하도록 라벨 셀렉터를 재정의해요. 또한 필요한 환경 변수, 포트, 볼륨, 볼륨 마운트를 주입해요.
Provider나 Function의 spec.runtimeConfigRef.name 필드는 기본적으로 default 값을 사용해요. 즉 지정하지 않으면 Crossplane이 기본 런타임 구성을 사용한다는 뜻이에요. Crossplane은 클러스터에 항상 기본 런타임 구성이 있도록 보장하지만, 이미 존재하면 그것을 변경하지 않아요. 이를 통해 사용자가 필요에 맞게 기본 런타임 구성을 커스터마이즈할 수 있어요.
DeploymentRuntimeConfig는 KubernetesDeploymentspec과 같은 스키마를 사용하므로, 스키마 검증을 우회하기 위해 빈 값을 전달해야 할 수도 있어요. 예를 들어replicas필드만 변경하려면 다음을 전달해야 해요.
apiVersion: pkg.crossplane.io/v1beta1
kind: DeploymentRuntimeConfig
metadata:
name: multi-replicas
spec:
deploymentTemplate:
spec:
replicas: 2
selector: {}
template: {}
런타임 deployment spec 구성 (Configuring runtime deployment spec)
패키지 매니저는 DeploymentRuntimeConfig에 제공된 Deployment spec을 기준으로 다음 규칙으로 패키지 런타임의 Deployment spec을 만든다.
- 패키지 런타임 컨테이너를 containers 배열의 첫 컨테이너로 주입 (이름
package-runtime) - 제공되지 않으면
spec.replicas를 1로 기본 설정 - Image pull 정책을
IfNotPresent로 기본 설정 - Pod Security Context를 다음으로 설정:
runAsNonRoot: true
runAsUser: 2000
runAsGroup: 2000
- 런타임 컨테이너의 Security Context를 다음으로 설정:
allowPrivilegeEscalation: false
privileged: false
runAsGroup: 2000
runAsNonRoot: true
runAsUser: 2000
- 다음을 적용:
metadata.namespace를 Crossplane 네임스페이스로 설정metadata.ownerReferences를 deployment가 패키지 리비전이 소유하도록 설정- 생성된 라벨로
spec.selectors설정 - 생성된 Service Account로
spec.serviceAccount설정 - Package spec에 제공된 pull secrets를
spec.packagePullSecrets로 이미지 pull secrets로 추가 - Package spec에 제공된 값(
spec.packagePullPolicy)으로 Image Pull Policy 설정 - 런타임 컨테이너에 필요한 Ports 추가
- 런타임 컨테이너에 필요한 Environments 추가
- 필요한 Volumes, Volume Mounts, Environments를 추가해 TLS secrets 마운트
런타임 리소스 메타데이터 구성 (Configuring metadata of runtime resources)
DeploymentRuntimeConfig는 런타임 리소스, 즉 Deployment, ServiceAccount, Service의 다음 메타데이터 구성도 가능하게 해줘요.
- name
- labels
- annotations
다음 예는 ServiceAccount의 이름과 Deployment의 라벨을 구성하는 방법을 보여줘요.
apiVersion: pkg.crossplane.io/v1beta1
kind: DeploymentRuntimeConfig
metadata:
name: my-runtime-config
spec:
deploymentTemplate:
metadata:
labels:
my-label: my-value
serviceAccountTemplate:
metadata:
name: my-service-account
serviceAccountTemplate.metadata.name필드를 설정하면 패키지 매니저가 만들고 Provider deployment에서 사용하는 service account의 이름을 재정의해요. 패키지 매니저는 그 service account를 소유하며, 소유권을 가지려는 다른 소유자와 충돌할 수 있어요. 흔한 실수는 여러 패키지에 같은 service account를 이렇게 구성하는 것인데, 이는 잦은 리컨사일 루프와 API 서버 부하를 일으켜요.기존 service account를 사용하고 싶다면 대신
deploymentTemplate.spec.template.spec.serviceAccountName필드만 설정해야 해요. 그러면 Crossplane은 소유권을 갖지 않고 기존 service account를 사용하고, 필요한 권한 바인딩은 계속 처리해요.
Provider 구성 (Provider configuration)
ProviderConfig는 Provider가 외부 Provider와 통신할 때 사용하는 설정을 결정해요. 각 Provider가 ProviderConfig의 사용 가능한 설정을 결정해요.
Provider 인증은 보통 ProviderConfig로 구성해요. 예를 들어 Provider AWS와 기본 키-페어 인증을 사용하려면 ProviderConfig spec이 credentials를 정의하고 Provider 파드가 Kubernetes Secrets 객체에서 찾아 aws-creds라는 키를 사용하도록 해요.
apiVersion: aws.m.upbound.io/v1beta1
kind: ProviderConfig
metadata:
namespace: default
name: aws-provider
spec:
credentials:
source: Secret
secretRef:
namespace: crossplane-system
name: aws-creds
key: creds
인증 구성은 Provider마다 다를 수 있어요. 특정 Provider의 인증 구성 방법은 해당 Provider 문서를 읽어보세요.
ProviderConfig 타입 (ProviderConfig types)
AWS Provider는 두 가지 ProviderConfig 리소스 타입을 지원해요.
ProviderConfig (네임스페이스 스코프):
apiVersion: aws.m.upbound.io/v1beta1
kind: ProviderConfig
metadata:
namespace: default
name: my-config
# Applies only to MRs in the same namespace
ClusterProviderConfig (클러스터 전역):
apiVersion: aws.m.upbound.io/v1beta1
kind: ClusterProviderConfig
metadata:
name: my-cluster-config
# Applies to MRs across all namespaces
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
ProviderConfig 객체는 개별 Managed Resources에 적용돼요. 단일 Provider는 ProviderConfig를 통해 여러 사용자나 계정으로 인증할 수 있어요. 각 계정의 자격 증명은 고유한 ProviderConfig에 연결돼요. 관리 리소스를 만들 때 원하는 ProviderConfig를 연결해요.
예를 들어 user-keys와 admin-keys라는 두 AWS ProviderConfig가 서로 다른 Kubernetes 시크릿을 사용해요.
apiVersion: aws.m.upbound.io/v1beta1
kind: ProviderConfig
metadata:
namespace: default
name: user-keys
spec:
credentials:
source: Secret
secretRef:
namespace: crossplane-system
name: my-key
key: secret-key
apiVersion: aws.m.upbound.io/v1beta1
kind: ProviderConfig
metadata:
namespace: default
name: admin-keys
spec:
credentials:
source: Secret
secretRef:
namespace: crossplane-system
name: admin-key
key: admin-secret-key
관리 리소스를 만들 때 ProviderConfig를 적용해요. 이는 user-keys ProviderConfig를 사용하는 AWS Bucket 리소스를 만들어요.
apiVersion: s3.aws.m.upbound.io/v1beta1
kind: Bucket
metadata:
namespace: default
name: user-bucket
spec:
forProvider:
region: us-east-2
providerConfigRef:
name: user-keys
kind: ProviderConfig
이것은 admin-keys ProviderConfig를 사용하는 두 번째 Bucket 리소스를 만들어요.
apiVersion: s3.aws.m.upbound.io/v1beta1
kind: Bucket
metadata:
namespace: default
name: admin-bucket
spec:
forProvider:
region: us-east-2
providerConfigRef:
name: admin-keys
kind: ProviderConfig