Kubernetes - คู่มือฉบับย่อ

Kubernetes ในเครื่องมือจัดการคอนเทนเนอร์แบบโอเพนซอร์สที่โฮสต์โดย Cloud Native Computing Foundation (CNCF) สิ่งนี้เรียกอีกอย่างว่า Borg เวอร์ชันปรับปรุงซึ่งได้รับการพัฒนาที่ Google เพื่อจัดการทั้งกระบวนการทำงานที่ยาวนานและงานแบทช์ซึ่งก่อนหน้านี้ได้รับการจัดการโดยระบบแยกต่างหาก

Kubernetes มาพร้อมกับความสามารถในการปรับใช้งานการปรับขนาดแอปพลิเคชันและการดำเนินงานของคอนเทนเนอร์แอปพลิเคชันในคลัสเตอร์โดยอัตโนมัติ สามารถสร้างโครงสร้างพื้นฐานที่มีคอนเทนเนอร์เป็นศูนย์กลาง

คุณสมบัติของ Kubernetes

ต่อไปนี้เป็นคุณสมบัติที่สำคัญบางประการของ Kubernetes

• พัฒนาต่อเนื่องรวมและปรับใช้

• โครงสร้างพื้นฐานแบบคอนเทนเนอร์

• การจัดการแอปพลิเคชันเป็นศูนย์กลาง

• โครงสร้างพื้นฐานที่ปรับขนาดได้อัตโนมัติ

• ความสอดคล้องของสภาพแวดล้อมระหว่างการทดสอบการพัฒนาและการผลิต

• โครงสร้างพื้นฐานที่ทำงานร่วมกันอย่างหลวม ๆ โดยที่แต่ละองค์ประกอบสามารถทำหน้าที่เป็นหน่วยแยกกันได้

• ความหนาแน่นของการใช้ทรัพยากรสูงขึ้น

• โครงสร้างพื้นฐานที่คาดเดาได้ซึ่งกำลังจะถูกสร้างขึ้น

องค์ประกอบหลักอย่างหนึ่งของ Kubernetes คือสามารถเรียกใช้แอปพลิเคชันบนคลัสเตอร์ของโครงสร้างพื้นฐานเครื่องเสมือนและจริง นอกจากนี้ยังมีความสามารถในการรันแอพพลิเคชั่นบนคลาวด์It helps in moving from host-centric infrastructure to container-centric infrastructure.

ในบทนี้เราจะพูดถึงสถาปัตยกรรมพื้นฐานของ Kubernetes

Kubernetes - สถาปัตยกรรมคลัสเตอร์

ดังที่เห็นในแผนภาพต่อไปนี้ Kubernetes เป็นไปตามสถาปัตยกรรมไคลเอนต์เซิร์ฟเวอร์ ในที่นี้เราได้ติดตั้งต้นแบบไว้ในเครื่องเดียวและโหนดบนเครื่อง Linux ที่แยกจากกัน

ส่วนประกอบหลักของมาสเตอร์และโหนดถูกกำหนดไว้ในส่วนต่อไปนี้

Kubernetes - ส่วนประกอบเครื่องจักรหลัก

ต่อไปนี้เป็นส่วนประกอบของ Kubernetes Master Machine

ฯลฯ

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

เซิร์ฟเวอร์ API

Kubernetes เป็นเซิร์ฟเวอร์ API ที่ให้การดำเนินการทั้งหมดในคลัสเตอร์โดยใช้ API เซิร์ฟเวอร์ API ใช้อินเทอร์เฟซซึ่งหมายความว่าเครื่องมือและไลบรารีต่างๆสามารถสื่อสารกับมันได้อย่างง่ายดายKubeconfigเป็นแพ็คเกจพร้อมกับเครื่องมือฝั่งเซิร์ฟเวอร์ที่สามารถใช้สำหรับการสื่อสาร มันแสดง Kubernetes API

ผู้จัดการตัวควบคุม

ส่วนประกอบนี้รับผิดชอบสำหรับตัวรวบรวมส่วนใหญ่ที่ควบคุมสถานะของคลัสเตอร์และดำเนินงาน โดยทั่วไปถือได้ว่าเป็น daemon ซึ่งทำงานแบบ nonterminating loop และมีหน้าที่รวบรวมและส่งข้อมูลไปยังเซิร์ฟเวอร์ API ทำงานเพื่อรับสถานะที่ใช้ร่วมกันของคลัสเตอร์จากนั้นทำการเปลี่ยนแปลงเพื่อนำสถานะปัจจุบันของเซิร์ฟเวอร์ไปสู่สถานะที่ต้องการ ตัวควบคุมที่สำคัญ ได้แก่ ตัวควบคุมการจำลองตัวควบคุมปลายทางตัวควบคุมเนมสเปซและตัวควบคุมบัญชีบริการ ตัวจัดการคอนโทรลเลอร์เรียกใช้ตัวควบคุมประเภทต่างๆเพื่อจัดการกับโหนดปลายทาง ฯลฯ

เครื่องมือจัดกำหนดการ

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

Kubernetes - ส่วนประกอบโหนด

ต่อไปนี้เป็นส่วนประกอบหลักของเซิร์ฟเวอร์โหนดที่จำเป็นในการสื่อสารกับ Kubernetes master

นักเทียบท่า

ข้อกำหนดแรกของแต่ละโหนดคือ Docker ซึ่งช่วยในการเรียกใช้คอนเทนเนอร์แอ็พพลิเคชันที่ห่อหุ้มในสภาพแวดล้อมการทำงานที่ค่อนข้างแยก แต่มีน้ำหนักเบา

บริการ Kubelet

นี่เป็นบริการขนาดเล็กในแต่ละโหนดที่รับผิดชอบในการถ่ายทอดข้อมูลไปยังและจากบริการเครื่องบินควบคุม มันโต้ตอบกับetcdจัดเก็บเพื่ออ่านรายละเอียดการกำหนดค่าและเขียนค่า สิ่งนี้สื่อสารกับคอมโพเนนต์หลักเพื่อรับคำสั่งและทำงาน kubeletจากนั้นจะถือว่ารับผิดชอบในการรักษาสถานะการทำงานและเซิร์ฟเวอร์โหนด จัดการกฎเครือข่ายการส่งต่อพอร์ต ฯลฯ

บริการ Kubernetes Proxy

นี่คือบริการพร็อกซีที่ทำงานบนแต่ละโหนดและช่วยในการทำให้บริการพร้อมใช้งานกับโฮสต์ภายนอก ช่วยในการส่งต่อคำขอเพื่อแก้ไขคอนเทนเนอร์และสามารถดำเนินการโหลดบาลานซ์แบบดั้งเดิมได้ ตรวจสอบให้แน่ใจว่าสภาพแวดล้อมเครือข่ายสามารถคาดเดาได้และสามารถเข้าถึงได้และในขณะเดียวกันก็แยกได้เช่นกัน จัดการพ็อดบนโหนดไดรฟ์ข้อมูลความลับการสร้างการตรวจสอบความสมบูรณ์ของคอนเทนเนอร์ใหม่ ฯลฯ

Kubernetes - โครงสร้างหลักและโหนด

ภาพประกอบต่อไปนี้แสดงโครงสร้างของ Kubernetes Master และ Node

สิ่งสำคัญคือต้องตั้งค่า Virtual Datacenter (vDC) ก่อนตั้งค่า Kubernetes นี่ถือได้ว่าเป็นชุดของเครื่องที่สามารถสื่อสารกันผ่านเครือข่าย สำหรับวิธีปฏิบัติจริงคุณสามารถตั้งค่า vDC ได้PROFITBRICKS หากคุณไม่ได้ติดตั้งโครงสร้างพื้นฐานทางกายภาพหรือระบบคลาวด์

เมื่อการตั้งค่า IaaS บนคลาวด์เสร็จสมบูรณ์คุณจะต้องกำหนดค่าไฟล์ Master และ Node.

Note- การตั้งค่าจะแสดงสำหรับเครื่อง Ubuntu สิ่งเดียวกันนี้สามารถตั้งค่าบนเครื่อง Linux อื่น ๆ ได้เช่นกัน

ข้อกำหนดเบื้องต้น

Installing Docker- จำเป็นต้องมี Docker ในทุกอินสแตนซ์ของ Kubernetes ต่อไปนี้เป็นขั้นตอนในการติดตั้ง Docker

Step 1 - เข้าสู่ระบบเครื่องด้วยบัญชีผู้ใช้รูท

Step 2- อัปเดตข้อมูลแพ็คเกจ ตรวจสอบให้แน่ใจว่าแพ็กเกจ apt ใช้งานได้

Step 3 - เรียกใช้คำสั่งต่อไปนี้

$ sudo apt-get update $ sudo apt-get install apt-transport-https ca-certificates

Step 4 - เพิ่มคีย์ GPG ใหม่

$ sudo apt-key adv \ --keyserver hkp://ha.pool.sks-keyservers.net:80 \ --recv-keys 58118E89F3A912897C070ADBF76221572C52609D $ echo "deb https://apt.dockerproject.org/repo ubuntu-trusty main" | sudo tee
/etc/apt/sources.list.d/docker.list

Step 5 - อัปเดตรูปภาพแพ็กเกจ API

$ sudo apt-get update

เมื่องานทั้งหมดข้างต้นเสร็จสมบูรณ์คุณสามารถเริ่มด้วยการติดตั้ง Docker engine จริง อย่างไรก็ตามก่อนหน้านี้คุณต้องตรวจสอบว่าเวอร์ชันเคอร์เนลที่คุณใช้นั้นถูกต้อง

ติดตั้ง Docker Engine

รันคำสั่งต่อไปนี้เพื่อติดตั้ง Docker engine

Step 1 - เข้าสู่ระบบเครื่อง

Step 2 - อัปเดตดัชนีแพ็คเกจ

$ sudo apt-get update

Step 3 - ติดตั้ง Docker Engine โดยใช้คำสั่งต่อไปนี้

$ sudo apt-get install docker-engine

Step 4 - เริ่ม Docker daemon

$ sudo apt-get install docker-engine

Step 5 - หากต้องการติดตั้ง Docker ให้ใช้คำสั่งต่อไปนี้

$ sudo docker run hello-world

ติดตั้ง etcd 2.0

จำเป็นต้องติดตั้งบน Kubernetes Master Machine ในการติดตั้งให้รันคำสั่งต่อไปนี้

$ curl -L https://github.com/coreos/etcd/releases/download/v2.0.0/etcd
-v2.0.0-linux-amd64.tar.gz -o etcd-v2.0.0-linux-amd64.tar.gz ->1
$ tar xzvf etcd-v2.0.0-linux-amd64.tar.gz ------>2 $ cd etcd-v2.0.0-linux-amd64 ------------>3
$ mkdir /opt/bin ------------->4 $ cp etcd* /opt/bin ----------->5

ในชุดคำสั่งข้างต้น -

• ก่อนอื่นเราดาวน์โหลดไฟล์ etcd. บันทึกสิ่งนี้ด้วยชื่อที่ระบุ
• จากนั้นเราจะต้องยกเลิกการติดตั้ง tar package
• เราทำผบ. ภายใน / opt named bin
• คัดลอกไฟล์ที่แตกแล้วไปยังตำแหน่งเป้าหมาย

ตอนนี้เราพร้อมที่จะสร้าง Kubernetes เราจำเป็นต้องติดตั้ง Kubernetes บนเครื่องทั้งหมดบนคลัสเตอร์

$ git clone https://github.com/GoogleCloudPlatform/kubernetes.git $ cd kubernetes
$ make release

คำสั่งดังกล่าวจะสร้างไฟล์ _outputdir ในรูทของโฟลเดอร์ kubernetes จากนั้นเราสามารถแยกไดเร็กทอรีไปยังไดเร็กทอรีใดก็ได้ที่เราเลือก / opt / bin ฯลฯ

ถัดไปเป็นส่วนของระบบเครือข่ายซึ่งเราต้องเริ่มต้นด้วยการตั้งค่า Kubernetes master และ node ในการดำเนินการนี้เราจะสร้างรายการในไฟล์โฮสต์ซึ่งสามารถทำได้บนเครื่องโหนด

$ echo "<IP address of master machine> kube-master
< IP address of Node Machine>" >> /etc/hosts

ต่อไปนี้จะเป็นผลลัพธ์ของคำสั่งดังกล่าว

ตอนนี้เราจะเริ่มต้นด้วยการกำหนดค่าจริงบน Kubernetes Master

ขั้นแรกเราจะเริ่มคัดลอกไฟล์การกำหนดค่าทั้งหมดไปยังตำแหน่งที่ถูกต้อง

$ cp <Current dir. location>/kube-apiserver /opt/bin/ $ cp <Current dir. location>/kube-controller-manager /opt/bin/
$ cp <Current dir. location>/kube-kube-scheduler /opt/bin/ $ cp <Current dir. location>/kubecfg /opt/bin/
$ cp <Current dir. location>/kubectl /opt/bin/ $ cp <Current dir. location>/kubernetes /opt/bin/

คำสั่งดังกล่าวจะคัดลอกไฟล์การกำหนดค่าทั้งหมดไปยังตำแหน่งที่ต้องการ ตอนนี้เราจะกลับมาที่ไดเร็กทอรีเดิมที่เราสร้างโฟลเดอร์ Kubernetes

$ cp kubernetes/cluster/ubuntu/init_conf/kube-apiserver.conf /etc/init/ $ cp kubernetes/cluster/ubuntu/init_conf/kube-controller-manager.conf /etc/init/
$ cp kubernetes/cluster/ubuntu/init_conf/kube-kube-scheduler.conf /etc/init/ $ cp kubernetes/cluster/ubuntu/initd_scripts/kube-apiserver /etc/init.d/
$ cp kubernetes/cluster/ubuntu/initd_scripts/kube-controller-manager /etc/init.d/ $ cp kubernetes/cluster/ubuntu/initd_scripts/kube-kube-scheduler /etc/init.d/

