Getting Start … with Kubernetes !

bennned LD

Published in

Sirisoft

9 min readOct 2, 2017

ปัจจุบันเทคโนโลยีที่น่าจับตามอง สำหรับสายงานที่เกี่ยวข้องกับด้านเทคโนโลยยี คงจะหนีไม่พ้นเรื่องของเทคโนโลยี Kubernetes

แต่ก่อนจะรู้ว่ามันคืออะไร เราไปรู้ว่าทำไมช่วงหลังมานี้มันถูกให้ความสนใจเป็นจำนวนมากกันดีกว่า

การ Deploy Application ที่เรารู้จักกันดี หรือการที่จะทำให้ Application สามารถใช้งานได้แต่ ล่ะตัวก็จะมีวิธีการที่ยุ่งยาก หลายขั้นตอน ตัวอย่างเช่น ต้องมีการเตรียมเครื่อง server มาเครื่องหนึ่ง ต้องมีการจัดการ partition บน OS รวมไปถึงการติดตั้ง Application Server ก็ต้องมีการ config ตามที่ Application ใช้งาน ถึงจะนำ source code ไป deploy ติดตั้งได้

ขั้นตอนการติดตั้ง ก็ว่ายากแล้ว ยังมีปัญหาอีกหลายอย่างที่ตามมา เช่น

ถ้ามีการเพิ่มเครื่องเป็น cluster หรือ ทำการย้ายเครื่อง ต้องมีเรื่องของ Downtime มาเกี่ยวข้องแน่ๆ
การควบคุม version ของ source code ที่ติดตั้งอยู่ บน Application server
ถ้าอยากได้ environment เหมือนเดิม แต่อยากเพิ่มเป็น environment TEST เข้ามาล้ะ คงมีแต่การ clone เครื่อง server ไปทั้งหมด แต่ก็ยังไม่แน่นอนว่าจะใช้การได้เพราะมีในเรื่องของ ip เข้ามาเกี่ยวข้อง

เลยเป็นที่มาของยุคต่อไปคือ Containerized Application

Concept ของ container application คือ การสร้างสภาพแวดล้อมเฉพาะให้ซอฟต์แวร์ทำงานได้โดยไม่กวนกับซอฟต์แวร์ตัวอื่นบนระบบปฏิบัติการเดียวกัน เราสามารถเอา Container ไปรันในคอมพิวเตอร์หรือ Server เครื่องไหนก็ยังทำงานได้เหมือนเดิม โปรแกรมใน Container ยังทำงานได้ปกติไม่ผิดเพี้ยนจากเดิม ที่ผ่านมา Software Container มีการพูดถึงและมีการใช้งานกันมานานแล้ว อาทิ LXC (Linux Container), Solaris Containers, OpenVZ เป็นต้น แต่ไม่เป็นที่แพร่หลายมากนัก เนื่องจากมีการใช้งานค่อนข้างยุ่งยาก ปัจจุบันจึงได้เกิด Engine ที่ชื่อว่า Docker

Docker

เป็น container application ทำงานได้รวดเร็ว ลดขั้นตอนการติดตั้ง การลง OS ของ container หรือจะเป็นการติด ตั้ง Application Server ก็สามารถทำได้ง่ายแต่มันจะดีกว่านี้ถ้ามีเครื่องมือที่สามารถ Scalability & Monitor เจ้าตัว Docker ได้

พอใช้ container อย่าง docker เข้ามาช่วย ก็ช่วยแก้ปัญหาข้างบนได้ระดับนึง ทำให้เราสามารถกำหนด environment ของแอปพลิเคชันเราได้ กำหนด version ได้ ทำให้ไม่ต้องกังวลเรื่องเหล่านี้อีก

นอกจากนี้ตัว docker เองยังมีลักษณะเป็น Infrastructure-as-Code คือแทนที่เราจะต้องมานั่งลงนั่นนี่เอง เราเขียนนิยามแทนว่าแอปพลิเคชัน เราเวลา deploy แล้วต้องเป็นยังไง ทำให้จัดการการตั้งค่าต่างๆได้ง่าย

พอเราห่อแอพเป็น container ถ้าเราอยาก scale หรือย้ายเครื่อง เราก็สามารถเอาทั้ง container ไปวางในที่ใหม่ได้เลย ไม่ต้องมา setup อะไรให้ยุ่งยาก

