내가 문서에서 이해 한 것은 다음과 같습니다.

• kubectl create = 클러스터에 새로운 k8s 리소스를 만듭니다
• kubectl replace = 라이브 클러스터의 리소스를 업데이트합니다
• kubectl apply = 생성 + 바꾸기를 원한다면 ( Reference )

내 질문은

1. 클러스터에서 동일한 작업을 수행하는 세 가지 작업이있는 이유는 무엇입니까?
2. 이러한 작업의 사용 사례는 무엇입니까?
3. 후드 아래에서 서로 어떻게 다른가요?

두 가지 접근 방식이 있습니다.

명령 관리

kubectl create우리가 명령 관리 라고 부르는 것 입니다. 이 방법을 사용하면 K8 클러스터 환경의 모양이 아니라 Kubernetes API에 생성, 교체 또는 삭제하려는 것을 알 수 있습니다.

선언적 관리

kubectl apply은 선언적 관리 방식의 일부로 , 객체에 대한 다른 변경 사항이 있더라도 라이브 객체에 적용 할 수있는 변경 사항 (예 :을 통해 scale)이 " 유지 "됩니다 apply.

명령 및 선언적 관리에 대한 자세한 내용은 Kubernetes Object Management 설명서를 참조하십시오.

CI 스크립트에서 실행할 때 자원이 이미 존재하는 경우 create 명령 에서 오류 가 발생하므로 명령 명령에 문제가 있습니다.

수행 할 수있는 작업은 및 옵션 을 사용하여 명령형 명령의 출력을 적용 (선언적 패턴)합니다 .--dry-run=true-o yaml

kubectl create whatever --dry-run=true -o yaml | kubectl apply -f -

위의 명령은 리소스가 이미 존재하는 경우 오류를 발생시키지 않으며 필요한 경우 리소스를 업데이트합니다.

이것은 선언적 패턴을 사용할 수없는 경우에 매우 유용합니다 (예 : 도커-레지스트리 비밀을 작성할 때).

내 이해에서보다 솔직한 대답을하기 위해 :

apply-기존 객체를 점진적으로 변경합니다
create-완전히 새로운 객체를 만듭니다 (이전에 존재하지 않거나 삭제됨) Kubernetes 웹 사이트에서 링크 된 DigitalOcean 기사


에서 가져옵니다 .

여기서는 작성 대신에 적용을 사용하여 이후에 변경 사항을 완전히 덮어 쓰지 않고 점진적으로 Ingress Controller 오브젝트에 적용 할 수 있습니다.

다음은 명령입니다 .

kubectl run = kubectl create deployment

장점 :

• 간단하고 배우기 쉽고 기억하기 쉽습니다.
• 클러스터를 변경하려면 단일 단계 만 필요합니다.

단점 :

• 변경 검토 프로세스와 통합하지 마십시오.
• 변경과 관련된 감사 내역을 제공하지 마십시오.
• 살아있는 것 이외의 기록을 제공하지 마십시오.
• 새 개체를 만들기위한 템플릿을 제공하지 마십시오.

다음은 필수 객체 구성입니다 .

kubectl create -f your-object-config.yaml

kubectl delete -f your-object-config.yaml

kubectl replace -f your-object-config.yaml

명령형 명령과 비교하여 장점 :

• Git과 같은 소스 제어 시스템에 저장할 수 있습니다.
• 푸시 및 감사 추적 전에 변경 사항 검토와 같은 프로세스와 통합 할 수 있습니다.
• 새 개체를 만들기위한 템플릿을 제공합니다.

명령형 명령과 비교할 때의 단점 :

• 객체 스키마에 대한 기본 지식이 필요합니다.
• YAML 파일을 작성하는 추가 단계가 필요합니다.

선언적 객체 구성과 비교하여 장점 :

• 더 간단하고 이해하기 쉽습니다.
• Kubernetes 버전 1.5 이후 더 성숙합니다.

선언적 객체 구성과 비교할 때의 단점 :

• 디렉토리가 아닌 파일에서 가장 잘 작동합니다.
• 라이브 객체에 대한 업데이트는 구성 파일에 반영되어야합니다. 그렇지 않으면 다음 교체 중에 손실됩니다.

이들은 선언적 객체 구성입니다

kubectl diff -f configs/

kubectl apply -f configs/

명령형 객체 구성과 비교 한 장점 :

• 활성 오브젝트에 직접 작성된 변경 사항은 구성 파일로 다시 병합되지 않더라도 유지됩니다.
• 디렉토리에서 작동하고 오브젝트 별 조작 유형 (작성, 패치, 삭제)을 자동으로 감지하는 기능이 향상되었습니다.

명령형 객체 구성과 비교할 때의 단점 :

• 예상치 못한 결과를 디버그하고 이해하기가 더 어렵습니다.
• diff를 사용한 부분 업데이트는 복잡한 병합 및 패치 작업을 만듭니다.

공식 문서의 아래 설명은 이해하는 데 도움이되었습니다 kubectl apply.

이 명령은 사용자가 지정한 구성의 버전을 이전 버전과 비교하고 지정하지 않은 속성에 대한 자동 변경 사항을 덮어 쓰지 않고 변경 사항을 적용합니다.

kubectl create 반면에 존재하지 않는 리소스를 생성합니다.

kubectl create 는 한 번에 하나의 객체 구성 파일로 작업 할 수 있습니다. 이것은 명령 관리라고도합니다.

kubectl create -f 파일 이름 | url

kubectl apply 는 객체 구성 yaml 파일을 포함하는 디렉토리 및 하위 디렉토리에서 작동합니다. 이것을 선언적 관리라고도합니다. 디렉토리에서 여러 오브젝트 구성 파일을 선택할 수 있습니다. kubectl apply -f 디렉토리 /

세부 사항 :
https://kubernetes.io/docs/tasks/manage-kubernetes-objects/declarative-config/ https://kubernetes.io/docs/tasks/manage-kubernetes-objects/imperative-config/

우리는 Kubernetes를 좋아합니다. 일단 우리가 원하는 것을 제공하면 개입하지 않고 달성하는 방법을 알아낼 수 있기 때문입니다.

"만들기"는 우리의 손에 물건을 가져 가서 하나님을하는 것과 같습니다. POD로만 작업하고 abt Deployment / Replication Controller를 신경 쓰지 않으려는 경우 로컬 디버깅에 유용합니다.

규칙에 따라 "적용"이 재생됩니다. "적용"은 마스터 도구와 유사하며 포드를 생성하고 수정하는 데 도움이되며 포드를 관리 할 필요가 없습니다.