$ cp kubernetes/cluster/ubuntu/default_scripts/kubelet /etc/default/ $ cp kubernetes/cluster/ubuntu/default_scripts/kube-proxy /etc/default/
$ cp kubernetes/cluster/ubuntu/default_scripts/kubelet /etc/default/

ขั้นตอนต่อไปคือการอัพเดตไฟล์คอนฟิกูเรชันที่คัดลอกภายใต้ / etc ผบ.

กำหนดค่า etcd บนมาสเตอร์โดยใช้คำสั่งต่อไปนี้

$ ETCD_OPTS = "-listen-client-urls = http://kube-master:4001"

กำหนดค่า kube-apiserver

สำหรับสิ่งนี้ในต้นแบบเราจำเป็นต้องแก้ไขไฟล์ /etc/default/kube-apiserver ไฟล์ที่เราคัดลอกไว้ก่อนหน้านี้

$ KUBE_APISERVER_OPTS = "--address = 0.0.0.0 \
--port = 8080 \
--etcd_servers = <The path that is configured in ETCD_OPTS> \
--portal_net = 11.1.1.0/24 \
--allow_privileged = false \
--kubelet_port = < Port you want to configure> \
--v = 0"

กำหนดค่า kube Controller Manager

เราจำเป็นต้องเพิ่มเนื้อหาต่อไปนี้ใน /etc/default/kube-controller-manager.

$ KUBE_CONTROLLER_MANAGER_OPTS = "--address = 0.0.0.0 \
--master = 127.0.0.1:8080 \
--machines = kube-minion \ -----> #this is the kubernatics node
--v = 0

จากนั้นกำหนดค่าตัวกำหนดตารางเวลา kube ในไฟล์ที่เกี่ยวข้อง

$ KUBE_SCHEDULER_OPTS = "--address = 0.0.0.0 \
--master = 127.0.0.1:8080 \
--v = 0"

เมื่องานทั้งหมดข้างต้นเสร็จสมบูรณ์เราก็พร้อมที่จะดำเนินการต่อโดยนำ Kubernetes Master ขึ้นมา ในการดำเนินการนี้เราจะรีสตาร์ท Docker

$ service docker restart

การกำหนดค่าโหนด Kubernetes

โหนด Kubernetes จะเรียกใช้บริการสองอย่างคือ kubelet and the kube-proxy. ก่อนที่จะดำเนินการต่อเราต้องคัดลอกไบนารีที่เราดาวน์โหลดไปยังโฟลเดอร์ที่จำเป็นซึ่งเราต้องการกำหนดค่าโหนด kubernetes

ใช้วิธีเดียวกับการคัดลอกไฟล์ที่เราทำกับ kubernetes master เนื่องจากจะรันเฉพาะ kubelet และ kube-proxy เราจึงกำหนดค่าให้

$ cp <Path of the extracted file>/kubelet /opt/bin/ $ cp <Path of the extracted file>/kube-proxy /opt/bin/
$ cp <Path of the extracted file>/kubecfg /opt/bin/ $ cp <Path of the extracted file>/kubectl /opt/bin/
$ cp <Path of the extracted file>/kubernetes /opt/bin/

ตอนนี้เราจะคัดลอกเนื้อหาไปยังผบ. ที่เหมาะสม

$ cp kubernetes/cluster/ubuntu/init_conf/kubelet.conf /etc/init/
$ cp kubernetes/cluster/ubuntu/init_conf/kube-proxy.conf /etc/init/ $ cp kubernetes/cluster/ubuntu/initd_scripts/kubelet /etc/init.d/
$ cp kubernetes/cluster/ubuntu/initd_scripts/kube-proxy /etc/init.d/ $ cp kubernetes/cluster/ubuntu/default_scripts/kubelet /etc/default/
$ cp kubernetes/cluster/ubuntu/default_scripts/kube-proxy /etc/default/

เราจะกำหนดค่าไฟล์ kubelet และ kube-proxy conf ไฟล์.

เราจะกำหนดค่าไฟล์ /etc/init/kubelet.conf.

$ KUBELET_OPTS = "--address = 0.0.0.0 \
--port = 10250 \
--hostname_override = kube-minion \
--etcd_servers = http://kube-master:4001 \
--enable_server = true
--v = 0"
/

สำหรับ kube-proxy เราจะกำหนดค่าโดยใช้คำสั่งต่อไปนี้

$ KUBE_PROXY_OPTS = "--etcd_servers = http://kube-master:4001 \
--v = 0"
/etc/init/kube-proxy.conf

ในที่สุดเราจะเริ่มบริการ Docker ใหม่

$ service docker restart

ตอนนี้เราทำเสร็จแล้วกับการกำหนดค่า คุณสามารถตรวจสอบได้โดยรันคำสั่งต่อไปนี้

$ /opt/bin/kubectl get minions

อิมเมจ Kubernetes (Docker) เป็นส่วนประกอบสำคัญของ Containerized Infrastructure ณ ตอนนี้เราสนับสนุน Kubernetes เพื่อรองรับอิมเมจ Docker เท่านั้น คอนเทนเนอร์แต่ละอันในพ็อดจะมีอิมเมจ Docker ทำงานอยู่ข้างใน

เมื่อเรากำหนดค่าพ็อดคุณสมบัติรูปภาพในไฟล์คอนฟิกูเรชันจะมีไวยากรณ์เหมือนกับคำสั่ง Docker ไฟล์คอนฟิกูเรชันมีฟิลด์สำหรับกำหนดชื่ออิมเมจซึ่งเรากำลังวางแผนที่จะดึงจากรีจิสตรี

ต่อไปนี้เป็นโครงสร้างการกำหนดค่าทั่วไปซึ่งจะดึงอิมเมจจาก Docker Registry และปรับใช้ใน Kubernetes container

apiVersion: v1
kind: pod
metadata:
   name: Tesing_for_Image_pull -----------> 1
   spec:
      containers:
         - name: neo4j-server ------------------------> 2
         image: <Name of the Docker image>----------> 3
         imagePullPolicy: Always ------------->4
         command: ["echo", "SUCCESS"] ------------------->

ในโค้ดข้างต้นเราได้กำหนด -

• name: Tesing_for_Image_pull - ชื่อนี้มีไว้เพื่อระบุและตรวจสอบว่าชื่อคอนเทนเนอร์ที่จะสร้างขึ้นหลังจากดึงภาพจาก Docker Registry คืออะไร

• name: neo4j-server- นี่คือชื่อที่กำหนดให้กับคอนเทนเนอร์ที่เราพยายามสร้าง เหมือนที่เราให้ neo4j-server

• image: <Name of the Docker image>- นี่คือชื่อของรูปภาพที่เราพยายามดึงมาจาก Docker หรือรีจิสตรีภายในของรูปภาพ เราจำเป็นต้องกำหนดเส้นทางรีจิสทรีที่สมบูรณ์พร้อมกับชื่อภาพที่เราพยายามดึง

• imagePullPolicy - เสมอ - นโยบายการดึงรูปภาพนี้กำหนดว่าเมื่อใดก็ตามที่เราเรียกใช้ไฟล์นี้เพื่อสร้างคอนเทนเนอร์ระบบจะดึงชื่อเดิมอีกครั้ง

• command: [“echo”, “SUCCESS”] - ด้วยสิ่งนี้เมื่อเราสร้างคอนเทนเนอร์และหากทุกอย่างเรียบร้อยดีก็จะแสดงข้อความเมื่อเราจะเข้าถึงคอนเทนเนอร์

ในการดึงภาพและสร้างคอนเทนเนอร์เราจะเรียกใช้คำสั่งต่อไปนี้

$ kubectl create –f Tesing_for_Image_pull

เมื่อเราดึงบันทึกเราจะได้ผลลัพธ์ที่สำเร็จ

$ kubectl log Tesing_for_Image_pull

คำสั่งดังกล่าวจะสร้างผลลัพธ์ของความสำเร็จหรือเราจะได้ผลลัพธ์เป็นความล้มเหลว

Note - ขอแนะนำให้คุณลองใช้คำสั่งทั้งหมดด้วยตัวเอง

หน้าที่หลักของงานคือการสร้างพ็อดอย่างน้อยหนึ่งรายการและติดตามเกี่ยวกับความสำเร็จของพ็อด ตรวจสอบให้แน่ใจว่าจำนวนพ็อดที่ระบุเสร็จสมบูรณ์ เมื่อการรันพ็อดสำเร็จตามจำนวนที่ระบุงานนั้นจะถือว่าเสร็จสมบูรณ์

การสร้างงาน

ใช้คำสั่งต่อไปนี้เพื่อสร้างงาน -

apiVersion: v1
kind: Job ------------------------> 1
metadata:
   name: py
   spec:
   template:
      metadata
      name: py -------> 2
      spec:
         containers:
            - name: py ------------------------> 3
            image: python----------> 4
            command: ["python", "SUCCESS"]
            restartPocliy: Never --------> 5

ในโค้ดข้างต้นเราได้กำหนด -

• kind: Job → เราได้กำหนดชนิดเป็น Job ซึ่งจะบอก kubectl ว่า yaml ไฟล์ที่ใช้คือการสร้างพ็อดประเภทงาน

• Name:py → นี่คือชื่อของเทมเพลตที่เราใช้และข้อมูลจำเพาะกำหนดเทมเพลต

• name: py → เราได้ตั้งชื่อเป็น py ภายใต้ข้อมูลจำเพาะของคอนเทนเนอร์ซึ่งช่วยในการระบุ Pod ที่กำลังจะถูกสร้างขึ้นจากมัน

• Image: python → ภาพที่เราจะดึงเพื่อสร้างคอนเทนเนอร์ที่จะวิ่งเข้าไปในพ็อด

• restartPolicy: Never →เงื่อนไขของการรีสตาร์ทอิมเมจนี้ถูกกำหนดให้เป็น never ซึ่งหมายความว่าถ้าคอนเทนเนอร์ถูกฆ่าหรือเป็นเท็จจะไม่รีสตาร์ทเอง

เราจะสร้างงานโดยใช้คำสั่งต่อไปนี้ด้วย yaml ซึ่งบันทึกด้วยชื่อ py.yaml.

$ kubectl create –f py.yaml

คำสั่งดังกล่าวจะสร้างงาน หากคุณต้องการตรวจสอบสถานะของงานให้ใช้คำสั่งต่อไปนี้

$ kubectl describe jobs/py

คำสั่งดังกล่าวจะสร้างงาน หากคุณต้องการตรวจสอบสถานะของงานให้ใช้คำสั่งต่อไปนี้

งานตามกำหนดการ

งานที่กำหนดเวลาไว้ใน Kubernetes ใช้ Cronetesซึ่งรับงาน Kubernetes และเปิดตัวในคลัสเตอร์ Kubernetes

• การจัดกำหนดการงานจะเรียกใช้พ็อดในช่วงเวลาที่กำหนด
• งานล้อเลียนถูกสร้างขึ้นสำหรับงานที่เรียกตัวเองโดยอัตโนมัติ

Note - คุณสมบัติของงานตามกำหนดเวลาได้รับการสนับสนุนโดยเวอร์ชัน 1.4 และ betch / v2alpha 1 API เปิดอยู่โดยการส่งผ่าน –runtime-config=batch/v2alpha1 ในขณะที่เปิดเซิร์ฟเวอร์ API

เราจะใช้มันเทศแบบเดียวกับที่เราใช้ในการสร้างงานและทำให้เป็นงานที่กำหนดเวลาไว้

apiVersion: v1
kind: Job
metadata:
   name: py
spec:
   schedule: h/30 * * * * ? -------------------> 1
   template:
      metadata
         name: py
      spec:
         containers:
         - name: py
         image: python
         args:
/bin/sh -------> 2
-c
ps –eaf ------------> 3
restartPocliy: OnFailure

ในโค้ดข้างต้นเราได้กำหนด -

• schedule: h/30 * * * * ? →เพื่อกำหนดเวลาให้งานทำงานในทุกๆ 30 นาที

• /bin/sh: สิ่งนี้จะเข้าไปในคอนเทนเนอร์ด้วย / bin / sh

• ps –eaf → จะเรียกใช้คำสั่ง ps -eaf บนเครื่องและแสดงรายการกระบวนการทำงานทั้งหมดภายในคอนเทนเนอร์

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

ป้ายกำกับ

เลเบลคือคู่คีย์ - ค่าที่แนบมากับพ็อดตัวควบคุมการจำลองและบริการ ใช้เป็นคุณสมบัติในการระบุแอตทริบิวต์สำหรับอ็อบเจ็กต์เช่นพ็อดและตัวควบคุมการจำลองแบบ สามารถเพิ่มลงในออบเจ็กต์ได้ในเวลาสร้างและสามารถเพิ่มหรือแก้ไขได้ในขณะดำเนินการ

ตัวเลือก

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

ปัจจุบัน Kubernetes API รองรับตัวเลือกสองประเภท -

• ตัวเลือกตามความเท่าเทียมกัน
• ตัวเลือกตามชุด

ตัวเลือกตามความเท่าเทียมกัน

อนุญาตให้กรองตามคีย์และค่า การจับคู่วัตถุควรเป็นไปตามป้ายกำกับที่ระบุทั้งหมด

Set-based Selectors

ตัวเลือกตามชุดอนุญาตให้กรองคีย์ตามชุดของค่า

apiVersion: v1
kind: Service
metadata:
   name: sp-neo4j-standalone
spec:
   ports:
      - port: 7474
      name: neo4j
   type: NodePort
   selector:
      app: salesplatform ---------> 1
      component: neo4j -----------> 2

