Http порт: , , , , Red Hat Enterprise Linux, RHCSA, RHCE, RHCE RHCSA, Red Hat Certified System Administrator, Red Hat Certified Engineer, , ,

Содержание

Порт HTTP и HTTPS — CodeRoad



Я создал приложение J2EE, которое работает с включенными GlassFish, HTTPS. Когда пользователь наберет http://www.mydomain.com: 8080/app, он будет перенаправлен на https: / / www.mydomain.com: 8181/app/login.

Однако, когда я вижу на некоторых сайтах, он действительно может перенаправляться на что-то вроде https: //www.mydomain.com/app/login (без порта HTTPS 8181). Означает ли это, что сервер работает как HTTP, так и HTTPS на порту 80?

Как настроить это на GlassFish 3.1?

glassfish-3
Поделиться Источник user851110     28 июля 2011 в 13:18

4 ответа

  • https и http, оба прослушивают порт 80 на appfog

    В моем локальном сервере apache2 http прослушивает порт 80, а https — порт 443 Но на appfog, http и https оба прослушивают порт 80, из-за которого я сталкиваюсь The webpage has a redirect loop on google chrome. Кто-нибудь поможет?

  • Файл Nginx conf: перенаправление с поддомена HTTP на порт HTTPS

    Я совершенно новичок в Nginx и установил новую установку с Ajenti на порт 8000. Я ищу точку поддомена в Адженти, которая является HTTPS, но не использую HTTPS где-либо еще на сайте. Так что все эти вещи случаются: http://domain1.co.uk http://sub.domain1.co.uk -> https://sub.domain1.co.uk…


11

Некорневой пользователь не должен использовать порты ниже 1024. Лучше сделать переадресацию портов с 80 на 8080 и с 443 (по умолчанию https) на 8181.

Выполните это как root:

iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -t nat -A PREROUTING -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 8080
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -t nat -A PREROUTING -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 8181

Нужно сделать это постоянным:

iptables-save -c > /etc/iptables.rules
iptables-restore < /etc/iptables.rules

и позвоните во время запуска, vi /etc/network/if-pre-up.d/iptablesload

#!/bin/sh
iptables-restore < /etc/iptables.rules
exit 0

Поделиться javadude     25 марта 2013 в 04:31


4

Вы также можете настроить его в веб-интерфейсе администратора в разделе:
Configuration -> Server Config -> Network Config -> Network Listeners

Поделиться alexblum     28 июля 2011 в 13:27


3

Просто, чтобы дать более подробную информацию об ответе alexblum, когда вы войдете в админ-панель Glassfish, перейдите в

Configurations -> server-config -> Network Listeners in Network Config .

  1. Затем нажмите кнопку Создать, чтобы добавить нового слушателя.
  2. На странице новый прослушиватель просто выберите 80 в качестве порта и поместите 0.0.0.0 в качестве IP.
  3. Выберите tcp в качестве транспорта и используйте http-thread-pool в качестве пула потоков
  4. Сохраните и перезапустите экземпляр Glassfish.

В любом случае, это сработало для меня.

Поделиться janex     12 декабря 2012 в 20:28

Поделиться Pindatjuh     28 июля 2011 в 13:19

Похожие вопросы:


Порт Grails https закрывает приложение

Запустив приложение grails с grails 2.4, я указываю порт сервера и порты https (9191 и 9192 соответственно) в команде run-app: grails -Dgrails.env=dev -Dgrails.server.port.http=9191…


Переключение протокола HTTP/HTTPS

Я хотел бы найти решение для переключения между протоколом HTTP и HTTPS на сервере PHP, и это решение должно работать как из локальной сети, так и из сети Интернет. Схема : DNS: domain.com IP:…


Задачу с перенаправлением http для https

В ISS 7.5 у меня было 2 привязки: Тип: http IP: 127.0.0.1 Порт: 80 Тип: https IP: 127.0.0.1 Порт: 443 и я с помощью этого кода перенаправляю http на https: (код в файле Global.asax.cs) if…


https и http, оба прослушивают порт 80 на appfog

В моем локальном сервере apache2 http прослушивает порт 80, а https — порт 443 Но на appfog, http и https оба прослушивают порт 80, из-за которого я сталкиваюсь The webpage has a redirect loop on…


Файл Nginx conf: перенаправление с поддомена HTTP на порт HTTPS

Я совершенно новичок в Nginx и установил новую установку с Ajenti на порт 8000. Я ищу точку поддомена в Адженти, которая является HTTPS, но не использую HTTPS где-либо еще на сайте. Так что все эти…


Как отличить http и https по http-заголовку

Я пишу прокси с TcpListener в C#. Этот прокси-сервер прослушивает порт, на который пользователи отправляют запрос. А когда будет принят запрос пользователя, он проанализирует заголовок запроса и…


Nodejs HTTP и HTTPS через один и тот же порт

Я гуглил и искал здесь stackoverflow, но не могу найти ответа, который мне нравится 😉 У меня есть сервер NodeJS, который работает над HTTPS и портом 3001. Теперь я хотел бы получить все входящие…


Перенаправление HTTP > HTTPS, когда порт всегда 80

Наше приложение должно перенаправить HTTP запросов на HTTPS . Обычно я бы использовал RewriteCond , как показано ниже. RewriteCond %{HTTPS} off Дело в том, что наша нынешняя хостинговая компания…


Перенаправление http на https, порт 80 используется другой службой

У меня есть apache (httpd), обслуживающий мой сайт, с включенным SSL (на https, порт 443). Кроме того, на том же сервере у меня есть отдельный процесс, который использует порт 80. Теперь я хочу…


Перенаправление http на https при блокировке порта http

У нас есть веб-приложение java, работающее в Apache Tomact 8.0.36. Настроен HTTP порт 80 и HTTPS порт 443. Перенаправление на HTTPS настроено в web.xml, как показано ниже, и оно работало нормально:…

Не удается найти страницу | Autodesk Knowledge Network

(* {{l10n_strings.REQUIRED_FIELD}})

{{l10n_strings.CREATE_NEW_COLLECTION}}*

{{l10n_strings.ADD_COLLECTION_DESCRIPTION}}

{{l10n_strings.COLLECTION_DESCRIPTION}} {{addToCollection.description.length}}/500 {{l10n_strings.TAGS}} {{$item}} {{l10n_strings.PRODUCTS}} {{l10n_strings.DRAG_TEXT}}  

{{l10n_strings.DRAG_TEXT_HELP}}

{{l10n_strings.LANGUAGE}} {{$select.selected.display}}

{{article.content_lang.display}}

{{l10n_strings.AUTHOR}}  

{{l10n_strings.AUTHOR_TOOLTIP_TEXT}}

{{$select.selected.display}} {{l10n_strings.CREATE_AND_ADD_TO_COLLECTION_MODAL_BUTTON}} {{l10n_strings.CREATE_A_COLLECTION_ERROR}}

linux — Доступ по http (80 порт) Ubuntu, apache

Добрый день

Установил на виртуальный сервер (OS: ubuntu, VPS: amazon AWS) apache. В iptables 80 порт открыт. Так же исходящие пакеты уходят корректно. При попытке зайти на хост — ничего не происходит. Помогите, пожалуйста.

Информация:

Раз

root@ip-172-31-17-173:/var/www# nmap -sS -p 80 ya.ru

Starting Nmap 6.40 ( http://nmap.org ) at 2015-11-15 11:54 UTC
Nmap scan report for ya.ru (93.158.134.3)
Host is up (0.19s latency).
Other addresses for ya.ru (not scanned): 213.180.193.3 213.180.204.3
rDNS record for 93.158.134.3: www.yandex.ru
PORT   STATE SERVICE
80/tcp open  http
Nmap done: 1 IP address (1 host up) scanned in 2.38 seconds

Два

root@ip-172-31-17-173:/var/www# netstat -anp | grep :80
tcp6       0      0 :::8080                 :::*                    LISTEN          9339/tnslsnr
tcp6       0      0 :::80                   :::*                    LISTEN      9498/apache2

Правила на input

root@ip-172-31-17-173:/var/www# iptables -L INPUT -n -v
pkts bytes target     prot opt in     out     source               destination
0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:1521
0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80

Статус apache:

root@ip-172-31-17-173:/var/www# apachectl status
Apache Server Status for localhost (via 127.0.0.1)

Server Version: Apache/2.4.7 (Ubuntu)
Server MPM: event
Server Built: Oct 14 2015 14:20:21

-------------------------------------------------------------------------------

Current Time: Sunday, 15-Nov-2015 12:06:15 UTC
Restart Time: Sunday, 15-Nov-2015 11:49:03 UTC
Parent Server Config. Generation: 4
Parent Server MPM Generation: 3
Server uptime: 17 minutes 11 seconds
Server load: 0.00 0.01 0.05
Total accesses: 1 - Total Traffic: 1 kB
CPU Usage: u0 s0 cu0 cs0

.00097 requests/sec — 0 B/second — 1024 B/request 1 requests currently being processed, 49 idle workers

 PID    Connections    Threads       Async connections
      total accepting busy idle writing keep-alive closing
11716 0     yes       0    25   0       0          0
11717 0     yes       1    24   0       0          0
Sum   0               1    49   0       0          0

______________________________W___________________..............
................................................................
......................

Scoreboard Key:
"_" Waiting for Connection, "S" Starting up, "R" Reading Request,
"W" Sending Reply, "K" Keepalive (read), "D" DNS Lookup,
"C" Closing connection, "L" Logging, "G" Gracefully finishing,

HTTPS, Socks4, Socks5, txt-экспорт ip-port и API-доступ — hidemy.name

Прокси нужны, когда применение VPN либо невозможно, либо неудобно. Например, для массовых действий сразу с множества IP-адресов: парсинга, увеличения просмотров, посещений, снятия лимитов онлайн-сервисов на количество обращений и другие.

Прокси из нашего листа не принадлежат нам. Их собирает автоматически «робот-паук» с тысяч разных сайтов в интернете, в том числе с закрытых форумов и даже некоторых приватных баз прокси.

Обратите внимание, что это не наши собственные прокси, поэтому мы не можем отвечать за их работоспособность и стабильность, а лишь показываем статус на момент проверки. В правом столбце списка указано, как давно была проверка.

Все proxy-серверы из списка проверяются и сортируются по различным параметрам.

Например, от типа прокси зависит, каким образом вы сможете его использовать. Вот какие типы бывают:

  • HTTP: обычные прокси, поддерживающие HTTP запросы. С ними можно просматривать сайты и скачивать файлы по HTTP-протоколу.
  • HTTPS: также их называют прокси-серверами с поддержкой SSL. Позволяют просматривать HTTPS сайты. С помощью специализированных программ их можно использовать для любого протокола, как SOCKS прокси-серверы.
  • Socks 4: прокси поддерживающие socks протокол 4 версии. С их помощью можно соединяться по TCP/IP протоколу с любым адресом и портом. Подходят для Telegram.
  • Socks 5: включает все возможности 4-й версии, а дополнительно можно использовать UDP протокол, делать DNS запросы через прокси, а также использовать метод BIND, чтобы открыть порт для входящих соединений. Также подойдут для использования в мессенджере Телеграм.

Анонимность прокси — очень важный параметр. От этого зависит, будет ли скрыт ваш реальный адрес и не заподозрит ли конечный сервер то, что вы используете прокси.

Категории анонимности, которые есть в нашем прокси-листе:

  • Нет анонимности: удалённый сервер знает ваш IP, и знает, что вы используете прокси.
  • Низкая анонимность: удалённый сервер не знает ваш IP, но знает, что вы используете прокси.
  • Средняя анонимность: удалённый сервер знает, что вы используете прокси, и думает, что знает ваш IP, но он не ваш (это обычно многосетевые прокси, показывающие удалённому серверу входящий интерфейс как REMOTE_ADDR).
  • Высокая анонимность: удалённый сервер не знает ваш IP, и у него нет прямых доказательств, что вы используете прокси. То есть нет заголовков из семейства прокси-информации. Это анонимные прокси.

Скорость обозначена в миллисекундах, но это не пинг, а с какой скоростью через прокси удалось загрузить небольшой тестовый файл. Проще всего ориентироваться на цвет полоски: зеленый — быстро, красный — медленно.

Пинг же будет варьироваться. Если для вас это важный параметр, то его лучше проверять прямо с того устройства, где будет использован proxy.

Для обладателей платной подписки доступна выгрузка proxy-list в форматах txt и csv, а также API-доступ. Доступ к API можно запросить у техподдержки.

HTTP 1.0 | Протокол HTTP

HTTP – текстовый протокол, с помощью которого взаимодействуют клиент, например, браузер и сервер. Работает это так. Пользователь шлёт определенный запрос на сервер, запрашивая или передавая нужные данные, а сервер, в зависимости от запроса, выполняет нужную логику и возвращает результат, обычно это HTML-страница либо редирект.

Для того, чтобы посмотреть, как работает HTTP, мы сделаем запрос к серверу google и разберём, как он выглядит. Для этого используется специальная утилита, которая называется telnet (пример HTTP-запроса, выполненного с помощью утилиты telnet).

# Передаем адрес сайта и указываем tcp порт
# После этого происходит подключение к серверу по протоколу tcp
$ telnet google.com 80

HTTP – протокол прикладного уровня. Другими словами, он предназначен для общения между двумя программами (клиентом и сервером), находящимися на разных компьютерах. Но, сам по себе, HTTP не может соединять два удаленных компьютера. Для этого используются другие протоколы, среди которых TCP. Именно TCP позволяет соединить программы на удаленных компьютерах, создав канал для общения друг с другом. Для этого нужно знать два параметра: ip-адрес компьютера, к которому нужно подключиться, и порт, на котором «висит» нужная программа.

Команда telnet выше делает именно это, она выполняет соединение по TCP и только после этого входит в режим взаимодействия по HTTP. При условии, что указан правильный ip-адрес и порт для соединения. И на этом моменте возникает два вопроса:

Мы передали адрес сайта, откуда берется ip-адрес? Любой адрес сайта это просто имя, за которым скрывается ip-адрес.]’.

После подключения веб-сервер входит в режим ожидания http-запроса. Осталось его послать.

Что из себя представляет сам запрос?

Запрос состоит из нескольких частей. Первая часть — request line. Вторая — заголовки.

В request line мы указываем специальное слово, ещё говорят глагол. В HTTP описаны разные глаголы, но мы сейчас не будем вдаваться в подробности. Просто скажем, что они определяют, как реагировать на этот запрос. И в данном случае мы будем использовать глагол HEAD. Он очень простой, и просит сервер отдать только заголовки, без содержимого. Более распространённым является GET. Именно с помощью GET мы запрашиваем содержимое сайта.

После глагола указывается строка запроса query string. Если мы указываем /, это обозначает просто корень сайта. Дальше всё, что нужно сделать, это указать название протокола и его версию. В этом курсе рассматриваются только версии HTTP 1.0 и 1.1, это основа протокола и знакомство с ним стоит начинать именно c них. Между версиями есть принципиальные отличия, которые нужно хорошо знать и понимать. Версия 1.0 продолжает использоваться в различных целях утилитами командной строки.

В принципе этого достаточно, и для 1.0 больше ничего делать не нужно:

HEAD / HTTP/1.0

Дальше идут заголовки. Что это? Заголовки позволяют передавать дополнительную информацию, например браузеры предоставляют информацию о себе, чтобы было понятно откуда идет запрос. Кроме этого они указывают какие форматы сжатия поддерживают, в каком формате готовы принимать ответ и так далее. Количество стандартных заголовков достаточно большое, помимо них можно добавлять любые свои.

Давайте рассмотрим, как выглядят заголовки. Мы указываем имя и через двоеточие какое-то значение: refer: value. Заголовки часто указывают заглавными буквами, но регистр здесь не важен. Порядок заголовков также не специфицирован. В каком бы порядке мы не передали заголовки, тело ответа будет разбираться только всё вместе.

Браузерами используется много заголовков, например user-agent. Этот заголовок используется для аналитики, а также, когда необходимо адаптировать страницы сайта под разные экраны или браузеры. Но и без него все должно работать:

HEAD / HTTP/1.0
User-Agent: google сhrome

