مجموعات Kubernetes في خدمة VPC

لقد أضفنا القدرة على تشغيل Kubernetes بسهولة في خدمة Virtual Private Cloud في وضع الاختبار التجريبي المبكر.

ستكون هذه الوظيفة مفيدة للمستخدمين الذين يحتاجون إلى إدارة مريحة لعدد كبير من التطبيقات التي تعمل كحاويات. تقدم Kubernetes أدوات لتغيير الحجم والشفاء الذاتي وموازنة للحاويات التي تعمل داخل مجموعة.

نظرًا لأن خدمة Virtual Private Cloud تستند إلى OpenStack ، فإننا نستخدم أحد مكوناتها - OpenStack Magnum . يسمح لك بإنشاء مجموعات Kubernetes الخاصة بسرعة مع العدد المطلوب من العقد.

في الوقت الحالي ، يمكن لأي مستخدم لخدمتنا إنشاء عدة مجموعات مستقلة في مشروعه. كعقد الكتلة ، سيتم استخدام الأجهزة الافتراضية ، والتي يمكن تحديد تكوينها وتغييرها.

في هذه المقالة ، سنتحدث عن الكائنات الرئيسية لمجموعة Kubernetes ونستخدم الأمثلة للنظر في عملية إنشاء مجموعة باستخدام OpenStack Magnum.

إنشاء وإدارة مجموعة Kubernetes

حاليًا ، لا يمكن إنشاء مجموعة Kubernetes إلا من خلال أدوات وحدة التحكم أو OpenStack API في منطقتي التوفر ru-1a و ru-1b (سانت بطرسبرغ).

للبدء ، ستحتاج إلى:

• إنشاء مشروع جديد أو استخدام مشروع VPC موجود ؛
• إنشاء مستخدم بمفتاح SSH ؛
• إضافة مستخدم إلى المشروع الذي تم إنشاؤه في صفحة إدارة المشروع ؛
• انتقل إلى المشروع واحصل على ملف الوصول في علامة تبويب الوصول ؛
• تثبيت عميل وحدة التحكم openstack مع مكتبة python-magnumclient ؛
• قم بتثبيت عميل وحدة التحكم kubectl .

لتثبيت عميل وحدة التحكم openstack ، يمكنك استخدام الإرشادات الموجودة على الرابط ، ومع ذلك ، يجب أن يوضع في الاعتبار أنه بالنسبة لهذا العميل ، ستحتاج أيضًا إلى تثبيت مكتبة python-magnumclient لدعم إنشاء مجموعات Kubernetes.

المجموعة الكاملة من الأوامر لتثبيت عميل openstack مع المكون الإضافي المطلوب لأنظمة تشغيل عائلة Ubuntu / Debian:

$ sudo apt update $ sudo apt -y install curl python-pip python-dev python3-dev git libxml2-dev libxslt1-dev python-openssl python3-openssl python-pyasn1 libffi-dev libssl-dev build-essential $ sudo pip install -UI pbr setuptools pytz $ sudo pip install -UI git+https://github.com/openstack/python-openstackclient $ sudo pip install -UI git+https://github.com/openstack/python-magnumclient 

المجموعة الكاملة من الأوامر لتثبيت عميل openstack مع المكون الإضافي المطلوب لأنظمة تشغيل عائلة Fedora / CentOS:

 $ sudo yum -y install python-pip gcc libffi-devel python-devel libxslt-devel openssl-devel git libffi-devel $ sudo pip install -UI pbr setuptools pytz $ sudo pip install -UI git+https://github.com/openstack/python-openstackclient $ sudo pip install -UI git+https://github.com/openstack/python-magnumclient 

لإدارة كائنات Kubernetes ، تحتاج إلى عميل وحدة التحكم kubectl . يتم وصف طرق التثبيت لمختلف أنظمة التشغيل في الوثائق الرسمية .

لإنشاء مجموعة ، ستحتاج إلى إنشاء مجموعات موجودة أو استخدامها:

• قالب الكتلة
• مجموعة من المعلمات لوحدة المعالجة المركزية وذاكرة الوصول العشوائي للأجهزة الافتراضية ( النكهة ).