ในโค้ดด้านบนเราใช้ตัวเลือกป้ายกำกับเป็น app: salesplatform และส่วนประกอบเป็น component: neo4j.

เมื่อเราเรียกใช้ไฟล์โดยใช้ไฟล์ kubectl มันจะสร้างบริการที่มีชื่อ sp-neo4j-standalone ซึ่งจะสื่อสารบนพอร์ต 7474 ype คือ NodePort ด้วยตัวเลือกป้ายกำกับใหม่เป็น app: salesplatform และ component: neo4j.

เนมสเปซให้คุณสมบัติเพิ่มเติมสำหรับชื่อทรัพยากร สิ่งนี้มีประโยชน์เมื่อหลายทีมใช้คลัสเตอร์เดียวกันและอาจเกิดความขัดแย้งกันของชื่อ อาจเป็นเสมือนกำแพงระหว่างคลัสเตอร์หลายกลุ่ม

การทำงานของเนมสเปซ

ต่อไปนี้เป็นฟังก์ชันที่สำคัญบางประการของเนมสเปซใน Kubernetes -

• เนมสเปซช่วยการสื่อสารแบบพ็อดต่อพ็อดโดยใช้เนมสเปซเดียวกัน

• เนมสเปซเป็นคลัสเตอร์เสมือนที่สามารถอยู่ด้านบนของคลัสเตอร์ฟิสิคัลเดียวกันได้

• พวกเขาให้การแยกทางตรรกะระหว่างทีมและสภาพแวดล้อมของพวกเขา

สร้างเนมสเปซ

คำสั่งต่อไปนี้ใช้เพื่อสร้างเนมสเปซ

apiVersion: v1
kind: Namespce
metadata
   name: elk

ควบคุมเนมสเปซ

คำสั่งต่อไปนี้ใช้เพื่อควบคุมเนมสเปซ

$ kubectl create –f namespace.yml ---------> 1
$ kubectl get namespace -----------------> 2 $ kubectl get namespace <Namespace name> ------->3
$ kubectl describe namespace <Namespace name> ---->4 $ kubectl delete namespace <Namespace name>

ในโค้ดด้านบน

• เรากำลังใช้คำสั่งเพื่อสร้างเนมสเปซ
• นี่จะแสดงรายการเนมสเปซทั้งหมดที่มี
• สิ่งนี้จะได้รับเนมสเปซเฉพาะที่มีชื่อระบุไว้ในคำสั่ง
• ข้อมูลนี้จะอธิบายรายละเอียดทั้งหมดเกี่ยวกับบริการ
• การดำเนินการนี้จะลบเนมสเปซเฉพาะที่มีอยู่ในคลัสเตอร์

การใช้เนมสเปซในบริการ - ตัวอย่าง

ต่อไปนี้เป็นตัวอย่างไฟล์ตัวอย่างสำหรับการใช้เนมสเปซในบริการ

apiVersion: v1
kind: Service
metadata:
   name: elasticsearch
   namespace: elk
   labels:
      component: elasticsearch
spec:
   type: LoadBalancer
   selector:
      component: elasticsearch
   ports:
   - name: http
      port: 9200
      protocol: TCP
   - name: transport
      port: 9300
      protocol: TCP

ในโค้ดด้านบนเราใช้เนมสเปซเดียวกันภายใต้ข้อมูลเมตาของบริการที่มีชื่อของ elk.

โหนดเป็นเครื่องจักรที่ทำงานในคลัสเตอร์ Kubernetes ซึ่งเรียกอีกอย่างว่า minion เป็นหน่วยการทำงานซึ่งอาจเป็นทางกายภาพ VM หรืออินสแตนซ์ระบบคลาวด์

แต่ละโหนดมีการกำหนดค่าที่จำเป็นทั้งหมดที่จำเป็นในการเรียกใช้พ็อดเช่นบริการพร็อกซีและบริการ kubelet พร้อมกับ Docker ซึ่งใช้เพื่อเรียกใช้คอนเทนเนอร์ Docker บนพ็อดที่สร้างบนโหนด

Kubernetes ไม่ได้สร้างขึ้น แต่สร้างจากภายนอกโดยผู้ให้บริการระบบคลาวด์หรือผู้จัดการคลัสเตอร์ Kubernetes บนเครื่องจริงหรือ VM

องค์ประกอบหลักของ Kubernetes ในการจัดการโหนดหลายโหนดคือตัวจัดการคอนโทรลเลอร์ซึ่งเรียกใช้คอนโทรลเลอร์หลายประเภทเพื่อจัดการโหนด ในการจัดการโหนด Kubernetes จะสร้างวัตถุชนิดโหนดซึ่งจะตรวจสอบว่าวัตถุที่สร้างขึ้นเป็นโหนดที่ถูกต้อง

บริการด้วย Selector

apiVersion: v1
kind: node
metadata:
   name: < ip address of the node>
   labels:
      name: <lable name>

ในรูปแบบ JSON วัตถุจริงจะถูกสร้างขึ้นซึ่งมีลักษณะดังนี้ -

{
   Kind: node
   apiVersion: v1
   "metadata": 
   {
      "name": "10.01.1.10",
      "labels"
      {
         "name": "cluster 1 node"
      }
   }
}

ตัวควบคุมโหนด

เป็นชุดของบริการที่ทำงานใน Kubernetes master และตรวจสอบโหนดในคลัสเตอร์อย่างต่อเนื่องบนพื้นฐานของ metadata.name หากบริการที่จำเป็นทั้งหมดทำงานอยู่โหนดจะได้รับการตรวจสอบความถูกต้องและพ็อดที่สร้างขึ้นใหม่จะถูกกำหนดให้กับโหนดนั้นโดยคอนโทรลเลอร์ หากไม่ถูกต้องต้นแบบจะไม่กำหนดพ็อดใด ๆ ให้กับมันและจะรอจนกว่ามันจะใช้ได้

Kubernetes master จะลงทะเบียนโหนดโดยอัตโนมัติหาก –register-node ธงเป็นจริง

–register-node = true

อย่างไรก็ตามหากผู้ดูแลระบบคลัสเตอร์ต้องการจัดการด้วยตนเองก็สามารถทำได้โดยการเปลี่ยนแบนของ -

–register-node = false

บริการสามารถกำหนดเป็นชุดของพ็อดเชิงตรรกะได้ สามารถกำหนดให้เป็นนามธรรมที่ด้านบนของพ็อดซึ่งมีที่อยู่ IP เดียวและชื่อ DNS ที่สามารถเข้าถึงพ็อดได้ ด้วยบริการการจัดการการกำหนดค่าการจัดสรรภาระงานทำได้ง่ายมาก ช่วยให้ฝักปรับขนาดได้ง่ายมาก

บริการคือออบเจ็กต์ REST ใน Kubernetes ซึ่งคำจำกัดความสามารถโพสต์ไปยัง Kubernetes apiServer บน Kubernetes ต้นแบบเพื่อสร้างอินสแตนซ์ใหม่

บริการโดยไม่ต้องเลือก

apiVersion: v1
kind: Service
metadata:
   name: Tutorial_point_service
spec:
   ports:
   - port: 8080
   targetPort: 31999

การกำหนดค่าข้างต้นจะสร้างบริการที่มีชื่อว่า Tutorial_point_service

ไฟล์กำหนดค่าบริการพร้อมตัวเลือก

apiVersion: v1
kind: Service
metadata:
   name: Tutorial_point_service
spec:
   selector:
      application: "My Application" -------------------> (Selector)
   ports:
   - port: 8080
   targetPort: 31999

ในตัวอย่างนี้เรามีตัวเลือก ดังนั้นในการถ่ายโอนการเข้าชมเราจำเป็นต้องสร้างปลายทางด้วยตนเอง

apiVersion: v1
kind: Endpoints
metadata:
   name: Tutorial_point_service
subnets:
   address:
      "ip": "192.168.168.40" -------------------> (Selector)
   ports:
      - port: 8080

ในโค้ดด้านบนเราได้สร้างจุดสิ้นสุดซึ่งจะกำหนดเส้นทางการรับส่งข้อมูลไปยังปลายทางที่กำหนดเป็น“ 192.168.168.40:8080”

การสร้างบริการหลายพอร์ต

apiVersion: v1
kind: Service
metadata:
   name: Tutorial_point_service
spec:
   selector:
      application: “My Application” -------------------> (Selector)
   ClusterIP: 10.3.0.12
   ports:
      -name: http
      protocol: TCP
      port: 80
      targetPort: 31999
   -name:https
      Protocol: TCP
      Port: 443
      targetPort: 31998

ประเภทของบริการ

ClusterIP- สิ่งนี้ช่วยในการ จำกัด บริการภายในคลัสเตอร์ จะแสดงบริการภายในคลัสเตอร์ Kubernetes ที่กำหนด

spec:
   type: NodePort
   ports:
   - port: 8080
      nodePort: 31999
      name: NodeportService

NodePort- จะแสดงบริการบนพอร์ตแบบคงที่บนโหนดที่ปรับใช้ กClusterIP บริการซึ่ง NodePortบริการจะกำหนดเส้นทางถูกสร้างขึ้นโดยอัตโนมัติ บริการสามารถเข้าถึงได้จากภายนอกคลัสเตอร์โดยใช้ไฟล์NodeIP:nodePort.

spec:
   ports:
   - port: 8080
      nodePort: 31999
      name: NodeportService
      clusterIP: 10.20.30.40

Load Balancer - ใช้ตัวจัดสรรภาระงานบนคลาวด์ NodePort และ ClusterIP บริการจะถูกสร้างขึ้นโดยอัตโนมัติซึ่งตัวจัดสรรภาระงานภายนอกจะกำหนดเส้นทาง

บริการเต็มรูปแบบ yamlไฟล์ที่มีประเภทบริการเป็น Node Port ลองสร้างด้วยตัวคุณเอง

apiVersion: v1
kind: Service
metadata:
   name: appname
   labels:
      k8s-app: appname
spec:
   type: NodePort
   ports:
   - port: 8080
      nodePort: 31999
      name: omninginx
   selector:
      k8s-app: appname
      component: nginx
      env: env_name

พ็อดคือชุดของคอนเทนเนอร์และที่เก็บข้อมูลภายในโหนดของคลัสเตอร์ Kubernetes เป็นไปได้ที่จะสร้างพ็อดที่มีภาชนะหลายอันอยู่ข้างใน ตัวอย่างเช่นการเก็บคอนเทนเนอร์ฐานข้อมูลและที่เก็บข้อมูลไว้ในพ็อดเดียวกัน

ประเภทของ Pod

พ็อดมีสองประเภท -

• พ็อดคอนเทนเนอร์เดี่ยว
• พ็อดหลายคอนเทนเนอร์

พ็อดคอนเทนเนอร์เดี่ยว

สามารถสร้างได้ง่ายๆด้วยคำสั่ง kubctl run ซึ่งคุณมีภาพที่กำหนดไว้ในรีจิสทรีของ Docker ซึ่งเราจะดึงในขณะที่สร้างพ็อด

$ kubectl run <name of pod> --image=<name of the image from registry>

Example - เราจะสร้างพ็อดที่มีอิมเมจแมวตัวผู้ซึ่งมีอยู่ใน Docker hub

$ kubectl run tomcat --image = tomcat:8.0

ซึ่งสามารถทำได้โดยการสร้างไฟล์ yaml แล้วเรียกใช้ไฟล์ kubectl create คำสั่ง

apiVersion: v1
kind: Pod
metadata:
   name: Tomcat
spec:
   containers:
   - name: Tomcat
    image: tomcat: 8.0
    ports:
containerPort: 7500
   imagePullPolicy: Always

เมื่อข้างต้น yaml สร้างไฟล์ขึ้นเราจะบันทึกไฟล์ด้วยชื่อของ tomcat.yml และรันคำสั่ง create เพื่อรันเอกสาร

$ kubectl create –f tomcat.yml

มันจะสร้างพ็อดที่มีชื่อของแมวตัวผู้ เราสามารถใช้คำสั่งอธิบายควบคู่ไปกับkubectl เพื่ออธิบายพ็อด

Multi Container Pod

พ็อดหลายคอนเทนเนอร์ถูกสร้างขึ้นโดยใช้ไฟล์ yaml mail ด้วยคำจำกัดความของคอนเทนเนอร์

apiVersion: v1
kind: Pod
metadata:
   name: Tomcat
spec:
   containers:
   - name: Tomcat
    image: tomcat: 8.0
    ports:
containerPort: 7500
   imagePullPolicy: Always
   -name: Database
   Image: mongoDB
   Ports:
containerPort: 7501
   imagePullPolicy: Always

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

Replication Controller เป็นหนึ่งในคุณสมบัติหลักของ Kubernetes ซึ่งมีหน้าที่จัดการวงจรชีวิตของพ็อด มีหน้าที่รับผิดชอบในการตรวจสอบให้แน่ใจว่าจำนวนการจำลองพ็อดที่ระบุกำลังทำงานอยู่ ณ เวลาใดก็ได้ ใช้ในช่วงเวลาที่ต้องการให้แน่ใจว่าจำนวนพ็อดที่ระบุหรืออย่างน้อยหนึ่งพ็อดกำลังทำงานอยู่ มีความสามารถในการนำขึ้นหรือลงไม่มีพ็อดที่ระบุ

เป็นแนวทางปฏิบัติที่ดีที่สุดในการใช้ตัวควบคุมการจำลองเพื่อจัดการวงจรชีวิตของพ็อดแทนที่จะสร้างพ็อดซ้ำแล้วซ้ำเล่า

apiVersion: v1
kind: ReplicationController --------------------------> 1
metadata:
   name: Tomcat-ReplicationController --------------------------> 2
