Англійська для розробників Crossplane

Crossplane розширює словник Kubernetes в інфраструктурне забезпечення, тому інженер платформи повинен накладати нові терміни — композиція, претензія, провайдер — на концепції, які вже знайомі з Terraform або простим Kubernetes.

Ключовий словник

Provider — розширення Crossplane, яке додає підтримку для певної хмари або сервісу, наприклад, AWS або GCP, реєструючи нетипові ресурси, необхідні для управління інфраструктурою цієї платформи. “Цього типу ресурсу ще не існує, тому що ми не встановили для нього провайдера — перевірте, чи він підтримується провайдером AWS, перш ніж писати власний.”

Composition — шаблон, який визначає, як ресурс вищого рівня, визначений командою платформи, відображається на одному або декількох базових хмарних ресурсах, інкапсулюючись у деталі реалізації від команди програми. “Оновлюйте склад, а не заяву кожної команди — це і є суть централізації реалізації в одному місці.”

** Заява ** — запит з простором імен від команди програми для інфраструктури, написаний проти спрощеного API, визначеного командою платформи, який Crossplane виконує за допомогою відповідної композиції. “Команди програм просто надсилають заявку на базу даних — їм не потрібно знати, чи вона забезпечує RDS або Cloud SQL під нею.”

** Складений ресурс (XR) ** — ресурс з обсягом кластера, який Crossplane створює у відповідь на заяву, що представляє фактичний збір основних хмарних ресурсів, якими керується. “Перевірити стан складного ресурсу, а не лише заяву — заява може виглядати здоровою, поки базовий XR все ще знаходиться у процесі примирення.”

** Примирення ** — постійний процес Crossplane, що порівнює бажаний стан, оголошений у композиціях і заявах, з фактичним станом хмари, і автоматично виправляє будь- який дрейф. “Хтось змінив розмір екземпляра безпосередньо в консолі AWS — прирівнювання поверне його до того, що було оголошено, тому зробіть зміну через заяву замість цього.”

Звичайні фрази

• Чи дійсно цей провайдер встановлений, чи тип ресурсу просто ще не доступний?»
• Чи повинна ця зміна йти в складі, чи це впливає тільки на претензії однієї команди?»
• Чи є твердження здоровим, або ж базовий складний ресурс все ще застряг у примиренні?
• “Хтось змінив це поза Crossplane? Примирення повинно захопити і повернути вручну дрейф»
• «Чи ця композиція абстрактна достатньо детально, або команди додатків все ще піддаються хмарним параметрам?»

Приклади висловлювань

Зневадження проблеми з дрейфом:

• “Хтось змінив розмір бази даних безпосередньо у консолі хмарного обслуговування, і прирівнювання просто повернуло її — якщо ця зміна була навмисною, то вона має пройти через заяву, а не консоль.” *

Пояснення вибору архітектури:

• “Ми побудували одну композицію для «стандартної бази даних», яку команди додатків вимагають, тому їм ніколи не потрібно знати або турбуватися, чи підтримується вона RDS або Cloud SQL.” *

Перегляд запиту на звантаження: “Це кодує певний тип екземпляра всередині заявки — ця деталь належить до композиції, тому її можна налаштувати центрально без зміни заявки кожної команди.”

Професійні поради

• Розрізняти ** claim ** від ** composite resource ** точно — claim це запит у просторі імен, XR — це те, що було фактично забезпечено, і об’ єднання їх робить зневадження стану заплутаним.
• Скажіть composition, коли описуєте, де повинні бути деталі реалізації — це шар абстракції команди платформи, і правильна назва прояснює власника.
• Явно посилатися на provider, якщо відсутній тип ресурсу — зазвичай це відсутній або застарілий провайдер, а не помилка Crossplane.
• Використовуйте reconciliation для пояснення автоматичного виправлення дрейфу — це перетворює питання « чому мої зміни, внесені вручну, було скасовано » зі звіту про помилку на очікувану поведінку.

Практичні вправи

1. Пояснити різницю між заявкою і складним ресурсом.
2. Описати, що складання відволікає від команд програм і чому це важливо.
3. Напишіть речення, у якому пояснюється, що відбувається під час прирівнювання, коли хтось вносить зміни вручну за межами Crossplane.

Національні мови: рідна мова для ненаціональних меншин

Crossplane є потужним інструментом, але як і будь-яка складна технологія, вона часто комунікується з точністю - і іноді ця точність може бути приголомшливою для тих, хто все ще розвиває свою вільну англійську. Незначні відмінності у фразуваннях, наголос на конкретних термінах і очікування ясного, короткого спілкування - це всі області, де можуть легко виникнути непорозуміння. Це не просто про те, щоб знати * що * щось робить; це про розуміння * як * це запитується, переглядається або пояснюється. Розглянемо декілька типових сценаріїв, які часто представляють виклики для розробників, чия перша мова не є англійською.

Однією з поширених проблем є часте використання «претензій» в Crossplane. Це не просто «запит» чогось; ви заявляєте ресурси через декларативне визначення. Переглядач може залишити коментар до вашого Запиту на звантаження, наприклад, « Ця заява може бути більш конкретною. Розгляньте можливість додавання міток, щоб чітко визначити його мету і залежності. Це не критика вашої роботи; це запрошення до пояснення — прохання до вас більш точніше сформулювати намір, який стоїть за вашою заявою. Аналогічно, дискусії навколо «композицій» часто вимагають ретельного розгляду. Це не просто зібрання компонентів; це визначення відносин і залежностей, які створюють єдине, функціональне ціле в Crossplane. Ефективне спілкування вимагає використання мови, яка підкреслює оркестрацію, а не просте з’єднання.

Іншим джерелом потенційної плутанини є рівень деталізації, який очікується під час опису змін до ваших розгортань. У повідомленні Slack з запитом на оновлення може бути написано: «Чи можете ви переглянути останню PR для оновлення постачальника Azure PostgreSQL? Переконайтеся, що параметри масштабування правильно налаштовані і документуйте будь-які зміни до манифестів Kubernetes. “Фраза “правильно налаштований” не є випадковим спостереженням; це директива, яка вимагає демонстраційного доказу дотримання встановлених найкращих практик. Аналогічно, «документувати будь-які зміни» переносить тягар на вас, щоб пояснити * чому * ці зміни були зроблені, забезпечуючи контекст для майбутніх супроводжувачів - важливий елемент, який часто ігнорується в початковому спілкуванні.

Нарешті, розуміння різниці між «провішн» і «девелопмент» часто є камінням спотикання. Хоча обидва відносяться до приведення ресурсів в мережу, «провішн» має сильнішу конотацію конфігурації основної інфраструктури, тоді як «девелопмент» зосереджений на встановленні самої програми. Використання правильного терміну демонструє глибше розуміння процесу і допомагає уникнути неоднозначності.

# Example: Using Crossplane to provision an AWS S3 bucket
apiVersion: crossplane.crossplane.sh/v1alpha1
kind: Bucket
metadata:
  name: my-s3-bucket
spec:
  storage:
    provisioner: busybox
    type: awsS3

Цей простий приклад демонструє основний словник в дії — визначення ресурсу ( Bucket ) і використання provisioner, щоб привести його до існування в межах вашого хмарного провайдера (тут, AWS S3). Ясність цього визначення YAML має надзвичайно важливе значення; будь- які неоднозначності буде позначено прапорцем під час перевірки.