Istio at Kubernetes sa produksyon. Bahagi 2. Pagsubaybay

Sa huli Artikulo Tiningnan namin ang mga pangunahing bahagi ng Service Mesh Istio, nakilala ang system at sinagot ang mga pangunahing tanong na kadalasang lumalabas kapag nagsimulang magtrabaho kasama si Istio. Sa bahaging ito titingnan natin kung paano ayusin ang koleksyon ng impormasyon sa pagsubaybay sa isang network.

Ang unang bagay na naiisip ng maraming developer at system administrator kapag narinig nila ang mga salitang sinusubaybayan ng Service Mesh. Sa katunayan, nagdaragdag kami ng isang espesyal na proxy server sa bawat network node kung saan dumadaan ang lahat ng trapiko ng TCP. Mukhang posible na ngayong madaling magpadala ng impormasyon tungkol sa lahat ng mga pakikipag-ugnayan sa network sa network. Sa kasamaang palad, sa katotohanan mayroong maraming mga nuances na kailangang isaalang-alang. Tingnan natin sila.

Maling kuru-kuro numero uno: maaari tayong makakuha ng online na data ng hiking nang libre.

Sa katunayan, para sa medyo libre, maaari lamang namin makuha ang mga node ng aming system na konektado sa pamamagitan ng mga arrow at ang rate ng data na dumadaan sa pagitan ng mga serbisyo (sa katunayan, ang bilang lamang ng mga byte bawat yunit ng oras). Gayunpaman, sa karamihan ng mga kaso, ang aming mga serbisyo ay nakikipag-usap sa ilang uri ng application layer protocol, gaya ng HTTP, gRPC, Redis, at iba pa. At, siyempre, gusto naming makita ang impormasyon sa pagsubaybay na partikular para sa mga protocol na ito; gusto naming makita ang rate ng kahilingan, hindi ang rate ng data. Gusto naming maunawaan ang latency ng mga kahilingan gamit ang aming protocol. Sa wakas, gusto naming makita ang buong landas na dadalhin ng isang kahilingan mula sa pag-log in sa aming system hanggang sa pagtanggap ng tugon mula sa user. Ang problemang ito ay hindi na madaling lutasin.

Una, tingnan natin kung ano ang hitsura ng pagpapadala ng mga tracing span mula sa isang arkitektura na pananaw sa Istio. Tulad ng naaalala natin mula sa unang bahagi, ang Istio ay may hiwalay na bahagi na tinatawag na Mixer para sa pagkolekta ng telemetry. Gayunpaman, sa kasalukuyang bersyon 1.0.*, direktang ginagawa ang pagpapadala mula sa mga proxy server, ibig sabihin, mula sa envoy proxy. Sinusuportahan ng Envoy proxy ang pagpapadala ng mga tracing span gamit ang zipkin protocol sa labas ng kahon. Posibleng ikonekta ang iba pang mga protocol, ngunit sa pamamagitan lamang ng isang plugin. Sa Istio, agad kaming nakakakuha ng naka-assemble at naka-configure na envoy proxy, na sumusuporta lamang sa zipkin protocol. Kung gusto naming gamitin, halimbawa, ang Jaeger protocol at magpadala ng tracing span sa pamamagitan ng UDP, kakailanganin naming bumuo ng sarili naming istio-proxy na imahe. Mayroong suporta para sa mga custom na plugin para sa istio-proxy, ngunit nasa alpha version pa rin ito. Samakatuwid, kung gusto naming gawin nang walang malaking bilang ng mga custom na setting, ang hanay ng mga teknolohiyang ginagamit para sa pag-iimbak at pagtanggap ng mga tracing span ay nababawasan. Sa mga pangunahing system, sa katunayan, ngayon ay maaari mong gamitin ang Zipkin mismo, o Jaeger, ngunit ipadala ang lahat doon gamit ang zipkin compatible protocol (na kung saan ay hindi gaanong mahusay). Ang zipkin protocol mismo ay nagsasangkot ng pagpapadala ng lahat ng impormasyon sa pagsubaybay sa mga kolektor sa pamamagitan ng HTTP protocol, na medyo mahal.

Gaya ng sinabi ko na, gusto naming subaybayan ang mga protocol sa antas ng aplikasyon. Nangangahulugan ito na ang mga proxy server na nakatayo sa tabi ng bawat serbisyo ay dapat na maunawaan kung anong uri ng pakikipag-ugnayan ang nangyayari ngayon. Bilang default, kino-configure ng Istio ang lahat ng port upang maging plain TCP, na nangangahulugang walang mga bakas na ipapadala. Upang maipadala ang mga bakas, kailangan mo, una, paganahin ang pagpipiliang ito sa pangunahing mesh config at, kung ano ang napakahalaga, pangalanan ang lahat ng mga port ng mga entidad ng serbisyo ng kubernetes alinsunod sa protocol na ginagamit sa serbisyo. Iyon ay, halimbawa, tulad nito:

apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  ports:
  - port: 80
    targetPort: 80
    name: http
  selector:
    app: nginx

Maaari ka ring gumamit ng mga tambalang pangalan tulad ng http-magic (makikita ni Istio ang http at makikilala ang port na iyon bilang isang http endpoint). Ang format ay: proto-extra.