แต่ก็ยังมีเรื่องที่เป็นปัญหาอยู่ เช่น

การ scale ก็ยังคงต้องไปเปิดเครื่องใหม่ แล้วเอา container ไปวาง
networking ระหว่าง container / service discovery / ก็ต้องมีการตั้งค่าต่างๆ

เลยมี Tools ที่มาช่วยจัดการ container อีกที เรียกว่า… Kubernetes

Kubernetes

เป็นเครื่องมือที่ช่วยจัดการกับ Container ซึ่งส่วนใหญ่จะใช้เป็น Docker Container โดยความสามารถหลักๆ ของมันคือการ automate deploying , scaling และการ monitoring คือ สามารถ เพิ่ม / ลด จำนวน container ได้ตามต้องการ ภายในระยะเวลาอันสั้น ซึ่งการที่มันสามารถจัดการ container ได้เยอะ เลยทำให้เหมาะกับการทำ cluster

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

โดยใน Kubernetes จะมี Node ที่ใช้อยู่ 2 ประเภท คือ

Master node : เป็นส่วน front-end สำหรับ Client ในการเข้าถึงเพื่อสั่งงาน หรือ ตั้งค่าต่างๆ เป็นส่วนที่คอยควบคุม จัดการ component ที่อยู่ภายใน รวมถึงการทำ Scalability และ มีหน้า Dashboard ที่สามารถ monitor สถานะ หรือดูว่ามีการทำงานใดบ้างอยู่ภายใน component ข้างในประกอบด้วย

Kube-apiserver : คือ REST webservice เป็นส่วนที่รับคำสั่ง เมื่อมีการส่ง manifest (ไฟล์ yaml) เข้ามาโดยจะผ่านทางคำสั่ง kubectl apply โดย manifest จะอยู่ในรูปของไฟล์ JSON ซึ่งจะส่งคำสั่งให้ API Server จากนั้น API Server จะเป็นคนจัดการว่าใน manifest มีการสั่งงานให้ทำอะไรบ้าง ใครควรเป็นคนทำคำสั่งนี่ต่อไป ก็จะส่งงานไปให้คนนั้น
Kube-controller-manager (Replication Controller) : เป็นตัวควบคุม การทำงานระหว่าง node โดยการเชื่อมต่อระหว่าง node จะทำโดยการ เรียกผ่าน Service ตัว kube-controller จะเป็นคนจัดการในส่วนนี้ รวมการ scale เพิ่ม / ลด ของ pod ภายใน เครื่องที่เป็น minions การ scale นอกจากจะรับคำสั่งจาก client ที่สั่งเข้ามาผ่านทาง Api-server แล้ว ยังจะทำการ scale ในกรณีของ Actual state ไม่เท่ากับ Desired state

Actual state คือสถานะปัจจุบันของ pod ว่า pod มีจำนวนเท่าใด ส่วน Desired state เป็นสถานะตอนแรกที่มาจาก manifest หรือ เรียกอีกอย่างว่าเป็นการ Control Plan คือเป็น ค่าตั้งแต่ต้น ว่าแต่ล่ะ pod ต้องมีจำนวนเท่าใด

เมื่อเริ่มแรกจำนวน pod จะถูกสร้างตามจำนวนที่ระบุไว้ใน manifest แล้วถ้าใช้ไประยะหนึ่ง pod บางตัวหยุดทำงานทำให้ Actual state ไม่เท่ากับ Desired state ส่วนของ Kube-controller-manager ก็จะคอย monitor และทำการ เพิ่ม pod ให้เท่าตามเดิม

kube-scheduler : จะทำหน้าที่ auto-scales ของ pod ตามที่ตั้ง policy ไว้ ว่าให้เพิ่ม pod ตอนไหน หรือ ให้เพิ่มตอน resource ของเครื่องเหลือเท่าไร ตัวอย่างเช่น ถ้ามีการใช้ CPU มากกว่า 80 % ให้ทำการเพิ่ม pod เป็นต้น เป็นตัวที่คอย monitor resource ว่าถึงเมื่อไรควรจะขยาย resource เพื่อที่ pod ใน minions จะได้เพียงพอต่อจำนวนการใช้งาน
Key/Value stores (etcd) : เป็น Database สำหรับเก็บข้อมูล configuration ของ manifest ว่าแต่ล่ะครั้งที่มีการส่งไฟล์ .yaml เข้ามามีการตั้งค่าแบบไหน ถือว่าเป็นส่วนที่สำคัญส่วนหนึ่ง เพราะใช้เก็บ configuration ถ้าส่วนนี้พังไป Kubernetes จะไม่สามารถใช้งานได้ ในการใช้งานจริงควรต้องทำการ Backup ในส่วนนี้

