kube-proxy
Огляд
Мережевий проксі-сервер Kubernetes працює на кожному вузлі. Це відображає сервіси, визначені у Kubernetes API, на кожному вузлі і може виконувати просте перенаправлення потоків TCP, UDP і SCTP або циклічне перенаправлення TCP, UDP і SCTP через набір бекендів. Наразі IP-адреси та порти кластерів обслуговування можна знайти за допомогою сумісних з Docker-посиланнями змінні оточення, що визначають порти, відкриті проксі-сервісом. Існує надбудова яка надає кластерний DNS для цих кластерних IP-адрес. Користувач повинен створити сервіс за допомогою API apiserver, щоб налаштувати проксі.
kube-proxy [flags]
Параметри
| --add_dir_header | |
Якщо true, додає теку файлу до заголовка повідомлень логу | |
| --alsologtostderr | |
виводити лог до stderr, а також у файли (не має ефекту, якщо -logtostderr=true) | |
| --bind-address string Типово: 0.0.0.0 | |
Перевизначає уявлення kube-proxy про первинну IP-адресу вузла. Зауважте, що назва є історичним артефактом, і kube-proxy насправді не привʼязує жодних сокетів до цього IP. Цей параметр ігнорується, якщо конфігураційний файл вказано за допомогою --config. | |
| --bind-address-hard-fail | |
Якщо true, kube-proxy розцінить невдалу спробу звʼязатися з портом як фатальну і завершить роботу | |
| --cleanup | |
Якщо true, очистіть iptables та правила ipvs і вийдіть. | |
| --cluster-cidr string | |
Діапазон CIDR для Podʼів у кластері. (Для двостекових кластерів це може бути пара діапазонів CIDR, розділених комами). Коли --detect-local-mode має значення ClusterCIDR, kube-proxy вважатиме трафік локальним, якщо IP-адреса його джерела знаходиться в цьому діапазоні. (В іншому випадку він не використовується.) Цей параметр ігнорується, якщо конфігураційний файл вказано за допомогою --config. | |
| --config string | |
Шлях до файлу конфігурації. | |
| --config-sync-period duration Типово: 15m0s | |
Як часто оновлюється конфігурація з apiserver. Повинно бути більше 0. | |
| --conntrack-max-per-core int32 Типово: 32768 | |
Максимальна кількість NAT-зʼєднань для відстеження на одне ядро процесора (0 — залишити ліміт як є і ігнорувати conntrack-min). | |
| --conntrack-min int32 Типово: 131072 | |
Мінімальна кількість записів conntrack для розподілу, незалежно від conntrack-max-per-core (встановіть conntrack-max-per-core=0, щоб залишити обмеження без змін). | |
| --conntrack-tcp-be-liberal | |
Увімкніть ліберальний режим відстеження TCP-пакетів, встановивши nf_conntrack_tcp_be_liberal у 1 | |
| --conntrack-tcp-timeout-close-wait duration Типово: 1h0m0s | |
Таймаут NAT для TCP-зʼєднань у стані CLOSE_WAIT | |
| --conntrack-tcp-timeout-established duration Типово: 24h0m0s | |
Тайм-аут простою для встановлених TCP-зʼєднань (0 — залишити як є) | |
| --conntrack-udp-timeout duration | |
Тайм-аут очікування для UDP-зʼєднань без відповіді (0 — залишити як є) | |
| --conntrack-udp-timeout-stream duration | |
Тайм-аут простою для ASSURED UDP-зʼєднань (0 — залишити як є) | |
| --detect-local-mode LocalMode | |
Режим для виявлення локального трафіку. Цей параметр ігнорується, якщо конфігураційний файл вказано за допомогою --config. | |
| --feature-gates <comma-separated 'key=True|False' pairs> | |
Набір пар key=value, які описують функціональні можливостідля альфа/експериментальних функцій. Можливі варіанти: | |
| --healthz-bind-address ipport Типово: 0.0.0.0:10256 | |
IP-адреса та порт для сервера перевірки справності, стандартно "0.0.0.0:10256". Цей параметр ігнорується, якщо конфігураційний файл вказано за допомогою --config. | |
| -h, --help | |
Довідка kube-proxy | |
| --hostname-override string | |
Якщо не порожнє, буде використано як імʼя вузла, на якому запущено kube-proxy. Якщо не задано, імʼя вузла вважається таким самим, як і імʼя хоста вузла. | |
| --init-only | |
Якщо true, виконайте всі кроки ініціалізації, які необхідно виконати з повними привілеями root, а потім вийдіть. Після цього ви можете запустити kube-proxy знову, але тільки з параметром CAP_NET_ADMIN. | |
| --iptables-localhost-nodeports Типово: true | |
Якщо значення false, kube-proxy вимкне застарілу поведінку, яка дозволяла доступ до сервісів NodePort через localhost. (Стосується лише режиму iptables та IPv4; NodePort через localhost ніколи не буде дозволено в інших режимах проксі або з IPv6). | |
| --iptables-masquerade-bit int32 Типово: 14 | |
Якщо використовується режим проксі iptables або ipvs, біт простору fwmark, яким слід позначати пакети, що вимагають SNAT. Повинен знаходитися в діапазоні [0, 31]. | |
| --iptables-min-sync-period duration Типово: 1s | |
Мінімальний період між пересинхронізаціями правил iptables (наприклад, '5s', '1m', '2h22m'). Значення 0 означає, що кожна зміна Service або EndpointSlice призведе до негайного пересинхронізації iptables. | |
| --iptables-sync-period duration Типово: 30s | |
Інтервал (наприклад, '5s', '1m', '2h22m'), який вказує, як часто виконуються різні операції ресинхронізації та очищення. Має бути більше 0. | |
| --ipvs-exclude-cidrs strings | |
Список CIDR, розділених комами, які ipvs-проксі-сервер не повинен торкатися під час очищення правил IPVS. | |
| --ipvs-min-sync-period duration Типово: 1s | |
Мінімальний період між ресинхронізаціями правил IPVS (наприклад, '5s', '1m', '2h22m'). Значення 0 означає, що кожна зміна Service або EndpointSlice призведе до негайної пересинхронізації IPVS. | |
| --ipvs-scheduler string | |
Тип планувальника ipvs, якщо режим проксі — ipvs | |
| --ipvs-strict-arp | |
Увімкніть строгий ARP, встановивши arp_ignore на 1 і arp_announce на 2 | |
| --ipvs-sync-period duration Типово: 30s | |
Інтервал (наприклад, '5s', '1m', '2h22m'), який вказує, як часто виконуються різні операції ресинхронізації та очищення. Має бути більше 0. | |
| --ipvs-tcp-timeout duration | |
Тайм-аут для неактивних TCP-зʼєднань IPVS, 0 — залишити як є. (наприклад, '5s', '1m', '2h22m'). | |
| --ipvs-tcpfin-timeout duration | |
Тайм-аут для IPVS TCP-зʼєднань після отримання FIN-пакету, 0 — залишити як є. (наприклад, '5s', '1m', '2h22m'). | |
| --ipvs-udp-timeout duration | |
Таймаут для IPVS UDP-пакетів, 0 — залишити як є. (наприклад, '5s', '1m', '2h22m'). | |
| --kube-api-burst int32 Типово: 10 | |
Сплеск для використання під час спілкування з apiserver на kubernetes. | |
| --kube-api-content-type string Типово: "application/vnd.kubernetes.protobuf" | |
Тип вмісту запитів, що надсилаються до apiserver. | |
| --kube-api-qps float Типово: 5 | |
Використання QPS під час спілкування з apiserver на kubernetes | |
| --kubeconfig string | |
Шлях до файлу kubeconfig з інформацією про авторизацію (розташування master може бути перевизначено прапорцем master). | |
| --log-flush-frequency duration Типово: 5s | |
Максимальна кількість секунд між очищеннями логів | |
| --log-text-info-buffer-size quantity | |
[Alpha] У текстовому форматі з розділеними потоками виводу інформаційні повідомлення можуть буферизуватися на деякий час для підвищення продуктивності. Стандартне значення, рівне нулю байт, вимикає буферизацію. Розмір можна вказати як кількість байт (512), кратну 1000 (1K), кратну 1024 (2Ki) або степінь (3M, 4G, 5Mi, 6Gi). Увімкніть функцію LoggingAlphaOptions, щоб скористатися цією можливістю. | |
| --log-text-split-stream | |
[Alpha] У текстовому форматі записувати повідомлення про помилки до stderr та інформаційні повідомлення до stdout. Стандартно до stdout записується один потік. Увімкніть функцію LoggingAlphaOptions, щоб скористатися цією можливістю. | |
| --log_backtrace_at <рядок у вигляді 'file:N'> Типово: :0 | |
при попаданні в лог-файл рядка file:N, вивести трасування стеку | |
| --log_dir string | |
Якщо тека не порожня, записати лог-файли у цю теку (не діє, якщо -logtostderr=true). | |
| --log_file string | |
Якщо файл не порожній, використовуйте цей файл логу (не діє, якщо -logtostderr=true) | |
| --log_file_max_size uint Типово: 1800 | |
Визначає максимальний розмір, до якого може зрости файл логу (не впливає, якщо -logtostderr=true). Одиниця виміру — мегабайти. Якщо значення дорівнює 0, максимальний розмір файлу необмежений. | |
| --logging-format string Типово: "text" | |
Задає формат логу. Дозволені формати: "text". | |
| --logtostderr Типово: true | |
писати лог в standard error, а не у файл | |
| --masquerade-all | |
SNAT для всього трафіку, що надсилається через IP-кластера сервісу. Це може бути необхідним для деяких втулків CNI. Підтримується лише в Linux. | |
| --master string | |
Адреса сервера API Kubernetes (перевизначає будь-яке значення в kubeconfig). | |
| --metrics-bind-address ipport Типово: 127.0.0.1:10249 | |
IP-адреса та порт для сервера метрик, типове значення: "127.0.0.1:10249". (Встановіть значення "0.0.0.0:10249" / "[::]:10249" для привʼязки на всіх інтерфейсах). Встановіть пусте значення, щоб вимкнути. Цей параметр ігнорується, якщо конфігураційний файл вказано за допомогою --config. | |
| --nodeport-addresses strings | |
Список діапазонів CIDR, які містять допустимі IP-адреси вузлів, або, як варіант, єдиний рядок 'primary'. Якщо встановлено перелік CIDRs, зʼєднання з сервісами NodePort будуть прийматися лише з IP-адрес вузла в одному із зазначених діапазонів. Якщо встановлено значення 'primary', сервіси NodePort будуть прийматися лише на основну IP-адресу вузла згідно з обʼєктом Node. Якщо не встановлено, зʼєднання до NodePort будуть прийматися на всіх локальних IP-адресах. Цей параметр ігнорується, якщо конфігураційний файл вказано за допомогою --config. | |
| --one_output | |
Якщо значення true, записувати логи лише до їхнього власного рівня важливості (замість запису до кожного нижчого рівня важливості; немає ефекту, якщо -logtostderr=true). | |
| --oom-score-adj int32 Типово: -999 | |
Значення oom-score-adj для процесу kube-proxy. Значення має бути в діапазоні [-1000, 1000]. Цей параметр ігнорується, якщо конфігураційний файл вказано за допомогою --config. | |
| --pod-bridge-interface string | |
Імʼя інтерфейсу bridge. Коли --detect-local-mode має значення BridgeInterface, kube-proxy вважатиме трафік локальним, якщо він походить з цього мосту. | |
| --pod-interface-name-prefix string | |
Префікс імені інтерфейсу. Коли --detect-local-mode має значення InterfaceNamePrefix, kube-proxy вважатиме трафік локальним, якщо він походить з будь-якого інтерфейсу, назва якого починається з цього префікса. | |
| --profiling | |
Якщо значення true, вмикає профілювання через веб-інтерфейс у обробнику /debug/pprof. Цей параметр ігнорується, якщо конфігураційний файл вказано за допомогою --config. | |
| --proxy-mode ProxyMode | |
Режим проксі-сервера: у Linux це може бути 'iptables' (стандартно) або 'ipvs'. У Windows єдиним підтримуваним значенням є 'kernelspace'. Цей параметр ігнорується, якщо у конфігураційному файлі вказано --config. | |
| --show-hidden-metrics-for-version string | |
Попередня версія, для якої ви хочете показати приховані метрики. Значення має лише попередня мінорна версія, інші значення не будуть дозволені. Формат: <major>.<minor>, наприклад: '1.16'. Мета цього формату — переконатися, що ви маєте можливість помітити, що наступний реліз приховує додаткові метрики, а не дивуватися, коли вони назавжди вилучаються в наступному релізі. Цей параметр ігнорується, якщо конфігураційний файл вказано за допомогою --config. | |
| --skip_headers | |
Якщо true, уникати префіксів заголовків у повідомленнях логу | |
| --skip_log_headers | |
Якщо значення true, уникати заголовків при відкритті файлів логу (не впливає, якщо -logtostderr=true) | |
| --stderrthreshold int Типово: 2 | |
логи на рівні або вище цього порогу потрапляють до stderr під час запису до файлів та stderr (не впливає, якщо -logtostderr=true або -alsologtostderr=true) | |
| -v, --v int | |
число рівня деталізації логу | |
| --version version[=true] | |
--version, --version=raw виводить інформацію про версію та виходить; --version=vX.Y.Z... встановлює вказану версію | |
| --vmodule pattern=N,... | |
список параметрів pattern=N, розділених комами, для файлового фільтрування логу (працює лише для текстового формату логу). | |
| --write-config-to string | |
Якщо встановлено, записати значення стандартної конфігурації до цього файлу і вийти. | |
Цю сторінку було стоврено автоматично.
Якщо у вас є наміри надіслати пропозиції щодо неї, додайте згадку, про те що сторінку створено автоматично в описі вашого повідомлення. Зміни мають відбутись всюди в проєкті Kubernetes.