2.1 - PKI Zertifikate and Anforderungen
Kubernetes benötigt PKI Zertifikate für die Authentifzierung über TLS.
Falls Sie Kubernetes über kubeadm installieren,
wurden die benötigten Zertifikate bereits automatisch generiert.
In jedem Fall können Sie diese auch selbst generieren -- beispielsweise um private Schlüssel
nicht auf dem API Server zu speichern und somit deren Sicherheit zu erhöhen.
Diese Seite erklärt, welche Zertifikate ein Cluster benötigt.
Wie Zertifikate in Ihrem Cluster verwendet werden
Kubernetes benötigt PKI-Zertifikate für die folgenden Vorgänge:
Server Zertifikate
- Server Zertifikate für den API Server Endpunkt
- Server Zertifikate für den etcd Server
- Server Zertifikate
für jeden kubelet (every node runs a kubelet)
- Optionale Server Zertifikate für den front-proxy
Client Zertifikate
- Client-Zertifikate für jedes
Kubelet
zur Authentifizierung gegenüber dem API-Server als Client der Kubernetes API
- Client-Zertifikat für jeden
API-Server
zur Authentifizierung gegenüber etcd
- Client-Zertifikat für den
Controller Manager
zur sicheren Kommunikation mit dem API-Server
- Client-Zertifikat für den
Scheduler
zur sicheren Kommunikation mit dem API-Server
- Client-Zertifikate, eines pro Node, für
kube-proxy
zur Authentifizierung gegenüber dem API-Server
- Optionale Client-Zertifikate für Administratoren des Clusters zur Authentifizierung gegenüber dem API-Server
- Optionales Client-Zertifikat für den Front-Proxy
Server- und Client-Zertifikate des Kubelets
Um eine sichere Verbindung herzustellen und sich gegenüber dem Kubelet zu authentifizieren, benötigt der API-Server ein Client-Zertifikat und ein Schlüsselpaar.
In diesem Szenario gibt es zwei Ansätze für die Verwendung von Zertifikaten:
-
Gemeinsame Zertifikate: Der kube-apiserver kann dasselbe Zertifikat und Schlüsselpaar verwenden, das er zur Authentifizierung seiner Clients nutzt.
Das bedeutet, dass bestehende Zertifikate wie apiserver.crt
und apiserver.key
für die Kommunikation mit den Kubelet-Servern verwendet werden können.
-
Separate Zertifikate: Alternativ kann der kube-apiserver ein neues Client-Zertifikat und Schlüsselpaar zur Authentifizierung seiner Kommunikation mit den Kubelet-Servern generieren.
In diesem Fall werden ein separates Zertifikat kubelet-client.crt
und der dazugehörige private Schlüssel kubelet-client.key
erstellt.
Hinweis:
front-proxy
-Zertifikate werden nur benötigt, wenn kube-proxy zur Unterstützung eines
Erweiterungs-API-Servers eingesetzt wird.
Auch etcd verwendet gegenseitiges TLS zur Authentifizierung von Clients und deren Gegenstelle.
Wo Zertifikate gespeichert werden
Wenn Sie Kubernetes mit kubeadm installieren, werden die meisten Zertifikate im Verzeichnis /etc/kubernetes/pki
gespeichert.
Alle Pfade in dieser Dokumentation beziehen sich auf dieses Verzeichnis,
mit Ausnahme der Benutzerzertifikate, die von kubeadm unter /etc/kubernetes
ablegt werden.
Zertifikate manuell konfigurieren
Wenn Sie nicht möchten, dass kubeadm die benötigten Zertifikate generiert,
können Sie diese entweder mithilfe einer einzelnen Root-CA selbst erstellen
oder alle Zertifikate vollständig manuell bereitstellen. Details zur Erstellung einer eigenen Zertifizierungsstelle finden Sie unter Zertifikate.
Weitere Informationen zur Verwaltung von Zertifikaten mit kubeadm bietet Zertifikatsverwaltung mit kubeadm.
Einzelne Root-CA
Sie können eine einzelne Root-CA erstellen, welche dann mehrere Zwischen-CAs generieren
und die Erstellung weiterer Zertifikate Kubernetes selbst überlassen kann.
Erforderliche CAs:
Pfad |
Standard-CN |
Beschreibung |
ca.crt,key |
kubernetes-ca |
Allgemeine CA für Kubernetes |
etcd/ca.crt,key |
etcd-ca |
Für alle etcd-bezogenen Funktionen |
front-proxy-ca.crt,key |
kubernetes-front-proxy-ca |
Für den Front-Proxy |
Zusätzlich zu den oben genannten CAs wird auch ein öffentliches/privates Schlüsselpaar für das Service-Account-Management benötigt: sa.key
und sa.pub
.
Das folgende Beispiel zeigt die CA-Schlüssel- und Zertifikatsdateien aus der vorherigen Tabelle:
/etc/kubernetes/pki/ca.crt
/etc/kubernetes/pki/ca.key
/etc/kubernetes/pki/etcd/ca.crt
/etc/kubernetes/pki/etcd/ca.key
/etc/kubernetes/pki/front-proxy-ca.crt
/etc/kubernetes/pki/front-proxy-ca.key
Alle Zertifikate
Wenn Sie die privaten CA-Schlüssel nicht in Ihren Cluster kopieren möchten, können Sie alle Zertifikate selbst generieren.
Erforderliche Zertifikate:
Standard-CN |
Ausstellende CA |
O (im Subject) |
Typ |
Hosts (SAN) |
kube-etcd |
etcd-ca |
|
Server, Client |
<hostname> , <Host_IP> , localhost , 127.0.0.1 |
kube-etcd-peer |
etcd-ca |
|
Server, Client |
<hostname> , <Host_IP> , localhost , 127.0.0.1 |
kube-etcd-healthcheck-client |
etcd-ca |
|
Client |
|
kube-apiserver-etcd-client |
etcd-ca |
|
Client |
|
kube-apiserver |
kubernetes-ca |
|
Server |
<hostname> , <Host_IP> , <advertise_IP> |
kube-apiserver-kubelet-client |
kubernetes-ca |
system:masters |
Client |
|
front-proxy-client |
kubernetes-front-proxy-ca |
|
Client |
|
Hinweis:
Anstelle der Superuser-Gruppe system:masters
für kube-apiserver-kubelet-client
kann auch eine weniger privilegierte Gruppe verwendet werden. kubeadm nutzt hierfür die Gruppe kubeadm:cluster-admins
.
Der Wert in der Spalte Typ
entspricht einer oder mehreren x509-Schlüsselverwendungen, die auch in .spec.usages
eines CertificateSigningRequest-Typs dokumentiert sind:
Typ |
Schlüsselverwendung |
Server |
Digitale Signatur, Schlüsselverschlüsselung, Serverauth. |
Client |
Digitale Signatur, Schlüsselverschlüsselung, Clientauth. |
Hinweis:
Die oben aufgelisteten Hosts/SANs sind die empfohlenen Werte, um einen funktionsfähigen Cluster zu erhalten.
Falls Ihr Setup es erfordert, können Sie auf allen Server-Zertifikaten zusätzliche SANs ergänzen.
Hinweis:
Nur für kubeadm-Benutzer:
- Das Szenario, bei dem Sie CA-Zertifikate ohne private Schlüssel in Ihren Cluster kopieren, wird in der kubeadm-Dokumentation als externe CA bezeichnet.
- Wenn Sie die obige Liste mit einer von kubeadm generierten PKI vergleichen, beachten Sie bitte, dass
kube-etcd
, kube-etcd-peer
und kube-etcd-healthcheck-client
nicht erzeugt werden, wenn ein externer etcd-Cluster verwendet wird.
Zertifikatspfade
Zertifikate sollten in einem empfohlenen Pfad abgelegt werden (wie von kubeadm verwendet).
Die Pfade sollten mit dem angegebenen Argument festgelegt werden, unabhängig vom Speicherort.
Standard-CN |
Empfohlener Schlüsselpfad |
Empfohlener Zertifikatspfad |
Befehl |
Schlüssel-Argument |
Zertifikat-Argument |
etcd-ca |
etcd/ca.key |
etcd/ca.crt |
kube-apiserver |
|
--etcd-cafile |
kube-apiserver-etcd-client |
apiserver-etcd-client.key |
apiserver-etcd-client.crt |
kube-apiserver |
--etcd-keyfile |
--etcd-certfile |
kubernetes-ca |
ca.key |
ca.crt |
kube-apiserver |
|
--client-ca-file |
kubernetes-ca |
ca.key |
ca.crt |
kube-controller-manager |
--cluster-signing-key-file |
--client-ca-file,--root-ca-file,--cluster-signing-cert-file |
kube-apiserver |
apiserver.key |
apiserver.crt |
kube-apiserver |
--tls-private-key-file |
--tls-cert-file |
kube-apiserver-kubelet-client |
apiserver-kubelet-client.key |
apiserver-kubelet-client.crt |
kube-apiserver |
--kubelet-client-key |
--kubelet-client-certificate |
front-proxy-ca |
front-proxy-ca.key |
front-proxy-ca.crt |
kube-apiserver |
|
--requestheader-client-ca-file |
front-proxy-ca |
front-proxy-ca.key |
front-proxy-ca.crt |
kube-controller-manager |
|
--requestheader-client-ca-file |
front-proxy-client |
front-proxy-client.key |
front-proxy-client.crt |
kube-apiserver |
--proxy-client-key-file |
--proxy-client-cert-file |
etcd-ca |
etcd/ca.key |
etcd/ca.crt |
etcd |
|
--trusted-ca-file,--peer-trusted-ca-file |
kube-etcd |
etcd/server.key |
etcd/server.crt |
etcd |
--key-file |
--cert-file |
kube-etcd-peer |
etcd/peer.key |
etcd/peer.crt |
etcd |
--peer-key-file |
--peer-cert-file |
etcd-ca |
|
etcd/ca.crt |
etcdctl |
|
--cacert |
kube-etcd-healthcheck-client |
etcd/healthcheck-client.key |
etcd/healthcheck-client.crt |
etcdctl |
--key |
--cert |
Gleiche Überlegungen gelten für das Service-Account-Schlüsselpaar:
Pfad privater Schlüssel |
Pfad öffentlicher Schlüssel |
Befehl |
Argument |
sa.key |
|
kube-controller-manager |
--service-account-private-key-file |
|
sa.pub |
kube-apiserver |
--service-account-key-file |
Das folgende Beispiel zeigt die Dateipfade aus den vorherigen Tabellen, die Sie bereitstellen müssen, wenn Sie alle Schlüssel und Zertifikate selbst generieren:
/etc/kubernetes/pki/etcd/ca.key
/etc/kubernetes/pki/etcd/ca.crt
/etc/kubernetes/pki/apiserver-etcd-client.key
/etc/kubernetes/pki/apiserver-etcd-client.crt
/etc/kubernetes/pki/ca.key
/etc/kubernetes/pki/ca.crt
/etc/kubernetes/pki/apiserver.key
/etc/kubernetes/pki/apiserver.crt
/etc/kubernetes/pki/apiserver-kubelet-client.key
/etc/kubernetes/pki/apiserver-kubelet-client.crt
/etc/kubernetes/pki/front-proxy-ca.key
/etc/kubernetes/pki/front-proxy-ca.crt
/etc/kubernetes/pki/front-proxy-client.key
/etc/kubernetes/pki/front-proxy-client.crt
/etc/kubernetes/pki/etcd/server.key
/etc/kubernetes/pki/etcd/server.crt
/etc/kubernetes/pki/etcd/peer.key
/etc/kubernetes/pki/etcd/peer.crt
/etc/kubernetes/pki/etcd/healthcheck-client.key
/etc/kubernetes/pki/etcd/healthcheck-client.crt
/etc/kubernetes/pki/sa.key
/etc/kubernetes/pki/sa.pub
Zertifikate für Benutzerkonten konfigurieren
Sie müssen diese Administrator- und Servicekonten manuell konfigurieren:
Dateiname |
Anmeldeinformationen-Name |
Standard-CN |
O (im Subject) |
admin.conf |
default-admin |
kubernetes-admin |
<admin-group> |
super-admin.conf |
default-super-admin |
kubernetes-super-admin |
system:masters |
kubelet.conf |
default-auth |
system:node:<nodeName> (siehe Hinweis) |
system:nodes |
controller-manager.conf |
default-controller-manager |
system:kube-controller-manager |
|
scheduler.conf |
default-scheduler |
system:kube-scheduler |
|
Hinweis:
Der Wert von
<nodeName>
in
kubelet.conf
muss exakt mit dem Node-Namen übereinstimmen, den der kubelet beim Registrieren am apiserver angibt.
Weitere Details finden Sie unter
Node Authorization.
Hinweis:
Im obigen Beispiel ist <admin-group>
implementierungsspezifisch. Manche Tools signieren das Zertifikat in der Standard-admin.conf
, sodass es Teil der Gruppe system:masters
ist.
system:masters
ist eine Notfall-Superuser-Gruppe, die die Autorisierungsschicht, wie zum Beispiel RBAC, von Kubernetes umgehen kann. Manche Tools erzeugen auch keine separate super-admin.conf
mit einem Zertifikat, das an diese Superuser-Gruppe gebunden ist.
kubeadm erstellt zwei separate Administratorzertifikate in kubeconfig-Dateien. Eines ist in admin.conf
und hat Subject: O = kubeadm:cluster-admins, CN = kubernetes-admin
.
kubeadm:cluster-admins
ist eine benutzerdefinierte Gruppe, die an die ClusterRole cluster-admin
gebunden ist. Diese Datei wird auf allen von kubeadm verwalteten Control-Plane-Maschinen erstellt.
Das andere ist in super-admin.conf
und hat Subject: O = system:masters, CN = kubernetes-super-admin
.
Diese Datei wird nur auf dem Node erzeugt, auf dem kubeadm init
ausgeführt wurde.
-
Generieren Sie für jede Konfiguration ein x509-Zertifikat/Schlüsselpaar mit dem angegebenen Common Name (CN) und der Organisation (O).
-
Führen Sie für jede Konfiguration kubectl
wie folgt aus:
KUBECONFIG=<Dateiname> kubectl config set-cluster default-cluster --server=https://<Host-IP>:6443 --certificate-authority <Pfad-zur-kubernetes-ca> --embed-certs
KUBECONFIG=<Dateiname> kubectl config set-credentials <Anmeldeinfo-Name> --client-key <Pfad-zum-Schlüssel>.pem --client-certificate <Pfad-zum-Zertifikat>.pem --embed-certs
KUBECONFIG=<Dateiname> kubectl config set-context default-system --cluster default-cluster --user <Anmeldeinfo-Name>
KUBECONFIG=<Dateiname> kubectl config use-context default-system
Diese Dateien werden wie folgt verwendet:
Dateiname |
Befehl |
Kommentar |
admin.conf |
kubectl |
Konfiguriert den Administrator-Benutzer für den Cluster |
super-admin.conf |
kubectl |
Konfiguriert den Super-Administrator-Benutzer für den Cluster |
kubelet.conf |
kubelet |
Wird für jeden Node im Cluster benötigt |
controller-manager.conf |
kube-controller-manager |
Muss im Manifest manifests/kube-controller-manager.yaml eingetragen werden |
scheduler.conf |
kube-scheduler |
Muss im Manifest manifests/kube-scheduler.yaml eingetragen werden |
Beispielhafte vollständige Pfade zu den Dateien aus der obigen Tabelle:
/etc/kubernetes/admin.conf
/etc/kubernetes/super-admin.conf
/etc/kubernetes/kubelet.conf
/etc/kubernetes/controller-manager.conf
/etc/kubernetes/scheduler.conf
3 - Kubernetes lokal über Minikube betreiben
Minikube ist ein Tool, mit dem Kubernetes lokal einfach ausgeführt werden kann. Minikube führt einen Kubernetes-Cluster mit einem einzigen Node in einer VM auf Ihrem Laptop aus, damit Anwender Kubernetes ausprobieren oder täglich damit entwickeln können.
Minikube-Funktionen
- Minikube unterstützt Kubernetes-Funktionen wie:
- DNS
- NodePorts
- ConfigMaps and Secrets
- Dashboards
- Container Laufzeiumgebungen: Docker, rkt, CRI-O und containerd
- Unterstützung von CNI (Container Network Interface)
- Ingress
Installation
Lesen Sie Minikube installieren für Informationen zur Installation von Minikubes.
Schnellstart
Folgend finden Sie eine kurze Demo zur Verwendung von Minikube.
Wenn Sie den VM-Treiber ändern möchten, fügen Sie das entsprechende --vm-driver=xxx
-Flag zu minikube start
hinzu.
Minikube unterstützt die folgenden Treiber:
Starting local Kubernetes cluster...
Running pre-create checks...
Creating machine...
Starting local Kubernetes cluster...
kubectl create deployment hello-minikube --image=registry.k8s.io/echoserver:1.10
deployment.apps/hello-minikube created
kubectl expose deployment hello-minikube --type=NodePort --port=8080
service/hello-minikube exposed
# Wir haben jetzt einen echoserver Pod gestartet, aber wir müssen warten,
# bis der Pod betriebsbereit ist, bevor wir über den exponierten Dienst auf ihn zugreifen können.
# Um zu überprüfen, ob der Pod läuft, können wir Folgendes verwenden:
kubectl get pod
NAME READY STATUS RESTARTS AGE
hello-minikube-3383150820-vctvh 0/1 ContainerCreating 0 3s
# Wir können anhand des ContainerCreating-Status sehen, dass der Pod immer noch erstellt wird.
kubectl get pod
NAME READY STATUS RESTARTS AGE
hello-minikube-3383150820-vctvh 1/1 Running 0 13s
# Wir können sehen, dass der Pod jetzt läuft und wir können ihn jetzt mit curl kontaktieren:
curl $(minikube service hello-minikube --url)
Hostname: hello-minikube-7c77b68cff-8wdzq
Pod Information:
-no pod information available-
Server values:
server_version=nginx: 1.13.3 - lua: 10008
Request Information:
client_address=172.17.0.1
method=GET
real path=/
query=
request_version=1.1
request_scheme=http
request_uri=http://192.168.99.100:8080/
Request Headers:
accept=*/*
host=192.168.99.100:30674
user-agent=curl/7.47.0
Request Body:
-no body in request-
kubectl delete services hello-minikube
service "hello-minikube" deleted
kubectl delete deployment hello-minikube
deployment.extensions "hello-minikube" deleted
Stopping local Kubernetes cluster...
Stopping "minikube"...
Alternative Containerlaufzeitumgebungen
containerd
Um containerd als Containerlaufzeitumgebung zu verwenden, führen Sie den folgenden Befehl aus:
minikube start \
--network-plugin=cni \
--enable-default-cni \
--container-runtime=containerd \
--bootstrapper=kubeadm
Oder verwenden Sie die erweiterte Version:
minikube start \
--network-plugin=cni \
--enable-default-cni \
--extra-config=kubelet.container-runtime=remote \
--extra-config=kubelet.container-runtime-endpoint=unix:///run/containerd/containerd.sock \
--extra-config=kubelet.image-service-endpoint=unix:///run/containerd/containerd.sock \
--bootstrapper=kubeadm
CRI-O
Um CRI-O als Containerlaufzeitumgebung zu verwenden, führen Sie den folgenden Befehl aus:
minikube start \
--network-plugin=cni \
--enable-default-cni \
--container-runtime=cri-o \
--bootstrapper=kubeadm
Oder verwenden Sie die erweiterte Version:
minikube start \
--network-plugin=cni \
--enable-default-cni \
--extra-config=kubelet.container-runtime=remote \
--extra-config=kubelet.container-runtime-endpoint=/var/run/crio.sock \
--extra-config=kubelet.image-service-endpoint=/var/run/crio.sock \
--bootstrapper=kubeadm
rkt container engine
Um rkt als Containerlaufzeitumgebung zu verwenden, führen Sie den folgenden Befehl aus:
minikube start \
--network-plugin=cni \
--enable-default-cni \
--container-runtime=rkt
Hierbei wird ein alternatives Minikube-ISO-Image verwendet, das sowohl rkt als auch Docker enthält, und CNI-Netzwerke ermöglichen.
Treiber Plugins
Weitere Informationen zu unterstützten Treibern und zur Installation von Plugins finden Sie bei Bedarf unter TREIBER.
Lokale Images durch erneute Verwendung des Docker-Daemon ausführen
Wenn Sie eine einzige Kubernetes VM verwenden, ist es sehr praktisch, den integrierten Docker-Daemon von Minikube wiederzuverwenden; Dies bedeutet, dass Sie auf Ihrem lokalen Computer keine Docker-Registy erstellen und das Image in die Registry importieren müssen - Sie können einfach innerhalb desselben Docker-Daemons wie Minikube arbeiten, was lokale Experimente beschleunigt. Stellen Sie einfach sicher, dass Sie Ihr Docker-Image mit einem anderen Element als 'latest' versehen, und verwenden Sie dieses Tag, wenn Sie das Image laden. Andernfalls, wenn Sie keine Version Ihres Images angeben, wird es als :latest
angenommen, mit der Pull-Image-Richtlinie von Always
entsprechend, was schließlich zu ErrImagePull
führen kann, da Sie möglicherweise noch keine Versionen Ihres Docker-Images in der Standard-Docker-Registry (normalerweise DockerHub) haben.
Um mit dem Docker-Daemon auf Ihrem Mac/Linux-Computer arbeiten zu können, verwenden Sie den docker-env
-Befehl in Ihrer Shell:
eval $(minikube docker-env)
Sie sollten nun Docker in der Befehlszeile Ihres Mac/Linux-Computers verwenden können, um mit dem Docker-Daemon in der Minikube-VM zu sprechen:
In Centos 7 meldets Docker möglicherweise den folgenden Fehler:
Could not read CA certificate "/etc/docker/ca.pem": open /etc/docker/ca.pem: no such file or directory
Das Update besteht darin, /etc/sysconfig/docker
zu aktualisieren, um sicherzustellen, dass die Umgebungsänderungen von Minikube beachtet werden:
< DOCKER_CERT_PATH=/etc/docker
---
> if [ -z "${DOCKER_CERT_PATH}" ]; then
> DOCKER_CERT_PATH=/etc/docker
> fi
Denken Sie daran, imagePullPolicy: Always
auszuschalten. Andernfalls verwendet Kubernetes keine lokal erstellten Images.
Cluster verwalten
Cluster starten
Mit dem Befehl minikube start
können Sie Ihr Cluster starten.
Dieser Befehl erstellt und konfiguriert eine virtuelle Maschine, auf der ein Kubernetes-Cluster mit einem Knoten ausgeführt wird.
Ebenfalls konfiguriert dieser Befehl auch Ihre kubectl Installation zur Kommunikation mit diesem Cluster.
Wenn Sie sich hinter einem Web-Proxy befinden, müssen Sie diese Informationen mit dem Befehl minikube start
übergeben:
https_proxy=<mein_proxy> minikube start --docker-env http_proxy=<mein_proxy> --docker-env https_proxy=<mein_proxy> --docker-env no_proxy=192.168.99.0/24
Leider wird nur das Setzen der Umgebungsvariablen nicht funktionieren.
Minikube erstellt auch einen "Minikube"-Kontext und setzt ihn in kubectl auf den Standardwert.
Um später wieder zu diesem Kontext zurückzukehren, führen Sie den folgenden Befehl aus: kubectl config use-context minikube
.
Angabe der Kubernetes-Version
Sie können die bestimmte Version von Kubernetes für Minikube angeben, indem Sie die Zeichenfolge --kubernetes-version
an den Befehl minikube start
anhängen.
Zum Verwenden der Version v1.7.3
führen Sie beispielsweise Folgendes aus:
minikube start --kubernetes-version v1.7.3
Kubernetes konfigurieren
Minikube verfügt über eine "Konfigurator"-Funktion, mit der Anwender die Kubernetes-Komponenten mit beliebigen Werten konfigurieren können.
Um diese Funktion zu verwenden, setzen Sie das --extra-config
-Flag an den minikube start
Befehl.
Dieses Flag wird wiederholt, sodass Sie es mehrere Male mit verschiedenen Werten übergeben können, um mehrere Optionen festzulegen.
Dieses Flag nimmt eine Zeichenkette der Form component.key=value
an, wobei component
eine der Zeichenketten aus der unteren Liste ist, key
ein Wert in der Konfigurationsstruktur ist und value
der einzustellende Wert ist.
Gültige Schlüssel finden Sie in der Dokumentation der Kubernetes componentconfigs
für jede Komponente.
Nachstehend die Dokumentation für jede unterstützte Konfiguration:
Beispiele
Um die MaxPods
-Einstellung im Kubelet auf 5 zu ändern, übergeben Sie dieses Flag: --extra-config=kubelet.MaxPods=5
.
Diese Funktion unterstützt auch verschachtelte Strukturen. Um die LeaderElection.LeaderElect
Einstellung zu true
zu ändern, übergeben Sie im Scheduler dieses Flag: --extra-config=scheduler.LeaderElection.LeaderElect=true
.
Um den AuthorizationMode
auf dem apiserver
zu RBAC
zu ändern, verwenden Sie: --extra-config=apiserver.authorization-mode=RBAC
.
Einen Cluster stoppen
Mit dem Befehl minikube stop
können Sie Ihr Cluster anhalten.
Mit diesem Befehl wird die Minikube Virtual Machine heruntergefahren, der Clusterstatus und die Clusterdaten bleiben jedoch erhalten.
Durch erneutes Starten des Clusters wird der vorherige Status wiederhergestellt.
Cluster löschen
Der Befehl minikube delete
kann zum Löschen Ihres Clusters verwendet werden.
Mit diesem Befehl wird die Minikube Virtual Machine heruntergefahren und gelöscht. Keine Daten oder Zustände bleiben erhalten.
Mit einem Cluster interagieren
Kubectl
Der minikube start
Befehl erstellt einen kubectl Kontext genannt "minikube".
Dieser Kontext enthält die Konfiguration für die Kommunikation mit Ihrem Minikube-Cluster.
Minikube setzt diesen Kontext automatisch auf den Standardwert, aber wenn Sie in Zukunft wieder darauf zurückgreifen müssen, führen Sie den folgenden Befehl aus:
kubectl config use-context minikube
,
Oder übergeben Sie den Kontext bei jedem Befehl wie folgt: kubectl get pods --context=minikube
.
Dashboard
Um Zugriff auf das Kubernetes Dashboard zu erhalten, führen Sie diesen Befehl in einer Shell aus, nachdem Sie Minikube gestartet haben, um die Adresse abzurufen:
Services
Um auf einen Service zuzugreifen, der über einen NodePort verfügbar gemacht wird, führen Sie diesen Befehl in einer Shell aus, nachdem Sie Minikube gestartet haben, um die Adresse abzurufen:
minikube service [-n NAMESPACE] [--url] NAME
Netzwerk
Die Minikube-VM wird über eine Host-Only-IP-Adresse, die mit dem Befehl minikube ip
abgerufen werden kann, für das Hostsystem verfügbar gemacht.
Auf alle Dienste des Typs NodePort
kann über diese IP-Adresse und den NodePort zugegriffen werden.
Um den NodePort für Ihren Dienst zu ermitteln, können Sie einen kubectl
-Befehl wie folgt verwenden:
kubectl get service $SERVICE --output='jsonpath="{.spec.ports[0].nodePort}"'
Dauerhafte Volumen
Minikube unterstützt PersistentVolumes des Typs hostPath
.
Diese dauerhaften Volumen werden einem Verzeichnis in der Minikube-VM zugeordnet.
Die Minikube-VM wird in ein temporäres Dateisystem hochgefahren, sodass die meisten Verzeichnisse nicht nach Neustarts beibehalten werden (minikube stop
).
Minikube ist jedoch so konfiguriert, dass Dateien beibehalten werden, die in den folgenden Host-Verzeichnissen gespeichert sind:
/data
/var/lib/minikube
/var/lib/docker
Hier ist ein Beispiel einer PersistentVolume-Konfiguration, um Daten im Verzeichnis / data
beizubehalten:
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv0001
spec:
accessModes:
- ReadWriteOnce
capacity:
storage: 5Gi
hostPath:
path: /data/pv0001/
Hostordnerfreigabe
Einige Treiber werden einen Hostordner in der VM bereitstellen, sodass Sie Dateien problemlos zwischen VM und Host freigeben können. Diese sind momentan nicht konfigurierbar und unterscheiden sich für den Treiber und das Betriebssystem, das Sie verwenden.
Hinweis:
Die Hostordnerfreigabe ist noch nicht im KVM-Treiber implementiert.
Treiber |
Betriebssystem |
Hostordner |
VM |
VirtualBox |
Linux |
/home |
/hosthome |
VirtualBox |
macOS |
/Users |
/Users |
VirtualBox |
Windows |
C://Users |
/c/Users |
VMware Fusion |
macOS |
/Users |
/Users |
Xhyve |
macOS |
/Users |
/Users |
Private Containerregistries
Um auf eine private Container Registry zuzugreifen, führen Sie die Schritte auf dieser Seite aus.
Wir empfehlen die Verwendung von ImagePullSecrets
, wenn Sie jedoch den Zugriff auf die Minikube-VM konfigurieren möchten, können Sie die Datei .dockercfg
im Verzeichnis/home/docker
oder die Datei config.json
im Verzeichnis/home/docker/.docker
ablegen.
Add-ons
Damit Minikube benutzerdefinierte Addons ordnungsgemäß starten oder neu starten kann, platzieren Sie die Addons, die mit Minikube gestartet werden sollen, im Verzeichnis ~ /.minikube/addons
.
Addons in diesem Ordner werden in die Minikube-VM verschoben und jedes Mal gestartet, wenn Minikube gestartet oder neu gestartet wird.
Minikube mit einem HTTP-Proxy verwenden
Minikube erstellt eine virtuelle Maschine, die Kubernetes und einen Docker-Dämon enthält.
Wenn Kubernetes versucht, Container mithilfe von Docker zu planen, erfordert der Docker-Daemon möglicherweise einen externen Netzwerkzugriff, um Container abzurufen.
Wenn Sie sich hinter einem HTTP-Proxy befinden, müssen Sie möglicherweise die Proxy-Einstellungen für Docker angeben.
Übergeben Sie dazu die erforderlichen Umgebungsvariablen während des minikube start
als Flags.
Zum Beispiel:
minikube start --docker-env http_proxy=http://$IHRPROXY:PORT \
--docker-env https_proxy=https://$IHRPROXY:PORT
Wenn die Adresse Ihrer virtuellen Maschine 192.168.99.100 lautet, besteht die Möglichkeit, dass Ihre Proxy-Einstellungen verhindern, dass kubectl
sie direkt erreicht.
Um die Proxy-Konfiguration für diese IP-Adresse zu umgehen, sollten Sie Ihre no_proxy-Einstellungen ändern. Sie können dies mit dem folgenden Befehl tun:
export no_proxy=$no_proxy,$(minikube ip)
Bekannte Probleme
- Funktionen, die einen Cloud-Provider erfordern, funktionieren in Minikube nicht. Diese schließen ein:
- Features, die mehrere Knoten erfordern. Diese schließen ein:
- Erweiterte Planungsrichtlinien
Design
Minikube verwendet libmachine zur Bereitstellung von VMs, und kubeadm um einen Kubernetes-Cluster in Betrieb zu nehmen.
Weitere Informationen zu Minikube finden Sie im Vorschlag.
Zusätzliche Links
- Ziele und Nichtziele: Die Ziele und Nichtziele des Minikube-Projekts finden Sie in unserer Roadmap.
- Entwicklungshandbuch: Lesen Sie CONTRIBUTING.md für einen Überblick über das Senden von Pull-Requests.
- Minikube bauen: Anweisungen zum Erstellen/Testen von Minikube aus dem Quellcode finden Sie im build Handbuch.
- Neue Abhängigkeit hinzufügen: Anweisungen zum Hinzufügen einer neuen Abhängigkeit zu Minikube finden Sie in der Anleitung zum Hinzufügen von Abhängigkeiten.
- Neues Addon hinzufügen: Anweisungen zum Hinzufügen eines neuen Addons für Minikube finden Sie im Anleitung zum Hinzufügen eines Addons.
- MicroK8s: Linux-Benutzer, die die Ausführung einer virtuellen Maschine vermeiden möchten, sollten MicroK8s als Alternative in Betracht ziehen.
Beiträge, Fragen und Kommentare werden begrüßt und ermutigt! Minikube-Entwickler finden Sie in Slack im #minikube Kanal (Erhalten Sie hier eine Einladung). Wir haben ausserdem die kubernetes-dev Google Groups-Mailingliste. Wenn Sie in der Liste posten, fügen Sie Ihrem Betreff bitte "minikube:" voran.