Ano ang ? Ito ang tinatawag na Service mesh, isang teknolohiya na nagdaragdag ng layer ng abstraction sa network. Hinaharang namin ang lahat o bahagi ng trapiko sa cluster at nagsasagawa kami ng isang tiyak na hanay ng mga operasyon kasama nito. Alin? Halimbawa, gumagawa kami ng matalinong pagruruta, o ipinatupad namin ang diskarte sa circuit breaker, maaari naming ayusin ang "canary deployment", bahagyang inililipat ang trapiko sa isang bagong bersyon ng serbisyo, o maaari naming limitahan ang mga panlabas na pakikipag-ugnayan at kontrolin ang lahat ng mga biyahe mula sa cluster patungo sa panlabas na network. Posibleng magtakda ng mga patakaran ng patakaran para makontrol ang mga biyahe sa pagitan ng iba't ibang microservice. Sa wakas, makukuha natin ang buong mapa ng pakikipag-ugnayan sa network at gawing ganap na transparent sa mga application ang pinag-isang koleksyon ng mga sukatan.
Maaari mong basahin ang tungkol sa mekanismo ng trabaho sa . Ang Istio ay isang napakalakas na tool na nagbibigay-daan sa iyong lutasin ang maraming gawain at problema. Sa artikulong ito, nais kong sagutin ang mga pangunahing tanong na karaniwang lumalabas kapag nagsimula sa Istio. Makakatulong ito sa iyo na harapin ito nang mas mabilis.
Prinsipyo ng operasyon
Ang Istio ay binubuo ng dalawang pangunahing lugar - ang control plane at ang data plane. Ang control plane ay naglalaman ng mga pangunahing bahagi na tinitiyak ang tamang operasyon ng iba. Sa kasalukuyang bersyon (1.0) ang control plane ay may tatlong pangunahing bahagi: Pilot, Mixer, Citadel. Hindi namin isasaalang-alang ang Citadel, ito ay kinakailangan upang makabuo ng mga sertipiko upang matiyak ang mutual TLS sa pagitan ng mga serbisyo. Tingnan natin ang device at layunin ng Pilot at Mixer.
Ang piloto ay ang pangunahing bahagi ng kontrol na namamahagi ng lahat ng impormasyon tungkol sa kung ano ang mayroon tayo sa cluster - mga serbisyo, ang kanilang mga endpoint at mga panuntunan sa pagruruta (halimbawa, mga panuntunan para sa pag-deploy ng Canary o mga panuntunan sa circuit breaker).
Ang Mixer ay isang opsyonal na bahagi ng control plane na nagbibigay ng kakayahang mangolekta ng mga sukatan, log, at anumang impormasyon tungkol sa pakikipag-ugnayan sa network. Sinusubaybayan din niya ang pagsunod sa mga patakaran ng Patakaran at pagsunod sa mga limitasyon sa rate.
Ipinapatupad ang data plane gamit ang mga sidecar proxy container. Ang makapangyarihan ay ginagamit bilang default. . Maaari itong mapalitan ng isa pang pagpapatupad, tulad ng nginx (nginmesh).
Upang ang Istio ay gumana nang ganap na transparent sa mga aplikasyon, mayroong isang awtomatikong sistema ng pag-iniksyon. Ang pinakabagong pagpapatupad ay angkop para sa mga bersyon ng Kubernetes 1.9+ (mutational admission webhook). Para sa Kubernetes na bersyon 1.7, 1.8 posibleng gamitin ang Initializer.
Ang mga sidecar container ay konektado sa Pilot gamit ang GRPC protocol, na nagbibigay-daan sa iyong i-optimize ang push model para sa mga pagbabagong nagaganap sa cluster. Ang GRPC ay ginamit sa Envoy mula noong bersyon 1.6, sa Istio ito ay ginamit mula noong bersyon 0.8 at ito ay isang pilot-agent - isang golang wrapper sa ibabaw ng envoy na nagko-configure ng mga opsyon sa paglulunsad.
Ang Pilot at Mixer ay ganap na walang estado na mga bahagi, lahat ng estado ay pinananatili sa memorya. Ang configuration para sa kanila ay nakatakda sa anyo ng Kubernetes Custom Resources, na naka-imbak sa etcd.
Nakukuha ng Istio-agent ang address ng Pilot at nagbukas ng stream ng GRPC dito.
Gaya ng sinabi ko, ipinapatupad ng Istio ang lahat ng functionality na ganap na transparent sa mga application. Tingnan natin kung paano. Ang algorithm ay ito:
- Pag-deploy ng bagong bersyon ng serbisyo.
- Depende sa sidecar container injecting approach, ang istio-init container at ang istio-agent container (envoy) ay idinaragdag sa yugto ng paglalapat ng configuration, o maaari na silang manu-manong ipasok sa paglalarawan ng Kubernetes Pod entity.
- Ang istio-init container ay isang script na naglalapat ng mga panuntunan sa iptables sa pod. Mayroong dalawang opsyon para sa pag-configure ng trapiko na ibalot sa isang istio-agent na lalagyan: gumamit ng mga panuntunan sa pag-redirect ng iptables, o . Sa oras ng pagsulat, ang default na diskarte ay may mga panuntunan sa pag-redirect. Sa istio-init, posibleng i-configure kung aling trapiko ang dapat ma-intercept at ipadala sa istio-agent. Halimbawa, upang ma-intercept ang lahat ng papasok at lahat ng papalabas na trapiko, kailangan mong itakda ang mga parameter
-iи-bsa kahulugan*. Maaari mong tukuyin ang mga partikular na port na haharangin. Upang hindi ma-intercept ang isang partikular na subnet, maaari mo itong tukuyin gamit ang bandila-x. - Matapos maisakatuparan ang mga lalagyan ng init, ilulunsad ang mga pangunahing lalagyan, kasama ang pilot-agent (envoy). Kumokonekta ito sa naka-deploy na Pilot sa pamamagitan ng GRPC at tumatanggap ng impormasyon tungkol sa lahat ng umiiral na serbisyo at mga patakaran sa pagruruta sa cluster. Ayon sa natanggap na data, kino-configure niya ang mga cluster at direktang itinatalaga ang mga ito sa mga endpoint ng aming mga application sa cluster ng Kubernetes. Kinakailangan din na tandaan ang isang mahalagang punto: dynamic na kino-configure ng envoy ang mga tagapakinig (IP, mga pares ng port) na sinisimulan nitong pakinggan. Samakatuwid, kapag ang mga kahilingan ay pumasok sa pod, ay na-redirect gamit ang mga panuntunan sa pag-redirect ng iptables sa sidecar, matagumpay na maproseso ng envoy ang mga koneksyong ito at maunawaan kung saan i-proxy pa ang trapiko. Gayundin sa yugtong ito, ipinapadala ang impormasyon sa Mixer, na titingnan natin sa ibang pagkakataon, at ipinapadala ang mga tracing span.
Bilang resulta, nakakakuha kami ng isang buong network ng mga envoy proxy server na maaari naming i-configure mula sa isang punto (Pilot). Ang lahat ng papasok at papalabas na kahilingan ay dumaan sa sugo. Bukod dito, ang trapiko ng TCP lamang ang naharang. Nangangahulugan ito na nalutas ang IP ng serbisyo ng Kubernetes gamit ang kube-dns sa UDP nang hindi nagbabago. Pagkatapos, pagkatapos ng pagresolba, ang papalabas na kahilingan ay naharang at pinoproseso ng envoy, na nagpapasya na kung aling endpoint ang kahilingan ay dapat ipadala (o hindi ipadala, sa kaso ng mga patakaran sa pag-access o ang circuit breaker ng algorithm).
Nalaman namin ang Pilot, ngayon kailangan naming maunawaan kung paano gumagana ang Mixer at kung bakit ito kinakailangan. Maaari mong basahin ang opisyal na dokumentasyon para dito .
Ang mixer sa kasalukuyan nitong anyo ay binubuo ng dalawang bahagi: istio-telemetry, istio-patakaran (bago ang bersyon 0.8 ito ay isang bahagi ng istio-mixer). Pareho silang mga mixer, ang bawat isa ay may pananagutan para sa sarili nitong gawain. Ang Istio telemetry ay tumatanggap ng impormasyon tungkol sa kung sino ang pupunta kung saan at kung anong mga parameter mula sa sidecar Report container sa pamamagitan ng GRPC. Tumatanggap ang Istio-policy ng mga kahilingan sa Check para i-verify na nasiyahan ang mga patakaran sa Patakaran. Ang mga pagsusuri sa patakaran ay, siyempre, hindi isinasagawa para sa bawat kahilingan, ngunit naka-cache sa kliyente (sa sidecar) sa isang tiyak na oras. Ang mga pagsusuri sa ulat ay ipinapadala bilang mga batch na kahilingan. Tingnan natin kung paano i-configure at kung anong mga parameter ang dapat ipadala sa ibang pagkakataon.
Ang Mixer ay dapat na isang lubos na magagamit na bahagi na nagsisiguro ng walang patid na trabaho sa pagpupulong at pagproseso ng data ng telemetry. Ang sistema ay nakuha bilang isang resulta bilang isang multi-level buffer. Sa una, ang data ay buffer sa sidecar side ng mga container, pagkatapos ay sa mixer side, at pagkatapos ay ipinadala sa tinatawag na mixer backend. Bilang resulta, kung ang alinman sa mga bahagi ng system ay nabigo, ang buffer ay lumalaki at namumula pagkatapos na maibalik ang system. Ang mga mixer backend ay mga endpoint para sa pagpapadala ng data ng telemetry: statsd, newrelic, atbp. Maaari kang magsulat ng iyong sariling backend, ito ay medyo simple, at makikita natin kung paano ito gagawin.
Upang ibuod, ang pamamaraan para sa pagtatrabaho sa istio-telemetry ay ang mga sumusunod.
- Nagpapadala ang Serbisyo 1 ng kahilingan sa serbisyo 2.
- Kapag umalis sa serbisyo 1, ang kahilingan ay nakabalot sa sarili nitong sidecar.
- Sinusubaybayan ng envoy ng Sidecar kung paano napupunta ang kahilingan sa serbisyo 2 at inihahanda ang kinakailangang impormasyon.
- Pagkatapos ay ipapadala ito sa istio-telemetry gamit ang isang kahilingan sa Ulat.
- Tinutukoy ng Istio-telemetry kung ang Ulat na ito ay dapat ipadala sa mga backend, kung saan at kung anong data ang dapat ipadala.
- Ang Istio-telemetry ay nagpapadala ng data ng Ulat sa backend kung kinakailangan.
Ngayon tingnan natin kung paano i-deploy ang Istio sa system, na binubuo lamang ng mga pangunahing bahagi (Pilot at sidecar envoy).
Una, tingnan natin ang pangunahing configuration (mesh) na binasa ng Pilot:
apiVersion: v1
kind: ConfigMap
metadata:
name: istio
namespace: istio-system
labels:
app: istio
service: istio
data:
mesh: |-
# пока что не включаем отправку tracing информации (pilot настроит envoy’и таким образом, что отправка не будет происходить)
enableTracing: false
# пока что не указываем mixer endpoint’ы, чтобы sidecar контейнеры не отправляли информацию туда
#mixerCheckServer: istio-policy.istio-system:15004
#mixerReportServer: istio-telemetry.istio-system:15004
# ставим временной промежуток, с которым будет envoy переспрашивать Pilot (это для старой версии envoy proxy)
rdsRefreshDelay: 5s
# default конфигурация для envoy sidecar
defaultConfig:
# аналогично как rdsRefreshDelay
discoveryRefreshDelay: 5s
# оставляем по умолчанию (путь к конфигурации и бинарю envoy)
configPath: "/etc/istio/proxy"
binaryPath: "/usr/local/bin/envoy"
# дефолтное имя запущенного sidecar контейнера (используется, например, в именах сервиса при отправке tracing span’ов)
serviceCluster: istio-proxy
# время, которое будет ждать envoy до того, как он принудительно завершит все установленные соединения
drainDuration: 45s
parentShutdownDuration: 1m0s
# по умолчанию используются REDIRECT правила iptables. Можно изменить на TPROXY.
#interceptionMode: REDIRECT
# Порт, на котором будет запущена admin панель каждого sidecar контейнера (envoy)
proxyAdminPort: 15000
# адрес, по которому будут отправляться trace’ы по zipkin протоколу (в начале мы отключили саму отправку, поэтому это поле сейчас не будет использоваться)
zipkinAddress: tracing-collector.tracing:9411
# statsd адрес для отправки метрик envoy контейнеров (отключаем)
# statsdUdpAddress: aggregator:8126
# выключаем поддержку опции Mutual TLS
controlPlaneAuthPolicy: NONE
# адрес, на котором будет слушать istio-pilot для того, чтобы сообщать информацию о service discovery всем sidecar контейнерам
discoveryAddress: istio-pilot.istio-system:15007
Ang lahat ng pangunahing bahagi ng kontrol (control plane) ay matatagpuan sa namespace istio-system sa Kubernetes.
Sa pinakamababa, kailangan lang nating mag-deploy ng Pilot. Para dito gagamitin namin
At manu-mano naming i-configure ang injecting sidecar ng container.
Init container:
initContainers:
- name: istio-init
args:
- -p
- "15001"
- -u
- "1337"
- -m
- REDIRECT
- -i
- '*'
- -b
- '*'
- -d
- ""
image: istio/proxy_init:1.0.0
imagePullPolicy: IfNotPresent
resources:
limits:
memory: 128Mi
securityContext:
capabilities:
add:
- NET_ADMIN
At sidecar:
name: istio-proxy
args:
- "bash"
- "-c"
- |
exec /usr/local/bin/pilot-agent proxy sidecar
--configPath
/etc/istio/proxy
--binaryPath
/usr/local/bin/envoy
--serviceCluster
service-name
--drainDuration
45s
--parentShutdownDuration
1m0s
--discoveryAddress
istio-pilot.istio-system:15007
--discoveryRefreshDelay
1s
--connectTimeout
10s
--proxyAdminPort
"15000"
--controlPlaneAuthPolicy
NONE
env:
- name: POD_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: POD_NAMESPACE
valueFrom:
fieldRef:
fieldPath: metadata.namespace
- name: INSTANCE_IP
valueFrom:
fieldRef:
fieldPath: status.podIP
- name: ISTIO_META_POD_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: ISTIO_META_INTERCEPTION_MODE
value: REDIRECT
image: istio/proxyv2:1.0.0
imagePullPolicy: IfNotPresent
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
memory: 2048Mi
securityContext:
privileged: false
readOnlyRootFilesystem: true
runAsUser: 1337
volumeMounts:
- mountPath: /etc/istio/proxy
name: istio-envoy
Upang matagumpay na magsimula ang lahat, kailangan mong lumikha ng ServiceAccount, ClusterRole, ClusterRoleBinding, CRD para sa Pilot, ang mga paglalarawan kung saan makikita .
Bilang resulta, ang serbisyo kung saan kami nag-inject ng sidecar na may envoy ay dapat na matagumpay na magsimula, matanggap ang lahat ng pagtuklas mula sa pilot at proseso ng mga kahilingan.
Mahalagang maunawaan na ang lahat ng bahagi ng control plane ay mga stateless na application at maaaring pahalang na sukatin nang walang mga problema. Ang lahat ng data ay nakaimbak sa etcd sa anyo ng mga custom na paglalarawan ng mga mapagkukunan ng Kubernetes.
Gayundin, ang Istio (pang-eksperimento pa rin) ay may kakayahang tumakbo sa labas ng cluster at ang kakayahang manood at mag-fumble ng pagtuklas ng serbisyo sa pagitan ng ilang mga cluster ng Kubernetes. Maaari mong basahin ang higit pa tungkol dito .
Para sa multi-cluster installation, magkaroon ng kamalayan sa mga sumusunod na limitasyon:
- Ang Pod CIDR at Service CIDR ay dapat na natatangi sa lahat ng cluster at hindi dapat mag-overlap.
- Ang lahat ng CIDR Pod ay dapat ma-access mula sa anumang CIDR Pod sa pagitan ng mga cluster.
- Ang lahat ng mga server ng Kubernetes API ay dapat na ma-access sa isa't isa.
Ito ang paunang impormasyon upang matulungan kang makapagsimula sa Istio. Gayunpaman, mayroon pa ring maraming mga pitfalls. Halimbawa, ang mga feature ng pagruruta sa panlabas na trapiko (sa labas ng cluster), ay lumalapit sa pag-debug ng mga sidecar, pag-profile, pag-set up ng mixer at pagsusulat ng custom na mixer backend, pag-set up ng mekanismo ng pagsubaybay at pagpapatakbo nito gamit ang envoy.
Ang lahat ng ito ay tatalakayin natin sa mga sumusunod na publikasyon. Tanungin ang iyong mga katanungan, susubukan kong takpan ang mga ito.
Pinagmulan: www.habr.com