Важно помнить, поскольку это протокол, и у него есть определенные правила, то нарушать их нельзя. HTTP — текстовый протокол. Все правила основаны на простых соглашениях. Например, несколько заголовков отделяются друг от друга переводом строки (и никак иначе!). Мы не можем записать их в одну строку, через запятую или как-то ещё. Всё очень строго. А каким образом сервер поймёт, что вы закончили передавать данные? Это должен быть какой-то маркер, определитель. В HTTP это делается с помощью двух переводов строки. После этого сервер считает что все данные были отправлены и больше данных не будет. То есть фактически два перевода строки (перевод после последнего заголовка и пустая строка) приводят к отправке данных.]’. HEAD / HTTP/1.0 HTTP/1.0 200 OK Date: Sat, 18 Jan 2020 09:24:50 GMT Expires: -1 Cache-Control: private, max-age=0 Content-Type: text/html; charset=ISO-8859-1 P3P: CP=»This is not a P3P policy! See g.co/p3phelp for more info.» Server: gws X-XSS-Protection: 0 X-Frame-Options: SAMEORIGIN Set-Cookie: 1P_JAR=2020-01-18-09; expires=Mon, 17-Feb-2020 09:24:50 GMT; path=/; domain=.google.com; Secure Set-Cookie: NID=196=wsHLMAMfnAaSyF7zduokI8TJeE5UoIKPHYC58HYH93VMnev9Nc2bAjhRdzoc4UhmuOd7ZVCorDnzGDe51yPefsRMeVyOFnYdHYYgQNqI8A1dYuk4pDK4OJurQgL4lX8kiNGSNi_kkUESFQ-MqLCB_YspxA9JRejhZdkTRtGyHNk; expires=Sun, 19-Jul-2020 09:24:50 GMT; path=/; domain=.google.com; HttpOnly Accept-Ranges: none Vary: Accept-Encoding Connection closed by foreign host.

В ответ к нам приходит response. Он состоит из status line HTTP/1.0 200 OK. Это строка ответа, в которой указан протокол (здесь он совпадает) и статус ответа 200 OK. В HTTP определено множество различных статусов (400, 500 и т.д.). Они могут информировать, что информация была не найдена, были ошибки на сервере и т.д. Все статусы имеют мнемоническое название, которое передается так же последним значением. 200 и OK обозначает, что всё прошло хорошо — success!

Далее выводится большое количество различных заголовков. В них нет ничего сложного, и их не нужно все учить (есть какие-то общие, и они достаточно понятны). Все заголовки состоят из ключа, двоеточия и значения. Можно заметить, что есть вещи связанные с кодировкой, кешированием. Некоторые заголовки специфичны для текущего сервера. Например, X-XSS-Protection: 0, где X указывает на кастомный заголовок. Но никакой веб-сервер, никакой веб-браузер не будут ломаться при посылке таких дополнительных заголовков.

Именно в HTTP 1.0 в конце после получения данных происходит закрытие соединения.

Простым языком об HTTP / Хабр

Вашему вниманию предлагается описание основных аспектов протокола HTTP — сетевого протокола, с начала 90-х и по сей день позволяющего вашему браузеру загружать веб-страницы. Данная статья написана для тех, кто только начинает работать с компьютерными сетями и заниматься разработкой сетевых приложений, и кому пока что сложно самостоятельно читать официальные спецификации.

HTTP — широко распространённый протокол передачи данных, изначально предназначенный для передачи гипертекстовых документов (то есть документов, которые могут содержать ссылки, позволяющие организовать переход к другим документам).

Аббревиатура HTTP расшифровывается как HyperText Transfer Protocol, «протокол передачи гипертекста». В соответствии со спецификацией OSI, HTTP является протоколом прикладного (верхнего, 7-го) уровня. Актуальная на данный момент версия протокола, HTTP 1.1, описана в спецификации RFC 2616.

Протокол HTTP предполагает использование клиент-серверной структуры передачи данных. Клиентское приложение формирует запрос и отправляет его на сервер, после чего серверное программное обеспечение обрабатывает данный запрос, формирует ответ и передаёт его обратно клиенту. После этого клиентское приложение может продолжить отправлять другие запросы, которые будут обработаны аналогичным образом.

Задача, которая традиционно решается с помощью протокола HTTP — обмен данными между пользовательским приложением, осуществляющим доступ к веб-ресурсам (обычно это веб-браузер) и веб-сервером. На данный момент именно благодаря протоколу HTTP обеспечивается работа Всемирной паутины.

Также HTTP часто используется как протокол передачи информации для других протоколов прикладного уровня, таких как SOAP, XML-RPC и WebDAV. В таком случае говорят, что протокол HTTP используется как «транспорт».

API многих программных продуктов также подразумевает использование HTTP для передачи данных — сами данные при этом могут иметь любой формат, например, XML или JSON.

Как правило, передача данных по протоколу HTTP осуществляется через TCP/IP-соединения. Серверное программное обеспечение при этом обычно использует TCP-порт 80 (и, если порт не указан явно, то обычно клиентское программное обеспечение по умолчанию использует именно 80-й порт для открываемых HTTP-соединений), хотя может использовать и любой другой.

Как отправить HTTP-запрос?

Самый простой способ разобраться с протоколом HTTP — это попробовать обратиться к какому-нибудь веб-ресурсу вручную. Представьте, что вы браузер, и у вас есть пользователь, который очень хочет прочитать статьи Анатолия Ализара.

Предположим, что он ввёл в адресной строке следующее:

http://alizar.habrahabr.ru/

Соответственно вам, как веб-браузеру, теперь необходимо подключиться к веб-серверу по адресу alizar.habrahabr.ru.

Для этого вы можете воспользоваться любой подходящей утилитой командной строки. Например, telnet:

telnet alizar.habrahabr.ru 80

Сразу уточню, что если вы вдруг передумаете, то нажмите Ctrl + «]», и затем ввод — это позволит вам закрыть HTTP-соединение. Помимо telnet можете попробовать nc (или ncat) — по вкусу.

После того, как вы подключитесь к серверу, нужно отправить HTTP-запрос. Это, кстати, очень легко — HTTP-запросы могут состоять всего из двух строчек.

Для того, чтобы сформировать HTTP-запрос, необходимо составить стартовую строку, а также задать по крайней мере один заголовок — это заголовок Host, который является обязательным, и должен присутствовать в каждом запросе. Дело в том, что преобразование доменного имени в IP-адрес осуществляется на стороне клиента, и, соответственно, когда вы открываете TCP-соединение, то удалённый сервер не обладает никакой информацией о том, какой именно адрес использовался для соединения: это мог быть, например, адрес alizar.habrahabr.ru, habrahabr.ru или m.habrahabr.ru — и во всех этих случаях ответ может отличаться. Однако фактически сетевое соединение во всех случаях открывается с узлом 212.24.43.44, и даже если первоначально при открытии соединения был задан не этот IP-адрес, а какое-либо доменное имя, то сервер об этом никак не информируется — и именно поэтому этот адрес необходимо передать в заголовке Host.

Стартовая (начальная) строка запроса для HTTP 1.1 составляется по следующей схеме:

Метод URI HTTP/Версия

Например (такая стартовая строка может указывать на то, что запрашивается главная страница сайта):

GET / HTTP/1.1

Метод (в англоязычной тематической литературе используется слово method, а также иногда слово verb — «глагол») представляет собой последовательность из любых символов, кроме управляющих и разделителей, и определяет операцию, которую нужно осуществить с указанным ресурсом. Спецификация HTTP 1.1 не ограничивает количество разных методов, которые могут быть использованы, однако в целях соответствия общим стандартам и сохранения совместимости с максимально широким спектром программного обеспечения как правило используются лишь некоторые, наиболее стандартные методы, смысл которых однозначно раскрыт в спецификации протокола.

URI (Uniform Resource Identifier, унифицированный идентификатор ресурса) — путь до конкретного ресурса (например, документа), над которым необходимо осуществить операцию (например, в случае использования метода GET подразумевается получение ресурса). Некоторые запросы могут не относиться к какому-либо ресурсу, в этом случае вместо URI в стартовую строку может быть добавлена звёздочка (астериск, символ «*»). Например, это может быть запрос, который относится к самому веб-серверу, а не какому-либо конкретному ресурсу. В этом случае стартовая строка может выглядеть так:

OPTIONS * HTTP/1.1

Версия определяет, в соответствии с какой версией стандарта HTTP составлен запрос. Указывается как два числа, разделённых точкой (например 1.1).

Для того, чтобы обратиться к веб-странице по определённому адресу (в данном случае путь к ресурсу — это «/»), нам следует отправить следующий запрос:

GET / HTTP/1.1
Host: alizar.habrahabr.ru

При этом учитывайте, что для переноса строки следует использовать символ возврата каретки (Carriage Return), за которым следует символ перевода строки (Line Feed). После объявления последнего заголовка последовательность символов для переноса строки добавляется дважды.

Впрочем, в спецификации HTTP рекомендуется программировать HTTP-сервер таким образом, чтобы при обработке запросов в качестве межстрочного разделителя воспринимался символ LF, а предшествующий символ CR, при наличии такового, игнорировался. Соответственно, на практике бо́льшая часть серверов корректно обработает и такой запрос, где заголовки отделены символом LF, и он же дважды добавлен после объявления последнего заголовка.

Если вы хотите отправить запрос в точном соответствии со спецификацией, можете воспользоваться управляющими последовательностями \r и \n:

echo -en "GET / HTTP/1.1\r\nHost: alizar.habrahabr.ru\r\n\r\n" | ncat alizar.habrahabr.ru 80

Как прочитать ответ?

Стартовая строка ответа имеет следующую структуру:

HTTP/Версия Код состояния Пояснение

Версия протокола здесь задаётся так же, как в запросе.

Код состояния (Status Code) — три цифры (первая из которых указывает на класс состояния), которые определяют результат совершения запроса. Например, в случае, если был использован метод GET, и сервер предоставляет ресурс с указанным идентификатором, то такое состояние задаётся с помощью кода 200. Если сервер сообщает о том, что такого ресурса не существует — 404. Если сервер сообщает о том, что не может предоставить доступ к данному ресурсу по причине отсутствия необходимых привилегий у клиента, то используется код 403. Спецификация HTTP 1.1 определяет 40 различных кодов HTTP, а также допускается расширение протокола и использование дополнительных кодов состояний.

Пояснение к коду состояния (Reason Phrase) — текстовое (но не включающее символы CR и LF) пояснение к коду ответа, предназначено для упрощения чтения ответа человеком. Пояснение может не учитываться клиентским программным обеспечением, а также может отличаться от стандартного в некоторых реализациях серверного ПО.

После стартовой строки следуют заголовки, а также тело ответа. Например:

HTTP/1.1 200 OK
Server: nginx/1.2.1
Date: Sat, 08 Mar 2014 22:53:46 GMT
Content-Type: application/octet-stream
Content-Length: 7
Last-Modified: Sat, 08 Mar 2014 22:53:30 GMT
Connection: keep-alive
Accept-Ranges: bytes

Wisdom

Тело ответа следует через два переноса строки после последнего заголовка. Для определения окончания тела ответа используется значение заголовка

Content-Length

(в данном случае ответ содержит 7 восьмеричных байтов: слово «Wisdom» и символ переноса строки).

Но вот по тому запросу, который мы составили ранее, веб-сервер вернёт ответ не с кодом 200, а с кодом 302. Таким образом он сообщает клиенту о том, что обращаться к данному ресурсу на данный момент нужно по другому адресу.

Смотрите сами:

HTTP/1.1 302 Moved Temporarily
Server: nginx
Date: Sat, 08 Mar 2014 22:29:53 GMT
Content-Type: text/html
Content-Length: 154
Connection: keep-alive
Keep-Alive: timeout=25
Location: http://habrahabr.ru/users/alizar/

<html>
<head><title>302 Found</title></head>
<body bgcolor="white">
<center><h2>302 Found</h2></center>
<hr><center>nginx</center>
</body>
</html>

В заголовке Location передан новый адрес. Теперь URI (идентификатор ресурса) изменился на /users/alizar/, а обращаться нужно на этот раз к серверу по адресу habrahabr.ru (впрочем, в данном случае это тот же самый сервер), и его же указывать в заголовке Host.

То есть:

GET /users/alizar/ HTTP/1.1
Host: habrahabr.ru

В ответ на этот запрос веб-сервер Хабрахабра уже выдаст ответ с кодом 200 и достаточно большой документ в формате HTML.

Если вы уже успели вжиться в роль, то можете теперь прочитать полученный от сервера HTML-код, взять карандаш и блокнот, и нарисовать профайл Ализара — в принципе, именно этим бы на вашем месте браузер сейчас и занялся.

А что с безопасностью?

Сам по себе протокол HTTP не предполагает использование шифрования для передачи информации. Тем не менее, для HTTP есть распространённое расширение, которое реализует упаковку передаваемых данных в криптографический протокол

SSL

или

TLS

.

Название этого расширения — HTTPS (HyperText Transfer Protocol Secure). Для HTTPS-соединений обычно используется TCP-порт 443. HTTPS широко используется для защиты информации от перехвата, а также, как правило, обеспечивает защиту от атак вида man-in-the-middle — в том случае, если сертификат проверяется на клиенте, и при этом приватный ключ сертификата не был скомпрометирован, пользователь не подтверждал использование неподписанного сертификата, и на компьютере пользователя не были внедрены сертификаты центра сертификации злоумышленника.

На данный момент HTTPS поддерживается всеми популярными веб-браузерами.

А есть дополнительные возможности?

Протокол HTTP предполагает достаточно большое количество возможностей для расширения. В частности, спецификация HTTP 1.1 предполагает возможность использования заголовка Upgrade для переключения на обмен данными по другому протоколу. Запрос с таким заголовком отправляется клиентом. Если серверу требуется произвести переход на обмен данными по другому протоколу, то он может вернуть клиенту ответ со статусом «426 Upgrade Required», и в этом случае клиент может отправить новый запрос, уже с заголовком Upgrade.

Такая возможность используется, в частности, для организации обмена данными по протоколу WebSocket (протокол, описанный в спецификации RFC 6455, позволяющий обеим сторонам передавать данные в нужный момент, без отправки дополнительных HTTP-запросов): стандартное «рукопожатие» (handshake) сводится к отправке HTTP-запроса с заголовком Upgrade, имеющим значение «websocket», на который сервер возвращает ответ с состоянием «101 Switching Protocols», и далее любая сторона может начать передавать данные уже по протоколу WebSocket.

Что-то ещё, кстати, используют?

На данный момент существуют и другие протоколы, предназначенные для передачи веб-содержимого. В частности, протокол

SPDY

