ProHoster > بلاګ > اداره > لږ تر لږه د وړ وړ Kubernetes

لږ تر لږه د وړ وړ Kubernetes

د مقالې ژباړه د کورس د پیل په ماښام چمتو شوې وه "DevOps کړنې او وسیلې".

لږ تر لږه د وړ وړ Kubernetes

که تاسو دا لوستل کوئ، تاسو شاید د کوبرنیټس په اړه یو څه اوریدلي وي (او که نه، تاسو دلته څنګه پای ته رسیدلي؟) مګر په حقیقت کې کوبرنیټس څه شی دی؟ دا "د صنعتي درجې کانتینرونو آرکیسټریشن"؟ یا "د کلاوډ اصلي عملیاتي سیسټم"؟ دا حتی څه معنی لري؟

د ریښتیني کیدو لپاره ، زه 100٪ ډاډه نه یم. مګر زه فکر کوم چې دا په زړه پورې ده چې داخلي ته وګورو او وګورو چې واقعیا په کبرنیټس کې د دې ډیری خلاصونو پرتونو لاندې څه پیښیږي. نو یوازې د ساتیرۍ لپاره ، راځئ یو نظر وګورو چې لږترلږه "کوبرنیټس کلسټر" واقعیا څه ډول ښکاري. (دا به په پرتله خورا اسانه وي Kubernetes سخته لاره.)

زه ګومان کوم چې تاسو د کبرنیټس ، لینکس ، او کانټینرونو لومړني پوهه لرئ. هر هغه څه چې موږ یې دلته په اړه خبرې کوو یوازې د څیړنې / زده کړې موخو لپاره دي، هیڅ یې تولید ته مه ورکوئ!

عمومي کتنه

Kubernetes ډیری برخې لري. په وینا د ويکيپېډيا، جوړښت داسې ښکاري:

لږ تر لږه د وړ وړ Kubernetes

دلته لږترلږه اته برخې ښودل شوي، مګر موږ به ډیری یې له پامه غورځوو. زه غواړم ووایم چې لږترلږه شی چې په معقول ډول د کوبرنیټس په نوم یادیږي درې اصلي برخې لري:

  • کبلیت
  • kube-apiserver (کوم چې په etcd پورې اړه لري - د دې ډیټابیس)
  • د کانټینر چلولو وخت (په دې قضیه کې ډاکر)

راځئ وګورو چې اسناد د دوی هر یو په اړه څه وايي (rus., انګلیسي.) په پیل کې کبلیت:

یو اجنټ په کلستر کې په هر نوډ کې روان دی. دا ډاډ ترلاسه کوي چې کانټینرونه په پوډ کې روان دي.

کافي ساده ښکاري. په اړه د کانټینر چلولو وخت (د کانټینر چلولو وخت)؟

د کانټینر چلولو وخت یو برنامه ده چې د کانټینرونو چلولو لپاره ډیزاین شوې.

ډیر معلوماتي. مګر که تاسو د ډاکر سره آشنا یاست ، نو تاسو باید عمومي نظر ولرئ چې دا څه کوي. (د کانټینر رن ټایم او کبلیټ ترمینځ د مسؤلیتونو جلا کولو توضیحات واقعیا خورا فرعي دي او زه به یې دلته نه ځم.)

И د API سرور?

د API سرور د Kubernetes کنټرول پینل برخه ده چې د Kubernetes API افشا کوي. د API سرور د Kubernetes کنټرول پینل د پیرودونکي اړخ دی

هر هغه څوک چې کله هم د کبرنیټس سره څه کړي وي باید د API سره مستقیم یا د kubectl له لارې اړیکه ونیسي. دا د هغه څه زړه دی چې Kubernetes Kubernetes جوړوي - دماغ چې د YAML غرونه بدلوي موږ ټول پوهیږو او مینه لرو (؟) کاري زیربنا ته. داسې ښکاري چې API باید زموږ په لږترلږه ترتیب کې شتون ولري.

شرطونه

  • لینکس مجازی یا فزیکي ماشین د روټ لاسرسي سره (زه په مجازی ماشین کې اوبنټو 18.04 کاروم).
  • او دا ټول دي!

