Найкращі практики

• 1: Міркування щодо великих кластерів
• 2: Запуск у кількох зонах
• 3: Перевірка налаштувань вузла
• 4: Запровадження стандартів безпеки для Podʼів
• 5: Сертифікати PKI та вимоги

1 - Міркування щодо великих кластерів

Кластер — це набір вузлів (фізичних або віртуальних машин), на яких працюють агенти Kubernetes, керовані через панель управління. Kubernetes v1.31 підтримує кластери розміром до 5,000 вузлів. Зокрема, Kubernetes розроблений для роботи з конфігураціями, які відповідають всім наступним критеріям:

• Не більше 110 Podʼів на вузол
• Не більше 5,000 вузлів
• Не більше 150,000 Podʼів загалом
• Не більше 300,000 контейнерів загалом

Ви можете масштабувати свій кластер, додаючи чи видаляючи вузли. Спосіб залежить від того, як ваш кластер розгорнутий.

Обмеження ресурсів у хмарних постачальників

Щоб уникнути проблем із квотами хмарного постачальника при створенні кластера із багатьма вузлами, розгляньте наступне:

• Запит на збільшення квоти ресурсів хмари, таких як:
  • Кількість компʼютерів
  • Центральні процесори (CPU)
  • Томи зберігання
  • Використані IP-адреси
  • Набори правил фільтрації пакетів
  • Кількість балансерів навантаження
  • Підмережі
  • Потоки логів
• Керування діями масштабування кластера для введення нових вузлів партіями, з паузою між партіями, оскільки деякі хмарні постачальники обмежують швидкість створення нових екземплярів.

Компоненти панелі управління

Для великого кластера вам потрібна панель управління з достатнім обчислювальними та іншими ресурсами.

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

Вам слід запускати принаймні один екземпляр на кожній зоні відмов для забезпечення стійкості до відмов. Вузли Kubernetes автоматично не направляють трафік до панелі управління, які знаходяться в тій же зоні відмов; однак ваш постачальник хмари може мати власні механізми для цього.

Наприклад, використовуючи керований балансувальник навантаження, ви налаштовуєте його на надсилання трафіку, який походить з kubelet та Podʼів у зоні відмови A, і направляєте цей трафік лише до хостів панелі управління, які також знаходяться в зоні A. Якщо один хост панелі управління або зона відмови точки доступу А виходить з мережі, це означає, що весь трафік панелі управління для вузлів у зоні А тепер надсилається між зонами. Запуск декількох хостів панелі управління в кожній зоні зменшує ймовірність цього результату.

Сховище etcd

Для покращення продуктивності великих кластерів ви можете зберігати обʼєкти подій в окремому відділеному екземплярі etcd.

При створенні кластера ви можете (за допомогою власних інструментів):

• запускати та налаштовувати додаткові екземплярти etcd
• налаштовувати API сервер для використання його для зберігання подій

Деталі з налаштування та управління etcd для великого кластера наведено в розділах Управління кластерами etcd для Kubernetes та Налаштування високодоступного кластера etcd за допомогою kubeadm.

Ресурси надбудов

Обмеження ресурсів Kubernetes допомагають мінімізувати вплив витоків памʼяті та інших способів, якими можуть впливати капсули та контейнери на інші компоненти. Ці обмеження ресурсів стосуються ресурсів надбудов так само як вони стосуються робочих навантажень застосунків.

Наприклад, ви можете встановити обмеження CPU та памʼяті для компонента логування:

  ...
  containers:
  - name: fluentd-cloud-logging
    image: fluent/fluentd-kubernetes-daemonset:v1
    resources:
      limits:
        cpu: 100m
        memory: 200Mi

Типові обмеження для надбудов, як правило, базуються на даних, зібраних з досвіду роботи кожної надбудови на невеликих або середніх кластерах Kubernetes. При роботі на великих кластерах надбудови часто споживають більше деяких ресурсів, ніж встановлено типовими обмеженими. Якщо великий кластер розгортати без налаштування цих значень, надбудови можуть постійно не штатно завершувати роботу через досягнення обмеження памʼяті. З іншого боку, надбудова може працювати, але з поганою продуктивністю через обмеження часу CPU.

