🥇 Kubernetes ที่ทำงานได้ขั้นต่ำ

การแปลบทความจัดทำขึ้นในวันเริ่มต้นหลักสูตร "แนวทางปฏิบัติและเครื่องมือ DevOps".

หากคุณกำลังอ่านข้อความนี้ คุณคงเคยได้ยินบางอย่างเกี่ยวกับ Kubernetes มาก่อน (และถ้าไม่ คุณมาอยู่ที่นี่ได้อย่างไร) แต่จริงๆ แล้ว Kubernetes คืออะไร? นี้ “การจัดเรียงตู้คอนเทนเนอร์ระดับอุตสาหกรรม”? หรือ “ระบบปฏิบัติการคลาวด์เนทีฟ”? สิ่งนี้หมายความว่าอย่างไร?

พูดตามตรงฉันไม่มั่นใจ 100% แต่ฉันคิดว่ามันน่าสนใจที่จะเจาะลึกถึงข้อมูลภายในและดูว่าเกิดอะไรขึ้นใน Kubernetes ภายใต้นามธรรมหลายชั้น เพื่อความสนุก เรามาดูกันว่าจริงๆ แล้ว "คลัสเตอร์ Kubernetes" แบบขั้นต่ำมีลักษณะเป็นอย่างไร (จะง่ายกว่านี้มาก. Kubernetes วิธีที่ยาก.)

ฉันถือว่าคุณมีความรู้พื้นฐานเกี่ยวกับ Kubernetes, Linux และคอนเทนเนอร์ ทุกสิ่งที่เราพูดถึงมีจุดประสงค์เพื่อการวิจัย/การเรียนรู้เท่านั้น อย่านำไปใช้จริง!

ทบทวน

Kubernetes มีส่วนประกอบมากมาย ตาม วิกิพีเดียสถาปัตยกรรมมีลักษณะดังนี้:

มีองค์ประกอบอย่างน้อยแปดรายการที่แสดงไว้ที่นี่ แต่เราจะเพิกเฉยต่อองค์ประกอบส่วนใหญ่ ฉันต้องการระบุว่าสิ่งขั้นต่ำที่สามารถเรียกได้อย่างสมเหตุสมผลว่า Kubernetes ประกอบด้วยองค์ประกอบหลักสามประการ:

คูเบเลต
kube-apiserver (ซึ่งขึ้นอยู่กับ ฯลฯ - ฐานข้อมูล)
รันไทม์คอนเทนเนอร์ (นักเทียบท่าในกรณีนี้)

มาดูกันว่าเอกสารพูดถึงอะไรเกี่ยวกับแต่ละเอกสาร (รัสเซีย., อังกฤษ.) ตอนแรก คูเบเลต:

เอเจนต์ที่ทำงานบนแต่ละโหนดในคลัสเตอร์ ทำให้แน่ใจว่าคอนเทนเนอร์กำลังทำงานอยู่ในพ็อด

ฟังดูง่ายพอ แล้วไง รันไทม์ของคอนเทนเนอร์ (รันไทม์คอนเทนเนอร์)?

รันไทม์ของคอนเทนเนอร์คือโปรแกรมที่ออกแบบมาเพื่อรันคอนเทนเนอร์

ข้อมูลมาก แต่ถ้าคุณคุ้นเคยกับ Docker คุณก็ควรมีแนวคิดทั่วไปว่ามันทำอะไรได้บ้าง (รายละเอียดของการแยกความรับผิดชอบระหว่างคอนเทนเนอร์รันไทม์และคูเบเล็ตนั้นค่อนข้างละเอียดอ่อนจริงๆ และฉันจะไม่พูดถึงสิ่งเหล่านี้ที่นี่)

И เซิร์ฟเวอร์เอพีไอ?

API Server คือส่วนประกอบแผงควบคุม Kubernetes ที่เปิดเผย Kubernetes API เซิร์ฟเวอร์ API คือฝั่งไคลเอ็นต์ของแผงควบคุม Kubernetes

ใครก็ตามที่เคยทำอะไรกับ Kubernetes จะต้องโต้ตอบกับ API โดยตรงหรือผ่าน kubectl นี่คือหัวใจสำคัญของสิ่งที่ทำให้ Kubernetes Kubernetes - สมองที่เปลี่ยนภูเขา YAML ที่เราทุกคนรู้จักและชื่นชอบ (?) ให้เป็นโครงสร้างพื้นฐานในการทำงาน ดูเหมือนชัดเจนว่า API ควรมีอยู่ในการกำหนดค่าขั้นต่ำของเรา

เงื่อนไขเบื้องต้น

เครื่องเสมือนหรือฟิสิคัล Linux พร้อมการเข้าถึงรูท (ฉันใช้ Ubuntu 18.04 บนเครื่องเสมือน)
และทั้งหมดนี้!

การติดตั้งที่น่าเบื่อ

