01.11.2021 11:43
Dradmin 1 1600 Источник

Введение

Rancher - это система, которая работает над Kubernetes и позволяет работать с несколькими кластерами через одну точку входа. Rancher помогает оптимизировать развёртывание кластеров в разных средах: bare-metal сервер (выделенный, железный), частные облака, публичнык облака и объединяет кластеры с помощью единой аутентификацией, контролем доступа и политик безопасности.

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

Задачи

  1. Разметка ресурсов:

    1. 3 служебные ноды (etcd, control panel)

    2. 4 рабочие ноды (worker)

    3. 1 виртуальная машина внутри нового кластера для создания туннеля

  2. Настроить связь между сетями:

    1. Первая сеть: внутренняя сеть с кластером Rancher и управляющим Rancher server

    2. Вторая сеть: внешняя сеть с кластером Rancher на bare-metal сервере

  3. Добавить сервер Nexus для хранения артефактов Helm и Docker

Установка VMware

Дано: выделенный сервер с характеристиками: 2 x Xeon Gold 6240R по 24 ядра каждый, ОЗУ 320 ГБ DDR4, 4 x 480 ГБ SSD.

Сделали на сервере RAID10 и установили VMware vSphere Hypervisor 7 License. Это бесплатная версия с ограничением до 8 ядер на каждую ВМ.

Установка и настройка виртуальных машин

#

Name

CPU

RAM. gb

HDD, gb

Private ip

Public ip

1

vm-firewall

1

4

16

10.21.0.1

8.10.7.2

2

vm-rch-node-1

8

32

60

10.21.0.11

3

vm-rch-node-2

8

32

60

10.21.0.12

4

vm-rch-node-3

8

32

60

10.21.0.13

5

vm-rch-node-4

8

32

60

10.21.0.14

6

vm-rch-etcd-1

2

8

20

10.21.0.15

7

vm-rch-etcd-2

2

8

20

10.21.0.16

8

vm-rch-etcd-3

2

8

20

10.21.0.17

9

vm-nexus

4

16

200

10.21.0.100

8.10.7.2:8081


На каждой ВМ установлен дистрибутив Ubuntu Server 18.

На каждой ВМ для кластера (кроме vm-nexus) выполняем команды для установки docker:

apt-get update && sudo apt-get install -y apt-transport-https echo "deb https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee -a /etc/apt/sources.list.d/kubernetes.listcurl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -apt-get update && sudo apt-get install -y kubectl docker.io open-iscsi bridge-utils open-vm-tools cifs-utils jq util-linux coreutils gccgo-go


И выключаем swap:

swapoff -a

в файле /etc/fstab удалить строку отвечающую за swap-файлПлюс удалить файл, который отвечает за swap: /swap

Архитектура сети

Ip-адреса на всех ВМ прописаны вручную. Настройки сети и маршрутов в каждой ВМ хранятся в файле по адресу: /etc/netplan/00-installer-config.yaml

Текущий кластер находится в сети 10.1.0.0/16

Для внутренней локальной сети нового кластера используется диапазон адресов: 10.21.0.0/16

Машина vm-firewall имеет два сетевых интерфейса:

  1. ens160. К этому интерфейсу прикреплён "белый" адрес: 8.10.7.2, который выдал провайдер. Через этот адрес происходит соединение с точкой входа трафика текущего кластера и создание туннеля.

  2. ens192. Интерфейс для внутренней сети нового кластера. Он выступает в роли шлюза для всех ВМ внутри сети нового кластера.

Настройки сети на vm-firewall:

network: 
ethernets:   
ens160:     
dhcp4: false     
addresses: [8.10.7.2/23]     
gateway4: 8.10.7.1     
dhcp4-overrides:       
use-dns: false     
nameservers:       
addresses: [8.8.8.8,8.8.4.4]     
routes:       
- to: 10.1.0.0/16         
via: 8.10.7.2         
on-link: true         
metric: 100       
- to: 10.21.0.0/16         
via: 10.21.0.1         
on-link: true         
metric: 110       
- to: 0.0.0.0/0         
via: 8.10.7.2         
on-link: true         
metric: 120   
ens192:     
dhcp4: false     
addresses: [10.21.0.1/16] 
version: 2


Настройки сети на любой другой ВМ:

network: 
ethernets:
ens160: 
dhcp4: false 
addresses: [10.21.0.11/16] 
gateway4: 10.21.0.1 
nameservers:   
addresses: [8.8.8.8,8.8.4.4] 
version: 2


