포드와 배포의 차이점은 무엇입니까?

나는 포드를 만들고 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 명령을 사용하여 포드를 직접 만들거나 배포를 통해 포드를 만들 수 있습니다. 배포를 사용하여 포드를 만드는 것이 좋습니다. 실패한 포드를 감시하고 지정된 수를 유지하기 위해 필요에 따라 새 포드를 시작합니다. 배포에서 포드를 모니터링하지 않으려면 (예 : 포드가 다시 시작해도 지속되지 않는 비 지속적 데이터를 작성하거나 포드의 수명이 매우 짧음) 포드를 사용하여 포드를 직접 만들 수 있습니다. create 명령

참고 : 배포를 사용하여 포드를 만드는 것이 좋습니다. 배포를 생성하지 않으려는 경우에만 아래 지침을 사용해야합니다.

그러나 이것은 무엇이 kind:pod좋은지에 대한 의문을 제기 합니까? 배포에서 포드를 어떻게 든 참조 할 수 있습니까? 나는 길을 보지 못했다. 포드로 얻는 것은 추가 메타 데이터이지만 replica재시작 정책 과 같은 배포 옵션은 없습니다 . 데이터를 유지하지 않고 재시작 후에도 포드가 좋은 점은 무엇입니까? 배포가 가능한 다중 컨테이너 포드를 만들 수 있다고 생각합니다.

포드와 배포는 Kubernetes API의 본격적인 개체입니다. 배포는 ReplicaSet를 통해 포드 생성을 관리합니다. 결론은 Deployment가 템플릿에서 가져온 사양으로 포드를 생성한다는 것입니다. 프로덕션 유스 케이스를 위해 포드를 직접 작성해야 할 가능성은 거의 없습니다.

Radek의 대답은 매우 좋지만 내 경험을 바탕으로하고 싶습니다 . 실제로 이해가되지 않기 때문에 종류 pod가 있는 객체 를 거의 사용 하지 않을 것입니다.

당신은 필요하기 때문에 배포 유사한 또는 기타는 Kubernetes의 API 개체 - 개체 복제 컨트롤러 또는 replicaset - 필요가 유지하는 것을 복제본 살아 (포드) (종류는 Kubernetes를 사용하는 점의이다).

일반적인 응용 프로그램에 실제로 사용할 것은 다음과 같습니다.

1. 다른 사양으로 앱 컨테이너를 호스팅 할 배포 개체 (앱 컨테이너 / 컨테이너를 지정할 위치)

2. 서비스 객체 (그룹핑 객체와 유사하며 pods특정 레이블이있는 가상 IP (클러스터 IP)를 제공하며 pods기본적으로 이전 배포 객체로 배포 한 앱 컨테이너 ).

배치 오브젝트에서 종료, 확장 및 축소 할 수 있고 영구하지 않기 때문에 IP 주소에 의존 할 수 없기 때문에 서비스 오브젝트 가 있어야합니다 pods.

따라서 안정적인 IP 를 제공 하는 서비스 와 같은 객체가 필요합니다 pods.

에 대한 컨텍스트를 제공하고 싶었 pods으므로 작업 방식을 알 수 있습니다.

오래 전에 내가 당신의 신발에 있었기를 바랍니다.)

Kubernetes에는 다음 세 가지 객체 유형이 있습니다.

• 포드 -하나 이상의 밀접한 관련 컨테이너를 실행합니다
• 서비스 -Kubernetes 클러스터에서 네트워킹 설정
• 배포 -동일한 포드 세트를 유지 관리하여 올바른 구성을 유지하고 올바른 개수의 포드가 존재하는지 확인합니다.

포드 :

• 단일 컨테이너 세트를 실행합니다
• 일회성 개발 목적으로 적합
• 생산에 직접 사용되는 경우는 드물다

전개:

• 동일한 포드 세트를 실행합니다
• 각 포드의 상태를 모니터링하여 필요에 따라 업데이트
• 개발자에게 좋습니다
• 생산에 적합

그리고 다른 답변에 동의하고 포드를 잊어 버리고 배포를 사용하십시오. 왜? 두 번째 글 머리 기호를 보면 각 포드의 상태를 모니터링하여 필요에 따라 업데이트됩니다.

따라서 다음과 같은 오류 메시지로 고심하지 않아도됩니다.

금지 : 포드 업데이트는 이외의 필드를 변경할 수 없습니다 spec.containers[*].image