spec:
   replicas: 3 ------------------------> 3
   template:
      metadata:
         name: Tomcat-ReplicationController
      labels:
         app: App
         component: neo4j
      spec:
         containers:
         - name: Tomcat- -----------------------> 4
         image: tomcat: 8.0
         ports:
            - containerPort: 7474 ------------------------> 5

รายละเอียดการตั้งค่า

• Kind: ReplicationController →ในโค้ดด้านบนเราได้กำหนดชนิดเป็นตัวควบคุมการจำลองซึ่งบอก kubectl ว่า yaml จะถูกใช้ในการสร้างตัวควบคุมการจำลอง

• name: Tomcat-ReplicationController→สิ่งนี้ช่วยในการระบุชื่อที่จะสร้างตัวควบคุมการจำลอง ถ้าเราเรียกใช้ kubctl รับrc < Tomcat-ReplicationController > มันจะแสดงรายละเอียดตัวควบคุมการจำลอง

• replicas: 3 →สิ่งนี้ช่วยให้ตัวควบคุมการจำลองแบบเข้าใจว่าจำเป็นต้องรักษาแบบจำลองของพ็อดสามแบบ ณ เวลาใดก็ได้ในวงจรชีวิตของพ็อด

• name: Tomcat →ในส่วนข้อมูลจำเพาะเราได้กำหนดชื่อเป็นแมวตัวผู้ซึ่งจะบอกตัวควบคุมการจำลองว่าคอนเทนเนอร์ที่อยู่ภายในพ็อดนั้นเป็นแมวตัวผู้

• containerPort: 7474 →ช่วยในการตรวจสอบให้แน่ใจว่าโหนดทั้งหมดในคลัสเตอร์ที่พ็อดกำลังเรียกใช้คอนเทนเนอร์ภายในพ็อดจะถูกเปิดเผยบนพอร์ต 7474 เดียวกัน

ที่นี่บริการ Kubernetes ทำงานเป็นตัวจัดสรรภาระงานสำหรับตัวจำลอง Tomcat สามตัว

Replica Set ช่วยให้มั่นใจได้ว่าควรจะเรียกใช้พ็อดจำลองจำนวนเท่าใด ถือได้ว่าเป็นการแทนที่ตัวควบคุมการจำลองแบบ ความแตกต่างที่สำคัญระหว่างชุดการจำลองและตัวควบคุมการจำลองคือตัวควบคุมการจำลองสนับสนุนเฉพาะตัวเลือกที่ยึดตามความเท่าเทียมกันในขณะที่ชุดการจำลองสนับสนุนตัวเลือกตามชุด

apiVersion: extensions/v1beta1 --------------------->1
kind: ReplicaSet --------------------------> 2
metadata:
   name: Tomcat-ReplicaSet
spec:
   replicas: 3
   selector:
      matchLables:
         tier: Backend ------------------> 3
      matchExpression:
{ key: tier, operation: In, values: [Backend]} --------------> 4
template:
   metadata:
      lables:
         app: Tomcat-ReplicaSet
         tier: Backend
      labels:
         app: App
         component: neo4j
   spec:
      containers:
      - name: Tomcat
      image: tomcat: 8.0
      ports:
      - containerPort: 7474

รายละเอียดการตั้งค่า

• apiVersion: extensions/v1beta1 →ในโค้ดด้านบนเวอร์ชัน API คือ Kubernetes เวอร์ชันเบต้าขั้นสูงซึ่งรองรับแนวคิดของชุดข้อมูลจำลอง

• kind: ReplicaSet →เราได้กำหนดชนิดเป็นชุดแบบจำลองซึ่งช่วยให้ kubectl เข้าใจว่าไฟล์นั้นใช้ในการสร้างชุดแบบจำลอง

• tier: Backend →เราได้กำหนดระดับป้ายกำกับเป็นแบ็กเอนด์ซึ่งสร้างตัวเลือกที่ตรงกัน

• {key: tier, operation: In, values: [Backend]} →สิ่งนี้จะช่วยได้ matchExpression เพื่อทำความเข้าใจเงื่อนไขการจับคู่ที่เรากำหนดไว้และในการดำเนินการที่ใช้โดย matchlabel เพื่อค้นหารายละเอียด

เรียกใช้ไฟล์ด้านบนโดยใช้ kubectl และสร้างชุดแบบจำลองแบ็กเอนด์ที่มีคำจำกัดความที่ให้ไว้ในไฟล์ yaml ไฟล์.

การปรับใช้ได้รับการอัพเกรดและตัวควบคุมการจำลองรุ่นที่สูงขึ้น พวกเขาจัดการการปรับใช้ชุดข้อมูลจำลองซึ่งเป็นเวอร์ชันอัพเกรดของตัวควบคุมการจำลองด้วย พวกเขามีความสามารถในการอัปเดตชุดข้อมูลจำลองและยังสามารถย้อนกลับไปใช้เวอร์ชันก่อนหน้าได้อีกด้วย

พวกเขามีคุณสมบัติที่อัปเดตมากมายของ matchLabels และ selectors. เรามีตัวควบคุมใหม่ใน Kubernetes ต้นแบบที่เรียกว่าตัวควบคุมการปรับใช้ซึ่งจะทำให้เกิดขึ้น มีความสามารถในการเปลี่ยนแปลงการปรับใช้กลางคัน

การเปลี่ยนการปรับใช้

Updating- ผู้ใช้สามารถอัปเดตการปรับใช้อย่างต่อเนื่องก่อนที่จะเสร็จสมบูรณ์ ในกรณีนี้การปรับใช้ที่มีอยู่จะถูกตัดสินและการปรับใช้ใหม่จะถูกสร้างขึ้น

Deleting- ผู้ใช้สามารถหยุดชั่วคราว / ยกเลิกการปรับใช้โดยการลบก่อนที่จะเสร็จสิ้น การสร้างการปรับใช้เหมือนเดิมอีกครั้งจะดำเนินการต่อ

Rollback- เราสามารถย้อนกลับการปรับใช้หรือการปรับใช้ที่อยู่ระหว่างดำเนินการ ผู้ใช้สามารถสร้างหรืออัพเดตการปรับใช้โดยใช้DeploymentSpec.PodTemplateSpec = oldRC.PodTemplateSpec.

กลยุทธ์การปรับใช้

กลยุทธ์การปรับใช้ช่วยในการกำหนดว่า RC ใหม่ควรแทนที่ RC ที่มีอยู่อย่างไร

Recreate- คุณสมบัตินี้จะฆ่า RC ที่มีอยู่ทั้งหมดแล้วเปิดขึ้นมาใหม่ ส่งผลให้ใช้งานได้อย่างรวดเร็ว แต่จะส่งผลให้เกิดการหยุดทำงานเมื่อพ็อดเก่าไม่ทำงานและพ็อดใหม่ยังไม่เกิด

Rolling Update- คุณลักษณะนี้จะค่อยๆลด RC เก่าและนำมาใช้ใหม่ ส่งผลให้การปรับใช้งานช้า แต่ไม่มีการปรับใช้ ตลอดเวลามีฝักเก่าไม่กี่ฝักและฝักใหม่ไม่กี่ฝักในกระบวนการนี้

ไฟล์คอนฟิกูเรชันของ Deployment มีลักษณะดังนี้

apiVersion: extensions/v1beta1 --------------------->1
kind: Deployment --------------------------> 2
metadata:
   name: Tomcat-ReplicaSet
spec:
   replicas: 3
   template:
      metadata:
         lables:
            app: Tomcat-ReplicaSet
            tier: Backend
   spec:
      containers:
         - name: Tomcatimage:
            tomcat: 8.0
            ports:
               - containerPort: 7474

ในโค้ดด้านบนสิ่งเดียวที่แตกต่างจากชุดข้อมูลจำลองคือเราได้กำหนดชนิดเป็นการปรับใช้

สร้างการปรับใช้

$ kubectl create –f Deployment.yaml -–record
deployment "Deployment" created Successfully.

ดึงข้อมูลการปรับใช้

$ kubectl get deployments
NAME           DESIRED     CURRENT     UP-TO-DATE     AVILABLE    AGE
Deployment        3           3           3              3        20s

ตรวจสอบสถานะการปรับใช้

$ kubectl rollout status deployment/Deployment

การอัปเดตการปรับใช้

$ kubectl set image deployment/Deployment tomcat=tomcat:6.0

ย้อนกลับไปที่การปรับใช้ก่อนหน้า

$ kubectl rollout undo deployment/Deployment –to-revision=2

ใน Kubernetes สามารถคิดไดเร็กทอรีเป็นไดเร็กทอรีที่สามารถเข้าถึงได้จากคอนเทนเนอร์ในพ็อด เรามีไดรฟ์ข้อมูลประเภทต่างๆใน Kubernetes และประเภทนี้จะกำหนดวิธีสร้างโวลุ่มและเนื้อหา

แนวคิดเรื่องปริมาณมีอยู่ใน Docker อย่างไรก็ตามปัญหาเดียวคือปริมาณถูก จำกัด ไว้ที่พ็อดเฉพาะอย่างมาก ทันทีที่อายุการใช้งานของพ็อดสิ้นสุดลงปริมาณก็หายไปเช่นกัน

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

ประเภทของ Kubernetes Volume

นี่คือรายการของ Kubernetes Volumes ยอดนิยม -

• emptyDir- เป็นประเภทของโวลุ่มที่สร้างขึ้นเมื่อ Pod ถูกกำหนดให้กับ Node เป็นครั้งแรก มันยังคงใช้งานได้ตราบเท่าที่ Pod ทำงานบนโหนดนั้น ไดรฟ์ข้อมูลในตอนแรกว่างเปล่าและคอนเทนเนอร์ในพ็อดสามารถอ่านและเขียนไฟล์ในโวลุ่ม emptyDir เมื่อ Pod ถูกลบออกจากโหนดข้อมูลใน emptyDir จะถูกลบ

• hostPath - โวลุ่มประเภทนี้จะติดตั้งไฟล์หรือไดเร็กทอรีจากระบบไฟล์ของโหนดโฮสต์ลงในพ็อดของคุณ

• gcePersistentDisk- โวลุ่มประเภทนี้จะติดตั้งดิสก์ถาวรของ Google Compute Engine (GCE) ลงในพ็อดของคุณ ข้อมูลในไฟล์gcePersistentDisk ยังคงเหมือนเดิมเมื่อนำ Pod ออกจากโหนด

• awsElasticBlockStore- ไดรฟ์ข้อมูลประเภทนี้ติดตั้ง Amazon Web Services (AWS) Elastic Block Store ไว้ใน Pod ของคุณ เหมือนกับgcePersistentDiskข้อมูลในไฟล์ awsElasticBlockStore ยังคงเหมือนเดิมเมื่อนำ Pod ออกจากโหนด

• nfs - อ nfsไดรฟ์ข้อมูลอนุญาตให้ติดตั้ง NFS (Network File System) ที่มีอยู่ในพ็อดของคุณ ข้อมูลในไฟล์nfsโวลุ่มจะไม่ถูกลบเมื่อนำพ็อดออกจากโหนด ไดรฟ์ข้อมูลจะถูกยกเลิกการต่อเชื่อมเท่านั้น

• iscsi - อ iscsi ไดรฟ์ข้อมูลอนุญาตให้ติดตั้งไดรฟ์ข้อมูล iSCSI (SCSI over IP) ที่มีอยู่ในพ็อดของคุณ

• flocker- เป็นตัวจัดการปริมาณข้อมูลคอนเทนเนอร์แบบโอเพ่นซอร์สที่คลัสเตอร์ ใช้สำหรับจัดการปริมาณข้อมูล กflockerไดรฟ์ข้อมูลอนุญาตให้ติดตั้งชุดข้อมูล Flocker ลงในพ็อด หากชุดข้อมูลไม่มีอยู่ใน Flocker ก่อนอื่นคุณต้องสร้างโดยใช้ Flocker API

• glusterfs- Glusterfs เป็นระบบไฟล์เครือข่ายโอเพ่นซอร์ส ไดรฟ์ข้อมูล glusterfs อนุญาตให้ติดตั้งไดรฟ์ข้อมูล glusterfs ลงในพ็อดของคุณ

• rbd- RBD ย่อมาจาก Rados Block Device อันrbdระดับเสียงอนุญาตให้ติดตั้งวอลลุ่ม Rados Block Device ในพ็อดของคุณ ข้อมูลจะยังคงถูกเก็บรักษาไว้หลังจากที่นำ Pod ออกจากโหนด

• cephfs - ก cephfsไดรฟ์ข้อมูลอนุญาตให้ติดตั้งโวลุ่ม CephFS ที่มีอยู่ลงในพ็อดของคุณ ข้อมูลยังคงเหมือนเดิมหลังจากที่นำ Pod ออกจากโหนด

• gitRepo - ก gitRepo ไดรฟ์ข้อมูลติดตั้งไดเร็กทอรีว่างและโคลน a git ที่เก็บไว้เพื่อให้พ็อดของคุณใช้

• secret - ก secret โวลุ่มใช้เพื่อส่งผ่านข้อมูลที่ละเอียดอ่อนเช่นรหัสผ่านไปยังพ็อด

• persistentVolumeClaim - ก persistentVolumeClaimวอลลุ่มใช้เพื่อเมานต์ PersistentVolume ลงในพ็อด PersistentVolumes เป็นวิธีที่ผู้ใช้ "อ้างสิทธิ์" พื้นที่เก็บข้อมูลที่ทนทาน (เช่น GCE PersistentDisk หรือไดรฟ์ข้อมูล iSCSI) โดยไม่ทราบรายละเอียดของสภาพแวดล้อมระบบคลาวด์โดยเฉพาะ

• downwardAPI - ก downwardAPIปริมาณใช้เพื่อทำให้ข้อมูล API ขาลงพร้อมใช้งานสำหรับแอปพลิเคชัน ติดตั้งไดเร็กทอรีและเขียนข้อมูลที่ร้องขอในไฟล์ข้อความธรรมดา

