L-am urmărit pe cel al lui Kelsey Hightower Kubernetes pe calea grea care vă ghidează prin configurarea manuală a unui cluster k8s.
Aceasta este nu rulează pe minikube - rulează pe un VPS la distanță.
Sunt la pasul în care am configurat planul de control al k8s.
Cu toate acestea, atunci când încercați să efectuați o verificare a stării de sănătate kube-apiserver Primesc următoarele:
$ kubectl cluster-info --kubeconfig admin.kubeconfig
Pentru a depana și a diagnostica în continuare problemele clusterului, utilizați „kubectl cluster-info dump”.
Conexiunea la serverul 127.0.0.1:6443 a fost refuzată - ați specificat gazda sau portul potrivit?
Nu sunt sigur de unde să încep depanarea de aici.
Configurare
Toate cele 3 servicii k8s rulează:
starea systemctl kube-apiserver kube-controller-manager kube-scheduler etcd
# => Toate cele 4 returnează: „activ (în rulare)”
The kube-apiserver este configurat pentru a începe cu systemd:
$ cat /etc/systemd/system/kube-apiserver.service
[Unitate]
Descriere=Server API Kubernetes
Documentație=https://github.com/kubernetes/kubernetes
[Serviciu]
ExecStart=/usr/local/bin/kube-apiserver \
--advertise-address=$INTERNAL_IP_REDACTED \
--allow-privileged=true \
--apiserver-count=3 \
--audit-log-maxage=30 \
--audit-log-maxbackup=3 \
--audit-log-maxsize=100 \
--audit-log-path=/var/log/audit.log \
--authorization-mode=Nod,RBAC \
--bind-address=0.0.0.0 \
--client-ca-file=/var/lib/kubernetes/ca.pem \
--enable-admission-plugins=NamespaceLifecycle,NodeRestriction,LimitRanger,ServiceAccount,DefaultStorageClass,ResourceQuota\
--etcd-cafile=/var/lib/kubernetes/ca.pem \
--etcd-certfile=/var/lib/kubernetes/kubernetes.pem \
--etcd-keyfile=/var/lib/kubernetes/kubernetes-key.pem \
--etcd-servers=https://10.240.0.10:2379,https://10.240.0.11:2379,https://10.240.0.12:2379 \
--event-ttl=1h \
--encryption-provider-config=/var/lib/kubernetes/encryption-config.yaml \
--kubelet-certificate-authority=/var/lib/kubernetes/ca.pem \
--kubelet-client-certificate=/var/lib/kubernetes/kubernetes.pem \
--kubelet-client-key=/var/lib/kubernetes/kubernetes-key.pem \
--runtime-config='api/all=true' \
--service-account-key-file=/var/lib/kubernetes/service-account.pem \
--service-account-signing-key-file=/var/lib/kubernetes/service-account-key.pem \
--service-account-issuer=https://$EXTERNAL_IP_REDACTED:6443 \
--service-cluster-ip-range=10.32.0.0/24 \
--service-node-port-range=30000-32767 \
--tls-cert-file=/var/lib/kubernetes/kubernetes.pem \
--tls-private-key-file=/var/lib/kubernetes/kubernetes-key.pem \
--v=2
Restart=la eșec
RestartSec=5
[Instalare]
WantedBy=multi-user.target
The kube-apiserver cu siguranță rulează și ascultă pe port :6443
$ lsof -iTCP -sTCP:ASCULTĂ -n -P | grep 6443
kube-apis 989442 root 7u IPv6 9345693 0t0 TCP *:6443 (ASCULTATE)
Aici este admin.kubeconfig fișier care este configurat să caute clusterul la 127.0.0.1:6443
apiVersion: v1
clustere:
- cluster:
date-autoritatea-de-certificat: LS0tL...
server: https://127.0.0.1:6443
nume: kubernetes-the-hard-way
contexte:
- context:
cluster: kubernetes-the-hard-way
utilizator: admin
nume: implicit
contextul curent: implicit
fel: Config
preferințe: {}
utilizatori:
- nume: admin
utilizator:
date-certificat-client: LS0tLS1CRU...
date-cheie-client: LS0tLS1C....
Există un certificat SSL furnizat (creat mai devreme în tutorialul Kubernetes)
$ ls -hlt /var/lib/kubernetes/ca*
-rw------- 1 rădăcină rădăcină 1.7K 18 decembrie 00:56 /var/lib/kubernetes/ca-key.pem
-rw-r--r-- 1 rădăcină rădăcină 1.3K 18 decembrie 00:56 /var/lib/kubernetes/ca.pem
În cele din urmă, NGINX este, de asemenea, configurat să redirecționeze portul 80 trafic către punctul final al controlului de sănătate
$ cat /etc/nginx/sites-available/kubernetes.default.svc.cluster.local
Server {
asculta 80;
nume_server kubernetes.default.svc.cluster.local;
locație /healthz {
proxy_pass https://127.0.0.1:6443/healthz;
proxy_ssl_trusted_certificate /var/lib/kubernetes/ca.pem;
}
}
După cum am menționat mai sus, nu văd cu adevărat ce este în neregulă și Nu am idee de unde să încep să investighez.
Mulțumesc!