يمكنك إنشاء قالب نظام المجموعة والنكهة بنفسك ، أو استخدام قوالب عامة تم إنشاؤها مسبقًا.

ستحتاج أيضًا إلى تحديد منطقة الإتاحة ، ونوع الأقراص للكتلة ، وعدد العقد. تجدر الإشارة إلى أننا لا ندعم بعد إمكانية إنشاء مجموعة واحدة في عدة مناطق. يمكنك اختيار أي نوع من محركات أقراص الشبكة (سريعة أو عامة أو أساسية).
يمكنك معرفة المزيد حول أنواع محركات الأقراص من قاعدة معارفنا .

يمكن أن يختلف عدد العقد للماجستير ولأدوار العميل . على العقد التي تؤدي الدور الرئيسي ، سيتم إطلاق عناصر التحكم في الكتلة - مدير التحكم ، المجدول ، واجهة برمجة التطبيقات . على العقد الأخرى ، سيتم إطلاق خدمات kubelet و kube-proxy وجميع حاويات التطبيقات. يمكنك معرفة المزيد حول المكونات التي تعمل على عُقد نظام المجموعة من الوثائق الرسمية .

للوصول إلى العقد عبر SSH ، ستحتاج إلى استخدام مفتاح SSH الذي تم إنشاؤه سابقًا. ستستخدم أوامر العينة مفتاحًا يسمى اختبار ssh .

سنستخدم قالب ونكهة الكتلة العامة ، ونوع القرص السريع ، ومنطقة توفر ru-1b .
في مجموعتنا ، سيتم إطلاق عقدتين رئيسيتين و 3 عقد مينيون في البداية.

للتحقق من هذه المعلمات ، نستخدم أوامر openstackclient وملف الوصول الذي تم تنزيله ( rc.sh ):

 #          . $ source rc.sh #  ,         $ openstack flavor show BL1.2-4096 -c ram -c vcpus +-------+-------+ | Field | Value | +-------+-------+ | ram | 4096 | | vcpus | 2 | +-------+-------+ #       ru-1b $ openstack volume type show fast.ru-1b -c name +-------+------------+ | Field | Value | +-------+------------+ | name | fast.ru-1b | +-------+------------+ #    Kubernetes $ openstack coe cluster template list -c name +---------------------------------------+ | name | +---------------------------------------+ | kubernetes-nofloatingips-ru-1b-v1.9.3 | | kubernetes-nofloatingips-ru-1b-v1.9.6 | | kubernetes-nofloatingips-ru-1b-v1.9.9 | | kubernetes-floatingips-ru-1b-v1.9.3 | | kubernetes-floatingips-ru-1b-v1.9.6 | | kubernetes-floatingips-ru-1b-v1.9.9 | | kubernetes-nofloatingips-ru-1a-v1.9.3 | | kubernetes-nofloatingips-ru-1a-v1.9.6 | | kubernetes-nofloatingips-ru-1a-v1.9.9 | | kubernetes-floatingips-ru-1a-v1.9.3 | | kubernetes-floatingips-ru-1a-v1.9.6 | | kubernetes-floatingips-ru-1a-v1.9.9 | +---------------------------------------+ 

على سبيل المثال ، سنختار قالب المجموعة الثاني ؛ لن يتم إنشاء العناوين العائمة المتاحة للجمهور لكل عقد منها. لن نحتاجهم.

 #   Kubernetes   test-cluster #   keypair   ,   $ openstack coe cluster create \ --cluster-template kubernetes-nofloatingips-ru-1b-v1.9.9 \ --master-count 2 \ --node-count 3 \ --keypair ssh-test \ --master-flavor BL1.2-4096 \ --flavor BL1.2-4096 \ test-cluster 

يرجى ملاحظة أننا اخترنا نفس التكوين للعقد المختلفة (معلمات النكهة الرئيسية والنكهة) ، يمكنك اختيار مجموعات تكوين مختلفة اعتمادًا على متطلبات المجموعة. تغييرهم ممكن بعد إنشائه.

تجدر الإشارة أيضًا إلى أنه عند إنشاء مجموعة تحتوي على عدة عقد رئيسية ، سيتم إنشاء موازن تحميل تلقائيًا للوصول إلى واجهة برمجة تطبيقات Kubernetes.