(произносится как английское слово

speedy

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

Увеличение скорости обеспечивается посредством сжатия, приоритизации и мультиплексирования дополнительных ресурсов, необходимых для веб-страницы, чтобы все данные можно было передать в рамках одного соединения.

Опубликованный в ноябре 2012 года черновик спецификации протокола HTTP 2.0 (следующая версия протокола HTTP после версии 1.1, окончательная спецификация для которой была опубликована в 1999) базируется на спецификации протокола SPDY.

Многие архитектурные решения, используемые в протоколе SPDY, а также в других предложенных реализациях, которые рабочая группа httpbis рассматривала в ходе подготовки черновика спецификации HTTP 2.0, уже ранее были получены в ходе разработки протокола HTTP-NG, однако работы над протоколом HTTP-NG были прекращены в 1998.

На данный момент поддержка протокола SPDY есть в браузерах Firefox, Chromium/Chrome, Opera, Internet Exporer и Amazon Silk.

И что, всё?

В общем-то, да. Можно было бы описать конкретные методы и заголовки, но фактически эти знания нужны скорее в том случае, если вы пишете что-то конкретное (например, веб-сервер или какое-то клиентское программное обеспечение, которое связывается с серверами через HTTP), и для базового понимания принципа работы протокола не требуются. К тому же, всё это вы можете очень легко найти через Google — эта информация есть и в спецификациях, и в Википедии, и много где ещё.

Впрочем, если вы знаете английский и хотите углубиться в изучение не только самого HTTP, но и используемых для передачи пакетов TCP/IP, то рекомендую прочитать вот эту статью.

Ну и, конечно, не забывайте, что любая технология становится намного проще и понятнее тогда, когда вы фактически начинаете ей пользоваться.

Удачи и плодотворного обучения!

ОАО Морской порт Санкт-Петербург

Санкт-Петербург – крупнейший промышленный, транспортный центр, морская столица России. Петербургский порт – европейские ворота страны, важное транспортное звено между Востоком и Западом.


АО «Морской порт Санкт-Петербург» – одна из крупнейших стивидорных компаний, оказывающая услуги по перевалке всех видов сухих грузов в Большом порту Санкт-Петербурга. Компания создана на базе Ленинградского морского торгового порта.

 

Более 2000 предприятий из России, стран СНГ, ближнего и дальнего зарубежья выбирают компанию «Морской порт Санкт-Петербург». Факторы успеха – профессионализм работников, современное техническое оснащение, высокий уровень обработки грузов, удобное местоположение и развитая инфраструктура территорий.


Продуманная политика модернизации производства, привлечение квалифицированных кадров, социальная и информационная открытость помогают Морскому порту СПб достойно решать проблемы транспортного рынка России.

 

Список аккредитованных автопредприятий

Онлайн-сервис по электронному оформлению заявок на пропуск в порт
Инструкция по работе с сервисом оформления заявок на пропуск в порт

 


 

QR-код, подтверждающий соблюдение стандартов ведения безопасной деятельности

 

Грузооборот Морского порта Санкт-Петербург вырос на 19%С января по сентябрь 2021 г. на причалах АО «Морской порт Санкт-Петербург» (МП СПб) перегружено более 6,1 млн тонн грузов – на 19% больше, чем за аналогичный период прошлого года. Объём перевалки генеральных грузов увеличился до 5,2 млн тонн (+30%), насыпных и навалочных составил 712 тыс. тонн (-18%).подробнееПортовики завершили озеленение Путиловской набережной29 октября коллектив АО «Морской порт Санкт-Петербург» завершил создание липовой аллеи на Путиловской набережной Канонерского острова. Мероприятие прошло в рамках ежегодной экологической акции портовиков «Чистый остров» при поддержке отдела благоустройства и дорожного хозяйства администрации Кировского района Санкт-Петербурга. подробнееМорской порт Санкт-Петербург поддержал сотрудников антиковидной выплатой АО «Морской порт Санкт-Петербург» приняло дополнительные меры социальной поддержки своих работников во время пандемийных ограничений. Компания выплатила по 30 000 р. каждому работнику со стажем работы более одного года, чей средний ежемесячный доход составил менее 120 000 р. Единовременную выплату также получили сотрудницы, находящиеся в декретном отпуске. подробнееМорское кадровое агентство увеличило количество выпускников на 38%За девять месяцев 2021 г. учебный центр ООО «Морское кадровое агентство» выпустил 1807 специалистов для портовой отрасли, что на 38% больше, чем за аналогичный период прошлого года. подробнее

Лоток для дисков

В лотке для накопителей находится ленточный накопитель, который вставляется в отсек для накопителей внутри приводной массив базового или приводного модуля.

Лоток содержит плату контроллера привода, которая позволяет приводу взаимодействовать с библиотека. Часто «ленточный накопитель» и «лоток для дисковода» являются синонимами. Только SL4000 поддерживает лотки для дисков с контроллером LOD.

Могу ли я повторно использовать лоток для дисков SL3000 в SL4000?

Вы можете использовать лоток для дисков SL3000 в SL4000, если лоток содержит LOD-карта контроллера SL4000.Плата HBD контроллера привода SL3000 не поддерживается. Вы можете легко определить тип лотка, отметив количество портов в верхней части лоток. Карта SL3000 HBD имеет один порт, а LOD — два порта.

Задняя часть лотка для дисков

Примечание:

Порты Ethernet на заднем лотке для дисководов отключены в SL4000.
  1. Питание привода (горит зеленым). Только питание в лотке или установка кода (мигает зеленым).
  2. Требуется сервисное обслуживание (желтый)
  3. Хорошо, удалить лоток для дисковода из библиотеки (синий). Мигает при использовании функция определения местоположения.
  4. Включение / выключение питания лотка (кнопка) — отключено на SL4000.Вместо этого используйте графический интерфейс для включения или выключения лотка.
  5. Ethernet-канал (зеленый). Порт отключен на SL4000 и только используется представителями службы Oracle для обслуживания.
  6. Сброс шифрования до IP-адреса по умолчанию (кнопка)
  7. Индикатор шифрования
  8. Порт карты шифрования. Порт отключен на SL4000.
  9. Порты Fibre Channel
  10. Кнопка обслуживания (НЕ ИСПОЛЬЗУЙТЕ в SL4000.Это займет диск офлайн.)
  11. Индикатор состояния привода
  12. Индикатор техобслуживания привода

Настройки порта

При развертывании AppDynamics вам может потребоваться открыть порты в сетевом брандмауэре или настроить балансировщик нагрузки, чтобы обеспечить связь между контроллером и остальной частью платформы AppDynamics.

Для SaaS вам нужно только настроить свою инфраструктуру, чтобы приспособить порт HTTPS, предоставленный вам AppDynamics.Однако для локального развертывания вам может потребоваться внести дополнительные настройки на основе информации здесь.

Порты компонентов платформы

Следующие порты открыты при развертывании платформы. Столбец «external» указывает, происходят ли соединения с портом полностью внутри хоста контроллера или извне, и поэтому может потребоваться изменение конфигурации брандмауэра или балансировщика нагрузки.

Имя порта По умолчанию Внешний?
Порт корпоративной консоли 9191 Да.Приложение использует порт 9191 для всего трафика.
Порт SSH 22 Порт должен быть открыт между Enterprise Console и удаленными хостами, которыми она управляет. Это только для Unix и не настраивается. Если вам необходимо настроить порт, обратитесь в службу поддержки AppDynamics.

Порт сервера базы данных

3388

 Нет
Порт базы данных по умолчанию 3377 Нет

Порт администратора сервера приложений

4848

 Нет

Порт JMS сервера приложений

7676

 Нет

Порт IIOP сервера приложений

3700

 Нет
Первичный порт сервера приложений (HTTP) 8090 Да
Порт SSL сервера приложений (HTTPS) 8181 Да
Порт API REST службы событий 9080 Если служба событий и контроллер находятся на разных хостах, необходимо настроить порт в брандмауэр или балансировщик нагрузки.
Порт администратора REST API службы событий 9081 Если служба событий и контроллер находятся на разных хостах, вам необходимо настроить порт в брандмауэре или балансировщике нагрузки.
Порт HTTP службы отчетов 8020 Нет
Порт HTTP службы отчетов 8021 Нет
Порт сервера EUM (HTTP) 7001 Если EUM и контроллер включены разные хосты, вам нужно настроить порт в брандмауэре или балансировщике нагрузки.
Порт SSL сервера EUM (HTTPS) 7002 Если EUM и контроллер находятся на разных хостах, вам необходимо настроить порт в брандмауэре или балансировщике нагрузки.

Во время установки вы можете ввести разные порты вручную. После установки вы можете изменить настройки порта, переустановив контроллер или отредактировав конфигурацию порта, как определено на странице Конфигурации корпоративной консоли или на базовом сервере приложений GlassFish, как описано в следующих разделах.

Редактирование конфигураций портов контроллера

Вы можете изменить настройки подключения через пользовательский интерфейс Enterprise Console. Enterprise Console автоматически обновит все вхождения в контроллере. Вам не нужно вручную обновлять все файлы и управлять последовательностью перезапуска служб. См. Обновление конфигураций платформы.

Вы также можете редактировать порты вручную, редактируя файлы конфигурации, используемые сервером приложений для домена контроллера. Однако обновление портов вручную приведет к тому, что Enterprise Console не будет видеть обновления и вызовет ошибки проверки работоспособности.

В следующих разделах перечислены параметры, которые необходимо изменить для изменения порта.

Измените порт прослушивания основного сервера

  1. В файле domain.xml измените номер порта, как он отображается в следующих местах:
    • Значение элемента network-listener с атрибутом для основного порта прослушивания, или http-listener-2 для безопасного прослушивающего порта для новой настройки порта.
    • Значения аргумента JVM для порта HTTP контроллера и порта служб контроллера в элементе конфигурации с именем server-config .
  2. Для каждого развернутого агента перейдите к proxy / conf в домашнем каталоге агента и измените значение controller-port в файле controller-info.xml .

Изменить порт базы данных

  1. В domain.xml измените порт прослушивания базы данных, где он отображается в элементе jdbc-connection-pool с именем controller_mysql_pool . Он отображается как значение свойства с именем portNumber .
  2. Отредактируйте файл appserver / glassfish / domains / domain1 / imq / instance / imqbroker / props / config.properties , чтобы изменить переменную "imq.persist.jdbc.mysql.property.url" , чтобы она включала в себя новый номер порта. Эта переменная представляет собой строку подключения JDBC.
  3. В db / db.cnf установите для переменной "port =" значение вашего нового порта.
  4. В bin / controller.bat (.sh) измените переменную «DB_PORT» на новую настройку порта.

Измените порт прослушивания администратора Glassfish

  1. В domain.xml измените значение атрибута порта элемента http-listener на новый порт. Это элемент со значением атрибута id "admin-listener" .
  2. Также в домашнем каталоге контроллера измените значение adminPort в .install4j / response.varfile . Это гарантирует, что новый номер порта не будет перезаписан при последующем обновлении контроллера.

Измените порт JMS

  1. В domain.xml измените значение атрибута порта для элемента jms-host с атрибутом имени default_JMS_host .
  2. Измените значение jmsPort в .install4j / response.varfile . Это гарантирует, что новый номер порта не будет перезаписан при последующем обновлении контроллера.

Изменить порт прослушивания IIOP

  1. В domain.xml отредактируйте значение атрибута порта элемента iiop-listener с атрибутом id orb-listener-1 .
  2. Измените значение iiopPort в /.install4j/response.varfile . Это гарантирует, что новый номер порта не будет перезаписан при последующем обновлении контроллера.

Включение проверок работоспособности сервера приложений для HTTPS

Если вы отключите или заблокируете порт HTTP контроллера, вам необходимо будет настроить проверку работоспособности сервера приложений для связи с портом HTTPS контроллера. Вы можете сделать это, выполнив следующие шаги:

  1. В домене .xml , установите для HTTP-прослушивателя http-listener-1 значение enabled = false .
  2. Перезапустите контроллер.
  3. Используйте Enterprise Console для обнаружения и обновления контроллера.
    Корпоративная консоль по умолчанию будет использовать порт HTTPS.

Обслуживание | Kubernetes

Абстрактный способ представить приложение, работающее на наборе модулей, в качестве сетевой службы.

С Kubernetes вам не нужно изменять приложение для использования незнакомого механизма обнаружения сервисов.Kubernetes дает Pod’ам собственные IP-адреса и единое DNS-имя для набора Pod’ов, и может балансировать нагрузку между ними.

Мотивация

Подов Kubernetes создаются и уничтожаются чтобы соответствовать состоянию вашего кластера. Поды — это непостоянные ресурсы. Если вы используете развертывание для запуска своего приложения, он может создавать и уничтожать поды динамически.

Каждый модуль получает свой собственный IP-адрес, однако при развертывании набор модулей бег в один момент времени может отличаться от набор модулей, запускающих это приложение мгновением позже.

Это приводит к проблеме: если какой-то набор модулей (назовем их «бэкэндами») предоставляет функциональность для других модулей (назовите их «внешними интерфейсами») внутри вашего кластера, как интерфейсы узнают и отслеживают, к какому IP-адресу подключаться чтобы фронтенд мог использовать бэкэнд часть рабочей нагрузки?

Введите Services .

Сервисные ресурсы

В Kubernetes служба — это абстракция, которая определяет логический набор модулей. и политику доступа к ним (иногда этот шаблон называют микросервис).Набор модулей, на которые нацелена служба, обычно определяется селектором. Чтобы узнать о других способах определения конечных точек службы, см. Услуги без селекторов .

Например, рассмотрим серверную часть обработки изображений без сохранения состояния, которая работает с 3 реплики. Эти реплики взаимозаменяемы — интерфейсам безразлично, какой из них они используют. Хотя фактические модули, составляющие набор серверной части, могут измениться, клиентские интерфейсы не должны знать об этом, и им не нужно хранить отслеживать множество самих бэкэндов.

Абстракция Service включает эту развязку.

Обнаружение облачных сервисов

Если вы можете использовать API Kubernetes для обнаружения сервисов в своем приложении, вы можете запросить сервер API для конечных точек, которые обновляются при изменении набора модулей в службе.

Для неродных приложений Kubernetes предлагает способы размещения сетевого порта или загрузки балансировщик между вашим приложением и внутренними модулями.

Определение услуги

Служба в Kubernetes — это объект REST, похожий на под.Как и все Объекты REST, вы можете POST определение службы для сервера API для создания новый экземпляр. Имя объекта службы должно быть действительным RFC 1035 имя метки.

Например, предположим, что у вас есть набор модулей, каждый из которых прослушивает TCP-порт 9376. и содержит метку app = MyApp :

  apiВерсия: v1
вид: Сервис
метаданные:
  имя: my-service
спецификация:
  селектор:
    приложение: MyApp
  порты:
    - протокол: TCP
      порт: 80
      targetPort: 9376

Эта спецификация создает новый объект службы с именем «my-service», который нацелен на TCP-порт 9376 на любом поде с меткой app = MyApp .

Kubernetes назначает этой Службе IP-адрес (иногда называемый «IP-адрес кластера»), который используется прокси Сервиса (см. Виртуальные IP-адреса и служебные прокси ниже).

Контроллер для селектора услуг непрерывно сканирует поды, которые соответствует его селектору, а затем отправляет любые обновления объекта Endpoint на POST также называется «мой-сервис».

Примечание: Служба может сопоставить любой входящий порт с целевым портом . По умолчанию и для удобства targetPort установлен на то же значение, что и порт поле.

Определения портов в модулях имеют имена, и вы можете ссылаться на эти имена в targetPort атрибут службы. Это работает, даже если есть смесь модулей в Службе, использующих одно настроенное имя, с одной и той же сетью протокол доступен через разные номера портов. Это обеспечивает большую гибкость при развертывании и развитии ваших Сервисов. Например, вы можете изменить номера портов, которые будут отображаться в следующих модулях. версия вашего серверного ПО, не нарушая клиентов.

Протоколом по умолчанию для служб является TCP; вы также можете использовать любой другой поддерживаемый протокол.

Поскольку многие службы должны предоставлять более одного порта, Kubernetes поддерживает несколько определения портов на объекте службы. Каждое определение порта может иметь один и тот же протокол или другой.

Услуги без переключателей

Службы

обычно абстрагируют доступ к модулям Kubernetes, но они также могут абстрактные другие виды бэкэндов. Например:

  • Вы хотите иметь кластер внешней базы данных в производстве, но в вашем В тестовой среде вы используете собственные базы данных.
  • Вы хотите указать свою услугу на услугу в другом Пространство имен или в другом кластере.
  • Вы переносите рабочую нагрузку в Kubernetes. Оценивая подход, вы запускаете в Kubernetes только часть своих бэкэндов.

В любом из этих сценариев вы можете определить Service без селектора Pod. Например:

  apiВерсия: v1
вид: Сервис
метаданные:
  имя: my-service
спецификация:
  порты:
    - протокол: TCP
      порт: 80
      targetPort: 9376

Поскольку эта служба не имеет селектора, соответствующий объект конечных точек не создается автоматически.Вы можете вручную сопоставить Сервис с сетевым адресом и портом. где он запущен, добавив вручную объект Endpoints:

  apiВерсия: v1
вид: Конечные точки
метаданные:
  имя: my-service
подмножества:
  - адреса:
      - ip: 192.0.2.42
    порты:
      - порт: 9376

Имя объекта Endpoints должно быть допустимым. Имя поддомена DNS.

Примечание:

IP-адреса конечной точки не должны быть : loopback (127.0.0.0/8 для IPv4, :: 1/128 для IPv6) или локальная ссылка (169.254.0.0 / 16 и 224.0.0.0/24 для IPv4, fe80 :: / 64 для IPv6).

IP-адреса конечных точек

не могут быть IP-адресами кластера других сервисов Kubernetes, потому что kube-proxy не поддерживает виртуальные IP-адреса как пункт назначения.

Доступ к службе без селектора работает так же, как если бы у нее был селектор. В приведенном выше примере трафик направляется к единственной конечной точке, определенной в YAML: 192.0.2.42:9376 (TCP).

Примечание. Сервер Kubernetes API не позволяет проксировать конечные точки, которые не сопоставлены с стручки.Такие действия, как kubectl proxy , где у службы нет селектор выйдет из строя из-за этого ограничения. Это мешает серверу Kubernetes API от использования в качестве прокси-сервера для конечных точек, для доступа вызывающему абоненту может быть отказано.

Служба ExternalName — это особый случай Службы, не имеющей селекторы и вместо этого использует DNS-имена. Для получения дополнительной информации см. Раздел ExternalName далее в этом документе.

Конечные точки с превышением емкости

Если ресурс Endpoints имеет более 1000 конечных точек, тогда Kubernetes v1.22 (или новее) cluster аннотирует эти конечные точки с помощью конечных точек .kubernetes.io/over-capacity: усечено . Эта аннотация указывает, что затронутый объект конечных точек превышает емкость и что контроллер конечных точек усек количество конечных точек до 1000.

EndpointSlices

СОСТОЯНИЕ ФУНКЦИИ: Kubernetes v1.21 [стабильный]

EndpointSlices — это ресурс API, который может предоставить более масштабируемую альтернативу. в конечные точки.Хотя концептуально очень похоже на конечные точки, EndpointSlices позволяют распределять конечные точки сети по нескольким ресурсам. По умолчанию, EndpointSlice считается «полным», когда он достигает 100 конечных точек, на которых дополнительные точки EndpointSlices будут созданы для хранения любых дополнительных конечные точки.

EndpointSlices предоставляют дополнительные атрибуты и функции, которые подробно описано в EndpointSlices.

Протокол приложения

СОСТОЯНИЕ ФУНКЦИИ: Kubernetes v1.20 [стабильный]

Поле appProtocol позволяет указать протокол приложения для каждый Сервисный порт. Значение этого поля отражается соответствующим Конечные точки и объекты EndpointSlice.

Это поле соответствует стандартному синтаксису меток Kubernetes. Значения должны быть либо Стандартные названия служб IANA или доменные имена с префиксом, например mycompany.com/my-custom-protocol .

Виртуальные IP-адреса и служебные прокси

На каждом узле кластера Kubernetes работает kube-proxy . kube-proxy есть отвечает за реализацию формы виртуального IP для Сервисов другого типа чем ExternalName .

Почему бы не использовать циклический DNS?

Время от времени возникает вопрос, почему Kubernetes полагается на проксирование для перенаправления входящего трафика на бэкенды. А как насчет других подходит? Например, можно ли настроить записи DNS, которые иметь несколько значений A (или AAAA для IPv6) и полагаться на циклическое имя разрешающая способность?

Есть несколько причин для использования прокси для Сервисов:

  • Существует долгая история реализации DNS, не соблюдающей TTL записей, и кэширование результатов поиска имен после истечения срока их действия.
  • Некоторые приложения выполняют поиск DNS только один раз и кэшируют результаты на неопределенный срок.
  • Даже если приложения и библиотеки правильно изменили разрешение, низкий или нулевой TTL записи DNS могут вызвать высокую нагрузку на DNS, которая затем становится сложно управлять.

Далее на этой странице вы можете прочитать о различных реализациях kube-proxy. Общий, следует отметить, что при запуске kube-proxy правила уровня ядра могут быть изменены (например, могут быть созданы правила iptables), которые не будут очищены, в некоторых случаях до перезагрузки.Таким образом, запуск kube-proxy должен должны выполняться только администратором, который понимает последствия наличия низкоуровневая привилегированная служба сетевого прокси на компьютере. Хотя kube-proxy исполняемый файл поддерживает функцию очистки , эта функция не является официальной функцией и таким образом, доступен только для использования «как есть».

Конфигурация

Обратите внимание, что kube-proxy запускается в разных режимах, которые определяются его конфигурацией.

  • Конфигурация kube-proxy выполняется через ConfigMap, а ConfigMap для kube-proxy фактически не поддерживает поведение почти всех флагов для kube-proxy.
  • ConfigMap для kube-proxy не поддерживает перезагрузку конфигурации в реальном времени.
  • Невозможно проверить все параметры ConfigMap для kube-proxy при запуске. Например, если ваша операционная система не позволяет запускать команды iptables, стандартная реализация ядра kube-proxy не будет работать.Аналогичным образом, если у вас есть операционная система, которая не поддерживает netsh , она не будет работать в режиме пользовательского пространства Windows.

Режим прокси в пользовательском пространстве

В этом (устаревшем) режиме kube-proxy наблюдает за уровнем управления Kubernetes для добавления и удаление объектов Service и Endpoint. Для каждой услуги открывается порт (выбранный случайным образом) на локальном узле. Любые подключения к этому «прокси-порту» проксируются на один из бэкэнд-модулей Сервиса (как сообщается через Конечные точки).kube-proxy принимает настройку SessionAffinity Сервиса в учетная запись при принятии решения о том, какой серверный модуль использовать.

Наконец, прокси-сервер пользовательского пространства устанавливает правила iptables, которые захватывают трафик на Служба clusterIP (который является виртуальным) и порт . Правила перенаправить этот трафик на порт прокси, который проксирует серверный модуль.

По умолчанию kube-proxy в режиме пользовательского пространства выбирает серверную часть с помощью алгоритма циклического перебора.

iptables режим прокси

В этом режиме kube-proxy наблюдает за уровнем управления Kubernetes для добавления и удаление объектов Service и Endpoint.Для каждой службы устанавливается правила iptables, которые захватывают трафик на кластер IP Службы и порт , и перенаправить этот трафик на один из бэкэнд-наборы. Для каждого объекта Endpoint он устанавливает правила iptables, которые выберите серверный модуль.

По умолчанию kube-proxy в режиме iptables выбирает серверную часть случайным образом.

Использование iptables для обработки трафика снижает нагрузку на систему, поскольку трафик обрабатывается сетевым фильтром Linux без необходимости переключения между пользовательским пространством и пространство ядра.Этот подход также, вероятно, будет более надежным.

Если kube-proxy работает в режиме iptables и первый выбранный под не отвечает, соединение не установлено. Это отличается от пользовательского пространства режим: в этом сценарии kube-proxy обнаружит, что подключение к первому Pod завершился неудачно и автоматически повторит попытку с другим серверным модулем.

Вы можете использовать зонды готовности Pod чтобы убедиться, что серверные модули работают нормально, чтобы kube-proxy в режиме iptables видит только проверенные серверные ВМ как работоспособные.Это означает, что вы избегаете трафик, отправленный через kube-proxy на под, который, как известно, вышел из строя.

Режим прокси IPVS

СОСТОЯНИЕ ФУНКЦИИ: Kubernetes v1.11 [стабильный]

В режиме ipvs kube-proxy наблюдает за сервисами и конечными точками Kubernetes, вызывает интерфейс netlink для создания соответствующих правил IPVS и синхронизирует Периодически правила IPVS с Kubernetes Services и Endpoints. Этот контур управления гарантирует, что статус IPVS соответствует желаемому. штат.При доступе к Сервису IPVS направляет трафик на один из бэкэнд-модулей.

Режим прокси IPVS основан на функции ловушки netfilter, которая аналогична iptables, но использует хеш-таблицу в качестве базовой структуры данных и работает в пространстве ядра. Это означает, что kube-proxy в режиме IPVS перенаправляет трафик с меньшей задержкой, чем kube-proxy в режиме iptables, с гораздо большей производительностью при синхронизации правила прокси. По сравнению с другими режимами прокси, режим IPVS также поддерживает более высокая пропускная способность сетевого трафика.

IPVS предоставляет больше возможностей для балансировки трафика для серверных модулей; это:

  • rr : циклический
  • lc : наименьшее количество соединений (наименьшее количество открытых соединений)
  • dh : целевое хеширование
  • sh : хеширование исходного кода
  • sed : кратчайшая ожидаемая задержка
  • nq : никогда не вставать в очередь
Примечание:

Чтобы запустить kube-proxy в режиме IPVS, вы должны сделать IPVS доступным на узел перед запуском kube-proxy.

Когда kube-proxy запускается в режиме прокси IPVS, он проверяет, модули ядра доступны. Если модули ядра IPVS не обнаружены, то kube-proxy возвращается к работе в режиме прокси iptables.

В этих моделях прокси трафик, привязанный к IP-адресу службы: проксируется на соответствующий сервер, и клиенты ничего не знают о Kubernetes, Сервисах или Подах.

Если вы хотите убедиться, что соединения от конкретного клиента передаются в один и тот же Pod каждый раз, вы можете выбрать привязку сеанса на основе на IP-адресах клиента, установив службу .spec.sessionAffinity на «ClientIP» (по умолчанию «Нет»). Вы также можете установить максимальное время прикрепления сеанса, установив service.spec.sessionAffinityConfig.clientIP.timeoutSeconds соответственно. (значение по умолчанию 10800, что составляет 3 часа).

Многопортовые службы

Для некоторых Сервисов нужно выставить более одного порта. Kubernetes позволяет настраивать несколько определений портов для объекта службы. При использовании нескольких портов для Сервиса вы должны дать имена всем своим портам. так что это однозначно.Например:

  apiВерсия: v1
вид: Сервис
метаданные:
  имя: my-service
спецификация:
  селектор:
    приложение: MyApp
  порты:
    - имя: http
      протокол: TCP
      порт: 80
      targetPort: 9376
    - имя: https
      протокол: TCP
      порт: 443
      targetPort: 9377
Примечание:

Как и в случае с именами Kubernetes в целом, имена портов должны содержать только строчные буквенно-цифровые символы и –. Имена портов должны также начинаются и заканчиваются буквенно-цифровыми символами.

Например, имена 123-abc и web допустимы, но 123_abc и -web — нет.

Выбор собственного IP-адреса

Вы можете указать свой собственный IP-адрес кластера как часть создания службы запрос. Для этого установите поле .spec.clusterIP . Например, если вы уже есть существующая запись DNS, которую вы хотите использовать повторно, или устаревшие системы которые настроены для определенного IP-адреса и их сложно перенастроить.

Выбранный вами IP-адрес должен быть действительным IPv4- или IPv6-адресом изнутри service-cluster-ip-range Диапазон CIDR, настроенный для сервера API. Если вы попытаетесь создать Сервис с недопустимым значением IP-адреса кластера, API сервер вернет код состояния HTTP 422, чтобы указать на наличие проблемы.

Правила дорожного движения

Политика внешнего трафика

Вы можете установить поле spec.externalTrafficPolicy для управления маршрутизацией трафика из внешних источников.Допустимые значения: Cluster и Local . Установите в поле значение Cluster для маршрутизации внешнего трафика ко всем готовым конечным точкам. и Local для маршрутизации только к готовым локальным конечным точкам узла. Если политика трафика — Local и нет локальных узлов конечные точки, kube-proxy не пересылает трафик для соответствующей службы.

Примечание:

СОСТОЯНИЕ ФУНКЦИИ: Kubernetes v1.22 [альфа]

Если вы включите ProxyTerminatingEndpoints ворота функций для kube-proxy kube-proxy проверяет, имеет локальные конечные точки и отмечены ли все локальные конечные точки как завершающие.Если есть локальные конечные точки и , все из них завершаются, тогда kube-proxy игнорирует любая политика внешнего трафика Local . Вместо этого, в то время как локальные конечные точки узла остаются как все завершение, kube-proxy перенаправляет трафик для этой службы на работоспособные конечные точки в другом месте, как если бы политика внешнего трафика была установлена ​​на Кластер . Такое поведение пересылки для завершающих конечных точек существует, чтобы позволить внешним балансировщикам нагрузки изящно осушать соединения, которые поддерживаются службами NodePort , даже если проверка работоспособности порт узла начинает выходить из строя.В противном случае трафик может быть потерян между тем временем, когда узел все еще находится в пуле узлов нагрузки. балансировщик, и трафик падает в течение периода завершения работы модуля.

Политика внутреннего трафика

СОСТОЯНИЕ ФУНКЦИИ: Kubernetes v1.22 [бета]

Вы можете установить поле spec.internalTrafficPolicy для управления маршрутизацией трафика из внутренних источников. Допустимые значения: Cluster и Local . Установите в поле значение Cluster для маршрутизации внутреннего трафика ко всем готовым конечным точкам. и Local для маршрутизации только к готовым локальным конечным точкам узла.Если политика трафика — Local и нет локальных узлов конечные точки, трафик сбрасывается kube-proxy.

Услуги по поиску

Kubernetes поддерживает 2 основных режима поиска Сервиса — окружение. переменные и DNS.

Переменные среды

Когда под запускается на узле, кубелет добавляет набор переменных среды. для каждой активной Услуги. Он поддерживает обе ссылки Docker совместимые переменные (см. makeLinkVariables) и более простые переменные {SVCNAME} _SERVICE_HOST и {SVCNAME} _SERVICE_PORT , где имя службы пишется в верхнем регистре, а дефисы преобразуются в символы подчеркивания.

Например, служба redis-master , которая предоставляет TCP-порт 6379 и была выделенный IP-адрес кластера 10.0.0.11, создает следующую среду переменные:

  REDIS_MASTER_SERVICE_HOST = 10.0.0.11
REDIS_MASTER_SERVICE_PORT = 6379
REDIS_MASTER_PORT = tcp: //10.0.0.11: 6379
REDIS_MASTER_PORT_6379_TCP = tcp: //10.0.0.11: 6379
REDIS_MASTER_PORT_6379_TCP_PROTO = TCP
REDIS_MASTER_PORT_6379_TCP_PORT = 6379
REDIS_MASTER_PORT_6379_TCP_ADDR = 10.0.0.11
Примечание:

Если у вас есть модуль, которому требуется доступ к службе, и вы используете метод переменной среды для публикации порта и IP-адреса кластера клиенту Модули, вы должны создать Службу до того, как появятся клиентские модули .В противном случае переменные среды этих клиентских модулей не будут заполнены.

Если вы используете DNS только для обнаружения IP-адреса кластера для службы, вам не нужно беспокоиться об этой проблеме с заказом.

DNS

Вы можете (и почти всегда должны) настроить службу DNS для своего Kubernetes кластер с помощью надстройки.

DNS-сервер с поддержкой кластера, такой как CoreDNS, следит за Kubernetes API в поисках новых Services и создает набор записей DNS для каждой из них. Если DNS был включен во всем кластере, тогда все поды должны автоматически разрешать Сервисы по их DNS-имени.

Например, если у вас есть служба под названием my-service в Kubernetes пространство имен my-ns , плоскость управления и служба DNS действуют вместе создать DNS-запись для my-service.my-ns . Поды в пространстве имен my-ns должен иметь возможность найти службу, выполнив поиск имени для my-service ( my-service.my-ns также подойдет).

Поды в других пространствах имен должны квалифицировать имя как my-service.my-ns .Эти имена будет разрешаться в IP-адрес кластера, назначенный для Службы.

Kubernetes также поддерживает записи DNS SRV (Service) для именованных портов. Если my-service.my-ns Служба имеет порт с именем http с протоколом, установленным на TCP , вы можете выполнить запрос DNS SRV для _http._tcp.my-service.my-ns , чтобы обнаружить номер порта для http , а также IP-адрес.

DNS-сервер Kubernetes — единственный способ получить доступ к службам ExternalName .Дополнительную информацию о разрешении ExternalName можно найти в Модули и службы DNS.

Безголовые службы

Иногда вам не нужна балансировка нагрузки и единый IP-адрес службы. В в этом случае вы можете создать так называемые «безголовые» службы, явно с указанием "None" для IP-адреса кластера ( .spec.clusterIP ).

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

Для безголового Services IP-адрес кластера не выделяется, kube-proxy не обрабатывает эти Сервисы, и платформа не выполняет балансировку нагрузки или проксирование. для них. Автоматическая настройка DNS зависит от того, есть ли у Службы определено селекторов:

С переключателями

Для автономных служб, которые определяют селекторы, контроллер конечных точек создает Конечные точки записей в API и изменяют конфигурацию DNS для возврата Записи (IP-адреса), которые указывают непосредственно на блоки Pods , поддерживающие службу .

Без селекторов

Для автономных служб, которые не определяют селекторы, контроллер конечных точек выполняет не создавать конечных точек записей. Однако система DNS ищет и настраивает либо:

  • Записи CNAME для служб типа ExternalName .
  • A записи для любых Конечных точек , которые имеют общее имя с Сервисом, для всех другие виды.

Издательские услуги (ServiceTypes)

Для некоторых частей вашего приложения (например, интерфейсов) вы можете захотеть открыть Служба на внешнем IP-адресе, который находится за пределами вашего кластера.

Kubernetes Типы служб позволяют указать, какой вид службы вам нужен. По умолчанию — ClusterIP .

Значения типа и их поведение:

Вы также можете использовать Ingress для предоставления доступа к вашему Сервису. Ingress — это не тип службы, но он действует как точка входа для вашего кластера. Это позволяет объединить правила маршрутизации в один ресурс, так как он может предоставлять несколько сервисов под одним и тем же IP-адресом.

Тип NodePort

Если вы установите для поля type значение NodePort , плоскость управления Kubernetes выделяет порт из диапазона, указанного флагом --service-node-port-range (по умолчанию: 30000-32767).Каждый узел передает этот порт (один и тот же номер порта на каждом узле) в вашу службу. Ваша служба сообщает о выделенном порте в своем поле .spec.ports [*]. NodePort .

Если вы хотите указать определенные IP-адреса для проксирования порта, вы можете установить --nodeport-addresses Флаг для kube-proxy или эквивалентный nodePortAddresses поле файл конфигурации kube-proxy к конкретному IP-блоку (ам).

Этот флаг принимает список IP-блоков, разделенных запятыми (например,грамм. 10.0.0.0/8 , 192.0.2.0/25 ), чтобы указать диапазоны IP-адресов, которые kube-proxy должен рассматривать как локальные для этого узла.

Например, если вы запускаете kube-proxy с флагом --nodeport-addresses = 127.0.0.0 / 8 , kube-proxy выбирает только интерфейс обратной связи для служб NodePort. По умолчанию для --nodeport-addresses — пустой список. Это означает, что kube-proxy должен учитывать все доступные сетевые интерфейсы для NodePort. (Это также совместимо с более ранними выпусками Kubernetes).

Если вам нужен конкретный номер порта, вы можете указать значение в nodePort поле. Плоскость управления либо выделит вам этот порт, либо сообщит, что транзакция API не удалась. Это означает, что вам необходимо самостоятельно позаботиться о возможных конфликтах портов. Вы также должны использовать действительный номер порта, который находится в пределах настроенного диапазона. для использования NodePort.

Использование NodePort дает вам свободу настраивать собственное решение для балансировки нагрузки, для настройки сред, которые не полностью поддерживаются Kubernetes, или даже для прямого доступа к одному или нескольким IP-адресам узлов.

Обратите внимание, что эта служба отображается как : spec.ports [*]. NodePort и .spec.clusterIP: spec.ports [*]. port . Если --nodeport-addresses флаг для kube-proxy или аналогичного поля в файле конфигурации kube-proxy установлено, что будет отфильтрованным IP-адресом узла.

Например:

  apiВерсия: v1
вид: Сервис
метаданные:
  имя: my-service
спецификация:
  тип: NodePort
  селектор:
    приложение: MyApp
  порты:
      # По умолчанию и для удобства, для параметра targetPort установлено то же значение, что и для поля port.- порт: 80
      targetPort: 80
      # Необязательное поле
      # По умолчанию и для удобства плоскость управления Kubernetes выделяет порт из диапазона (по умолчанию: 30000-32767)
      nodePort: 30007

Тип Балансировщик нагрузки

На облачных провайдерах, поддерживающих внешние балансировщики нагрузки, установка типа в поле LoadBalancer подготавливает балансировщик нагрузки для вашей службы. Фактическое создание балансировщика нагрузки происходит асинхронно, и информация о подготовленном балансировщике публикуется в .Поле status.loadBalancer . Например:

  apiВерсия: v1
вид: Сервис
метаданные:
  имя: my-service
спецификация:
  селектор:
    приложение: MyApp
  порты:
    - протокол: TCP
      порт: 80
      targetPort: 9376
  clusterIP: 10.0.171.239
  тип: LoadBalancer
положение дел:
  loadBalancer:
    вход:
    - ip: 192.0.2.127

Трафик от внешнего балансировщика нагрузки направляется на серверные модули. Облачный провайдер решает, как выполняется балансировка нагрузки.

Некоторые облачные провайдеры позволяют указывать loadBalancerIP .В этих случаях создается балансировщик нагрузки. с указанным пользователем loadBalancerIP . Если поле loadBalancerIP не указано, loadBalancer настроен с временным IP-адресом. Если указать loadBalancerIP но ваш облачный провайдер не поддерживает эту функцию, поле loadbalancerIP , которое вы набор игнорируется.

Балансировщики нагрузки со смешанными типами протоколов

СОСТОЯНИЕ ФУНКЦИИ: Kubernetes v1.20 [альфа]

По умолчанию для служб типа LoadBalancer, когда определено более одного порта, все порты должны иметь один и тот же протокол, и протокол должен быть поддерживаемым поставщиком облачных услуг.

Если функция Gate MixedProtocolLBService включена для kube-apiserver, разрешено использовать разные протоколы, когда определено более одного порта.

Примечание. Набор протоколов, которые можно использовать для служб типа LoadBalancer, по-прежнему определяется поставщиком облачных услуг.

Отключение распределения NodePort балансировщика нагрузки

СОСТОЯНИЕ ФУНКЦИИ: Kubernetes v1.20 [альфа]

Начиная с v1.20, вы можете дополнительно отключить выделение портов узла для Service Type = LoadBalancer, установив поле spec.allocateLoadBalancerNodePorts от до false . Это следует использовать только для реализации балансировщика нагрузки. которые направляют трафик непосредственно к модулям, а не используют порты узлов. По умолчанию спец.allocateLoadBalancerNodePorts равно true и тип LoadBalancer Services продолжит выделять порты узлов. Если spec.allocateLoadBalancerNodePorts установлено значение false для существующей службы с выделенными портами узлов, эти порты узлов НЕ будут автоматически отменены. Вы должны явно удалить запись nodePorts в каждом служебном порте, чтобы освободить эти порты узла. Для использования этого поля необходимо включить шлюз функции ServiceLBNodePortControl .

Указание класса реализации балансировщика нагрузки

СОСТОЯНИЕ ФУНКЦИИ: Kubernetes v1.22 [бета]

spec.loadBalancerClass позволяет использовать реализацию балансировщика нагрузки, отличную от используемой по умолчанию облачного провайдера. Эта функция доступна начиная с версии 1.21, необходимо включить шлюз функции ServiceLoadBalancerClass , чтобы использовать это поле в версии 1.21, а шлюз функции включен по умолчанию, начиная с версии 1.22. По умолчанию спец.loadBalancerClass равен nil , а тип службы LoadBalancer использует реализация балансировщика нагрузки облачного провайдера по умолчанию, если кластер настроен с облачный провайдер, использующий флаг компонента --cloud-provider . Если указан spec.loadBalancerClass , предполагается, что балансировщик нагрузки реализация, соответствующая указанному классу, наблюдает за Службами. Любая реализация балансировщика нагрузки по умолчанию (например, предоставленная поставщик облачных услуг) будет игнорировать Сервисы, для которых установлено это поле. spec.loadBalancerClass может быть установлен только для службы типа LoadBalancer . После установки его нельзя изменить. Значение spec.loadBalancerClass должно быть идентификатором стиля метки, с необязательным префиксом, например « internal-vip » или « example.com/internal-vip ». Имена без префикса зарезервированы для конечных пользователей.

Внутренний балансировщик нагрузки

В смешанной среде иногда необходимо направлять трафик от Сервисов внутри одного и того же (виртуальный) сетевой адресный блок.

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

Чтобы установить внутренний балансировщик нагрузки, добавьте одну из следующих аннотаций к вашему Сервису в зависимости от поставщика облачных услуг, который вы используете.

  [...]
метаданные:
    имя: my-service
    аннотации:
        cloud.google.com/load-balancer-type: "Внутренний"
[...]
  
  [...]
метаданные:
    имя: my-service
    аннотации:
        услуга.beta.kubernetes.io/aws-load-balancer-internal: "правда"
[...]
  
  [...]
метаданные:
    имя: my-service
    аннотации:
        service.beta.kubernetes.io/azure-load-balancer-internal: "правда"
[...]
  
  [...]
метаданные:
    имя: my-service
    аннотации:
        service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "частный"
[...]
  
  [...]
метаданные:
    имя: my-service
    аннотации:
        услуга.beta.kubernetes.io/openstack-internal-load-balancer: "правда"
[...]
  
  [...]
метаданные:
    имя: my-service
    аннотации:
        service.beta.kubernetes.io/cce-load-balancer-internal-vpc: "правда"
[...]
  
  [...]
метаданные:
  аннотации:
    service.kubernetes.io/qcloud-loadbalancer-internal-subnetid: подсеть-xxxxx
[...]
  
  [...]
метаданные:
  аннотации:
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "интранет"
[...]
Поддержка
TLS на AWS

Для частичной поддержки TLS / SSL на кластерах, работающих на AWS, вы можете добавить три аннотации к службе LoadBalancer :

  метаданные:
  имя: my-service
  аннотации:
    service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn: aws: acm: us-east-1: 123456789012: certificate / 12345678-1234-1234-1234-123456789012

Первый указывает ARN используемого сертификата. Это может быть либо сертификат от стороннего эмитента, который был загружен в IAM или создан в AWS Certificate Manager.

  метаданные:
  имя: my-service
  аннотации:
    service.beta.kubernetes.io/aws-load-balancer-backend-protocol: (https | http | ssl | tcp)

Вторая аннотация указывает протокол, по которому работает Pod. Для HTTPS и SSL, ELB ожидает, что Pod аутентифицируется через зашифрованный подключение, используя сертификат.

HTTP и HTTPS выбирает проксирование уровня 7: ELB завершается соединение с пользователем, анализирует заголовки и вводит X-Forwarded-For заголовок с IP-адресом пользователя (модули видят только IP-адрес ELB на другом конце своего соединения) при пересылке запросов.

TCP и SSL выбирают проксирование уровня 4: ELB пересылает трафик без изменение заголовков.

В смешанной среде, где одни порты защищены, а другие остаются незашифрованными, вы можете использовать следующие аннотации:

  метаданные:
      имя: my-service
      аннотации:
        service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http
        service.beta.kubernetes.io/aws-load-balancer-ssl-ports: «443,8443»

В приведенном выше примере, если Служба содержала три порта, 80 , 443 и 8443 , затем 443 и 8443 будут использовать сертификат SSL, но 80 будет проксировать HTTP.

Начиная с Kubernetes v1.9 и далее, вы можете использовать предопределенные политики SSL AWS с HTTPS или SSL для ваших Сервисов. Чтобы узнать, какие политики доступны для использования, вы можете использовать инструмент командной строки aws :

  aws elb describe-load-balancer-policies --query 'PolicyDescriptions []. PolicyName'

Затем вы можете указать любую из этих политик, используя « service.beta.kubernetes.io/aws-load-balancer-ssl-negotiation-policy » аннотация; например:

  метаданные:
      имя: my-service
      аннотации:
        услуга.beta.kubernetes.io/aws-load-balancer-ssl-negotiation-policy: "ELBSecurityPolicy-TLS-1-2-2017-01"
Поддержка протокола PROXY на AWS

Для включения протокола PROXY поддержку кластеров, работающих на AWS, вы можете использовать следующий сервис аннотация:

  метаданные:
      имя: my-service
      аннотации:
        service.beta.kubernetes.io/aws-load-balancer-proxy-protocol: «*»

Начиная с версии 1.3.0, использование этой аннотации применяется ко всем портам, проксируемым ELB. и не может быть настроен иначе.

Журналы доступа ELB на AWS

Есть несколько аннотаций для управления журналами доступа к сервисам ELB на AWS.

Аннотация service.beta.kubernetes.io/aws-load-balancer-access-log-enabled контролирует, включены ли журналы доступа.

Аннотация service.beta.kubernetes.io/aws-load-balancer-access-log-emit-interval контролирует интервал в минутах для публикации журналов доступа. Вы можете указать интервал 5 или 60 минут.

Аннотация service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name контролирует имя корзины Amazon S3, в которой хранятся журналы доступа к балансировщику нагрузки. хранится.

Аннотация service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix определяет логическую иерархию, созданную для корзины Amazon S3.

  метаданные:
      имя: my-service
      аннотации:
        service.beta.kubernetes.io/aws-load-balancer-access-log-enabled: "true"
        # Указывает, включены ли журналы доступа для балансировщика нагрузки
        услуга.beta.kubernetes.io/aws-load-balancer-access-log-emit-interval: «60»
        # Интервал публикации журналов доступа. Вы можете указать интервал 5 или 60 (минут).
        service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name: "my-bucket"
        # Имя корзины Amazon S3, в которой хранятся журналы доступа
        service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix: "my-bucket-prefix / prod"
        # Логическая иерархия, которую вы создали для своего ведра Amazon S3, например, `my-bucket-prefix / prod`
Соединение слива на AWS

Осушением соединения для Classic ELB можно управлять с помощью аннотации сервис.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled набор к значению "истина" . Аннотация service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout может также может использоваться для установки максимального времени в секундах, в течение которого существующие соединения остаются открытыми перед отменой регистрации экземпляров.

  метаданные:
      имя: my-service
      аннотации:
        service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled: "true"
        услуга.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout: «60»
Другие аннотации ELB

Существуют и другие аннотации для управления Classic Elastic Load Balancer, которые описаны ниже.

  метаданные:
      имя: my-service
      аннотации:
        service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout: «60»
        # Время в секундах, в течение которого соединение может находиться в режиме ожидания (данные не были отправлены по соединению) до того, как оно будет закрыто балансировщиком нагрузки

        услуга.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: "true"
        # Указывает, включена ли межзонная балансировка нагрузки для балансировщика нагрузки

        service.beta.kubernetes.io/aws-load-balancer-additional-resource-tags: "environment = prod, owner = DevOps"
        # Список пар ключ-значение, разделенных запятыми, которые будут записаны как
        # дополнительных тегов в ELB.

        service.beta.kubernetes.io/aws-load-balancer-healthcheck-healthy-threshold: ""
        # Количество последовательных успешных проверок работоспособности, необходимых для того, чтобы серверная часть
        # считаться пригодным для трафика.По умолчанию 2, должно быть от 2 до 10.

        service.beta.kubernetes.io/aws-load-balancer-healthcheck-unhealthy-threshold: «3»
        # Количество неудачных проверок работоспособности, необходимых для работы серверной части.
        # считается вредным для трафика. По умолчанию 6, должно быть от 2 до 10.

        service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval: «20»
        # Приблизительный интервал в секундах между проверками работоспособности
        # индивидуальный экземпляр. По умолчанию 10, должно быть от 5 до 300.

        услуга.beta.kubernetes.io/aws-load-balancer-healthcheck-timeout: «5»
        # Время в секундах, в течение которого отсутствие ответа означает сбой
        # проверка состояния здоровья. Это значение должно быть меньше, чем service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval.
        # ценить. По умолчанию 5, должно быть от 2 до 60.

        service.beta.kubernetes.io/aws-load-balancer-security-groups: «sg-53fae93f»
        # Список существующих групп безопасности, которые нужно настроить на созданном ELB. В отличие от аннотации
        # услуга.beta.kubernetes.io/aws-load-balancer-extra-security-groups, это заменяет все другие группы безопасности, ранее назначенные для ELB, а также отменяет создание
        # уникально созданной группы безопасности для этого ELB.
        # Первый идентификатор группы безопасности в этом списке используется в качестве источника для разрешения входящего трафика на целевые рабочие узлы (служебный трафик и проверки работоспособности).
        # Если несколько ELB настроены с одним и тем же идентификатором группы безопасности, только одна строка разрешения будет добавлена ​​в группы безопасности рабочего узла, это означает, что если вы удалите любой
        # из этих ELB будет удалена единственная строка разрешения и заблокирован доступ для всех ELB с одним и тем же идентификатором группы безопасности.# Это может вызвать перерыв в работе сервиса, если не используется должным образом

        service.beta.kubernetes.io/aws-load-balancer-extra-security-groups: «sg-53fae93f, sg-42efd82e»
        # Список дополнительных групп безопасности, которые должны быть добавлены в созданный ELB, это оставляет уникально сгенерированную группу безопасности на месте, это гарантирует, что каждый ELB
        # имеет уникальный идентификатор группы безопасности и соответствующую строку разрешения, чтобы разрешить трафик к целевым рабочим узлам (служебный трафик и проверки работоспособности).
        # Определенные здесь группы безопасности могут использоваться разными службами.service.beta.kubernetes.io/aws-load-balancer-target-node-labels: "ingress-gw, gw-name = public-api"
        # Список используемых пар ключ-значение, разделенных запятыми
        # для выбора целевых узлов для балансировщика нагрузки
Поддержка Network Load Balancer на AWS

СОСТОЯНИЕ ФУНКЦИИ: Kubernetes v1.15 [бета]

Чтобы использовать Network Load Balancer на AWS, используйте аннотацию service.beta.kubernetes.io/aws-load-balancer-type со значением nlb .

  метаданные:
      имя: my-service
      аннотации:
        service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
Примечание. NLB работает только с определенными классами экземпляров; см. документацию AWS на Elastic Load Balancing, чтобы получить список поддерживаемых типов экземпляров.

В отличие от классических эластичных балансировщиков нагрузки, сетевые балансировщики нагрузки (NLB) пересылают IP-адрес клиента до узла. Если служба .spec.externalTrafficPolicy установлен на Кластер , IP-адрес клиента не распространяется на конец Стручки.

При установке .spec.externalTrafficPolicy на Local клиентские IP-адреса размножаются до конечных стручков, но это может привести к неравномерному распределению движение. Узлы без каких-либо модулей для конкретной службы LoadBalancer выйдут из строя проверка работоспособности целевой группы NLB на автоматически назначенном .spec.healthCheckNodePort и не получают никакого трафика.

Для достижения равномерного трафика используйте DaemonSet или укажите стручок антиаффинности не располагаться на одном узле.

Вы также можете использовать службы NLB с внутренним балансировщиком нагрузки. аннотация.

Чтобы клиентский трафик достигал экземпляров за NLB, защита узла группы изменяются следующими IP-правилами:

Правило Протокол Порт (ы) IPRange (-а) Описание IPRange
Проверка работоспособности TCP NodePort ( .spec.healthCheckNodePort для .spec.externalTrafficPolicy = Local ) Подсеть CIDR kubernetes.io/rule/nlb/health=
Клиентский трафик TCP NodePort (ы) .spec.loadBalancerSourceRanges (по умолчанию 0.0.0.0/0 ) kubernetes.io/rule/nlb/client=
MTU Discovery ICMP 3,4 .spec.loadBalancerSourceRanges (по умолчанию 0.0,0.0 / 0 ) kubernetes.io/rule/nlb/mtu=

Чтобы ограничить IP-адреса клиентов, которые могут получить доступ к Network Load Balancer, укажите loadBalancerSourceRanges .

  спецификации:
  loadBalancerSourceRanges:
    - «143.231.0.0/16»

Примечание: Если .spec.loadBalancerSourceRanges не установлен, Kubernetes разрешает трафик от 0.0.0.0/0 к группам безопасности узла.Если узлы имеют общедоступные IP-адреса, имейте в виду, что трафик, не связанный с NLB, также может достигать всех экземпляров в этих измененных группах безопасности.

Дополнительную документацию по аннотациям для эластичных IP-адресов и других распространенных сценариев использования можно найти в документации по AWS Load Balancer Controller.

Другие аннотации CLB для Tencent Kubernetes Engine (TKE)

Существуют и другие аннотации для управления балансировщиками облачной нагрузки на TKE, как показано ниже.

  метаданные:
      имя: my-service
      аннотации:
        # Привязать балансировщики нагрузки к указанным узлам
        услуга.kubernetes.io/qcloud-loadbalancer-backends-label: введите (значение1, значение2)

        # ID существующего балансировщика нагрузки
        service.kubernetes.io/tke-existed-lbid：lb-6swtxxxx

        # Пользовательские параметры для балансировщика нагрузки (LB), пока не поддерживает изменение типа LB
        service.kubernetes.io/service.extensiveParameters: ""

        # Пользовательские параметры для прослушивателя LB
        service.kubernetes.io/service.listenerParameters: ""

        # Указывает тип балансировщика нагрузки;
        # допустимые значения: классический (Classic Cloud Load Balancer) или application (Application Cloud Load Balancer)
        услуга.kubernetes.io/loadbalance-type: xxxxx

        # Определяет метод выставления счетов за пропускную способность общедоступной сети;
        # допустимые значения: TRAFFIC_POSTPAID_BY_HOUR (счет за трафиком) и BANDWIDTH_POSTPAID_BY_HOUR (счет за пропускную способность).
        service.kubernetes.io/qcloud-loadbalancer-internet-charge-type: xxxxxx

        # Определяет значение полосы пропускания (диапазон значений: [1,2000] Мбит / с).
        service.kubernetes.io/qcloud-loadbalancer-internet-max-bandwidth-out: «10»

        # Когда эта аннотация установлена, балансировщики нагрузки будут регистрировать только узлы
        # с запущенным подом, иначе все узлы будут зарегистрированы.service.kubernetes.io/local-svc-only-bind-node-with-pod: правда

Тип Внешнее имя

Службы типа ExternalName сопоставляют Службу с именем DNS, а не с типичным селектором, таким как my-service или кассандра . Вы указываете эти службы с параметром spec.externalName .

Это определение службы, например, отображает my-service Service в пространстве имен prod до my.database.example.com :

  apiВерсия: v1
вид: Сервис
метаданные:
  имя: my-service
  пространство имен: prod
спецификация:
  тип: ExternalName
  externalName: my.database.example.com
Примечание. ExternalName принимает строку адреса IPv4, но как имя DNS, состоящее из цифр, а не как IP-адрес. Внешние имена, похожие на адреса IPv4, не разрешаются CoreDNS или ingress-nginx, поскольку ExternalName предназначен для указания канонического DNS-имени. Чтобы жестко закодировать IP-адрес, рассмотрите возможность использования безголовые службы.

При поиске узла my-service.prod.svc.cluster.local служба DNS кластера возвращает запись CNAME со значением my.database.example.com . Доступ my-service работает так же, как и другие службы, но с важными разница в том, что перенаправление происходит на уровне DNS, а не через проксирование или пересылка. Если вы позже решите переместить свою базу данных в кластер, вы может запускать свои модули, добавлять соответствующие селекторы или конечные точки и изменять Сервисный тип .

Предупреждение:

У вас могут возникнуть проблемы с использованием ExternalName для некоторых распространенных протоколов, включая HTTP и HTTPS. Если вы используете ExternalName, то имя хоста, используемое клиентами внутри вашего кластера, отличается от имени, на которое ссылается ExternalName.

Для протоколов, использующих имена хостов, это различие может привести к ошибкам или неожиданным ответам. HTTP-запросы будут иметь заголовок Host: , который исходный сервер не распознает; Серверы TLS не смогут предоставить сертификат, соответствующий имени хоста, к которому подключился клиент.

Внешние IP-адреса

Если есть внешние IP-адреса, которые маршрутизируют один или несколько узлов кластера, Kubernetes Services могут быть доступны на этих внешних IP-адресов . Трафик, входящий в кластер с внешним IP-адресом (в качестве IP-адреса назначения), на служебном порте, будет направлен на одну из конечных точек службы. externalIPs не управляется Kubernetes и находится под его ответственностью администратора кластера.

В спецификации службы externalIPs могут быть указаны вместе с любым из ServiceTypes .В приведенном ниже примере к « my-service » могут получить доступ клиенты на « 80.11.12.10:80 » ( externalIP: порт )

  apiВерсия: v1
вид: Сервис
метаданные:
  имя: my-service
спецификация:
  селектор:
    приложение: MyApp
  порты:
    - имя: http
      протокол: TCP
      порт: 80
      targetPort: 9376
  externalIPs:
    - 80.11.12.10

Недостатки

Использование прокси пользовательского пространства для VIP-персон работает в малых и средних масштабах, но будет не масштабируются до очень больших кластеров с тысячами служб.В оригинальное дизайнерское предложение порталов есть более подробная информация об этом.

Использование прокси-сервера пользовательского пространства скрывает исходный IP-адрес пакета, сервис. Это делает невозможными некоторые виды сетевой фильтрации (брандмауэра). Iptables прокси-режим не работает неясные исходные IP-адреса в кластере, но это по-прежнему влияет на клиентов, проходящих через балансировщик нагрузки или узел-порт.

Поле Тип разработано как вложенная функциональность — каждый уровень добавляет предыдущий. Это строго не требуется для всех облачных провайдеров (например, для облачных сервисов).грамм. Google Compute Engine делает не нужно выделять NodePort , чтобы LoadBalancer работал, но AWS это делает) но текущий API требует этого.

