Гэтай ноччу чарговы рэліз Kubernetes - . Па якая склалася для нашага блога традыцыі, распавядаем аб ключавых зменах у новай версіі гэтага выдатнага Open Source-прадукта.
Інфармацыя, выкарыстаная для падрыхтоўкі гэтага матэрыялу, узята з , і суадносных issues, pull requests, Kubernetes Enhancement Proposals (KEP).
Пачнём з важнага ўвядзення ад SIG cluster-lifecycle: дынамічныя адмоваўстойлівыя кластары Kubernetes (а калі выяўляцца больш дакладна, то self-hosted HA deployments) зараз з дапамогай звыклых (у кантэксце кластараў з адным вузлом) каманд kubeadm (init и join). Калі сцісла, то для гэтага:
- выкарыстоўваныя кластарам сертыфікаты пераносяцца ў сакрэты;
- для магчымасці выкарыстання кластара etcd ўнутры K8s-кластара (г.зн. збавення ад існавалай да гэтага часу знешняй залежнасці) задзейнічаны ;
- дакументуюцца рэкамендуемыя настройкі для знешняга балансавальніка нагрузкі, які забяспечвае адмоваўстойлівасць канфігурацыю (у далейшым плануецца магчымасць адмовы і ад гэтай залежнасці, але не на дадзеным этапе).
Архітэктура HA-кластара Kubernetes, створанага з kubeadm
З падрабязнасцямі аб рэалізацыі можна азнаёміцца ў . Гэтая фіча была па-сапраўднаму доўгачаканай: альфа-версія чакалася яшчэ ў K8s 1.9, але з'явілася толькі зараз.
API
Каманда apply ды ўвогуле дэкларатыўнае кіраванне аб'ектамі з kubectl у apiserver. Самі распрацоўшчыкі коратка тлумачаць сваё рашэнне тым, што kubectl apply - фундаментальная частка працы з канфігурацыямі ў Kubernetes, аднак «поўная багаў і складана паддаецца выпраўленням», у сувязі з чым гэтую функцыянальнасць неабходна прывесці да нармальнага ўвазе і перанесці ў control plane. Простыя і наглядныя прыклады існуючых сёння праблем:
Падрабязнасці аб рэалізацыі - у . Бягучая гатоўнасць - альфа-версія (прасоўванне да бэты запланавана на наступны рэліз Kubernetes).
У альфа-версіі стала даступнай выкарыстання схемы OpenAPI v3 для стварэння і публікацыі OpenAPI-дакументацыі па CustomResources (CR), выкарыстоўваным для валідацыі (на боку сервера) рэсурсаў K8s, вызначаных карыстачом (CustomResourceDefinition, CRD). Публікацыя OpenAPI для CRD дазваляе кліентам (напрыклад, kubectl) выконваць валідацыю на сваім баку (у рамках kubectl create и kubectl apply) і выдаваць дакументацыю па схеме (kubectl explain). Падрабязнасці - у .
Існавалі раней логі са сцягам O_APPEND (а не O_TRUNC) у пазбяганне страты логаў у некаторых сітуацыях і для выгоды truncate'а логаў вонкавымі ўтылітамі для ратацыі.
Таксама ў кантэксце Kubernetes API можна адзначыць, што ў PodSandbox и PodSandboxStatus поле runtime_handler для ўліку інфармацыі пра RuntimeClass у pod'е (падрабязней пра яго чытайце ў тэксце пра , дзе гэты клас і з'явіўся як альфа-версія), а ў Admission Webhooks магчымасць вызначаць, якія версіі AdmissionReview яны падтрымліваюць. Нарэшце, у правілах Admission Webhooks зараз маштабы іх ужывання namespace'амі і рамкамі кластара.
Сховішчы
, якія мелі статус бэта-версіі з рэлізу , стабільнымі (GA): гэты feature gate больш не адключаецца і будзе выдалены ў Kubernetes 1.17.
выкарыстання зменных асяроддзі так званага (напрыклад, імя pod'а) для назваў дырэкторый, якія мантуюцца як , атрымала развіццё - у выглядзе новага поля subPathExpr, з дапамогай якога зараз і вызначаецца патрэбнае імя дырэкторыі. Першапачаткова фіча з'явілася ў Kubernetes 1.11, але і для 1.14 засталася ў статуце альфа-версіі.
Як і ў мінулы рэліз Kubernetes, шмат значных змен прадстаўлена для актыўна які развіваецца CSI (Container Storage Interface):
CSI
Стала даступнай (у рамках альфа-версіі) змены памеру для CSI-томаў. Для яе выкарыстання спатрэбіцца ўключыць feature gate пад назвай ExpandCSIVolumes, а таксама наяўнасць падтрымкі гэтай аперацыі ў канкрэтным CSI-драйверы.
Яшчэ адна фіча для CSI у альфа-версіі спасылацца напрамую (г.зн. без выкарыстання PV/PVC) на CSI-томы ў рамках спецыфікацыі pod'ов. Гэта здымае абмежаванне на выкарыстанне CSI як выключна выдаленых сховішчаў даных, адчыняючы для іх дзверы ў свет . Для выкарыстання () неабходна ўключыць CSIInlineVolume feature gate.
Вызначыўся прагрэс і ва «ўнутранасцях» Kubernetes, злучаных з CSI, якія не так прыкметныя канчатковым карыстачам (сістэмным адміністратарам)… У сапраўдны момант распрацоўнікі змушаныя падтрымліваць дзве версіі кожнага плагіна сховішчы: адзін — «на стары лад», усярэдзіне кодавай базы K8s (in -tree), а другі - у рамках новага CSI (падрабязней пра яго чытайце, напрыклад, у ). Гэта выклікае зразумелыя нязручнасці, якія неабходна ўхіліць па меры стабілізацыі CSI як такога. Проста ўзяць і абвясціць састарэлымі (deprecated) API унутраных (in-tree) убудоў не ўяўляецца магчымым з-за .
Усё гэта прывяло да таго, што альфа-версіі дасягнуў ўнутранага кода плагінаў, Якія рэалізуюцца як in-tree, у CSI plugins, дзякуючы чаму клопаты распрацоўнікаў будуць зведзены да падтрымкі адной версіі іх убудоў, а сумяшчальнасць са старымі API захаваецца і іх можна будзе абвясціць састарэлымі па звычайным сцэнары. Чакаецца, што да наступнага рэлізу Kubernetes (1.15) будзе праведзена міграцыя ўсіх убудоў хмарных правайдэраў, рэалізацыя атрымае статут бэта-версіі і будзе актываваная ва ўсталёўках K8s па змаўчанні. Падрабязнасці гл. у . Следствам гэтай міграцыі таксама стаў ад абмежаванняў для тамоў, вызначаных пэўнымі хмарнымі правайдэрамі (AWS, Azure, GCE, Cinder).
Акрамя таго, падтрымка блокавых прылад з CSI (CSIBlockVolume) у бэта-версію.
Вузлы / Kubelet
Прадстаўлена альфа-версія у Kubelet, прызначанага для аддачы метрык па асноўных рэсурсах. Наогул кажучы, калі раней Kubelet атрымліваў статыстыку па выкарыстанні кантэйнераў з cAdvisor, то зараз гэтыя дадзеныя паступаюць з выкананага асяроддзя кантэйнера праз CRI (Container Runtime Interface), аднак захавана і сумяшчальнасць для працы са старымі версіямі Docker. Раней сабраная ў Kubelet статыстыка аддавалася праз REST API, а зараз для гэтага выкарыстоўваецца endpoint, размешчаны па адрасе /metrics/resource/v1alpha1. Доўгатэрміновая ж стратэгія распрацоўшчыкаў у тым, каб мінімізаваць набор метрык, якія прадстаўляюцца Kubelet. Дарэчы, самі гэтыя метрыкі не "core metrics", а "resource metrics", і апісваюць як "first-class resources, such as cpu, and memory".
Вельмі забаўны нюанс: нягледзячы на відавочную перавагу ў прадукцыйнасці gRPC endpoint у параўнанні з рознымі выпадкамі выкарыстання фармату Prometheus (вынік аднаго з benchmark'аў гл. ніжэй), аўтары аддалі перавагу тэкставы фармат Prometheus з-за відавочнага лідэрства гэтай сістэмы маніторынгу ў супольнасці.
gRPC не сумяшчальны з асноўнымі пайплайнамі маніторынгу. Endpoint ж будзе карысны толькі для пастаўкі метрык у Metrics Server або кампаненты маніторынгу, якія інтэгруюцца напрамую з ім. Пры выкарыстанні кэшавання ў Metrics Server прадукцыйнасць тэкставага фармату Prometheus дастаткова добрая для нас, каб аддаць перавагу Prometheus, а не gRPC, улічваючы шырокую распаўсюджанасць Prometheus у супольнасці. Калі фармат OpenMetrics стане больш стабільным, мы зможам наблізіцца да папулярнасці gRPC з дапамогай фармату на аснове proto».
Адзін з параўнальных тэстаў прадукцыйнасці выкарыстання фарматаў gRPC і Prometheus у новым endpoint'е Kubelet для метрык. Больш графікаў і іншыя падрабязнасці можна знайсці ў .
Сярод іншых змен:
- Kubelet цяпер (аднойчы) кантэйнеры ў невядомым стане (unknown) перад аперацыямі рэстарту і выдаленні.
- Пры выкарыстанні зараз init-кантэйнеру тая ж інфармацыя, што і звычайнаму кантэйнеру.
- кубелет
usageNanoCoresз правайдэра статыстыкі CRI, а для вузлоў і кантэйнераў у Windows сеткавая статыстыка. - Інфармацыя аб аперацыйнай сістэме і архітэктуры зараз запісваецца ў лэйблы
kubernetes.io/osиkubernetes.io/archаб'ектаў Node (перакладзена з бэты ў GA). - Магчымасць указання канкрэтнай сістэмнай групы карыстальнікаў для кантэйнераў у pod'е (
RunAsGroup, з'явілася ў ) да бэта-версіі (уключана па змаўчанні). - du і find, якія выкарыстоўваюцца ў cAdvisor, на Go-рэалізацыі.
CLI
У cli-runtime і kubectl сцяг -k для інтэграцыі з (дарэчы, яго распрацоўка зараз вядзецца ў асобным рэпазітары), г.зн. для апрацоўкі дадатковых YAML-файлаў з спецыяльных дырэкторый kustomization (падрабязнасці аб іх выкарыстанні гл. ):
Прыклад простага выкарыстання файла (магчыма і больш складанае прымяненне kustomize ў рамках )
Акрамя таго:
- новая каманда
kubectl create cronjob, назва якога гаворыць за сябе. - В
kubectl logsзараз можна сцягі-f(--followдля стрымінгу логаў) і-l(--selectorдля label query). - кубектль капіяваць файлы, якія выбіраюцца з дапамогай wild card.
- У каманду
kubectl waitсцяг--allдля выбару ўсіх рэсурсаў у прасторы імёнаў названага тыпу рэсурсаў.
Іншыя
Стабільны (GA) статус атрымалі наступныя магчымасці:
- , які выкарыстоўваецца ў спецыфікацыі pod'а для вызначэння дадатковых умоў, якія ўлічваюцца ў гатоўнасці pod'а;
- Падтрымка вялікіх старонак (feature gate пад назвай );
- ;
- PriorityClass API, .
Іншыя змены, прадстаўленыя ў Kubernetes 1.14:
- Палітыка RBAC па змаўчанні больш не дае доступу да API
discoveryиaccess-reviewкарыстальнікам без аўтэнтыфікацыі (unauthenticated). - Афіцыйная падтрымка CoreDNS толькі для Linux, таму пры выкарыстанні kubeadm для яго (CoreDNS) разгортванні ў кластары вузлы павінны працаваць толькі ў Linux (для гэтага абмежавання выкарыстоўваюцца nodeSelectors).
- Канфігурацыя CoreDNS па змаўчанні зараз замест проксі. Акрамя таго, у CoreDNS readinessProbe, якая прадухіляе балансаванне нагрузкі на адпаведныя (не гатовыя да абслугоўвання) pod'ы.
- У kubeadm, на фазах
initабоupload-certs, загружаць сертыфікаты, якія патрабуюцца для падлучэння новага control-plane да сакрэту kubeadm-certs (выкарыстоўваецца сцяг--experimental-upload-certs). - Для Windows-інсталяцый з'явілася альфа-версія gMSA (Group Managed Service Account) - спецыяльных уліковых запісаў у Active Directory, якія могуць выкарыстоўвацца і кантэйнерамі.
- Для GCE mTLS-шыфраванне паміж etcd і kube-apiserver.
- Абнаўленні ў выкарыстоўваным/залежным праграмным забеспячэнні: Go 1.12.1, CSI 1.1, CoreDNS 1.3.1, падтрымка Docker 18.09 у kubeadm, а мінімальнай падтрымліваемай версіяй Docker API стала 1.26.
PS
Чытайце таксама ў нашым блогу:
- «»;
- «»;
- «»;
- «.
Крыніца: habr.com