بعد بضع دقائق ، ستظهر مجموعة Kubernetes في مشروعك. في لوحة تحكم المشروع ، سترى أجهزة افتراضية وأقراص وكائنات شبكة جديدة.

يمكنك التحقق من حالة مجموعتك من خلال openstackclient:

 openstack coe cluster list -c name -c status +--------------+--------------------+ | name | status | +--------------+--------------------+ | test-cluster | CREATE_IN_PROGRESS | +--------------+--------------------+ 

بعد دخول الكتلة في حالة CREATE_COMPLETE ، يمكنك إدارة كائناتها من خلال أداة kubectl عن طريق تنزيل ملف التكوين باستخدام الأوامر التالية:

 $ mkdir -p ~/test-cluster $ openstack coe cluster config test-cluster --dir ~/test-cluster 

بعد ذلك ، يمكنك العمل مع الكتلة باستخدام الأداة المساعدة kubectl:

 $ export KUBECONFIG=~/test-cluster/config $ kubectl get pods --all-namespaces -o=custom-columns=NAME:.metadata.name,STATUS:.status.phase NAME STATUS coredns-785dcf9c58-6gnfp Running heapster-6846cdc674-rm4k6 Running kube-dns-autoscaler-6b94f7bbf8-x5clt Running kubernetes-dashboard-747575c864-wlg6p Running monitoring-grafana-84b4596dd7-zf5rx Running monitoring-influxdb-c8486fc95-bqqb6 Running node-exporter-test-cluster-robvp4cvwpt7-minion-0 Running 

إذا لزم الأمر ، يمكنك زيادة أو تقليل عدد عقد العميل في المجموعة من خلال openstackclient بتمرير قيمة node_count الجديدة:

 $ openstack coe cluster update test-cluster replace node_count=4 

كائنات الكتلة Kubernetes الرئيسية

القرون

على الرغم من أن Kubernetes تدير مجموعة من الحاويات ، فإن الكيان الأساسي الذي تديره Kubernetes ليس حاوية ، بل Pod .

Pod هي مجموعة من مساحات أسماء نواة Linux وإعدادات مكدس الشبكة التي تسمح لك بتجميع مجموعة من الحاويات في كيان واحد.
في كثير من الأحيان ، يتم تشغيل حاوية واحدة مع التطبيق داخل Pod منفصل واحد.
إذا لزم الأمر ، يمكنك تشغيل عدة حاويات داخل Pod واحد ، يمكن أن يكون هذا مفيدًا عندما تحتاج إلى توفير الوصول من حاوية إلى أخرى من خلال واجهة شبكة localhost ، أو لسبب آخر تشغيل عدة حاويات على نفس المضيف.
سيكون لجميع الحاويات التي تعمل في نفس Pod اسم مضيف واحد وعنوان IP وجدول توجيه وأقراص.

تجدر الإشارة إلى أنه عند قياس عدد مثيلات تطبيقك داخل Kubernetes ، من الضروري زيادة عدد Pods ، وليس عدد الحاويات في Pod واحد محدد.
مزيد من التفاصيل في وثائق Pods الرسمية.

على سبيل المثال ، لنقم بإنشاء أبسط Pod باستخدام Nginx باستخدام الوصف بتنسيق yaml:

 # nginx-basic.yaml apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - name: nginx image: library/nginx:1.14-alpine ports: - containerPort: 80 

لإنشاء Pod ، يمكننا استخدام الأداة المساعدة kubectl .
أضفنا جميع الأمثلة المقدمة في المقالة إلى مجموعة Github ، لذلك لا يمكنك إنشاء ملفات على جهاز الكمبيوتر الخاص بك ، ولكن استخدام عنوان URL الخاص بالملف من المستودع العام:

 $ kubectl create \ -f https://raw.githubusercontent.com/selectel/kubernetes-examples/master/pods/nginx-basic.yaml 