Upang hindi ma-patch ang isang malaking bilang ng mga configuration upang matukoy ang protocol, maaari kang gumamit ng isang maruming workaround: i-patch ang Pilot component sa sandaling ito ay bago pa lamang. gumaganap ng lohika ng kahulugan ng protocol. Sa huli, siyempre, kakailanganing baguhin ang lohika na ito sa pamantayan at lumipat sa isang kombensiyon ng pagbibigay ng pangalan para sa lahat ng port.

Upang maunawaan kung ang protocol ay talagang tinukoy nang tama, kailangan mong pumunta sa alinman sa mga sidecar container na may envoy proxy at humiling sa admin port ng envoy interface na may lokasyon /config_dump. Sa resultang pagsasaayos, kailangan mong tingnan ang larangan ng pagpapatakbo ng nais na serbisyo. Ginagamit ito sa Istio bilang isang identifier kung saan ginawa ang kahilingan. Upang ma-customize ang halaga ng parameter na ito sa Istio (makikita natin ito sa aming sistema ng pagsubaybay), kinakailangang tukuyin ang flag ng serviceCluster sa yugto ng paglulunsad ng sidecar container. Halimbawa, maaari itong kalkulahin tulad nito mula sa mga variable na nakuha mula sa pababang kubernetes API:

--serviceCluster ${POD_NAMESPACE}.$(echo ${POD_NAME} | sed -e 's/-[a-z0-9]*-[a-z0-9]*$//g')

Isang magandang halimbawa upang maunawaan kung paano gumagana ang pagsubaybay sa sugo dito.

Ang mismong endpoint para sa pagpapadala ng mga tracing span ay dapat ding tukuyin sa mga flag ng paglulunsad ng envoy proxy, halimbawa: --zipkinAddress tracing-collector.tracing:9411

Maling kuru-kuro numero dalawa: maaari kaming murang makakuha ng kumpletong bakas ng mga kahilingan sa pamamagitan ng system sa labas ng kahon

Sa kasamaang palad, ito ay hindi. Ang pagiging kumplikado ng pagpapatupad ay nakasalalay sa kung paano mo naipatupad ang pakikipag-ugnayan ng mga serbisyo. Bakit ganon?

Ang katotohanan ay upang maunawaan ng istio-proxy ang mga sulat ng mga papasok na kahilingan sa isang serbisyo sa mga umaalis sa parehong serbisyo, hindi sapat na harangin lamang ang lahat ng trapiko. Kailangan mong magkaroon ng ilang uri ng pagkakakilanlan ng komunikasyon. Gumagamit ang HTTP envoy proxy ng mga espesyal na header, kung saan nauunawaan ng envoy kung aling partikular na kahilingan sa serbisyo ang bumubuo ng mga partikular na kahilingan sa iba pang mga serbisyo. Listahan ng mga naturang header:

• x-request-id
• x-b3-traceid,
• x-b3-spanid,
• x-b3-parentspanid,
• x-b3-sample,
• x-b3-flag,
• x-ot-span-context.

Kung mayroon kang isang punto, halimbawa, isang pangunahing kliyente, kung saan maaari kang magdagdag ng ganoong lohika, kung gayon ang lahat ay maayos, kailangan mo lamang maghintay para sa library na ito na ma-update para sa lahat ng mga kliyente. Ngunit kung mayroon kang isang napaka-magkakaibang sistema at walang pag-iisa sa paglipat mula sa serbisyo patungo sa serbisyo sa network, malamang na ito ay isang malaking problema. Kung walang pagdaragdag ng ganoong lohika, ang lahat ng impormasyon sa pagsubaybay ay magiging "iisang antas" lamang. Ibig sabihin, matatanggap namin ang lahat ng inter-service na pakikipag-ugnayan, ngunit hindi sila ididikit sa iisang chain of passage sa network.

Konklusyon

Nagbibigay ang Istio ng maginhawang tool para sa pagkolekta ng impormasyon sa pagsubaybay sa isang network, ngunit dapat mong maunawaan na para sa pagpapatupad kakailanganin mong iakma ang iyong system at isaalang-alang ang mga tampok ng pagpapatupad ng Istio. Bilang resulta, dalawang pangunahing punto ang kailangang lutasin: ang pagtukoy sa antas ng application protocol (na dapat suportahan ng envoy proxy) at pag-set up ng pagpapasa ng impormasyon tungkol sa koneksyon ng mga kahilingan sa serbisyo mula sa mga kahilingan mula sa serbisyo (gamit ang mga header , sa kaso ng HTTP protocol). Kapag nalutas ang mga isyung ito, mayroon kaming isang makapangyarihang tool na nagbibigay-daan sa amin na malinaw na mangolekta ng impormasyon mula sa network, kahit na sa napaka-magkakaibang mga sistemang nakasulat sa maraming iba't ibang wika at mga balangkas.

Sa susunod na artikulo tungkol sa Service Mesh, titingnan natin ang isa sa pinakamalalaking problema sa Istio – ang malaking pagkonsumo ng RAM ng bawat sidecar proxy container at tatalakayin kung paano mo ito haharapin.

Pinagmulan: www.habr.com