Application Deployment

배포방법

1. pod 타입으로 배포
2. ReplicaSet 타입으로 배포: 실행되는 pod개수를 지정한만큼 항상 실행될 수 있게한다.
3. Deployment 타입으로 배포: 우리가 흔히 사용한다. replicaset resource를 생성시키고 그 후 생성된 replicaset resource 정보에 따라 pod resource가 해당 개수만큼 생성되어 최종적으로 실제 pod가 생성되게 한다.

Pod 타입으로 배포

내피셜이긴한데 2개가 있는듯? 물론 더 있을 수도 있어.

Run 명령어를 이용하여 pod 배포하기

kubectl run [pod name] --image=[container image name] --port=[port number]

이렇게 입력한다. 근데 쿠버네티스에서 pod는 기본적으로 IP주소를 가지고 있어야 통신을 할 수 있다. 근데 여기서 입력할때 IP주소를 따로 지정하지 않는다. 그럼 누가 ip주소를 붙여주는 거지???

IP주소는 클러스터의 네트워크 인프라가 자동으로 할당해준다고 한다! 쿠버네티스에서 클러스터로 구축할 때, 기본적인 네트워크 인프라가 함께 설치된다.

그래서 배포할 때 파드 이름, 컨테이너 이름, 포트 넘버 이렇게 3가지만 입력하면 된다.

• 그러면 pod가 죽었다가 살아나면 누가 살아난 것을 알고 IP주소를 붙여주는가? 에 대한 의문?간단히 말하면:• IP 주소는 명령어에서 직접 지정하지 않는데, 이는 쿠버네티스가 자동으로 네트워크 인프라를 통해 IP 주소를 붙여주기 때문이야.그리고 누가 Pod가 살아난 걸 알고 IP 주소를 할당해주는가에 대해서는 쿠버네티스의 핵심 구성 요소 중 하나인 kubelet이 관여해. Kubelet은 각 노드에서 실행되면서 해당 노드에서 돌아가는 Pod들을 모니터링하고, 새로운 Pod가 생기면 이를 감지해서 필요한 네트워크 설정(예: IP 주소 할당)을 처리해.파일에서 언급된 내용과 같이, 기본적인 네트워크 설정과 IP 주소 할당은 쿠버네티스가 내부적으로 처리해준다는 점을 기억하면 돼 .
• 따라서, IP 주소는 쿠버네티스 클러스터 내에서 자동으로 할당되며, 이러한 네트워크 구성은 이후에 좀 더 자세히 배울 수 있는 네트워킹의 기본이 되는 개념들이야.
• • 이러한 네트워킹 방식 덕분에 사용자는 IP 주소에 신경 쓸 필요 없이 배포에만 집중할 수 있어.
• • 사용자는 kubectl run 명령어에서 특정 컨테이너 이미지를 실행하고, 필요한 포트 번호(TCP/UDP)를 지정해.
• 쿠버네티스에서 Pod의 IP 주소는 클러스터의 네트워크 인프라가 자동으로 할당해줘. 쿠버네티스를 클러스터로 구축할 때, 기본적인 네트워크 인프라도 함께 설치돼. 이 네트워크 인프라가 Pod가 생성될 때마다 그 Pod에 고유한 IP 주소를 붙여주는 역할을 해. 이는 쿠버네티스 네트워크 플러그인이나 CNI(Container Network Interface)라는 표준을 통해 이루어져.

yaml 파일을 이용하여 pod 배포하기

kubectl create -f [file name]

❓create와 apply의 차이

create: 리소스를 처음 생성할때만 사용할 수 있다. 리소스가 이미 존재하는 상태에서는 에러가 발생하게 된다.

apply: 리소스의 생성 및 업데이트 모두 가능하다. 선언적 관리를 위한 명령어이다. (아 나 여태까지 delete하고 apply한거 다 필요없었네..?)

<aside>

시험 만약 강제로 pod를 지운다면 어떻게 될까? 컨테이너는 사라지지만 쿠버네티스의 etcd 안에 있는 pod 정보가 남아있다. 하지만 쿠버네티스는 이 pod가 더이상 존재하지 않는다는 사실을 인지한다. 어떻게?

