කැනරි යෙදවීමක් දියත් කිරීමට සහ දෘශ්යමාන කිරීමට Istio+Kiali භාවිතා කිරීම
මෙම ලිපි මාලාවේ ලිපි
Kubernetes #1 හි කැනරි යෙදවීම: Gitlab CI Kubernetes #2 හි කැනරි යෙදවීම: Argo Rollouts - (මෙම ලිපිය)
- Jenkins-X Istio Flagger භාවිතයෙන් කැනරි යෙදවීම
කැනරි යෙදවීම
ඔබ කියවනු ඇතැයි අපි බලාපොරොත්තු වෙමු
ඉස්ටියෝ
තවද මෙම ලිපිය කියවීමෙන් ඔබ ඉස්තියෝ යනු කුමක්දැයි දැනටමත් දන්නා බව අපි උපකල්පනය කරමු. එසේ නොවේ නම්, ඔබට ඒ ගැන කියවිය හැකිය
පරීක්ෂණ සඳහා අයදුම්පත
සෑම පොඩ් එකකම බහාලුම් දෙකක් අඩංගු වේ: අපගේ යෙදුම සහ istio-proxy.
අපි frontend-nginx සහ backend python Pods සමඟ සරල පරීක්ෂණ යෙදුමක් භාවිතා කරන්නෙමු. nginx පොඩ් එක සෑම ඉල්ලීමක්ම පසුබිම් පොඩ් වෙත හරවා යවා ප්රොක්සියක් ලෙස ක්රියා කරයි. විස්තර පහත අලවලින් සොයාගත හැකිය:
පරීක්ෂණ යෙදුම ඔබම ධාවනය කිරීම
ඔබට මගේ ආදර්ශය අනුගමනය කිරීමට සහ මෙම පරීක්ෂණ යෙදුම ඔබම භාවිතා කිරීමට අවශ්ය නම්, බලන්න
මූලික යෙදවීම
අපි පළමු යෙදවීම දියත් කරන විට, අපගේ යෙදුමේ කරල් වල ඇත්තේ බහාලුම් 2 ක් පමණක් බව අපට පෙනේ, එනම් ඉස්ටියෝ සයිඩ්කාර් ක්රියාත්මක වෙමින් පවතී:
ඒවගේම අපි නාම අවකාශයේ Istio Gateway Loadbalancer එකත් දකිනවා istio-system
:
රථවාහන උත්පාදනය
ඉදිරිපස පොඩ්ස් මගින් ලැබෙන සහ පසුපෙළ පොඩ් වෙත යොමු කරන ගමනාගමනය උත්පාදනය කිරීමට අපි පහත IP භාවිතා කරන්නෙමු:
while true; do curl -s --resolve 'frontend.istio-test:80:35.242.202.152' frontend.istio-test; sleep 0.1; done
අපි ද එකතු කරන්නෙමු frontend.istio-test
අපගේ සත්කාරක ගොනුවට.
Kiali හරහා Mesh බලන්න
අපි Tracing, Grafana, Prometheus සහ Kiali සමඟ පරීක්ෂණ යෙදුම සහ Istio ස්ථාපනය කර ඇත (විස්තර සඳහා පහත බලන්න).
istioctl dashboard kiali # admin:admin
Kiali වත්මන් ගමනාගමනය Mesh හරහා දෘශ්යමාන කරයි
අපට පෙනෙන පරිදි, ගමනාගමනයෙන් 100% ක් ඉදිරිපස සේවාවට, පසුව ලේබලය v1 සහිත ඉදිරිපස පොඩ් වෙත යයි, මන්ද අපි සරල nginx ප්රොක්සියක් භාවිතා කරන බැවින් ඉල්ලීම් පසුපෙළ සේවාවට හරවා යවන අතර එමඟින් ඒවා පසුපස පොඩ් වෙත හරවා යවනු ලැබේ. ලේබලය v1 සමඟ.
Kiali Istio සමඟ හොඳින් ක්රියා කරන අතර කොටු දැල් විදැහුම්කරණ විසඳුමක් සපයයි. නියමයි.
කැනරි යෙදවීම
අපගේ පසුතලය දැනටමත් k8s යෙදවීම් දෙකක් ඇත, එකක් v1 සඳහා සහ එකක් v2 සඳහා. දැන් අපට අවශ්ය වන්නේ ඉස්ටියෝට යම් ඉල්ලීම් ප්රතිශතයක් v2 වෙත යොමු කරන ලෙසයි.
පියවර 1: 10%
ඒ වගේම අපි කරන්න ඕන VirtualService හි බර සකස් කිරීමයි
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: backend
namespace: default
spec:
gateways: []
hosts:
- "backend.default.svc.cluster.local"
http:
- match:
- {}
route:
- destination:
host: backend.default.svc.cluster.local
subset: v1
port:
number: 80
weight: 90
- destination:
host: backend.default.svc.cluster.local
subset: v2
port:
number: 80
weight: 10
ඉල්ලීම් වලින් 10% ක් v2 වෙත හරවා යවන බව අපට පෙනේ.
පියවර 2: 50%
දැන් එය 50% දක්වා වැඩි කිරීමට ප්රමාණවත්ය:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: backend
namespace: default
spec:
...
- destination:
host: backend.default.svc.cluster.local
subset: v1
port:
number: 80
weight: 50
- destination:
host: backend.default.svc.cluster.local
subset: v2
port:
number: 80
weight: 50
පියවර 3: 100%
දැන් කැනරි යෙදවීම සම්පූර්ණ ලෙස සැලකිය හැකි අතර සියලුම ගමනාගමනය v2 වෙත හරවා යවනු ලැබේ:
කැනරි අතින් පරීක්ෂා කිරීම
අපි දැන් සියලුම ඉල්ලීම් වලින් 2%ක් v10 බැක්එන්ඩ් එකට යවමු කියමු. අපි බලාපොරොත්තු වන පරිදි සෑම දෙයක්ම ක්රියාත්මක වන බව සහතික කර ගැනීමට අපට v2 අතින් පරීක්ෂා කිරීමට අවශ්ය නම් කුමක් කළ යුතුද?
අපට HTTP ශීර්ෂ මත පදනම්ව විශේෂ ගැළපෙන රීතියක් එක් කළ හැක:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: backend
namespace: default
spec:
gateways: []
hosts:
- "backend.default.svc.cluster.local"
http:
- match:
- headers:
canary:
exact: "canary-tester"
route:
- destination:
host: backend.default.svc.cluster.local
subset: v2
port:
number: 80
weight: 100
- match:
- {}
route:
- destination:
host: backend.default.svc.cluster.local
subset: v1
port:
number: 80
weight: 90
- destination:
host: backend.default.svc.cluster.local
subset: v2
port:
number: 80
weight: 10
දැන් curl භාවිතයෙන් අපට ශීර්ෂය යැවීමෙන් v2 ඉල්ලීමක් බල කළ හැක:
ශීර්ෂයක් නොමැති ඉල්ලීම් තවමත් 1/10 අනුපාතය මගින් මෙහෙයවනු ලැබේ:
යැපෙන අනුවාද දෙකක් සඳහා කැනරි
දැන් අපි ඉදිරිපස සහ පසුපෙළ යන දෙකටම v2 අනුවාදය ඇති විකල්පය සලකා බලමු. දෙකම සඳහා, අපි තදබදයෙන් 10% v2 වෙත යා යුතු බව සඳහන් කළෙමු:
අපි දකිනවා ඉදිරිපස v1 සහ v2 යන දෙකම ඉදිරි ගමනාගමනය පසුපසට v1 සහ v10 දක්වා 1/2 අනුපාතයකින්.
එය v2 සමඟ නොගැළපෙන නිසා අපට ඉදිරිපස-v2 සිට backend-v1 දක්වා පමණක් ගමනාගමනය යොමු කිරීමට අවශ්ය නම් කුමක් කළ යුතුද? මෙය සිදු කිරීම සඳහා, අපි ඉදිරිපස කොටස සඳහා 1/10 අනුපාතයක් සකසන්නෙමු, එය සාකච්ඡා භාවිතයෙන් පසුපෙළ-v2 වෙත ලැබෙන ගමනාගමනය පාලනය කරයි. sourceLabels
:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: backend
namespace: default
spec:
gateways: []
hosts:
- "backend.default.svc.cluster.local"
http:
...
- match:
- sourceLabels:
app: frontend
version: v2
route:
- destination:
host: backend.default.svc.cluster.local
subset: v2
port:
number: 80
weight: 100
ප්රතිඵලයක් වශයෙන්, අපට අවශ්ය දේ ලබා ගනී:
අතින් කැනරි ප්රවේශයෙන් වෙනස්කම්
В පළමු කොටස අපි කැනරි යෙදවීම අතින් සිදු කළ අතර, k8s යෙදවුම් දෙකක් ද භාවිතා කළෙමු. එහිදී අපි අනුරූ ගණන වෙනස් කරමින් ඉල්ලීම් අනුපාතය පාලනය කළා. මෙම ප්රවේශය ක්රියා කරයි, නමුත් බරපතල අඩුපාඩු තිබේ.
Istio මඟින් අනුරූ ගණන නොතකා ඉල්ලීම්වල අනුපාතය තීරණය කිරීමට හැකි වේ. මෙයින් අදහස් කරන්නේ, උදාහරණයක් ලෙස, අපට HPAs (Horizontal Pod Autoscalers) භාවිතා කළ හැකි අතර කැනරි යෙදවීමේ වත්මන් තත්ත්වය අනුව වින්යාස කිරීම අවශ්ය නොවන බවයි.
ප්රතිඵලය
Istio විශිෂ්ට ලෙස ක්රියා කරන අතර එය Kiali සමඟ එක්ව භාවිතා කිරීම ඉතා ප්රබල සංයෝජනයක් බවට පත් කරයි. මගේ රුචිකත්ව ලැයිස්තුවේ ඊළඟට ස්පින්නකර් ස්වයංක්රීයකරණය සහ කැනරි විශ්ලේෂණ සඳහා ඉස්ටියෝ සමඟ ඒකාබද්ධ කිරීමයි.
මූලාශ්රය: www.habr.com