Внедрение виртуального IP

Предыдущей информации должно быть достаточно для многих людей, которые хотят использовать Сервисы. Однако за кулисами происходит многое, что может быть стоит понять.

Предотвращение столкновений

Одна из основных философий Kubernetes заключается в том, что вы не должны подвержены ситуациям, которые могут привести к провалу ваших действий не по вине своих собственных.Для дизайна ресурса Сервиса это означает, что вы выбираете свой собственный номер порта, если этот выбор может противоречить чужой выбор. Это отказ изоляции.

Чтобы вы могли выбрать номер порта для ваших Сервисов, мы должны убедитесь, что никакие две службы не могут конфликтовать. Kubernetes делает это, выделяя каждый Сервис имеет собственный IP-адрес.

Чтобы гарантировать, что каждая служба получает уникальный IP-адрес, внутренний распределитель атомарно обновляет глобальную карту распределения в etcd перед созданием каждой Услуги.Объект карты должен существовать в реестре для Услуги для присвоения IP-адресов, в противном случае творения будут сбой с сообщением, указывающим, что IP-адрес не может быть выделен.

В плоскости управления за создание этого карта (необходима для поддержки перехода со старых версий Kubernetes, которые использовали блокировка в памяти). Kubernetes также использует контроллеры для проверки недействительности назначения (например, из-за вмешательства администратора) и для очистки выделенных IP-адреса, которые больше не используются никакими Сервисами.

