Мережа

• 1: Додавання записів до файлу /etc/hosts у Podʼі за допомогою HostAliases
• 2: Переналаштування стандартного ServiceCIDR Kubernetes

1 - Додавання записів до файлу /etc/hosts у Podʼі за допомогою HostAliases

Додавання записів до файлу /etc/hosts у Podʼі дає змогу перевизначити розвʼязання імен хостів на рівні Podʼа, коли DNS та інші варіанти не підходять. Ви можете додавати ці власні записи за допомогою поля HostAliases у PodSpec.

Проєкт Kubernetes рекомендує змінювати конфігурацію DNS за допомогою поля hostAliases (частина .spec Podʼа), а не за допомогою init-контейнера чи інших засобів безпосереднього редагування /etc/hosts. Зміни, внесені іншим способом, kubelet може перезаписати під час створення або перезапуску Podʼа.

Стандартний вміст файлу hosts

Запустіть Pod із Nginx, якому призначено IP-адресу Podʼа:

kubectl run nginx --image nginx

pod/nginx created

Перевірте IP-адресу Podʼа:

kubectl get pods --output=wide

NAME     READY     STATUS    RESTARTS   AGE    IP           NODE
nginx    1/1       Running   0          13s    10.200.0.4   worker0

Вміст файлу hosts виглядатиме так:

kubectl exec nginx -- cat /etc/hosts

# Kubernetes-managed hosts file.
127.0.0.1	localhost
::1	localhost ip6-localhost ip6-loopback
fe00::0	ip6-localnet
fe00::0	ip6-mcastprefix
fe00::1	ip6-allnodes
fe00::2	ip6-allrouters
10.200.0.4	nginx

Стандартно файл hosts містить лише шаблонні записи IPv4 та IPv6, такі як localhost і власне імʼя хоста.

Додавання додаткових записів за допомогою hostAliases

Крім стандартних шаблонних записів, ви можете додати до файлу hosts інші записи. Наприклад, щоб розвʼязувати foo.local, bar.local у 127.0.0.1, а foo.remote, bar.remote у 10.1.2.3, налаштуйте HostAliases для Podʼа в полі .spec.hostAliases:

service/networking/hostaliases-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: hostaliases-pod
spec:
  restartPolicy: Never
  hostAliases:
  - ip: "127.0.0.1"
    hostnames:
    - "foo.local"
    - "bar.local"
  - ip: "10.1.2.3"
    hostnames:
    - "foo.remote"
    - "bar.remote"
  containers:
  - name: cat-hosts
    image: busybox:1.28
    command:
    - cat
    args:
    - "/etc/hosts"

Ви можете запустити Pod із такою конфігурацією, виконавши:

kubectl apply -f https://k8s.io/examples/service/networking/hostaliases-pod.yaml

pod/hostaliases-pod created

Перегляньте подробиці Podʼа, щоб побачити його адресу IPv4 і статус:

kubectl get pod --output=wide

NAME                           READY     STATUS      RESTARTS   AGE       IP              NODE
hostaliases-pod                0/1       Completed   0          6s        10.200.0.5      worker0

Вміст файлу hosts виглядає так:

kubectl logs hostaliases-pod

# Kubernetes-managed hosts file.
127.0.0.1	localhost
::1	localhost ip6-localhost ip6-loopback
fe00::0	ip6-localnet
fe00::0	ip6-mcastprefix
fe00::1	ip6-allnodes
fe00::2	ip6-allrouters
10.200.0.5	hostaliases-pod

# Entries added by HostAliases.
127.0.0.1	foo.local	bar.local
10.1.2.3	foo.remote	bar.remote

з додатковими записами, вказаними внизу.

Чому kubelet керує файлом hosts?

kubelet керує файлом hosts для кожного контейнера Podʼа, щоб середовище виконання контейнерів не змінювало цей файл після запуску контейнерів. Історично Kubernetes завжди використовував Docker Engine як середовище виконання контейнерів, а Docker Engine змінював файл /etc/hosts після запуску кожного контейнера.

Поточний Kubernetes може використовувати різні середовища виконання контейнерів; попри це, kubelet керує файлом hosts у кожному контейнері, щоб результат був очікуваним незалежно від середовища виконання контейнерів, яке ви використовуєте.

2 - Переналаштування стандартного ServiceCIDR Kubernetes

У цьому документі описано, як переналаштувати стандартні діапазони IP-адрес Service, призначені кластеру.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

• iximiuz Labs
• Killercoda
• KodeKloud

Для перевірки версії введіть kubectl version.

Переналаштування стандартного ServiceCIDR Kubernetes

У цьому документі пояснено, як керувати діапазоном IP-адрес Service у кластері Kubernetes, що також впливає на сімейства IP, які кластер підтримує для Services.

Сімейства IP, доступні для ClusterIP у Service, визначаються прапорцем --service-cluster-ip-range у kube-apiserver. Щоб краще зрозуміти виділення IP-адрес Service, дивіться документацію Відстеження виділення IP-адрес Services.

