ప్రోహోస్టర్ > బ్లాగ్ > పరిపాలన > ఉత్పత్తిలో కుబెర్నెట్లను ఉపయోగించి ఇస్టియోను ఎలా అమలు చేయాలి. 1 వ భాగము
ఉత్పత్తిలో కుబెర్నెట్లను ఉపయోగించి ఇస్టియోను ఎలా అమలు చేయాలి. 1 వ భాగము
ఏం ఇస్టియో? ఇది సర్వీస్ మెష్ అని పిలవబడేది, ఇది నెట్వర్క్లో సంగ్రహణ పొరను జోడించే సాంకేతికత. మేము క్లస్టర్లోని ట్రాఫిక్ను పూర్తిగా లేదా కొంత భాగాన్ని అడ్డగించి, దానితో నిర్దిష్ట కార్యకలాపాలను నిర్వహిస్తాము. ఏది? ఉదాహరణకు, మేము స్మార్ట్ రూటింగ్ చేస్తాము, లేదా మేము సర్క్యూట్ బ్రేకర్ విధానాన్ని అమలు చేస్తాము, మేము “కానరీ విస్తరణ”ని నిర్వహించవచ్చు, ట్రాఫిక్ను పాక్షికంగా సేవ యొక్క క్రొత్త సంస్కరణకు మార్చవచ్చు లేదా మేము బాహ్య పరస్పర చర్యలను పరిమితం చేయవచ్చు మరియు క్లస్టర్ నుండి అన్ని పర్యటనలను నియంత్రించవచ్చు. బాహ్య నెట్వర్క్. విభిన్న మైక్రోసర్వీస్ల మధ్య ప్రయాణాలను నియంత్రించడానికి విధాన నియమాలను సెట్ చేయడం సాధ్యపడుతుంది. చివరగా, మేము మొత్తం నెట్వర్క్ ఇంటరాక్షన్ మ్యాప్ను పొందవచ్చు మరియు మెట్రిక్ల ఏకీకృత సేకరణను అప్లికేషన్లకు పూర్తిగా పారదర్శకంగా చేయవచ్చు.
మీరు పని యొక్క యంత్రాంగం గురించి చదువుకోవచ్చు అధికారిక డాక్యుమెంటేషన్. Istio అనేది నిజంగా శక్తివంతమైన సాధనం, ఇది అనేక పనులు మరియు సమస్యలను పరిష్కరించడానికి మిమ్మల్ని అనుమతిస్తుంది. ఈ వ్యాసంలో, ఇస్టియోతో ప్రారంభించేటప్పుడు సాధారణంగా తలెత్తే ప్రధాన ప్రశ్నలకు నేను సమాధానం ఇవ్వాలనుకుంటున్నాను. దీన్ని వేగంగా ఎదుర్కోవటానికి ఇది మీకు సహాయం చేస్తుంది.
ఇది ఎలా పనిచేస్తుంది
ఇస్టియో రెండు ప్రధాన ప్రాంతాలను కలిగి ఉంటుంది - కంట్రోల్ ప్లేన్ మరియు డేటా ప్లేన్. నియంత్రణ విమానం మిగిలిన వాటి యొక్క సరైన ఆపరేషన్ను నిర్ధారించే ప్రధాన భాగాలను కలిగి ఉంటుంది. ప్రస్తుత సంస్కరణలో (1.0) నియంత్రణ విమానం మూడు ప్రధాన భాగాలను కలిగి ఉంది: పైలట్, మిక్సర్, సిటాడెల్. మేము సిటాడెల్ను పరిగణించము, సేవల మధ్య పరస్పర TLSని నిర్ధారించడానికి సర్టిఫికేట్లను రూపొందించడం అవసరం. పైలట్ మరియు మిక్సర్ యొక్క పరికరం మరియు ప్రయోజనం గురించి నిశితంగా పరిశీలిద్దాం.
పైలట్ అనేది క్లస్టర్ - సేవలు, వాటి ముగింపు పాయింట్లు మరియు రూటింగ్ నియమాల గురించిన మొత్తం సమాచారాన్ని పంపిణీ చేసే ప్రధాన నియంత్రణ భాగం.
మిక్సర్ అనేది మెట్రిక్లు, లాగ్లు మరియు నెట్వర్క్ ఇంటరాక్షన్ గురించి ఏదైనా సమాచారాన్ని సేకరించే సామర్థ్యాన్ని అందించే ఐచ్ఛిక నియంత్రణ ప్లేన్ భాగం. అతను విధాన నియమాలకు అనుగుణంగా మరియు రేట్ పరిమితులకు అనుగుణంగా ఉండేలా పర్యవేక్షిస్తాడు.
సైడ్కార్ ప్రాక్సీ కంటైనర్లను ఉపయోగించి డేటా ప్లేన్ అమలు చేయబడుతుంది. పవర్ ఫుల్ అనేది డిఫాల్ట్గా ఉపయోగించబడుతుంది. రాయబారి ప్రాక్సీ. ఇది nginx (nginmesh) వంటి మరొక అమలు ద్వారా భర్తీ చేయబడుతుంది.
Istio అప్లికేషన్లకు పూర్తిగా పారదర్శకంగా పని చేయడానికి, ఆటోమేటిక్ ఇంజెక్షన్ సిస్టమ్ ఉంది. తాజా అమలు కుబెర్నెటెస్ 1.9+ వెర్షన్లకు (మ్యుటేషన్ అడ్మిషన్ వెబ్హుక్) అనుకూలంగా ఉంటుంది. Kubernetes సంస్కరణలు 1.7, 1.8 కోసం ఇనిషియలైజర్ని ఉపయోగించడం సాధ్యమవుతుంది.
సైడ్కార్ కంటైనర్లు GRPC ప్రోటోకాల్ను ఉపయోగించి పైలట్కి కనెక్ట్ చేయబడ్డాయి, ఇది క్లస్టర్లో సంభవించే మార్పుల కోసం పుష్ మోడల్ను ఆప్టిమైజ్ చేయడానికి మిమ్మల్ని అనుమతిస్తుంది. GRPC సంస్కరణ 1.6 నుండి ఎన్వోయ్లో ఉపయోగించబడింది, ఇస్టియోలో ఇది వెర్షన్ 0.8 నుండి ఉపయోగించబడింది మరియు ఇది పైలట్-ఏజెంట్ - ప్రయోగ ఎంపికలను కాన్ఫిగర్ చేసే రాయబారిపై గోలాంగ్ రేపర్.
పైలట్ మరియు మిక్సర్ పూర్తిగా స్థితిలేని భాగాలు, మొత్తం స్థితి మెమరీలో ఉంచబడుతుంది. వాటి కోసం కాన్ఫిగరేషన్ కుబెర్నెట్స్ కస్టమ్ రిసోర్సెస్ రూపంలో సెట్ చేయబడింది, ఇవి etcdలో నిల్వ చేయబడతాయి.
ఇస్టియో-ఏజెంట్ పైలట్ చిరునామాను పొందుతుంది మరియు దానికి GRPC స్ట్రీమ్ను తెరుస్తుంది.
నేను చెప్పినట్లుగా, Istio అప్లికేషన్లకు పూర్తిగా పారదర్శకంగా అన్ని కార్యాచరణలను అమలు చేస్తుంది. ఎలాగో చూద్దాం. అల్గోరిథం ఇది:
సేవ యొక్క కొత్త సంస్కరణను అమలు చేస్తోంది.
సైడ్కార్ కంటైనర్ ఇంజెక్షన్ విధానంపై ఆధారపడి, కాన్ఫిగరేషన్ను వర్తింపజేసే దశలో istio-init కంటైనర్ మరియు istio-ఏజెంట్ కంటైనర్ (దూత) జోడించబడతాయి లేదా వాటిని ఇప్పటికే మాన్యువల్గా Kubernetes Pod ఎంటిటీ వివరణలో చేర్చవచ్చు.
istio-init కంటైనర్ అనేది పాడ్కు iptables నియమాలను వర్తింపజేసే స్క్రిప్ట్. istio-agent కంటైనర్లో చుట్టబడిన ట్రాఫిక్ను కాన్ఫిగర్ చేయడానికి రెండు ఎంపికలు ఉన్నాయి: iptables దారిమార్పు నియమాలను ఉపయోగించండి, లేదా TPROXY. వ్రాసే సమయంలో, డిఫాల్ట్ విధానం దారిమార్పు నియమాలతో ఉంటుంది. istio-initలో, ఏ ట్రాఫిక్ను అడ్డగించాలో మరియు istio-agentకు పంపాలో కాన్ఫిగర్ చేయడం సాధ్యపడుతుంది. ఉదాహరణకు, అన్ని ఇన్కమింగ్ మరియు అవుట్గోయింగ్ ట్రాఫిక్ను అడ్డగించడానికి, మీరు పారామితులను సెట్ చేయాలి -i и -b అర్థం లోకి *. మీరు అడ్డగించడానికి నిర్దిష్ట పోర్ట్లను పేర్కొనవచ్చు. నిర్దిష్ట సబ్నెట్ను అడ్డగించకుండా ఉండటానికి, మీరు ఫ్లాగ్ని ఉపయోగించి దాన్ని పేర్కొనవచ్చు -x.
init కంటైనర్లు అమలు చేయబడిన తర్వాత, పైలట్-ఏజెంట్ (దూత)తో సహా ప్రధానమైనవి ప్రారంభించబడతాయి. ఇది ఇప్పటికే అమలులో ఉన్న పైలట్కి GRPC ద్వారా కనెక్ట్ అవుతుంది మరియు క్లస్టర్లో ఇప్పటికే ఉన్న అన్ని సేవలు మరియు రూటింగ్ విధానాల గురించి సమాచారాన్ని అందుకుంటుంది. అందుకున్న డేటా ప్రకారం, అతను క్లస్టర్లను కాన్ఫిగర్ చేస్తాడు మరియు వాటిని నేరుగా కుబెర్నెటెస్ క్లస్టర్లోని మా అప్లికేషన్ల ముగింపు పాయింట్లకు కేటాయిస్తాడు. ఇది ఒక ముఖ్యమైన విషయాన్ని గమనించడం కూడా అవసరం: రాయబారి వినడం ప్రారంభించే శ్రోతలను (IP, పోర్ట్ జతలు) డైనమిక్గా కాన్ఫిగర్ చేస్తుంది. అందువల్ల, అభ్యర్థనలు పాడ్లోకి ప్రవేశించినప్పుడు, సైడ్కార్లోని దారిమార్పు iptables నియమాలను ఉపయోగించి దారి మళ్లించబడినప్పుడు, రాయబారి ఇప్పటికే ఈ కనెక్షన్లను విజయవంతంగా ప్రాసెస్ చేయగలరు మరియు ట్రాఫిక్ను ఎక్కడ ప్రాక్సీ చేయాలో అర్థం చేసుకోవచ్చు. ఈ దశలో కూడా, సమాచారం మిక్సర్కు పంపబడుతుంది, దానిని మేము తరువాత పరిశీలిస్తాము మరియు ట్రేసింగ్ స్పాన్లు పంపబడతాయి.
ఫలితంగా, మేము ఒక పాయింట్ (పైలట్) నుండి కాన్ఫిగర్ చేయగల ఎన్వోయ్ ప్రాక్సీ సర్వర్ల మొత్తం నెట్వర్క్ను పొందుతాము. అన్ని ఇన్బౌండ్ మరియు అవుట్బౌండ్ అభ్యర్థనలు రాయబారి ద్వారా వెళ్తాయి. అంతేకాకుండా, TCP ట్రాఫిక్ మాత్రమే అంతరాయం కలిగిస్తుంది. దీని అర్థం Kubernetes సర్వీస్ IP మారకుండా UDP ద్వారా kube-dnsని ఉపయోగించి పరిష్కరించబడుతుంది. అప్పుడు, పరిష్కారం తర్వాత, అవుట్గోయింగ్ అభ్యర్థనను రాయబారి అడ్డగించి ప్రాసెస్ చేస్తారు, ఇది అభ్యర్థనను ఏ ఎండ్పాయింట్కి పంపాలో (లేదా యాక్సెస్ విధానాలు లేదా అల్గారిథమ్ యొక్క సర్క్యూట్ బ్రేకర్ విషయంలో) పంపబడకూడదని ఇప్పటికే నిర్ణయిస్తుంది.
మేము పైలట్ను కనుగొన్నాము, ఇప్పుడు మిక్సర్ ఎలా పని చేస్తుందో మరియు అది ఎందుకు అవసరమో మనం అర్థం చేసుకోవాలి. మీరు దాని కోసం అధికారిక డాక్యుమెంటేషన్ చదవవచ్చు ఇక్కడ.
మిక్సర్ దాని ప్రస్తుత రూపంలో రెండు భాగాలను కలిగి ఉంటుంది: istio-టెలిమెట్రీ, istio-విధానం (వెర్షన్ 0.8కి ముందు ఇది ఒక istio-మిక్సర్ భాగం). రెండూ మిక్సర్లు, వీటిలో ప్రతి ఒక్కటి దాని స్వంత పనికి బాధ్యత వహిస్తాయి. ఇస్టియో టెలిమెట్రీ GRPC ద్వారా సైడ్కార్ రిపోర్ట్ కంటైనర్ల నుండి ఎవరు ఎక్కడికి మరియు ఏ పారామితులతో వెళతారు అనే సమాచారాన్ని అందుకుంటుంది. విధాన నియమాలు సంతృప్తికరంగా ఉన్నాయని ధృవీకరించడానికి Istio-విధానం తనిఖీ అభ్యర్థనలను అంగీకరిస్తుంది. పాలసీ తనిఖీలు, ప్రతి అభ్యర్థన కోసం నిర్వహించబడవు, కానీ క్లయింట్లో (సైడ్కార్లో) నిర్దిష్ట సమయం వరకు కాష్ చేయబడతాయి. నివేదిక తనిఖీలు బ్యాచ్ అభ్యర్థనలుగా పంపబడతాయి. ఎలా కాన్ఫిగర్ చేయాలో చూద్దాం మరియు ఏ పారామితులను కొంచెం తరువాత పంపాలి.
మిక్సర్ అనేది టెలిమెట్రీ డేటా యొక్క అసెంబ్లింగ్ మరియు ప్రాసెసింగ్పై నిరంతరాయంగా పని చేసేలా అత్యంత అందుబాటులో ఉండే భాగం. సిస్టమ్ బహుళ-స్థాయి బఫర్గా ఫలితంగా పొందబడుతుంది. ప్రారంభంలో, డేటా కంటైనర్ల సైడ్కార్ వైపు, తర్వాత మిక్సర్ వైపు బఫర్ చేయబడుతుంది, ఆపై మిక్సర్ బ్యాకెండ్లు అని పిలవబడే వాటికి పంపబడుతుంది. ఫలితంగా, సిస్టమ్ భాగాలు ఏవైనా విఫలమైతే, బఫర్ పెరుగుతుంది మరియు సిస్టమ్ పునరుద్ధరించబడిన తర్వాత ఫ్లష్ చేయబడుతుంది. మిక్సర్ బ్యాకెండ్లు టెలిమెట్రీ డేటాను పంపడానికి ముగింపు బిందువులు: statsd, newrelic, మొదలైనవి. మీరు మీ స్వంత బ్యాకెండ్ను వ్రాయవచ్చు, ఇది చాలా సులభం మరియు దీన్ని ఎలా చేయాలో మేము చూస్తాము.
సంగ్రహంగా చెప్పాలంటే, istio-telemetryతో పని చేసే పథకం క్రింది విధంగా ఉంటుంది.
సర్వీస్ 1 సర్వీస్ 2కి అభ్యర్థనను పంపుతుంది.
సేవ 1 నుండి నిష్క్రమించినప్పుడు, అభ్యర్థన దాని స్వంత సైడ్కార్లో చుట్టబడుతుంది.
సైడ్కార్ రాయబారి అభ్యర్థన సేవ 2కి ఎలా వెళ్తుందో పర్యవేక్షిస్తుంది మరియు అవసరమైన సమాచారాన్ని సిద్ధం చేస్తుంది.
నివేదిక అభ్యర్థనను ఉపయోగించి దాన్ని istio-telemetryకి పంపుతుంది.
Istio-telemetry ఈ నివేదికను బ్యాకెండ్లకు పంపాలా, దేనికి మరియు ఏ డేటాను పంపాలి అని నిర్ణయిస్తుంది.
ఇప్పుడు ప్రధాన భాగాలను (పైలట్ మరియు సైడ్కార్ ఎన్వోయ్) మాత్రమే కలిగి ఉన్న సిస్టమ్లో ఇస్టియోను ఎలా అమలు చేయాలో చూద్దాం.
మొదట, పైలట్ చదివే ప్రధాన కాన్ఫిగరేషన్ (మెష్) చూద్దాం:
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
అన్ని ప్రధాన నియంత్రణ భాగాలు (కంట్రోల్ ప్లేన్) కుబెర్నెట్స్లోని నేమ్స్పేస్ ఇస్టియో-సిస్టమ్లో ఉంటాయి.
కనిష్టంగా, మేము పైలట్ని మాత్రమే నియమించాలి. దీని కోసం మేము ఉపయోగిస్తాము అటువంటి కాన్ఫిగరేషన్.
మరియు మేము కంటైనర్ యొక్క ఇంజెక్షన్ సైడ్కార్ను మాన్యువల్గా కాన్ఫిగర్ చేస్తాము.
ప్రతిదీ విజయవంతంగా ప్రారంభం కావడానికి, మీరు పైలట్ కోసం సర్వీస్ అకౌంట్, క్లస్టర్ రోల్, క్లస్టర్ రోల్ బైండింగ్, సిఆర్డిని సృష్టించాలి, వాటి వివరణలు కనుగొనబడతాయి ఇక్కడ.
ఫలితంగా, మేము ఎంవోయ్తో సైడ్కార్ని ఇంజెక్ట్ చేసే సేవ విజయవంతంగా ప్రారంభం కావాలి, పైలట్ నుండి అన్ని ఆవిష్కరణలను స్వీకరించి అభ్యర్థనలను ప్రాసెస్ చేయాలి.
అన్ని కంట్రోల్ ప్లేన్ కాంపోనెంట్లు స్థితిలేని అప్లికేషన్లు మరియు సమస్యలు లేకుండా అడ్డంగా స్కేల్ చేయబడతాయని అర్థం చేసుకోవడం ముఖ్యం. కుబెర్నెట్స్ వనరుల అనుకూల వివరణల రూపంలో మొత్తం డేటా etcdలో నిల్వ చేయబడుతుంది.
అలాగే, ఇస్టియో (ఇప్పటికీ ప్రయోగాత్మకంగా ఉంది) క్లస్టర్ వెలుపల పరిగెత్తగల సామర్థ్యాన్ని కలిగి ఉంది మరియు అనేక కుబెర్నెట్స్ క్లస్టర్ల మధ్య సర్వీస్ డిస్కవరీని వీక్షించే మరియు ఫంబుల్ చేయగల సామర్థ్యాన్ని కలిగి ఉంది. మీరు దీని గురించి మరింత చదువుకోవచ్చు ఇక్కడ.
బహుళ-క్లస్టర్ ఇన్స్టాలేషన్ కోసం, కింది పరిమితుల గురించి తెలుసుకోండి:
పాడ్ CIDR మరియు సర్వీస్ CIDR తప్పనిసరిగా అన్ని క్లస్టర్లలో ప్రత్యేకంగా ఉండాలి మరియు అతివ్యాప్తి చెందకూడదు.
అన్ని CIDR పాడ్లు క్లస్టర్ల మధ్య ఏదైనా CIDR పాడ్ల నుండి తప్పనిసరిగా యాక్సెస్ చేయబడాలి.
అన్ని Kubernetes API సర్వర్లు తప్పనిసరిగా ఒకదానికొకటి ప్రాప్యత కలిగి ఉండాలి.
ఇస్టియోతో ప్రారంభించడంలో మీకు సహాయపడే ప్రాథమిక సమాచారం ఇది. అయినప్పటికీ, ఇంకా చాలా ఆపదలు ఉన్నాయి. ఉదాహరణకు, బాహ్య ట్రాఫిక్ను రూట్ చేయడం (క్లస్టర్ వెలుపల), సైడ్కార్లను డీబగ్గింగ్ చేసే విధానాలు, ప్రొఫైలింగ్, మిక్సర్ని సెటప్ చేయడం మరియు కస్టమ్ మిక్సర్ బ్యాకెండ్ రాయడం, ట్రేసింగ్ మెకానిజం సెటప్ చేయడం మరియు ఎన్వోయ్ని ఉపయోగించి దాని ఆపరేషన్ వంటి లక్షణాలు.
ఇవన్నీ మనం ఈ క్రింది ప్రచురణలలో పరిశీలిస్తాము. మీ ప్రశ్నలను అడగండి, నేను వాటిని కవర్ చేయడానికి ప్రయత్నిస్తాను.