Щоб уникнути проблем з ресурсами надбудов у кластері з багатьма вузлами, розгляньте наступне:

• Деякі надбудови масштабуються вертикально — є одна репліка надбудови для кластера чи обслуговування всієї зони відмов. Для таких надбудов збільшуйте запити та обмеження при масштабуванні вашого кластера.
• Багато надбудов масштабуються горизонтально — ви додаєте можливості, запускаючи більше Podʼів, але з дуже великим кластером вам може також знадобитися трошки збільшити обмеження CPU чи памʼяті. Vertical Pod Autoscaler може працювати в режимі recommender, щоб надати запропоновані цифри для запитів та обмежень.
• Деякі надбудови працюють як одна копія на вузол, керована DaemonSet: наприклад, агрегатор логів рівня вузла. Так само як і у випадку горизонтально масштабованих надбудов, вам може також знадобитися трошки збільшити обмеження CPU чи памʼяті.

Що далі

• VerticalPodAutoscaler — це власний ресурс, який ви можете розгортати у свій кластер, щоб допомогти управляти запитами та обмеженнями ресурсів для Podʼів. Дізнайтеся більше про Vertical Pod Autoscaler та як ви можете використовувати його для масштабування компонентів кластера, включаючи критичні для кластера надбудови.

• Автомасштабування кластера

• Надбудова Resizer допомагає автоматично змінювати розміри надбудов при зміні масштабу вашого кластера.

2 - Запуск у кількох зонах

Ця сторінка описує запуск Kubernetes у кількох зонах.

Контекст

Kubernetes створено так, що один кластер Kubernetes може працювати у кількох зонах відмов, зазвичай там, де ці зони вписуються в логічну групу, яку називають регіоном. Основні постачальники хмар визначають регіон як набір зон відмов (також називають зонами доступності), які надають однаковий набір функцій: в межах регіону кожна зона пропонує ті самі API та служби.

Типові хмарні архітектури спрямовані на мінімізацію ймовірності того, що відмова в одній зоні також призведе до порушення роботи служб в іншій зоні.

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

Усі компоненти панелі управління підтримують роботу як пул взаємозамінних ресурсів, реплікованих для кожного компонента.

При розгортанні панелі управління кластера розміщуйте репліки компонентів панелі управління в різних зонах відмов. Якщо доступність важлива, виберіть принаймні три зони відмов і реплікуйте кожен окремий компонент панелі управління (API-сервер, планувальник, etcd, менеджер контролерів кластера) принаймні в трьох зонах відмов. Якщо ви використовуєте менеджер хмарного контролера, вам також слід повторити це у всіх вибраних вами зонах відмови.

Поведінка вузла

Kubernetes автоматично розподіляє Podʼи для робочих ресурсів (таких як Deployment чи StatefulSet) по різних вузлах кластера. Це розподілення допомагає зменшити вплив відмов.

При запуску вузлів kubelet на кожному вузлі автоматично додає мітки до обʼєкта вузла який представляє цей конкретний kubelet в API Kubernetes. Ці мітки можуть включати інформацію про зону.

Якщо ваш кластер охоплює кілька зон або регіонів, ви можете використовувати мітки вузла разом з обмеженнями розподілу топології для Podʼів, щоб керувати тим, як Podʼи розподіляються по вашому кластеру серед доменів відмови: регіони, зони, і навіть конкретні вузли. Ці підказки дозволяють планувальнику розміщувати Podʼи для забезпечення кращої очікуваної доступності, зменшуючи ризик того, що пошкодження вашого навантаження вплине на весь робочий процес.

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

Розподіл вузлів по зонах

Ядро Kubernetes не створює вузли за вас; вам потрібно це зробити самостійно, або використовувати інструмент, такий як Cluster API, щоб керувати вузлами від вашого імені.

Використовуючи інструменти, такі як Cluster API, ви можете визначити набори машин, які працюватимуть як робочі вузли для вашого кластера в різних областях відмови, і правила для автоматичного відновлення кластера у разі порушення обслуговування всієї зони.

Ручне призначення зон для Podʼів