• azureDiskVolume - อ AzureDiskVolume ใช้เพื่อติดตั้ง Microsoft Azure Data Disk ลงใน Pod

การอ้างสิทธิ์ปริมาณต่อเนื่องและปริมาณที่ต่อเนื่อง

Persistent Volume (PV)- เป็นพื้นที่เก็บข้อมูลเครือข่ายที่ได้รับการจัดสรรโดยผู้ดูแลระบบ เป็นทรัพยากรในคลัสเตอร์ซึ่งไม่ขึ้นกับพ็อดใด ๆ ที่ใช้ PV

Persistent Volume Claim (PVC)- พื้นที่จัดเก็บที่ Kubernetes ร้องขอสำหรับพ็อดเรียกว่า PVC ผู้ใช้ไม่จำเป็นต้องทราบการจัดเตรียมพื้นฐาน ต้องสร้างการอ้างสิทธิ์ในเนมสเปซเดียวกับที่สร้างพ็อด

การสร้าง Persistent Volume

kind: PersistentVolume ---------> 1
apiVersion: v1
metadata:
   name: pv0001 ------------------> 2
   labels:
      type: local
spec:
   capacity: -----------------------> 3
      storage: 10Gi ----------------------> 4
   accessModes:
      - ReadWriteOnce -------------------> 5
      hostPath:
         path: "/tmp/data01" --------------------------> 6

ในโค้ดข้างต้นเราได้กำหนด -

• kind: PersistentVolume →เราได้กำหนดชนิดเป็น PersistentVolume ซึ่งบอก kubernetes ว่าไฟล์ yaml ที่ใช้คือการสร้าง Persistent Volume

• name: pv0001 →ชื่อ PersistentVolume ที่เรากำลังสร้าง

• capacity: →ข้อมูลจำเพาะนี้จะกำหนดความจุของ PV ที่เราพยายามสร้าง

• storage: 10Gi →นี่เป็นการบอกโครงสร้างพื้นฐานที่เราพยายามอ้างสิทธิ์พื้นที่ 10Gi บนเส้นทางที่กำหนด

• ReadWriteOnce →สิ่งนี้บอกสิทธิ์การเข้าถึงของไดรฟ์ข้อมูลที่เรากำลังสร้าง

• path: "/tmp/data01" →คำจำกัดความนี้บอกเครื่องว่าเรากำลังพยายามสร้างไดรฟ์ข้อมูลภายใต้เส้นทางนี้บนโครงสร้างพื้นฐานพื้นฐาน

การสร้าง PV

$ kubectl create –f local-01.yaml
persistentvolume "pv0001" created

ตรวจสอบ PV

$ kubectl get pv
NAME        CAPACITY      ACCESSMODES       STATUS       CLAIM      REASON     AGE
pv0001        10Gi            RWO         Available                            14s

อธิบาย PV

$ kubectl describe pv pv0001

การสร้างการอ้างสิทธิ์แบบต่อเนื่อง

kind: PersistentVolumeClaim --------------> 1
apiVersion: v1
metadata:
   name: myclaim-1 --------------------> 2
spec:
   accessModes:
      - ReadWriteOnce ------------------------> 3
   resources:
      requests:
         storage: 3Gi ---------------------> 4

ในโค้ดข้างต้นเราได้กำหนด -

• kind: PersistentVolumeClaim →มันสั่งโครงสร้างพื้นฐานที่เราพยายามอ้างสิทธิ์ตามจำนวนพื้นที่ที่กำหนด

• name: myclaim-1 →ชื่อการอ้างสิทธิ์ที่เราพยายามสร้าง

• ReadWriteOnce →นี่เป็นการระบุโหมดของการอ้างสิทธิ์ที่เราพยายามสร้างขึ้น

• storage: 3Gi →สิ่งนี้จะบอก kubernetes เกี่ยวกับจำนวนพื้นที่ที่เราพยายามอ้างสิทธิ์

การสร้างพีวีซี

$ kubectl create –f myclaim-1
persistentvolumeclaim "myclaim-1" created

ขอรายละเอียดเกี่ยวกับ PVC

$ kubectl get pvc
NAME        STATUS   VOLUME   CAPACITY   ACCESSMODES   AGE
myclaim-1   Bound    pv0001     10Gi         RWO       7s

อธิบาย PVC

$ kubectl describe pv pv0001

ใช้ PV และ PVC กับ POD

kind: Pod
apiVersion: v1
metadata:
   name: mypod
   labels:
      name: frontendhttp
spec:
   containers:
   - name: myfrontend
      image: nginx
      ports:
      - containerPort: 80
         name: "http-server"
      volumeMounts: ----------------------------> 1
      - mountPath: "/usr/share/tomcat/html"
         name: mypd
   volumes: -----------------------> 2
      - name: mypd
         persistentVolumeClaim: ------------------------->3
         claimName: myclaim-1

ในโค้ดข้างต้นเราได้กำหนด -

• volumeMounts: →นี่คือเส้นทางในภาชนะที่จะทำการติดตั้ง

• Volume: →คำจำกัดความนี้กำหนดคำจำกัดความของปริมาณที่เราจะอ้าง

• persistentVolumeClaim: →ภายใต้สิ่งนี้เรากำหนดชื่อโวลุ่มที่เราจะใช้ในพ็อดที่กำหนด

ความลับสามารถกำหนดเป็นออบเจ็กต์ Kubernetes ที่ใช้ในการจัดเก็บข้อมูลที่ละเอียดอ่อนเช่นชื่อผู้ใช้และรหัสผ่านด้วยการเข้ารหัส

มีหลายวิธีในการสร้างความลับใน Kubernetes

• สร้างจากไฟล์ txt
• สร้างจากไฟล์ yaml

การสร้างจากไฟล์ข้อความ

ในการสร้างความลับจากไฟล์ข้อความเช่นชื่อผู้ใช้และรหัสผ่านอันดับแรกเราต้องเก็บไว้ในไฟล์ txt และใช้คำสั่งต่อไปนี้

$ kubectl create secret generic tomcat-passwd –-from-file = ./username.txt –fromfile = ./.
password.txt

การสร้างจากไฟล์ Yaml

apiVersion: v1
kind: Secret
metadata:
name: tomcat-pass
type: Opaque
data:
   password: <User Password>
   username: <User Name>

การสร้างความลับ

$ kubectl create –f Secret.yaml
secrets/tomcat-pass

การใช้ความลับ

เมื่อเราสร้างความลับแล้วก็สามารถใช้ในพ็อดหรือตัวควบคุมการจำลองเป็น -

• ตัวแปรสภาพแวดล้อม
• Volume

เป็นตัวแปรสภาพแวดล้อม

ในการใช้ความลับเป็นตัวแปรสภาพแวดล้อมเราจะใช้ env ภายใต้ส่วนข้อมูลจำเพาะของไฟล์ pod yaml

env:
- name: SECRET_USERNAME
   valueFrom:
      secretKeyRef:
         name: mysecret
         key: tomcat-pass

เป็น Volume

spec:
   volumes:
      - name: "secretstest"
         secret:
            secretName: tomcat-pass
   containers:
      - image: tomcat:7.0
         name: awebserver
         volumeMounts:
            - mountPath: "/tmp/mysec"
            name: "secretstest"

การกำหนดค่าความลับเป็นตัวแปรสภาพแวดล้อม

apiVersion: v1
kind: ReplicationController
metadata:
   name: appname
spec:
replicas: replica_count
template:
   metadata:
      name: appname
   spec:
      nodeSelector:
         resource-group:
      containers:
         - name: appname
            image:
            imagePullPolicy: Always
            ports:
            - containerPort: 3000
            env: -----------------------------> 1
               - name: ENV
                  valueFrom:
                     configMapKeyRef:
                        name: appname
                        key: tomcat-secrets

ในรหัสด้านบนภายใต้ env นิยามเราใช้ความลับเป็นตัวแปรสภาพแวดล้อมในตัวควบคุมการจำลอง

ความลับเป็น Volume Mount

apiVersion: v1
kind: pod
metadata:
   name: appname
spec:
   metadata:
      name: appname
   spec:
   volumes:
      - name: "secretstest"
         secret:
            secretName: tomcat-pass
   containers:
      - image: tomcat: 8.0
         name: awebserver
         volumeMounts:
            - mountPath: "/tmp/mysec"
            name: "secretstest"

นโยบายเครือข่ายกำหนดวิธีที่พ็อดในเนมสเปซเดียวกันจะสื่อสารกันและปลายทางของเครือข่าย มันต้องการextensions/v1beta1/networkpoliciesเพื่อเปิดใช้งานในคอนฟิกูเรชันรันไทม์ในเซิร์ฟเวอร์ API ทรัพยากรใช้เลเบลเพื่อเลือกพ็อดและกำหนดกฎเพื่ออนุญาตการรับส่งข้อมูลไปยังพ็อดเฉพาะนอกเหนือจากที่กำหนดไว้ในเนมสเปซ

ขั้นแรกเราต้องกำหนดค่านโยบายการแยกเนมสเปซ โดยทั่วไปต้องใช้นโยบายเครือข่ายประเภทนี้ในตัวโหลดบาลานเซอร์

kind: Namespace
apiVersion: v1
metadata:
   annotations:
      net.beta.kubernetes.io/network-policy: |
      {
         "ingress": 
         {
            "isolation": "DefaultDeny"
         }
      }

