زموږ د Kubernetes چټک پیل لړۍ ته ښه راغلاست. دا یو منظم کالم دی چې د خورا زړه پورې پوښتنو سره چې موږ آنلاین او زموږ په روزنې کې ترلاسه کوو. د Kubernetes متخصص ځوابونه.
د نن ورځ کارپوه ډینیل پولینچیک دی (). ډینیل کې د ښوونکي او سافټویر جوړونکي په توګه کار کوي .
که غواړۍ په راتلونکي پوسټ کې مو پوښتنې ځواب کړې او یا .
پخواني پوسټونه له لاسه ورکړي؟ .
د مختلف معلوماتو مرکزونو کې د Kubernetes کلسترونه څنګه وصل کړئ؟
په لنډه توګه: ، او زه هم د لوستلو وړاندیز کوم и .
ډیری وختونه، زیربنا په مختلفو سیمو کې، په ځانګړې توګه په کنټرول شوي چاپیریال کې نقل شوي او ویشل کیږي.
که یوه سیمه شتون ونلري، ټرافیک بلې ته لیږل کیږي ترڅو د خنډونو مخه ونیسي.
د Kubernetes سره، تاسو کولی شئ ورته ستراتیژي وکاروئ او په مختلفو سیمو کې د کار بارونه وویشئ.
تاسو کولی شئ په هر ټیم، سیمه، چاپیریال، یا د دې عناصرو ترکیب یو یا څو کلسترونه ولرئ.
ستاسو کلسترونه په مختلفو بادلونو او آن پریمیسس کې کوربه کیدی شي.
مګر تاسو څنګه د داسې جغرافیایی خپریدو لپاره زیربنا پلان کوئ؟
ایا تاسو اړتیا لرئ په یوه شبکه کې د څو کلاوډ چاپیریالونو لپاره یو لوی کلستر جوړ کړئ؟
یا ډیری کوچني کلسترونه لرئ او د دوی کنټرول او همغږي کولو لپاره لاره ومومئ؟
یو د مشرتابه کلستر
په یوه شبکه کې د یو کلستر جوړول دومره اسانه ندي.
تصور وکړئ چې تاسو یوه حادثه لرئ، د کلستر برخو ترمنځ ارتباط له لاسه ورکړی.
که تاسو یو ماسټر سرور ولرئ، نیمایي سرچینې به د نوي حکمونو ترلاسه کولو توان ونلري ځکه چې دوی به د ماسټر سره اړیکه ونلري.
او په ورته وخت کې تاسو زاړه روټینګ میزونه لرئ (kube-proxy نشي کولی نوي ډاونلوډ کړي) او هیڅ اضافي پوډونه (کوبلیټ نشي کولی د تازه معلوماتو غوښتنه وکړي).
د دې لپاره چې مسله نوره هم خرابه کړي، که Kubernetes یو نوډ ونه ګوري، دا د یتیم په توګه په نښه کوي او ورک شوي پوډونه موجوده نوډونو ته توزیع کوي.
د پایلې په توګه، تاسو دوه ځله ډیری پوزې لرئ.
که تاسو د هرې سیمې لپاره یو ماسټر سرور جوړ کړئ، نو د etcd ډیټابیس کې به د موافقت الګوریتم سره ستونزې وي. ((نږدې ed. - په حقیقت کې، د etcd ډیټابیس اړین ندي چې په ماسټر سرورونو کې موقعیت ولري. دا په ورته سیمه کې د سرورونو په جلا ګروپ کې پرمخ وړل کیدی شي. ریښتیا، په ورته وخت کې د کلستر د ناکامۍ نقطه ترلاسه کول. خو ژر.)
etcd کاروي په ډیسک کې د لیکلو دمخه د ارزښت په اړه خبرې کول.
دا دی، ډیری مثالونه باید موافقې ته ورسیږي مخکې له دې چې دولت etcd ته ولیکل شي.
که چیرې د etcd مثالونو ترمینځ ځنډ په ډراماتیک ډول ډیر شي ، لکه څنګه چې په بیلابیلو سیمو کې د دریو etcd مثالونو سره قضیه وي ، دا د ارزښت په اړه خبرې کولو او ډیسک ته لیکلو لپاره ډیر وخت نیسي.
دا د Kubernetes کنټرولرونو کې منعکس کیږي.
د کنټرولر مدیر ډیر وخت ته اړتیا لري ترڅو د بدلون په اړه زده کړي او ډیټابیس ته ځواب ولیکي.
او ځکه چې دلته یو کنټرولر نشته، مګر څو، یو سلسله غبرګون پایله کوي او ټول کلستر ډیر ورو کار پیل کوي.
etcd دومره ځنډ سره حساس دی .
اوس مهال د یو واحد کلستر لپاره د لوی شبکې ښه مثالونه شتون نلري.
اساسا، د پراختیا کونکي ټولنه او د SIG-کلستر ګروپ هڅه کوي معلومه کړي چې څنګه د کلسترونو آرکیسټریټ کول په ورته ډول د Kubernetes آرکیسټریټ کانټینرونه.
1 اختیار: د کلستر فدراسیون د کیوبفیډ سره
د SIG کلستر رسمي ځواب - .
د لومړي ځل لپاره، موږ هڅه وکړه چې د کلسترونو ټولګه د یو واحد اعتراض په توګه د کیوب فدراسیون وسیلې په کارولو سره اداره کړو.
پیل ښه و، مګر په پای کې د کیوب فدراسیون هیڅکله مشهور نه شو ځکه چې دا د ټولو سرچینو ملاتړ نه کوي.
دا د فدرالي تحویلۍ او خدماتو ملاتړ کوي، مګر د بیلګې په توګه، StatefulSets نه.
همدارنګه، د فدراسیون ترتیب د اعلاناتو په بڼه لیږدول شوی او انعطاف وړ نه و.
تصور وکړئ چې تاسو څنګه کولی شئ یوازې د تشریحاتو په کارولو سره په فدراسیون کې د هر کلستر لپاره د نقل ویش تشریح کړئ.
دا یو بشپړ ګډوډي وه.
SIG-cluster د kubefed v1 وروسته ډیر کار وکړ او پریکړه یې وکړه چې ستونزې ته د مختلف زاویې څخه مراجعه وکړي.
د تشریحاتو پرځای، دوی پریکړه وکړه چې یو کنټرولر خوشې کړي چې په کلسترونو کې نصب شوی. دا د ګمرک سرچینې تعریفونو (CRDs) په کارولو سره دودیز کیدی شي.
د هرې سرچینې لپاره چې د فدراسیون برخه وي، تاسو د دریو برخو سره د CRD دودیز تعریف لرئ:
- د یوې سرچینې معیاري تعریف، د بیلګې په توګه ځای پرځای کول؛
- کړی
placement، چیرې چې تاسو تعریف کوئ چې سرچینې به په فدراسیون کې څنګه ویشل کیږي؛ - کړی
override، چیرې چې د یوې ځانګړې سرچینې لپاره تاسو کولی شئ د ځای په ځای کولو څخه وزن او پیرامیټونه پورته کړئ.
دلته د ځای پرځای کولو او پورته کولو برخو سره د ګډ تحویلۍ بیلګه ده.
apiVersion: types.federation.k8s.io/v1alpha1
kind: FederatedDeployment
metadata:
name: test-deployment
namespace: test-namespace
spec:
template:
metadata:
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- image: nginx
name: nginx
placement:
clusterNames:
- cluster2
- cluster1
overrides:
- clusterName: cluster2
clusterOverrides:
- path: spec.replicas
value: 5لکه څنګه چې تاسو لیدلی شئ، عرضه په دوو کلسترونو ویشل شوې ده: cluster1 и cluster2.
لومړی کلستر درې نقلونه چمتو کوي، او دویم یې 5 ته ټاکل شوی.
که تاسو د نقلونو شمیر باندې ډیر کنټرول ته اړتیا لرئ، kubefed2 یو نوی ReplicaSchedulingPreference څیز وړاندې کوي چیرې چې نقلونه وزن کیدی شي:
apiVersion: scheduling.federation.k8s.io/v1alpha1
kind: ReplicaSchedulingPreference
metadata:
name: test-deployment
namespace: test-ns
spec:
targetKind: FederatedDeployment
totalReplicas: 9
clusters:
A:
weight: 1
B:
weight: 2د CRD جوړښت او API لاهم بشپړ چمتو ندي، او د پروژې په رسمي ذخیره کې فعال کار روان دی.
په kubefed2 سترګې پټ کړئ، مګر په یاد ولرئ چې دا لاهم د تولید لپاره مناسب نه دی.
د kubefed2 په اړه نور معلومات ترلاسه کړئ په بلاګ کې د Kubernetes او in په اړه .
2 اختیار: د Booking.com سټایل کې د کلسترونو ترکیب
د Booking.com پراختیا کونکو په kubefed v2 کې کار نه دی کړی، مګر دوی د شیپر سره راغلل - په څو کلسترونو، په څو سیمو او څو بادونو کې د رسولو لپاره یو آپریټر.
یو څه ورته kubefed2.
دواړه وسیلې تاسو ته اجازه درکوي چې ستاسو د څو کلستر ګمارنې ستراتیژي تنظیم کړئ (کوم کلسترونه کارول کیږي او څومره عکسونه لري).
خو د شیپر هدف د سپارلو پرمهال د غلطیو خطر کمول دي.
په شیپر کې، تاسو کولی شئ یو لړ مرحلې تعریف کړئ چې د تیرو او اوسني ګمارلو او د راتلونکو ټرافیک حجم ترمنځ د نقلونو ویش تشریح کوي.
کله چې تاسو یوې سرچینې کلستر ته فشار ورکړئ، د شیپر کنټرولر په تدریجي ډول د ټولو یوځای شوي کلسترونو کې بدلون راولي.
همچنان ، لیږدونکی خورا محدود دی.
د مثال په توګه، دا د هیلم چارټونه د ننوتلو په توګه مني او د وینیلا سرچینو ملاتړ نه کوي.
په عمومي اصطلاحاتو کې، شیپر دا ډول کار کوي.
د معیاري تحویلۍ پرځای ، تاسو اړتیا لرئ د غوښتنلیک سرچینه رامینځته کړئ چې پکې د هیلم چارټ شامل وي:
apiVersion: shipper.booking.com/v1alpha1
kind: Application
metadata:
name: super-server
spec:
revisionHistoryLimit: 3
template:
chart:
name: nginx
repoUrl: https://storage.googleapis.com/shipper-demo
version: 0.0.1
clusterRequirements:
regions:
- name: local
strategy:
steps:
- capacity:
contender: 1
incumbent: 100
name: staging
traffic:
contender: 0
incumbent: 100
- capacity:
contender: 100
incumbent: 0
name: full on
traffic:
contender: 100
incumbent: 0
values:
replicaCount: 3شیپر د ډیری کلسترونو اداره کولو لپاره یو ښه اختیار دی، مګر د هیلم سره نږدې اړیکې یوازې په لاره کې راځي.
څه که موږ ټول له هیلم څخه بدل شو او یا ?
د شیپر او د هغې فلسفې په اړه نور معلومات په کې ومومئ .
که تاسو غواړئ کوډ ته وخورئ، .
3 اختیار: "جادو" کلستر یوځای کول
Kubefed v2 او Shipper د کلستر فدراسیون سره کار کوي، د دودیز سرچینو تعریف له لارې کلسترونو ته نوې سرچینې چمتو کوي.
مګر څه که تاسو نه غواړئ ټول تحویلۍ ، StatefulSets ، DaemonSets او نور د یوځای کولو لپاره بیا ولیکئ؟
د YAML بدلولو پرته په فدراسیون کې موجوده کلستر څنګه شامل کړئ؟
، کوم چې په کلسترونو کې د کاري بارونو مهالویش سره معامله کوي.
مګر د دې پرځای چې د کلستر سره د تعامل لپاره نوې لارې سره راشي او په دودیز تعریفونو کې سرچینې وپلټئ ، ملټي کلستر - مهالویش د معیاري کبرنیټس ژوند دورې کې ځای په ځای شوی او ټول هغه زنګونه مداخله کوي چې پوډونه رامینځته کوي.
هر جوړ شوی پوډ سمدلاسه د ډمي سره بدل شوی.
د څو کلستر - مهالویش کارول د زنګ مخنیوی کول او یو غیر فعال ډمی پوډ جوړ کړئ.
اصلي پوډ د بل پلان کولو دورې څخه تیریږي چیرې چې د ټول فدراسیون د رایې ورکولو وروسته د ځای پرځای کولو پریکړه کیږي.
په نهایت کې، پوډ د هدف کلستر ته سپارل کیږي.
د پایلې په توګه، تاسو یو اضافي پوډ لرئ چې هیڅ نه کوي، یوازې ځای نیسي.
ګټه دا ده چې تاسو اړتیا نلرئ د اکمالاتو یوځای کولو لپاره نوې سرچینې ولیکئ.
هره سرچینه چې پوډ رامینځته کوي په اوتومات ډول یوځای کیدو ته چمتو دي.
دا په زړه پورې ده، ځکه چې ناڅاپه تاسو په ډیری سیمو کې توزیع شوي، او تاسو حتی پام نه دی کړی. په هرصورت، دا خورا خطرناک دی، ځکه چې دلته هرڅه په جادو پورې اړه لري.
مګر پداسې حال کې چې شیپر هڅه کوي تر ډیره د تحویلۍ اغیزې کمې کړي ، ملټي کلستر - مهالویش کونکی ډیر عمومي دندې اداره کوي او شاید د بیچ دندو لپاره غوره وي.
دا د تدریجي تحویلي پرمختللي میکانیزم نلري.
د ملټي کلستر - مهالویش په اړه نور معلومات په کې موندل کیدی شي .
که تاسو غواړئ په عمل کې د څو کلستر - مهالویش په اړه ولولئ، اډمیرلټي لري - کاري جریان، پیښې، CI او CD Kubernetes.
نور وسایل او حلونه
د څو کلسترونو نښلول او اداره کول یو پیچلی کار دی، او هیڅ نړیوال حل شتون نلري.
که تاسو غواړئ دا موضوع نوره هم وپلټئ، دلته ځینې سرچینې دي:
- یوه وسیله ده چې د مختلف Kubernetes کلسترونو پوښښ شبکې سره نښلوي.
- د پرچون سلسلې هدف کارول .
- د IPV6 کارولو هڅه وکړئ او .
- تاسو کولی شئ د خدمت میش وکاروئ، د بیلګې په توګه .
- Cilium، د کانټینر شبکې انٹرفیس پلگ ان، وړاندیز کوي ، کوم چې تاسو ته اجازه درکوي څو کلسترونه یوځای کړئ
دا ټول د نن ورځې لپاره دي
تر پایه د لوستلو لپاره مننه!
که تاسو پوهیږئ چې څنګه ډیری کلسترونه په اغیزمنه توګه وصل کړئ، .
موږ به ستاسو طریقه په لینکونو کې اضافه کړو.
د کریس نیسبټ سمیټ څخه ځانګړې مننه () او وینسنټ دی سمی () (د اعتبار انجنیر په د مقالې لوستلو او د فدراسیون د کار کولو څرنګوالي په اړه ګټور معلومات شریکولو لپاره.
سرچینه: www.habr.com