Оновлення кластера
Ця сторінка надає огляд кроків, які вам слід виконати для оновлення кластера Kubernetes.
Спосіб оновлення кластера залежить від того, як ви спочатку розгорнули його та від будь-яких наступних змін.
На високому рівні кроки, які ви виконуєте, такі:
- Оновити панель управління
- Оновити вузли в вашому кластері
- Оновити клієнтів, такі як kubectl
- Відредагувати маніфести та інші ресурси на основі змін API, які супроводжують нову версію Kubernetes
Перш ніж ви розпочнете
Вам потрібно мати кластер. Ця сторінка присвячена оновленню з Kubernetes 1.29 до Kubernetes 1.30. Якщо ваш кластер зараз працює на Kubernetes 1.29, тоді, будь ласка, перевірте документацію для версії Kubernetes, на яку ви плануєте оновити.
Підходи до оновлення
kubeadm
Якщо ваш кластер був розгорнутий за допомогою інструменту kubeadm, дивіться Оновлення кластерів kubeadm для докладної інформації щодо оновлення кластера.
Після того, як ви оновили кластер, не забудьте встановити останню версію kubectl.
Ручне розгортання
Увага:
Ці кроки не враховують розширень сторонніх сторін, таких як мережеві втулки та втулки сховищ.Вам слід вручну оновити панель управління наступним чином:
- etcd (всі екземпляри)
- kube-apiserver (всі хости панелі управління)
- kube-controller-manager
- kube-scheduler
- контролер управління хмари, якщо ви використовуєте його
На цьому етапі вам слід встановити останню версію kubectl.
Для кожного вузла в вашому кластері, очистіть цей вузол, а потім або замініть його новим вузлом, який використовує 1.30 kubelet, або оновіть kubelet на цьому вузлі та відновіть його Service.
Увага:
Jxbotyyz вузлів перед оновленням kubelet забезпечує повторний вхід Podʼів та перезапуск контейнерів, що може бути необхідно для розвʼязання деяких проблем безпеки або інших важливих помилок.Інші розгортання
Дивіться документацію для вашого інструменту розгортання кластера, щоб дізнатися рекомендовані кроки для підтримки.
Завдання після оновлення
Перемикання версії API зберігання кластера
Обʼєкти, які серіалізуються в etcd для внутрішнього представлення кластера ресурсів Kubernetes, записуються за допомогою певної версії API.
Коли підтримуване API змінюється, ці обʼєкти можуть потребувати перезаписування в новому API. Невиконання цього призведе до того, що ресурси не можна буде декодувати або використовувати за допомогою сервера API Kubernetes.
Для кожного ураженого обʼєкта, отримайте його, використовуючи останню підтримувану версію API, а потім записуйте його також, використовуючи останню підтримувану версію API.
Оновлення маніфестів
Оновлення до нової версії Kubernetes може надати нові API.
Ви можете використовувати команду kubectl convert для конвертації маніфестів між різними версіями API. Наприклад:
kubectl convert -f pod.yaml --output-version v1
Інструмент kubectl замінює вміст pod.yaml на маніфест, який встановлює kind на Pod (незмінно), але з оновленим apiVersion.
Втулки пристроїв
Якщо ваш кластер використовує втулки пристроїв і вузол потребує оновлення до випуску Kubernetes з новішою версією API втулка пристроїв, втулки пристроїв повинні бути оновлені для підтримки обох версій перед оновленням вузла, щоб гарантувати, що виділення пристроїв продовжує успішно завершуватися під час оновлення.
Дивіться Сумісність API та Версії API керуючого пристрою Kubelet для отримання додаткової інформації.