เกี่ยวกับความนิยมที่เพิ่มขึ้นของ Kubernetes

เฮ้ ฮับ!

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

เพลิดเพลินไปกับการอ่าน!

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

คอนเทนเนอร์เริ่มต้นจากการออกแบบพิเศษสำหรับการแยกกระบวนการใน Linux; รวมตู้คอนเทนเนอร์ตั้งแต่ปี 2007 กลุ่ม cgroupsและตั้งแต่ปี 2002 – เนมสเปซ ตู้คอนเทนเนอร์ได้รับการออกแบบให้ดียิ่งขึ้นภายในปี 2008 เมื่อมีวางจำหน่าย LXCและ Google ได้พัฒนากลไกภายในองค์กรของตนเองที่เรียกว่า แอนเดอโดยที่ “งานทั้งหมดทำในคอนเทนเนอร์” จากนี้ไป เราจะก้าวไปสู่ปี 2013 ซึ่งเป็นช่วงที่ Docker เปิดตัวครั้งแรก และในที่สุดคอนเทนเนอร์ก็กลายเป็นโซลูชันยอดนิยมสำหรับมวลชนในที่สุด เครื่องมือหลักในการจัดตู้คอนเทนเนอร์ในสมัยนั้นก็คือ เมโสแม้ว่าเขาจะไม่ได้รับความนิยมอย่างล้นหลามก็ตาม Kubernetes เปิดตัวครั้งแรกในปี 2015 หลังจากนั้นเครื่องมือนี้ได้กลายเป็นมาตรฐานโดยพฤตินัยในด้านการจัดการคอนเทนเนอร์

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

โครงสร้างพื้นฐานเป็น YAML

ในโลกที่เปลี่ยนจาก Puppet และ Chef มาเป็น Kubernetes การเปลี่ยนแปลงครั้งใหญ่ที่สุดอย่างหนึ่งคือการย้ายจาก "โครงสร้างพื้นฐานเป็นโค้ด" ไปเป็น "โครงสร้างพื้นฐานเป็นข้อมูล" โดยเฉพาะเช่น YAML ทรัพยากรทั้งหมดใน Kubernetes ซึ่งรวมถึงพ็อด การกำหนดค่า อินสแตนซ์ที่ใช้งาน วอลุ่ม ฯลฯ สามารถอธิบายได้อย่างง่ายดายในไฟล์ YAML ตัวอย่างเช่น:

apiVersion: v1
kind: Pod
metadata:
  name: site
  labels:
    app: web
spec:
  containers:
    - name: front-end
      image: nginx
      ports:
        - containerPort: 80

มุมมองนี้ช่วยให้มืออาชีพ DevOps หรือ SRE แสดงปริมาณงานของตนได้อย่างเต็มที่ได้ง่ายขึ้น โดยไม่ต้องเขียนโค้ดในภาษาอย่าง Python หรือ Javascript

ข้อดีอื่นๆ ของการจัดระเบียบโครงสร้างพื้นฐานเป็นข้อมูล ได้แก่:

• GitOps หรือการควบคุมเวอร์ชันการดำเนินการ Git แนวทางนี้ช่วยให้คุณเก็บไฟล์ Kubernetes YAML ทั้งหมดไว้ในที่เก็บ git เพื่อให้ติดตามได้อย่างแน่ชัดว่ามีการเปลี่ยนแปลงเมื่อใด ใครเป็นผู้ดำเนินการ และมีอะไรเปลี่ยนแปลงอย่างแน่นอน สิ่งนี้จะเพิ่มความโปร่งใสของการดำเนินงานทั่วทั้งองค์กรและปรับปรุงประสิทธิภาพการดำเนินงานโดยขจัดความคลุมเครือ โดยเฉพาะอย่างยิ่งในกรณีที่พนักงานควรมองหาทรัพยากรที่พวกเขาต้องการ ในเวลาเดียวกัน การเปลี่ยนแปลงทรัพยากร Kubernetes โดยอัตโนมัติจะง่ายขึ้นโดยการรวมคำขอดึงเข้าด้วยกัน
• ความสามารถในการขยายขนาด เมื่อทรัพยากรถูกกำหนดเป็น YAML จะกลายเป็นเรื่องง่ายสำหรับผู้ปฏิบัติงานคลัสเตอร์ในการเปลี่ยนตัวเลขหนึ่งหรือสองตัวในทรัพยากร Kubernetes ซึ่งจะเป็นการเปลี่ยนวิธีการปรับขนาด Kubernetes จัดเตรียมกลไกสำหรับการปรับขนาดพ็อดอัตโนมัติในแนวนอน ซึ่งสามารถใช้เพื่อกำหนดจำนวนพ็อดขั้นต่ำและสูงสุดที่ต้องการได้อย่างสะดวกในการกำหนดค่าการใช้งานเฉพาะเพื่อรองรับการรับส่งข้อมูลในระดับต่ำและสูง ตัวอย่างเช่น หากคุณใช้งานการกำหนดค่าที่ต้องใช้ความจุเพิ่มเติมเนื่องจากมีการรับส่งข้อมูลที่เพิ่มขึ้นอย่างกะทันหัน maxReplicas สามารถเปลี่ยนจาก 10 เป็น 20 ได้:

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: myapp
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp-deployment
  minReplicas: 1
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