После правки конфигурационного файла службы netplan необходимо проверить синтаксис:

netplan generate


И применить настройки:

netplan apply


После этого необходимо проверить как применились настройки ip-адреса:

user@vm-rch-node-01:~$ ifconfig
ens160: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500   
inet 10.21.0.11  netmask 255.255.0.0  broadcast 10.21.255.255    inet6 fe80::20c:29ff:fe3b:3ea5  prefixlen 64  scopeid 0x20<link>    ether 00:0c:29:3b:3e:a5  txqueuelen 1000  (Ethernet)   
RX packets 3756900  bytes 2423660972 (2.4 GB)   
RX errors 0  dropped 503  overruns 0  frame 0   
TX packets 2413321  bytes 311067924 (311.0 MB)   
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


И как применились настройки маршрутов:

user@vm-rch-node-01:~$ ip route
default via 10.21.0.1 dev ens160 proto static
10.21.0.0/16 dev ens160 proto kernel scope link src 10.21.0.11

Настройка туннеля между текущим кластером и новым кластером

Переменные:

  • 19.4.15.14 - белый ip-адрес на точке текущего кластера, который служит для связи с новым кластером

  • 8.10.7.2 - белый ip-адрес устанавливается на vm-firewall и служит точкой, через которую создаётся туннель и будет происходить связь с текущим кластером

Для туннеля выбрана технология IPsec. Настройки производятся на ВМ vm-firewall.

Со стороны нашей внутренней сети текущего кластера настраиваем точку входа на файерволе и сохраняем файл с настройками 1-ой и 2-ой фазы для поднятия туннеля.

Установка пакетов:

apt-get install racoon ipsec-tools


В системе устанавливаются два компонента:

  1. Демона racoon для управления туннелем ISAKMP.

  2. Утилиты setkey для управления SA-туннелей с данными.

Начнем с первого. Racoon отвечает за параметры авторизации туннелей в рамках IKE. Это демон, он настраивается одним конфигурационным файлом (/etc/racoon/racoon.conf), запускается обычным init-скриптом (/etc/init.d/racoon <start|stop|restart>):

В блоке remote указываются настройки 1-й фазы

В блоке sainfo указываются настройки 2-й фазы

root@vm-firewall:~# cat /etc/racoon/racoon.conf
log notify;
path pre_shared_key "/etc/racoon/psk.txt";
listen {
isakmp 8.10.7.2[500];
strict_address;
}
remote 19.4.15.14 {
exchange_mode main,aggressive;
lifetime time 24 hour;
dpd_delay 5;
proposal {   
encryption_algorithm aes 256;   
hash_algorithm sha1;   
authentication_method pre_shared_key;   
dh_group 2;   
lifetime time 86400 sec;
}
}
sainfo address 10.21.0.0/24 any address 10.1.0.0/16 any {
pfs_group 2;
lifetime time 28800 sec;
encryption_algorithm aes 256;
authentication_algorithm hmac_sha1;
compression_algorithm deflate;
}


В файле psk.txt указываем ключ, который задали на точке входа со стороны сети текущего кластера:

root@vm-firewall:~# cat /etc/racoon/psk.txt
# IPv4/v6 addresses
19.4.15.14 PA$$W0RD


Дальше займемся утилитой setkey. Она тоже запускается как демон (/etc/init.d/setkey <start|stop|restart>), но по факту она выполняет скрипт /etc/ipsec-tools.conf. Как говорилось ранее, она уже задает создает туннели для пользовательского трафика. А именно задает SA и SP для них:

root@vm-firewall:~# cat /etc/ipsec-tools.conf
#!/usr/sbin/setkey -f

# NOTE: Do not use this file if you use racoon with racoon-tool
# utility. racoon-tool will setup SAs and SPDs automatically using
# /etc/racoon/racoon-tool.conf configuration.
#
## Flush the SAD and SPD
#
flush;
spdflush;

## Some sample SPDs for use racoon
#
spdadd 10.21.0.0/24 10.1.0.0/16 any -P out ipsec  
esp/tunnel/8.10.7.2-19.4.15.14/require;                 
spdadd 10.1.0.0/16 10.21.0.0/24 any -P in ipsec  
esp/tunnel/19.4.15.14-8.10.7.2/require;


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

systemctl restart setkey.service
systemctl restart racoon.service

Проверка работоспособности

