Pengalaman kita nggarap data ing kluster Kubernetes etcd langsung (tanpa API K8s)

Tambah akeh, klien njaluk supaya kita menehi akses menyang kluster Kubernetes supaya bisa ngakses layanan ing kluster: supaya bisa langsung nyambung menyang sawetara database utawa layanan, kanggo nyambungake aplikasi lokal karo aplikasi ing kluster...

Contone, ana perlu kanggo nyambung saka mesin lokal menyang layanan memcached.staging.svc.cluster.local. Kita nyedhiyakake kemampuan iki nggunakake VPN ing kluster sing disambungake klien. Kanggo nindakake iki, kita ngumumake subnet pods, layanan lan push cluster DNS menyang klien. Mangkono, nalika klien nyoba nyambung menyang layanan kasebut memcached.staging.svc.cluster.local, panjalukan menyang DNS kluster lan nanggepi alamat layanan iki saka jaringan layanan kluster utawa alamat pod.

Kita ngatur kluster K8s nggunakake kubeadm, ngendi subnet layanan standar 192.168.0.0/16, lan jaringan pods punika 10.244.0.0/16. Biasane kabeh bisa mlaku kanthi apik, nanging ana sawetara poin:

• Subnet 192.168.*.* asring digunakake ing jaringan kantor klien, lan malah luwih asring ing jaringan asal pangembang. Banjur kita entuk konflik: router ngarep nggarap subnet iki lan VPN nyurung subnet kasebut saka kluster menyang klien.
• Kita duwe sawetara klompok (produksi, panggung lan / utawa sawetara klompok dev). Banjur, kanthi standar, kabeh bakal duwe subnet sing padha kanggo pod lan layanan, sing nggawe kesulitan gedhe kanggo karya simultan karo layanan ing sawetara klompok.

Kita wis suwe nggunakake praktik nggunakake subnet sing beda kanggo layanan lan pod ing proyek sing padha - umume, supaya kabeh klompok duwe jaringan sing beda. Nanging, ana akeh klompok ing operasi sing aku ora kaya kanggo muter liwat saka ngeruk, amarga padha mbukak akeh layanan, aplikasi stateful, etc.

Banjur kita takon dhéwé: carane ngganti subnet ing kluster sing wis ana?

Nggoleki keputusan

Praktek sing paling umum yaiku nggawe maneh kabeh layanan karo jinis ClusterIP. Minangka pilihan, bisa menehi saran lan iki:

Proses ing ngisor iki duwe masalah: sawise kabeh diatur, pods teka karo IP lawas minangka nameserver DNS ing /etc/resolv.conf.
Amarga aku isih ora nemokake solusi, aku kudu ngreset kabeh kluster kanthi ngreset kubeadm lan miwiti maneh.

Nanging iki ora cocok kanggo kabeh wong ... Iki introduksi luwih rinci kanggo kasus kita:

• Flanel digunakake;
• Ana klompok loro ing méga lan ing hardware;
• Aku kaya supaya re-deploying kabeh layanan ing kluster;
• Ana perlu kanggo umume kabeh karo nomer minimal masalah;
• Versi Kubernetes yaiku 1.16.6 (Nanging, langkah sabanjure bakal padha karo versi liyane);
• Tugas utama kanggo mesthekake yen ing kluster disebarake nggunakake kubeadm karo subnet layanan 192.168.0.0/16, ganti karo 172.24.0.0/16.

Lan kedaden kita wis suwe kepengin weruh apa lan carane ing Kubernetes disimpen ing etcd, apa sing bisa ditindakake ... Dadi kita mikir: "Apa ora mung nganyari data ing etcd, ngganti alamat IP lawas (subnet) karo anyar? "

Sawise nggoleki alat sing wis siap kanggo nggarap data ing etcd, kita ora nemokake apa wae sing ngrampungake masalah kasebut. (Oalah, yen sampeyan ngerti babagan apa wae utilitas kanggo nggarap data langsung ing etcd, kita bakal ngurmati tautan kasebut.) Nanging, titik wiwitan sing apik yaiku etcdhelper saka OpenShift (Thanks kanggo penulis!).

Utilitas iki bisa nyambung menyang etcd nggunakake sertifikat lan maca data saka ing kono nggunakake printah ls, get, dump.

