Vår erfarenhet av att arbeta med data i etcd Kubernetes-klustren direkt (utan K8s API)

Allt fler kunder vänder sig till oss med önskemål om att få tillgång till Kubernetes-klustret för att kunna nå tjänster inom klustret: så att man direkt kan ansluta till en databas eller tjänst, för att koppla en lokal applikation till applikationer inom klustret…

Till exempel uppstår behovet av att ansluta från sin lokala maskin till tjänsten memcached.staging.svc.cluster.local. Vi erbjuder denna möjlighet via VPN inom klustret, som kunden ansluter till. För detta annonserar vi pod-subnät, tjänster och pushar kluster-DNS till kunden. På så sätt, när kunden försöker ansluta till tjänsten memcached.staging.svc.cluster.local, skickas en begäran till kluster-DNS och får som svar adressen till denna tjänst från tjänsternas nätverk eller adressen till pod'en.

K8s-kluster konfigurerar vi med kubeadm, där standard tjänstenätverket är 192.168.0.0/16, och pod-nätverket är 10.244.0.0/16. Vanligtvis fungerar allt bra, men det finns ett par saker:

• Subnätverket 192.168.*.* används ofta i kundernas kontorsnätverk, och ännu oftare i utvecklares hemmarnätverk. Och då får vi konflikter: hemmaroutrar arbetar i detta subnät och VPN pushar dessa subnät från klustret till kunden.
• Vi har flera kluster (produktionskluster, stage och/eller flera utvecklingskluster). Då kommer de alla att ha samma standard-subnät för poddar och tjänster, vilket skapar stora problem för samtidig användning av tjänster i flera kluster.

Vi har sedan länge antagit en praxis att använda olika subnät för tjänster och poddar inom ett och samma projekt — för att alla kluster skall ha olika nätverk. Men det finns ett stort antal kluster i drift, som vi inte vill börja om från grunden med, eftersom många tjänster, stateful-applikationer osv. är igång där.

Och då ställde vi oss frågan: hur skulle man kunna ändra subnätet i ett befintligt kluster?

Sök efter lösningar

Det vanligaste tillvägagångssättet är att återskapa alla tjänster med typ ClusterIP. Som ett alternativ kan de rekommendera och så här:

Den följande processen har ett problem: efter att allt är konfigurerat kommer poddarna upp med den gamla IP:n som DNS-nameserver i /etc/resolv.conf.
Eftersom jag fortfarande inte hittade lösningen, var jag tvungen att återställa hela klustret med kubeadm reset och initiera det igen.

Men inte alla passar för detta… Här är mer detaljerad information för vårt fall:

• Flannel används;
• Det finns kluster både i molnet och på hårdvara;
• Vi vill undvika att behöva deploya alla tjänster i klustret igen;
• Det finns ett behov av att lösa allt med minimala problem;
• Kubernetes-versionen är 1.16.6 (övriga åtgärder kommer att vara desamma för andra versioner);
• Huvuduppgiften är att i klustret, distribuerat med kubeadm med service-subnätet, 192.168.0.0/16, ersätta det med 172.24.0.0/16.

Och det råkar också vara så att vi länge varit intresserade av att se vad och hur Kubernetes lagrar i etcd, vad som går att göra med detta… Så vi tänkte: "Varför inte bara uppdatera uppgifterna i etcd genom att ersätta de gamla IP-adresserna (subnätet) med nya??»

Efter att ha letat efter färdiga verktyg för att arbeta med data i etcd, fann vi inget som helt löste den ställda uppgiften. (Förresten, om ni känner till några verktyg för att arbeta med data direkt i etcd — vi skulle uppskatta länkar.) En bra utgångspunkt blev etcdhelper från OpenShift (tack till dess skapare!).

Detta verktyg kan ansluta till etcd med certifikat och läsa data därifrån med hjälp av kommandon. ls, hämta, dump.

Vi lägger till etcdhelper

Den nästa tanken är logisk: "Vad hindrar oss från att utöka detta verktyg genom att lägga till möjlighet att skriva data i etcd?"

Detta blev en modifierad version av etcdhelper med två nya funktioner: changeServiceCIDR och changePodCIDR. Koden för den kan ses här.

Vad gör de nya funktionerna? Algoritmen changeServiceCIDR:

• skapar en deserialiserare;
• kompilerar ett reguljärt uttryck för att ersätta CIDR;
• går igenom alla tjänster av typen ClusterIP i klustret:
  • avkodar värdet från etcd till ett Go-objekt;
  • ersätter de första två bytes av adressen med hjälp av det reguljära uttrycket;
  • tilldelar tjänsten en IP-adress från det nya subnätet;
  • skapar en serialiserare, omvandlar Go-objektet till protobuf, skriver de nya uppgifterna i etcd.

