Deep To Cloud ຕອນທີ 1: k8s ກັບ YAML file
ສຳລັບຜູ້ທີ່ກຳລັງເລີ່ມຕົ້ນໃຊ້ k8s ຫຼື ໃຊ້ມາໄລຍະໜຶ່ງແລ້ວກໍ່ຕາມ. ບົດຄວາມນີ້ເປັນຕອນທຳອິດໃນ Series Deep To Cloud ທີ່ຈະເວົ້າເລື່ອງ k8s ໂດຍສະເພາະເຈາະຈົງທີ່ມີເປົ້າໝາຍໃຫ້ຜູ້ທີ່ເລີ່ມຕົ້ນໃຊ້ງານ k8s ສາມາດນຳໄປໃຊ້ໄດ້ຈິງ ຫຼື ເຫັນຊ່ອງທາງທີ່ຈະໄປຕໍ່ກັບການເຮັດ cluster ດ້ວຍ k8s.
ສຳລັບບົດຄວາມນີ້ແມ່ນຈະມາເວົ້າເຖິງການຂຽນ yaml file ທີ່ໃຊ້ເປັນ configuration ສຳລັບ k8s ວ່າເຮົາຈະຂຽນ file ນີ້ຂື້ນມາໄດ້ແນວໃດ. ແຕ່ກ່ອນຈະໄປເທິງຂັ້ນນັ້ນແນະນຳໃຫ້ຜູ້ອ່ານທີ່ຫາກໍ່ເລີ່ມຕົ້ນກັບໄປອ່ານບົດຄວາມເກົ່າເສຍກ່ອນເພື່ອໃຫ້ຮູ້ເຖິງ object, resource ແລະ ການຕິດຕັ້ງ k8s cluster ທັງໃນ local ແລະ cloud server.
YAML ຄືຫຍັງ ແລະ ໃຊ້ໄວ້ເຮັດຫຍັງ ໃນ k8s?
ດັ່ງທີ່ຮູ້ກັນດີວ່າ k8s ຈະມີ kubectl ເປັນ client ຕິດຕໍ່ກັບ kube-apiServer ທີ່ໃຊ້ບໍລິຫານຈັດການ cluster ບໍ່ວ່າຈະເປັນການສ້າງ pod , scale pod, expose service ແລະ ອຶ່ນໆ
ຈາກບົດຄວາມກ່ອນໜ້ານີ້ຈະເຫັນວ່າໃນການສ້າງ pod ແລະ expose service ເຮົາຈະໃຊ້ command line ເຊິ່ງມັນກໍ່ໃຊ້ໄດ້!. ແຕ່ບັນຫາກໍ່ຄື ມັນບໍ່ portable ແລະ ແກ້ໄຂປັບປຸງຍາກ. ພ້ອມກັນນັ້ນຄົນອື່ນທີ່ມາດູແລ cluster ແທນເຮົາກໍ່ບໍ່ອາດເຂົ້າໃຈວ່າເຮົາໄດ້ deploy application ໄປແນວໃດ(ຄົງຕ້ອງງົມໆທາວໆກັນດົນສົມຄວນ). ສະນັ້ນຈຶ່ງຕ້ອງເກັບ config ນັ້ນໄວ້ເປັນ file ໃຫ້ເປັນລະບຽບຮຽບຮ້ອຍເຊິ່ງ file ດັ່ງກ່າວສ່ວນຫຼາຍຈະເປັນ yaml file ທີ່ເປັນ ພາສາໂຄງສ້າງຂອງຂໍ້ມູນທີ່ເຮັດໃຫ້ຄົນເຮົາອ່ານເຂົ້າໃຈໄດ້.
ຂຽນ YAML ຂອງ k8s ແນວໃດ!?
ໃນຫຼາຍເດືອນກ່ອນຜູ້ຂຽນເອງກໍ່ມຶນໆງົງໆວ່າເຮົາຈະຂຽນ yaml file ຂອງ k8s ແນວໃດ. ຈະຮູ້ໄດ້ແນວໃດວ່າມີ resource ໃດແດ່ ແລະ ແຕ່ລະ resource ມີໂຄງສ້າງຂໍ້ມູນແນວໃດ. ເຊິ່ງພໍງົມໆໄປກໍ່ພົບວ່າ kubectl ຈະມີຄຳສັ່ງທີ່ໃຊ້ອະທິບາຍໂຄງສ້າງຂອງຂໍ້ມູນແຕ່ລະ resource ເອົາໄວ້ໃຫ້ລະອຽດຢູ່ແລ້ວໂດຍໃຊ້ຄຳສັ່ງ
$ kubectl explain <k8s resource>ຕົວຢ່າງ: ເຮົາຕ້ອງການຂ້ຽນ yaml deployment ໂຄງສ້າງຂໍ້ມູນໃນການ config ກໍ່ຈະປະມານນີ້
$ kubectl explain deploymentKIND: Deployment
VERSION: extensions/v1beta1
DESCRIPTION:
DEPRECATED - This group version of Deployment is deprecated by
apps/v1beta2/Deployment. See the release notes for more information.
Deployment enables declarative updates for Pods and ReplicaSets.
FIELDS:
apiVersion <string>
APIVersion defines the versioned schema of this representation of an
object. Servers should convert recognized schemas to the latest internal
value, and may reject unrecognized values. More info:
https://git.k8s.io/community/contributors/devel/api-conventions.md#resources
kind <string>
Kind is a string value representing the REST resource this object
represents. Servers may infer this from the endpoint the client submits
requests to. Cannot be updated. In CamelCase. More info:
https://git.k8s.io/community/contributors/devel/api-conventions.md#types-kinds
metadata <Object>
Standard object metadata.
spec <Object>
Specification of the desired behavior of the Deployment.
status <Object>
Most recently observed status of the Deployment.
ກໍ່ຈະເຫັນບັນດາ key ຂໍ້ມູນ ແລະ ຊະນິດຂໍ້ມູນຂອງ key ນັ້ນໆທີ່ສາມາດກຳນົດໄດ້. ນອກນັ້ນເຮົາຍັງສາມາດຂະຫຍາຍເບິ່ງລາຍລະອຽດຂອງແຕ່ລະ key ໄດ້ໂດຍໃຊ້ພຽງແຕ່ເຄື່ອງໝາຍຈຳແລ້ວຕາມດ້ວຍ key ທີ່ຕ້ອງການເບິ່ງ.
$ kubectl explain deployment.specKIND: Deployment
VERSION: extensions/v1beta1
RESOURCE: spec <Object>
DESCRIPTION:
Specification of the desired behavior of the Deployment.
DeploymentSpec is the specification of the desired behavior of the
Deployment.
FIELDS:
minReadySeconds <integer>
Minimum number of seconds for which a newly created pod should be ready
without any of its container crashing, for it to be considered available.
Defaults to 0 (pod will be considered available as soon as it is ready)
paused <boolean>
Indicates that the deployment is paused and will not be processed by the
deployment controller.
progressDeadlineSeconds <integer>
The maximum time in seconds for a deployment to make progress before it is
considered to be failed. The deployment controller will continue to process
failed deployments and a condition with a ProgressDeadlineExceeded reason
will be surfaced in the deployment status. Note that progress will not be
estimated during the time a deployment is paused. This is set to the max
value of int32 (i.e. 2147483647) by default, which means "no deadline".
replicas <integer>
Number of desired pods. This is a pointer to distinguish between explicit
zero and not specified. Defaults to 1.
revisionHistoryLimit <integer>
The number of old ReplicaSets to retain to allow rollback. This is a
pointer to distinguish between explicit zero and not specified. This is set
to the max value of int32 (i.e. 2147483647) by default, which means
"retaining all old RelicaSets".
rollbackTo <Object>
DEPRECATED. The config this deployment is rolling back to. Will be cleared
after rollback is done.
selector <Object>
Label selector for pods. Existing ReplicaSets whose pods are selected by
this will be the ones affected by this deployment....
ສ່ວນຄວາມໝາຍຂອງແຕ່ລະ key ກໍ່ມີອະທິບາຍໄວຢ່າງຊັດເຈນວ່າໃຊ້ໄວ້ເພື່ອຫຍັງ (ຕ້ອງໃຊ້ຄວາມຮູ້ພາສາອັງກິດໜ້ອຍໜຶ່ງ).
ສ່ວນ resource ອື່ນໆກໍ່ເຊັ່ນດຽວກັນ. ສາມາດຫາລາຍການ resource ຕ່າງໆ ຂອງ k8s ຕາມ link ນີ້ເລີຍ
ເມື່ອເຮົາຮູ້ແບບນີ້ແລ້ວກໍ່ເປັນການງ່າຍໃນການສ້າງ yaml file config ສຳລັບ k8s cluster. Step ຕໍ່ໄປກໍ່ຂຶ້ນກັບເຮົາແລ້ວວ່າຈະ deploy application ເຮົາແນວໃດ!.
ຕົວຢ່າງການຂຽນ yaml file ເພື່ອ deploy hello-app
ໃນຕົວຢ່າງນີ້ຈະຍົກເອົາການ deploy hello-app ທີ່ເຮົາ deploy ໂດຍໃຊ້ command line ນັ້ນປ່ຽນມາໃຊ້ yaml file.
deployment
command line
$ kubectl run hello-app --image=gcr.io/google-samples/hello-app:1.0 --port=8080ປ່ຽນເປັນ yaml file
expose service
command line
$ kubectl expose deployment hello-appປ່ຽນເປັນ yaml file
Access hello-app
ເບິ່ງ deployment ຂອງ hello-app
$ kubectl get deployments -l app=hello
NAME READY UP-TO-DATE AVAILABLE AGE
hello-app 2/2 2 2 13mມີສອງ replicas ເພາະເຮົາກຳນົດຢູ່ replicas=2 ໃນ deployment.yml
ເບິ່ງ service ຂອງ hello-app
$ kubectl get svc -l app=hello
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
hello-app NodePort 10.109.71.48 <none> 8080:30125/TCP 14mສັງເກດເບິ່ງ PORT (<contianer-port>:<node-port>)
$ curl http://<YOUR_NODE_IP>:<node-port>/
Hello, world!
Version: 1.0.0
Hostname: hello-app-65955dd86-n45h7ສະຫຼຸບ
ບົດຄວາມນີ້ກໍ່ເປັນການເລີ່ມຕົ້ນ Series ຂອງ deep to cloud ທີ່ຈະກ່ຽວເນື່ອງກັບບົດຄວາມຕໍ່ໆໄປທີ່ຈະຍາກຂຶ້ນຕາມລຳດັບ. ຈຸດປະສົງສູງສຸດຂອງບົດຄວາມນີ້ຢາກໃຫ້ຮູ້ວ່າ ເຮົາຈະຂຽນ yaml file ແນວໃດ ຫຼື ຮູ້ວ່າ k8s resource ຕ່າງໆທີ່ຕົວເຮົາຈະໃຊ້ນັ້ນມີໂຄງສ້າງການກຳນົດຂໍ້ມູນແນວໃດໂດຍໃຊ້ kubectl explain.
next blog: ວ່າດ້ວຍເລື່ອງ PV ແລະ PVC ໃນ k8s ທີ່ຈຳເປັນຕ້ອງເຂົ້າໃຈກ່ອນຈະນຳໄປໃຊ້!