Служебные IP-адреса

В отличие от IP-адресов Pod, которые фактически направляются к фиксированному месту назначения, На служебные IP-адреса фактически не отвечает ни один хост. Вместо этого kube-proxy использует iptables (логика обработки пакетов в Linux) для определения виртуальных IP-адресов которые при необходимости перенаправляются прозрачно. Когда клиенты подключаются к VIP, их трафик автоматически передается в соответствующую конечную точку. Переменные среды и DNS для служб фактически заполняются в условия виртуального IP-адреса (и порта) Сервиса.

kube-proxy поддерживает три режима прокси: пользовательское пространство, iptables и IPVS, которые каждый работает немного по-своему.

Пространство пользователя

В качестве примера рассмотрим приложение для обработки изображений, описанное выше. Когда создается серверная служба, мастер Kubernetes назначает виртуальную IP-адрес, например 10.0.0.1. Предполагая, что служебный порт — 1234, За сервисом наблюдают все экземпляры kube-proxy в кластере. Когда прокси-сервер видит новую службу, он открывает новый случайный порт, устанавливает iptables перенаправляет с виртуального IP-адреса на этот новый порт и начинает принимать связи на нем.

Когда клиент подключается к виртуальному IP-адресу службы, iptables Правило срабатывает и перенаправляет пакеты на собственный порт прокси. «Прокси-сервер службы» выбирает серверную часть и начинает проксировать трафик от клиента к серверной части.