Funktionen changePodCIDR är i grunden liknande changeServiceCIDR — bara istället för att redigera specifikationerna för tjänsterna gör vi detta för noden och ändrar .spec.PodCIDR till det nya subnätet.

Praxis

Ändring av serviceCIDR

Planen för att genomföra den ställda uppgiften är mycket enkel, men innebär nedetid under återställandet av alla poddar i klustret. Efter att ha beskrivit de grundläggande stegen kommer vi också att dela våra tankar om hur man i teorin kan minimera denna nedetid.

Förberedande åtgärder:

• installera nödvändig programvara och bygga det patchade etcdhelper;
• backup av etcd och /etc/kubernetes.

Kort handlingsplan för att ändra serviceCIDR:

• ändra manifest för apiserver och controller-manager;
• omutfärda certifikat;
• ändring av ClusterIP-tjänster i etcd;
• omstart av alla poddar i klustret.

Här presenteras hela sekvensen av åtgärder i detalj.

1. Installera etcd-klienten för att dumpa data:

apt install etcd-client

2. Bygg etcdhelper:

• Installera golang:

  GOPATH=\/root\/golang
  mkdir -p $GOPATH\/local
  curl -sSL https:\/\/dl.google.com\/go\/go1.14.1.linux-amd64.tar.gz | tar -xzvC $GOPATH\/local
  echo "export GOPATH="$GOPATH"" >> ~\/.bashrc
  echo 'export GOROOT="$GOPATH\/local\/go"' >> ~\/.bashrc
  echo 'export PATH="$PATH:$GOPATH\/local\/go\/bin"' >> ~\/.bashrc

• Spara etcdhelper.go, ladda ner beroenden, bygg:

  wget https:\/\/raw.githubusercontent.com\/flant\/examples\/master\/2020\/04-etcdhelper\/etcdhelper.go
  go get go.etcd.io\/etcd\/clientv3 k8s.io\/kubectl\/pkg\/scheme k8s.io\/apimachinery\/pkg\/runtime
  go build -o etcdhelper etcdhelper.go

3. Skapa en backup av etcd:

backup_dir=\/root\/backup
mkdir ${backup_dir}
cp -rL \/etc\/kubernetes ${backup_dir}
ETCDCTL_API=3 etcdctl --cacert=\/etc\/kubernetes\/pki\/etcd\/ca.crt --key=\/etc\/kubernetes\/pki\/etcd\/server.key --cert=\/etc\/kubernetes\/pki\/etcd\/server.crt --endpoints https:\/\/192.168.199.100:2379 snapshot save ${backup_dir}\/etcd.snapshot

4. Ändra tjänstnätet i Kubernetes control plane-manifesten. I filerna /etc/kubernetes/manifests/kube-apiserver.yaml och /etc/kubernetes/manifests/kube-controller-manager.yaml ändra parameter --service-cluster-ip-range till det nya nätet: 172.24.0.0/16 istället för 192.168.0.0/16.

5. Eftersom vi ändrar tjänstnätet, för vilket kubeadm utfärdar certifikat för apiservern (bland annat), måste de utfärdas på nytt:

1. Låt oss titta på vilka domäner och IP-adresser det nuvarande certifikatet har utfärdats för:

   openssl x509 -noout -ext subjectAltName <\/etc\/kubernetes\/pki\/apiserver.crt
   X509v3 Subject Alternative Name:
       DNS:dev-1-master, DNS:kubernetes, DNS:kubernetes.default, DNS:kubernetes.default.svc, DNS:kubernetes.default.svc.cluster.local, DNS:apiserver, IP Address:192.168.0.1, IP Address:10.0.0.163, IP Address:192.168.199.100

2. Förbered en minimal konfiguration för kubeadm:

   cat kubeadm-config.yaml
   apiVersion: kubeadm.k8s.io\/v1beta1
   kind: ClusterConfiguration
   networking:
     podSubnet: "10.244.0.0\/16"
     serviceSubnet: "172.24.0.0\/16"
   apiServer:
     certSANs:
     - "192.168.199.100" # IP-adress för master noden

3. Ta bort gamla crt och key, annars kommer det nya certifikatet inte att utfärdas:

   rm \/etc\/kubernetes\/pki\/apiserver.{key,crt}