$ kubectl annotate ns <namespace> "net.beta.kubernetes.io/network-policy = 
{\"ingress\": {\"isolation\": \"DefaultDeny\"}}"

เมื่อสร้างเนมสเปซแล้วเราจำเป็นต้องสร้างนโยบายเครือข่าย

Yaml นโยบายเครือข่าย

kind: NetworkPolicy
apiVersion: extensions/v1beta1
metadata:
   name: allow-frontend
   namespace: myns
spec:
   podSelector:
      matchLabels:
         role: backend
   ingress:
   - from:
      - podSelector:
         matchLabels:
            role: frontend
   ports:
      - protocol: TCP
         port: 6379

Kubernetes API ทำหน้าที่เป็นรากฐานสำหรับสคีมาการกำหนดค่าที่เปิดเผยสำหรับระบบ Kubectlเครื่องมือบรรทัดคำสั่งสามารถใช้เพื่อสร้างอัปเดตลบและรับออบเจ็กต์ API Kubernetes API ทำหน้าที่สื่อสารระหว่างส่วนประกอบต่างๆของ Kubernetes

การเพิ่ม API ไปยัง Kubernetes

การเพิ่ม API ใหม่ลงใน Kubernetes จะเพิ่มคุณลักษณะใหม่ ๆ ให้กับ Kubernetes ซึ่งจะช่วยเพิ่มฟังก์ชันการทำงานของ Kubernetes อย่างไรก็ตามนอกจากนี้ยังจะเพิ่มต้นทุนและความสามารถในการบำรุงรักษาระบบ เพื่อสร้างความสมดุลระหว่างต้นทุนและความซับซ้อนมีการกำหนดไว้สองสามชุด

API ที่กำลังจะเพิ่มควรมีประโยชน์กับผู้ใช้มากกว่า 50% ไม่มีวิธีอื่นในการใช้ฟังก์ชันใน Kubernetes มีการพูดถึงสถานการณ์พิเศษในการประชุมชุมชนของ Kubernetes จากนั้นจึงเพิ่ม API

การเปลี่ยนแปลง API

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

เพื่อแสดงให้เห็นถึงกระบวนการทั่วไปนี่คือตัวอย่าง (สมมุติฐาน) -

• ผู้ใช้โพสต์วัตถุ Pod ให้ /api/v7beta1/...

• JSON ไม่แปรเปลี่ยนเป็นไฟล์ v7beta1.Pod โครงสร้าง

• ค่าดีฟอลต์ถูกนำไปใช้กับไฟล์ v7beta1.Pod

• v7beta1.Pod ถูกแปลงเป็นไฟล์ api.Pod โครงสร้าง

• api.Pod ได้รับการตรวจสอบและข้อผิดพลาดใด ๆ จะถูกส่งกลับไปยังผู้ใช้

• api.Pod ถูกแปลงเป็น v6.Pod (เนื่องจาก v6 เป็นเวอร์ชันเสถียรล่าสุด)

• v6.Pod จัดเป็น JSON และเขียนถึง etcd

ตอนนี้เรามีวัตถุ Pod ที่จัดเก็บแล้วผู้ใช้สามารถรับวัตถุนั้นในเวอร์ชัน API ที่รองรับ ตัวอย่างเช่น -

• ผู้ใช้รับ Pod จาก /api/v5/...

• JSON อ่านได้จาก etcd และ unmarshalled เป็น v6.Pod โครงสร้าง

• ค่าดีฟอลต์ถูกนำไปใช้กับไฟล์ v6.Pod

• v6.Pod ถูกแปลงเป็นโครงสร้าง api.Pod

• api.Pod ถูกแปลงเป็นไฟล์ v5.Pod โครงสร้าง

• v5.Pod จะถูกจัดเป็น JSON และส่งไปยังผู้ใช้

ผลกระทบของกระบวนการนี้คือการเปลี่ยนแปลง API ต้องกระทำอย่างรอบคอบและย้อนกลับไปได้

การกำหนดเวอร์ชัน API

เพื่อให้ง่ายต่อการรองรับโครงสร้างต่างๆ Kubernetes จึงรองรับ API หลายเวอร์ชันในแต่ละเส้นทางของ API เช่น /api/v1 หรือ /apsi/extensions/v1beta1

มาตรฐานการกำหนดเวอร์ชันที่ Kubernetes กำหนดไว้หลายมาตรฐาน

ระดับอัลฟ่า

• เวอร์ชันนี้มีอัลฟา (เช่น v1alpha1)

• เวอร์ชันนี้อาจเป็นรถ เวอร์ชันที่เปิดใช้งานอาจมีข้อบกพร่อง

• การรองรับข้อบกพร่องสามารถลดลงได้ทุกเมื่อ

• แนะนำให้ใช้ในการทดสอบระยะสั้นเท่านั้นเนื่องจากการสนับสนุนอาจไม่มีอยู่ตลอดเวลา

ระดับเบต้า

• ชื่อเวอร์ชันประกอบด้วยเบต้า (เช่น v2beta3)

• โค้ดได้รับการทดสอบอย่างสมบูรณ์และเวอร์ชันที่เปิดใช้งานควรจะเสถียร

• การสนับสนุนของคุณสมบัติจะไม่ถูกทิ้ง อาจมีการเปลี่ยนแปลงเล็กน้อย

• แนะนำสำหรับการใช้งานที่ไม่สำคัญทางธุรกิจเท่านั้นเนื่องจากอาจเกิดการเปลี่ยนแปลงที่เข้ากันไม่ได้ในรุ่นต่อ ๆ ไป

ระดับคงที่

• ชื่อเวอร์ชันคือ vX ที่ไหน X เป็นจำนวนเต็ม

• คุณลักษณะเวอร์ชันเสถียรจะปรากฏในซอฟต์แวร์ที่วางจำหน่ายสำหรับเวอร์ชันต่อ ๆ ไปอีกมากมาย

Kubectl เป็นยูทิลิตี้บรรทัดคำสั่งเพื่อโต้ตอบกับ Kubernetes API เป็นอินเทอร์เฟซที่ใช้ในการสื่อสารและจัดการพ็อดในคลัสเตอร์ Kubernetes

จำเป็นต้องตั้งค่า kubectl เป็น local เพื่อโต้ตอบกับคลัสเตอร์ Kubernetes

การตั้งค่า Kubectl

ดาวน์โหลดไฟล์ปฏิบัติการไปยังเวิร์กสเตชันโลคัลโดยใช้คำสั่ง curl

บน Linux

$ curl -O https://storage.googleapis.com/kubernetesrelease/
release/v1.5.2/bin/linux/amd64/kubectl

บนเวิร์กสเตชัน OS X

$ curl -O https://storage.googleapis.com/kubernetesrelease/
release/v1.5.2/bin/darwin/amd64/kubectl

หลังจากดาวน์โหลดเสร็จสิ้นให้ย้ายไบนารีในเส้นทางของระบบ

$ chmod +x kubectl
$ mv kubectl /usr/local/bin/kubectl

การกำหนดค่า Kubectl

ต่อไปนี้เป็นขั้นตอนในการดำเนินการกำหนดค่า

$ kubectl config set-cluster default-cluster --server = https://${MASTER_HOST} -- certificate-authority = ${CA_CERT}

$ kubectl config set-credentials default-admin --certificateauthority = ${
CA_CERT} --client-key = ${ADMIN_KEY} --clientcertificate = ${
ADMIN_CERT}

$ kubectl config set-context default-system --cluster = default-cluster -- user = default-admin $ kubectl config use-context default-system

• แทนที่ ${MASTER_HOST} ด้วยแอดเดรสโหนดหลักหรือชื่อที่ใช้ในขั้นตอนก่อนหน้านี้

• แทนที่ ${CA_CERT} ด้วยเส้นทางที่แน่นอนไปยัง ca.pem สร้างขึ้นในขั้นตอนก่อนหน้านี้

• แทนที่ ${ADMIN_KEY} ด้วยเส้นทางที่แน่นอนไปยัง admin-key.pem สร้างขึ้นในขั้นตอนก่อนหน้านี้

• แทนที่ ${ADMIN_CERT} ด้วยเส้นทางที่แน่นอนไปยัง admin.pem สร้างขึ้นในขั้นตอนก่อนหน้านี้

กำลังตรวจสอบการตั้งค่า

เพื่อตรวจสอบว่าไฟล์ kubectl ทำงานได้ดีหรือไม่ตรวจสอบว่าไคลเอ็นต์ Kubernetes ตั้งค่าถูกต้องหรือไม่

$ kubectl get nodes

NAME       LABELS                                     STATUS
Vipin.com  Kubernetes.io/hostname = vipin.mishra.com    Ready

Kubectlควบคุมคลัสเตอร์ Kubernetes เป็นหนึ่งในองค์ประกอบหลักของ Kubernetes ซึ่งทำงานบนเวิร์กสเตชันบนเครื่องใดก็ได้เมื่อการตั้งค่าเสร็จสิ้น มีความสามารถในการจัดการโหนดในคลัสเตอร์

Kubectlคำสั่งใช้เพื่อโต้ตอบและจัดการออบเจ็กต์ Kubernetes และคลัสเตอร์ ในบทนี้เราจะพูดถึงคำสั่งบางคำที่ใช้ใน Kubernetes ผ่านทาง kubectl

kubectl annotate - อัปเดตคำอธิบายประกอบบนทรัพยากร

$kubectl annotate [--overwrite] (-f FILENAME | TYPE NAME) KEY_1=VAL_1 ...
KEY_N = VAL_N [--resource-version = version]

ตัวอย่างเช่น,

kubectl annotate pods tomcat description = 'my frontend'

kubectl api-versions - พิมพ์ API เวอร์ชันที่รองรับบนคลัสเตอร์

$ kubectl api-version;

kubectl apply - มีความสามารถในการกำหนดค่าทรัพยากรตามไฟล์หรือ stdin

$ kubectl apply –f <filename>

kubectl attach - สิ่งนี้ยึดติดกับคอนเทนเนอร์ที่กำลังทำงานอยู่

$ kubectl attach <pod> –c <container> $ kubectl attach 123456-7890 -c tomcat-conatiner

kubectl autoscale - ใช้เพื่อปรับขนาดพ็อดอัตโนมัติที่กำหนดไว้เช่น Deployment, Replication Set, Replication Controller

$ kubectl autoscale (-f FILENAME | TYPE NAME | TYPE/NAME) [--min = MINPODS] -- max = MAXPODS [--cpu-percent = CPU] [flags] $ kubectl autoscale deployment foo --min = 2 --max = 10

kubectl cluster-info - จะแสดงข้อมูลคลัสเตอร์

$ kubectl cluster-info

kubectl cluster-info dump - ทิ้งข้อมูลที่เกี่ยวข้องเกี่ยวกับคลัสเตอร์สำหรับการดีบักและการวินิจฉัย

$ kubectl cluster-info dump
$ kubectl cluster-info dump --output-directory = /path/to/cluster-state

kubectl config - แก้ไขไฟล์ kubeconfig

$ kubectl config <SUBCOMMAD>
$ kubectl config –-kubeconfig <String of File name>

kubectl config current-context - แสดงบริบทปัจจุบัน

$ kubectl config current-context
#deploys the current context

kubectl config delete-cluster - ลบคลัสเตอร์ที่ระบุจาก kubeconfig

$ kubectl config delete-cluster <Cluster Name>

kubectl config delete-context - ลบบริบทที่ระบุจาก kubeconfig

$ kubectl config delete-context <Context Name>

kubectl config get-clusters - แสดงคลัสเตอร์ที่กำหนดไว้ใน kubeconfig

$ kubectl config get-cluster $ kubectl config get-cluster <Cluser Name>

kubectl config get-contexts - อธิบายบริบทหนึ่งหรือหลายบริบท

$ kubectl config get-context <Context Name>

kubectl config set-cluster - ตั้งค่ารายการคลัสเตอร์ใน Kubernetes

$ kubectl config set-cluster NAME [--server = server] [--certificateauthority =
path/to/certificate/authority] [--insecure-skip-tls-verify = true]

kubectl config set-context - ตั้งค่ารายการบริบทในจุดเข้าใช้ kubernetes

$ kubectl config set-context NAME [--cluster = cluster_nickname] [-- user = user_nickname] [--namespace = namespace] $ kubectl config set-context prod –user = vipin-mishra

kubectl config set-credentials - ตั้งค่ารายการผู้ใช้ใน kubeconfig

$ kubectl config set-credentials cluster-admin --username = vipin --
password = uXFGweU9l35qcif

kubectl config set - ตั้งค่าแต่ละค่าในไฟล์ kubeconfig

$ kubectl config set PROPERTY_NAME PROPERTY_VALUE

kubectl config unset - จะยกเลิกการตั้งค่าส่วนประกอบเฉพาะใน kubectl

$ kubectl config unset PROPERTY_NAME PROPERTY_VALUE

kubectl config use-context - ตั้งค่าบริบทปัจจุบันในไฟล์ kubectl

$ kubectl config use-context <Context Name>

kubectl config view

$ kubectl config view $ kubectl config view –o jsonpath='{.users[?(@.name == "e2e")].user.password}'

kubectl cp - คัดลอกไฟล์และไดเรกทอรีไปยังและจากคอนเทนเนอร์

$ kubectl cp <Files from source> <Files to Destinatiion> $ kubectl cp /tmp/foo <some-pod>:/tmp/bar -c <specific-container>

kubectl create- เพื่อสร้างทรัพยากรตามชื่อไฟล์หรือ stdin ในการดำเนินการนี้ยอมรับรูปแบบ JSON หรือ YAML

$ kubectl create –f <File Name> $ cat <file name> | kubectl create –f -

ในทำนองเดียวกันเราสามารถสร้างหลายสิ่งตามรายการโดยใช้ไฟล์ create คำสั่งพร้อมกับ kubectl.

• deployment
• namespace
• quota
• นักเทียบท่าที่เป็นความลับ
• secret
• ความลับทั่วไป
• tls ลับ
• serviceaccount
• คลัสเตอร์บริการ
• โหลดบาลานซ์บริการ
• ท่าเรือบริการ

kubectl delete - ลบทรัพยากรตามชื่อไฟล์ stdin ทรัพยากรและชื่อ

$ kubectl delete –f ([-f FILENAME] | TYPE [(NAME | -l label | --all)])

kubectl describe- อธิบายทรัพยากรเฉพาะใน kubernetes แสดงรายละเอียดของทรัพยากรหรือกลุ่มของทรัพยากร

$ kubectl describe <type> <type name>
$ kubectl describe pod tomcat

kubectl drain- ใช้เพื่อระบายโหนดเพื่อการบำรุงรักษา เตรียมโหนดสำหรับการบำรุงรักษา การดำเนินการนี้จะทำเครื่องหมายโหนดว่าไม่พร้อมใช้งานดังนั้นจึงไม่ควรกำหนดด้วยคอนเทนเนอร์ใหม่ที่จะสร้างขึ้น

$ kubectl drain tomcat –force

kubectl edit- ใช้เพื่อสิ้นสุดทรัพยากรบนเซิร์ฟเวอร์ สิ่งนี้ช่วยให้สามารถแก้ไขทรัพยากรที่สามารถรับได้โดยตรงผ่านเครื่องมือบรรทัดคำสั่ง

$ kubectl edit <Resource/Name | File Name) Ex. $ kubectl edit rc/tomcat

kubectl exec - สิ่งนี้ช่วยในการดำเนินการคำสั่งในคอนเทนเนอร์

$ kubectl exec POD <-c CONTAINER > -- COMMAND < args...> $ kubectl exec tomcat 123-5-456 date

kubectl expose- ใช้เพื่อแสดงออบเจ็กต์ Kubernetes เช่นพ็อดตัวควบคุมการจำลองและบริการเป็นบริการ Kubernetes ใหม่ สิ่งนี้มีความสามารถในการเปิดเผยผ่านคอนเทนเนอร์ที่กำลังทำงานอยู่หรือจากไฟล์yaml ไฟล์.

$ kubectl expose (-f FILENAME | TYPE NAME) [--port=port] [--protocol = TCP|UDP] [--target-port = number-or-name] [--name = name] [--external-ip = external-ip-ofservice] [--type = type] $ kubectl expose rc tomcat –-port=80 –target-port = 30000
$ kubectl expose –f tomcat.yaml –port = 80 –target-port =

kubectl get - คำสั่งนี้สามารถดึงข้อมูลบนคลัสเตอร์เกี่ยวกับทรัพยากร Kubernetes ได้

$ kubectl get [(-o|--output=)json|yaml|wide|custom-columns=...|custom-columnsfile=...|
go-template=...|go-template-file=...|jsonpath=...|jsonpath-file=...]
(TYPE [NAME | -l label] | TYPE/NAME ...) [flags]

ตัวอย่างเช่น,

$ kubectl get pod <pod name> $ kubectl get service <Service name>

kubectl logs- ใช้เพื่อรับบันทึกของคอนเทนเนอร์ในฝัก การพิมพ์บันทึกสามารถกำหนดชื่อคอนเทนเนอร์ในพ็อดได้ หาก POD มีเพียงคอนเทนเนอร์เดียวก็ไม่จำเป็นต้องกำหนดชื่อ

$ kubectl logs [-f] [-p] POD [-c CONTAINER] Example $ kubectl logs tomcat.
$ kubectl logs –p –c tomcat.8

kubectl port-forward - ใช้เพื่อส่งต่อพอร์ตท้องถิ่นอย่างน้อยหนึ่งพอร์ตไปยังพ็อด

$ kubectl port-forward POD [LOCAL_PORT:]REMOTE_PORT
[...[LOCAL_PORT_N:]REMOTE_PORT_N]
$ kubectl port-forward tomcat 3000 4000 $ kubectl port-forward tomcat 3000:5000

kubectl replace - สามารถแทนที่ทรัพยากรด้วยชื่อไฟล์หรือ stdin.

$ kubectl replace -f FILENAME $ kubectl replace –f tomcat.yml
$ cat tomcat.yml | kubectl replace –f -