بعد الإنشاء ، يمكننا طلب معلومات كاملة عن حالة Pod باستخدام الأمر kubectl description:

 $ kubectl describe pod nginx Name: nginx Namespace: default Node: test-cluster-nd5c5y6lsfxb-minion-0/10.0.0.5 Start Time: Sun, 17 Jun 2018 12:29:03 +0000 Labels: <none> Annotations: <none> Status: Running IP: 10.100.88.9 Containers: nginx: Container ID: docker://6ca6383b66686c05c61c1f690737110e0f8994eda393f44a7ebfbbf2b2026267 Image: library/nginx:1.14-alpine Image ID: docker-pullable://docker.io/nginx@sha256:944b79ca7dbe456ce72e73e70816c1990e39967c8f010349a388c00b77ec519c Port: 80/TCP Host Port: 0/TCP State: Running Started: Sun, 17 Jun 2018 12:29:16 +0000 Ready: True Restart Count: 0 Environment: <none> Mounts: /var/run/secrets/kubernetes.io/serviceaccount from default-token-rp5ls (ro) Conditions: Type Status Initialized True Ready True PodScheduled True Volumes: default-token-rp5ls: Type: Secret (a volume populated by a Secret) SecretName: default-token-rp5ls Optional: false QoS Class: BestEffort Node-Selectors: <none> Tolerations: <none> Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 52s default-scheduler Successfully assigned nginx to test-cluster-nd5c5y6lsfxb-minion-0 Normal SuccessfulMountVolume 51s kubelet, test-cluster-nd5c5y6lsfxb-minion-0 MountVolume.SetUp succeeded for volume "default-token-rp5ls" Normal Pulling 50s kubelet, test-cluster-nd5c5y6lsfxb-minion-0 pulling image "library/nginx:1.14-alpine" Normal Pulled 39s kubelet, test-cluster-nd5c5y6lsfxb-minion-0 Successfully pulled image "library/nginx:1.14-alpine" Normal Created 39s kubelet, test-cluster-nd5c5y6lsfxb-minion-0 Created container Normal Started 39s kubelet, test-cluster-nd5c5y6lsfxb-minion-0 Started container 

كما ترى ، بدأ Pod على عقدة باسم test-الكتلة-nd5c5y6lsfxb-minion-0 وتلقى عنوان IP داخليًا 10.100.88.9.

من قسم الأحداث ، يمكنك مشاهدة أحداث الإطلاق الرئيسية - تحديد عقدة لبدء الصورة وتنزيلها.

يمكننا الدخول إلى Pod والتحقق من حالة العمليات داخل الحاوية:

 $ kubectl exec -it nginx sh ps aux PID USER TIME COMMAND 1 root 0:00 nginx: master process nginx -g daemon off; 7 nginx 0:00 nginx: worker process 20 root 0:00 sh 24 root 0:00 ps aux exit 

يجب أن يؤخذ في الاعتبار أن عنوان IP 10.100.88.9 لن يكون متاحًا للتطبيقات الأخرى داخل وخارج مجموعة Kubernetes ، ولن يكون الوصول إلى Nginx قيد التشغيل ممكنًا إلا من داخل Pod نفسها:

 $ ping -c 1 10.100.88.9 PING 10.100.88.9 (10.100.88.9): 56 data bytes --- 10.100.88.9 ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss $ kubectl exec nginx -- ping -c1 10.100.88.9 PING 10.100.88.9 (10.100.88.9): 56 data bytes 64 bytes from 10.100.88.9: seq=0 ttl=64 time=0.075 ms --- 10.100.88.9 ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max = 0.075/0.075/0.075 ms 

بالإضافة إلى حقيقة أن عنوان IP المحدد يمكن الوصول إليه فقط من الحاوية ، فهو ليس دائمًا. هذا يعني أنه إذا تم إعادة إنشاء هذا Pod ، فيمكنه الحصول على عنوان IP مختلف.

لحل هذه المشاكل ، يمكنك استخدام كائن يسمى الخدمة.

الخدمات

تتيح لك الخدمة تعيين عناوين IP دائمة لل Pods ، وتزويدهم بالوصول من الشبكات الخارجية وتحقيق التوازن بين طلبات Pods.
يمكنك معرفة المزيد عن الخدمة في الوثائق الرسمية .

على سبيل المثال ، نحتاج إلى إزالة Pod تشغيل:

 $ kubectl delete pod nginx 

أضف إلى وصف Pod p تسمية (Label) المطلوبة للخدمة:

 # nginx-labeled.yaml apiVersion: v1 kind: Pod metadata: name: nginx labels: app: webservice spec: containers: - name: nginx image: library/nginx:1.14-alpine ports: - containerPort: 80 

سنحتاج أيضًا إلى وصف للخدمة:

 # nginx-nodeport.yaml apiVersion: v1 kind: Service metadata: name: nginx-nodeport labels: app: webservice spec: type: NodePort ports: - port: 80 nodePort: 30001 protocol: TCP selector: app: webservice 

إنشاء بود وخدمة:

 $ kubectl create \ -f https://raw.githubusercontent.com/selectel/kubernetes-examples/master/pods/nginx-labeled.yaml \ -f https://raw.githubusercontent.com/selectel/kubernetes-examples/master/services/nginx-nodeport.yaml 

نظرًا لأن الخدمة التي تم إنشاؤها هي من نوع NodePort ، فسيتم فتح المنفذ 30001 الذي أشرنا إليه في جميع واجهات الشبكة على جميع عُقد المجموعة.
هذا يعني أنه إذا أضفنا عنوان IP خارجيًا إلى أي عقدة ، فيمكننا الوصول إلى Pod العاملة باستخدام Nginx من شبكة خارجية.

من أجل عدم استخدام العناوين الخارجية لعقد الكتلة للوصول إلى الخدمة ، يمكننا استخدام نوع LoadBalancer بدلاً من NodePort.
سنحتاج إلى وصف جديد للخدمة:

 # nginx-loadbalancer.yaml apiVersion: v1 kind: Service metadata: name: nginx-loadbalancer labels: app: webservice spec: type: LoadBalancer ports: - port: 80 protocol: TCP selector: app: webservice 

احذف الخدمة الحالية وقم بتطبيق الوصف الجديد:

 $ kubectl delete service nginx-service $ kubectl create \ -f https://raw.githubusercontent.com/selectel/kubernetes-examples/master/services/nginx-loadbalancer.yaml 

بعد بدء الخدمة ، ستتوفر Nginx على منفذ TCP 80 من شبكة خارجية ، ولن تكون هناك حاجة لتعيين واستخدام عناوين خارجية لعقد نظام المجموعة. ستقوم الخدمة من النوع LoadBalancer تلقائيًا بتخصيص عنوان خارجي جديد لمشروع VPC الخاص بك وبدء استخدامه.

يمكنك الحصول على معلومات حول العنوان الخارجي المميز باستخدام kubectl:

 $ kubectl get service nginx-service -o=custom-columns=IP:status.loadBalancer.ingress[0].ip IP xxx.xxx.xxx.xxx 

في أمثلةنا ، تم إطلاق Pod واحد فقط مع Nginx. لتوسيع نطاق التطبيق إلى عدد أكبر من Pods ، يمكننا استخدام النشر.

عمليات النشر

النشر هو جوهر مجموعة Kubernetes ، والذي يسمح لك بتوسيع Pods وتحديث الإصدارات بسهولة أو استرجاعها لعدد كبير من Pods.
بدلاً من النشر ، يمكنك أيضًا استخدام كائن ReplicaSet ، لكننا لن نتطرق إليه في أمثلةنا.
يمكنك معرفة المزيد حول النشر في الوثائق الرسمية .

سنحتاج مرة أخرى إلى إزالة Pod (لا نحتاج إلى إزالة الخدمة):

 $ kubectl delete pod nginx 

أضف وصف النشر التالي:

 # nginx-1.14.yaml apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 10 selector: matchLabels: app: webservice minReadySeconds: 10 strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 1 maxSurge: 1 template: metadata: labels: app: webservice spec: containers: - name: nginx image: library/nginx:1.14-alpine ports: - containerPort: 80 

إنشاء النشر المحدد:

 $ kubectl create -f \ https://raw.githubusercontent.com/selectel/kubernetes-examples/master/deployments/nginx-1.14.yaml 

اخترنا 10 لمعلمة النسخ المتماثلة ، لذلك سيتم إنشاء 10 Pods مع تطبيق Nginx في مجموعتنا:

 $ kubectl get pods --selector app=webservice NAME READY STATUS RESTARTS AGE nginx-deployment-54bfdc4489-42rrb 1/1 Running 0 4m nginx-deployment-54bfdc4489-5lvtc 1/1 Running 0 4m nginx-deployment-54bfdc4489-g7rk2 1/1 Running 0 4m nginx-deployment-54bfdc4489-h5rxp 1/1 Running 0 4m nginx-deployment-54bfdc4489-l9l2d 1/1 Running 0 4m nginx-deployment-54bfdc4489-pjpvg 1/1 Running 0 4m nginx-deployment-54bfdc4489-q8dnp 1/1 Running 0 4m nginx-deployment-54bfdc4489-s4wzf 1/1 Running 0 4m nginx-deployment-54bfdc4489-tfxf9 1/1 Running 0 4m nginx-deployment-54bfdc4489-xjzb5 1/1 Running 0 4m 

يمكنك الوصول إلى التطبيق الجاري تشغيله من الشبكة الخارجية باستخدام الخدمة التي تم إنشاؤها في القسم السابق. ستوازن الخدمة تلقائيًا بين الطلبات الواردة من الشبكة الخارجية وبين 10 مثيلات Nginx.

إذا لزم الأمر ، يمكننا تحديث إصدار Nginx. تحديث وصف النشر بتغيير إصدار الصورة من 1.14-alpine إلى 1.15-alpine:

 # nginx-1.15.yaml apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 10 selector: matchLabels: app: webservice minReadySeconds: 10 strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 1 maxSurge: 1 template: metadata: labels: app: webservice spec: containers: - name: nginx image: library/nginx:1.15-alpine # <-- changed ports: - containerPort: 80 

لبدء عملية تحديث Pods ، نستخدم الأمر kubectl. انتبه إلى الحجة - سجل ، من المفيد لنا التراجع المريح اللاحق لإصدار Nginx:

 $ kubectl apply -f \ https://raw.githubusercontent.com/selectel/kubernetes-examples/master/deployments/nginx-1.15.yaml \ --record 

يمكنك مراقبة تقدم التحديث باستخدام الأمر التالي:

 $ kubectl rollout status deployment nginx-deployment Waiting for rollout to finish: 4 out of 10 new replicas have been updated... 

ستنتظر Kubernetes 10 ثوانٍ بعد التحديث الناجح لقرص صوتي واحد ، حيث حددنا قيمة 10 لمعلمة minReadySeconds في وصف النشر.

بعد اكتمال التحديث ، ستصبح كل Pods للنشر في حالة نشطة:

 $ kubectl get deployment --selector app=webservice NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE nginx-deployment 10 10 10 10 23m 

يمكننا التراجع عن إصدار التطبيق إذا حدث خطأ ما. للقيام بذلك ، نحتاج إلى تحديد مراجعة النشر المطلوبة:

 $ kubectl rollout history deployment nginx-deployment deployments "nginx-deployment" REVISION CHANGE-CAUSE 1 <none> 2 kubectl apply --filename=https://raw.githubusercontent.com/selectel/kubernetes-examples/master/deployments/nginx-1.15.yaml --record=true 

هناك تنقيحتان في إخراج الأمر - الأول هو الإنشاء الأولي للنشر ، والثاني تحديث. نظرًا لأننا استخدمنا الوسيطة --record عند التحديث ، فإننا نرى الأمر الذي أنشأ المراجعة الثانية للنشر.

لتراجع النسخة ، استخدم الأمر التالي:

 $ kubectl rollout undo deployment nginx-deployment --to-revision=1 

وبالمثل مع التحديث ، يمكننا مراقبة التراجع عن الإصدار باستخدام الأمر:

 $ kubectl rollout status deployment nginx-deployment Waiting for rollout to finish: 6 out of 10 new replicas have been updated… 

في جميع أمثلةنا ، استخدمنا حاويات بدون مخزن بيانات مستمر. في القسم التالي سنقوم بإصلاحه.

تخزين البيانات

بشكل افتراضي ، تكون جميع البيانات من الحاويات التي تعمل داخل Pods زائلة وستفقد عند تحطم Pods.

يمكنك استخدام كائن PersistentVolumeClaim لتشغيل Pods مع مستودع بيانات مستمر.

إن إنشاء مثل هذا الكائن في مجموعة أمر بسيط للغاية - ما عليك سوى إضافة وصفه ، على غرار الطريقة التي أنشأنا بها Pod أو Service أو Deployment في الأقسام السابقة.

يمكن العثور على مزيد من المعلومات في الوثائق الرسمية .

مثال على وصف PersistentVolumeClaim لإنشاء قرص 10 جيجا بايت:

 apiVersion: v1 kind: PersistentVolumeClaim metadata: name: my-pv-claim spec: accessModes: - ReadWriteOnce resources: requests: storage: 10Gi 

يمكننا توصيله كقرص إلى Pod من خلال تحديث وصف Pod مع Nginx الذي تم إنشاؤه سابقًا:

 # nginx-with-volume.yaml apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - name: nginx image: library/nginx:1.14-alpine ports: - containerPort: 80 volumeMounts: - mountPath: "/var/www/html" name: data volumes: - name: data persistentVolumeClaim: claimName: my-pv-claim 

ومع ذلك ، من أجل إنشاء القرص ، تحتاج إلى تحديد خصائص القرص الذي تم إنشاؤه في شكل StorageClass. في خدمة "Virtual Private Cloud" ، يمكنك استخدام محركات أقراص الشبكة من الأنواع السريعة والعامة والأساسية كمخزن دائم لبيانات Kubernetes Pod.

على سبيل المثال ، لإنشاء StorageClass الذي يسمح لك باستخدام الأقراص السريعة في منطقة توفر ru-1b ، تحتاج إلى الوصف التالي:

 # fast.ru-1b.yaml kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: fast.ru-1b annotations: storageclass.beta.kubernetes.io/is-default-class: "true" provisioner: kubernetes.io/cinder parameters: type: fast.ru-1b availability: ru-1b 

قبل إنشاء الكائنات المحددة ، احذف النشر الذي تم إنشاؤه سابقًا:

 $ kubectl delete deployment nginx-deployment 

بادئ ذي بدء ، دعنا ننشئ StorageClass ، لذلك ستصبح الفئة الافتراضية ، وسيستخدمها PersistentVolumeClaim الذي تم إنشاؤه لاحقًا:

 $ kubectl create -f \ https://raw.githubusercontent.com/selectel/kubernetes-examples/master/storageclasses/fast.ru-1b.yaml 

إنشاء PersistentVolumeClaim and Pod:

 $ kubectl create \ -f https://raw.githubusercontent.com/selectel/kubernetes-examples/master/persistentvolumeclaims/my-pv-claim.yaml \ -f https://raw.githubusercontent.com/selectel/kubernetes-examples/master/pods/nginx-with-volume.yaml 

بعد ذلك ، سيتم إنشاء قرص تلقائيًا في مشروعك سيتم توصيله بإحدى عقد العميل في المجموعة. عندما يسقط ، يتحول القرص تلقائيًا إلى عقدة أخرى.

يمكننا رؤية القرص داخل الحاوية باستخدام Nginx:

 $ kubectl exec -it nginx sh mount | grep "/var/www/html" /dev/sdc on /var/www/html type ext4 (rw,seclabel,relatime,data=ordered) exit 

يمكنك توصيل محرك الأقراص بالنشر. يمكن العثور على مثال مطابق في الوثائق الرسمية .

لوحة تحكم Kubernetes

يمكنك استخدام لوحة التحكم المدمجة في Kubernetes نفسها لعرض حالة كائنات العنقود وإدارتها.

للوصول إلى جميع ميزات اللوحة ، ستحتاج إلى إنشاء حساب مع دور المسؤول في مجموعتك.

للقيام بذلك ، نحتاج إلى وصف الحساب:

 # admin-user.yaml apiVersion: v1 kind: ServiceAccount metadata: name: admin-user namespace: kube-system 

ووصف الدور:

 # cluster-admin.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: admin-user roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-admin subjects: - kind: ServiceAccount name: admin-user namespace: kube-system 

إنشاء الكائنات المحددة:

 $ kubectl create \ -f https://raw.githubusercontent.com/selectel/kubernetes-examples/master/accounts/admin-user.yaml \ -f https://raw.githubusercontent.com/selectel/kubernetes-examples/master/clusterrolebindings/cluster-admin.yaml 

بعد ذلك ، ستحتاج إلى معرفة قيمة الرمز المميز الذي تم إنشاؤه لهذا الحساب.
للقيام بذلك ، ابحث عن الكائن السري المقابل في المجموعة:

 $ kubectl get secret --namespace=kube-system | grep "admin-user-token" admin-user-token-bkfhb kubernetes.io/service-account-token 3 22m 

وإلقاء نظرة على قيمة الرمز المميز للسر الموجود باسم admin-user-token-bkfhb:

 $ kubectl describe secret admin-user-token-bkfhb --namespace=kube-system | grep "token:" token: XXXXXX... 

ردًا على ذلك ، ستتلقى قيمة الرمز المميز ، احفظه ، سيكون مفيدًا لنا في المستقبل.
للحصول على تفاصيل التحكم في الوصول لكائنات Kubernetes ، راجع الوثائق الرسمية .

في حالة إنشاء مجموعة من قالب عام ، فإن Pod and Service موجودان بالفعل فيه لضمان تشغيل اللوحة:

 $ kubectl get svc kubernetes-dashboard --namespace=kube-system 206ms Tue Jun 19 14:35:19 2018 NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes-dashboard ClusterIP 10.254.122.245 <none> 443/TCP 2d $ kubectl get pod --namespace=kube-system --selector k8s-app=kubernetes-dashboard 119ms Tue Jun 19 14:36:48 2018 NAME READY STATUS RESTARTS AGE kubernetes-dashboard-747575c864-jpxvt 1/1 Running 0 2d 

نظرًا لأن الخدمة من نوع ClusterIP ، فلن تتوفر إلا من داخل المجموعة نفسها.
يمكنك الوصول إلى اللوحة من الكمبيوتر العامل باستخدام ملف تكوين الكتلة باستخدام الأمر kubectl:

 $ kubectl proxy Starting to serve on 127.0.0.1:8001 

اختبر الوكيل عن طريق فتح العنوان المحدد في المتصفح:

إذا رأيت إجابة شبيهة بلقطة الشاشة ، فيمكنك الانتقال إلى شاشة لوحة التحكم باستخدام العنوان التالي:

 http://127.0.0.1:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/ 

من خلال ذلك ، يجب أن تشاهد شاشة تسجيل الدخول في اللوحة:

ستحتاج إلى تحديد الرمز المميز الذي تم تلقيه سابقًا. بعد تسجيل الدخول ، يمكنك استخدام لوحة التحكم:

يمكنك التعرف على جميع ميزات لوحة التحكم في الوثائق الرسمية .

مراقبة كائنات Kubernetes

إذا كنت تستخدم قالب الكتلة العام ، فستقوم تلقائيًا بتشغيل مكونات جمع وعرض المقاييس - Prometheus و Grafana.

على غرار لوحة التحكم ، يتم تثبيت ClusterIP كنوع الخدمة ؛ ولا يمكن الوصول إليه إلا من داخل المجموعة أو من خلال وكيل kubectl. يمكنك الوصول إلى Grafana من كمبيوتر العمل الخاص بك على العنوان التالي:

 http://127.0.0.1:8001/api/v1/proxy/namespaces/kube-system/services/monitoring-grafana:80 

الخلاصة

في هذه المقالة ، قمنا بفحص كائنات Kubernetes الأكثر استخدامًا ونظرنا في أمثلة على بدء وإدارة مجموعة باستخدام OpenStack Magnum.

في المستقبل القريب ، سيكون من الممكن استخدام أحدث إصدارات Kubernetes ، وستكون إدارة المجموعة متاحة من خلال لوحة التحكم .

سنكون سعداء إذا استخدمت خدمتنا في وضع الاختبار وقدمت ملاحظات.