Ви можете застосовувати обмеження селектора вузла до Podʼів, які ви створюєте, а також до шаблонів Podʼів в робочих ресурсах таких як Deployment, StatefulSet або Job.

Доступ до ресурсів зберігання для зон

При створенні постійних томів, Kubernetes автоматично додає мітки зони до будь-яких PersistentVolumes, які повʼязані з конкретним зони. Потім планувальник переконується, через свій предикат NoVolumeZoneConflict, що Podʼи, які вимагають певного постійного тому, розміщуються тільки в тій самій зоні, що й цей том.

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

Ви можете вказати StorageClass для PersistentVolumeClaims, який вказує домени відмов (зони), які може використовувати сховище в цьому класі. Щоб дізнатися, як налаштувати StorageClass, який опікується доменами відмов або зонами, див. Дозволені топології.

Мережа

Сам по собі Kubernetes не містить мережі, які знається на зонах. Ви можете використовувати мережевий втулок для налаштування мережі кластера, і це мережеве рішення може мати елементи, специфічні для зони. Наприклад, якщо ваш постачальник хмари підтримує служби з type=LoadBalancer, балансир може відправляти трафік лише до Podʼів, які працюють в тій же зоні, що й елемент балансування навантаження, який обробляє ці зʼєднання. Перевірте документацію вашого постачальника хмари для отримання деталей.

Для власних або для розгортань на локальних обчислювальних ресурсах застосовуються подібні міркування. Поведінка Service та Ingress, включаючи обробку різних зон відмов, різняться залежно від того, як саме налаштований ваш кластер.

Відновлення після відмов

При налаштуванні кластера можливо вам також доведеться розглядати можливість та способи відновлення обслуговування, якщо всі зони відмов у регіоні вийдуть з ладу одночасно. Наприклад, чи ви покладаєтесь на те, що принаймні один вузол може виконувати Podʼи в зоні? Переконайтеся, що будь-які роботи з ремонту, критичні для кластера, не покладаються на те, що у вашому кластері є принаймні один справний вузол. Наприклад: якщо всі вузли несправні, вам може знадобитися запустити роботу з ремонту з особливим Toleration, щоб ремонт міг завершити роботу, щоб принаймні один вузол був в робочому стані.

Kubernetes не має відповіді на це виклик; однак це щось, що варто враховувати.

Що далі

Щоб дізнатися, як планувальник розміщує Podʼи в кластері, дотримуючись налаштованих обмежень, відвідайте Планування та Виселення.

3 - Перевірка налаштувань вузла

Тест відповідності вузла

Тест відповідності вузла — це контейнеризований тестовий фреймворк, який надає системну перевірку та тестування функціональності для вузла. Тест перевіряє, чи вузол відповідає мінімальним вимогам Kubernetes; вузол, який успішно проходить тест, має відповідати вимогам для приєднання до кластера Kubernetes.

Передумови вузла

Для запуску тесту відповідності вузла вузол повинен відповідати тим же передумовам, що й стандартний вузол Kubernetes. Принаймні, на вузлі повинні бути встановлені наступні служби:

• Сумісні з CRI середовища виконання контейнерів, такі як Docker, containerd та CRI-O
• kubelet

Запуск тесту відповідності вузла

Для запуску тесту відповідності вузла виконайте наступні кроки:

1. Визначте значення параметра --kubeconfig для kubelet, наприклад: --kubeconfig=/var/lib/kubelet/config.yaml. Оскільки тестовий фреймворк запускає локальну панель управління для тестування kubelet, використовуйте http://localhost:8080 як URL API-сервера. Є ще деякі інші параметри командного рядка kubelet, які можна використовувати:

   • --cloud-provider: Якщо ви використовуєте --cloud-provider=gce, ви повинні видалити прапорець для запуску тесту.

2. Запустіть тест відповідності вузла за допомогою команди:

   # $CONFIG_DIR — це шлях до файлу маніфеста под вашого Kubelet.
   # $LOG_DIR — це шлях для виведення результатів тесту.
   sudo docker run -it --rm --privileged --net=host \
     -v /:/rootfs -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \
     registry.k8s.io/node-test:0.2
   