따라서 포드를 리팩터링하거나 완전히 다시 생성하여 포드를 생성하여 필요한 작업을 수행 할 수 있습니다. 배포를 사용하면 원하는 구성을 변경할 수 있으며 해당 오류 메시지가 표시 될 염려가 없습니다.

포드는 컨테이너 인스턴스입니다.

그 결과는 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

포드는 컨테이너 및 Kuberntes의 기본 개체의 모음입니다. 포드의 모든 컨테이너는 동일한 노드에 있습니다.

• 생산에 적합하지 않음
• 지속적 업데이트 없음

Kubernetes의 배포는 일종의 컨트롤러입니다.

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

Deployment는 ReplicaSet을 작성하여 CurrentReplicas가 항상 desiredReplicas와 동일한 지 확인합니다.

장점 :

• 배포를 사용하여 변경 사항을 롤아웃 및 롤백 할 수 있습니다
• 각 포드의 상태를 모니터링합니다
• 생산에 가장 적합
• 롤링 업데이트 지원

Kubernetes In Action 책의 정보를 추가하고 싶기 때문에 포드, 배포 및 복제 컨트롤러 (ReplicaSet)와 같은 Kubernetes 리소스 간의 모든 그림과 연결 관계를 볼 수 있습니다

깍지

Kubernetes의 기본 배포 가능 단위입니다. 그러나 실제 사용 사례에서는 배포가 자동으로 유지되고 수동 개입없이 건강을 유지하기를 원합니다. 이를 위해 권장되는 접근 방식은 Deployment 를 사용하는 것입니다. Deployment 는 후드 아래에서 ReplicaSet을 생성합니다 .

ReplicaSet는 이름에서 알 수 있듯이, 이들로 유지 복제본 (포드)의 집합 수정 이력.

(ReplicaSet은 ReplicationController 라는 오래된 개체를 확장합니다. 이는 기록이없는 것과 완전히 동일합니다.

ReplicaSet은 지속적으로 실행중인 포드 목록을 모니터링하고 특정 사양과 일치하는 실행중인 포드 수는 항상 원하는 수와 일치하는지 확인합니다.

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는 물론, 복제 및 포드를 관리 할 수 있습니다. 배포를 사용하는 경우, 실제 포드가 생성 및 관리에 의해되는 배포 의 ReplicaSets 아닌하여 배포 직접

무슨 일이 있었는지 생각해 봅시다. 배포 리소스에서 포드 템플릿을 변경하면 단일 필드를 변경하여 앱을 최신 버전으로 업데이트했습니다!

마지막으로 배포 롤백 배포 리소스를 사용하여 배포를 이전 버전 또는 이전 버전 .

이 이미지는 Kubernetes In Action 서적에서도 제공됩니다.

노드 장애 또는 포드 종료시 포드의 종류가 변경되거나 자체 복구되지 않는 컨테이너를 관리하기 위해 포드를 피하고 대신 배포를 구현하십시오.

배포는 일반적으로 원하는 수의 포드를 항상 사용할 수 있도록 ReplicaSet을 정의하고 RollingUpdate와 같은 포드를 대체 할 전략을 지정하기 때문에 선호됩니다.

kubernetes에서 포드는 배포 가능한 가장 작은 단위입니다. 배포, 복제 세트, 상태 저장 세트, 데몬 세트와 같은 kubernetes 객체를 만들 때마다 포드가 생성됩니다.

위에서 언급했듯이 배포는 배포 객체에 언급 된 원하는 상태를 기반으로 포드를 만듭니다. 예를 들어 replicas: 5배포 매니페스트에서 언급 한 5 개의 응용 프로그램 복제본이 필요합니다 . 이제 Deployment Controller는 RBAC 정책, 네트워크 정책, 레이블, 주석, 상태 확인, 리소스 할당량, 테 인트 / 톨 레이션 및 기타와 같은 모든 메타 데이터를 사용하여 지정된 응용 프로그램의 동일한 복제본 5 개 (이하, 더 이상)를 생성하고 각 포드와 연결해야합니다. 그것은 만듭니다.

포드를 만들려는 경우가 있습니다. 예를 들어 응용 프로그램을 영원히 실행할 필요가없는 테스트 사이드카를 실행하는 경우, 여러 개의 복제본이 필요하지 않으며 응용 프로그램을 실행할 때 응용 프로그램을 실행하는 경우가 있습니다. 케이스 포드가 적합합니다. 예를 들어 helm test, 지정된 명령으로 실행할 컨테이너를 지정하는 포드 정의입니다.