콩꼬투리

A Pod is the basic execution unit of a Kubernetes application–the smallest and simplest unit in the Kubernetes object model that you create or deploy.

우리는 "좋은 세상"기중기를 정의할 것이다.yaml 파일로 정의합니다.우리는 apiVersion을 정의하고 Kubernetes 대상의 kind(예를 들어 Pod, 배치, 서비스 등)을 지시할 것입니다.

apiVersion: v1
kind: Pod

그런 다음 생성 중인 Pod에 식별자를 지정해야 합니다.이것들은 metadata이라고 불린다.metadata 대상은pod의 이름과pod를 식별하는 모든 라벨을 포함합니다.

metadata:
  name: hello-world
  labels:
    app: hello

Pod에서 실행될 컨테이너를 정의해야 합니다.기중기 안에는 하나 이상의 용기가 포함될 수 있다.spec 객체에서 정의할 수 있습니다.

spec:
  containers:
  - name: hello-world-container
    image: busybox
    command: ['sh', '-c', 'echo Hello World! && sleep 3600']

이것은 Docker 정의와 비슷하지만 키워드는 다릅니다.그러나 저장소에서 busybox 이미지를 가져와 지정한 명령을 실행하는 것뿐입니다.이미지를 실행할 때 컨테이너의 이름은 hello-world-container입니다.

그런데 왜 용기가 아니라 콩꼬투리일까요?

때때로 우리는 두 개의 다른 용기 사이에서 자원을 공유해야 한다.그들은 아무런 지연 없이 서로 연락해야 한다.그것들을 응집력 있는 환경에서 공존시키는 것은 취할 만하다.우리는 이 용기들을 기중기에 넣을 것이다.Kubernetes는 같은 네트워크 네임스페이스에서 컨테이너를 조정하려고 시도하기도 합니다.이것은 그들로 하여금 쉽게 공유하고 소통할 수 있게 한다.
pod의 이러한 공유 컨테이너는 다음과 같은 이점을 제공합니다.

그들은 localhost을 사용하여 서로 통신한다.

스토리지 볼륨 공유

은 응집력을 가진 서비스 단원을 구성한다.

Pods here에 대한 추가 정보 보기

초기화 및 응용 프로그램 컨테이너

Kubernetes는 기중기를 조정하고 그룹 내에서 운행합니다.때때로 우리는 용기가 작동하기 전에 약간의 물건을 운행해야 한다.
예를 들어 우리는 데이터베이스가 시작된 후에 응용 프로그램을 시작하기만 하면 된다.우리는 initContainers을 사용할 것이다.

apiVersion: v1
kind: Pod
metadata:
  name: hello-world
  labels:
    app: hello
spec:
  containers:
  - name: hello-world-container
    image: busybox
    command: ['sh', '-c', 'echo Hello World! && sleep 3600']
  initContainers:
  - name: mysql-container
    image: busybox
    command:
      - '/bin/sh'
      - '-c'
      - |
          while true
          do
            rt=$(nc -z -w 1 hello-mysql 3306)          
            if [ $? -eq 0 ]; then
              echo "DB is UP"
              break
            fi
            echo "DB is not yet reachable;sleep for 10s before retry"
            sleep 10
          done

initContainers은 containers과 유사하다.이곳에서 우리는 또 다른 busybox 용기를 사용하여 hello-mysql 기중기가 작동하고 운행하기를 기다렸다.hello-mysql 기중기는 보기에 이렇다.

apiVersion: v1
kind: Deployment
metadata:
  name: hello-mysql
spec:
  volumes:
    - name: data
      emptydir: {}
  containers:
  - name: mysql
    image: mysql
    env:
    - name: MYSQL_USER
      value: root
    - name: MYSQL_ALLOW_EMPTY_PASSWORD
      value: 'yes'
    - name: MYSQL_DATABASE
      value: 'some-app'
  ports:
  - containerPort: 3306
---
apiVersion: v1
kind: Service
metadata:
  name: hello-mysql
spec:
  selector:
    app: hello-mysql
  ports:
  - port: 3306

상기 정의는 deployment과 service으로 구성되어 있다.우리는 잠시 후에 그것들을 탐색할 것이다.그러나 Deployment의 템플릿은 Pod의 템플릿과 더욱 유사하다.initContainersbusybox 용기를 시작하여 성공하기를 기다립니다.DB is UP이 시작되면 appContainers 또는 containers이 시작됩니다.initContainers here에 대한 더 많은 정보.

콩꼬투리 생명주기

기중기마다 status의 대상이 있다.status 객체에는 phase 필드가 있습니다.

The phase is not intended to be a comprehensive rollup of observations of Container or Pod state, nor is it intended to be a comprehensive state machine.