kubectl rolling-update- ดำเนินการอัปเดตแบบต่อเนื่องบนตัวควบคุมการจำลองแบบ แทนที่ตัวควบคุมการจำลองที่ระบุด้วยตัวควบคุมการจำลองแบบใหม่โดยการอัพเดต POD ในแต่ละครั้ง

$ kubectl rolling-update OLD_CONTROLLER_NAME ([NEW_CONTROLLER_NAME] --
image = NEW_CONTAINER_IMAGE | -f NEW_CONTROLLER_SPEC)
$ kubectl rolling-update frontend-v1 –f freontend-v2.yaml

kubectl rollout - สามารถจัดการการเปิดตัวการใช้งานได้

$ Kubectl rollout <Sub Command>
$ kubectl rollout undo deployment/tomcat

นอกเหนือจากที่กล่าวมาเราสามารถทำงานได้หลายอย่างโดยใช้การเปิดตัวเช่น -

• ประวัติการเปิดตัว
• หยุดการเปิดตัวชั่วคราว
• ประวัติย่อการเปิดตัว
• สถานะการเปิดตัว
• ยกเลิกการเปิดตัว

kubectl run - คำสั่ง Run มีความสามารถในการเรียกใช้รูปภาพบนคลัสเตอร์ Kubernetes

$ kubectl run NAME --image = image [--env = "key = value"] [--port = port] [--
replicas = replicas] [--dry-run = bool] [--overrides = inline-json] [--command] --
[COMMAND] [args...]
$ kubectl run tomcat --image = tomcat:7.0 $ kubectl run tomcat –-image = tomcat:7.0 –port = 5000

kubectl scale - จะปรับขนาดของ Kubernetes Deployments, ReplicaSet, Replication Controller หรืองาน

$ kubectl scale [--resource-version = version] [--current-replicas = count] -- replicas = COUNT (-f FILENAME | TYPE NAME ) $ kubectl scale –-replica = 3 rs/tomcat
$ kubectl scale –replica = 3 tomcat.yaml

kubectl set image - อัปเดตรูปภาพของเทมเพลตพ็อด

$ kubectl set image (-f FILENAME | TYPE NAME)
CONTAINER_NAME_1 = CONTAINER_IMAGE_1 ... CONTAINER_NAME_N = CONTAINER_IMAGE_N
$ kubectl set image deployment/tomcat busybox = busybox ngnix = ngnix:1.9.1 $ kubectl set image deployments, rc tomcat = tomcat6.0 --all

kubectl set resources- ใช้เพื่อกำหนดเนื้อหาของทรัพยากร อัปเดตทรัพยากร / ข้อ จำกัด เกี่ยวกับวัตถุด้วยเทมเพลตพ็อด

