Google Kubernetes Engine & VPN
Я использую Google Kubernetes Engine для развертывания некоторых приложений, которые должны подключаться к БД на месте. Для этого я настроил VPN-туннель и создал VPC.
Затем я создал кластер GKE (1 узел), который использует этот VPC, и я могу подтвердить, что БД доступна, подключившись к узлу, и попытаться пропинговать сервер БД.
~ $ sudo toolbox ping 10.197.100.201
Spawning container root-gcr.io_google-containers_toolbox-20180309-00 on
/var/lib/toolbox/root-gcr.io_google-containers_toolbox-20180309-00.
Press ^] three times within 1s to kill container.
PING 10.197.100.201 (10.197.100.201): 56 data bytes
64 bytes from 10.197.100.201: icmp_seq=0 ttl=62 time=45.967 ms
64 bytes from 10.197.100.201: icmp_seq=1 ttl=62 time=44.186 ms`
Тем не менее, если я пытаюсь сделать то же самое из Pod, я не могу подключиться.
root@one-shot-pod:/# traceroute 10.197.100.201
traceroute to 10.197.100.201 (10.197.100.201), 30 hops max, 60 byte
packets
1 10.0.0.1 (10.0.0.1) 0.046 ms 0.009 ms 0.007 ms
2 * * *
3 * * *```
Что мне не хватает?
0 ответов
После некоторого расследования я нашел основную причину проблемы. По сути, связь не работала должным образом, потому что есть что-то, называемое ip masquerade (https://cloud.google.com/kubernetes-engine/docs/how-to/ip-masquerade-agent), которое используется для преобразования NAT.
Поскольку у GKE есть несколько адресов по умолчанию, которые настроены так, чтобы не маскироваться (в версии, которую я использовал, значения по умолчанию были: 10.0.0.0/8, 172.16.0.0/12 а также 192.168.0.0/16), а IP-адрес назначения был 10.197.100.201 (часть 10.0.0.0/8), и этот IP-адрес находился вне кластера, решение изменяло nonMasqueradeCIDRs и удалить 10.0.0.0/8 и использовать 10.44.0.0/14 (GKE кластер CIDR) вместо этого.
Для этого я использовал следующую конфигурационную карту:
apiVersion: v1
data:
config: |-
nonMasqueradeCIDRs:
- 10.44.0.0/14
- 172.16.0.0/12
- 192.168.0.0/16
resyncInterval: 60s
kind: ConfigMap
metadata:
name: ip-masq-agent
namespace: kube-system
После этого, чтобы применить конфигурацию, вы можете загрузить карту конфигурации с помощью следующей команды:
kubectl create configmap ip-masq-agent --from-file <configmap file> --namespace kube-system
Я нашел решение в этом блоге.
Проблема в том, что конфигурация iptables по умолчанию выглядит так:
iptables -A POSTROUTING ! -d 10.0.0.0/8 \
-m comment --comment “kubenet: outbound traffic" -m addrtype \
! --dst-type LOCAL -j MASQUERADE -t nat
Это означает, что трафик от модулей будет преобразован через NAT на IP-адрес хоста только в том случае, если пункт назначения не находится в 10.0.0.0/8.
Проблема с 10.0.0.0/8: он слишком велик.
Он также включает ваш 10.197.100.201 IP.
Чтобы исправить это, вы можете добавить следующий DaemonSet в свой кластер Kubernetes:
kind: DaemonSet
apiVersion: extensions/v1beta1
metadata:
name: fix-nat
labels:
app: fix-nat
spec:
template:
metadata:
labels:
app: fix-nat
spec:
hostPID: true
containers:
- name: fix-nat
image: gcr.io/google-containers/startup-script:v1
imagePullPolicy: Always
securityContext:
privileged: true
env:
- name: STARTUP_SCRIPT
value: |
#! /bin/bash
while true; do
iptables-save | grep MASQUERADE | grep -q "NAT-VPN"
if [ $? -ne 0 ]; then
echo "Missing NAT rule for VPN, adding it"
iptables -A POSTROUTING -d 10.197.100.0/24 -m comment --comment "NAT-VPN: SNAT for outbound traffic through VPN" -m addrtype ! --dst-type LOCAL -j MASQUERADE -t nat
fi
sleep 60
done
Этот небольшой скрипт будет каждую минуту, вечно проверять правильность правила iptables и, если нет, добавлять его.
Обратите внимание, что привилегированный: true необходим для того, чтобы модуль мог изменять правила iptables с хоста.
У меня была такая же проблема, и это решило проблему.