kubelet 덕분이다. kubelet이 노드에서 pod를 감시하고 있고, 노드에 컨테이너가 사라진 것을 확인하게 되면, 쿠버네티스는 pod가 사라졌다고 알고 etcd랑 apiserver가 통신을해서 etcd에 pod 없음. 이라고 기록이 된다.! 근데 그렇게 되면 etcd는 실제상태와 목표상태가 달라지잖아??? 근데 클러스터는 목표 상태를 유지하려고 하니까 pod가 다시 생성되서 복구가 되는거임!

</aside>

describe: 상세 정보 출력

kubectl describe pod [pod name]

을 통해서 namespace, label, IP address, container와 같은 상세 정보를 확인할 수 있다.

exec: pod 내 컨테이너에 접속하여 명령 실행

kubectl exec [Pod 이름] -- [실행할 명령어]

뭐 지금까지 내가 사용한 예시를 들어보자면

kubectl exec -it nginx-pod -- /bin/bash

이 명령어를 통해서 nginx-pod의 bash 셸로 접속할 수 있다.

1. kubectl exec nginx-pod -- /bin/bash: • 그냥 Bash 셸을 실행하고 종료됨. Bash 셸에 접속해서 작업할 수 없음.
2. kubectl exec -it nginx-pod -- /bin/bash: • Bash 셸에 접속해서, ls, pwd, cat 같은 명령어를 계속 입력하면서 여러 작업을 할 수 있음.

ReplicaSet타입으로 배포

yaml 파일을 이용하여 배포하기

kubectl apply -f [File이름]

Replicaset 수를 유지하는 특징

지정한 replicaset 수를 초과하면 pod를 다시 삭제하기도 하고, 인위적으로 pod를 삭제하면 다시 새로운 Pod가 생성되는 것을 확인할 수 있다.

Deployment 타입으로 배포

create 명령어를 이용하여 deployment 배포

kubectl create deployment [Deployment name] --image=[container image name] --replicas=2

특징이 deployment로 배포하면 replica 수를 관리하고자 replica set을 자동으로 생성한다.

yaml 파일을 이용하여 deployment 배포

kubectl create -f [File name]

describe: 상세 출력

kubectl describe deployments [Deployment name]

여기서 하나 알아두어야할게 pod를 죽었다 살린다해도 IP주소가 고정되지 않아 변한다. 하지만 만약 외부에서 이용할 수 있게하려면? 고정된 IP주소를 가져야한다. 이건 Service의 영역이고 뒤에서 배운다.

Deployment의 특징

Replicaset에 문제가 발생해도 자동으로 replicaset을 복제하여 명시된 replica 개수를 유지한다. !!

배포방법

1. pod 타입으로 배포
2. ReplicaSet 타입으로 배포: 실행되는 pod개수를 지정한만큼 항상 실행될 수 있게한다.
3. Deployment 타입으로 배포: 우리가 흔히 사용한다. replicaset resource를 생성시키고 그 후 생성된 replicaset resource 정보에 따라 pod resource가 해당 개수만큼 생성되어 최종적으로 실제 pod가 생성되게 한다.

Pod 타입으로 배포

내피셜이긴한데 2개가 있는듯? 물론 더 있을 수도 있어.

Run 명령어를 이용하여 pod 배포하기

kubectl run [pod name] --image=[container image name] --port=[port number]

이렇게 입력한다. 근데 쿠버네티스에서 pod는 기본적으로 IP주소를 가지고 있어야 통신을 할 수 있다. 근데 여기서 입력할때 IP주소를 따로 지정하지 않는다. 그럼 누가 ip주소를 붙여주는 거지???

IP주소는 클러스터의 네트워크 인프라가 자동으로 할당해준다고 한다! 쿠버네티스에서 클러스터로 구축할 때, 기본적인 네트워크 인프라가 함께 설치된다.

그래서 배포할 때 파드 이름, 컨테이너 이름, 포트 넘버 이렇게 3가지만 입력하면 된다.