2. Worker node / Minion : เป็นเครื่องที่ใช้ run งานจริง มีหน้าที่ทำงานอย่างเดียวสามารถใช้ทั้ง VM หรือ เครื่อง Server จริงๆ มาทำก็ได้ แต่ล่ะ Worker node จะมีหน้าที่ run pod และจะถูกจัดการโดย Master Node ประกอบด้วย 3 ส่วน

Kubelet : เป็น agent ในการรับคำสั่งจาก Master ถ้าไม่มี kubelet เครื่อง minion จะไม่สามารถรับคำสั่งจาก Master ได้ และจะไม่ทำงานตามคำสั่ง โดย kubelet จะคอย monitor งานที่ต้องทำจาก API Server มีการยิงคำสั่งเข้ามาที่ kubelet จากนั้น kubelet จะเป็นตัวจัดการภายใน minion ให้ทำตามคำสั่งที่ได้รับมา ไม่ว่าจะเป็น สั่งให้ Docker Engine สร้าง image ใหม่ขึ้นมา หรือ config Network เป็นต้น นอกจากจะเป็นตัวที่รับคำสั่งจาก master ตัวมันยังทำหน้าที่รายงานผลและ log กลับไปหา Master ผ่าน port :10255 อีกด้วย
Container Engine : เป็นส่วนของตัว Container Engine ซึ่ง Kubernetes ไม่ได้
Support ของ Docker อย่างเดียว แต่ส่วนใหญ่ที่ใช้งานจะเป็น Docker Engine
เป็นตัวที่ทำหน้าที่ ดึง image มาจาก cloud ทำการ start image ให้ run หรือทำงานได้
ซึ่ง image จะอยู่ภายใต้ pod โดย Kubelet จะเป็นคนสร้าง pod แล้วสั่งให้ Docker Engine ทำการ start image แล้ว run container ขึ้นมาใช้งาน
Kube-proxy : ทำหน้าที่ในส่วนของ network ถือว่าเป็น kubernetes network จะเป็นตัวที่ Assign ip ให้ pod ใช้งาน แล้วยังเป็นตัวทำหน้าที่ Load Balance จากการเรียกของ Service กระจายไปยัง pod แต่ล่ะตัว

Pod

Pod เป็นกลุ่มของ Container การทำงานของ Kubernetes ที่เด่นในเรื่องของการ scale มันคือการ scale pod โดยใน pod สามารถมี Container ตั้งแต่ 1 เครื่องขึ้นไป หรือ สามารถมีได้หลาย Container แต่ที่ทาง Kubernetes แนะนำคือ 1 pod ควรจะมี 1 Container เพราะ ถ้า สร้าง Container หลายตัวไว้ใน pod เดียว ถ้าเกิด pod นั้นหยุดทำงาน Container ทุกตัวใน pod จะไม่สามารถใช้งานได้ ส่วนใหญ่กรณีที่ใช้ Container มากกว่า 1 ตัวใน 1 pod จะเป็น Container ที่ต้องการทำ Load Balance ภายใน คือมี Container ที่เป็น LB และ Container ที่ใช้ run งาน นอกจากนี้ใน Container ยังมี resource ต่างๆที่จำเป็นสำหรับ container เช่น storage, network ip และมันยังเก็บ config ต่างๆเกี่ยวกับ container แต่ละอัน เช่น ต้องรันยังไง ต้องคุยผ่าน port ไหน Container ทุกตัวที่อยู่ใน pod จะใช้ resource ร่วมกันเสมอ

Services

