У нас есть настройка Crossplane для создания ResourceGroup и StorageAccount в Azure (см. полноценный пример проекта на GitHub).
Мы используем официального поставщика Azure (то есть новые семейства разделенных поставщиков Upbound) Provider-azure-storage и создаем следующие кроссплоскостные манифесты:
Определение Provider
:
apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
name: provider-azure-storage
spec:
package: xpkg.upbound.io/upbound/provider-azure-storage:v0.39.0
packagePullPolicy: Always
revisionActivationPolicy: Automatic
revisionHistoryLimit: 1
ProviderConfig
:
apiVersion: azure.upbound.io/v1beta1
kind: ProviderConfig
metadata:
name: default
spec:
credentials:
source: Secret
secretRef:
namespace: crossplane-system
name: azure-account-creds
key: creds
azure-account-creds
генерируются , как описано в руководстве по началу работы .
Наши CompositeResourceDefinition
:
apiVersion: apiextensions.crossplane.io/v1
kind: CompositeResourceDefinition
metadata:
name: xstoragesazure.crossplane.jonashackt.io
spec:
group: crossplane.jonashackt.io
names:
kind: XStorageAzure
plural: xstoragesazure
claimNames:
kind: StorageAzure
plural: storagesazure
defaultCompositionRef:
name: storageazure-composition
versions:
- name: v1alpha1
served: true
referenceable: true
schema:
openAPIV3Schema:
type: object
properties:
spec:
type: object
properties:
parameters:
type: object
properties:
location:
type: string
resourceGroupName:
type: string
storageAccountName:
type: string
required:
- location
- resourceGroupName
- storageAccountName
Наши Composition
:
apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
name: storageazure-composition
labels:
crossplane.io/xrd: xstoragesazure.crossplane.jonashackt.io
provider: azure
spec:
compositeTypeRef:
apiVersion: crossplane.jonashackt.io/v1alpha1
kind: XStorageAzure
writeConnectionSecretsToNamespace: crossplane-system
resources:
- name: storageaccount
base:
apiVersion: storage.azure.upbound.io/v1beta1
kind: Account
metadata: {}
spec:
forProvider:
accountKind: StorageV2
accountTier: Standard
accountReplicationType: LRS
patches:
- fromFieldPath: spec.parameters.storageAccountName
toFieldPath: metadata.name
- fromFieldPath: spec.parameters.resourceGroupName
toFieldPath: spec.forProvider.resourceGroupName
- fromFieldPath: spec.parameters.location
toFieldPath: spec.forProvider.location
- name: resourcegroup
base:
apiVersion: azure.upbound.io/v1beta1
kind: ResourceGroup
metadata: {}
patches:
- fromFieldPath: spec.parameters.resourceGroupName
toFieldPath: metadata.name
- fromFieldPath: spec.parameters.location
toFieldPath: spec.forProvider.location
И, наконец, наши Claim
:
apiVersion: crossplane.jonashackt.io/v1alpha1
kind: StorageAzure
metadata:
namespace: default
name: managed-storage-account
spec:
compositionRef:
name: storageazure-composition
parameters:
location: West Europe
resourceGroupName: rg-crossplane
storageAccountName: account4c8672f
Все применяется через kubectl apply
и не выдает никаких ошибок.
Хотя StorageAccount имеет READY: False
при просмотре вывода kubectl get crossplane
.
Как мы можем проверить ресурсы кроссплоскости, чтобы иметь возможность отследить ошибку. StorageAccount, похоже, не создан на портале Azure.
В документации есть отличная документация о том, как устранять неполадки в ресурсах кроссплана, которая в основном посвящена запуску kubectl describe
и kubectl get event
на ваших кроссплатформенных ресурсах.
Но начиная с версии Crossplane 1.14 в интерфейс командной строки Crossplane включены новые функции. Одной из таких функций является команда crossplane beta trace
, которая позволяет проверять любые межплоскостные ресурсы и видеть их соответствующий статус, а также направлена на оптимизацию процесса устранения неполадок:
trace
изучить живые ресурсы и найти первопричину проблем быстро
Теперь для использования команды в нашем примере необходимо сначала установить интерфейс командной строки Crossplane. Согласно документации этого можно добиться следующим образом:
curl -sL "https://raw.githubusercontent.com/crossplane/crossplane/master/install.sh" | sh
sudo mv crossplane /usr/local/bin
Теперь, имея интерфейс командной строки Crossplane, мы можем использовать его для проверки статуса нашего Claim
с помощью следующей команды:
crossplane beta trace StorageAzure managed-storage-account -o wide
После trace
вам нужно указать имя вашего Claim
(в нашем случае это StorageAzure
), а затем metadata.name
(здесь managed-storage-account
). Добавленный -o wide
помогает увидеть полные сообщения об ошибках, если таковые имеются.
Теперь это должно дать вам ценную информацию. У нас был случай, когда наши учетные данные Azure были нарушены, и теперь мы наконец получили подсказку:
$ crossplane beta trace StorageAzure managed-storage-account -o wide
NAME SYNCED READY STATUS
StorageAzure/managed-storage-account (default) True False Waiting: ...resource claim is waiting for composite resource to become Ready
└─ XStorageAzure/managed-storage-account-6g2xn True False Creating: Unready resources: resourcegroup, storageaccount
├─ Account/account4c8672d False - ReconcileError: ...r_uri":"https://login.microsoftonline.com/error?code=7000215"}:
└─ ResourceGroup/rg-crossplane False - ReconcileError: ...r_uri":"https://login.microsoftonline.com/error?code=7000215"}:
Почему этот вопрос закрыт, как и многие другие перекрестные вопросы? Существует ровно 0 вопросов о кроссплане в ServerFault или других сообществах Stackexchange, а также нет тега CI/CD (где для него есть сообщество здесь, среди других облачных сообществ)? Кроме того, этот вопрос, кажется, помогает многим людям - я этого не понимаю. В этом рассуждении должны быть закрыты любые вопросы по Docker, Kubernetes, CI/CD (GitHub, GitLab — тоже Сообщество), Ansible и т.д. и т.п. Действительно раздражает. Извините, что разглагольствую здесь, но не знаю, где это сделать.