Запуск тесту відповідності вузла для інших архітектур

Kubernetes також надає образи Docker для тестування відповідності вузлів для інших архітектур:

Запуск конкретних тестів

Щоб запустити конкретні тести, перезапишіть змінну середовища FOCUS регулярним виразом тестів, які ви хочете запустити.

sudo docker run -it --rm --privileged --net=host \
  -v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \
  -e FOCUS=MirrorPod \ # Запустити тільки тест MirrorPod
  registry.k8s.io/node-test:0.2

Щоб пропустити певні тести, перезапишіть змінну середовища SKIP регулярним виразом тестів, які ви хочете пропустити.

sudo docker run -it --rm --privileged --net=host \
  -v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \
  -e SKIP=MirrorPod \

 # Запустити всі тести відповідності, але пропустити тест MirrorPod
  registry.k8s.io/node-test:0.2

Тест відповідності вузла — це контейнеризована версія e2e тесту вузла. Стандартно запускаються всі тести відповідності.

Теоретично ви можете запустити будь-який e2e тест вузла, якщо налаштуєте контейнер та правильно змонтуєте необхідні томи. Але настійно рекомендується виключно використовувати тести відповідності, оскільки для запуску тестів, що не є тестами відповідності, потрібна набагато складніша конфігурація.

Обмеження

• Тест залишає на вузлі деякі образи Docker, включаючи образ тесту відповідності вузла та образи контейнерів, що використовуються у функціональному тесту.
• Тест залишає на вузлі мертві контейнери. Ці контейнери створюються під час функціонального тесту.

4 - Запровадження стандартів безпеки для Podʼів

Ця сторінка надає огляд найкращих практик щодо впровадження стандартів безпеки для Podʼів.

Використання вбудованого контролера допуску безпеки Podʼів

Контролер допуску безпеки Podʼів має на меті замінити застарілі політики безпеки Podʼів (PodSecurityPolicies).

Налаштування для всіх просторів імен кластера

Простори імен, які абсолютно не мають жодної конфігурації, повинні розглядатися як значущі прогалини в безпеці вашого кластера. Ми рекомендуємо приділити час аналізу типів робочих навантажень в кожному просторі імен і, посилаючись на стандарти безпеки Podʼів, визначити відповідний рівень для кожного з них. Простори імен без міток повинні вказувати лише на те, що їх ще не оцінено.

У сценарії, коли всі робочі навантаження у всіх просторах імен мають однакові вимоги до безпеки, ми надаємо приклад який показує, як можна застосовувати мітки безпеки для Podʼів гуртом.

Принципу найменшого доступу

У ідеальному світі кожен Pod в кожному просторі імен повинен відповідати вимогам політики restricted. Однак це або не можливо, або не практично, оскільки деякі робочі навантаження будуть вимагати підняття привілеїв з певних причин.

• Простори імен, які дозволяють робочі навантаження з піднятими привілеями, повинні встановлювати та здійснювати відповідні рівні контролю доступу.
• Для робочих навантажень, які працюють в цих дозвільних просторах імен, важливо зберігати документацію щодо їх унікальних вимог до безпеки. Якщо це можливо, розгляньте можливість подальшого обмеження цих вимог.

Використання стратегії мультимодальності

Режими audit та warn контролера впровадження стандартів безпеки Podʼів дозволяють легко збирати важливі відомості щодо безпеки ваших Podʼів без порушення поточних робочих навантажень.

Доброю практикою є включення цих режимів для всіх просторів імен, встановлюючи їх на бажаний рівень і версію, яку ви в кінцевому підсумку хочете застосувати. Попередження та аудит-анотації, створені на цьому етапі, можуть направляти вас до цього стану. Якщо ви очікуєте, що автори робочих навантажень внесуть зміни для відповідності бажаному рівню, увімкніть режим warn. Якщо ви очікуєте використання логів аудиту для моніторингу та виклику змін для відповідності бажаному рівню, включіть режим audit.

Коли режим enforce встановлено як бажаний рівень, ці режими все ще можуть бути корисними декількома різними способами:

