Організація доступу до кластеру за допомогою файлів kubeconfig
Використовуйте файли kubeconfig для організації інформації про кластери, користувачів, простори імен та механізми автентифікації. kubectl
використовує файли kubeconfig, щоб знайти інформацію, необхідну для вибору кластера та звʼязку з сервером API кластера.
Примітка:
Файл, який використовується для налаштування доступу до кластерів, називається файлом kubeconfig. Це загальний спосіб посилання на файли конфігурації. Це не означає, що існує файл з іменемkubeconfig
.Попередження:
Використовуйте файли kubeconfig лише з надійних джерел. Використання спеціально створеного файлу kubeconfig може призвести до виконання зловмисного коду або розголошення файлів. Якщо вам все ж потрібно використовувати ненадійний файл kubeconfig, уважно перевірте його, так само як ви це зробили б з файлом скрипту оболонки.Типово kubectl
шукає файл з імʼям config
у каталозі $HOME/.kube
. Ви можете вказати інші файли kubeconfig, встановивши змінну середовища KUBECONFIG
або встановивши прапорець --kubeconfig
.
Для покрокових інструкцій щодо створення та вказівки файлів kubeconfig див. Налаштування доступу до кількох кластерів.
Підтримка кількох кластерів, користувачів та механізмів автентифікації
Припустимо, у вас є декілька кластерів, і ваші користувачі та компоненти автентифікуються різними способами. Наприклад:
- Робочий kubelet може автентифікуватися за допомогою сертифікатів.
- Користувач може автентифікуватися за допомогою токенів.
- Адміністратори можуть мати набори сертифікатів, які вони надають окремим користувачам.
За допомогою файлів kubeconfig ви можете організувати ваші кластери, користувачів та простори імен. Ви також можете визначити контексти, щоб швидко та легко перемикатися між кластерами та просторами імен.
Контекст
Елемент context в файлі kubeconfig використовується для групування параметрів доступу під зручною назвою. Кожен контекст має три параметри: кластер, простір імен та користувач. Типово, інструмент командного рядка kubectl
використовує параметри з поточного контексту для звʼязку з кластером.
Щоб обрати поточний контекст:
kubectl config use-context
Змінна середовища KUBECONFIG
Змінна середовища KUBECONFIG
містить список файлів kubeconfig. Для Linux та Mac список розділяється двокрапкою. Для Windows список розділяється крапкою з комою. Змінна середовища KUBECONFIG
не є обовʼязковою. Якщо змінна середовища KUBECONFIG
не існує, kubectl
використовує стандартний файл kubeconfig, $HOME/.kube/config
.
Якщо змінна середовища KUBECONFIG
існує, kubectl
використовує ефективну конфігурацію, яка є результатом обʼєднання файлів, перерахованих у змінній середовища KUBECONFIG
.
Обʼєднання файлів kubeconfig
Щоб переглянути вашу конфігурацію, введіть цю команду:
kubectl config view
Як описано раніше, вихідні дані можуть бути з одного файлу kubeconfig або бути результатом обʼєднання кількох файлів kubeconfig.
Ось правила, які використовує kubectl
під час обʼєднання файлів kubeconfig:
Якщо встановлено прапорець
--kubeconfig
, використовуйте лише вказаний файл. Обʼєднання не здійснюється. Дозволяється лише один екземпляр цього прапорця.У іншому випадку, якщо встановлена змінна середовища
KUBECONFIG
, використовуйте її як список файлів, які потрібно обʼєднати. Обʼєднайте файли, перераховані у змінній середовищаKUBECONFIG
, згідно з наступними правилами:- Ігноруйте порожні імена файлів.
- Виводьте помилки для файлів з вмістом, який не може бути десеріалізований.
- Перший файл, що встановлює певне значення або ключ зіставлення, має перевагу.
- Ніколи не змінюйте значення або ключ зіставлення. Наприклад: Зберігайте контекст першого файлу, який встановлює
current-context
. Наприклад: Якщо два файли вказують наred-user
, використовуйте лише значення зred-user
першого файлу. Навіть якщо другий файл має несумісні записи підred-user
, відкиньте їх.
Для прикладу встановлення змінної середовища
KUBECONFIG
дивіться Встановлення змінної середовища KUBECONFIG.В іншому випадку використовуйте стандартний файл kubeconfig,
$HOME/.kube/config
, без обʼєднання.Визначте контекст, який буде використовуватися на основі першого збігу в цьому ланцюжку:
- Використовуйте прапорець командного рядка
--context
, якщо він існує. - Використовуйте
current-context
з обʼєднаних файлів kubeconfig.
Порожній контекст допускається на цьому етапі.
- Використовуйте прапорець командного рядка
Визначте кластер та користувача. На цьому етапі може бути або не бути контексту. Визначте кластер та користувача на основі першого збігу в цьому ланцюжку, який запускається двічі: один раз для користувача та один раз для кластера:
- Використовуйте прапорці командного рядка, якщо вони існують:
--user
або--cluster
. - Якщо контекст не порожній, беріть користувача або кластер з контексту.
Користувач та кластер можуть бути порожніми на цьому етапі.
- Використовуйте прапорці командного рядка, якщо вони існують:
Визначте фактичну інформацію про кластер, яку слід використовувати. На цьому етапі може бути або не бути інформації про кластер. Побудуйте кожен елемент інформації про кластер на основі цього ланцюжка; перший збіг перемагає:
- Використовуйте прапорці командного рядка, якщо вони існують:
--server
,--certificate-authority
,--insecure-skip-tls-verify
. - Якщо існують будь-які атрибути інформації про кластер з обʼєднаних файлів kubeconfig, використовуйте їх.
- Якщо немає розташування сервера, відмовтеся.
- Використовуйте прапорці командного рядка, якщо вони існують:
Визначте фактичну інформацію про користувача, яку слід використовувати. Побудуйте інформацію про користувача, використовуючи ті ж правила, що і для інформації про кластер, за винятком того, що дозволяється лише одна техніка автентифікації для кожного користувача:
- Використовуйте прапорці командного рядка, якщо вони існують:
--client-certificate
,--client-key
,--username
,--password
,--token
. - Використовуйте поля
user
з обʼєднаних файлів kubeconfig. - Якщо є дві суперечливі техніки, відмовтеся.
- Використовуйте прапорці командного рядка, якщо вони існують:
Для будь-якої інформації, що все ще відсутня, використовуйте стандартні значення і, можливо, запитайте інформацію для автентифікації.
Посилання на файли
Посилання на файли та шляхи в файлі kubeconfig є відносними до місця розташування файлу kubeconfig. Посилання на файли в командному рядку є відносними до поточного робочого каталогу. У файлі $HOME/.kube/config
відносні шляхи зберігаються відносно, абсолютні шляхи зберігаються абсолютно.
Проксі
Ви можете налаштувати kubectl
використовувати проксі для кожного кластера за допомогою proxy-url
у вашому файлі kubeconfig, на зразок такого:
apiVersion: v1
kind: Config
clusters:
- cluster:
proxy-url: http://proxy.example.org:3128
server: https://k8s.example.org/k8s/clusters/c-xxyyzz
name: development
users:
- name: developer
contexts:
- context:
name: development