Починаючи з Kubernetes 1.33, сімейства IP Service, налаштовані для кластера, відображаються в обʼєкті ServiceCIDR з назвою kubernetes. Обʼєкт ServiceCIDR kubernetes створює перший запущений екземпляр kube-apiserver на основі свого налаштованого прапорця --service-cluster-ip-range. Щоб забезпечити узгоджену поведінку кластера, усі екземпляри kube-apiserver мають бути налаштовані з однаковими значеннями --service-cluster-ip-range, які мають відповідати стандартному обʼєкту ServiceCIDR kubernetes.

Категорії переналаштування ServiceCIDR Kubernetes

Переналаштування ServiceCIDR зазвичай належить до однієї з таких категорій:

• Розширення наявних ServiceCIDR: Це можна зробити динамічно, додавши нові обʼєкти ServiceCIDR без переналаштування kube-apiserver. Дивіться окрему документацію про Розширення діапазонів IP-адрес Service.

• Перетворення з одного стека на подвійний стек зі збереженням первинного ServiceCIDR: Це передбачає додавання вторинного сімейства IP (IPv6 до кластера лише з IPv4 або IPv4 до кластера лише з IPv6) зі збереженням початкового сімейства IP як первинного. Для цього потрібно оновити конфігурацію kube-apiserver і відповідно змінити різні компоненти кластера, які мають працювати з цим додатковим сімейством IP. Серед цих компонентів, зокрема, kube-proxy, CNI або мережевий втулок, реалізації service mesh і сервіси DNS.

• Перетворення з подвійного стека на один зі збереженням первинного ServiceCIDR: Це передбачає вилучення вторинного сімейства IP з кластера з подвійним стеком і повернення до одного сімейства IP зі збереженням початкового первинного сімейства IP. Окрім переналаштування компонентів відповідно до нового сімейства IP, може знадобитися розібратися з Services, які явно налаштовані на використання вилученого сімейства IP.

• Усе, що призводить до зміни первинного ServiceCIDR: Повна заміна стандартного ServiceCIDR — складна операція. Якщо новий ServiceCIDR не перетинається з наявним, потрібно буде перенумерувати всі наявні Services і змінити Service kubernetes.default. Випадок, коли змінюється ще й первинне сімейство IP, ще складніший і може потребувати зміни кількох компонентів кластера (kubelet, мережевих втулків тощо) відповідно до нового первинного сімейства IP.

Ручні операції для заміни стандартного ServiceCIDR

Переналаштування стандартного ServiceCIDR потребує ручних дій з боку оператора кластера, адміністратора або програмного забезпечення, що керує життєвим циклом кластера. Зазвичай це такі дії:

1. Оновлення конфігурації kube-apiserver: змініть прапорець --service-cluster-ip-range, указавши нові діапазони IP.
2. Переналаштування мережевих компонентів: це критичний крок, і конкретна процедура залежить від мережевих компонентів, що використовуються. Він може охоплювати оновлення файлів конфігурації, перезапуск Podʼів агентів або оновлення компонентів для керування новими ServiceCIDR і бажаною конфігурацією сімейства IP для Podʼів. Такими компонентами можуть бути реалізація Services Kubernetes, наприклад kube-proxy, налаштований мережевий втулок і, можливо, інші мережеві компоненти, такі як контролери service mesh і сервери DNS, щоб вони могли правильно обробляти трафік і виконувати виявлення сервісів із новою конфігурацією сімейства IP.
3. Керування наявними Services: Services з IP-адресами зі старого CIDR потрібно обробити, якщо вони не входять до нових налаштованих діапазонів. Варіанти: повторне створення (що призводить до простою і призначення нових IP-адрес) або потенційно складніші стратегії переналаштування.
4. Повторне створення внутрішніх сервісів Kubernetes: Service kubernetes.default потрібно видалити й створити заново, щоб отримати IP-адресу з нового ServiceCIDR, якщо первинне сімейство IP змінено або замінено іншою мережею.

Приклад кроків переналаштування

Наведені нижче кроки описують контрольоване переналаштування з повною заміною стандартного ServiceCIDR і повторним створенням Service kubernetes.default:

1. Запустіть kube-apiserver з початковим --service-cluster-ip-range.
2. Створіть початкові Services, які отримують IP-адреси з цього діапазону.
3. Створіть новий ServiceCIDR як тимчасову ціль переналаштування.
4. Позначте стандартний ServiceCIDR kubernetes для видалення (він лишатиметься в очікуванні через наявні IP-адреси й завершувачі). Це запобігає новим виділенням зі старого діапазону.
5. Повторно створіть наявні Services. Тепер вони мають отримати IP-адреси з нового тимчасового ServiceCIDR.
6. Перезапустіть kube-apiserver із налаштованими новими ServiceCIDR і вимкніть старий екземпляр.
7. Видаліть Service kubernetes.default. Новий kube-apiserver створить його заново в новому ServiceCIDR.

Що далі

• Мережеві концепції Kubernetes
• Services Kubernetes із подвійним стеком
• Розширення діапазонів IP-адрес Service Kubernetes