ستړیا نصبول

موږ اړتیا لرو په هغه ماشین کې ډاکر نصب کړو چې موږ به یې کاروو. (زه د ډاکر او کانټینرونو د کار کولو څرنګوالي په اړه توضیحاتو ته نه ځم؛ که تاسو علاقه لرئ ، دلته شتون لري په زړه پورې مقالې). راځئ چې دا یوازې نصب کړو apt:

$ sudo apt install docker.io
$ sudo systemctl start docker

له هغې وروسته، موږ اړتیا لرو د کوبرنیټس بائنری ترلاسه کړو. په حقیقت کې، زموږ د "کلستر" د لومړني پیل لپاره موږ یوازې اړتیا لرو kubelet، ځکه چې د سرور نورو برخو چلولو لپاره موږ کولی شو وکاروو kubelet. د چلولو وروسته زموږ د کلستر سره د تعامل لپاره، موږ به هم وکاروو kubectl.

$ curl -L https://dl.k8s.io/v1.18.5/kubernetes-server-linux-amd64.tar.gz > server.tar.gz
$ tar xzvf server.tar.gz
$ cp kubernetes/server/bin/kubelet .
$ cp kubernetes/server/bin/kubectl .
$ ./kubelet --version
Kubernetes v1.18.5

څه پیښیږي که موږ یوازې منډې وکړو kubelet?

$ ./kubelet
F0609 04:03:29.105194    4583 server.go:254] mkdir /var/lib/kubelet: permission denied

kubelet باید د ریښی په توګه وګرځی. خورا منطقي، ځکه چې هغه د ټول نوډ اداره کولو ته اړتیا لري. راځئ چې د هغې پیرامیټونه وګورو:

$ ./kubelet -h
<слишком много строк, чтобы разместить здесь>
$ ./kubelet -h | wc -l
284

واه، ډیری اختیارونه! خوشبختانه، موږ یوازې یو څو ته اړتیا لرو. دلته یو له هغو پیرامیټونو څخه دی چې موږ یې لیوالتیا لرو:

--pod-manifest-path string

هغه ډایرکټر ته لاره چې د جامد پوډونو لپاره فایلونه لري، یا هغه فایل ته لاره چې د جامد پوډونو تشریح کوي. د نقطو سره پیل شوي فایلونه له پامه غورځول شوي. (منحرف شوی: دا اختیار باید د --config اختیار له لارې کوبیلټ ته لیږدول شوي ترتیب شوي فایل کې تنظیم شي. د نورو معلوماتو لپاره، وګورئ kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file .)

دا اختیار موږ ته د چلولو اجازه راکوي جامد پوزې - پوډونه چې د Kubernetes API له لارې نه اداره کیږي. جامد پوډونه په ندرت سره کارول کیږي ، مګر دا د ګړندي کلستر لوړولو لپاره خورا اسانه دي ، او دا هغه څه دي چې موږ ورته اړتیا لرو. موږ به دا لوی خبرداری له پامه غورځوو (بیا ، دا په تولید کې مه چلوئ!) او وګورو چې ایا موږ پوډ چلولی شو.

لومړی به موږ د جامد پوډونو او چلولو لپاره لارښود جوړ کړو kubelet:

$ mkdir pods
$ sudo ./kubelet --pod-manifest-path=pods

بیا، په بل ټرمینل / tmux کړکۍ / هر څه کې، موږ به یو پوډ منشور جوړ کړو:

$ cat <<EOF > pods/hello.yaml
apiVersion: v1
kind: Pod
metadata:
  name: hello
spec:
  containers:
  - image: busybox
    name: hello
    command: ["echo", "hello world!"]
EOF

kubelet د ځینې اخطارونو لیکل پیل کوي او داسې ښکاري چې هیڅ نه پیښیږي. خو دا رښتیا نه ده! راځئ چې ډاکر ته وګورو:

