ความแตกต่างระหว่างพ็อดและการปรับใช้คืออะไร

ฉันกำลังสร้างพ็อดด้วยtype:deploymentแต่ฉันเห็นว่ามีการใช้เอกสารประกอบบางอย่างtype:podมากขึ้นโดยเฉพาะเอกสารประกอบสำหรับพ็อดหลายคอนเทนเนอร์ :

apiVersion: v1
kind: Pod
metadata:
  name: ""
  labels:
    name: ""
  namespace: ""
  annotations: []
  generateName: ""
spec:
  ? "// See 'The spec schema' for details."
  : ~

แต่เพื่อสร้างพ็อดฉันสามารถใช้ประเภทการปรับใช้ :

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: ""
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: ""
    spec:
      containers:
        etc

ฉันสังเกตว่าเอกสารพ็อดบอกว่า:

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

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

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

ทั้ง Pod และ Deployment เป็นวัตถุที่เต็มเปี่ยมใน Kubernetes API การปรับใช้จัดการการสร้าง Pod โดยใช้ ReplicaSets สิ่งที่ควรพิจารณาคือการปรับใช้จะสร้างพ็อดที่มีสเปคที่นำมาจากเทมเพลต ไม่น่าเป็นไปได้ที่คุณจะต้องสร้างพ็อดโดยตรงสำหรับกรณีใช้งานจริง

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

เนื่องจากคุณต้องการวัตถุการปรับใช้ - หรือวัตถุ Kubernetes API อื่น ๆ เช่นตัวควบคุมการจำลองแบบหรือแบบจำลอง - ที่จำเป็นเพื่อให้แบบจำลอง (พ็อด) ยังมีชีวิตอยู่ (นั่นคือจุดที่ใช้ kubernetes)

สิ่งที่คุณจะใช้ในทางปฏิบัติสำหรับแอปพลิเคชันทั่วไปคือ:

1. วัตถุการปรับใช้ (ซึ่งคุณจะระบุแอพคอนเทนเนอร์ / คอนเทนเนอร์) ที่จะโฮสต์คอนเทนเนอร์แอปของคุณด้วยข้อกำหนดอื่น ๆ

2. วัตถุบริการ (ซึ่งคล้ายกับวัตถุการจัดกลุ่มและให้มันเรียกว่า IP เสมือน (IP คลัสเตอร์) สำหรับpodsฉลากที่มีป้ายกำกับแน่นอน - และวัตถุเหล่านั้นpodsเป็นคอนเทนเนอร์ของแอปที่คุณปรับใช้กับวัตถุปรับใช้เดิม)

คุณต้องมีวัตถุบริการเพราะpodsจากวัตถุการปรับใช้สามารถฆ่าปรับขนาดขึ้นและลงและคุณไม่สามารถพึ่งพาที่อยู่ IP ของพวกเขาเพราะพวกเขาจะไม่คงอยู่

ดังนั้นคุณต้องการวัตถุเช่นบริการที่ให้podsIP ที่เสถียร

แค่อยากให้บริบทแก่คุณpodsเพื่อให้คุณรู้ว่าสิ่งต่าง ๆ ทำงานร่วมกันได้อย่างไร

หวังว่าจะล้างบางสิ่งให้คุณไม่นานมานี้ฉันอยู่ในรองเท้าของคุณ :)

Kubernetes มีประเภทวัตถุสามประเภทที่คุณควรรู้เกี่ยวกับ:

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

ฝัก:

• รันคอนเทนเนอร์หนึ่งชุด
• เหมาะสำหรับการพัฒนาใช้ครั้งเดียว
• ไม่ค่อยใช้ในการผลิตโดยตรง

การใช้งาน:

• รันชุดของพ็อดที่เหมือนกัน
• ตรวจสอบสถานะของแต่ละพ็อดปรับปรุงตามความจำเป็น
• ดีสำหรับนักพัฒนา
• ดีสำหรับการผลิต

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

ดังนั้นแทนที่จะดิ้นรนกับข้อความแสดงข้อผิดพลาดเช่นอันนี้:

ต้องห้าม: การอัปเดตพ็อดอาจไม่เปลี่ยนฟิลด์อื่น spec.containers[*].image

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

พ็อดเป็นอินสแตนซ์ของคอนเทนเนอร์

นั่นคือผลลัพธ์ของ replicas: 3

คิดว่ามีหนึ่งdeploymentสามารถมีอินสแตนซ์ที่ทำงานอยู่มากมาย

//deployment.yaml
apiVersion: apps/v1beta2
kind: Deployment
metadata:
  name: tomcat-deployment222