• 그러면 pod가 죽었다가 살아나면 누가 살아난 것을 알고 IP주소를 붙여주는가? 에 대한 의문?간단히 말하면:• IP 주소는 명령어에서 직접 지정하지 않는데, 이는 쿠버네티스가 자동으로 네트워크 인프라를 통해 IP 주소를 붙여주기 때문이야.그리고 누가 Pod가 살아난 걸 알고 IP 주소를 할당해주는가에 대해서는 쿠버네티스의 핵심 구성 요소 중 하나인 kubelet이 관여해. Kubelet은 각 노드에서 실행되면서 해당 노드에서 돌아가는 Pod들을 모니터링하고, 새로운 Pod가 생기면 이를 감지해서 필요한 네트워크 설정(예: IP 주소 할당)을 처리해.파일에서 언급된 내용과 같이, 기본적인 네트워크 설정과 IP 주소 할당은 쿠버네티스가 내부적으로 처리해준다는 점을 기억하면 돼 .
• 따라서, IP 주소는 쿠버네티스 클러스터 내에서 자동으로 할당되며, 이러한 네트워크 구성은 이후에 좀 더 자세히 배울 수 있는 네트워킹의 기본이 되는 개념들이야.
• • 이러한 네트워킹 방식 덕분에 사용자는 IP 주소에 신경 쓸 필요 없이 배포에만 집중할 수 있어.
• • 사용자는 kubectl run 명령어에서 특정 컨테이너 이미지를 실행하고, 필요한 포트 번호(TCP/UDP)를 지정해.
• 쿠버네티스에서 Pod의 IP 주소는 클러스터의 네트워크 인프라가 자동으로 할당해줘. 쿠버네티스를 클러스터로 구축할 때, 기본적인 네트워크 인프라도 함께 설치돼. 이 네트워크 인프라가 Pod가 생성될 때마다 그 Pod에 고유한 IP 주소를 붙여주는 역할을 해. 이는 쿠버네티스 네트워크 플러그인이나 CNI(Container Network Interface)라는 표준을 통해 이루어져.

yaml 파일을 이용하여 pod 배포하기

kubectl create -f [file name]

❓create와 apply의 차이

create: 리소스를 처음 생성할때만 사용할 수 있다. 리소스가 이미 존재하는 상태에서는 에러가 발생하게 된다.

apply: 리소스의 생성 및 업데이트 모두 가능하다. 선언적 관리를 위한 명령어이다. (아 나 여태까지 delete하고 apply한거 다 필요없었네..?)

<aside>

시험 만약 강제로 pod를 지운다면 어떻게 될까? 컨테이너는 사라지지만 쿠버네티스의 etcd 안에 있는 pod 정보가 남아있다. 하지만 쿠버네티스는 이 pod가 더이상 존재하지 않는다는 사실을 인지한다. 어떻게?

kubelet 덕분이다. kubelet이 노드에서 pod를 감시하고 있고, 노드에 컨테이너가 사라진 것을 확인하게 되면, 쿠버네티스는 pod가 사라졌다고 알고 etcd랑 apiserver가 통신을해서 etcd에 pod 없음. 이라고 기록이 된다.! 근데 그렇게 되면 etcd는 실제상태와 목표상태가 달라지잖아??? 근데 클러스터는 목표 상태를 유지하려고 하니까 pod가 다시 생성되서 복구가 되는거임!

</aside>

describe: 상세 정보 출력

kubectl describe pod [pod name]

을 통해서 namespace, label, IP address, container와 같은 상세 정보를 확인할 수 있다.

exec: pod 내 컨테이너에 접속하여 명령 실행

kubectl exec [Pod 이름] -- [실행할 명령어]

뭐 지금까지 내가 사용한 예시를 들어보자면

kubectl exec -it nginx-pod -- /bin/bash

이 명령어를 통해서 nginx-pod의 bash 셸로 접속할 수 있다.

1. kubectl exec nginx-pod -- /bin/bash: • 그냥 Bash 셸을 실행하고 종료됨. Bash 셸에 접속해서 작업할 수 없음.
2. kubectl exec -it nginx-pod -- /bin/bash: • Bash 셸에 접속해서, ls, pwd, cat 같은 명령어를 계속 입력하면서 여러 작업을 할 수 있음.