$ sudo docker ps -a
CONTAINER ID        IMAGE                  COMMAND                 CREATED             STATUS                      PORTS               NAMES
8c8a35e26663        busybox                "echo 'hello world!'"   36 seconds ago      Exited (0) 36 seconds ago                       k8s_hello_hello-mink8s_default_ab61ef0307c6e0dee2ab05dc1ff94812_4
68f670c3c85f        k8s.gcr.io/pause:3.2   "/pause"                2 minutes ago       Up 2 minutes                                    k8s_POD_hello-mink8s_default_ab61ef0307c6e0dee2ab05dc1ff94812_0
$ sudo docker logs k8s_hello_hello-mink8s_default_ab61ef0307c6e0dee2ab05dc1ff94812_4
hello world!

kubelet ما د پوډ منشور ولوست او ډاکر ته یې امر ورکړ چې زموږ د ځانګړتیاو سره سم یو څو کانټینرونه پیل کړي. (که تاسو د "پاز" کانټینر په اړه حیران یاست، دا د کوبرنیټس هیک دی - وګورئ دا بلاګ.) کوبیلټ به زموږ کانټینر پیل کړي busybox د ټاکل شوي کمانډ سره او دا به د نامعلوم وخت لپاره بیا پیل کړي تر هغه چې جامد پوډ حذف شوی نه وي.

خپل ځان ته مبارکي ورکړئ. موږ یوازې ټرمینل ته د متن محصول کولو لپاره یو له خورا مغشوشونکې لارې سره راغلی یو!

لانچ وغيره

زموږ وروستی هدف د Kubernetes API چلول دي، مګر د دې کولو لپاره موږ لومړی باید چلولو ته اړتیا ولرو etcd. راځئ چې د پوډ ډایرکټر کې د دې تنظیماتو په ځای کولو سره لږترلږه etcd کلستر پیل کړو (د مثال په توګه ، pods/etcd.yaml):

apiVersion: v1
kind: Pod
metadata:
  name: etcd
  namespace: kube-system
spec:
  containers:
  - name: etcd
    command:
    - etcd
    - --data-dir=/var/lib/etcd
    image: k8s.gcr.io/etcd:3.4.3-0
    volumeMounts:
    - mountPath: /var/lib/etcd
      name: etcd-data
  hostNetwork: true
  volumes:
  - hostPath:
      path: /var/lib/etcd
      type: DirectoryOrCreate
    name: etcd-data

که تاسو کله هم د Kubernetes سره کار کړی وي، دا د YAML فایلونه باید تاسو ته پیژندل شوي وي. دلته یوازې دوه ټکي د پام وړ دي:

موږ د کوربه فولډر نصب کړی دی /var/lib/etcd په پوډ کې د دې لپاره چې د etcd ډاټا د بیا پیل کولو وروسته ساتل کیږي (که دا ترسره نه شي، د کلستر حالت به هرکله چې پوډ بیا پیل شي له منځه یوړل شي، کوم چې حتی د لږ تر لږه Kubernetes نصبولو لپاره به ښه نه وي).

موږ نصب کړی دی hostNetwork: true. دا ترتیب، په حیرانتیا سره، د پوډ داخلي شبکې پر ځای د کوربه شبکې کارولو لپاره etcd ترتیبوي (دا به د API سرور لپاره د etcd کلستر موندل اسانه کړي).

یو ساده چک ښیې چې etcd په حقیقت کې په لوکل هوسټ کې روان دی او ډیسک ته ډیټا خوندي کوي:

$ curl localhost:2379/version
{"etcdserver":"3.4.3","etcdcluster":"3.4.0"}
$ sudo tree /var/lib/etcd/
/var/lib/etcd/
└── member
    ├── snap
    │   └── db
    └── wal
        ├── 0.tmp
        └── 0000000000000000-0000000000000000.wal

د API سرور پیل کول

د Kubernetes API سرور چلول حتی اسانه دي. یوازینی پیرامیټر چې باید تیر شي هغه دی --etcd-servers، هغه څه کوي چې تاسو یې تمه لرئ:

apiVersion: v1
kind: Pod
metadata:
  name: kube-apiserver
  namespace: kube-system
spec:
  containers:
  - name: kube-apiserver
    command:
    - kube-apiserver
    - --etcd-servers=http://127.0.0.1:2379
    image: k8s.gcr.io/kube-apiserver:v1.18.5
  hostNetwork: true