เนื่องจาก pod ที่ใช้ run Container ที่ติดตั้ง แอปพลิเคชัน มีโอกาส เพิ่ม / ลด ของ pod ตลอดเวลาด้วยคำสั่งของ Client หรือ การ Auto scale จากเวลาที่ Actual state ไม่เท่ากับ Desired state ก็ตาม ทำให้ IP ของ pod ที่ใช้ run Application มีโอกาสเปลี่ยนแปลงได้ตลอดเวลา ทำให้ไม่สามารถเรียกใช้งาน หรือเชื่อมต่อ Application ผ่าน ip-address เพราะฉะนั้นสิ่งที่ทำให้การทำงานในคลัสเตอร์ของ Kubernetes สามารถค้นหาและสื่อสารกับโลกภายนอกได้ คือ Service

Service ทำหน้าที่กระจาย Load balance ไปยังแต่ล่ะ pod สามารถทำหน้าที่เป็น API Gateway ในตัวทำให้เวลามีการ เพิ่ม / ลด ของ pod ตัวที่ทำการเรียกมายัง pod ดังกล่าวจะไม่รู้สึกว่าหลังบ้านของ pod มีการเปลี่ยนแปลงเพราะ มี service เป็นตัวกลาง ทั้งเป็นตัวกลาง จาก Client มายัง pod หรือ เป็นตัวกลางระหว่าง pod เองก็ตาม

นอกจากการที่ Service ทำให้ผู้ใช้ที่เรียก เข้ามาไม่รู้สึกได้รับผลกระทบเมื่อมีการ เพิ่ม / ลด ของ pod แล้ว service ยังช่วยในเรื่องของการทำ Blue Green – Deployment คือการ Deploy New version โดยไม่เกิด Down-time ซึ่ง Default ของ Kubernetes เป็น Blue Green -Deployment อยู่แล้วโดยหลักการของการทำ Blue Green – Deployment ถ้ามีการเปลี่ยนเวอร์ชั่น Kubernetes จะยังคงรักษา work-load ไว้เท่าเดิม ไม่ลดลง เคยมี 2 เครื่องก็จะมี 2 เครื่องเท่าเดิม คือถ้ามีการเปลี่ยนเวอร์ชั่นจาก 1 ไปเป็น 2 ตอนแรกมี pod ที่เป็นเวอร์ชั่น 1 จำนวน 2 pod งานที่มันจะทำคือ สร้าง pod แรกที่เป็น version 2 (New-version) ก่อน และจะสร้าง pod อีกเครื่องให้เป็น version 2 เพื่อไม่ให้ work-load ลดลง แล้วจะปลด version เก่าทิ้ง

การเขียน code ต้องเรียกด้วย DNS ทั้งหมดห้ามเรียกด้วย ip ไม่งั้นจะไม่สามารถ scale หรือ ทำการ update version ได้เลย

Labels

ในการตัดสินใจว่า Service ไหนจะเชื่อมต่อไปยัง pod ใด Kubernest ใช้ labels ในการ route traffic ลง pod แต่ล่ะตัว การตั้งค่า labels จะถูกตั้งค่าไว้ที่ manifest (config file )

ตัวอย่างเช่น Service ถูกตั้งค่าไว้ว่ามี label คือ Prod และ BE เพราะฉนั้น service ตัวนี้จะทำการกระจาย Load ไปยัง Pod ที่มี label ตรงกับ service แม้ว่า pod ที่กระจายไปจะมี label ของ version ก็ตาม ถ้ามีครบตรงตาม Service มันก็จะทำการกระจาย Load ไปยังทุก pod สามารถใช้ในเรื่องของการอัพเดทเวอร์ชั่นของแอพพลิเคชั่นได้ แต่ถ้าอยากทำการระบุเวอร์ชั่น สามารถทำได้โดยการเพิ่ม label ของเวอร์ชั่นที่ต้องการใน Service มันก็จะทำการกระจาย Load ไปยังเวอร์ชั่นที่ระบุ

Deploying

ใน manifest file จะมี type กำกับที่จะบ่งบอกว่าเราต้องการสร้างอะไร type หนึ่งในนั้นคือ deployment

เบื้องต้นเราได้บอกว่า ReplicationController เป็นคนสร้าง Pod แล้ว แต่เจ้าตัว Deployment คือผู้สร้าง ReplicationController อีกทีนึง แต่จริงๆ มันใช้ ReplicaSet ที่เป็น API ในการสร้าง pod อาจกล่าวได้ว่า ReplicaSet เป็น next-generation ของ ReplicationController

โดย Deployment จะมีการทำงานดังนี้

