Mögliche Fehler finden

In der Zwischenzeit können Sie einen Blick in die webbasierte AWS Console werfen und sich ansehen, was Kops dort angerichtet hat. Normalerweise sollten Sie zwei Node- und eine Master-Instanz sehen, die gerade starten. Außerdem sollten einige EBS-Volumes und zwei neue Security-Groups existieren.

Die EC2-Instanzen startet Kops nicht direkt, sondern verwendet dafür Autoscaling Groups und Launch Configurations, die sich ebenfalls in der AWS Console wiederfinden. Dies ist auch ein Ansatzpunkt, sollte etwas nicht wie erwartet funktionieren. Starten beispielsweise die Instanzen nicht, sehen Sie sich die Autoscaling Groups an und klappen im unteren Teil des Fensters die "Activity History" aus, wo Sie gegebenenfalls einen Grund für den Nicht-Start finden.

Eine weitere typische Fehlerquelle ist wie immer DNS. Zusätzlich zur Zonen- und Nameserverkonfiguration, die Sie oben manuell vorgenommen haben, setzt Kops einige A-Records, die es zunächst mit Dummy-Adressen belegt und später ändert. Gibt es Probleme mit dem dafür zuständigen Kubernetes-DNS-Controller, finden sich unter Umständen noch die Dummy-Adressen im DNS. Wenn der Kubernetes-Master läuft, können Sie sich auch dort per SSH einloggen und sich die zugehörigen Docker-Container ansehen. Den Hostnamen des Master finden Sie entweder über die AWS Console heraus oder einen AWS-CLI-Aufruf wie den folgenden, der das von Kops vergebene Tag für den Master als Filter verwendet:

$ aws ec2 describe-instances --filter Name=tag:k8s.io/role/master,Values=1 --query 'Reservations[].Instances[].PublicDnsName'

Auf dem Master loggen Sie sich mit dem SSH-Usernamen "admin" ein, für den Kops einen lokalen SSH-Key injiziert hat. "kubectl" können Sie dort vermutlich nicht verwenden, solange Kubernetes nicht funktioniert, also werfen Sie als Root ( »sudo« ) mit »docker container ls« einen Blick auf die laufenden Container. Wer die beschriebene Konfiguration zu unsicher findet, kann übrigens seinen Cluster mit Kops auch mit einem Bastion-Host einrichten, der den SSH-Zugang vom Kubernetes-Master trennt. Alternativ oder ergänzend dazu können Sie den Admin-Zugang zum Cluster mit dem Parameter "admin-access" (Commandline oder Configfile) auf einzelne IP-Adressen oder -Netze beschränken.

Sollten Sie das kostenlose Testangebot von Amazon verwenden, den sogenannten "Free Tier", müssen Sie die auferlegten Limits beachten, die vor allem bei neuen Accounts sehr niedrig sind: Typischerweise dürfen Sie nur eine Instanz pro Region starten. Mit einer Supportanfrage können Sie das Limit gegebenenfalls erhöhen lassen, was etwa ein bis drei Tage in Anspruch nimmt.

Die Cluster-Konfiguration ändern Sie über das eingebaute Kommando "edit", mit dem Sie effektiv wieder die Konfiguration in dem S3-Bucket ändern. Um die Änderungen umzusetzen, rufen Sie danach das "update"-Kommando auf:

$ kops edit cluster kube.aws.zetacloud.de
$ kops update cluster kube.aws.zetacloud.de --yes

Alternativ exportieren Sie die Konfiguration im YAML-Format, editieren sie und ersetzen damit die Konfiguration im S3-Bucket:

$ kops get kube.aws.zetacloud.de -o yaml > config.yml
$ vi config.yml
$ kops replace -f config.yml --state s3://aws-zetacloud-de-state-store kops update cluster kube.aws.zetacloud.de --yes

HA-Setup

Je nach Anwendungsfall soll ein "produktiver" Kubernetes-Cluster meist hochverfügbar sein. Auch dies ist mit Kops einfach möglich. Dazu müssen Sie mehr als einen Master und einige Nodes in unterschiedlichen Availability-Zones betreiben. Das erreichen Sie mit dem Schalter "--master-zones", hinter dem die entsprechenden AZs folgen. Das Gleiche gilt für die Nodes mit der Option "--zones". Außerdem müssen Sie hier ein anderes Overlay-Netzwerk als das sonst verwendete Kubenet verwenden, etwa Flannel oder Calico. Der entsprechende Aufruf von Kops sieht dann etwa so aus:

$ kops create cluster --node-count 3 --zones eu-central-1a,eu-central-1b --master-zones eu-central-1a,eu-central-1b --topology private --networking flannel hacluster.example.com

Einen einfachen Cluster in einen auf mehrere Availability-Zones verteilten HA-Cluster umzuwandeln, ist möglich, aber schwierig. Deshalb raten die Kops-Entwickler dazu, ein HA-Setup möglichst schon vor der Installation zu planen. Ein alternativer Ansatz, den Kops ebenso unterstützt, fasst mehrere Kubernetes-Cluster zu einer "Federation" zusammen.