چگونه با Kubernetes در GKE شروع کردم

در این قسمت ما بر روی نصب دو ابزار gcloud و راه اندازی اولین کلاستر GKE تمرکز خواهیم کرد. برای راه اندازی ابزارهای gcloud در CLI محلی خود می توانید از طریق این راهنما بروید. پس از ایجاد یک حساب کاربری GKE، اولین قدم ایجاد یک کلاستر خواهد بود. برای انجام این کار، می‌توانیم به سادگی از طریق رابط کاربری گرافیکی GKE برویم، دکمه «Create Cluster» را فشار داده و از طریق ویزارد عبور کنیم. اکنون که یک خوشه داریم، بیایید اعتبار آن را بگیریم تا بتوانیم زمینه Kubernetes را روی آن خوشه در CLI محلی خود تنظیم کنیم. برای این کار می توانیم اجرا کنیم:

1
gcloud container clusters get-credentials CLUSTER --zone ZONE --project PROJECT

کجا CLUSTER نام خوشه وZONE ناحیه ای که هنگام پر کردن جادوگر انتخاب کردیم و PROJECT شناسه پروژه ما

در مرحله بعد، در منوی Docker برای Mac، باید بتوانیم نام خوشه خود را در لیست زمینه در زیر “Kubernetes” ببینیم:

اگر روی آن کلیک کنیم، تمام دستورات بعدی Kubernetes که اجرا می کنیم در مقابل خوشه GKE ما اجرا می شوند. مثلاً اگر بخواهیم اجرا کنیم kubectl get pods، باید ببینیم که (هنوز) هیچ منبعی در این خوشه نداریم.

در مرحله بعد، اولین بارهای کاری خود را در کلاسترهای GKE خود مستقر خواهیم کرد. اگر با Kubernetes تازه کار هستید، اینجاست که همه چیز کمی پیچیده می شود، اما من تمام تلاشم را می کنم تا واژگان لازم را به شما معرفی کنم. در اینجا انواع مختلفی از بارهای کاری وجود دارد که ما در کلاستر خود اجرا خواهیم کرد:

• زیر: گروهی از کانتینرهای در حال اجرا. این کوچکترین و ساده ترین شی Kubernetes است که ما با آن کار خواهیم کرد.

• استقرار: یک شی Kubernetes که کپی های Pods را مدیریت می کند.

• خدمات: یک شی Kubernetes که پورت ها، بار متعادل کننده ها و نحوه دسترسی به برنامه ها را توصیف می کند.

• ورود: یک شی Kubernetes که دسترسی خارجی به سرویس های خوشه ای را از طریق HTTP مدیریت می کند.

اگر هنوز به اندازه کافی اعتماد به نفس ندارید، توصیه می کنم این آموزش عالی را برای شروع کار با اصول اولیه بررسی کنید: https://kubernetes.io/docs/tutorials/kubernetes-basics/.

بارهای کاری Kubernetes معمولاً با فایل‌های YAML توصیف می‌شوند، که می‌توان آن‌ها را تقریباً همانطور که دوست داریم سازمان‌دهی کرد. ما حتی می توانیم چندین نوع بار کاری Kubernetes را در یک فایل YAML ایجاد کنیم.
به عنوان مثال، در اینجا یک فایل YAML حاوی تعریف اولین بارهای کاری است که در خوشه Kubernetes خود مستقر خواهیم کرد:

1
apiVersion: apps/v1beta1
18
    imagePullPolicy: "Always"

توجه داشته باشید: اولین باری که این حجم کاری را از قسمت “نوع” سرویس مستقر کردم بسیار گیج شدم، سپس این مقاله شگفت انگیز را خواندم که همه چیز را برای من پاک کرد: https://medium.com/@pczarkowski/kubernetes-services-exposed-86d45c994521

بیایید فایل فوق را در دستگاه خود ذخیره کنیم و این بارهای کاری را با اجرای: kubectl apply -f PATH/FILENAME.yml. استقرار نباید بیش از چند ثانیه طول بکشد و سپس می توانیم بررسی کنیم که همه بارهای کاری ما واقعاً مستقر شده اند. اجرا کنید kubectl get TYPE، جایی که نوع هر یک از انواع Kubernetes است که در بالا تعریف کردیم، به عنوان مثال. kubectl get pods، برای فهرست کردن همه بارهای کاری Kubernetes از یک نوع معین. اگر می خواهید در مورد آنها بیشتر بدانید، می توانید اجرا کنید kubectl describe TYPE NAME، به عنوان مثال kubectl describe service website.

با برشمردن خدمات، باید به نتیجه ای مشابه این برسیم:

ما می توانیم آن را ببینیم بندر 8000 خدمات ما به بندر نگاشت شده است **31508** در یکی از گره های ما در خوشه ما، اما گره های GKE به طور پیش فرض در دسترس خارجی نیستند، بنابراین سرویس وب سایت ما (هنوز) از طریق اینترنت قابل دسترسی نیست. اینجا کجاست وارد می شود وارد تصویر می شود

در اینجا ما یک Ingress برای دسترسی به سرویس وب سایت خود از اینترنت ایجاد می کنیم. حجم کاری Ingress اساسا شامل مجموعه ای از قوانین برای هدایت ترافیک به سرویس ما است.
برای مثال می توانیم موارد زیر را در فایلی به نام قرار دهیم ingress.yml:

1
apiVersion: extensions/v1beta1

اگر اجرا کنیم kubectl apply -f ingress.yml، ما قانونی ایجاد می کنیم تا تمام ترافیک HTTP خارجی که به آدرس IP ورودی خارجی ما می رسد به وب سایت ما هدایت شود. اگر چند دقیقه صبر کنیم، می بینیم که کار می کند kubectl get ingress لیستی حاوی main-ingress با IP خارجی:

دسترسی به IP خارجی از مرورگر شما باید صفحه اصلی NGINX را به شما نشان دهد! ما به تازگی اولین بار کاری Kubernetes خود را مستقر، افشا و منتشر کرده ایم!

اما صبر کنید، چیزهای بیشتری وجود دارد: ما در واقع می توانیم از این ورودی برای متعادل کردن بار با افزودن قوانین خاص تر استفاده کنیم. فرض کنید ما فقط دامنه خود را می خواهیم myawesomedomain.com برای دسترسی به خدمات در وب سایت ما، ممکن است مجموعه ای از قوانین را اضافه کنیم:

1
apiVersion: extensions/v1beta1
7
    - host: myawesomedomain.com

حالا اگر اجرا کنیم kubectl apply -f ingress.yml پس از ذخیره محتوای بالا در ما ingress.yml فایل و نام دامنه ما را مشخص کنید myawesomedomain.com به IP خارجی Ingress ما، می توانید به سرویس وب سایت خود با آن دامنه دسترسی پیدا کنید.

هنگامی که چندین سرویس میزبانی در یک کلاستر دارید، Ingress ها بسیار راحت هستند. را ingress.yml فایلی که من در حال حاضر برای پروژه های شخصی خود استفاده می کنم به شکل زیر است:

1
apiVersion: extensions/v1beta1
7
    - host: myawesomedomain.com
13
    - host: test.myawesomedomain.com
17
      serviceName: testwebsite
19
    - host: hello.myawesomedomain.com

به لطف Ingress خود، ما اکنون یک راه آسان برای هدایت ترافیک به سرویس های خاص با صرفاً اعلام قوانین در یک فایل YAML و استقرار آن در کلاستر داریم.

اکنون که خدمات خود را برای Kubernetes منتشر کرده‌ایم، گام بعدی دریافت گواهی‌های SSL است که برای خدمات ما کار می‌کنند. این است که بتوان به آن رسید [https://myawesomedomain.com](https://myawesomedomain.com,)، [https://test.myawesomedomain.com](https://test.myawesomedomain.com)و غیره. در هاست میکروسرویس قبلی خود، یک نسخه کانتینری ساخته شده خانگی از HAProxy را اجرا می کردم که از من درخواست می کرد. بیایید رمزگذاری کنیم گواهینامه ها (رایگان هستند!) و خودم آنها را برای من تمدید کنم. بسیار مفید است زیرا نمی‌خواستم هر 90 روز یکبار آنها را به‌طور دستی تمدید کنم.

من مجبور شدم مدت زیادی به اطراف نگاه کنم و چندین پروژه را امتحان کنم، مانند Kube-lego که قبلاً رد شده بود، قبل از اینکه به راه حلی برسم که برای من کارساز بود: kube-cert-manager. این پروژه دقیقاً همان چیزی است که من نیاز داشتم: “تامین خودکار و مدیریت گواهینامه های TLS در Kubernetes”.

به عنوان اولین گام باید a را پیاده سازی کنیم NGINX-Ingress-Controller برای GKE. این Ingress Controller اساساً حجم کاری Ingress را مصرف می کند و ترافیک ورودی آن را هدایت می کند. پس از کلون سازی مخزن، باید موارد زیر را انجام دهیم:

اکنون یک سرویس Load Balancer داریم که به تمام ترافیک ورودی در پورت 80 (برای ترافیک HTTP) و 443 (برای ترافیک HTTPS) با یک آدرس IP خارجی گوش می دهد. از همه Ingresses در خوشه ما برای مسیریابی ترافیک، از جمله ترافیک ما استفاده می کند main-ingress.

سپس ما باید مستقر شویم kube-cert-manager. درست مانند کاری که برای Ingress Controller انجام دادیم، قبل از استقرار پروژه باید چند ویرایش انجام دهیم:

2
  - name: kube-cert-manager
4
    - name: DNSIMPLE_BASE_URL
5
      value: [https://api.dnsimple.com](https://api.dnsimple.com)
6
    - name: DNSIMPLE_OAUTH_TOKEN
7
      value: myrequestedoauthtoken

بالاخره دویدنcd gke-kube-cert-manager && ./deploy.sh مدیر گواهی را راه اندازی و در خوشه شما مستقر می کند.

اکنون بخش سرگرم کننده اینجاست: تمام این تنظیمات به ما امکان می دهد ایجاد کنیم Certificate حجم کاری Kubernetes هر گواهی ایجاد شده در این خوشه توسط آن گرفته شده و درخواست (و تمدید) خواهد شد kube-cert-manager استقرار بیایید یکی برای ایجاد کنیم myawesomedomain.com در فایلی به نام certificates.yml:

1
apiVersion: 'stable.k8s.psg.io/v1'
7
    stable.k8s.psg.io/kcm.class: 'kube-cert-manager'
9
  domain: 'myawesomedomain.com'

در حال اجرا kubectl apply -f certificates.yml درخواست را به Let’s Encrypt ارسال می کند و یک راز TLS برای کنترل کننده ورودی NGINX ما ایجاد می کند تا از آن استفاده کند. می‌توانیم لاگ‌های kube-cert-manager Pod را بررسی کنیم kubectl logs -f nameofyourcertmanagerpodpod در حین درخواست و اگر همه چیز خوب پیش رفت، باید لاگ هایی مانند این را ببینیم:

پس از چند دقیقه، همانطور که در گزارش های بالا نشان داده شده است، باید یک راز با عنوان داشته باشیم myawesomedomain.com روی خوشه ما بدویم kubectl get secrets برای اطمینان از وجود آن قبل از ادامه ما در نهایت می توانیم مال خود را اکنون ویرایش کنیم ingress.yml فایل به این صورت برای شامل گواهی ما:

1
apiVersion: extensions/v1beta1
6
  kubernetes.io/ingress.class: 'nginx'
9
    - host: myawesomedomain.com
17
    - secretName: myawesomedomain.com

حالا بیایید فرار کنیم kubectl apply -f ingress.yml برای به روز رسانی ما main-ingress برای حمایت از رازی که قبلا ایجاد کردیم. بعد از آن فقط باید مطمئن باشیم myawesomedomain.com به IP خارجی کنترلر دروازه NGINX ما اشاره می کند و پس از مدتی سرویس وب سایت ما از طریق HTTPS در دسترس خواهد بود!

می بینیم که در این مرحله ما یک راه کاملا محکم و آسان برای افزودن سرویس های جدید به خوشه خود، مقیاس بندی آنها، هدایت ترافیک به آنها به لطف آنچه در قسمت های II و III آموختیم و افزودن گواهینامه ها به دامنه های مربوطه با درخواست و تمدید خودکار آنها به لطف kube-cert-manager داریم.

منابعی که هنگام شروع کار با Kubernetes استفاده کردم