Это означает, что владельцы сервисов могут выбрать любой порт, который они хотят, без риска столкновение. Клиенты могут подключаться к IP и порту, не зная из которых они фактически получают доступ.

iptables

Снова рассмотрим приложение для обработки изображений, описанное выше.Когда создается серверная служба, плоскость управления Kubernetes назначает виртуальную IP-адрес, например 10.0.0.1. Предполагая, что служебный порт — 1234, За сервисом наблюдают все экземпляры kube-proxy в кластере. Когда прокси-сервер видит новую службу, он устанавливает серию правил iptables, которые перенаправление с виртуального IP-адреса на правила для каждой службы. За услугу правила связаны с правилами для каждой конечной точки, которые перенаправляют трафик (с использованием NAT назначения) к бэкэндам.

Когда клиент подключается к виртуальному IP-адресу службы, срабатывает правило iptables.Выбирается серверная часть (либо на основе схожести сеанса, либо случайным образом), и пакеты перенаправлен на бэкэнд. В отличие от прокси пользовательского пространства, пакеты никогда не скопировано в пользовательское пространство, kube-proxy не обязательно должен быть запущен для виртуального IP-адрес для работы, и узлы видят трафик, поступающий с неизмененного IP-адреса клиента. адрес.

Этот же базовый поток выполняется, когда трафик входит через узел-порт или через балансировщик нагрузки, хотя в этих случаях IP-адрес клиента действительно изменяется.

ИПВС

операции iptables резко замедляются в крупномасштабном кластере e.g 10 000 услуг. IPVS разработан для балансировки нагрузки и основан на хэш-таблицах ядра. Таким образом, вы можете добиться стабильной производительности в большом количестве сервисов с помощью kube-proxy на основе IPVS. Между тем, kube-proxy на основе IPVS имеет более сложные алгоритмы балансировки нагрузки (минимум соединений, локальность, взвешенность, постоянство).

Объект API

Служба

— это ресурс верхнего уровня в Kubernetes REST API. Вы можете найти более подробную информацию об объекте API по адресу: Объект Service API.

Поддерживаемые протоколы

TCP

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

UDP

UDP можно использовать для большинства служб. Для type = LoadBalancer Services, поддержка UDP зависит от поставщика облачных услуг, предлагающего эту возможность.

SCTP

СОСТОЯНИЕ ФУНКЦИИ: Kubernetes v1.20 [стабильный]

При использовании сетевого плагина, поддерживающего трафик SCTP, вы можете использовать SCTP для большинство услуг. Для type = LoadBalancer Services поддержка SCTP зависит от облака. поставщик, предлагающий эту услугу. (Большинство не делают).

Предупреждения
Поддержка многосетевых ассоциаций SCTP
Предупреждение:

Для поддержки многосетевых ассоциаций SCTP требуется, чтобы подключаемый модуль CNI мог поддерживать назначение нескольких интерфейсов и IP-адресов модулю.

NAT для многосетевых ассоциаций SCTP требует специальной логики в соответствующих модулях ядра.

Окна

Примечание. SCTP не поддерживается узлами на базе Windows.

Пользовательское пространство kube-proxy

Предупреждение: kube-proxy не поддерживает управление ассоциациями SCTP, когда он находится в режиме пользовательского пространства.

HTTP

Если ваш облачный провайдер поддерживает это, вы можете использовать Сервис в режиме LoadBalancer. для настройки внешнего обратного проксирования HTTP / HTTPS, перенаправляемого на конечные точки службы.

Примечание: Вы также можете использовать Ingress вместо Сервиса. чтобы открыть службы HTTP / HTTPS.

Протокол PROXY

Если ваш облачный провайдер поддерживает это, вы можете использовать службу в режиме LoadBalancer для настройки балансировщика нагрузки вне самого Kubernetes, который будет перенаправлять соединения с префиксом ПРОКСИ протокол.

Балансировщик нагрузки отправит начальную серию октетов, описывающих входящее соединение, аналогично этому примеру

  ПРОКСИ TCP4 192.0.2.202 10.0.42.7 12345 7 \ r \ n

, за которыми следуют данные от клиента.

Что дальше?

Последнее изменение 12 ноября 2021 г., 21:32 PST : Исправить неработающую ссылку привязки # type-nodeport в service.md (# 30388) (7a513e6de)

Глава 4. Конфигурация сети и портов Red Hat JBoss Enterprise Application Platform 7.0

JBoss EAP ссылается на именованные интерфейсы на протяжении всей конфигурации. Это позволяет конфигурации ссылаться на отдельные объявления интерфейса с логическими именами, вместо того, чтобы запрашивать полную информацию об интерфейсе при каждом использовании.

Это также позволяет упростить настройку в управляемом домене, где детали сетевого интерфейса могут различаться на разных машинах. Каждому экземпляру сервера может соответствовать группа логических имен.

Файлы standalone.xml , domain.xml и host.xml содержат объявления интерфейсов. Существует несколько предварительно настроенных имен интерфейсов, в зависимости от того, какая конфигурация используется по умолчанию. Интерфейс управления может использоваться для всех компонентов и служб, которым требуется уровень управления, включая конечную точку управления HTTP.Общедоступный интерфейс может использоваться для всех сетевых коммуникаций, связанных с приложениями. Небезопасный интерфейс используется для сокетов IIOP в стандартной конфигурации. Частный интерфейс используется для сокетов JGroups в стандартной конфигурации.

4.1.1. Конфигурации интерфейсов по умолчанию 

 <интерфейсы>

По умолчанию JBoss EAP связывает эти интерфейсы с 127.0.0.1 , но эти значения можно переопределить во время выполнения, установив соответствующее свойство.Например, внутренний адрес общедоступного интерфейса может быть установлен при запуске JBoss EAP в качестве автономного сервера с помощью следующей команды.

 $ EAP_HOME / bin / standalone.sh -Djboss.bind.address = IP_ADDRESS

В качестве альтернативы вы можете использовать переключатель -b в командной строке запуска сервера. Дополнительные сведения о параметрах запуска сервера см. В разделе «Аргументы среды выполнения сервера».

Если вы изменяете сетевые интерфейсы или порты по умолчанию, которые использует JBoss EAP, вы также должны не забыть изменить любые сценарии, использующие измененные интерфейсы или порты.К ним относятся сценарии службы JBoss EAP, а также необходимость указывать правильный интерфейс и порт при доступе к консоли управления или интерфейсу командной строки управления.