4. Utfärda certifikat på nytt för API-servern:

   kubeadm init phase certs apiserver --config=kubeadm-config.yaml

5. Kontrollera att certifikatet har utfärdats för det nya nätet:

   openssl x509 -noout -ext subjectAltName <\/etc\/kubernetes\/pki\/apiserver.crt
   X509v3 Subject Alternative Name:
       DNS:kube-2-master, DNS:kubernetes, DNS:kubernetes.default, DNS:kubernetes.default.svc, DNS:kubernetes.default.svc.cluster.local, IP Address:172.24.0.1, IP Address:10.0.0.163, IP Address:192.168.199.100

6. Efter att certifikatet för API-servern har utfärdats på nytt, starta om dess container:

   docker ps | grep k8s_kube-apiserver | awk '{print $1}' | xargs docker restart

7. Regenerera konfigurationen för admin.conf:

   kubeadm alpha certs renew admin.conf

8. Redigera data i etcd:

   .\/etcdhelper -cacert \/etc\/kubernetes\/pki\/etcd\/ca.crt -cert \/etc\/kubernetes\/pki\/etcd\/server.crt -key \/etc\/kubernetes\/pki\/etcd\/server.key -endpoint https:\/\/127.0.0.1:2379 change-service-cidr 172.24.0.0\/16 

   Varning! I detta ögonblick slutar domänupplösningen att fungera i klustret, eftersom de redan existerande poddarna har /etc/resolv.conf den gamla adressen för CoreDNS (kube-dns) inställd, och kube-proxy har ändrat iptables-reglerna från det gamla subnätet till det nya. Artikeln beskriver sedan möjliga alternativ för att minimera driftsstopp.

9. Vi justerar ConfigMap:ar i namnområdet kube-system:

   kubectl -n kube-system edit cm kubelet-config-1.16

   — här kommer vi att byta ut clusterDNS mot den nya IP-adressen för kube-dns-tjänsten: kubectl -n kube-system get svc kube-dns.

   kubectl -n kube-system edit cm kubeadm-config

   — vi kommer att korrigera data.ClusterConfiguration.networking.serviceSubnet till det nya subnätet.

10. Eftersom adressen för kube-dns har ändrats är det nödvändigt att uppdatera kubelet-konfigurationen på alla noder:

    kubeadm upgrade node phase kubelet-config && systemctl restart kubelet

11. Det återstår att starta om alla poddar i klustret:

    kubectl get pods --no-headers=true --all-namespaces | sed -r 's\/(S+)s+(S+).*\/kubectl --namespace \1 delete pod \2\/e'

Minimera driftsstopp

Fundera på hur man kan minimera nedetid:

1. Efter förändringarna av kontrollplansmanifesten, skapa en ny kube-dns-tjänst, till exempel med namnet kube-dns-tmp och den nya adressen 172.24.0.10.
2. Gör if i etcdhelper, som inte kommer att modifiera kube-dns-tjänsten.
3. Byt ut adressen i alla kubeletar ClusterDNS till den nya, medan den gamla tjänsten fortsätter att fungera samtidigt som den nya.
4. Vänta på att poddar med ansökningar ska rullas ut antingen av sig själva av naturliga skäl, eller vid en överenskommet tid.
5. Ta bort tjänsten kube-dns-tmp och ändra serviceSubnetCIDR för kube-dns-tjänsten.

Denna plan kommer att minimera nedetiden till ~en minut – tiden det tar att ta bort tjänsten kube-dns-tmp och byta subnet för tjänsten Det mest intressanta och nya för mig var själva anledningen till den betydande ökningen av DNS-förfrågningar. Om detta och vad man ska göra åt det handlar mitt inlägg..

Modifiering av podNetwork

Samtidigt har vi beslutat att se hur man modifierar podNetwork med hjälp av den resulterande etcdhelper. Stegen blir följande:

• Vi justerar konfigurationerna i kube-system;
• vi justerar kube-controller-manager-manifestet;
• vi ändrar podCIDR direkt i etcd;
• vi startar om alla noder i klustret.

Nu mer detaljerat om dessa åtgärder:

1. Modifiera ConfigMap:ar i namnområdet kube-system:

kubectl -n kube-system edit cm kubeadm-config

— vi justerar data.ClusterConfiguration.networking.podSubnet till det nya subnätet 10.55.0.0/16.

kubectl -n kube-system edit cm kube-proxy

— vi justerar data.config.conf.clusterCIDR: 10.55.0.0/16.

2. Modifiera controller-manager-manifestet:

vim /etc/kubernetes/manifests/kube-controller-manager.yaml

