Używanie zmiennych środowiskowych w specyfikacji wdrażania Kubernetes

Obecnie używam specyfikacji Kubernetes Deployment.yamldo wdrażania usługi. Specyfikacja zawiera dosłowne odniesienie do określonego adresu IP (oznaczonego jak <static-ip-address>poniżej):

spec:
  type: LoadBalancer
  loadBalancerIP: <static-ip-address>

Niepokoi mnie przekazywanie informacji, takich jak hasła lub adresy IP, do zdalnych repozytoriów Git. Czy mogę tego uniknąć, np. Wykorzystując zmienne środowiskowe, np. Ze specyfikacją wdrożenia i faktycznym wdrożeniem mniej więcej w następujący sposób:

spec:
   type: LoadBalancer
   loadBalancerIP: ${SERVICE_ADDRESS}

i

export SERVICE_ADDRESS=<static-ip-address>
kubectl create -f Deployment.yaml

Oczywiście ta konkretna składnia jeszcze nie działa. Ale czy coś takiego jest możliwe, a jeśli tak, to w jaki sposób?

Wolałbym nie polegać na osobnym narzędziu do obsługi administracyjnej . Tajne s i ConfigMaps wydają się obiecujące, ale najwyraźniej nie mogą być spożywane w sposób, który pasuje do tego celu. Gdybym mógł bezpośrednio odwoływać się do statycznego adresu IP, który został zdefiniowany gcloud compute addresses create service-address, byłoby to najlepsze.

Znacznie łatwiejsze / czystsze rozwiązanie: envsubst

W deploy.yml:

LoadbalancerIP: $LBIP

Następnie po prostu stwórz swój env var i uruchom kubectl w następujący sposób:

export LBIP="1.2.3.4"
envsubst < deploy.yml | kubectl apply -f -

Po prostu wstawiasz zwykłe zmienne Bash do dowolnego pliku, którego chcesz użyć, w tym przypadku manifest YAML, i zniewalasz odczytanie tego pliku. Wyśle plik z zmiennymi env zmienionymi na ich wartości. Możesz także użyć go do tworzenia nowych plików takich jak ten:

envsubst < input.yml > output.yml

envsubstjest dostępny np gettext. w pakiecie Ubuntu / Debian .

Nie było innego mile proste rozwiązanie: Mam Google Compute Adres my-addresszdefiniowane, a ja najwyraźniej go używać w specyfikacji usług tak: loadBalancerIP: my-address.

Ponieważ jest to „zewnętrzne” źródło adresów IP i kluczy tajnych dla haseł, nie ma już potrzeby korzystania z narzędzia (lub szablonów) do obsługi mojego prostego przypadku użycia (w środowisku GKE).

OBSOLETE NOW: W końcu zdecydowałem się użyć pewnego rodzaju narzędzia do udostępniania, a mianowicie „wbudowanego” sed.

Mój Deployment.yamlteraz zawiera „zmienną szablonu” np. W

loadBalancerIP: $$EXTERNAL_IP

i wdrażam usługę z, powiedzmy, 1.2.3.4 jako zewnętrzny adres IP za pomocą

cat Deployment.yaml | sed s/\$\$EXTERNAL_IP/1.2.3.4/ | kubectl create -f -

Możesz napisać prosty procesor wstępny, aby wykonać podstawienie zmiennych w plikach yaml (lub możesz użyć jsonnet, aby osiągnąć to samo w plikach konfiguracyjnych json).

Trwa dyskusja na temat dodawania szablonów bezpośrednio do konfiguracji Kubernetes, ale nie jest ona jeszcze zaimplementowana ani dostępna.

Do czasu udostępnienia szablonów najłatwiejszym sposobem jest uruchomienie zadania, które korzysta z interfejsu API Kubernetes do aktualizacji usługi. Skrypt krótkiej powłoki na obrazie alpejskim, w połączeniu z kluczem tajnym (zawierającym adres IP) i mapą konfiguracji (zawierającą szablon), powinien być dość prosty. Trudnym bitem jest prawidłowe użycie funkcji uwierzytelniania i autoryzacji apiserver.

/programming/30690186/how-do-i-access-the-kubernetes-api-from-withina-a-pod-container daje przykład dostępu do interfejsu API. Oczywiście w tym przykładzie będziesz chciał POST do / api / v1 / namespaces / default / services zamiast GET.