ReplicaSet타입으로 배포

yaml 파일을 이용하여 배포하기

kubectl apply -f [File이름]

Replicaset 수를 유지하는 특징

지정한 replicaset 수를 초과하면 pod를 다시 삭제하기도 하고, 인위적으로 pod를 삭제하면 다시 새로운 Pod가 생성되는 것을 확인할 수 있다.

Deployment 타입으로 배포

create 명령어를 이용하여 deployment 배포

kubectl create deployment [Deployment name] --image=[container image name] --replicas=2

특징이 deployment로 배포하면 replica 수를 관리하고자 replica set을 자동으로 생성한다.

yaml 파일을 이용하여 deployment 배포

kubectl create -f [File name]

describe: 상세 출력

kubectl describe deployments [Deployment name]

여기서 하나 알아두어야할게 pod를 죽었다 살린다해도 IP주소가 고정되지 않아 변한다. 하지만 만약 외부에서 이용할 수 있게하려면? 고정된 IP주소를 가져야한다. 이건 Service의 영역이고 뒤에서 배운다.

Deployment의 특징

Replicaset에 문제가 발생해도 자동으로 replicaset을 복제하여 명시된 replica 개수를 유지한다. !!

배포방법

1. pod 타입으로 배포
2. ReplicaSet 타입으로 배포: 실행되는 pod개수를 지정한만큼 항상 실행될 수 있게한다.
3. Deployment 타입으로 배포: 우리가 흔히 사용한다. replicaset resource를 생성시키고 그 후 생성된 replicaset resource 정보에 따라 pod resource가 해당 개수만큼 생성되어 최종적으로 실제 pod가 생성되게 한다.

Pod 타입으로 배포

내피셜이긴한데 2개가 있는듯? 물론 더 있을 수도 있어.

Run 명령어를 이용하여 pod 배포하기

kubectl run [pod name] --image=[container image name] --port=[port number]

이렇게 입력한다. 근데 쿠버네티스에서 pod는 기본적으로 IP주소를 가지고 있어야 통신을 할 수 있다. 근데 여기서 입력할때 IP주소를 따로 지정하지 않는다. 그럼 누가 ip주소를 붙여주는 거지???

IP주소는 클러스터의 네트워크 인프라가 자동으로 할당해준다고 한다! 쿠버네티스에서 클러스터로 구축할 때, 기본적인 네트워크 인프라가 함께 설치된다.

그래서 배포할 때 파드 이름, 컨테이너 이름, 포트 넘버 이렇게 3가지만 입력하면 된다.

• 그러면 pod가 죽었다가 살아나면 누가 살아난 것을 알고 IP주소를 붙여주는가? 에 대한 의문?간단히 말하면:• IP 주소는 명령어에서 직접 지정하지 않는데, 이는 쿠버네티스가 자동으로 네트워크 인프라를 통해 IP 주소를 붙여주기 때문이야.그리고 누가 Pod가 살아난 걸 알고 IP 주소를 할당해주는가에 대해서는 쿠버네티스의 핵심 구성 요소 중 하나인 kubelet이 관여해. Kubelet은 각 노드에서 실행되면서 해당 노드에서 돌아가는 Pod들을 모니터링하고, 새로운 Pod가 생기면 이를 감지해서 필요한 네트워크 설정(예: IP 주소 할당)을 처리해.파일에서 언급된 내용과 같이, 기본적인 네트워크 설정과 IP 주소 할당은 쿠버네티스가 내부적으로 처리해준다는 점을 기억하면 돼 .
• 따라서, IP 주소는 쿠버네티스 클러스터 내에서 자동으로 할당되며, 이러한 네트워크 구성은 이후에 좀 더 자세히 배울 수 있는 네트워킹의 기본이 되는 개념들이야.
• • 이러한 네트워킹 방식 덕분에 사용자는 IP 주소에 신경 쓸 필요 없이 배포에만 집중할 수 있어.
• • 사용자는 kubectl run 명령어에서 특정 컨테이너 이미지를 실행하고, 필요한 포트 번호(TCP/UDP)를 지정해.
• 쿠버네티스에서 Pod의 IP 주소는 클러스터의 네트워크 인프라가 자동으로 할당해줘. 쿠버네티스를 클러스터로 구축할 때, 기본적인 네트워크 인프라도 함께 설치돼. 이 네트워크 인프라가 Pod가 생성될 때마다 그 Pod에 고유한 IP 주소를 붙여주는 역할을 해. 이는 쿠버네티스 네트워크 플러그인이나 CNI(Container Network Interface)라는 표준을 통해 이루어져.