Tambah etcdhelper

Pikiran sabanjure logis: "Apa sing ngalangi sampeyan nambahake sarana iki kanthi nambah kemampuan nulis data menyang etcd?"

Iku dadi versi modifikasi saka etcdhelper karo rong fungsi anyar changeServiceCIDR и changePodCIDR. marang dheweke sampeyan bisa ndeleng kode kene.

Apa fungsi anyar? Algoritma changeServiceCIDR:

• nggawe deserializer;
• ngumpulake ekspresi reguler kanggo ngganti CIDR;
• kita ngliwati kabeh layanan kanthi jinis ClusterIP ing kluster:
  • decode nilai saka etcd menyang obyek Go;
  • nggunakake ekspresi reguler kita ngganti rong bita pisanan saka alamat;
  • nemtokake layanan alamat IP saka subnet anyar;
  • nggawe serializer a, Ngonversi obyek Go menyang protobuf, nulis data anyar kanggo etcd.

fungsi changePodCIDR ateges padha changeServiceCIDR - mung tinimbang nyunting spesifikasi layanan, kita nindakake kanggo simpul lan owah-owahan .spec.PodCIDR menyang subnet anyar.

Praktek

Ganti layanan CIDR

Rencana kanggo ngleksanakake tugas kasebut gampang banget, nanging kalebu downtime nalika nggawe kabeh polong ing kluster. Sawise njlentrehake langkah-langkah utama, kita uga bakal nuduhake pikirane babagan carane, ing teori, downtime iki bisa diminimalisir.

Langkah-langkah persiapan:

• nginstal piranti lunak sing dibutuhake lan ngrakit etcdhelper sing ditambal;
• serep etcd lan /etc/kubernetes.

Rencana aksi singkat kanggo ngganti layananCIDR:

• ngganti apiserver lan controller-manager manifests;
• penerbitan maneh sertifikat;
• ngganti layanan ClusterIP ing etcd;
• miwiti maneh kabeh pods ing kluster.

Ing ngisor iki minangka urutan lengkap tumindak kanthi rinci.

1. Instal etcd-klien kanggo mbucal data:

apt install etcd-client

2. Mbangun etcdhelper:

• Pasang 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

• Kita nyimpen kanggo awake dhewe etcdhelper.go, download dependensi, kumpulake:

  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. Gawe serep 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. Ngganti subnet layanan ing bidang kontrol Kubernetes manifests. Ing file /etc/kubernetes/manifests/kube-apiserver.yaml и /etc/kubernetes/manifests/kube-controller-manager.yaml ngganti parameter --service-cluster-ip-range menyang subnet anyar: 172.24.0.0/16 tinimbang 192.168.0.0/16.

5. Amarga kita ngganti subnet layanan sing kubeadm ngetokake sertifikat kanggo apiserver (kalebu), kudu diterbitake maneh:

1. Ayo ndeleng domain lan alamat IP sing sertifikat saiki wis ditanggepi:

   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. Ayo nyiyapake konfigurasi minimal kanggo 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-адрес мастер узла

3. Ayo mbusak crt lan kunci lawas, amarga tanpa sertifikat anyar ora bakal ditanggepi:

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

4. Ayo menehi maneh sertifikat kanggo server API:

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

5. Ayo priksa manawa sertifikat ditanggepi kanggo subnet anyar:

   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. Sawise ngetokake sertifikat server API maneh, wadhahe maneh:

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

7. Ayo dadi regenerate config kanggo admin.conf:

   kubeadm alpha certs renew admin.conf

8. Ayo ngowahi data ing 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 

   Ati-ati Ing wektu iki, résolusi domain mandheg ing kluster, amarga ana ing pods /etc/resolv.conf alamat CoreDNS lawas (kube-dns) kedhaftar, lan kube-proxy ngganti aturan iptables saka subnet lawas menyang anyar. Luwih ing artikel kasebut ditulis babagan opsi sing bisa kanggo nyuda downtime.

9. Ayo ndandani ConfigMap ing ruang jeneng kube-system:

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

   - ngganti kene clusterDNS menyang alamat IP anyar layanan kube-dns: kubectl -n kube-system get svc kube-dns.

   kubectl -n kube-system edit cm kubeadm-config

   - kita bakal ndandani iku data.ClusterConfiguration.networking.serviceSubnet menyang subnet anyar.