ครั้งแรกเมื่อเราสร้าง Deployment มันจะไปสร้าง ReplicaSet เพื่อให้ ReplicaSet เป็นคนสร้าง pod ตามที่ระบุไว้ใน manifest

เราสามารถทำการแก้ไข deployment ได้ ด้วยคำสั่ง

kubectl edit deployment name

พอมีการเปลี่ยนแปลง หรือการเพิ่มเวอร์ชั่น Deployment จะสั่งสร้าง ReplicaSet เพื่อให้ ReplicaSet ไปสั่งสร้าง pod เวอร์ชั่นที่มี การเปลี่ยนแปลงแก้ไข หลังจาก pod ที่สร้างใช้งานได้มันจะทำการลดขนาด ReplicaSet เดิมลง และเพิ่มขนาด ReplicaSet ใหม่อีก ทำซ้ำไปเรื่อยๆ จนกระทั่ง ReplicaSet ใหม่ขนาดเท่าเดิม และอันเดิมขนาดเหลือ 0

พูดง่ายๆ ก็คือ Deployment จะแทนที่ Pod เก่าด้วย Pod ใหม่ทีละ Pod ทำให้เวลา deploy แล้วระบบเราจะไม่มี downtime เกิดขึ้นเลย

นอกจากนี้ Deployment ยังจะเก็บ ReplicaSet ของเก่าไว้ด้วย นั่นแปลว่าถ้า deploy แล้วพังก็สามารถสั่ง kubectl rollout undo เพื่อถอยกลับได้อีกด้วย

Namespace

Namespace เป็นตัวแบ่ง Project ของ pod เพราะ เมื่อเรามีการใช้ cluster กันหลายๆ project อาจจะเกิดความสับสน เราสามารถแยกของไม่ให้ปนกันได้ด้วยการใช้ Namespace

เวลาเราจะพิมพ์คำสั่งต่างๆ ถ้าระบุ kubectl --namespace app2 ... ก็จะเห็นเฉพาะของที่อยู่ใน namespace นั้นๆ โดยปกติแล้ว Kubernetes จะมี namespace สำคัญๆ 2 อัน ก็คือ default ที่เราใช้ได้เวลาไม่ระบุชื่อ namespace และ kube-system ที่เก็บ service ของ Kubernetes

Installing Kubernetes !

(reference)

เมื่อรู้จัก Kubernetes เบื้องต้นกันไปแล้วมาลองดูขั้นตอนการติดตั้งของเจ้าตัว Kubernetes กันบ้าง ซึ่งในตัวอย่างนี้ จะเป็นการติดตั้งแบบ On-premise บน Centos 7

ขั้นตอนแรกทำการติดตั้ง package ที่จำเป็นสำหรับ Kubernetes

$ sudo yum install -y yum-utils device-mapper-persistent-data lvm2

ทำการโหลดและติดตั้ง docker-ce

$ sudo yum-config-manager \  
  --add-repo \  
  https://download.docker.com/linux/centos/docker-ce.repo$ sudo yum makecache fast
$ sudo yum install docker-ce

ทำการ start Service: Docker

$ sudo systemctl enable docker.service && systemctl start docker

ทำการติดตั้ง kubeadm, kubelet and kubectl ทำการดาวน์โหลด kubectl

$ curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectlchmod +x ./kubectl
sudo mv ./kubectl /usr/local/bin/kubectl

ตั้งค่า repo ให้สามารถ yum ได้

cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
        https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF
setenforce 0
yum install -y kubelet kubeadm kubectl
systemctl enable kubelet && systemctl start kubelet

จากนั้นทำการ install kubelet kubeadm

yum install -y kubelet kubeadm

ทำการ start kubelet และทำการปิด firewall จากนั้นเราควร mapping /etc/hosts ไฟล์ทุกเครื่องของ node

systemctl enable kubelet && systemctl start  kubelet
systemctl disable firewalld && systemctl stop firewalld

ขั้นตอนด้านบนเราจะทำทุก node ใน kubernetes ทั้ง master และ minions แต่ขั้นตอนตาอไปจะทำเฉพาะเครื่องที่เป็น master

kubeadm init — apiserver-advertise-address=<master_ip> — pod-network-cidr=10.244.0.0/16