yaml 파일을 이용하여 pod 배포하기

kubectl create -f [file name]

❓create와 apply의 차이

create: 리소스를 처음 생성할때만 사용할 수 있다. 리소스가 이미 존재하는 상태에서는 에러가 발생하게 된다.

apply: 리소스의 생성 및 업데이트 모두 가능하다. 선언적 관리를 위한 명령어이다. (아 나 여태까지 delete하고 apply한거 다 필요없었네..?)

<aside>

시험 만약 강제로 pod를 지운다면 어떻게 될까? 컨테이너는 사라지지만 쿠버네티스의 etcd 안에 있는 pod 정보가 남아있다. 하지만 쿠버네티스는 이 pod가 더이상 존재하지 않는다는 사실을 인지한다. 어떻게?

kubelet 덕분이다. kubelet이 노드에서 pod를 감시하고 있고, 노드에 컨테이너가 사라진 것을 확인하게 되면, 쿠버네티스는 pod가 사라졌다고 알고 etcd랑 apiserver가 통신을해서 etcd에 pod 없음. 이라고 기록이 된다.! 근데 그렇게 되면 etcd는 실제상태와 목표상태가 달라지잖아??? 근데 클러스터는 목표 상태를 유지하려고 하니까 pod가 다시 생성되서 복구가 되는거임!

</aside>

describe: 상세 정보 출력

kubectl describe pod [pod name]

을 통해서 namespace, label, IP address, container와 같은 상세 정보를 확인할 수 있다.

exec: pod 내 컨테이너에 접속하여 명령 실행

kubectl exec [Pod 이름] -- [실행할 명령어]

뭐 지금까지 내가 사용한 예시를 들어보자면

kubectl exec -it nginx-pod -- /bin/bash

이 명령어를 통해서 nginx-pod의 bash 셸로 접속할 수 있다.

1. kubectl exec nginx-pod -- /bin/bash: • 그냥 Bash 셸을 실행하고 종료됨. Bash 셸에 접속해서 작업할 수 없음.
2. kubectl exec -it nginx-pod -- /bin/bash: • Bash 셸에 접속해서, ls, pwd, cat 같은 명령어를 계속 입력하면서 여러 작업을 할 수 있음.

ReplicaSet타입으로 배포

yaml 파일을 이용하여 배포하기

kubectl apply -f [File이름]

Replicaset 수를 유지하는 특징

지정한 replicaset 수를 초과하면 pod를 다시 삭제하기도 하고, 인위적으로 pod를 삭제하면 다시 새로운 Pod가 생성되는 것을 확인할 수 있다.

Deployment 타입으로 배포

create 명령어를 이용하여 deployment 배포

kubectl create deployment [Deployment name] --image=[container image name] --replicas=2

특징이 deployment로 배포하면 replica 수를 관리하고자 replica set을 자동으로 생성한다.

yaml 파일을 이용하여 deployment 배포

kubectl create -f [File name]

describe: 상세 출력

kubectl describe deployments [Deployment name]

여기서 하나 알아두어야할게 pod를 죽었다 살린다해도 IP주소가 고정되지 않아 변한다. 하지만 만약 외부에서 이용할 수 있게하려면? 고정된 IP주소를 가져야한다. 이건 Service의 영역이고 뒤에서 배운다.

Deployment의 특징

Replicaset에 문제가 발생해도 자동으로 replicaset을 복제하여 명시된 replica 개수를 유지한다. !!