Барган сайын кардарлар кластердин ичиндеги кызматтарга кирүү мүмкүнчүлүгүн алуу үчүн бизден Kubernetes кластерине кирүү мүмкүнчүлүгүн берүүнү суранышууда: кандайдыр бир маалымат базасына же кызматка түздөн-түз туташуу мүмкүнчүлүгү, кластердин ичиндеги тиркемелер менен локалдык тиркемени туташтыруу...
Мисалы, жергиликтүү машинаңыздан кызматка туташуу зарылчылыгы бар memcached.staging.svc.cluster.local. Биз бул мүмкүнчүлүктү кардар туташтырган кластердин ичиндеги VPN аркылуу камсыз кылабыз. Бул үчүн, биз поднумдардын, кызматтардын субторлорун жарыялайбыз жана DNS кластерин кардарга түртөбүз. Ошентип, кардар кызматка кошулууга аракет кылганда memcached.staging.svc.cluster.local, суроо-талап DNS кластерине барат жана жооп катары бул кызматтын дарегин кластердик тейлөө тармагынан же подкасттын дарегин алат.
Биз K8s кластерлерин kubeadm аркылуу конфигурациялайбыз, бул жерде демейки кызматтын ички тармагы жайгашкан 192.168.0.0/16, ал эми подводдордун тармагы болуп саналат 10.244.0.0/16. Адатта баары жакшы иштейт, бирок бир нече пункттар бар:
- Subnet
192.168.*.*көбүнчө кардарлардын кеңсе тармактарында, ал тургай көбүнчө иштеп чыгуучулардын үй тармактарында колдонулат. Анан биз чыр-чатактарды алабыз: үй роутерлери бул субтордо иштейт жана VPN бул субторлорду кластерден кардарга түртөт. - Бизде бир нече кластерлер бар (өндүрүш, этап жана/же бир нече иштеп чыгуучу кластерлер). Андан кийин, демейки боюнча, алардын бардыгында подтар жана кызматтар үчүн бирдей субтор болот, бул бир нече кластерлерде кызматтар менен бир убакта иштөө үчүн чоң кыйынчылыктарды жаратат.
Биз бир эле долбоордун алкагында кызматтар жана подтармактар үчүн ар кандай ички тармактарды колдонуу практикасын эчак эле кабыл алганбыз - жалпысынан, бардык кластерлерде ар кандай тармактар бар. Бирок, иштеп жаткан кластерлердин көп саны бар, мен нөлдөн баштап айланткым келбейт, анткени алар көптөгөн кызматтарды, мамлекеттик тиркемелерди ж.б.у.с. иштетет.
Анан биз өзүбүзгө суроо бердик: учурдагы кластерде субсетти кантип өзгөртүү керек?
Чечимдерди издөө
Эң кеңири таралган практика — кайра жаратуу бардык ClusterIP түрү менен кызматтар. Опция катары, жана бул:
Төмөнкү процессте көйгөй бар: баары конфигурациялангандан кийин, подколор /etc/resolv.conf дарегинде DNS ат сервери катары эски IP менен келишет.
Мен дагы эле чечим таба албагандыктан, бүт кластерди kubeadm баштапкы абалга келтирип, кайра баштоого туура келди.
Бирок бул баарына ылайыктуу эмес... Бул жерде биздин ишибиз үчүн кененирээк киришүү:
- Фланель колдонулат;
- Булуттарда да, аппаратурада да кластерлер бар;
- Мен кластердеги бардык кызматтарды кайра жайылтуудан алыс болгум келет;
- Жалпысынан бардыгын минималдуу көйгөйлөр менен жасоо зарыл;
- Kubernetes версиясы 1.16.6 (бирок, кийинки кадамдар башка версиялар үчүн окшош болот);
- Негизги милдет - кызматтын субсеттери менен kubeadm аркылуу жайгаштырылган кластерде камсыз кылуу
192.168.0.0/16, менен алмаштырыңыз172.24.0.0/16.
Ошентип, биз көптөн бери Kubernetes'те эмне жана кантип etcd сакталганын, аны менен эмне кылса болорун көрүүгө кызыкканбыз... Ошентип, биз ойлодук: "Эмне үчүн жөн гана эски IP даректерди (субсет) жаңылары менен алмаштырып, etcd ичиндеги маалыматтарды жаңыртпаңыз? "
etcd маалыматтар менен иштөө үчүн даяр куралдарды издеп, биз маселени толугу менен чечкен эч нерсе таба алган жокпуз. (Баса, эгер сиз түздөн-түз etcd ичинде маалыматтар менен иштөө үчүн кандайдыр бир утилиталар жөнүндө билсеңиз, биз шилтемелерди баалайбыз.) Бирок, жакшы башталыш болуп саналат (анын авторлоруна рахмат!).
Бул утилита сертификаттар аркылуу etcd менен туташып, буйруктар аркылуу ал жерден маалыматтарды окуй алат ls, get, dump.
etcdhelper кошуу
Кийинки ой логикалуу: "Бул утилитаны кошууга сизге эмне тоскоолдук кылып жатат, бул etcdге маалымат жазуу мүмкүнчүлүгүн кошуу?"
Бул эки жаңы функция менен etcdhelperдин өзгөртүлгөн версиясы болуп калды changeServiceCIDR и changePodCIDR. ага сиз кодду көрө аласыз .
Жаңы функциялар эмне кылат? Алгоритм changeServiceCIDR:
- deserializer түзүү;
- CIDR алмаштыруу үчүн регулярдуу туюнтманы түзүү;
- биз кластерде ClusterIP түрү менен бардык кызматтарды карап чыгабыз:
- etcd маанисин Go объектине декоддоо;
- регулярдуу туюнтманы колдонуу менен биз даректин биринчи эки байтын алмаштырабыз;
- кызматка жаңы ички тармактан IP дарегин дайындоо;
- сериализатор түзүңүз, Go объектисин протобуфка айландырыңыз, ж.б. жаңы маалыматтарды жазыңыз.
милдети changePodCIDR негизи окшош changeServiceCIDR - кызматтын спецификациясын түзөтүүнүн ордуна гана биз аны түйүн жана өзгөртүү үчүн жасайбыз .spec.PodCIDR жаңы ички тармакка.
практика
CIDR кызматын өзгөртүү
Тапшырманы ишке ашыруу планы абдан жөнөкөй, бирок ал кластердеги бардык поддондорду кайра түзүү учурунда токтоп калууларды камтыйт. Негизги кадамдарды сүрөттөп бергенден кийин, биз теориялык жактан бул токтоп калууларды кантип азайтуу керектиги жөнүндө ой бөлүшөбүз.
Даярдоо кадамдары:
- керектүү программалык камсыздоону орнотуу жана жамаачыланган etcdhelperди чогултуу;
- камдык ж.б. жана
/etc/kubernetes.
CIDR кызматын өзгөртүү боюнча иш-аракеттердин кыскача планы:
- аписерверди жана контроллер-менеджер манифесттерин өзгөртүү;
- күбөлүктөрдү кайра чыгаруу;
- etcd ичинде ClusterIP кызматтарын өзгөртүү;
- кластердеги бардык поддондорду кайра иштетүү.
Төмөндө майда-чүйдөсүнө чейин иш-аракеттердин толук ырааттуулугу болуп саналат.
1. Маалымат таштандысы үчүн etcd-client орнотуңуз:
apt install etcd-client2. Build etcdhelper:
- Голанг орнотуу:
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 - Биз өзүбүз үчүн сактайбыз
etcdhelper.go, көз карандылыкты жүктөп алуу, чогултуу: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. Камдык көчүрмөнү ж.б. жасаңыз:
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. Kubernetes башкаруу планынын манифесттеринде кызматтын ички тармагын өзгөртүңүз. Файлдарда /etc/kubernetes/manifests/kube-apiserver.yaml и /etc/kubernetes/manifests/kube-controller-manager.yaml параметрди өзгөртүү --service-cluster-ip-range жаңы ички тармакка: 172.24.0.0/16 ордуна 192.168.0.0/16.
5. Биз kubeadm аписерверге (анын ичинде) сертификаттарды берген кызматтын ички тармагын өзгөртүп жаткандыктан, аларды кайра чыгаруу керек:
- Келгиле, учурдагы сертификат кайсы домендерге жана IP даректерге берилгенин карап көрөлү:
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 - Келиңиз, 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-адрес мастер узла - Эски crt жана ачкычты жок кылалы, ансыз жаңы сертификат берилбейт:
rm /etc/kubernetes/pki/apiserver.{key,crt} - API сервери үчүн сертификаттарды кайра чыгаралы:
kubeadm init phase certs apiserver --config=kubeadm-config.yaml - Келгиле, тастыктама жаңы ички тармак үчүн берилгенин текшерип көрөлү:
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 - API серверинин сертификатын кайра чыгаргандан кийин анын контейнерин кайра иштетиңиз:
docker ps | grep k8s_kube-apiserver | awk '{print $1}' | xargs docker restart - үчүн конфигурацияны калыбына келтирели
admin.conf:kubeadm alpha certs renew admin.conf - Келгиле, 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Эскертүү! Учурда домендин чечилиши кластерде иштебей калат, анткени учурдагы подкасттарда
/etc/resolv.confэски CoreDNS дареги (kube-dns) катталган жана kube-proxy iptables эрежелерин эски ички тармактан жаңысына өзгөртөт. Андан ары макалада токтоп калууларды азайтуунун мүмкүн болгон варианттары жөнүндө жазылган. - Келгиле, аттар мейкиндигинде ConfigMap'ти оңдойлу
kube-system:kubectl -n kube-system edit cm kubelet-config-1.16- бул жерден алмаштыр
clusterDNSkube-dns кызматынын жаңы IP дарегине:kubectl -n kube-system get svc kube-dns.kubectl -n kube-system edit cm kubeadm-config- оңдойбуз
data.ClusterConfiguration.networking.serviceSubnetжаңы ички тармакка. - Kube-dns дареги өзгөргөндүктөн, бардык түйүндөрдөгү kubelet конфигурациясын жаңыртуу керек:
kubeadm upgrade node phase kubelet-config && systemctl restart kubelet - Кластердеги бардык подкасттарды кайра иштетүү гана калды:
kubectl get pods --no-headers=true --all-namespaces |sed -r 's/(S+)s+(S+).*/kubectl --namespace 1 delete pod 2/e'
Токтоп калуу убактысын азайтыңыз
токтоп калууларды кантип азайтуу боюнча ойлор:
- Башкаруу тегиздигинин манифесттерин өзгөрткөндөн кийин, жаңы kube-dns кызматын түзүңүз, мисалы, аты менен
kube-dns-tmpжана жаңы дарек172.24.0.10. - жасоо
ifкубе-днс кызматын езгертпей турган etcdhelperде. - Бардык кубелеттерде даректи алмаштырыңыз
ClusterDNSжаңысына, ал эми эски кызмат жаңысы менен бир убакта иштей берет. - Табигый себептерден улам же макулдашылган убакытта тиркемелери бар кабыкчалар өзүнөн-өзү жылмайынча күтө туруңуз.
- Кызматты жок кылуу
kube-dns-tmpжана өзгөртүүserviceSubnetCIDRкубе-днс кызматы учун.
Бул план иштебей калуу убактысын ~бир мүнөткө чейин кыскартууга мүмкүндүк берет - кызматты алып салуу мөөнөтү үчүн kube-dns-tmp жана кызмат үчүн ички тармакты өзгөртүү kube-dns.
Модификация podNetwork
Ошол эле учурда, биз пайда болгон etcdhelper аркылуу podNetworkди кантип өзгөртүүнү карап көрүүнү чечтик. Иш-аракеттердин ырааттуулугу төмөнкүдөй:
- конфигурацияларды оңдоо
kube-system; - кубе-контроллер-менеджер манифестин бекитүү;
- podCIDRди түздөн-түз etcd менен өзгөртүү;
- бардык кластер түйүндөрүн кайра жүктөө.
Эми бул иш-аракеттер жөнүндө көбүрөөк маалымат:
1. ConfigMap'ты аттар мейкиндигинде өзгөртүңүз kube-system:
kubectl -n kube-system edit cm kubeadm-config
- оңдоо data.ClusterConfiguration.networking.podSubnet жаңы ички тармакка 10.55.0.0/16.
kubectl -n kube-system edit cm kube-proxy
- оңдоо data.config.conf.clusterCIDR: 10.55.0.0/16.
2. Контроллер-менеджер манифестин өзгөртүңүз:
vim /etc/kubernetes/manifests/kube-controller-manager.yaml
- оңдоо --cluster-cidr=10.55.0.0/16.
3. Учурдагы баалуулуктарды караңыз .spec.podCIDR, .spec.podCIDRs, .InternalIP, .status.addresses бардык кластер түйүндөрү үчүн:
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. etcd түзмөгүнө өзгөртүү киргизүү менен podCIDRди алмаштырыңыз:
./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/165. Келгиле, podCIDR чындап өзгөргөнүн текшерели:
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. Бардык кластер түйүндөрүн бирден кайра жүктөйбүз.
7. Эгер сиз жок дегенде бир түйүн калтырсаңыз эски podCIDR, анда kube-контроллер-менеджер иштей албайт жана кластердеги поддондор пландаштырылбайт.
Чынында, podCIDR өзгөртүү андан да жөнөкөй (мисалы, ). Бирок биз etcd менен түз иштөөнү үйрөнгүбүз келди, анткени etcd ичинде Kubernetes объектилерин түзөткөн учурлар бар - гана мүмкүн болгон вариант. (Мисалы, сиз иштебей туруп эле Кызмат талаасын өзгөртө албайсыз spec.clusterIP.)
жыйынтык
Макалада түздөн-түз etcd ичиндеги маалыматтар менен иштөө мүмкүнчүлүгү каралат, б.а. Kubernetes API'ни айланып өтүү. Кээде бул ыкма "татаал иштерди" кылууга мүмкүндүк берет. Биз текстте берилген операцияларды чыныгы K8s кластерлеринде сынап көрдүк. Бирок, алардын кеңири колдонууга даяр статусу PoC (концепциянын далили). Ошондуктан, эгер сиз өзүңүздүн кластерлериңизде etcdhelper утилитасынын өзгөртүлгөн версиясын колдонгуңуз келсе, аны өзүңүзгө тобокелге салыңыз.
PS
Биздин блогдон дагы окуңуз:
- «";
- «";
- «";
- ««.
Source: www.habr.com