หลังจากใช้คำสั่งด้านบน จะได้คำสั่ง join เพื่อที่จะไปใช้กับเครื่อง minions ที่เราต้องการ

mkdir -p $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config

ขั้นตอนนี้เป็นการ install pod Network (flannel) ทำการดาวน์โหลดไฟล์ manifest ของ pod

curl -O https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel-rbac.yml curl -O https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

ทำการ apply ไฟล์ manifest

kubectl apply -f kube-flannel-rbac.yml -f kube-flannel.yml

จากนั้นตรวจสอบ pod flannel ว่าสถานะเป็น running หรือยัง โดยการตรวจสอบเราจะใส่ชื่อ namespace ของ pod ที่ต้องการตรวจสอบไปด้วย pod ของ flannel จะอยู่ที่ namespace kube-system

kubectl get all -n kube-system

หลังที่ใช้คำสั่ง kubeadm init กับ node ที่เป็นเครื่อง master ด้านบน จะได้ token สำหรับเครื่อง minions ที่จะใช้ join เข้ามา นำคำสั่งที่ได้ใช้ในเครื่อง minions ที่ต้องการ

kubeadm join --token <token> <master-ip>:<master-port>

ขั้นตอนนี้จะเป็นขั้นตอนติดตั้ง pod ที่ใช้เป็นหน้า Dashboard เพื่อจัดการ Kubernetes

สร้างไฟล์ kubernetes-dashboard.yamlvi kubernetes-dashboard.yaml# Copyright 2015 Google Inc. All Rights Reserved.
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#     http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.# Configuration to deploy release version of the Dashboard UI compatible with
# Kubernetes 1.6 (RBAC enabled).
#
# Example usage: kubectl create -f <this_file>apiVersion: v1
kind: ServiceAccount
metadata:
  labels:
    k8s-app: kubernetes-dashboard
  name: kubernetes-dashboard
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: kubernetes-dashboard
  labels:
    k8s-app: kubernetes-dashboard
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: kubernetes-dashboard
  namespace: kube-system
---
kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  labels:
    k8s-app: kubernetes-dashboard
  name: kubernetes-dashboard
  namespace: kube-system
spec:
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      k8s-app: kubernetes-dashboard
  template:
    metadata:
      labels:
        k8s-app: kubernetes-dashboard
    spec:
      containers:
      - name: kubernetes-dashboard
        image: gcr.io/google_containers/kubernetes-dashboard-amd64:v1.6.2
        ports:
        - containerPort: 9090
          protocol: TCP
        volumeMounts:
          - name: "kubeconfig"
            mountPath: "/etc/kubernetes/"
            readOnly: true
        args:
          # Uncomment the following line to manually specify Kubernetes API server Host
          # If not specified, Dashboard will attempt to auto discover the API server and connect
          # to it. Uncomment only if the default does not work.
          - --apiserver-host=https://10.0.0.2:6443      // IP_Master
          - --heapster-host=http://heapster.kube-system:80
          - --kubeconfig=/etc/kubernetes/admin.conf
        livenessProbe:
          httpGet:
            path: /
            port: 9090
          initialDelaySeconds: 30
          timeoutSeconds: 30
      volumes:
      - name: "kubeconfig"
        hostPath:
          path: "/etc/kubernetes/"
      nodeSelector:
        node-role.kubernetes.io/master:
      # Comment the following tolerations if Dashboard must not be deployed on master
      tolerations:
      - key: node-role.kubernetes.io/master
        effect: NoSchedule
---
kind: Service
apiVersion: v1
metadata:
  labels:
    k8s-app: kubernetes-dashboard
  name: kubernetes-dashboard
  namespace: kube-system
spec:
  ports:
  - port: 80
    targetPort: 9090
  selector:
    k8s-app: kubernetes-dashboard

ทำการ apply manifest ของ pod ที่ทำหน้าที่เป็น Dashboard

kubectl apply -f kubernetes-dashboard.yaml -n kube-system
kubectl get all -n kube-system

เมื่อติดตั้ง pod ของ Dashboard เรียบร้อยแล้ว ขั้นตอนต่อไปเป็นการ access เข้าหน้า Dashboard โดยผ่านเครื่องอื่นที่ไม่ใช่ เครื่องที่ติดตั้ง Kubernetes ในตัวอย่างจะเข้าหน้า Dashboard โดยผ่านเครื่องที่เป็น Windows

