Өнөө шөнө Kubernetes-ийн дараагийн хувилбар - . Манай блогт зориулж бий болсон уламжлалын дагуу бид энэхүү гайхамшигтай Нээлттэй эхийн бүтээгдэхүүний шинэ хувилбарын гол өөрчлөлтүүдийн талаар ярьж байна.
Энэ материалыг бэлтгэхэд ашигласан мэдээллийг эндээс авсан болно , болон холбогдох асуудлууд, татах хүсэлт, Kubernetes Enhancement Proposals (KEP).
SIG кластерийн амьдралын мөчлөгийн чухал танилцуулгаас эхэлцгээе: динамик бүтэлгүйтлийн кластерууд Kubernetes (эсвэл илүү нарийвчлалтайгаар, өөрөө зохион байгуулсан HA байршуулалт) одоо байна танил (нэг зангилааны кластерын контекст) командуудыг ашиглах kubeadm (init и join). Товчхондоо, үүний тулд:
- кластерт ашигласан гэрчилгээг нууцад шилжүүлсэн;
- K8s кластер дотор etcd кластер ашиглах боломжийн хувьд (жишээ нь өмнө нь байсан гадаад хамаарлаас ангижрах) ;
- Гадны ачаалал тэнцвэржүүлэгчийн санал болгож буй тохиргоог баримтжуулсан бөгөөд энэ нь алдааг тэсвэрлэх чадвартай тохиргоог хангадаг (ирээдүйд энэ хамаарлыг арилгахаар төлөвлөж байгаа боловч энэ үе шатанд биш).
kubeadm ашиглан бүтээсэн Kubernetes HA кластерын архитектур
Хэрэгжилтийн талаарх дэлгэрэнгүй мэдээллийг эндээс авах боломжтой . Энэ функц нь үнэхээр удаан хүлээгдэж байсан: альфа хувилбар нь K8s 1.9-д буцаж ирэх төлөвтэй байсан боловч одоо л гарч ирсэн.
API
баг apply ерөнхийдөө ярих тунхаглалын объектын удирдлага нь kubectl apiserver дээр. Хөгжүүлэгчид өөрсдөө ийм байдлаар шийдвэрээ товч тайлбарлав kubectl apply - Kubernetes дахь тохиргоотой ажиллах үндсэн хэсэг боловч "энэ нь алдаануудаар дүүрэн бөгөөд засахад хэцүү" тул энэ функцийг хэвийн байдалд оруулж, хяналтын хавтгайд шилжүүлэх шаардлагатай байна. Өнөөдөр байгаа асуудлуудын энгийн бөгөөд тодорхой жишээнүүд:
Хэрэгжилтийн талаар дэлгэрэнгүй мэдээлэл байна . Одоогийн бэлэн байдал нь альфа (Кубернетесийн дараагийн хувилбарт бета хувилбар руу шилжихээр төлөвлөж байна).
Альфа хувилбарт ашиглах боломжтой OpenAPI v3 схемийг ашиглан CustomResources-д зориулсан OpenAPI баримт бичгийг үүсгэх, нийтлэх (CR) нь (сервер талын) K8-ийн хэрэглэгчийн тодорхойлсон нөөцийг баталгаажуулахад ашиглагддаг (CustomResourceDefinition, CRD). CRD-д зориулсан OpenAPI-г нийтлэх нь үйлчлүүлэгчдэд (жишээ нь: kubectl) баталгаажуулалтыг өөрийн талд (дотор kubectl create и kubectl apply) ба схемийн дагуу баримт бичгийг гаргах (kubectl explain). Дэлгэрэнгүй - дотор .
Өмнө нь байгаа бүртгэлүүд тугтай O_APPEND (гэхдээ үгүй O_TRUNC) зарим тохиолдолд логоо алдахаас сэргийлж, эргэлтэнд зориулсан гадаад хэрэгслүүдээр логуудыг тайрахад хялбар болгох.
Мөн Kubernetes API-ийн хүрээнд үүнийг тэмдэглэж болно PodSandbox и PodSandboxStatus талбар runtime_handler тухай мэдээллийг бүртгэх RuntimeClass хонхорцог (энэ тухай текстээс дэлгэрэнгүй уншина уу , энэ анги альфа хувилбар хэлбэрээр гарч ирсэн) болон Элсэлтийн Вэб дэгээ дээр ямар хувилбаруудыг тодорхойлох чадвар AdmissionReview тэд дэмждэг. Эцэст нь, Элсэлтийн Webhooks дүрэм одоо байна нэрийн орон зай болон кластерын хүрээгээр тэдгээрийн ашиглалтын цар хүрээ.
Хадгалах
, гарснаас хойш бета статустай байсан , тогтвортой (GA): энэ функцийн хаалгыг цаашид идэвхгүй болгохоо больсон бөгөөд Kubernetes 1.17 дээр устгах болно.
гэж нэрлэгддэг орчны хувьсагчдыг ашиглан (жишээ нь, pod нэр) гэж холбогдсон сангуудын нэр , боловсруулсан - шинэ талбар хэлбэрээр subPathExpr, энэ нь одоо хүссэн лавлах нэрийг тодорхойлоход хэрэглэгддэг. Энэ функц нь анх Kubernetes 1.11-д гарч ирсэн боловч 1.14-т альфа хувилбарын төлөвт байсан.
Kubernetes-ийн өмнөх хувилбарын нэгэн адил идэвхтэй хөгжиж буй CSI (Container Storage Interface)-д олон чухал өөрчлөлтүүдийг оруулсан болно:
CSI
Боломжтой болсон (альфа хувилбарын нэг хэсэг болгон) CSI ботьуудын хэмжээг өөрчлөх. Үүнийг ашиглахын тулд та дуудагдсан функцийн хаалгыг идэвхжүүлэх хэрэгтэй ExpandCSIVolumes, түүнчлэн тодорхой CSI драйвер дээр энэ үйлдлийг дэмжих дэмжлэг байгаа эсэх.
Альфа хувилбар дахь CSI-ийн өөр нэг онцлог - pod техникийн үзүүлэлт доторх CSI эзлэхүүнийг шууд (жишээ нь PV/PVC ашиглахгүйгээр) лавлана уу. Энэ CSI-г зөвхөн зайнаас мэдээлэл хадгалах хэрэгсэл болгон ашиглах хязгаарлалтыг арилгана, тэдэнд дэлхийн хаалгыг нээж байна . Хэрэглэхийн тулд () идэвхжүүлсэн байх ёстой CSIInlineVolume онцлог хаалга.
CSI-тай холбоотой Kubernetes-ийн "дотоод" хэсэгт мөн ахиц дэвшил гарсан бөгөөд энэ нь эцсийн хэрэглэгчдэд (системийн администраторуудад) тийм ч харагдахгүй байна ... Одоогоор хөгжүүлэгчид хадгалах залгаас бүрийн хоёр хувилбарыг дэмжихээс өөр аргагүйд хүрч байна: нэг - "д хуучин арга", K8s кодын дотор (мод дотор), хоёр дахь нь - шинэ CSI-ийн нэг хэсэг болгон. (жишээлбэл, энэ талаар дэлгэрэнгүй уншина уу ). Энэ нь CSI өөрөө тогтворжиж байгаа тул шийдвэрлэх шаардлагатай ойлгомжтой хүндрэлүүдийг үүсгэдэг. Үүний улмаас дотоод (мод доторх) залгаасуудын API-г зүгээр л цуцалж болохгүй .
Энэ бүхэн альфа хувилбарт хүрэхэд хүргэсэн дотоод залгаасын код, CSI залгаасуудад мод доторх хэлбэрээр хэрэгжсэн бөгөөд үүний ачаар хөгжүүлэгчдийн санаа зоволт нь тэдний залгаасуудын нэг хувилбарыг дэмжихээс багасч, хуучин API-уудтай нийцтэй байдал хэвээр үлдэх бөгөөд тэдгээрийг ердийн хувилбарт хуучирсан гэж зарлах боломжтой. Kubernetes-ийн дараагийн хувилбар (1.15) гэхэд үүлэн үйлчилгээ үзүүлэгчийн бүх залгаасуудыг шилжүүлж, хэрэгжилт нь бета статусыг хүлээн авч, K8s суулгацуудад анхдагчаар идэвхжих болно. Дэлгэрэнгүйг үзнэ үү . Энэ нүүдэл бас үр дүнд хүрсэн тодорхой үүл үйлчилгээ үзүүлэгчдийн (AWS, Azure, GCE, Cinder) тодорхойлсон эзлэхүүний хязгаараас.
Нэмж дурдахад CSI бүхий блок төхөөрөмжүүдийн дэмжлэг (CSIBlockVolume) бета хувилбар руу.
Зангилаа/Кубелет
Альфа хувилбарыг танилцууллаа зориулагдсан Kubelet-д гол нөөцийн хэмжүүрүүдийг буцаана. Ерөнхийдөө Кубелет өмнө нь cAdvisor-аас контейнер ашиглалтын статистик мэдээллийг хүлээн авч байсан бол одоо энэ өгөгдөл нь CRI (Container Runtime Interface)-ээр дамжуулан контейнерийн ажиллах орчны орчноос ирдэг боловч Docker-ын хуучин хувилбаруудтай ажиллахад нийцтэй байдал мөн хадгалагдсаар байна. Өмнө нь Kubelet-д цуглуулсан статистик мэдээллийг REST API-ээр илгээдэг байсан бол одоо төгсгөлийн цэг нь /metrics/resource/v1alpha1. Хөгжүүлэгчдийн урт хугацааны стратеги Kubelet-ийн өгсөн хэмжүүрүүдийн багцыг багасгах явдал юм. Дашрамд хэлэхэд эдгээр хэмжүүрүүд өөрсдөө "үндсэн хэмжигдэхүүн" биш, харин "нөөцийн хэмжигдэхүүн" бөгөөд "Cpu, санах ой зэрэг нэгдүгээр зэрэглэлийн нөөц" гэж тодорхойлсон.
Маш сонирхолтой нюанс: Prometheus форматыг ашиглах янз бүрийн тохиолдлуудтай харьцуулахад gRPC төгсгөлийн цэгийн гүйцэтгэлийн тодорхой давуу талыг үл харгалзан (доорх жишиг үзүүлэлтүүдийн аль нэгний үр дүнг харна уу), Зохиогчид энэхүү хяналтын системийг нийгэмд тодорхой удирдаж байсан тул Prometheus-ийн текстийн форматыг илүүд үздэг.
“gRPC нь гол хяналтын шугам хоолойтой нийцэхгүй байна. Төгсгөлийн цэг нь зөвхөн хэмжигдэхүүнийг Metrics Server-д хүргэх эсвэл түүнтэй шууд нэгдсэн хяналтын бүрэлдэхүүн хэсгүүдэд хэрэгтэй болно. Metrics Server дээр кэш ашиглах үед Prometheus текст форматын гүйцэтгэл хангалттай сайн нийгэмд Prometheus-ийг өргөнөөр үрчилж авснаар бид Prometheus-ийг gRPC-ээс илүүд үзэх хэрэгтэй. OpenMetrics формат илүү тогтвортой болмогц бид proto-д суурилсан форматаар gRPC гүйцэтгэлд хандах боломжтой болно."
Хэмжилтийн шинэ Kubelet төгсгөлийн цэгт gRPC болон Prometheus форматыг ашиглах гүйцэтгэлийн харьцуулсан тестүүдийн нэг. График болон бусад дэлгэрэнгүй мэдээллийг эндээс авах боломжтой .
Бусад өөрчлөлтүүдийн дунд:
- Кубелет одоо (нэг удаа) дахин эхлүүлэх болон устгах үйлдлүүдийн өмнө үл мэдэгдэх төлөвт байгаа контейнер.
- Хэрэглэхдээ одоо init сав руу энгийн савтай ижил мэдээлэл.
- Кубелет
usageNanoCoresCRI статистикийн үйлчилгээ үзүүлэгчээс болон Windows дээрх зангилаа болон контейнерийн хувьд сүлжээний статистик. - Үйлдлийн систем болон архитектурын мэдээллийг шошгон дээр тэмдэглэсэн
kubernetes.io/osиkubernetes.io/archЗангилааны объектууд (бета хувилбараас GA руу шилжүүлсэн). - Под дахь контейнеруудад зориулсан системийн хэрэглэгчийн тодорхой бүлгийг тодорхойлох чадвар (
RunAsGroup, онд гарч ирэв ) бета хувилбараас өмнө (өгөгдмөлөөр идэвхжсэн). - du болон cAdvisor-д ашигласан олох, on Go хэрэгжилт.
CLI
Cli-runtime болон kubectl-д -k-тэй нэгтгэх туг (Дашрамд хэлэхэд, түүний хөгжлийг одоо тусдаа репозиторт хийж байна), i.e. тусгай kustomization сангаас нэмэлт YAML файлуудыг боловсруулах (тэдгээрийг ашиглах талаар дэлгэрэнгүйг үзнэ үү ):
Энгийн файлын хэрэглээний жишээ (kustomize-ийн илүү төвөгтэй хэрэглээг дотор нь хийх боломжтой )
Үүнээс гадна:
- шинэ баг
kubectl create cronjob, нэр нь өөрөө ярьдаг. - В
kubectl logsодоо та чадна тугнууд-f(--followурсгалын лог) болон-l(--selectorшошгоны асуулгын хувьд). - кубектл зэрлэг картаар сонгосон файлуудыг хуулах.
- Багийнханд
kubectl waitтуг--allзаасан нөөцийн төрлийн нэрийн талбар дахь бүх нөөцийг сонгох.
Бусад
Дараах чадварууд тогтвортой (GA) статусыг авсан:
- , хонгилын бэлэн байдалд харгалзан үзсэн нэмэлт нөхцөлийг тодорхойлохын тулд pod-ийн тодорхойлолтод ашигласан;
- Том хуудасны дэмжлэг (онцлогын хаалга гэж нэрлэдэг );
- ;
- PriorityClass API .
Kubernetes 1.14-д оруулсан бусад өөрчлөлтүүд:
- Өгөгдмөл RBAC бодлого нь API хандалтыг зөвшөөрөхгүй
discoveryиaccess-reviewбаталгаажуулалтгүй хэрэглэгчид (баталгаагүй). - Албан ёсны CoreDNS дэмжлэг Зөвхөн Линукс, тиймээс үүнийг (CoreDNS) кластерт байрлуулахдаа kubeadm ашиглах үед зангилаанууд зөвхөн Линукс дээр ажиллах ёстой (энэ хязгаарлалтад nodeSelectors ашигладаг).
- Өгөгдмөл CoreDNS тохиргоо одоо байна проксины оронд. Мөн CoreDNS дээр ReadinessProbe нь тохирох (үйлчилгээнд бэлэн биш) pods дээр ачааллыг тэнцвэржүүлэхээс сэргийлдэг.
- kubeadm-д, үе шатууд дээр
initбуюуupload-certs, Шинэ удирдлагын онгоцыг kubeadm-certs нууцтай холбоход шаардагдах гэрчилгээг ачаална уу (туг ашиглана уу.--experimental-upload-certs). - Windows суулгацын альфа хувилбар гарч ирэв gMSA (Group Managed Service Account) - Active Directory дахь тусгай дансуудыг контейнерт ашиглах боломжтой.
- G.C.E-ийн хувьд etcd болон kube-apiserver хооронд mTLS шифрлэлт.
- Ашигласан/хамааралтай програм хангамжийн шинэчлэлтүүд: Go 1.12.1, CSI 1.1, CoreDNS 1.3.1, kubeadm дахь Docker 18.09 дэмжлэгтэй, хамгийн бага дэмжигдсэн Docker API хувилбар нь одоо 1.26 байна.
PS
Мөн манай блог дээрээс уншина уу:
- «";
- «";
- «";
- «".
Эх сурвалж: www.habr.com