4.1.2. Настройка интерфейсов

Сетевые интерфейсы объявляются путем указания логического имени и критериев выбора для физического интерфейса. Критерии выбора могут ссылаться на адрес с подстановочными знаками или указывать набор из одной или нескольких характеристик, которые должен иметь интерфейс или адрес, чтобы быть допустимым соответствием.Список всех доступных критериев выбора интерфейса см. В разделе «Атрибуты интерфейса».

Интерфейсы можно настроить с помощью консоли управления или интерфейса командной строки управления. Ниже приведены несколько примеров добавления и обновления интерфейсов. Сначала отображается команда интерфейса командной строки управления, за которой следует соответствующий XML-код конфигурации.

Добавить интерфейс со значением NIC

Добавьте новый интерфейс со значением NIC eth0 .

 / interface = external: add (nic = eth0)
Добавить интерфейс с несколькими условными значениями

Добавьте новый интерфейс, который соответствует любому интерфейсу / адресу в правильной подсети, если он включен, поддерживает многоадресную рассылку и не является двухточечным.

 /interface=default:add(subnet-match=192.168.0.0/16,up=true,multicast=true,not={point-to-point=true}) 
 
   
   <вверх />
   
   <не>
      <точка-точка />
Обновление атрибута интерфейса

Обновите значение по умолчанию inet-address общедоступного интерфейса , сохранив значение jboss.bind.address , чтобы разрешить установку этого значения во время выполнения.

 /interface=public:write-attribute(name=inet-address,value="${jboss.bind.address:192.168.0.0} ")
Добавить интерфейс к серверу в управляемом домене 
 /host=master/server-config=SERVER_NAME/interface=INTERFACE_NAME:add(inet-address=127.0.0.1) 
 
   
      <интерфейсы>

Привязки сокетов и группы привязок сокетов позволяют вам определять сетевые порты и их отношение к сетевым интерфейсам, необходимым для вашей конфигурации JBoss EAP. Привязка сокета - это именованная конфигурация для сокета. Группа привязки сокета - это набор объявлений привязки сокета, сгруппированных под логическим именем.

Это позволяет другим разделам конфигурации ссылаться на привязки сокетов по их логическому имени, вместо того, чтобы требовать полную информацию о конфигурации сокета при каждом использовании.

Объявления для этих именованных конфигураций можно найти в файлах конфигурации standalone.xml и domain.xml . Автономный сервер содержит только одну группу привязки сокетов, а управляемый домен может содержать несколько групп. Вы можете создать группу привязки сокетов для каждой группы серверов в управляемом домене или совместно использовать группу привязки сокетов между несколькими группами серверов.

Порты, используемые JBoss EAP по умолчанию, зависят от используемых групп привязки сокетов и требований ваших индивидуальных развертываний.

Порты управления были объединены в JBoss EAP 7. По умолчанию JBoss EAP 7 использует порт 9990 как для собственного управления, используемого интерфейсом командной строки управления, так и для управления HTTP, используемого веб-консолью управления. Порт 9999 , который использовался как собственный порт управления в JBoss EAP 6, больше не используется, но при желании его можно включить.

Если для консоли управления включен HTTPS, по умолчанию используется порт 9993 .

4.2.2. Привязки сокетов по умолчанию

JBoss EAP поставляется с группой привязки разъемов для каждого из четырех предопределенных профилей ( по умолчанию , га , полный , полный ).

Для получения подробной информации о привязках сокетов по умолчанию, таких как порты и описания по умолчанию, см. Раздел «Привязки сокетов по умолчанию».

Если вы изменяете сетевые интерфейсы или порты по умолчанию, которые использует JBoss EAP, вы также должны не забыть изменить любые сценарии, использующие измененные интерфейсы или порты.К ним относятся сценарии службы JBoss EAP, а также необходимость указывать правильный интерфейс и порт при доступе к консоли управления или интерфейсу командной строки управления.

Автономный сервер

При работе в качестве автономного сервера для каждого файла конфигурации определяется только одна группа привязки сокетов. Каждый автономный файл конфигурации ( standalone.xml , standalone-ha.xml , standalone-full.xml , standalone-full-ha.xml ) определяет привязки сокетов для технологий, используемых в соответствующем профиле.

Например, в автономном файле конфигурации по умолчанию ( standalone.xml ) указаны следующие привязки сокетов.

 
    
    
    <привязка сокета name = "ajp" port = "$ {jboss.ajp.port: 8009}" />
    <привязка сокета name = "http" port = "$ {jboss.http.port: 8080}" />
    
    <имя-привязки сокета = "txn-recovery-environment" порт = "4712" />
    <имя-привязки сокета = "txn-status-manager" порт = "4713" />
    
        <удаленный целевой хост = "localhost" порт = "25" />
Управляемый домен

При работе в управляемом домене все группы привязки сокетов определены в домене .xml файл. Существует четыре предопределенных группы привязки сокетов:

  • розетки стандартные
  • га розеток
  • полнопроходные
  • гнезда полноприводные

Каждая группа привязки сокетов определяет привязки сокетов для технологий, используемых в соответствующем профиле. Например, группа привязки сокетов full-ha-sockets определяет несколько привязок сокетов jgroups , которые используются профилем full-ha для обеспечения высокой доступности.

 <группы-привязки сокетов>
    
        
        <привязка сокета name = "ajp" port = "$ {jboss.ajp.port: 8009}" />
        <привязка сокета name = "http" port = "$ {jboss.http.port: 8080}" />
        
        <имя-привязки сокета = "txn-recovery-environment" порт = "4712" />
        <имя-привязки сокета = "txn-status-manager" порт = "4713" />
        
            <удаленный целевой хост = "localhost" порт = "25" />
        
    
    
        
    ...
    
    
        
    ...
    
    
        
        <привязка сокета name = "ajp" port = "$ {jboss.ajp.port: 8009}" />
        <имя привязки сокета = "http" port = "$ {jboss.http.port: 8080} "/>
        
        <привязка сокета name = "iiop" interface = "unsecure" port = "3528" />
        
        
        
        
        <имя-привязки сокета = "jgroups-udp" interface = "private" port = "55200" multicast-address = "$ {jboss.default.multicast.address: 230.0.0.4} "multicast-port =" 45688 "/>
        
        
        <имя-привязки сокета = "txn-recovery-environment" порт = "4712" />
        <имя-привязки сокета = "txn-status-manager" порт = "4713" />
        
            <удаленный целевой хост = "localhost" порт = "25" />

Конфигурация сокета для интерфейсов управления определяется на хосте контроллера домена.xml файл.

4.2.3. Настройка привязки сокетов

При определении привязки сокета вы можете настроить атрибуты порта и интерфейса , а также параметры многоадресной рассылки, такие как многоадресный адрес и многоадресный порт . Дополнительные сведения обо всех доступных атрибутах привязки сокетов см. В разделе «Атрибуты привязки сокетов».

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

  1. Добавьте новую группу привязки сокета. Обратите внимание, что этот шаг нельзя выполнить при работе в качестве автономного сервера.

     / группа-привязка-сокетов = новые-сокеты: добавить (интерфейс по умолчанию = общедоступный)

  2. Добавьте привязку сокета.

     / socket-binding-group = new-sockets / socket-binding = new-socket-binding: add (port = 1234)

  3. . Измените привязку сокета, чтобы использовать интерфейс, отличный от интерфейса по умолчанию, который задается группой привязки сокета.

     / socket-binding-group = new-sockets / socket-binding = new-socket-binding: write-attribute (name = interface, value = unsecure)

. В следующем примере показано, как может выглядеть конфигурация XML после выполнения вышеуказанных шагов.

 <группы-привязки сокетов>
    ...

Смещение порта - это числовое значение смещения, добавляемое ко всем значениям портов, указанным в группе привязки сокета для этого сервера.Это позволяет серверу наследовать значения портов, определенные в его группе привязки сокетов, со смещением, чтобы гарантировать, что он не конфликтует с другими серверами на том же хосте. Например, если HTTP-порт группы привязки сокетов - 8080 , а сервер использует смещение порта 100 , то его HTTP-порт - 8180 .

Ниже приведен пример установки смещения порта 250 для сервера в управляемом домене с помощью интерфейса командной строки управления.

 / host = master / server-config = server-two /: атрибут записи (имя = смещение привязки-порта, значение = 250)

Смещения портов могут использоваться для серверов в управляемом домене и для запуска нескольких автономных серверов на одном хосте.

Вы можете передать смещение порта при запуске автономного сервера, используя свойство jboss.socket.binding.port-offset .

 $ EAP_HOME / bin / standalone.sh -Djboss.socket.binding.port-offset = 100

По умолчанию JBoss EAP настроен для работы с использованием адресов IPv4.Следующие шаги показывают, как настроить JBoss EAP для работы с использованием адресов IPv6.

Настроить стек JVM для адресов IPv6

Обновите конфигурацию запуска, чтобы отдавать предпочтение адресам IPv6.

  1. Откройте файл конфигурации запуска.

    • При работе в качестве автономного сервера отредактируйте файл EAP_HOME / bin / standalone.conf (или standalone.conf.bat для Windows Server).
    • При работе в управляемом домене отредактируйте EAP_HOME / bin / domain.conf (или domain.conf.bat для Windows Server).

  2. Установите для свойства java.net.preferIPv4Stack значение false .

     -Djava.net.preferIPv4Stack = false

  3. Добавьте свойство java.net.preferIPv6Addresses и установите для него значение true .

     -Djava.net.preferIPv6Addresses = true

В следующем примере показано, как параметры JVM в файле конфигурации запуска могут выглядеть после внесения вышеуказанных изменений.

 # Укажите параметры для передачи виртуальной машине Java.
#
если ["x $ JAVA_OPTS" = "x"]; тогда
   JAVA_OPTS = "- Xms1303m -Xmx1303m -Djava.net.preferIPv4Stack = false"
   JAVA_OPTS = "$ JAVA_OPTS -Djboss.modules.system.pkgs = $ JBOSS_MODULES_SYSTEM_PKGS -Djava.awt.headless = true"
   JAVA_OPTS = "$ JAVA_OPTS -Djava.net.preferIPv6Addresses = true"
else
Обновить объявления интерфейса для адресов IPv6

Значения интерфейса по умолчанию в конфигурации можно изменить на адреса IPv6. Например, приведенная ниже команда интерфейса командной строки управления устанавливает для интерфейса управления адрес обратной связи IPv6 ( :: 1 ).

 /interface=management:write-attribute(name=inet-address,value="${jboss.bind.address.management:[::1]} ")

В следующем примере показано, как может выглядеть конфигурация XML после выполнения указанной выше команды.

 <интерфейсы>
    
        
    
    ....

Порты по умолчанию для реестра NiFi и NiFi

Справочник по портам по умолчанию для реестра NiFi и NiFi.

NiFi

В следующей таблице перечислены порты по умолчанию, используемые NiFi, и соответствующие свойства в файл nifi.properties. При необходимости вы можете изменить эти значения.

примечание

  • Значения по умолчанию устанавливаются Cloudera Manager.
  • Если вы установите двоичные файлы только для NiFi, не управляемые Cloudera Manager, значения по умолчанию будут разные, их можно найти в файле nifi.properties.
Функция Имущество Значение по умолчанию, установленное Cloudera Manager
Порт HTTP нифи.web.http.port 8080
Порт HTTPS nifi.web.https.port 8443
Разъем удаленного входа, порт nifi.remote.input.socket.port нет
Протокол узла кластера Порт nifi.cluster.node.protocol.port 9088
Порт балансировки нагрузки узла кластера нифи.cluster.node.load.balance.port

6342

Порт перенаправления веб-HTTP nifi.web.http.port.forwarding

нет

Реестр NiFi

В следующей таблице перечислены порты по умолчанию, используемые NiFi Registry, и соответствующие недвижимость в нифи-реестре.файл свойств. Вы можете изменить эти значения как требуется.

примечание

Если вы устанавливаете двоичные файлы только для NiFi, не управляемые Cloudera Manager, то:

  • При включении HTTPS отключите свойство nifi.registry.web.http.port .
  • Значения по умолчанию будут другими, их можно найти в файл nifi-registry.properties.
Функция Имущество Значение по умолчанию, установленное Cloudera Manager
Порт HTTP нифи.registry.web.http.port 18080
Порт HTTPS nifi.registry.web.https.port 18433

Установка порта HTTP Squid

Первая опция в файле squid.conf устанавливает порт (ы) HTTP, который Squid будет слушать входящие запросы.

Сетевые службы прослушивают определенные порты. Порты ниже 1024 могут используются только системным администратором и используются программами которые предоставляют базовые интернет-сервисы: SMTP, POP, DNS и HTTP (Интернет).Порты выше 1024 используются для ненадежных сервисов (где сервис не запускается от имени администратора), а также для временных подключений, таких как исходящие запросы данных.

Обычно веб-серверы прослушивают входящие веб-запросы (используя Протокол передачи гипертекста - HTTP) на порт 80.