دا د YAML فایل په لارښود کې ځای په ځای کړئ pods، او د API سرور به پیل شي. سره چک کول curl ښیې چې د Kubernetes API په پورټ 8080 کې په بشپړ ډول خلاص لاسرسي سره اوریدل کیږي - هیڅ تصدیق ته اړتیا نشته!

$ curl localhost:8080/healthz
ok
$ curl localhost:8080/api/v1/pods
{
  "kind": "PodList",
  "apiVersion": "v1",
  "metadata": {
    "selfLink": "/api/v1/pods",
    "resourceVersion": "59"
  },
  "items": []
}

(بیا بیا، دا په تولید کې مه چلوئ! زه یو څه حیران وم چې د ډیفالټ ترتیب خورا ناامنه دی. مګر زه اټکل کوم چې دا د پراختیا او ازموینې اسانه کول دي.)

او، په زړه پورې حیرانتیا، kubectl پرته له کوم اضافي ترتیباتو څخه د بکس څخه کار کوي!

$ ./kubectl version
Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.5", GitCommit:"e6503f8d8f769ace2f338794c914a96fc335df0f", GitTreeState:"clean", BuildDate:"2020-06-26T03:47:41Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.5", GitCommit:"e6503f8d8f769ace2f338794c914a96fc335df0f", GitTreeState:"clean", BuildDate:"2020-06-26T03:39:24Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"}
$ ./kubectl get pod
No resources found in default namespace.

ستونزه

مګر که تاسو لږ ژور وخورئ، داسې ښکاري چې یو څه غلط وي:

$ ./kubectl get pod -n kube-system
No resources found in kube-system namespace.

هغه جامد پوډونه چې موږ جوړ کړي دي ورک شوي دي! په حقیقت کې، زموږ د کوبیلټ نوډ په بشپړه توګه ندی موندل شوی:

$ ./kubectl get nodes
No resources found in default namespace.

ستونزه څه ده؟ که تاسو یو څو پراګرافونه مخکې په یاد ولرئ، موږ کوبیلټ د کمانډ لاین پیرامیټونو خورا ساده سیټ سره پیل کړ، نو کوبیلټ نه پوهیږي چې څنګه د API سرور سره اړیکه ونیسي او د دې حالت خبر کړي. د اسنادو د مطالعې وروسته، موږ ورته بیرغ پیدا کوو:

--kubeconfig string

فایل ته لاره kubeconfig، کوم چې مشخص کوي چې څنګه د API سرور سره وصل شي. شتون --kubeconfig د API سرور حالت فعالوي، نه --kubeconfig آف لائن حالت فعالوي.

دا ټول وخت، پرته له دې چې پوه شو، موږ کوبیلټ په "آفلاین حالت" کې چلولو. (که چیرې موږ پیډانټیک واو ، نو موږ کولی شو د یو واحد کیبلیټ په اړه د "لږترلږ وړ وړ کبرنیټس" په توګه فکر وکړو ، مګر دا به خورا ستړي وي). د "ریښتیني" ترتیب کولو کار کولو لپاره ، موږ اړتیا لرو د کیوب کنفګ فایل کیوبیلټ ته واستوو نو دا پوهیږي چې څنګه د API سرور سره خبرې وکړي. خوشبختانه دا خورا ساده دی (ځکه چې موږ هیڅ تصدیق یا سند مسله نلرو):

apiVersion: v1
kind: Config
clusters:
- cluster:
    server: http://127.0.0.1:8080
  name: mink8s
contexts:
- context:
    cluster: mink8s
  name: mink8s
current-context: mink8s

دا په توګه خوندي کړئ kubeconfig.yaml، پروسه وژني kubelet او د اړینو پیرامیټونو سره بیا پیل کړئ:

$ sudo ./kubelet --pod-manifest-path=pods --kubeconfig=kubeconfig.yaml