• Встановивши warn на той самий рівень, що й enforce, клієнти отримають попередження при спробі створення Podʼів (або ресурсів, які мають шаблони Podʼів), які не проходять валідацію. Це допоможе їм оновити ці ресурси, щоб вони стали сумісними.
• В просторах імен, які закріплюють enforce за конкретною не-останньою версією, встановлення режимів audit та warn на той самий рівень, що й enforce, але на latest версію, надає видимість налаштувань, які були дозволені попередніми версіями, але не дозволяються за поточними найкращими практиками.

Альтернативи від сторонніх постачальників

В екосистемі Kubernetes розробляються інші альтернативи для впровадження профілів безпеки:

• Kubewarden.
• Kyverno.
• OPA Gatekeeper.

Вирішення вибору вбудованого рішення (наприклад, контролера допуску безпеки Podʼів) або інструменту від сторонніх постачальників цілком залежить від вашої конкретної ситуації. При оцінці будь-якого рішення довіра до вашого ланцюга постачання є критичною. В решті решт використання будь-якого з зазначених підходів буде кращим, ніж нічого.

5 - Сертифікати PKI та вимоги

Kubernetes вимагає наявності сертифікатів PKI для автентифікації за допомогою TLS. Якщо ви встановлюєте Kubernetes за допомогою kubeadm, сертифікати, необхідні для вашого кластера, генеруються автоматично. Ви також можете створити свої власні сертифікати, наприклад, щоб зберігати ваші приватні ключі більш безпечно, не зберігаючи їх на сервері API. Ця сторінка пояснює, які сертифікати необхідні для вашого кластера.

Як кластер використовує сертифікати

Kubernetes вимагає PKI для виконання таких операцій:

Сертифікати сервера

• Сертифікат сервера для точки доступу API сервера
• Сертифікат сервера для сервера etcd
• Сертифікати сервера для кожного kubelet (кожен вузол запускає kubelet)
• Опціональний сертифікат сервера для front-proxy

Сертифікати клієнта

• Сертифікати клієнта для кожного kubelet, які використовуються для автентифікації в API сервері як клієнта Kubernetes API
• Сертифікат клієнта для кожного API сервера, який використовується для автентифікації в etcd
• Сертифікат клієнта для менеджера контролерів для безпечного звʼязку з API сервером
• Сертифікат клієнта для планувальника для безпечного звʼязку з API сервером
• Сертифікати клієнтів для кожного вузла, які використовуються kube-proxy для автентифікації в API сервері
• Опціональні сертифікати клієнтів для адміністраторів кластера для автентифікації в API сервері
• Опціональний сертифікат клієнта для front-proxy

Серверні та клієнтські сертифікати Kubelet

Для встановлення безпечного зʼєднання та автентифікації у kubelet, API сервер вимагає сертифікат клієнта та пару ключів.

У цій ситуації є два підходи до використання сертифікатів:

• Спільні сертифікати: kube-apiserver може використовувати ту ж саму пару сертифікатів та ключів, яку використовує для автентифікації своїх клієнтів. Це означає, що наявні сертифікати, такі як apiserver.crt та apiserver.key, можуть використовуватися для звʼязку з серверами kubelet.

• Окремі сертифікати: Альтернативно, kube-apiserver може згенерувати новий сертифікат клієнта та пару ключів для автентифікації звʼязку з серверами kubelet. У цьому випадку створюється окремий сертифікат з назвою kubelet-client.crt та відповідний приватний ключ, kubelet-client.key.

etcd також реалізує взаємну аутентифікацію TLS для автентифікації клієнтів.

Де зберігаються сертифікати

Якщо ви встановлюєте Kubernetes за допомогою kubeadm, більшість сертифікатів зберігається в /etc/kubernetes/pki. Усі шляхи в цьому документі стосуються цієї теки, за винятком сертифікатів облікових записів користувачів, які kubeadm розміщує в /etc/kubernetes.

Налаштування сертифікатів вручну

Якщо ви не хочете, щоб kubeadm генерував необхідні сертифікати, ви можете створити їх за допомогою одного кореневого ЦС або подавши всі сертифікати. Детальні відомості щодо створення власного центра сертифікації дивіться в Сертифікати. Додаткові відомості знаходяться в розділі Управління сертифікатами з kubeadm.