Не забывайте, туннель поднимется только тогда, когда в него пойдет трафик. Надо запустить пинг до назначения. Запускаем пинг с ноды 10.21.0.11 до ноды текущего кластера (10.1.1.13):

user@vm-rch-node-01:~$ ping 10.1.1.13
PING 10.1.1.13 (10.1.13.13) 56(84) bytes of data.
64 bytes from 10.1.1.13: icmp_seq=1 ttl=61 time=4.67 ms
64 bytes from 10.1.1.13: icmp_seq=2 ttl=61 time=2.55 ms
64 bytes from 10.1.1.13: icmp_seq=3 ttl=61 time=2.94 ms
64 bytes from 10.1.1.13: icmp_seq=4 ttl=61 time=4.07 ms^C
--- 10.1.1.13 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 2.556/3.563/4.671/0.850 ms


С небольшой задержкой должны быть ответы с обратной стороны (если конечно ICMP нигде не закрыт на участке).

Проверяем настройку маршрутов на той же ноде:

user@vm-rch-node-01:~$ traceroute 10.1.1.13
traceroute to 10.1.1.13 (10.1.1.13), 30 hops max, 60 byte packets
1 _gateway (10.21.0.1) 0.113 ms 0.080 ms 0.096 ms
2 * * *
3 10.1.1.13 (10.1.1.13) 2.846 ms 2.875 ms 2.874 ms


На vm-firewall проверяем поднялся ли ISAKMP-туннель:

root@vm-firewall:~# racoonctl show-sa isakmp
Destination    Cookies                                      Created
10.1.0.1.500   356a7e134251a93f:30071210375c165         2021-02-19 09:18:28


Также мы можем посмотреть создались ли туннели с пользовательскими данными с помощью команд racoonctl show-sa esp или setket -D:

root@vm-firewall:~# setkey -D
8.10.7.2 19.4.15.14
esp mode=tunnel spi=133928257(0x07fb9541) reqid=0(0x00000000)
E: aes-cbc e12ee98c dcc52fa3 dd115cae 57aaa59e b7b37484 ffbfe306 b7a1e3cd 1e2c5301
A: hmac-sha1 a8d2c0a7 f9690fe2 287cad8f 3023a683 67d4ed85seq=0x00000000 replay=4 flags=0x00000000 state=mature
created: Feb 20 07:53:53 2021 current: Feb 20 08:15:59 2021
diff: 1326(s) hard: 1800(s) soft: 1440(s)
last: Feb 20 07:53:54 2021 hard: 0(s) soft: 0(s)
current: 49838883(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 52998 hard: 0 soft: 0
sadb_seq=1 pid=4468 refcnt=0
19.4.15.14 8.10.7.2
esp mode=tunnel spi=193529941(0x0b890855) reqid=0(0x00000000)
E: aes-cbc 8ad5774d eaa4fe28 685eb88a 12320bac 4ed8ec2e c6af576f 7f3e1f27 666da5da
A: hmac-sha1 22c82645 7f7b9550 73cbd018 1648b4b7 402411ffseq=0x00000000 replay=4 flags=0x00000000 state=mature
created: Feb 20 07:53:53 2021 current: Feb 20 08:15:59 2021
diff: 1326(s) hard: 1800(s) soft: 1440(s)
last: Feb 20 07:53:54 2021 hard: 0(s) soft: 0(s)
current: 7180221(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 24822 hard: 0 soft: 0sadb_seq=2 pid=4468 refcnt=0


Если туннель не устанавливается, то необходимо в файле /etc/racoon/racoon.conf изменить уровень логов с log notify до log debug2 и перезагрузить сервисы:

systemctl restart setkey.service
systemctl restart racoon.service


После этого мы увидим подробные логи в /var/log/syslog и по команде racoon -F

Внимательно читаем man racoon.conf и примеры в /usr/share/doc/racoon/

После дебага не забудьте вернуть уровень логов на прежнее место.

Установка и настройка Nexus

Переходим на машину, где надо установить Nexus и устанавливаем его по инструкции: https://help.sonatype.com/repomanager3/installation

Проверяем, что Nexus отвечает на порту 8081:

user@vm-nexus:~$ curl -I localhost:8081
HTTP/1.1 200 OK
Date: Sat, 20 Feb 2021 09:58:41 GMT
Server: Nexus/3.29.2-02 (OSS)
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block
Content-Type: text/html
Last-Modified: Sat, 20 Feb 2021 09:58:41 GMT
Pragma: no-cache
Cache-Control: no-cache, no-store, max-age=0, must-revalidate, post-check=0, pre-check=0
Expires: 0Content-Length: 8435


Далее настройки производятся на ВМ vm-firewall.

Устанавливаем пакет для возможности сохранять/восстанавливать iptables:

aptitude install iptables-persistent


Настраиваем возможность пересылки пакетов (IP forwarding):

Открываем файл sysctl.conf:

nano /etc/sysctl.conf


Находим в файле и убираем комментарий со строки:

net.ipv4.ip_forward=1


Сохраняем, выходим из файла и перезагружаем машину командой reboot

Проверяем что настройка применилась:

root@vm-firewall:~# sysctl -a | grep net.ipv4.ip_forwardnet.ipv4.ip_forward = 1


Добавляем правило в iptables для возможности пересылки пакетов:

iptables -t nat -A POSTROUTING -o ens160 -j MASQUERADE


Проверяем что правило добавилось:

root@vm-firewall:~# iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
target prot opt source           destination  
Chain INPUT (policy ACCEPT)
target prot opt source           destination  
Chain OUTPUT (policy ACCEPT)
target prot opt source           destination  
Chain POSTROUTING (policy ACCEPT)
MASQUERADE  all  --  anywhere         anywhere


Запрещаем подключение к 22 порту (по SSH) для всех, но разрешаем подключаться из сети текущего кластера (10.1.0.0):

iptables -A INPUT -p tcp -s 10.1.0.0/16 --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp --sport 22 -m conntrack --ctstate ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j DROP


Необходимо подключаться к веб-интерфейсу Nexus. Так как он установлен на внутренней машине 10.21.0.100, то необходимо сделать возможность подключаться к нему с публичного адреса 8.10.7.2. Для этого делаем правило на iptables, которое пробрасываем порт 8081 с 10.21.0.100 где запущен Nexus на порт 8081. Таким образом веб-интерфейс Nexus будет доступен по адресу: 8.10.7.2:8081

iptables -t nat -A PREROUTING -p tcp -d 8.10.7.2 --dport 8081 -j DNAT --to-destination 10.21.0.100:8081
iptables -t nat -A POSTROUTING -p tcp --sport 8081 --dst 10.21.0.100 -j SNAT --to-source 8.10.7.2:8081

Сохранение iptables

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

Для этого выполняем команду:

iptables-save > /etc/iptables/rules.v4


Также можно просто посмотреть какие правила сохранятся без записи в файл:

root@vm-firewall:~# iptables-save
# Generated by iptables-save v1.6.1 on Sat Feb 20 10:23:16 2021
*filter
:INPUT ACCEPT [1367208:430732612]
:FORWARD ACCEPT [2626485:2923178076]
:OUTPUT ACCEPT [887495:574719960]
-A INPUT -s 10.1.0.0/16 -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j DROP
-A OUTPUT -p tcp -m tcp --sport 22 -m conntrack --ctstate ESTABLISHED -j ACCEPT
COMMIT
# Completed on Sat Feb 20 10:23:16 2021
# Generated by iptables-save v1.6.1 on Sat Feb 20 10:23:16 2021
*nat
:PREROUTING ACCEPT [590459:52961865]
:INPUT ACCEPT [218805:21703262]
:OUTPUT ACCEPT [130:9341]
:POSTROUTING ACCEPT [1549:81533]
-A PREROUTING -d 8.10.7.2/32 -p tcp -m tcp --dport 8081 -j DNAT --to-destination 10.21.0.100:8081
-A POSTROUTING -s 10.21.0.0/16 -d 10.1.0.0/16 -o ens160 -m policy --dir out --pol ipsec -j ACCEPT
-A POSTROUTING -d 10.21.0.100/32 -p tcp -m tcp --sport 8081 -j SNAT --to-source 8.10.7.2:8081
-A POSTROUTING -o ens160 -j MASQUERADE
COMMIT
# Completed on Sat Feb 20 10:23:16 2021

Отладка iptables

Если надо удалить все правила iptables:

iptables -Fiptables -Xiptables -t nat -Xiptables -t nat -Fiptables -t filter -Xiptables -t filter -F


Восстановление правил из файла:

iptables-restore < /etc/iptables/rules.v4

Автор статьи https://www.facebook.com/ymalov/

Комментарии (1)


  1. Sleuthhound
    02.11.2021 22:09
    #23661044
    +1

    А причем тут Rancher и Kubernetes то?

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