spec:
  selector:
    matchLabels:
      app: tomcat
  replicas: 3
  template:
    metadata:
      labels:
        app: tomcat
    spec:
      containers:
      - name: tomcat
        image: tomcat:9.0
        ports:
        - containerPort: 8080

Pod คือชุดของคอนเทนเนอร์และวัตถุพื้นฐานของ Kuberntes คอนเทนเนอร์ทั้งหมดของพ็อดอยู่ในโหนดเดียวกัน

• ไม่เหมาะสำหรับการผลิต
• ไม่มีการอัพเดท

การปรับใช้เป็นตัวควบคุมชนิดหนึ่งใน Kubernetes

Controllers use a Pod Template that you provide to create the Pods for which it is responsible.

การปรับใช้สร้าง ReplicaSet ซึ่งในทางกลับกันตรวจสอบให้แน่ใจว่า CurrentReplicas นั้นเหมือนกับที่ต้องการ Replicas เสมอ

ข้อดี:

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

ฉันต้องการเพิ่มข้อมูลบางอย่างจากKubernetes In Action book เพื่อให้คุณสามารถดูรูปภาพทั้งหมดและเชื่อมต่อความสัมพันธ์ระหว่างทรัพยากร Kubernetes เช่น Pod, Deployment และ ReplicationController (ReplicaSet)

ฝัก

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

ReplicaSetเป็นชื่อที่มีความหมายเป็นชุดของแบบจำลอง (ฝัก) การบำรุงรักษาของพวกเขาด้วยการทบทวนประวัติศาสตร์

(ReplicaSet ขยายวัตถุเก่าที่ชื่อว่าReplicationControllerซึ่งเหมือนกันทุกประการ แต่ไม่มีประวัติการแก้ไข)

ReplicaSet ตรวจสอบรายการ Pod ที่กำลังทำงานอยู่อย่างต่อเนื่องและตรวจสอบให้แน่ใจว่าจำนวนฝักที่กำลังทำงานตรงกับข้อมูลจำเพาะบางอย่างนั้นตรงกับหมายเลขที่ต้องการเสมอ

Removing a pod from the scope of the ReplicationController comes in handy
when you want to perform actions on a specific pod. For example, you might 
have a bug that causes your pod to start behaving badly after a specific amount 
of time or a specific event.

การปรับใช้

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

เมื่อคุณสร้างการปรับใช้เป็นReplicaSetทรัพยากรจะถูกสร้างขึ้นภายใต้ (ในที่สุดก็ขึ้นของพวกเขา) ReplicaSetsทำซ้ำและจัดการพ็อดเช่นกัน เมื่อใช้การจัดวางฝักที่เกิดขึ้นจริงมีการสร้างและจัดการโดยการปรับใช้ ‘s ReplicaSetsไม่โดยการปรับใช้โดยตรง

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

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

ภาพเหล่านี้มาจากหนังสือของKubernetes In Actionเช่นกัน

พยายามหลีกเลี่ยง Pods และใช้การปรับใช้แทนการจัดการคอนเทนเนอร์เนื่องจากออบเจ็กต์ประเภท Pod จะไม่ได้รับการจัดตารางใหม่ (หรือการเยียวยาตนเอง) ในกรณีที่โหนดล้มเหลวหรือมีการยกเลิกพ็อด

โดยทั่วไปการปรับใช้นั้นเป็นที่นิยมมากกว่าเพราะมันจะกำหนด ReplicaSet เพื่อให้แน่ใจว่าจำนวน Pods ที่ต้องการนั้นมีอยู่เสมอและระบุกลยุทธ์เพื่อแทนที่ Pods เช่น RollingUpdate

ใน kubernetes Pods เป็นหน่วยที่เล็กที่สุดที่สามารถนำไปใช้งานได้ ทุกครั้งที่เราสร้างวัตถุ kubernetes เช่น Deployments, replica-sets, statefulsets, daemonsets จะสร้าง pod

ดังกล่าวข้างต้นการปรับใช้สร้างพ็อดตามสถานะที่ต้องการที่ระบุไว้ในวัตถุการปรับใช้ของคุณ ตัวอย่างเช่นคุณต้องการ 5 แบบจำลองของแอปพลิเคชันคุณพูดถึงreplicas: 5ในรายการการปรับใช้ของคุณ ตอนนี้ตัวควบคุมการปรับใช้มีหน้าที่สร้างแบบจำลองที่เหมือนกัน 5 รายการ (ไม่น้อยกว่าไม่มาก) ของแอปพลิเคชันที่กำหนดด้วยข้อมูลเมตาทั้งหมดเช่นนโยบาย RBAC นโยบายเครือข่ายป้ายกำกับคำอธิบายประกอบการตรวจสุขภาพสถานะโควต้าทรัพยากรมลทิน / ทนและอื่น ๆ มันสร้าง

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