Один кореневий ЦС

Ви можете створити один кореневий ЦС, яким керує адміністратор. Цей кореневий ЦС може створювати кілька проміжних ЦС та делегувати весь подальший процес створення Kubernetes.

Необхідні ЦС:

На додачу до цих ЦС також необхідно отримати пару ключ/сертифікат для управління обліковими записами служби, sa.key та sa.pub. Наведений нижче приклад ілюструє файли ключа та сертифіката ЦС, показані в попередній таблиці:

/etc/kubernetes/pki/ca.crt
/etc/kubernetes/pki/ca.key
/etc/kubernetes/pki/etcd/ca.crt
/etc/kubernetes/pki/etcd/ca.key
/etc/kubernetes/pki/front-proxy-ca.crt
/etc/kubernetes/pki/front-proxy-ca.key

Усі сертифікати

Якщо ви не хочете копіювати приватні ключі ЦС до свого кластера, ви можете створити всі сертифікати самостійно.

Необхідні сертифікати:

де kind посилається на один або кілька ключів x509, які також документовані в .spec.usages типу CertificateSigningRequest:

Шляхи до сертифікатів

Сертифікати повинні бути розміщені в рекомендованому шляху (який використовує kubeadm). Шляхи повинні бути вказані за вказаним аргументом незалежно від місця розташування.

Ті ж самі вимоги стосуються пари ключів облікових записів служби:

Наведений нижче приклад ілюструє повні шляхи до файлів, перерахованих в попередній таблиці:

/etc/kubernetes/pki/etcd/ca.key
/etc/kubernetes/pki/etcd/ca.crt
/etc/kubernetes/pki/apiserver-etcd-client.key
/etc/kubernetes/pki/apiserver-etcd-client.crt
/etc/kubernetes/pki/ca.key
/etc/kubernetes/pki/ca.crt
/etc/kubernetes/pki/apiserver.key
/etc/kubernetes/pki/apiserver.crt
/etc/kubernetes/pki/apiserver-kubelet-client.key
/etc/kubernetes/pki/apiserver-kubelet-client.crt
/etc/kubernetes/pki/front-proxy-ca.key
/etc/kubernetes/pki/front-proxy-ca.crt
/etc/kubernetes/pki/front-proxy-client.key
/etc/kubernetes/pki/front-proxy-client.crt
/etc/kubernetes/pki/etcd/server.key
/etc/kubernetes/pki/etcd/server.crt
/etc/kubernetes/pki/etcd/peer.key
/etc/kubernetes/pki/etcd/peer.crt
/etc/kubernetes/pki/etcd/healthcheck-client.key
/etc/kubernetes/pki/etcd/healthcheck-client.crt
/etc/kubernetes/pki/sa.key
/etc/kubernetes/pki/sa.pub

Налаштування сертифікатів для облікових записів користувачів

Ви повинні вручну налаштувати ці облікові записи адміністратора та службові облікові записи:

1. Для кожної конфігурації створіть пару ключ/сертифікат x509 із зазначеними Common Name (CN) та Organization (O).

2. Виконайте команду kubectl для кожної конфігурації наступним чином:

KUBECONFIG=<filename> kubectl config set-cluster default-cluster --server=https://<host ip>:6443 --certificate-authority <path-to-kubernetes-ca> --embed-certs
KUBECONFIG=<filename> kubectl config set-credentials <credential-name> --client-key <path-to-key>.pem --client-certificate <path-to-cert>.pem --embed-certs
KUBECONFIG=<filename> kubectl config set-context default-system --cluster default-cluster --user <credential-name>
KUBECONFIG=<filename> kubectl config use-context default-system

Ці файли використовуються наступним чином:

Наведені нижче файли ілюструють повні шляхи до файлів, перерахованих у попередній таблиці:

/etc/kubernetes/admin.conf
/etc/kubernetes/super-admin.conf
/etc/kubernetes/kubelet.conf
/etc/kubernetes/controller-manager.conf
/etc/kubernetes/scheduler.conf