Порт HTTP Squid по умолчанию - 3129 . Многие люди запускают свой кеш серверы на порту, который легче запомнить: что-то вроде 80 или 8080 ). Если вы выберете порт с низким номером, вы нужно будет запустить Squid как root (иначе вы будете считаться unrusted , и вы не сможете запустить Squid.Многие интернет-провайдеры используйте порт 8080, что делает его принятым псевдостандартным .

При желании вы можете использовать несколько портов, добавив второй номер порта. в переменную http_port . Вот пример:

http_port 3128 8080

Очень важно обращаться к вашему кэш-серверу с общим DNS имя. Тот факт, что у вас сейчас только один сервер, не означает, что не стоит строить планы на будущее. Хорошая идея - настроить DNS. имя хоста для вашего прокси-сервера.Сделай это прямо сейчас! Простая запись DNS может сэкономить много часов в дальнейшем. Настройка клиентских машин для доступа к кеш-серверу по IP-адресу требует долгого, мучительного переход по дороге. Обычно люди добавляют имя хоста, например cache.mydomain.com в DNS. Другие люди предпочитают имя прокси и создайте имя вроде proxy.mydomain.com .

HTTP определяет формат как запроса информации, так и формат ответа сервера.Основные аспекты протокола довольно прямо: клиент (например, ваш браузер) подключается к порту 80 и запрашивает файл, указав полный путь и имя файла, он хочет скачать. Клиент также указывает версию Протокол HTTP, который он хочет использовать для поиска.

Формат прокси-запроса немного отличается. Клиент указывает весь URL-адрес, а не только путь к файлу. Затем прокси-сервер подключается к веб-серверу, указанному в URL-адресе, и отправляет обычный HTTP-запрос для страницы.(? Формат HTTP-запросов более подробно описано в главе 4, где вы вводите HTTP-запрос, так же, как браузер отправил бы его, чтобы проверить, что кеш реагирует на запросы - может вместо этого использовать программу-клиент?)

Так как формат запросов прокси очень похож на обычный HTTP запроса, неудивительно, что многие веб-серверы могут также работают как прокси-серверы. Изменение программы веб-сервера для работы поскольку прокси обычно включает в себя сравнительно небольшие изменения в коде, особенно если код написан по модульному принципу - как и веб-сервер Apache.Во многих случаях, в результате сервер не такой быстрый или настраиваемый, как выделенный кеш-сервер может быть.

Веб-сервер ЦЕРН httpd был первым широко доступным веб-сервером. Прокси сервер. Вся система WWW изначально создавалась, чтобы дать людям легкий доступ к данным CERN, и поэтому CERN HTTPD фактически стал испытательной площадкой для новых дополнений к исходной неофициальной спецификации HTTP. Самый (и, конечно же, на каком-то этапе все ) первых веб-сайтов сервер ЦЕРН. Многие системные администраторы хотели прокси-сервер просто использовали свой стандартный веб-сервер CERN (прослушивание порта 80) как их прокси-сервер, поскольку он может функционировать как один.Это легко для веб-сервер, чтобы отличить запрос веб-сайта от обычной веб-страницы запрос, так как он просто должен проверить, указан ли полный URL вместо простого имени пути. Учитывая выбор (даже сегодня) многие системные администраторы выберут порт 80 в качестве прокси-сервера порт просто как «порт 80 является стандартным портом для веб-запросов».

Однако есть веские причины выбрать порт , отличный от . 80.

Запуск обеих служб на одном порте означал, что если системный администратор хотел установить другой пакет веб-сервера (для получения дополнительных функций в новом программном обеспечении) они будут ограничены программным обеспечением, которое может выполнять оба как веб-сервер и как прокси.Аналогично, если тот же системный администратор обнаружил, что низкоуровневый прокси-модуль их веб-сервера не мог справиться с нагрузкой их постоянно расширяющаяся локальная клиентская база, они будут ограничены прокси-сервером который может функционировать как веб-сервер. Единственная альтернатива - перенастроить всех клиентов, что обычно требует затрат дней, чтобы извиниться перед пользователями и помочь им пройти этапы, связанные с переходя.

Microsoft использует веб-сервер Microsoft (IIS) в качестве основы для своего прокси-сервера компонент, и прокси-сервер Microsoft, таким образом, только (? пробовал один раз - посмотрим, он изменился с тех пор?) принимает входящий запрос прокси на порт 80.Если ты установка системы Squid для замены запущенных в CERN, Apache или IIS оба режима веб-сервера и кеш-сервера на одном и том же порте, вам нужно будет установите http_port на 80. Squid написан только как высокопроизводительный прокси-сервер, поэтому он не может работать как веб-сервер, поскольку Squid не поддерживает чтение файлов с локального диска, на котором запущен CGI. скрипты и так далее. Однако есть обходной путь.

Если у вас есть обе службы, работающие на одном порте, и вы не можете смени свой клиентский компьютер, не отчаивайтесь.Squid может принимать запросы в формат веб-сервера и перенаправить их на другой сервер. Если у вас только один машине, и вы можете настроить программное обеспечение веб-сервера для приема входящих запросов на порт, отличный от порта по умолчанию (например, 81), Squid может быть настроен на пересылку входящие веб-запросы к этому порту. Это называется режим ускорителя (поскольку его первоначальная цель заключалась в ускорении очень медленных веб-серверов). Кальмар эффективно выполняет перевод исходного запроса, а затем просто действует так, как если бы запрос был запросом прокси, и подключается к хосту: тот факт, что это не удаленный хост, не имеет значения.Режим акселератора более подробно обсуждается в главе 9. А пока установите Squid и работает на другом порту, и проработайте первую пару глав этой книги, пока у вас не будет работающая пилотная система. Как только Squid станет стабильным и протестированным, вы можете переходить к смене веб-сервера. настройки. Однако, если вы любите приключения, вы можете пропустить это в ближайшее время!

Где хранить кэшированные данные

Кэшированные данные должны где-то храниться. В разделе о фурнитуре При выборе размера мы обсудили размер и количество дисков, которые будут использоваться для кэширования.Однако Squid не может автоматически определять, где хранить эти данные, поэтому вам нужно чтобы сообщить Squid, какие каталоги он может использовать для хранения данных.

Оператор cache_dir в squid.conf файл используется для настройки специальные складские помещения. Если вы используете более одного диска для кэшированные данные, вам может понадобиться более одной точки монтирования (например, / usr / local / squid / cache1 для первого диска, / usr / local / squid / cache2 для второго). Кальмар позволяет иметь более одного cache_dir вариант в вашем файле конфигурации.

Рассмотрим только одну запись cache_dir в тем временем. Здесь я использую стандартные значения по умолчанию. squid.conf .

cache_dir / usr / local / squid / cache / 100 16256

Первый вариант для cache_dir тег устанавливает каталог, в котором будут храниться данные. Значение префикса просто имеет / cache / , помеченный в конце и он используется как каталог по умолчанию. Этот каталог также сделан команда make install , которую мы использовали ранее.

Следующая опция для cache_dir проста: это значение размера. Squid будет хранить до этого количества данных в этом каталоге. В значение в мегабайтах, поэтому кеш-хранилища. По умолчанию 100 мегабайт.

Два других варианта более сложные: они устанавливают количество подкаталоги (первый и второй уровень) для создания в этом каталоге. Squid создает множество каталогов и хранит по несколько файлов в каждом из них. в попытке ускорить доступ к диску (найти правильную запись в каталог с одним миллионом файлов неэффективен: лучше чтобы разбить файлы на множество меньших наборов файлов... не пока слишком сильно об этом беспокоюсь). Я предлагаю вам использовать значения по умолчанию для этих параметров в среднем: если у вас очень большое хранилище кеша, вы можете захотеть увеличить эти значения, но это рассматривается в разделе о

Сетевые политики | Документация по программе ThoughtSpot

80

TCP

nginx

входящий

Все узлы

Все узлы

Первичный HTTP-порт приложения (nginx)

443

TCP

Безопасный nginx

входящий

Все узлы

Все узлы

Первичный порт HTTPS приложения (nginx)

2100

RPC

Порт RPC Oreo

двунаправленный

Все узлы

Все узлы

Демон узла RPC

2101

HTTP

Порт HTTP Oreo

двунаправленный

IP-адреса администратора и все узлы

Все узлы

Демон узла HTTP

2181

TCP

Серверы Zookeeper прослушивают этот порт RPC для клиентских подключений

двунаправленный

Все узлы

Все узлы

Серверы Zookeeper прослушивают этот порт RPC для клиентских подключений

3181

TCP

Серверы Zookeeper прослушивают этот порт RPC для клиентских подключений

двунаправленный

Все узлы

Все узлы

Серверы Zookeeper прослушивают этот порт RPC для клиентских подключений

4181

TCP

Серверы Zookeeper прослушивают этот порт RPC для клиентских подключений

двунаправленный

Все узлы

Все узлы

Серверы Zookeeper прослушивают этот порт RPC для клиентских подключений

2200

RPC

Главный порт RPC Orion

двунаправленный

Все узлы

Все узлы

Внутренняя связь с менеджером кластера

2201

HTTP

Главный HTTP-порт Orion

двунаправленный

IP-адреса администратора и все узлы

Все узлы

Порт, используемый для отладки диспетчера кластера

2205

TCP

TCP-порт службы обновления кластера

двунаправленный

Все узлы

Все узлы

Внутренняя связь с менеджером кластера

2210

RPC

Порт RPC службы статистики кластера

двунаправленный

Все узлы

Все узлы

Внутренняя связь со сборщиком статистики

2211

HTTP

Служба статистики кластера HTTP-порт

двунаправленный

IP-адреса администратора и все узлы

Все узлы

Порт, используемый для отладки сборщика статистики

2230

RPC

Порт RPC сборщика статистики Callosum

двунаправленный

Все узлы

Все узлы

Внутренняя связь со сборщиком статистики BI

2231

HTTP

Сборщик статистики Callosum HTTP-порт

двунаправленный

IP-адреса администратора и все узлы

Все узлы

Порт, используемый для отладки сборщика статистики BI

2240

RPC

Менеджер оповещений

двунаправленный

Все узлы

Все узлы

Порт, через который служба оповещения принимает события оповещения

2241

RPC

Менеджер оповещений

двунаправленный

Все узлы

Все узлы

Порт, через который служба оповещения принимает события оповещения

2888

RPC

Порты, используемые серверами Zookeeper для связи между собой

двунаправленный

Все узлы

Все узлы

Порты, используемые серверами Zookeeper для связи между собой

3181

RPC

Порты, используемые серверами Zookeeper для связи между собой

двунаправленный

Все узлы

Все узлы

Порты, используемые серверами Zookeeper для связи между собой

3888

RPC

Порты, используемые серверами Zookeeper для связи между собой

двунаправленный

Все узлы

Все узлы

Порты, используемые серверами Zookeeper для связи между собой

4000

RPC

Falcon worker RPC-порт

двунаправленный

Все узлы

Все узлы

Порт, используемый кешем данных для связи между собой

4001

HTTP

Falcon worker HTTP-порт

двунаправленный

IP-адреса администратора и все узлы

Все узлы

Порт, используемый для отладки кэша данных

4002

HTTP

Falcon worker HTTP-порт

двунаправленный

IP-адреса администратора и все узлы

Все узлы

Порт, используемый для отладки кэша данных

4003

RPC

Falcon worker RPC-порт

двунаправленный

Все узлы

Все узлы

Порт, используемый кешем данных для связи между собой

4004

RPC

Falcon worker RPC-порт

двунаправленный

Все узлы

Все узлы

Порт, используемый кешем данных для связи между собой

4021

RPC

Порт службы метаданных Sage (экспортируется Tomcat), службы Callosum, такие как службы метаданных, служба зависимости от medata, служба планирования, служба без сеанса, служба Spotiq

двунаправленный

Все узлы

Все узлы

Порт, по которому служба поиска связывается со службой метаданных для получения метаданных

4181

RPC

Порты, используемые серверами Zookeeper для связи между собой

двунаправленный

Все узлы

Все узлы

Порты, используемые серверами Zookeeper для связи между собой

4201

HTTP

Сервер Sage автозаполнения Порт интерфейса HTTP

двунаправленный

IP-адреса администратора и все узлы

Все узлы

Порт, используемый для отладки поисковой службы

4231

HTTP

Сервер индексации Sage HTTP-порт

двунаправленный

IP-адреса администратора и все узлы

Все узлы

Порт, используемый для отладки поисковой службы

4232

RPC

Порт подписчика метаданных сервера индексации Sage

двунаправленный

Все узлы

Все узлы

Порт, используемый для внутренней связи поисковой службы

4233

RPC

Порт RPC сервера индексирования Sage

двунаправленный

Все узлы

Все узлы

Порт, используемый для внутренней связи поисковой службы

4241

HTTP

Сервер автозаполнения Sage HTTP-порт

двунаправленный

IP-адреса администратора и все узлы

Все узлы

Порт, используемый для отладки поисковой службы

4242

RPC

Порт RPC сервера Sage автозаполнения

двунаправленный

Все узлы

Все узлы

Порт, используемый для внутренней связи поисковой службы

4243

RPC

Порт подписчика метаданных сервера автозаполнения Sage

двунаправленный

Все узлы

Все узлы

Порт, используемый для поиска внутренней связи

4244

RPC

Порт подписчика метаданных сервера автозаполнения Sage

двунаправленный

Все узлы

Все узлы

Порт, используемый для поиска внутренней связи

4245

RPC

Порт подписчика метаданных сервера автозаполнения Sage

двунаправленный

Все узлы

Все узлы

Порт, используемый для поиска внутренней связи

4249

TCP

Порты, используемые Enlite / SearchIQ

двунаправленный

Все узлы

Все узлы

Порт, используемый для внутренней связи SpotIQ

4251

RPC

Порт RPC мастера Sage

двунаправленный

Все узлы

Все узлы

Порт, используемый для внутренней связи поисковой службы

4405

RPC

Алмазный (графитовый) порт

двунаправленный

Все узлы

Все узлы

Порт, используемый для связи со службой мониторинга

4406

RPC

Алмазный (графитовый) порт

двунаправленный

Все узлы

Все узлы

Порт, используемый для связи со службой мониторинга

4500

RPC

Порт RPC службы хранилища трассировки

двунаправленный

Все узлы

Все узлы

Сбор трассировки для сервисов ThoughtSpot

4501

HTTP

HTTP-порт службы хранилища трассировки

двунаправленный

IP-адреса администратора и все узлы

Все узлы

Сбор трассировки отладки

4851

RPC

Графитовый менеджер RPC-порт

двунаправленный

Все узлы

Все узлы

Связь с графитовым менеджером

4852

HTTP

Графитовый менеджер HTTP-порт

двунаправленный

IP-адреса администратора и все узлы

Все узлы

Отладка графического менеджера

4853

RPC

Менеджер стека эластичного поиска (ELK) Порт RPC

двунаправленный

Все узлы

Все узлы

Связь со службой поиска по журналу

4853

HTTP

HTTP-порт диспетчера стека эластичного поиска (ELK)

двунаправленный

IP-адреса администратора и все узлы

Все узлы

Служба поиска по журналу отладки

9200

RPC

Эластичный поиск (ELK)

двунаправленный

Все узлы

Все узлы

Связь со службой поиска по журналу

5021

RPC

Службы Callosum, такие как службы метаданных, служба зависимости от medata, служба планирования, служба без сеанса, служба Spotiq

двунаправленный

Все узлы

Все узлы

Порт, по которому служба поиска связывается со службой метаданных для получения метаданных

5432

Постгрес

Порт сервера базы данных Postgres

двунаправленный

Все узлы

Все узлы

Связь с базой данных Postgres

6021

RPC

Службы Callosum, такие как службы метаданных, служба зависимости от medata, служба планирования, служба без сеанса, служба Spotiq

двунаправленный

Все узлы

Все узлы

Порт, по которому служба поиска связывается со службой метаданных для получения метаданных

7021

RPC

Службы Callosum, такие как службы метаданных, служба зависимости от medata, служба планирования, служба без сеанса, служба Spotiq

двунаправленный

Все узлы

Все узлы

Порт, по которому служба поиска связывается со службой метаданных для получения метаданных

8020

RPC

HDFS namenode server RPC порт

двунаправленный

Все узлы

Все узлы

Связь распределенной файловой системы (DFS) с клиентами

8021

RPC

Службы Callosum, такие как службы метаданных, служба зависимости от medata, служба планирования, служба без сеанса, служба Spotiq

двунаправленный

Все узлы

Все узлы

Порт, по которому служба поиска связывается со службой метаданных для получения метаданных

8080

HTTP

Tomcat

двунаправленный

Все узлы

Все узлы

Связь ядра BI с клиентами

8081

HTTP

Статус Callosum / Tomcat

двунаправленный

Все узлы

Все узлы

Связь ядра BI с клиентами

8787

HTTP

Служба Periscope (UI) HTTP-порт

двунаправленный

Все узлы

Все узлы

Серверная часть административного интерфейса

8888

HTTP

HTTP-прокси-сервер (tinyproxy)

двунаправленный

Все узлы

Все узлы

Обратный туннель SSH

11211

Кэширование в памяти

Порт сервера Memcached

двунаправленный

Все узлы

Все узлы

Кэш механизма BI

12345

ODBC

Порт сервера Simba

двунаправленный

Все узлы

Все узлы

Порт, используемый для ETL (извлечение, преобразование, загрузка)

8480

HTTP

HDFS journalnode server HTTP-порт

двунаправленный

Все узлы

Все узлы

Отладка метаданных DFS

8485

HTTP

HDFS journalnode server HTTP-порт

двунаправленный

Все узлы

Все узлы

Отладка метаданных DFS

50070

HTTP

HDFS namenode server HTTP-порт

двунаправленный

Все узлы

Все узлы

Отладка метаданных DFS

50090

HTTP

HDFS вторичный сервер namenode HTTP-порт

двунаправленный

Все узлы

Все узлы

Отладка метаданных DFS

50075

HTTP

Сервер узла данных HDFS HTTP-порт

двунаправленный

Все узлы

Все узлы

Отладка данных DFS

50010

HTTP

Сервер узла данных HDFS HTTP-порт

двунаправленный

Все узлы

Все узлы

Отладка данных DFS

50020

HTTP

Сервер узла данных HDFS HTTP-порт

двунаправленный

Все узлы

Все узлы

Отладка данных DFS

7000

TCP

База данных магазина Cassandra KV

двунаправленный

Все узлы

Все узлы

Отладка данных DFS

7001

TCP

Кассандра

двунаправленный

Все узлы

Все узлы

Отладка данных DFS

9042

HTTP

Служба снятия слепков Munshi, Cassandra

двунаправленный

Все узлы

Все узлы

Отладка данных DFS

9160

TCP

Кассандра

двунаправленный

Все узлы

Все узлы

Отладка данных DFS

4010

HTTP

Falcon модератор

двунаправленный

Все узлы

Все узлы

Отладка данных DFS

4011

HTTP

Falcon модератор

двунаправленный

Все узлы

Все узлы

Отладка данных DFS

20123-32768

TCP (динамический)

Динамический порт в этом диапазоне, используемый для различных служб и вспомогательных служб, таких как atlas, caffeine, callhome, callosum, falcon, monitoring, munshi server, nlp, object_search, postgres, sage UBR, spotiq snapshot, своевременный

Все узлы

Услуги

5270

TCP

Служба мониторинга кластера (ELK)

двунаправленный

Все узлы

Все узлы

Услуги

5271

TCP

Служба мониторинга кластера (ELK)

двунаправленный

Все узлы

Все узлы

Услуги

5601

TCP

Кибана UI (ELK)

двунаправленный

Все узлы

Все узлы

Услуги

6311

TCP

R сервис

двунаправленный

Все узлы

Все узлы

Услуги

8008

TCP

Видеорегистратор

двунаправленный

Все узлы

Все узлы

Услуги

9090

TCP

Своевременно

двунаправленный

Все узлы

Все узлы

Услуги

ICMPv4

Используется для проверки работоспособности узлов кластера

двунаправленный

Все узлы

Все узлы

Услуги

.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *