وقتی ما دستور kubectl را اجرا می کنیم، در واقع آن دستور تبدیل به فراخوانی REST API می شود و به kube API Server ارسال می شود.
پارامترهای ورودی تبدیل به json شده و به kube API Server ارسال می شوند و نتیجه نیز بصورت json برگردانده می شود.
Resource: هر چیزی که کوبرنتیز مدیریت می کند، یک Resource است مانند Node و Pod و Service
API Group: دسته ای از API ها که یک حیطه کاری را انجام می دهند جزو یک API Group هستند.
API Versioning:
1.Alpha (Example: V1Alpha1)
نسخه ای است که هنوز به طور کامل تست نشده است و ممکن است دارای Bug باشد. ممکن است این نسخه در آینده کلا حذف شود. در محیط product به هیچ وجه نباید از نسخه های alpha استفاده شود.
2.Beta (Example: V1Beta1)
نسخه ای است که تست اولیه شده است. در آینده حذف نخواهد شد. مانند نسخه آلفا از نسخه بتا نیز نباید در محیط product استفاده شود.
3.Stable (Example: V1)
نسخه پایدار است که بصورت کامل تست شده و Bug های آن برطرف شده است.
فرمت فراخوانی:
GET /api/GROUP/VERSION/RESOURCETYPE
*توجه: اگر GROUP وارد نشود، مقدار پیش فرض آن یعنی core در نظر گرفته می شود.
برای فراخوانی مستقیم API های kubernetes، ابتدا باید یک پروکسی بالا بیاوریم. با دستور زیر یک پروکسی کوبرنتیز ایجاد می شود:
kubectl proxy --port=8080
حالا می توانیم از طریق پروکسی ایجاد شده، APIهای کوبر را فراخوانی کنیم:
# گرفتن لیست پادها curl http://127.0.0.1:8080/api/v1/pods # گرفتن لیست پادها و ذخیره خروجی در فایل curl http://127.0.0.1:8080/api/v1/pods > pods.json
# get pods in kube-system namespace by kubectl command kubectl get po -n kube-system # get pods in kube-system namespace by kube API curl http://127.0.0.1:8080/api/v1/namespaces/kube-system/pods
kubectl api-resources | more
[root@MASTER-01 ~]# kubectl api-resources | more NAME SHORTNAMES APIVERSION NAMESPACED KIND bindings v1 true Binding componentstatuses cs v1 false ComponentStatus configmaps cm v1 true ConfigMap endpoints ep v1 true Endpoints events ev v1 true Event limitranges limits v1 true LimitRange namespaces ns v1 false Namespace nodes no v1 false Node persistentvolumeclaims pvc v1 true PersistentVolumeClaim persistentvolumes pv v1 false PersistentVolume pods po v1 true Pod podtemplates v1 true PodTemplate ...
برای اینکه نیاز نباشد ما دستورات kubernetes را حفظ بکنیم و به راحتی از دستورات استفاده کنیم، باید bash-completion را نصب کنیم.
yum -y install bash-completion kubectl completion bash | sudo tee /etc/bash_completion.d/kubectl > /dev/null sudo chmod a+r /etc/bash_completion.d/kubectl
حالا هنگام نوشتن دستورات kubectl، هر کجا که نیاز داشته باشیم می توانیم با زدن tab پیشنهادات موجود در ادامه دستور را مشاهده کنیم.
* ابزارهایی مانند Rancher ، Lenz و غیره از Kube API برای ارتباط با کوبر استفاده می کنند.*
کوچکترین واحد قابل Deploy روی کلاستر kubernetes پاد می باشد.
پاد مجموعه ای از یک یا چند Container هست که storage و network مشترکی دارند و Namespace آنها یکی است.
یعنی هر پاد و همه کانتینرهای داخل آن یک IP دارند. همچنین اگر ما پوشه ای را داخل پاد یا داخل یکی از کانتینرهای آن بسازیم، همه کانتینرهای داخل پاد به آن پوشه دسترسی خواهند داشت.
Manifest هر پاد در فایل yaml نوشته می شود و چهار بخش دارد:
apiVersion:
kind:
metadata:
spec:
apiVersion و kind مربوط به پاد را با دستور زیر می توانیم بدست آوریم:
kubectl api-resources | grep pods
[root@MASTER-01 ~]# kubectl api-resources | grep pods pods po v1 true Pod
اطلاعاتی که در هر بخش نوشته می شوند به شرح زیر هستند:
apiVersion: [نسخه پاد] kind: Pod metadata: name: [نام پاد] namespace: [نام namespace] spec: containers: //مشخصات کانتینرهای پاد - name: [نام کانتینر] image: [image کانتینر] imagePullPolicy: [ifNotPresent/Always/Never]
مثال:
apiVersion: v1 kind: Pod metadata: name: webserver namespace: default spec: containers: - name: nginx image: nginx:latest imagePullPolicy: ifNotPresent
بعد از تهیه فایل manifest پاد، آن را در کلاستر کوبرنتیز apply می کنیم.
kubectl apply -f pod.yaml
CrashLoopBackup:
وقتی یک پاد در وضعیت Pending است، کوبر دائما تلاش می کند که آن را به وضعیت Running ببرد. اگر بعد از تعدادی تلاش، کوبر نتواند پاد را اجرایی کند مثلا اگر نتواند image آن را دانلود کند، وضعیت پاد را به CrashLoopBackup تغییر می دهد. در وضعیت CrashLoopBackup کوبر همچنان از تلاش برای اجرای پاد دست نمی کشد ولی بازه های زمانی تلاش مجدد خود را طولانی تر می کند.
Container Phases (Lifecycle):
1.Running
2.Waiting
3.Terminated
وضعیت پاد تابعی است از وضعیت کانتینر.
Pod Canditions:
PodReadyToStartContainers (True/False)
Initialized (True/False)
Ready (True/False)
ContainersReady (True/False)
PodScheduled (True/False)
وقتی دستور kubectl apply را اجرا می کنیم، کانتینر و پاد روی نود worker بالا می آید. یعنی فایلهای image و کانتینر روی Pod دانلود می شود و نیازی به دانلود آنها روی نودهای master نیست.
حذف پاد:
Kubectl delete -f pod.yaml --force Kubectl delete po webserver --force
اجرای دستور bash داخل پادی با نام webserver:
Kubectl exec -it webserver -- bash حالا داخل پاد هستیم ls -l
* قاعدتا ما نباید نیازی به این کار داشته باشیم؛ مگر در حالتهای خاص برای troubleshooting.
اگر روی یک پاد چند کانتینر وجود داشته باشد موقع اجرای کامند exec باید مشخص کنیم که منظورمان کدام کانتینر است. در غیر این صورت کوبرنتیز خودش یکی از کانتینرها را به عنوان پیش فرض انتخاب کرده و داخل آن می شود.
Kubectl exec -it -n time-namespace time-pod -c nginx-container -- bash
مشاهده 200 خط آخر لاگی که برنامه نویس روی کنسول write کرده است:
Kubectl logs --tail 200 -f webserver
ابزارهایی وجود دارند که کنسول برنامه را خوانده و در ابزارهای ذخیره لاگ، ذخیره می کند. بنابراین فقط کافی است که برنامه نویس لاگهای خود را با یک فرمت استاندارد مثلا json در کنسول write کند.
دریافت اطلاعات پاد:
Kubectl get po redis
Export فایل yaml از پاد:
Kubectl get po redis -o yaml > redis.yaml
فایل yaml خروجی، شامل برخی اطلاعات اضافی هست که مختص همین پادی است که در حال اجراست. برای ایجاد یک پاد دیگر از روی این فایل yaml، باید اطلاعات اضافی حذف شوند.
کانتینری است که قبل از کانتینر اصلی بالا می آید و بعد از اینکه terminate شد، کانتینر اصلی بالا می آید. در حالتهایی که بخواهیم قبل از اجرای کانتینر اصلی یک کانتینر اجرا شود و دیتاهای اولیه را برای کانتینر اصلی فراهم کند، از initContainer استفاده می کنیم.
یک پاد می تواند چند initContainer و چند کانتینر اصلی داشته باشد.
نحوه تعریف initContainer در فایل manifestمانند کانتینر اصلی است.
apiVersion: v1 kind: Pod metadata: name: webserver spec: containers: - name: nginx image: nginx:1.14.2 imagePullPolicy: IfNotPresent initContainers: - name: init-service1 image: busybox:1.28 command: [ “sleep”, “10”] - name: init-service2 image: busybox:1.28 command: [ “sleep”, “10”]
اگر خطایی در اجرای initContainer رخ دهد، کانتینر اصلی اجرا نمی شود.
فرق initContainer و multiContainer در این است که initContainer ها ابتدا اجرا می شوند و بعد از اتمام کار آنها، کانتینرهای اصلی اجرا می شوند ولی در یک پاد multiContainer همه کانتنرها باهم اجرا می شوند.
کاربرد multiContainer در دو حالت زیر می باشد:
1. Sidecar
در sidecar، کانتینرها موازی با هم اجرا می شوند. از این حالت عمدتا برای لاگ گیری و مانیتورینگ استفاده می شود.
مثال: ما یک اپلیکیشن داشته باشیم که کار خود را انجام دهد و لاگ ها را در کنسول بنویسد. همزمان یک اپلیکیشن دیگر هم نیاز داشته باشیم که لاگ ها را بخواند و به یک لاگ سرور مانند Fluend ارسال کند. یعنی ما نمیخواهیم اپلیکیشن اصلی درگیر نحوه ارسال و ذخیره لاگ شود.
2. Ambassador
از این حالت عمدتا برای proxy و کنترل ترافیک استفاده می کنند.
مثال: ما یک اپلیکیشن داریم که میخواهیم قبل از اینکه درخواستها به آن برسند، درخواستها از یک پروکسی مانند envoy رد شوند و از این طریق قوانین و محدودیتهایی را برای مسیریابی و دسترسی اعمال نماییم.
منابع:
https://kubernetes.io/docs/concepts/workloads/pods/init-containers/