• การรักษาความปลอดภัยและการจัดการ YAML เหมาะอย่างยิ่งสำหรับการประเมินวิธีการปรับใช้สิ่งต่าง ๆ ใน Kubernetes ตัวอย่างเช่น ข้อกังวลด้านความปลอดภัยที่สำคัญเกี่ยวข้องกับว่าปริมาณงานของคุณทำงานในฐานะผู้ใช้ที่ไม่ใช่ผู้ดูแลระบบหรือไม่ ในกรณีนี้เราอาจจำเป็นต้องมีเครื่องมือเช่น คอนเฟิร์มที่สุด, เครื่องมือตรวจสอบ YAML/JSON บวกด้วย เปิดตัวแทนนโยบายผู้ตรวจสอบนโยบายเพื่อให้แน่ใจว่าบริบท บริบทความปลอดภัย ปริมาณงานของคุณไม่อนุญาตให้คอนเทนเนอร์ทำงานด้วยสิทธิ์ของผู้ดูแลระบบ หากจำเป็น ผู้ใช้สามารถใช้นโยบายง่ายๆ ได้ ผมขออธิษฐาน, แบบนี้:

package main

deny[msg] {
  input.kind = "Deployment"
  not input.spec.template.spec.securityContext.runAsNonRoot = true
  msg = "Containers must not run as root"
}

• ตัวเลือกสำหรับการผสานรวมกับผู้ให้บริการคลาวด์ แนวโน้มที่โดดเด่นที่สุดประการหนึ่งของเทคโนโลยีชั้นสูงในปัจจุบันคือการรันเวิร์กโหลดบนผู้ให้บริการคลาวด์สาธารณะ การใช้ส่วนประกอบ ผู้ให้บริการคลาวด์ Kubernetes อนุญาตให้คลัสเตอร์ใดๆ ทำงานร่วมกับผู้ให้บริการระบบคลาวด์ที่คลัสเตอร์ทำงานอยู่ ตัวอย่างเช่น หากผู้ใช้เรียกใช้แอปพลิเคชันใน Kubernetes บน AWS และต้องการเปิดเผยแอปพลิเคชันนั้นผ่านบริการ ผู้ให้บริการระบบคลาวด์จะช่วยสร้างบริการโดยอัตโนมัติ LoadBalancerซึ่งจะจัดเตรียมโหลดบาลานเซอร์ให้โดยอัตโนมัติ Amazon Elastic Load Balancerเพื่อเปลี่ยนเส้นทางการรับส่งข้อมูลไปยังพ็อดแอปพลิเคชัน

ความสามารถในการขยาย

Kubernetes สามารถขยายได้มากและนักพัฒนาก็ชอบมัน มีชุดทรัพยากรที่พร้อมใช้งาน เช่น พ็อด การปรับใช้ StatefulSets, ความลับ, ConfigMapsฯลฯ จริงอยู่ ผู้ใช้และนักพัฒนาสามารถเพิ่มทรัพยากรอื่นๆ ในแบบฟอร์มได้ คำจำกัดความของทรัพยากรที่กำหนดเอง.

เช่น หากเราต้องการกำหนดทรัพยากร CronTabจากนั้นคุณสามารถทำสิ่งนี้:

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: crontabs.my.org
spec:
  group: my.org
  versions:
    - name: v1
      served: true
      storage: true
      Schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                cronSpec:
                  type: string
                  pattern: '^(d+|*)(/d+)?(s+(d+|*)(/d+)?){4}$'
                replicas:
                  type: integer
                  minimum: 1
                  maximum: 10
  scope: Namespaced
  names:
    plural: crontabs
    singular: crontab
    kind: CronTab
    shortNames:
    - ct

หลังจากนั้นเราสามารถสร้างทรัพยากร CronTab ได้ดังนี้:

apiVersion: "my.org/v1"
kind: CronTab
metadata:
  name: my-cron-object
spec:
  cronSpec: "* * * * */5"
  image: my-cron-image
  replicas: 5

อีกทางเลือกหนึ่งสำหรับความสามารถในการขยายใน Kubernetes ก็คือนักพัฒนาสามารถเขียนคำสั่งของตนเองได้ ผู้ประกอบการ เป็นกระบวนการพิเศษในคลัสเตอร์ Kubernetes ที่ทำงานตาม “วงจรควบคุม" ด้วยความช่วยเหลือของโอเปอเรเตอร์ ผู้ใช้สามารถทำให้การจัดการ CRD (คำจำกัดความทรัพยากรที่กำหนดเอง) เป็นแบบอัตโนมัติโดยการแลกเปลี่ยนข้อมูลกับ Kubernetes API

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

