Цій статті вже більше одного року. Старі статті можуть містити застарілу інформацію. Перевірте та переконайтесь, що інформація на сторінці не стала невірною після її публікації.
pkgs.k8s.io: Представляємо репозиторії пакунків від спільноти Kubernetes
Від імені Kubernetes SIG Release, я дуже радий представити репозиторії програмного забезпечення від спільноти Kubernetes, для пакунків Debian та RPM: pkgs.k8s.io! Нові репозиторії пакунків є заміною для репозиторіїв, що надаються Google (apt.kubernetes.io та yum.kubernetes.io), які ми використовували з Kubernetes v1.5.
Цей допис містить інформацію про ці нові репозиторії пакунків. Що це означає для вас як кінцевого користувача, і як перейти на нові репозиторії?
ℹ️ Оновлення (26 березня 2024): застарілі репозиторії, що надаються Google, були прибрані 4 березня 2024. Більше неможливо встановлювати пакунки Kubernetes із застарілих репозиторіїв, що надаються Google. Перегляньте оголошення про припинення підтримки для отримання додаткової інформації про цю зміну.
Що вам потрібно знати про нові репозиторії пакунків?
(оновлено 12 січня 2024 та 26 березня 2024)
- Це не автоматична зміна; вам потрібно вручну перейти з використання репозиторію, що підтримується Google, на репозиторії, що належать спільноті Kubernetes. Дивіться як перейти далі в цьому оголошенні для інформації про міграцію та інструкцій.
- Застарілі репозиторії, що надаються Google, було прибрано 4 березня 2024. Більше неможливо встановлювати пакунки Kubernetes із застарілих репозиторіїв, що надаються Google. Ці репозиторії були визнані застарілими з 31 серпня 2023, та заморожені з 13 вересня 2023. Перегляньте оголошення про припинення підтримки для отримання додаткової інформації про цю зміну.
Застарілі репозиторії, що надаються Google, будуть прибрані у січні 2024. Ці репозиторії були визнані застарілими з 31 серпня 2023, та заморожені з 13 вересня 2023. Перегляньте оголошення про припинення підтримки для отримання додаткової інформації про цю зміну.Наявні пакунки в застарілих репозиторіях будуть доступні на невизначений час. Однак, проєкт Kubernetes не може гарантувати, як довго це буде. Застарілі репозиторії та їх вміст можуть бути видалені в будь-який час у майбутньому без подальшого періоду повідомлення. Застарілі репозиторії пакунків зникнуть у січні 2024.Застарілі репозиторії, що надаються Google, були прибрані 4 березня 2024.- Оскільки нові релізи не будуть публікуватися в застарілих репозиторіях після 13 вересня 2023, ви не зможете оновитися до будь-якого патча або мінорного релізу, зробленого з тієї дати і далі, якщо ви не перейдете на нові репозиторії пакунків Kubernetes.
Тим не менш, ми рекомендуємо переходити на нові репозиторії пакунків Kubernetes якнайшвидше.Перехід на нові репозиторії пакунків Kubernetes необхідний для отримання офіційних пакунків Kubernetes. - Нові репозиторії пакунків Kubernetes містять пакунки, починаючи з тих версій Kubernetes, які все ще підтримувалися, коли спільнота взяла на себе збірку пакунків. Це означає, що нові репозиторії пакунків мають пакунки Linux для всіх релізів Kubernetes, починаючи з v1.24.0.
- Kubernetes не має офіційних пакунків Linux, доступних для попередніх релізів Kubernetes; однак, ваш дистрибутив Linux може надавати власні пакунки.
- Існує окремий репозиторій пакунків для кожної мінорної версії Kubernetes. При оновленні до іншої мінорної версії, ви повинні памʼятати, що деталі репозиторію пакунків також змінюються. Перегляньте посібник Зміна репозиторію пакунків Kubernetes для отримання інформації про кроки, які вам потрібно виконати під час оновлення мінорної версії Kubernetes.
Чому ми представляємо нові репозиторії пакунків?
Оскільки проєкт Kubernetes розвивається, ми хочемо забезпечити найкращий можливий досвід використання для кінцевих користувачів. Репозиторій, що надається Google, служив нам добре багато років, але ми почали стикатися з деякими проблемами, які вимагають значних змін у тому, як ми публікуємо пакунки. Інша мета, яку ми маємо, — це використання інфраструктури, що належить спільноті, для всіх критичних компонентів, і це включає репозиторії пакунків.
Публікація пакунків у репозиторій, що надається Google, є ручним процесом, який може виконуватися лише командою співробітників Google, Google Build Admins. Команда менеджерів релізів Kubernetes є дуже різноманітною, особливо щодо часових поясів, у яких ми працюємо. З огляду на це обмеження, нам доводиться дуже ретельно планувати кожен реліз, щоб забезпечити наявність як менеджера релізів, так і Google Build Admin для виконання релізу.
Інша проблема полягає в тому, що у нас є лише один репозиторій пакунків. Через це, ми не могли публікувати пакунки для попередніх версій (alpha, beta та rc). Це ускладнювало тестування попередніх релізів Kubernetes для всіх, хто зацікавлений був це робити. Зворотний звʼязок, який ми отримуємо від людей, що тестують ці релізи, є критичним для забезпечення найкращої якості релізів, тому ми хочемо зробити тестування цих релізів якомога простішим. Крім того, наявність лише одного репозиторію обмежувала нас щодо публікації залежностей, таких як cri-tools та kubernetes-cni.
Незважаючи на всі ці проблеми, ми дуже вдячні Google та Google Build Admins за їх участь, підтримку та допомогу всі ці роки!
Як працюють нові репозиторії пакунків?
Нові репозиторії пакунків надаються за адресою pkgs.k8s.io для пакунків Debian та RPM. На цей час цей домен вказує на CloudFront CDN, який вказує на кошик S3 в якому місяться репозиторії та пакунки. Однак, ми плануємо розгорнути додаткові дзеркала в майбутньому, даючи можливість іншим компаніям допомогти нам з обслуговуванням пакунків.
Пакунки збираються та публікуються платформою OpenBuildService (OBS). Після тривалого періоду оцінки різних рішень, ми прийняли рішення використовувати OpenBuildService як платформу для управління нашими репозиторіями та пакунками. По-перше, OpenBuildService є відкритою платформою, що використовується великою кількістю проєктів з відкритим кодом та компаній, таких як openSUSE, VideoLAN, Dell, Intel та інші. OpenBuildService має багато функцій, що роблять його дуже гнучким та легким для інтеграції з нашими поточними інструментами випусків релізів. Він також дозволяє нам збирати пакунки подібним чином, як для репозиторію, що надається Google, роблячи процес міграції якомога безшовним.
SUSE спонсорує проєкт Kubernetes надаючи доступ до їх налаштувань OpenBuildService (build.opensuse.org) та технічу підтримку для інтеграції OBS з нашими процесами випусків релізів.
Ми використовуємо екземпляр OBS від SUSE для збірки та публікації пакунків. При збірці нового релізу, наші інструменти автоматично надсилають необхідні артефакти та специфікації пакунків до build.opensuse.org. Це запускає процес збірки, який збиратиме пакунки для всіх підтримуваних архітектур (AMD64, ARM64, PPC64LE, S390X). Наприкінці, згенеровані пакунки будуть автоматично надіслані до нашого спільнотного кошика S3, роблячи їх доступними для всіх користувачів.
Ми хочемо скористатися цією можливістю, щоб подякувати SUSE за дозвіл використовувати build.opensuse.org та їх щедру підтримку для здійснення цієї інтеграції!
Які значні відмінності між репозиторіями, що надаються Google, та репозиторіями пакунків Kubernetes?
Існує три значні відмінності, про які ви повинні знати:
- Існує окремий репозиторій для кожної мінорної версії Kubernetes. Наприклад, репозиторій з назвою
core:/stable:/v1.28містить лише пакунки для стабільних релізів Kubernetes v1.28. Це означає, що ви можете встановити v1.28.0 з цього репозиторію, але не можете встановити v1.27.0 або будь-яку іншу мінорну версію крім v1.28. При оновленні до іншої мінорної версії, вам потрібно додати новий репозиторій та опціонально видалити старий - Існує різниця в тому, які версії пакунків
cri-toolsтаkubernetes-cniдоступні в кожному репозиторії Kubernetes- Ці два пакунки є залежностями для
kubeletтаkubeadm - Репозиторії Kubernetes для v1.24 до v1.27 мають ті самі версії цих пакунків, що й репозиторій, що підтримується Google
- Репозиторії Kubernetes для v1.28 та далі будуть публікувати лише версії, що використовуються цією мінорною версією Kubernetes
- Говорячи про v1.28, лише kubernetes-cni 1.2.0 та cri-tools v1.28 будуть доступні в репозиторії для Kubernetes v1.28
- Подібно для v1.29, ми плануємо публікувати лише cri-tools v1.29 та ту версію kubernetes-cni, що буде використовуватися Kubernetes v1.29
- Ці два пакунки є залежностями для
- Частина ревізії версії пакунка (частина
-00у1.28.0-00) тепер автоматично генерується платформою OpenBuildService та має інший формат. Ревізія тепер у форматі-x.y, наприклад1.28.0-1.1
Чи впливає це якимось чином на існуючі репозиторії, що надаються Google?
(оновлено 26 березня 2024)
Застарілі репозиторії, що надаються Google, були прибрані 4 березня 2024. Більше неможливо встановлювати пакунки Kubernetes із застарілих репозиторіїв, що надаються Google. Перегляньте оголошення про припинення підтримки для отримання додаткової інформації про цю зміну.
Репозиторій, що надається Google, та всі пакунки, опубліковані в ньому, будуть продовжувати працювати так само, як і раніше. Немає змін у тому, як ми збираємо та публікуємо пакунки в репозиторій, що надається Google, всі нововведені зміни впливають лише на пакунки, опубліковані в репозиторіях, що належать спільноті.
Однак, як згадувалося на початку цього допису в блозі, ми плануємо припинити публікацію пакунків у репозиторій, що надається Google, у майбутньому.
Як перейти на репозиторії пакунків від спільноти Kubernetes?
Debian, Ubuntu та операційні системи, що використовують apt/apt-get
Замініть визначення репозиторію
apt, щобaptвказував на новий репозиторій замість репозиторію, що надається Google. Переконайтеся, що замінили мінорну версію Kubernetes у команді нижче на мінорну версію, яку ви зараз використовуєте:echo "deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.28/deb/ /" | sudo tee /etc/apt/sources.list.d/kubernetes.listЗавантажте публічний ключ підпису для репозиторіїв пакунків Kubernetes. Той самий ключ підпису використовується для всіх репозиторіїв, тому ви можете ігнорувати версію в URL:
curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.28/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpgОновлення: У релізах старіших за Debian 12 та Ubuntu 22.04, теки
/etc/apt/keyringsнемає, її слід створити перед виконанням команди curl.Оновіть індекс пакунків
apt:sudo apt-get update
CentOS, Fedora, RHEL та операційні системи, що використовують rpm/dnf
Замініть визначення репозиторію
yum, щобyumвказував на новий репозиторій замість репозиторію, що надається Google. Переконайтеся, що замінили мінорну версію Kubernetes у команді нижче на мінорну версію, яку ви зараз використовуєте:cat <<EOF | sudo tee /etc/yum.repos.d/kubernetes.repo [kubernetes] name=Kubernetes baseurl=https://pkgs.k8s.io/core:/stable:/v1.28/rpm/ enabled=1 gpgcheck=1 gpgkey=https://pkgs.k8s.io/core:/stable:/v1.28/rpm/repodata/repomd.xml.key exclude=kubelet kubeadm kubectl cri-tools kubernetes-cni EOF
Де я можу отримати пакунки для версій Kubernetes до v1.24.0?
(оновлено 26 березня 2024 року)
Для Kubernetes v1.24 і новіших версій пакунки Linux для компонентів Kubernetes доступні для завантаження через офіційні репозиторії пакунків Kubernetes. Kubernetes не публікує жодних пакунків програмного забезпечення для релізів Kubernetes старіших за v1.24.0; однак, ваш дистрибутив Linux може надавати власні пакунки. Крім того, ви можете безпосередньо завантажити бінарні файли замість використання пакунків. Наприклад, дивіться інструкції Без менеджера пакунків у документі "Встановлення kubeadm".
Чи можу я повернутися до репозиторію, що надається Google, після міграції до репозиторіїв Kubernetes?
(оновлено 26 березня 2024 року)
Застарілі репозиторії, розміщені Google, припинили роботу 4 березня 2024 року, тому більше неможливо повернутися до застарілих репозиторіїв, що надаються Google.
Загалом, так. Просто виконайте ті самі кроки, що й під час міграції, але використовуйте параметри для репозиторію, що надається Google. Ви можете знайти ці параметри в документі, такому як "Встановлення kubeadm".
Чому немає стабільного списку доменів/IP? Чому я не можу обмежити завантаження пакунків?
Наш план для pkgs.k8s.io полягає в тому, щоб зробити його перенаправлювачем до набору бекендів (дзеркал пакунків) на основі розташування користувача. Характер цієї зміни означає, що користувач, який завантажує пакунок, може бути перенаправлений до будь-якого дзеркала в будь-який час. З огляду на архітектуру та наші плани щодо підключення додаткових дзеркал у найближчому майбутньому, ми не можемо надати список IP-адрес або доменів, які ви можете додати до списку дозволених.
Обмежувальні механізми контролю, такі як проксі man-in-the-middle або мережеві політики, що обмежують доступ до конкретного списку IP/доменів, зламаються з цією зміною. Для цих сценаріїв ми рекомендуємо віддзеркалювати пакунки релізу до локального репозиторію пакунків, над яким ви маєте повний контроль.
Що робити, якщо я виявив якусь аномалію з новими репозиторіями?
Якщо ви зіткнулися з будь-якою проблемою з новими репозиторіями пакунків Kubernetes, будь ласка, створіть тікет в репозиторії kubernetes/release.