Kubernetes 컨트롤러가 스케줄러에 pod를 생성해야 할 때스케줄러는pod의 생성을 안배합니다.컨트롤러는pod를 만들어야 하는지 결정합니다.스케줄러는kubelets가 저장소에서 용기 이미지를 다운로드하도록 요구할 것입니다.그리고 인터넷을 통해 다운로드합니다.이 단계에서 기중기는 Pending단계에 있다.
용기를 다운로드한 후,pod는 Kubernetes 집단의 노드에 분배됩니다.용기가 작동합니다.용기가 모든 필요한 프로세스를 정확하게 시작하고 실행하든지 간에, 쿠버넷은pod에 Running단계를 분배합니다.
Kubernetes 세계에서 모든 용기는 결국 종료됩니다.그것들은 성공적으로 중지하든지 아니면 실패하여 중지한다.
단계 Succeeded의pod는 성공적으로 종료되었음을 의미하며,pod는 영원히 다시 시작하지 않을 것입니다.failure으로 종료된pod는 Failed으로 종료됩니다.
Kubernetes 마스터는 실행 중인pod에 연결할 수 없는 경우가 있습니다.이 기중기들은 Unknown상이 표시되어 있다.
Kubernetes의 주요 장점은 기중기/용기를 자동으로 재부팅할 수 있다는 것이다.이 동작을 restartPolicy 필드가 있는pod로 정의할 수 있습니다.restartPolicy 접수 Always | onFailure | Never.기본값은 Always입니다.즉, 포드가 failed 상태로 끝날 때마다 Kubernetes 시스템은 포드를 다시 시작하려고 시도할 것이다.

그것을 탐지하다

컨테이너를 실행할 때 컨테이너가 실행 중일 수 있지만 Kubernetes에서 프로그램이 제대로 작동하는지 확인할 수 없습니다.이를 위해, 우리는 용기의 단점이나 응용 프로그램이 정확하게 응답하는지 정기적으로 검사해야 한다.Kubernetes는 용기를 탐지하고 정확하고 예상된 상태를 확보하는 세 가지 종류의 프로세서를 제공합니다.

프로세서는 다음과 같습니다.

실행

TCPSocketAction

HTTPGetAction

그것들은 이해하기 쉽다.컨테이너 내에서 명령을 실행하여 TCP 연결 또는 HTTP 요청을 탐지할 수 있습니다.
프로브는 Success | Failure | Unknown을 초래할 수 있습니다.
하지만 중요한 것은 언제 조사를 할지 아는 것이다.예를 들어 앞의 예시에서 데이터베이스를 사용했다.우리는 줄곧 데이터베이스가 시작되기를 기다리고 있다.이 기간 동안 프로그램을 검사하기 위해 어떤 탐침도 사용할 수 없습니다.따라서 Kubernetes 탐지기는 실행 중인 용기를 검사하기 위해 두 종류의 탐지기를 사용해야 한다.그들은 다음과 같습니다.

livenessProbe

readinessProbe

readinessProbe
readinessProbe는 용기가 준비될 때까지 용기를 탐지합니다.이것이 바로 모든 초기 작업(예를 들어 initContainers)의 운행이다.readinessProbe이 성공했을 때만pod를 사용할 수 있습니다.
응용 프로그램에 health 노드가 있다고 가정하십시오.이것은 응용 프로그램의 운행 상황을 설명한다.

readinessProbe:
   httpGet:
     path: hello-world/health
     port: http
   initialDelaySeconds: 20
   periodSeconds: 15
   failureThreshold: 6

상기readinessProbe는 지정된 경로 HTTPGetAction에서 hello-world/health을 실행하도록 지정합니다.그것은 최초로 20초를 기다려 initialDelaySeconds으로 탐측을 시작했다.그리고 용기가 준비되었는지 15초(periodSeconds)마다 탐지합니다.
여기에서 failureThreshold은 6개의 연속 고장 메시지를 받은 후에만 상태를 failure으로 지정합니다.
livenessProbe
livenessProbe는 용기가 running인지 여부를 표시합니다.탐지에 실패하면 용기가 종료되고 restartPolicy에 따라 용기를 다시 시작합니다.

livenessProbe:
 httpGet:
   path: hello-world/health
   port: http
 initialDelaySeconds: 120

여기서 livenessProbe 검사는 상기와 같은 단점을 검사하지만, 초기 120초 지연된 후에야 활성 검사를 시작합니다.

한계성

콩꼬투리 안에 용기가 있다.우리에게 있어서 그것이 이용할 수 있는 memory과 cpus의 수량을 제한하는 것은 매우 중요하다.

CPU and memory are collectively referred to as compute resources, or just resources.

resources:
  requests:
    memory: "512Mi"
    cpu: "500m"
  limits:
    memory: "1Gi"
    cpu: "1"

여기서 pod는 총 사용 가능한 CPU의 0.5% 인 512Mi 메모리와 500m을 요청할 수 있도록 지정합니다.limits은pod가 허용하는 최대 메모리와 CPU를 지정합니다.메모리 초과 조정이 있을 때, Kubernetes는 리셋 정책에 따라pod를 리셋하기만 하면 됩니다.
여기에 적당한 값을 주고 메모리와 CPU를 효과적으로 분배하는 것이 중요하다.

We can also define the resources at a pod or at the container level.

본고는 당신을 위해 쿠베르네츠의 Pods을 간략하게 소개할 수 있기를 바랍니다.kubernetes.io을 클릭하여 쿠베르네츠에 대한 정보를 더 알아보세요.
쿠버넷의 전모와 작업 원리를 알고 싶으면 this 게시물을 보십시오.
이제 Istio check-out post를 사용하여 Kubernetes 위에 예시 프로그램을 설치하고자 합니다.
너는 나를 따라와도 된다.
만약 당신이 이 문장을 좋아한다면, 좋아하거나 평론을 남겨 주세요.❤️