เริ่มจากการติดตั้ง package ที่มีชื่อว่า Chocolatey เป็น pckage ที่ทำให้สามารถใช้ kubectl บน Windows ได้

หลังจากการติดตั้ง จะใช้คำสั่ง kubectl version เพื่อเป็นการยืนยันว่าบนเครื่อง Windows ได้ติดตั้ง kubectl เรียบร้อยแล้ว

พอติดตั้งเสร็จสิ่งที่สำคัญที่สุด คือการตั้งค่า configuration file เพื่อที่จะ remote ไปยัง Kubernetes ที่ต้องการ โดย config file สามารถนำไฟล์ config ที่มีอยู่บนเครื่องที่ทำการติดตั้ง kubetnetes มาใช้ได้เลย โดย path ของ configuration file สามารถสร้างได้ ดังนี้

cd C:\users\yourusername (Or wherever your %HOME% directory is)
mkdir .kube
cd .kube

path ของไฟล์ config ในเครื่อง Windows จะอยู่ในโฟลเดอร์ .kube ภายในโฟลเดอร์ User โดยการสร้างโฟลเดอร์ .kube จะสามารถทำการสร้างโดยผ่าน command mkdir

พอสร้าง path ที่จะนำ config file มาวางเรียบร้อยแล้วจะนำไฟล์ config ที่อยู่บน kubernetes ใน path Home ของ User ในโฟลเดอร์ .kube มาวางบนเครื่อง Windows จากนั้นใช้คำสั่ง

kubectl proxy

บนเครื่อง Windows เพื่อสร้าง proxy ไปยัง Kubernetes จากนั้นจะได้ port มาเราสามารถ เข้าหน้า Dashboard ผ่าน localhost ของ port นั้นได้เลย

Installing a sample application

เมื่อตั้งค่าไฟล์ configuration เสร็จเรียบร้อยแล้ว และสามารถเปิดหน้า Dashboard ได้แล้วขั้นตอนถัดมาจะเป็นการนำ application ที่เป็น Microservice ไปใช้บน Kubernetes ผ่านไฟล์ .yaml โดย application นี้เป็น sample application ที่ทาง Kubernetes ได้เตรียมไฟล์ .yaml ไว้เรียบร้อยแล้ว สามารถนำไปใช้ได้เลยด้วยคำสั่ง

kubectl create namespace sock-shop
kubectl apply -n sock-shop -f "https://github.com/microservices-demo/microservices-demo/blob/master/deploy/kubernetes/complete-demo.yaml?raw=true"

เมื่อใช้คำสั่งด้านบน ในหน้า Dashboard จะปรากฎ Namespace ที่ชื่อว่า sock-shop เมื่อตอนที่พึ่งสร้างสถานะของ pod จะเป็นสีเทา คืออยู่ระหว่างดำเนินการ รอจนกว่าสถานะของ pod ทุกตัวจะเป็นสีเขียวหรือ running

จากนั้นใช้คำสั่งด้านล่าง เพื่อดูการ access เข้า Service

kubectl -n sock-shop get svc front-end

ตัวอย่าง output:

NAME        CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
front-end   10.110.250.153   <nodes>       80:30001/TCP   59s

จากนั้นเราจะทำการเรียกไปยัง Service ด้วย http://<master_ip>:<port> ซึ่งในตัวอย่างจะเป็น port:30001

หลังจากทำการเรียก ก็จะได้หน้า front-end ออกมาตามด้านล่าง

เราได้รู้ขั้นตอนการติดตั้งเบื้อต้นไปแล้ว ถ้าเกิดใครที่จะติดตั้งบน OS อื่นก็สามารถเข้าไปดูวิธีการติดตั้งได้ในเว็ปของ kubernetes.io หรือใครจะเข้าไปศึกษาเพิ่มเติมก็สามารถเข้าไปได้ที่เดียวกัน

ถ้ามีโอกาสหน้าคงได้มาพูดถึงเรื่อง manifest หรือไฟล์ .yaml เจ้าไฟล์ตัวสำคัญที่สามารถทำให้ Application ใช้งานได้เพียงไม่กี่นาที งั้นตอนนี้ต้องขอตัวลาไปก่อนไว้เจอกันโอกาสหน้าค่ะ