เราจำเป็นต้องติดตั้ง Docker บนเครื่องที่เราจะใช้ (ฉันจะไม่ลงรายละเอียดเกี่ยวกับวิธีการทำงานของ Docker และคอนเทนเนอร์ หากคุณสนใจก็มี บทความที่ยอดเยี่ยม). มาติดตั้งกันด้วย apt:

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

หลังจากนั้นเราจะต้องได้รับไบนารีของ Kubernetes ที่จริงแล้ว สำหรับการเปิดตัว “คลัสเตอร์” ของเราครั้งแรก เราต้องการเพียงเท่านั้น 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

เส้นทางไปยังไดเร็กทอรีที่มีไฟล์สำหรับพ็อดแบบคงที่ หรือเส้นทางไปยังไฟล์ที่อธิบายพ็อดแบบคงที่ ไฟล์ที่ขึ้นต้นด้วยจุดจะถูกละเว้น (เลิกใช้แล้ว: ตัวเลือกนี้จะต้องตั้งค่าในไฟล์การกำหนดค่าที่ส่งไปยัง Kubelet ผ่านตัวเลือก --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 ฉันอ่านรายการพ็อดและให้คำสั่ง Docker เพื่อเปิดใช้คอนเทนเนอร์สองสามรายการตามข้อกำหนดของเรา (หากคุณสงสัยเกี่ยวกับคอนเทนเนอร์ "หยุดชั่วคราว" นั่นเป็นแฮ็ค Kubernetes - ดู บล็อกนี้.) Kubelet จะเปิดตัวคอนเทนเนอร์ของเรา busybox ด้วยคำสั่งที่ระบุและจะรีสตาร์ทอย่างไม่มีกำหนดจนกว่าสแตติกพ็อดจะถูกลบ

ขอแสดงความยินดีกับตัวเอง เราเพิ่งคิดวิธีหนึ่งที่สับสนที่สุดในการแสดงข้อความไปยังเทอร์มินัล!

เปิดตัว ฯลฯ

เป้าหมายสูงสุดของเราคือการรัน Kubernetes API แต่การจะทำเช่นนั้นได้ เราต้องรันก่อน ฯลฯ. มาเริ่มต้นคลัสเตอร์ etcd ขั้นต่ำโดยวางการตั้งค่าไว้ในไดเร็กทอรี pods (ตัวอย่างเช่น 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 ในพ็อดเพื่อให้ข้อมูล ฯลฯ ยังคงอยู่หลังจากการรีสตาร์ท (หากไม่เสร็จสิ้น สถานะคลัสเตอร์จะถูกลบทุกครั้งที่รีสตาร์ทพ็อด ซึ่งจะไม่ดีสำหรับการติดตั้ง Kubernetes เพียงเล็กน้อย)

เราได้ติดตั้ง hostNetwork: true. การตั้งค่านี้ไม่น่าแปลกใจเลยที่กำหนดค่า etcd ให้ใช้เครือข่ายโฮสต์แทนเครือข่ายภายในของพ็อด (ซึ่งจะทำให้เซิร์ฟเวอร์ API ค้นหาคลัสเตอร์ etcd ได้ง่ายขึ้น)

การตรวจสอบง่ายๆ แสดงให้เห็นว่า etcd ทำงานบน localhost และบันทึกข้อมูลลงดิสก์:

$ 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.

พ็อดคงที่ที่เราสร้างหายไปแล้ว! จริงๆ แล้ว โหนด kubelet ของเราไม่ถูกค้นพบเลย:

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

เกิดอะไรขึ้น? หากคุณจำสองสามย่อหน้าที่ผ่านมาได้ เราได้เริ่ม kubelet ด้วยชุดพารามิเตอร์บรรทัดคำสั่งที่ง่ายมาก ดังนั้น kubelet จึงไม่รู้วิธีติดต่อกับเซิร์ฟเวอร์ API และแจ้งสถานะของเซิร์ฟเวอร์ หลังจากศึกษาเอกสารประกอบแล้ว เราพบแฟล็กที่เกี่ยวข้อง:

--kubeconfig string

เส้นทางไปยังไฟล์ kubeconfigซึ่งระบุวิธีเชื่อมต่อกับเซิร์ฟเวอร์ API ความพร้อมใช้งาน --kubeconfig เปิดใช้งานโหมดเซิร์ฟเวอร์ API ไม่ใช่ --kubeconfig เปิดใช้งานโหมดออฟไลน์

ตลอดเวลานี้ เรากำลังใช้งาน kubelet ใน "โหมดออฟไลน์" โดยที่เราไม่รู้ตัว (หากเราเป็นคนอวดรู้ เราอาจนึกถึง kubelet แบบสแตนด์อโลนว่าเป็น "Kubernetes ที่ใช้งานได้ขั้นต่ำ" แต่นั่นคงจะน่าเบื่อมาก) เพื่อให้การกำหนดค่า "ของจริง" ทำงานได้ เราต้องส่งไฟล์ kubeconfig ไปยัง kubelet เพื่อให้รู้วิธีพูดคุยกับเซิร์ฟเวอร์ 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 ผ่านทาง curl เมื่อ kubelet ไม่ทำงาน คุณจะพบว่ามันยังคงทำงานอยู่! Kubelet ไม่ใช่ "พาเรนต์" ของพ็อดอย่าง Docker มันเป็นเหมือน "การควบคุม" มากกว่า daemon” คอนเทนเนอร์ที่จัดการโดย kubelet จะยังคงทำงานต่อไปจนกว่า kubelet จะหยุด)

ในไม่กี่นาที 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 มีความสามารถอะไรบ้าง เริ่มจากพ็อด nginx กันก่อน:

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

แม้ว่าเราจะสร้างบัญชีบริการด้วยตนเอง แต่โทเค็นการตรวจสอบสิทธิ์ก็ไม่ถูกสร้างขึ้น ในขณะที่เราทดลองกับ "คลัสเตอร์" แบบเรียบง่ายของเราต่อไป เราจะพบว่าสิ่งที่มีประโยชน์ส่วนใหญ่ที่มักจะเกิดขึ้นโดยอัตโนมัติจะหายไป เซิร์ฟเวอร์ Kubernetes 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

ในที่สุดพ็อดก็ปรากฏตัว! แต่ที่จริงแล้วมันจะไม่เริ่มเพราะเราไม่มี นักวางแผน (scheduler) เป็นอีกหนึ่งองค์ประกอบที่สำคัญของ Kubernetes ขอย้ำอีกครั้งว่า Kubernetes API นั้น "โง่" อย่างน่าประหลาดใจ - เมื่อคุณสร้าง Pod ใน API มันจะลงทะเบียนมัน แต่ไม่ได้พยายามคิดว่าโหนดใดที่จะรันบนนั้น

ที่จริงแล้ว คุณไม่จำเป็นต้องมีเครื่องกำหนดเวลาในการเรียกใช้พ็อด คุณสามารถเพิ่มโหนดลงในรายการในพารามิเตอร์ได้ด้วยตนเอง nodeName:

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

(แทนที่ mink8s เป็นชื่อของโหนด) หลังจากลบและนำไปใช้เราจะเห็นว่า nginx ได้เริ่มต้นแล้วและกำลังฟังที่อยู่ 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 และ Secret ทำงานตามที่คาดไว้ แต่บริการและการปรับใช้ไม่ได้

ความสำเร็จ!

โพสต์นี้กินเวลานานดังนั้นฉันจะประกาศชัยชนะและบอกว่านี่คือการกำหนดค่าที่ใช้งานได้ซึ่งสามารถเรียกว่า "Kubernetes" เพื่อสรุป: ไบนารีสี่ตัว, พารามิเตอร์บรรทัดคำสั่งห้าพารามิเตอร์และ YAML "เท่านั้น" 45 บรรทัด (ไม่ใช่ มากขนาดนั้นตามมาตรฐาน Kubernetes) และเรามีบางสิ่งที่ใช้งานได้:

พ็อดได้รับการจัดการโดยใช้ Kubernetes API ปกติ (พร้อมแฮ็กเล็กน้อย)
คุณสามารถอัปโหลดและจัดการอิมเมจคอนเทนเนอร์สาธารณะได้
พ็อดจะยังคงมีชีวิตอยู่และรีสตาร์ทโดยอัตโนมัติ
การสร้างเครือข่ายระหว่างพ็อดภายในโหนดเดียวกันทำงานได้ค่อนข้างดี
ConfigMap, Secret และการติดตั้งที่เก็บข้อมูลแบบธรรมดาทำงานได้ตามที่คาดไว้

แต่สิ่งที่ทำให้ Kubernetes มีประโยชน์อย่างแท้จริงส่วนใหญ่ยังคงขาดหายไป เช่น:

ตัวกำหนดเวลาพ็อด
การรับรองความถูกต้อง/การอนุญาต
หลายโหนด
เครือข่ายการให้บริการ
DNS ภายในแบบคลัสเตอร์
ตัวควบคุมสำหรับบัญชีบริการ การปรับใช้ การผสานรวมกับผู้ให้บริการระบบคลาวด์ และคุณสมบัติอื่นๆ ส่วนใหญ่ที่ Kubernetes นำมา

แล้วเราได้อะไรมาบ้าง? Kubernetes API ซึ่งทำงานด้วยตัวมันเองเป็นเพียงแพลตฟอร์มสำหรับจริงๆ ระบบอัตโนมัติของคอนเทนเนอร์. มันไม่ได้ช่วยอะไรมากนัก มันเป็นงานสำหรับคอนโทรลเลอร์และผู้ปฏิบัติงานต่างๆ ที่ใช้ API แต่จะให้สภาพแวดล้อมที่สอดคล้องกันสำหรับระบบอัตโนมัติ

เรียนรู้เพิ่มเติมเกี่ยวกับหลักสูตรนี้ในการสัมมนาผ่านเว็บฟรี

อ่านเพิ่มเติม:

ที่มา: will.com

Kubernetes ที่ทำงานได้ขั้นต่ำ