10. Wiwit alamat kube-dns wis diganti, sampeyan kudu nganyari konfigurasi kubelet ing kabeh simpul:

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

11. Kabeh sing isih ana yaiku miwiti maneh kabeh pod ing kluster:

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

Nyilikake downtime

Pikiran babagan carane nyilikake downtime:

1. Sawise ngganti manifests bidang kontrol, nggawe layanan kube-dns anyar, contone, karo jeneng kube-dns-tmp lan alamat anyar 172.24.0.10.
2. Kanggo nggawe if ing etcdhelper, sing ora bakal ngowahi layanan kube-dns.
3. Ganti alamat ing kabeh kubelets ClusterDNS menyang anyar, nalika layanan lawas bakal terus bisa bebarengan karo anyar.
4. Enteni nganti pods karo aplikasi muter liwat dhewe kanggo alasan alam utawa ing wektu sing disepakati.
5. Mbusak layanan kube-dns-tmp lan owah-owahan serviceSubnetCIDR kanggo layanan kube-dns.

Rencana iki bakal ngidini sampeyan nyilikake downtime nganti ~sawijining menit - sajrone wektu mbusak layanan kube-dns-tmp lan ngganti subnet kanggo layanan kasebut kube-dns.

Modifikasi podNetwork

Ing wektu sing padha, kita mutusake kanggo ndeleng carane ngowahi podNetwork nggunakake etcdhelper asil. Urutane tumindak kaya ing ngisor iki:

• ndandani konfigurasi ing kube-system;
• ndandani manifes kube-controller-manager;
• ngganti podCIDR langsung ing etcd;
• urip maneh kabeh simpul kluster.

Saiki luwih akeh babagan tumindak kasebut:

1. Owahi ConfigMap ing namespace kube-system:

kubectl -n kube-system edit cm kubeadm-config

- mbenerake data.ClusterConfiguration.networking.podSubnet menyang subnet anyar 10.55.0.0/16.

kubectl -n kube-system edit cm kube-proxy

- mbenerake data.config.conf.clusterCIDR: 10.55.0.0/16.

2. Ngowahi manifest controller-manager:

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

- mbenerake --cluster-cidr=10.55.0.0/16.

3. Deleng nilai saiki .spec.podCIDR, .spec.podCIDRs, .InternalIP, .status.addresses kanggo kabeh node kluster:

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. Ganti podCIDR kanthi ngganti langsung menyang 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. Priksa manawa podCIDR wis owah tenan:

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. Ayo urip maneh kabeh kelenjar kluster siji-siji.

7. Yen sampeyan ninggalake paling siji simpul podCIDR lawas, banjur kube-controller-manager ora bakal bisa miwiti, lan pods ing kluster ora bakal dijadwal.

Nyatane, ngganti podCIDR bisa ditindakake luwih gampang (contone, supaya). Nanging kita pengin sinau cara nggarap etcd langsung, amarga ana kasus nalika nyunting obyek Kubernetes ing etcd - tunggal bisa varian. (Contone, sampeyan ora bisa ngganti lapangan Layanan tanpa downtime spec.clusterIP.)

Asile

Artikel kasebut mbahas kemungkinan nggarap data ing etcd langsung, i.e. nglewati API Kubernetes. Kadhangkala pendekatan iki ngidini sampeyan nindakake "prakara sing angel." We dites operasi diwenehi ing teks ing kluster K8s nyata. Nanging, status kesiapan kanggo panggunaan sing akeh yaiku PoC (bukti konsep). Mulane, yen sampeyan pengin nggunakake versi modifikasi saka utilitas etcdhelper ing kluster sampeyan, nglakoni kanthi resiko dhewe.

PS

Waca uga ing blog kita:

• «etcd 3.4.3: sinau linuwih panyimpenan lan keamanan";
• «Calico kanggo jaringan ing Kubernetes: introduksi lan pengalaman sethithik";
• «6 bug sistem sing nyenengake ing operasi Kubernetes [lan solusine]";
• «Pandhuan Visual kanggo Ngatasi Masalah Kubernetes".

Source: www.habr.com