— vi justerar --cluster-cidr=10.55.0.0/16.

3. Kolla aktuella värden .spec.podCIDR, .spec.podCIDRs, .InternalIP, .status.addresses för alla noder i klustret:

kubectl get no -o json | jq '[.items[] | {"name": .metadata.name, "podCIDR": .spec.podCIDR, "podCIDRs": .spec.podCIDRs, "InternalIP": (.status.addresses[] | select(.type == "InternalIP") | .address)}]'

[
  {
    "name": "kube-2-master",
    "podCIDR": "10.244.0.0/24",
    "podCIDRs": [
      "10.244.0.0/24"
    ],
    "InternalIP": "192.168.199.2"
  },
  {
    "name": "kube-2-master",
    "podCIDR": "10.244.0.0/24",
    "podCIDRs": [
      "10.244.0.0/24"
    ],
    "InternalIP": "10.0.1.239"
  },
  {
    "name": "kube-2-worker-01f438cf-579f9fd987-5l657",
    "podCIDR": "10.244.1.0/24",
    "podCIDRs": [
      "10.244.1.0/24"
    ],
    "InternalIP": "192.168.199.222"
  },
  {
    "name": "kube-2-worker-01f438cf-579f9fd987-5l657",
    "podCIDR": "10.244.1.0/24",
    "podCIDRs": [
      "10.244.1.0/24"
    ],
    "InternalIP": "10.0.4.73"
  }
]

4. Vi byter ut podCIDR genom att göra ändringar direkt i etcd:

./etcdhelper -cacert /etc/kubernetes/pki/etcd/ca.crt -cert /etc/kubernetes/pki/etcd/server.crt -key /etc/kubernetes/pki/etcd/server.key -endpoint https://127.0.0.1:2379 change-pod-cidr 10.55.0.0/16

5. Vi kontrollerar att podCIDR verkligen har ändrats:

kubectl get no -o json | jq '[.items[] | {"name": .metadata.name, "podCIDR": .spec.podCIDR, "podCIDRs": .spec.podCIDRs, "InternalIP": (.status.addresses[] | select(.type == "InternalIP") | .address)}]'

[
  {
    "name": "kube-2-master",
    "podCIDR": "10.55.0.0/24",
    "podCIDRs": [
      "10.55.0.0/24"
    ],
    "InternalIP": "192.168.199.2"
  },
  {
    "name": "kube-2-master",
    "podCIDR": "10.55.0.0/24",
    "podCIDRs": [
      "10.55.0.0/24"
    ],
    "InternalIP": "10.0.1.239"
  },
  {
    "name": "kube-2-worker-01f438cf-579f9fd987-5l657",
    "podCIDR": "10.55.1.0/24",
    "podCIDRs": [
      "10.55.1.0/24"
    ],
    "InternalIP": "192.168.199.222"
  },
  {
    "name": "kube-2-worker-01f438cf-579f9fd987-5l657",
    "podCIDR": "10.55.1.0/24",
    "podCIDRs": [
      "10.55.1.0/24"
    ],
    "InternalIP": "10.0.4.73"
  }
]

6. Vi startar om alla noder i klustret en i taget.

7. Om ens en nod lämnas med den gamla podCIDR, kan kube-controller-manager inte startas, vilket innebär att poddar i klustret inte kommer att schemaläggas.

Ändringen av podCIDR kan faktiskt göras enklare (till exempel, så). Men vi ville ju lära oss att arbeta direkt med etcd, för det finns tillfällen när det kan vara nödvändigt att redigera Kubernetes-objekt i etcd — den enda en möjlig lösning. (Till exempel kan man inte bara ändra ett Service-fält utan att få nedtid, spec.clusterIP.)

Resultat

Denna artikel undersöker möjligheten att arbeta med data direkt i etcd, det vill säga utan Kubernetes API. Ibland gör detta tillvägagångssätt det möjligt att göra "smartare grejer". De operationer som presenteras har testats på verkliga K8s-kluster. Deras status för bred användning är — PoC (proof of concept). Därför, om du vill använda en modifierad version av verktyget etcdhelper på dina kluster, gör det på egen risk.

P.S.

Läs även i vår blogg:

• «etcd 3.4.3: undersökning av tillförlitlighet och säkerhet hos lagret»;
• «Calico för nätverk i Kubernetes: introduktion och lite erfarenhet»;
• «6 intressanta systembuggar vid användning av Kubernetes [och deras lösningar]»;
• «Visuell guide för felsökning i Kubernetes».

Källa: habr.com