Як сказати kubectl, Kubernetes і інші DevOps терміни
Правильна вимова для kubectl, Kubernetes, Terraform, Ansible, Grafana, Prometheus, Helm і 10 інших інструментів DevOps — з обґрунтуванням кожного з них.
Якщо ви працюєте з Kubernetes, ви, ймовірно, чули * kubectul *, * kub- control *, і * cube- cuttle * в одному спринті. Ці інструменти в основному були створені окремими інженерами або невеликими командами, які ніколи не публікували офіційного посібника з вимову. Ось що спільнота вирішила, і де дебати все ще живуть.
Найбільше відомий своїми виступами за «Депортіво»
kubectl
** Найбільш поширені: KYOO- bi- ctl** або ** KUBE- ectl**
Це найчастіше запитуваний DevOps вимовою, і чесно кажучи, спільнота не повністю вирішила його. Ви почуєте такі параметри:
- ** « cube- cuttle » ** — неформальний, використовується у багатьох конференційних виступах і екранних записах
- « kube- control » — тому що
kubectl= « Kubernetes control » - “кубе-ек-ті-ель” - як написати
- “кубе-ей-ті-елл” — ще один варіант написання
Спільнота Kubernetes розділена. « Cube- cuttle », мабуть, найпоширеніший в англомовних спільнотах. У підкастах DevOps і на розмовах KubeCon ви почуєте все, що вище. Виберіть одну і будьте послідовними.
Kubernetes
Право: KYOO-ber-NET-eez (/kjuːbəˈnɛtiːz/)
Чотири склади: к’ю-бер-нет-із. Це походить від грецького слова κυβερνήτης (kubernḗtēs), що означає « керманич » або « пілот ». Абревіатуру « K8s » читають як « kates » (K + 8 літер + s).
Не скажіть “ку-бер-нет-іс” або “ку-бер-ні-тіс”. Перший склад - “КЮО” з звуком “Y”, як “чека”
Terraform
Праворуч: TER-a-форма (/ˈtɛrəfɔːrm/)
“Terra” - це латинське слово для землі; “form” = формувати. Отже, “терраформа” = зробити Землю подібною. Підкреслюйте перший склад. Не кажи “РАЗРАЗ-а-форм” (розривай як у плачі).
Ansible
Праворуч: AN-si-bul (/ˈænsɪbəl/)
Три склади: AN-si-bul. Названо на честь пристрою зв’язку, що працює швидше світла, в Урсулі К. Наукова фантастика Ле Гуїна. Наголос на першому складі: AN-si-bul.
Grafana
- Ґа́ррі (нар
Творець і компанія використовують “gra-FAH-na” з наголосом на другому складі. Не “ГРАФ-а-на”
Prometheus
Право: pro-MEE-thee-us (/prəˈmiːθiəs/)
Цей слідує своєму грецькому міфологічному джерелу. Четыре слога: про-МЕЕ-те-нас. Не “про-ме-ТЕУС”
Helm
** Право: HELM ** - один склад, римується з “реальність”
Простенько. Але варто відзначити: у мові ви кажете “Шлемовий графік” (по одному складу кожному).
etcd
Праворуч: ЕТ-сі-ді (написати: Е-Т-С-Д)
Не « et- kid » або « et- seed ». Літери: E- T- C- D → « ee- tee- see- dee ». Це розподілене сховище ключів і значень; назва походить від Unix /etc directory + « d » для « розподіленого »
Nginx (переглянуто в контексті DevOps)
Праворуч: EN-jinx
Варто повторити: nginx — це скорочення від «engine X». Вимовляється як EN-jinx. Ви будете налаштовувати його як зворотній проксі постійно; скажіть це з впевненістю.
Названий на честь обласного центру
| Term | Pronunciation | Notes |
|---|---|---|
| AWS | ay-double-you-ess | Always spell it out |
| GCP | jee-see-pee | Always spell it out |
| Azure | AZH-er | /ˈæʒər/ — rhymes with “treasure” without the tre |
| Vercel | VER-sel | Two syllables: VER-sel |
| Heroku | HEH-roh-koo | Three syllables, stress on first |
| Netlify | NET-li-fy | Three syllables |
Бази даних та повідомлення
| Term | Pronunciation | Notes |
|---|---|---|
| PostgreSQL | POST-gres-Q-L | Always spell out the SQL part: P-O-S-T-G-R-E-S, then Q-L |
| Redis | RED-is | Short E — like “red” + “is.” Not “REE-dis.” |
| Kafka | KAF-kuh | Short A — like the author Franz Kafka |
| RabbitMQ | RAB-it em-KYOO | Spell out “MQ” as: em-queue |
| Elasticsearch | ee-LAS-tic-search | Four syllables, stress on second |
Linux-World (англійською)
| Term | Pronunciation | Notes |
|---|---|---|
| Ubuntu | oo-BOON-too | /ʊˈbʊntuː/ — from the Zulu/Xhosa word; three syllables |
| Debian | DEB-ee-un | Three syllables; named after creator Debra and Ian Murdock |
| Arch | ARCH | One syllable, like “archway” |
| systemd | SIS-tem-dee | Read as: system-dee |
| crontab | KRON-tab | KRON = one syllable (rhymes with “on”); tab = one syllable |
«Слово про пана Кубрика» в контексті
Одна річ, яку треба практикувати: екосистемні терміни разом. Речення, яке ви можете сказати під час виступу: « Я розгорнув службу за допомогою Helm, оновив ConfigMap за допомогою kubectl і перевірив метрику у Grafana. »
Це означає: ”… використовуючи HELM, оновив ConfigMap за допомогою KYOO-bi-ctl, і перевірив метрику в gra-FAH-na.”
Практикуючи ціле речення вголос - а не тільки окремі слова - так вимова стає природною в розмові. Візьміть документацію DevOps, яку ви читаєте, і прочитайте її вголос. Конференційні виступи на YouTube (KubeCon, HashiConf, власні виступи Grafana) є найкращим джерелом для того, щоб почути ці терміни, які використовуються їх творцями.
Збірник Cheatsheet
| Term | Say this |
|---|---|
| kubectl | cube-cuttle (most common) or kube-control |
| Kubernetes | KYOO-ber-NET-eez |
| Terraform | TER-a-form |
| Ansible | AN-si-bul |
| Grafana | gra-FAH-na |
| Prometheus | pro-MEE-thee-us |
| etcd | ee-tee-see-dee |
| Redis | RED-is |
| Kafka | KAF-kuh |
| Ubuntu | oo-BOON-too |
| Azure | AZH-er |
На практиці: Навігація нюансів за межами простого перекладу
Для людей, для яких англійська мова не є рідною, в середовищі DevOps легко потрапити в пастку простого перекладу термінів безпосередньо з вашої першої мови. Хоча це може забезпечити базове розуміння, часто втрачається важливий контекст і нюанси, які є життєво важливими для ефективного спілкування в технічній команді. Розглянемо концепцію «рефакторингу» — основної практики в розробці програмного забезпечення. У прямому перекладі можна зосередитись на буквальному значенні слова « переупорядкувати », але у коментарі перегляду коду ви почуєте щось на зразок: « Цей перефакторизація покращує читабельність і підтримку за допомогою спрощення складної логіки. » Додані фрази не стосуються того, що змінюється, вони переказують, чому це важливо для досягнення цілей проекту. Аналогічно, коли пояснюється стратегія розгортання зацікавленим сторонам, простого зауваження «ми використовуємо Kubernetes» недостатньо. Вам потрібно сформулювати * як * це підтримує їх бізнес-потреби - наприклад, “Kubernetes дозволяє нам автоматично масштабувати нашу програму на основі попиту користувача, забезпечуючи оптимальну продуктивність і мінімізуючи час простою.”
Іншою поширеною пасткою є нерозуміння рівня формальності, очікуваної в різних каналах комунікації. У повідомленні Slack, у якому обговорюється швидке виправлення, може бути використано більш неформальний опис, ніж докладний опис запиту на звантаження. Під час перегляду коду, точність є найважливішою. Зворотній зв’ язок на зразок « Це має бути надійніше » не є достатнім; за ним повинні слідувати конкретні пропозиції: « Чи можете ви додати обробку помилок для потенційних тайм- аутів мережі? » або « Розгляньте можливість використання mutexa, щоб запобігти умовам перегонів під час оновлення бази даних. » Крім того, термінологія DevOps часто містить неявні припущення щодо встановлених потоків роботи і найкращих практик. Розробник може сказати: «Давайте просто запустимо kubectl apply -f deployment.yaml», не пояснюючи, що ця команда ініціює послідовне оновлення програми на всіх вузлах кластера — дія, яка безпосередньо впливає на доступність сервісу і вимагає ретельного моніторингу. Зрозуміти ці немовлені очікування є ключем до безперервної інтеграції в команду.
Нарешті, пам’ятайте, що технічний жаргон не тільки про окремі слова; це про зв’язки між концепціями. Ви часто почуєте такі фрази, як «блакитно-зелене розгортання» або «інфраструктура як код» - це не ізольовані терміни, а представляють складний процес з конкретними цілями і розрахунками. Важливо зрозуміти загальний робочий процес і те, як кожен інструмент сприяє досягненню цього робочого процесу. Не бійтеся задати прояснюючі питання; набагато краще шукати розуміння, ніж робити припущення, засновані на буквальному перекладі.
kubectl get pods -n my-app