$ kubectl set resources (-f FILENAME | TYPE NAME) ([--limits = LIMITS & -- requests = REQUESTS] $ kubectl set resources deployment tomcat -c = tomcat --
limits = cpu = 200m,memory = 512Mi

kubectl top node- แสดงการใช้งาน CPU / หน่วยความจำ / ที่เก็บข้อมูล คำสั่งด้านบนช่วยให้คุณเห็นการใช้ทรัพยากรสำหรับโหนด

$ kubectl top node [node Name]

คำสั่งเดียวกันนี้สามารถใช้กับพ็อดได้เช่นกัน

ในการสร้างแอปพลิเคชันสำหรับการปรับใช้ Kubernetes เราต้องสร้างแอปพลิเคชันบน Docker ก่อน สามารถทำได้สองวิธี -

• โดยการดาวน์โหลด
• จากไฟล์ Docker

โดยการดาวน์โหลด

อิมเมจที่มีอยู่สามารถดาวน์โหลดได้จาก Docker hub และสามารถเก็บไว้ในรีจิสทรีของ Docker ภายในเครื่อง

ในการดำเนินการดังกล่าวให้เรียกใช้ Docker pull คำสั่ง

$ docker pull --help
Usage: docker pull [OPTIONS] NAME[:TAG|@DIGEST]
Pull an image or a repository from the registry
   -a, --all-tags = false     Download all tagged images in the repository
   --help = false             Print usage

ต่อไปนี้จะเป็นผลลัพธ์ของโค้ดด้านบน

ภาพหน้าจอด้านบนแสดงชุดภาพที่เก็บไว้ในรีจิสทรี Docker ในพื้นที่ของเรา

หากเราต้องการสร้างคอนเทนเนอร์จากรูปภาพซึ่งประกอบด้วยแอปพลิเคชันเพื่อทดสอบเราสามารถทำได้โดยใช้คำสั่ง Docker run

$ docker run –i –t unbunt /bin/bash

จาก Docker File

ในการสร้างแอปพลิเคชันจากไฟล์ Docker เราต้องสร้างไฟล์ Docker ก่อน

ต่อไปนี้เป็นตัวอย่างของไฟล์ Jenkins Docker

FROM ubuntu:14.04
MAINTAINER [email protected]
ENV REFRESHED_AT 2017-01-15
RUN apt-get update -qq && apt-get install -qqy curl
RUN curl https://get.docker.io/gpg | apt-key add -
RUN echo deb http://get.docker.io/ubuntu docker main > /etc/apt/↩
sources.list.d/docker.list
RUN apt-get update -qq && apt-get install -qqy iptables ca-↩
certificates lxc openjdk-6-jdk git-core lxc-docker
ENV JENKINS_HOME /opt/jenkins/data
ENV JENKINS_MIRROR http://mirrors.jenkins-ci.org
RUN mkdir -p $JENKINS_HOME/plugins
RUN curl -sf -o /opt/jenkins/jenkins.war -L $JENKINS_MIRROR/war-↩ stable/latest/jenkins.war RUN for plugin in chucknorris greenballs scm-api git-client git ↩ ws-cleanup ;\ do curl -sf -o $JENKINS_HOME/plugins/${plugin}.hpi \ -L $JENKINS_MIRROR/plugins/${plugin}/latest/${plugin}.hpi ↩
; done
ADD ./dockerjenkins.sh /usr/local/bin/dockerjenkins.sh
RUN chmod +x /usr/local/bin/dockerjenkins.sh
VOLUME /var/lib/docker
EXPOSE 8080
ENTRYPOINT [ "/usr/local/bin/dockerjenkins.sh" ]

เมื่อสร้างไฟล์ด้านบนแล้วให้บันทึกด้วยชื่อ Dockerfile และ cd ลงในพา ธ ไฟล์ จากนั้นรันคำสั่งต่อไปนี้

$ sudo docker build -t jamtur01/Jenkins .

เมื่อสร้างอิมเมจแล้วเราสามารถทดสอบว่ารูปภาพทำงานได้ดีและสามารถแปลงเป็นคอนเทนเนอร์ได้หรือไม่

$ docker run –i –t jamtur01/Jenkins /bin/bash

การทำให้ใช้งานได้คือวิธีการแปลงอิมเมจเป็นคอนเทนเนอร์จากนั้นจัดสรรอิมเมจเหล่านั้นไปยังพ็อดในคลัสเตอร์ Kubernetes นอกจากนี้ยังช่วยในการตั้งค่าคลัสเตอร์แอปพลิเคชันซึ่งรวมถึงการปรับใช้บริการพ็อดตัวควบคุมการจำลองและชุดการจำลอง คลัสเตอร์สามารถตั้งค่าในลักษณะที่แอปพลิเคชันที่ปรับใช้บนพ็อดสามารถสื่อสารกันได้

ในการตั้งค่านี้เราสามารถตั้งค่าตัวจัดสรรภาระงานที่ด้านบนของแอปพลิเคชันหนึ่งเพื่อเปลี่ยนการรับส่งข้อมูลไปยังชุดของพ็อดและหลังจากนั้นจะสื่อสารกับพ็อดแบ็กเอนด์ การสื่อสารระหว่างพ็อดเกิดขึ้นผ่านออบเจ็กต์บริการที่สร้างขึ้นใน Kubernetes

ไฟล์ Ngnix Load Balancer Yaml

apiVersion: v1
kind: Service
metadata:
   name: oppv-dev-nginx
      labels:
         k8s-app: omni-ppv-api
spec:
   type: NodePort
   ports:
   - port: 8080
      nodePort: 31999
      name: omninginx
   selector:
      k8s-app: appname
      component: nginx
      env: dev

Ngnix Replication Controller Yaml

apiVersion: v1
kind: ReplicationController
metadata:
   name: appname
spec:
   replicas: replica_count
   template:
      metadata:
         name: appname
         labels:
            k8s-app: appname
            component: nginx
               env: env_name
spec:
   nodeSelector:
      resource-group: oppv
   containers:
      - name: appname
      image: IMAGE_TEMPLATE
      imagePullPolicy: Always
      ports:
         - containerPort: 8080
         resources:
            requests:
               memory: "request_mem"
               cpu: "request_cpu"
            limits:
               memory: "limit_mem"
               cpu: "limit_cpu"
            env:
            - name: BACKEND_HOST
               value: oppv-env_name-node:3000

ไฟล์ Yaml บริการส่วนหน้า

apiVersion: v1
kind: Service
metadata:
   name: appname
   labels:
      k8s-app: appname
spec:
   type: NodePort
   ports:
   - name: http
      port: 3000
      protocol: TCP
      targetPort: 3000
   selector:
      k8s-app: appname
      component: nodejs
      env: dev

ไฟล์ Yaml ตัวควบคุมการจำลองส่วนหน้า

apiVersion: v1
kind: ReplicationController
metadata:
   name: Frontend
spec:
   replicas: 3
   template:
      metadata:
         name: frontend
         labels:
            k8s-app: Frontend
            component: nodejs
            env: Dev
spec:
   nodeSelector:
      resource-group: oppv
   containers:
      - name: appname
         image: IMAGE_TEMPLATE
         imagePullPolicy: Always
         ports:
            - containerPort: 3000
            resources:
               requests:
                  memory: "request_mem"
                  cpu: "limit_cpu"
                  limits:
                  memory: "limit_mem"
                  cpu: "limit_cpu"
            env:
               - name: ENV
               valueFrom:
               configMapKeyRef:
               name: appname
               key: config-env

ไฟล์ Yaml บริการแบ็กเอนด์

apiVersion: v1
kind: Service
metadata:
   name: backend
   labels:
      k8s-app: backend
spec:
   type: NodePort
   ports:
   - name: http
      port: 9010
      protocol: TCP
      targetPort: 9000
   selector:
      k8s-app: appname
      component: play
      env: dev

ไฟล์ Yaml ตัวควบคุมการจำลองที่สำรองไว้

apiVersion: v1
kind: ReplicationController
metadata:
   name: backend
spec:
   replicas: 3
   template:
      metadata:
         name: backend
      labels:
         k8s-app: beckend
         component: play
         env: dev
spec:
   nodeSelector:
      resource-group: oppv
      containers:
         - name: appname
            image: IMAGE_TEMPLATE
            imagePullPolicy: Always
            ports:
            - containerPort: 9000
            command: [ "./docker-entrypoint.sh" ]
            resources:
               requests:
                  memory: "request_mem"
                  cpu: "request_cpu"
               limits:
                  memory: "limit_mem"
                  cpu: "limit_cpu"
            volumeMounts:
               - name: config-volume
               mountPath: /app/vipin/play/conf
         volumes:
            - name: config-volume
            configMap:
            name: appname

Autoscalingเป็นคุณลักษณะหลักอย่างหนึ่งในคลัสเตอร์ Kubernetes เป็นคุณลักษณะที่คลัสเตอร์สามารถเพิ่มจำนวนโหนดได้เนื่องจากความต้องการในการตอบสนองบริการเพิ่มขึ้นและลดจำนวนโหนดเมื่อความต้องการลดลง ปัจจุบันคุณลักษณะของการปรับขนาดอัตโนมัตินี้รองรับใน Google Cloud Engine (GCE) และ Google Container Engine (GKE) และจะเริ่มต้นด้วย AWS ในไม่ช้า

ในการตั้งค่าโครงสร้างพื้นฐานที่ปรับขนาดได้ใน GCE ก่อนอื่นเราต้องมีโครงการ GCE ที่ใช้งานอยู่ซึ่งมีคุณสมบัติของการตรวจสอบระบบคลาวด์ของ Google การบันทึกบนคลาวด์ของ Google และการเปิดใช้งาน stackdriver

ขั้นแรกเราจะตั้งค่าคลัสเตอร์โดยมีโหนดไม่กี่โหนดทำงานอยู่ เมื่อเสร็จแล้วเราต้องตั้งค่าตัวแปรสภาพแวดล้อมต่อไปนี้

ตัวแปรสภาพแวดล้อม

export NUM_NODES = 2
export KUBE_AUTOSCALER_MIN_NODES = 2
export KUBE_AUTOSCALER_MAX_NODES = 5
export KUBE_ENABLE_CLUSTER_AUTOSCALER = true

เมื่อเสร็จแล้วเราจะเริ่มคลัสเตอร์โดยการเรียกใช้ kube-up.sh. สิ่งนี้จะสร้างคลัสเตอร์พร้อมกับการเพิ่มสเกลาร์อัตโนมัติของคลัสเตอร์

./cluster/kube-up.sh

ในการสร้างคลัสเตอร์เราสามารถตรวจสอบคลัสเตอร์ของเราโดยใช้คำสั่ง kubectl ต่อไปนี้

$ kubectl get nodes
NAME                             STATUS                       AGE
kubernetes-master                Ready,SchedulingDisabled     10m
kubernetes-minion-group-de5q     Ready                        10m
kubernetes-minion-group-yhdx     Ready                        8m

ตอนนี้เราสามารถปรับใช้แอปพลิเคชันบนคลัสเตอร์แล้วเปิดใช้งานตัวปรับขนาดอัตโนมัติแนวนอน ซึ่งสามารถทำได้โดยใช้คำสั่งต่อไปนี้

$ kubectl autoscale deployment <Application Name> --cpu-percent = 50 --min = 1 --
max = 10

คำสั่งดังกล่าวแสดงให้เห็นว่าเราจะคงไว้อย่างน้อยหนึ่งและสูงสุด 10 แบบจำลองของ POD เมื่อโหลดในแอปพลิเคชันเพิ่มขึ้น

เราสามารถตรวจสอบสถานะของตัวปรับขนาดอัตโนมัติได้โดยเรียกใช้ไฟล์ $kubclt get hpaคำสั่ง เราจะเพิ่มภาระในพ็อดโดยใช้คำสั่งต่อไปนี้

$ kubectl run -i --tty load-generator --image = busybox /bin/sh
$ while true; do wget -q -O- http://php-apache.default.svc.cluster.local; done

เราสามารถตรวจสอบไฟล์ hpa โดยการวิ่ง $ kubectl get hpa คำสั่ง

$ kubectl get hpa NAME REFERENCE TARGET CURRENT php-apache Deployment/php-apache/scale 50% 310% MINPODS MAXPODS AGE 1 20 2m $ kubectl get deployment php-apache
NAME         DESIRED    CURRENT    UP-TO-DATE    AVAILABLE   AGE
php-apache      7          7           7            3        4m

เราสามารถตรวจสอบจำนวนพ็อดที่ทำงานได้โดยใช้คำสั่งต่อไปนี้

jsz@jsz-desk2:~/k8s-src$ kubectl get pods
php-apache-2046965998-3ewo6 0/1        Pending 0         1m
php-apache-2046965998-8m03k 1/1        Running 0         1m
php-apache-2046965998-ddpgp 1/1        Running 0         5m
php-apache-2046965998-lrik6 1/1        Running 0         1m
php-apache-2046965998-nj465 0/1        Pending 0         1m
php-apache-2046965998-tmwg1 1/1        Running 0         1m
php-apache-2046965998-xkbw1 0/1        Pending 0         1m

และสุดท้ายเราจะได้รับสถานะโหนด

$ kubectl get nodes
NAME                             STATUS                        AGE
kubernetes-master                Ready,SchedulingDisabled      9m
kubernetes-minion-group-6z5i     Ready                         43s
kubernetes-minion-group-de5q     Ready                         9m
kubernetes-minion-group-yhdx     Ready                         9m

การตั้งค่าแดชบอร์ด Kubernetes เกี่ยวข้องกับหลายขั้นตอนโดยมีชุดเครื่องมือที่จำเป็นเป็นข้อกำหนดเบื้องต้นในการตั้งค่า

• นักเทียบท่า (1.3+)
• ไป (1.5+)
• nodejs (4.2.2+)
• npm (1.3+)
• จาวา (7+)
• อึก (3.9+)
• Kubernetes (1.1.2+)

การตั้งค่าแดชบอร์ด

$ sudo apt-get update && sudo apt-get upgrade Installing Python $ sudo apt-get install python
$ sudo apt-get install python3 Installing GCC $ sudo apt-get install gcc-4.8 g++-4.8

Installing make
$ sudo apt-get install make Installing Java $ sudo apt-get install openjdk-7-jdk

Installing Node.js
$ wget https://nodejs.org/dist/v4.2.2/node-v4.2.2.tar.gz $ tar -xzf node-v4.2.2.tar.gz
$ cd node-v4.2.2 $ ./configure
$ make $ sudo make install

Installing gulp
$ npm install -g gulp $ npm install gulp

กำลังตรวจสอบเวอร์ชัน

Java Version
$ java –version java version "1.7.0_91" OpenJDK Runtime Environment (IcedTea 2.6.3) (7u91-2.6.3-1~deb8u1+rpi1) OpenJDK Zero VM (build 24.91-b01, mixed mode) $ node –v
V4.2.2

$ npn -v 2.14.7 $ gulp -v
[09:51:28] CLI version 3.9.0

$ sudo gcc --version
gcc (Raspbian 4.8.4-1) 4.8.4
Copyright (C) 2013 Free Software Foundation, Inc. This is free software; 
see the source for copying conditions. There is NO warranty; not even for 
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

กำลังติดตั้ง GO

$ git clone https://go.googlesource.com/go
$ cd go $ git checkout go1.4.3
$ cd src Building GO $ ./all.bash
$ vi /root/.bashrc In the .bashrc export GOROOT = $HOME/go
   export PATH = $PATH:$GOROOT/bin
   
$ go version
go version go1.4.3 linux/arm

การติดตั้ง Kubernetes Dashboard

$ git clone https://github.com/kubernetes/dashboard.git
$ cd dashboard $ npm install -g bower

เรียกใช้แดชบอร์ด

$ git clone https://github.com/kubernetes/dashboard.git $ cd dashboard
$ npm install -g bower $ gulp serve
[11:19:12] Requiring external module babel-core/register
[11:20:50] Using gulpfile ~/dashboard/gulpfile.babel.js
[11:20:50] Starting 'package-backend-source'...
[11:20:50] Starting 'kill-backend'...
[11:20:50] Finished 'kill-backend' after 1.39 ms
[11:20:50] Starting 'scripts'...
[11:20:53] Starting 'styles'...
[11:21:41] Finished 'scripts' after 50 s
[11:21:42] Finished 'package-backend-source' after 52 s
[11:21:42] Starting 'backend'...
[11:21:43] Finished 'styles' after 49 s
[11:21:43] Starting 'index'...
[11:21:44] Finished 'index' after 1.43 s
[11:21:44] Starting 'watch'...
[11:21:45] Finished 'watch' after 1.41 s
[11:23:27] Finished 'backend' after 1.73 min
[11:23:27] Starting 'spawn-backend'...
[11:23:27] Finished 'spawn-backend' after 88 ms
[11:23:27] Starting 'serve'...
2016/02/01 11:23:27 Starting HTTP server on port 9091
2016/02/01 11:23:27 Creating API client for
2016/02/01 11:23:27 Creating Heapster REST client for http://localhost:8082
[11:23:27] Finished 'serve' after 312 ms
[BS] [BrowserSync SPA] Running...
[BS] Access URLs:
--------------------------------------
Local: http://localhost:9090/
External: http://192.168.1.21:9090/
--------------------------------------
UI: http://localhost:3001
UI External: http://192.168.1.21:3001
--------------------------------------
[BS] Serving files from: /root/dashboard/.tmp/serve
[BS] Serving files from: /root/dashboard/src/app/frontend
[BS] Serving files from: /root/dashboard/src/app

แดชบอร์ด Kubernetes

การตรวจสอบเป็นองค์ประกอบหลักอย่างหนึ่งสำหรับการจัดการคลัสเตอร์ขนาดใหญ่ สำหรับสิ่งนี้เรามีเครื่องมือมากมาย

การตรวจสอบด้วย Prometheus

เป็นระบบตรวจสอบและแจ้งเตือน สร้างขึ้นที่ SoundCloud และเปิดแหล่งที่มาในปี 2555 จัดการข้อมูลหลายมิติได้เป็นอย่างดี

Prometheus มีส่วนประกอบหลายอย่างเพื่อเข้าร่วมในการตรวจสอบ -

• Prometheus - เป็นส่วนประกอบหลักในการคัดลอกและจัดเก็บข้อมูล

• Prometheus node explore - รับเมทริกซ์ระดับโฮสต์และเปิดเผยให้โพรมีธีอุส

• Ranch-eye - คือ haproxy และเปิดเผย cAdvisor สถิติของ Prometheus

• Grafana - การแสดงข้อมูล

• InfuxDB - ฐานข้อมูลอนุกรมเวลาที่ใช้ในการจัดเก็บข้อมูลจากผู้ดูแลฟาร์ม

• Prom-ranch-exporter - เป็นแอปพลิเคชั่น node.js ที่เรียบง่ายซึ่งช่วยในการสืบค้นเซิร์ฟเวอร์ Rancher สำหรับสถานะของกองบริการ

Sematext Docker Agent

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

การปรับใช้เอเจนต์กับโหนด

Kubernetes มี DeamonSets ซึ่งช่วยให้มั่นใจได้ว่าพ็อดจะถูกเพิ่มลงในคลัสเตอร์

การกำหนดค่า SemaText Docker Agent

มีการกำหนดค่าผ่านตัวแปรสภาพแวดล้อม

• รับบัญชีฟรีที่apps.sematext.comหากคุณยังไม่มี

• สร้างแอป SPM ประเภท“ Docker” เพื่อรับ SPM App Token SPM App จะเก็บเมตริกและเหตุการณ์ประสิทธิภาพ Kubernetes ของคุณ

• สร้างแอป Logsene เพื่อรับ Logsene App Token แอป Logsene จะเก็บบันทึก Kubernetes ของคุณ

• แก้ไขค่าของ LOGSENE_TOKEN และ SPM_TOKEN ในนิยาม DaemonSet ดังที่แสดงด้านล่าง

• หยิบเทมเพลต sematext-agent-daemonset.yml (raw plain-text) ล่าสุด (ตามที่แสดงด้านล่าง)

• จัดเก็บไว้ที่ใดที่หนึ่งบนดิสก์

• แทนที่ตัวยึดตำแหน่ง SPM_TOKEN และ LOGSENE_TOKEN ด้วยโทเค็น SPM และ Logsene App ของคุณ

สร้าง DaemonSet Object

apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
   name: sematext-agent
spec:
   template:
      metadata:
         labels:
            app: sematext-agent
      spec:
         selector: {}
         dnsPolicy: "ClusterFirst"
         restartPolicy: "Always"
         containers:
         - name: sematext-agent
            image: sematext/sematext-agent-docker:latest
            imagePullPolicy: "Always"
            env:
            - name: SPM_TOKEN
               value: "REPLACE THIS WITH YOUR SPM TOKEN"
            - name: LOGSENE_TOKEN
               value: "REPLACE THIS WITH YOUR LOGSENE TOKEN"
            - name: KUBERNETES
               value: "1"
            volumeMounts:
               - mountPath: /var/run/docker.sock
                  name: docker-sock
               - mountPath: /etc/localtime
                  name: localtime
            volumes:
               - name: docker-sock
                  hostPath:
                     path: /var/run/docker.sock
               - name: localtime
                  hostPath:
                     path: /etc/localtime

การรัน Sematext Agent Docker ด้วย kubectl

$ kubectl create -f sematext-agent-daemonset.yml
daemonset "sematext-agent-daemonset" created

บันทึก Kubernetes

บันทึกของคอนเทนเนอร์ Kubernetes ไม่แตกต่างจากบันทึกคอนเทนเนอร์ Docker มากนัก อย่างไรก็ตามผู้ใช้ Kubernetes ต้องดูบันทึกสำหรับพ็อดที่ทำให้ใช้งานได้ ดังนั้นการมีข้อมูลเฉพาะ Kubernetes สำหรับการค้นหาบันทึกจึงมีประโยชน์มากเช่น -

• เนมสเปซ Kubernetes
• ชื่อฝัก Kubernetes
• ชื่อคอนเทนเนอร์ Kubernetes
• ชื่ออิมเมจ Docker
• Kubernetes UID

ใช้ ELK Stack และ LogSpout

ELK stack ประกอบด้วย Elasticsearch, Logstash และ Kibana ในการรวบรวมและส่งต่อบันทึกไปยังแพลตฟอร์มการบันทึกเราจะใช้ LogSpout (แม้ว่าจะมีตัวเลือกอื่น ๆ เช่น FluentD)

รหัสต่อไปนี้แสดงวิธีตั้งค่าคลัสเตอร์ ELK บน Kubernetes และสร้างบริการสำหรับ ElasticSearch -

apiVersion: v1
kind: Service
metadata:
   name: elasticsearch
   namespace: elk
   labels:
      component: elasticsearch
spec:
   type: LoadBalancer
   selector:
      component: elasticsearch
   ports:
   - name: http
      port: 9200
      protocol: TCP
   - name: transport
      port: 9300
      protocol: TCP

การสร้าง Replication Controller

apiVersion: v1
kind: ReplicationController
metadata:
   name: es
   namespace: elk
   labels:
      component: elasticsearch
spec:
   replicas: 1
   template:
      metadata:
         labels:
            component: elasticsearch
spec:
serviceAccount: elasticsearch
containers:
   - name: es
      securityContext:
      capabilities:
      add:
      - IPC_LOCK
   image: quay.io/pires/docker-elasticsearch-kubernetes:1.7.1-4
   env:
   - name: KUBERNETES_CA_CERTIFICATE_FILE
   value: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
   - name: NAMESPACE
   valueFrom:
      fieldRef:
         fieldPath: metadata.namespace
   - name: "CLUSTER_NAME"
      value: "myesdb"
   - name: "DISCOVERY_SERVICE"
      value: "elasticsearch"
   - name: NODE_MASTER
      value: "true"
   - name: NODE_DATA
      value: "true"
   - name: HTTP_ENABLE
      value: "true"
ports:
- containerPort: 9200
   name: http
   protocol: TCP
- containerPort: 9300
volumeMounts:
- mountPath: /data
   name: storage
volumes:
   - name: storage
      emptyDir: {}

Kibana URL

สำหรับ Kibana เราให้ Elasticsearch URL เป็นตัวแปรสภาพแวดล้อม

- name: KIBANA_ES_URL
value: "http://elasticsearch.elk.svc.cluster.local:9200"
- name: KUBERNETES_TRUST_CERT
value: "true"

Kibana UI จะเข้าถึงได้ที่พอร์ตคอนเทนเนอร์ 5601 และการรวมโฮสต์ / พอร์ตโหนดที่เกี่ยวข้อง เมื่อคุณเริ่มต้นจะไม่มีข้อมูลใด ๆ ใน Kibana (ซึ่งคาดว่าเนื่องจากคุณไม่ได้ผลักดันข้อมูลใด ๆ )