(په لاره کې، که تاسو د کرل له لارې API ته د لاسرسي هڅه وکړئ کله چې کیوبیلټ نه روان وي، نو تاسو به ومومئ چې دا لاهم روانه ده! کوبیلټ د ډاکر په څیر د دې پوډونو "والدین" نه دی، دا د "کنټرول" په څیر دی. ډیمون." کانټینرونه چې د کیوبیلټ لخوا اداره کیږي تر هغه پورې به دوام وکړي ترڅو چې کیوبیلټ دوی ودروي.)

په څو دقیقو کې kubectl باید موږ ته پوډونه او نوډونه وښیو لکه څنګه چې موږ تمه لرو:

$ ./kubectl get pods -A
NAMESPACE     NAME                    READY   STATUS             RESTARTS   AGE
default       hello-mink8s            0/1     CrashLoopBackOff   261        21h
kube-system   etcd-mink8s             1/1     Running            0          21h
kube-system   kube-apiserver-mink8s   1/1     Running            0          21h
$ ./kubectl get nodes -owide
NAME     STATUS   ROLES    AGE   VERSION   INTERNAL-IP    EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION       CONTAINER-RUNTIME
mink8s   Ready    <none>   21h   v1.18.5   10.70.10.228   <none>        Ubuntu 18.04.4 LTS   4.15.0-109-generic   docker://19.3.6

راځئ چې دا ځل واقعیا خپل ځان ته مبارکي ووایو (زه پوهیږم چې ما دمخه ځان ته مبارکي ویلې) - موږ لږترلږه Kubernetes "کلستر" لرو چې د بشپړ فعال API سره پرمخ ځي!

موږ لاندې پیل کوو

اوس راځئ وګورو چې API د څه وړتیا لري. راځئ چې د نګینکس پوډ سره پیل وکړو:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - image: nginx
    name: nginx

دلته موږ یو په زړه پورې تېروتنه ترلاسه کوو:

$ ./kubectl apply -f nginx.yaml
Error from server (Forbidden): error when creating "nginx.yaml": pods "nginx" is
forbidden: error looking up service account default/default: serviceaccount
"default" not found
$ ./kubectl get serviceaccounts
No resources found in default namespace.

دلته موږ ګورو چې زموږ د Kubernetes چاپیریال څومره بدبختانه نیمګړی دی - موږ د خدماتو لپاره هیڅ حساب نه لرو. راځئ چې په لاسي ډول د خدماتو حساب رامینځته کولو سره بیا هڅه وکړو او وګورو چې څه پیښیږي:

$ cat <<EOS | ./kubectl apply -f -
apiVersion: v1
kind: ServiceAccount
metadata:
  name: default
  namespace: default
EOS
serviceaccount/default created
$ ./kubectl apply -f nginx.yaml
Error from server (ServerTimeout): error when creating "nginx.yaml": No API
token found for service account "default", retry after the token is
automatically created and added to the service account

حتی کله چې موږ د خدماتو حساب په لاسي ډول جوړ کړ، د تصدیق نښه نه ده رامینځته شوې. لکه څنګه چې موږ د خپل لږترلږه "کلستر" سره تجربې ته دوام ورکوو، موږ به ومومئ چې ډیری ګټور شیان چې معمولا په اتوماتيک ډول پیښیږي ورک شي. د کوبرنیټس API سرور خورا لږ دی ، د ډیری درنو پورته کولو او اتوماتیک ترتیب سره په مختلف کنټرولرونو او شالید دندو کې پیښیږي چې لاهم ندي روان دي.

موږ کولی شو د دې ستونزې په شاوخوا کې د اختیار په ترتیبولو سره کار وکړو automountServiceAccountToken د خدمت حساب لپاره (ځکه چې موږ به یې په هرصورت ونه کاروو):

$ cat <<EOS | ./kubectl apply -f -
apiVersion: v1
kind: ServiceAccount
metadata:
  name: default
  namespace: default
automountServiceAccountToken: false
EOS
serviceaccount/default configured
$ ./kubectl apply -f nginx.yaml
pod/nginx created
$ ./kubectl get pods
NAME    READY   STATUS    RESTARTS   AGE
nginx   0/1     Pending   0          13m

په نهایت کې ، پوډ څرګند شو! مګر په حقیقت کې دا به پیل نشي ځکه چې موږ نه لرو پلان جوړونکی (شیډولر) د Kubernetes بله مهمه برخه ده. یوځل بیا ، موږ ګورو چې د کوبرنیټس API په حیرانتیا سره "ګونګ" دی - کله چې تاسو په API کې پوډ رامینځته کوئ ، نو دا یې راجستر کوي ، مګر هڅه نه کوي چې معلومه کړي چې کوم نوډ یې پرمخ وړي.

په حقیقت کې، تاسو د پوډ چلولو لپاره مهالویش ته اړتیا نلرئ. تاسو کولی شئ په لاسي ډول په پیرامیټر کې مینیفیسټ ته نوډ اضافه کړئ nodeName:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - image: nginx
    name: nginx
  nodeName: mink8s

(بدلون mink8s د نوډ نوم ته.) د حذف او پلي کولو وروسته، موږ ګورو چې نګینکس پیل شوی او داخلي IP پتې ته غوږ نیسي:

$ ./kubectl delete pod nginx
pod "nginx" deleted
$ ./kubectl apply -f nginx.yaml
pod/nginx created
$ ./kubectl get pods -owide
NAME    READY   STATUS    RESTARTS   AGE   IP           NODE     NOMINATED NODE   READINESS GATES
nginx   1/1     Running   0          30s   172.17.0.2   mink8s   <none>           <none>
$ curl -s 172.17.0.2 | head -4
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>

د دې لپاره چې ډاډ ترلاسه کړئ چې د پوډونو تر مینځ شبکه په سمه توګه کار کوي، موږ کولی شو د بل پوډ څخه curl چلوو:

$ cat <<EOS | ./kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: curl
spec:
  containers:
  - image: curlimages/curl
    name: curl
    command: ["curl", "172.17.0.2"]
  nodeName: mink8s
EOS
pod/curl created
$ ./kubectl logs curl | head -6
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>

دا خورا په زړه پوري ده چې پدې چاپیریال کې کیندل او وګورئ چې څه کار کوي او څه نه کوي. ما وموندله چې ConfigMap او پټ کار لکه څنګه چې تمه کیږي، مګر خدمت او ګمارل ندي.

بریا!

دا پوسټ اوږدیږي ، نو زه به د بریا اعلان وکړم او ووایم چې دا یو مناسب ترتیب دی چې "کوبرنیټس" بلل کیدی شي. دا د معیارونو له مخې د Kubernetes) او موږ یو څه شیان لرو چې کار کوي:

  • پوډونه د منظم Kubernetes API په کارولو سره اداره کیږي (د یو څو هیکونو سره)
  • تاسو کولی شئ د عامه کانټینر عکسونه اپلوډ او اداره کړئ
  • پوډونه ژوندي پاتې کیږي او په اتوماتيک ډول بیا پیل کیږي
  • په ورته نوډ کې د پوډونو ترمینځ شبکه کول خورا ښه کار کوي
  • ConfigMap، پټ او ساده ذخیره کولو کار لکه څنګه چې تمه کیده

مګر ډیری هغه څه چې کبرنیټس واقعیا ګټور کوي لاهم ورک دي ، لکه:

  • د پوډ شیډولر
  • تصدیق / اجازه ورکول
  • څو نوډونه
  • د خدماتو شبکه
  • کلستر شوی داخلي DNS
  • د خدماتو حسابونو لپاره کنټرولرونه ، ځای په ځای کول ، د کلاوډ چمتو کونکو سره ادغام او ډیری نور شیان چې کوبرنیټس راوړي

نو موږ واقعیا څه ترلاسه کړل؟ د Kubernetes API، په خپله پرمخ ځي، په حقیقت کې یوازې یو پلیټ فارم دی د کانټینر اتوماتیک. دا ډیر څه نه کوي - دا د API په کارولو سره د مختلف کنټرولرانو او آپریټرانو لپاره دنده ده - مګر دا د اتومات کولو لپاره دوامداره چاپیریال چمتو کوي.

په وړیا ویبینار کې د کورس په اړه نور معلومات ترلاسه کړئ.

نور یی ولوله:

سرچینه: www.habr.com

Add a comment