$ operator-sdk new my-operator --repo github.com/myuser/my-operator

ซึ่งจะสร้างโค้ดสำเร็จรูปทั้งหมดสำหรับโอเปอเรเตอร์ของคุณ รวมถึงไฟล์ YAML และโค้ด Golang:

.
|____cmd
| |____manager
| | |____main.go
|____go.mod
|____deploy
| |____role.yaml
| |____role_binding.yaml
| |____service_account.yaml
| |____operator.yaml
|____tools.go
|____go.sum
|____.gitignore
|____version
| |____version.go
|____build
| |____bin
| | |____user_setup
| | |____entrypoint
| |____Dockerfile
|____pkg
| |____apis
| | |____apis.go
| |____controller
| | |____controller.go

จากนั้นคุณสามารถเพิ่ม API และตัวควบคุมที่จำเป็นได้ ดังนี้:

$ operator-sdk add api --api-version=myapp.com/v1alpha1 --kind=MyAppService

$ operator-sdk add controller --api-version=myapp.com/v1alpha1 --kind=MyAppService

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

$ operator-sdk build your.container.registry/youruser/myapp-operator

หากนักพัฒนาต้องการการควบคุมที่มากขึ้น ก็สามารถเปลี่ยนแปลงโค้ดสำเร็จรูปในไฟล์ Go ได้ ตัวอย่างเช่น หากต้องการแก้ไขข้อมูลเฉพาะของคอนโทรลเลอร์ คุณสามารถทำการเปลี่ยนแปลงไฟล์ได้ controller.go.

อีกหนึ่งโครงการ ทุกที่ช่วยให้คุณสร้างคำสั่งโดยใช้เฉพาะไฟล์ YAML ที่ประกาศเท่านั้น ตัวอย่างเช่น จะมีการกำหนดโอเปอเรเตอร์สำหรับ Apache Kafka โดยประมาณ ดังนั้น. ด้วยสิ่งนี้ คุณสามารถติดตั้งคลัสเตอร์ Kafka บน Kubernetes ได้โดยใช้คำสั่งเพียงไม่กี่คำสั่ง:

$ kubectl kudo install zookeeper
$ kubectl kudo install kafka

จากนั้นกำหนดค่าด้วยคำสั่งอื่น:

$ kubectl kudo install kafka --instance=my-kafka-name 
            -p ZOOKEEPER_URI=zk-zookeeper-0.zk-hs:2181 
            -p ZOOKEEPER_PATH=/my-path -p BROKER_CPUS=3000m 
            -p BROKER_COUNT=5 -p BROKER_MEM=4096m 
            -p DISK_SIZE=40Gi -p MIN_INSYNC_REPLICAS=3 
            -p NUM_NETWORK_THREADS=10 -p NUM_IO_THREADS=20

นวัตกรรม

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

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

ชุมชน

สิ่งสำคัญอีกประการหนึ่งของความนิยมของ Kubernetes คือความแข็งแกร่งของชุมชน ในปี 2015 เมื่อถึงเวอร์ชัน 1.0 Kubernetes ได้รับการสนับสนุนจาก มูลนิธิ Cloud Native Computing.

นอกจากนี้ยังมีชุมชนต่างๆ ซิก (กลุ่มความสนใจพิเศษ) มุ่งเน้นไปที่การทำงานในด้านต่างๆ ของ Kubernetes ในขณะที่โครงการมีการพัฒนา กลุ่มเหล่านี้เพิ่มคุณสมบัติใหม่อย่างต่อเนื่อง ทำให้การทำงานกับ Kubernetes สะดวกและสะดวกยิ่งขึ้น

Cloud Native Foundation ยังเป็นเจ้าภาพ CloudNativeCon/KubeCon ซึ่งเป็นการประชุมโอเพ่นซอร์สที่ใหญ่ที่สุดในโลกในขณะที่เขียนบทความนี้ โดยปกติจะจัดขึ้นปีละสามครั้ง โดยมีผู้เชี่ยวชาญหลายพันคนที่ต้องการปรับปรุง Kubernetes และระบบนิเวศ รวมไปถึงเรียนรู้คุณสมบัติใหม่ๆ ที่จะปรากฏขึ้นทุกๆ สามเดือน

นอกจากนี้ Cloud Native Foundation ยังมี คณะกรรมการกำกับดูแลด้านเทคนิคซึ่งร่วมกับ SIG จะตรวจสอบสิ่งใหม่และที่มีอยู่ โครงการ กองทุนมุ่งเน้นไปที่ระบบนิเวศคลาวด์ โครงการเหล่านี้ส่วนใหญ่ช่วยปรับปรุงจุดแข็งของ Kubernetes

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

อนาคต

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

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

ที่มา: will.com