Der schwierige Teil ist die externe Erreichbarkeit der Kubernetes-Container. Eine Variante ist über Ingress. Dabei übernimmt ein NGINX-Container die Zuordnung von Server-Namen und Aufrufpfaden auf die entsprechenden Dienste. Als Informationsquelle sind dabei auch folgende Seiten interessant:
- http://stytex.de/blog/2017/01/25/deploy-kubernetes-to-bare-metal-with-nginx/
- http://alesnosek.com/blog/2017/02/14/accessing-kubernetes-pods-from-outside-of-the-cluster/
Ingress bereitstellen
Die Einrichtung für meine Umgebung habe ich der Anleitung entnommen:
curl https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/namespace.yaml \
| kubectl apply -f -
curl https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/default-backend.yaml \
| kubectl apply -f -
curl https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/configmap.yaml \
| kubectl apply -f -
curl https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/tcp-services-configmap.yaml \
| kubectl apply -f -
curl https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/udp-services-configmap.yaml \
| kubectl apply -f -
curl https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/rbac.yaml \
| kubectl apply -f -
curl https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/with-rbac.yaml \
| kubectl apply -f -
curl https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/provider/baremetal/service-nodeport.yaml \
| kubectl apply -f -
Beispiel-Konfiguration
Als Beispiel soll der Echo-Server dienen. Zuerst wird er bereitgestellt:
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: http-svc
spec:
replicas: 1
template:
metadata:
labels:
app: http-svc
spec:
containers:
- name: http-svc
image: gcr.io/google_containers/echoserver:1.8
ports:
- containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
name: http-svc
labels:
app: http-svc
spec:
ports:
- port: 80
targetPort: 8080
protocol: TCP
name: http
selector:
app: http-svc
kubectl create -f http-svc.yaml
Anschließend kann eine Regel zur Ingress-Konfiguration hinzugefügt werden:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
name: zork-master
namespace: default
spec:
rules:
- http:
paths:
- backend:
serviceName: http-svc
servicePort: 80
path: /zork
Noch erscheint der Endpunkt nicht auf Port 80. Der tatsächliche Port muss erst ermittelt werden:
$ kubectl get services -n ingress-nginx NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE default-http-backend ClusterIP 10.109.79.14380/TCP 4h ingress-nginx NodePort 10.109.185.214 80:30359/TCP,443:32246/TCP 4h
Ein HTTP-Aufruf gibt nun das gewünschte Ergebnis:
$ curl -k https://192.168.144.117:32246/zork/zuppli
Hostname: http-svc-697c95bf97-gq9hh
Pod Information:
-no pod information available-
Server values:
server_version=nginx: 1.13.3 - lua: 10008
Request Information:
client_address=10.244.2.23
method=GET
real path=/zuppli
query=
request_version=1.1
request_uri=http://192.168.144.117:8080/zuppli
Request Headers:
accept=*/*
connection=close
host=192.168.144.117:32246
user-agent=curl/7.57.0
x-forwarded-for=10.244.1.0
x-forwarded-host=192.168.144.117:32246
x-forwarded-port=443
x-forwarded-proto=https
x-original-uri=/zork/zuppli
x-real-ip=10.244.1.0
x-scheme=https
Request Body:
-no body in request-
Dashboard
Das Dashboard kann über folgende Konfiguration eingebunden werden:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
nginx.ingress.kubernetes.io/secure-backends: true
name: dashboard
namespace: kube-system
spec:
rules:
- http:
paths:
- backend:
serviceName: kubernetes-dashboard
servicePort: 443
path: /dashboard