미니큐브란?
미니큐브(Minikube)는 로컬 개발 환경에서 Kubernetes 클러스터를 구동할 수 있게 해주는 도구입니다.
Kubernetes는 분산 컨테이너 오케스트레이션 플랫폼으로, 애플리케이션을 여러 개의 컨테이너로 분리하여 배포, 관리, 확장하는 기능을 제공합니다. 미니큐브는 이러한 Kubernetes 클러스터를 로컬 환경에서 쉽게 실행하고 테스트할 수 있도록 도와줍니다.
미니큐브를 사용하면 개발자는 로컬 컴퓨터에서 실제 Kubernetes 클러스터와 유사한 환경을 만들 수 있습니다. 이를 통해 애플리케이션을 컨테이너화하고, 로컬에서 클러스터를 구동하여 애플리케이션을 배포하고 테스트할 수 있습니다.
미니큐브는 가상화 기술을 사용하여 로컬 머신에서 격리된 Kubernetes 환경을 생성합니다. 이를 통해 개발자는 실제 클라우드 환경과 유사한 설정을 사용하여 애플리케이션을 개발하고 디버깅할 수 있습니다.
미니큐브는 단일 노드 Kubernetes 클러스터를 구성하며, 일반적으로 Docker를 기반으로 동작합니다. 또한, 다양한 플러그인과 기능을 제공하여 로컬 환경에서의 Kubernetes 클러스터 관리 및 디버깅을 용이하게 해줍니다.
미니큐브는 개발자들에게 로컬에서 Kubernetes를 사용하여 애플리케이션을 개발, 테스트, 디버깅할 수 있는 강력한 도구로 널리 사용되고 있습니다.
미니큐브를 설치하는 방법이 중요함...!! 나중에 사용할 수 있으니 정리 잘 해두기
https://ssoontory.tistory.com/306
[minikube] 환경 세팅하기_Minikube 설치 + kubectl 설치
minikube란 ? 미니큐브는 쿠버 네티스의 light한 버전이고 k8s와 달리 다중 노드가 아닌, 한 개의 노드만 들어있다. 즉 마스터서버 (api server, etcd , controller, scheduler) + 노드(proxy, kubelet)를 함께 운영 왜
ssoontory.tistory.com
* 실습을 원하시는 독자님은 위 포스팅에서 환경 세팅을 하고 시작하길 바랍니다.
▶ CLI 기본 사용법
workspace
먼저 workspace실습용 폴더 생성
# mkdir workspace && cd $_
# kubectl run nginx-pod --image=nginx
nginx의 이미지를 가진 nginx-pod라는 이름의 컨테이너를 만듬.
pod가 만들어지고 그 안에 nginx이미지로 이루어진 컨테이너를 만듬.
생성 순서 : pending > ContainerCreating > Running
# kubectl get pod
-파트를 확인해보면 nginx-pod라는 이름의 파드가 하나 나옴.
파드가 컨테이너를 담고있다고하니, 접속을해서 Welcome to Enginx 화면을 보자!
접속하는 방법은 service를 가져오는 것임.
# kubectl get service
-현재 실행중인 서비스 목록 가져오기
`kubectl get service`는 Kubernetes 클러스터에서 실행 중인 서비스의 목록을 조회하는 명령입니다.
Kubernetes는 컨테이너화된 애플리케이션을 배포하고 관리하는 오픈 소스 컨테이너 오케스트레이션 플랫폼입니다. 서비스는 Kubernetes 클러스터 내에서 실행 중인 애플리케이션의 네트워크 연결을 관리하는 리소스입니다. `kubectl get service` 명령은 현재 실행 중인 모든 서비스의 이름, 유형, 클러스터 IP, 외부 IP 등과 같은 정보를 표시합니다. 이를 통해 클러스터 내에 어떤 서비스가 있는지, 각 서비스의 세부 정보를 확인할 수 있습니다. 예를 들어, `kubectl get service` 명령을 실행하면 다음과 같은 결과를 얻을 수 있습니다: ``` NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE my-service ClusterIP 10.0.0.123 <none> 80/TCP 5d ``` 이 출력에서 `NAME`은 서비스의 이름, `TYPE`은 서비스 유형 (일반적으로 ClusterIP, LoadBalancer, NodePort 등), `CLUSTER-IP`는 내부 클러스터 IP 주소, `EXTERNAL-IP`는 외부로 노출된 IP 주소 (외부에서 접근 가능한 경우), `PORT(S)`는 서비스가 사용하는 포트, `AGE`는 서비스가 생성된 후 경과한 시간을 나타냅니다. 이러한 정보를 통해 클러스터의 서비스 상태를 파악하고, 필요한 작업을 수행할 수 있습니다.
디폴트로 들어있는 kubernetes ClusterIP 의 443 포트에 대해 궁금해져서 GPT에게 물어보았다.
"443/TCP"는 Kubernetes에서 기본적으로 제공되는 Kubernetes API 서버의 포트입니다.
Kubernetes API 서버는 Kubernetes 클러스터의 중심 컨트롤 플레인 역할을 수행하며, 클러스터 관리자 및 사용자가 Kubernetes 리소스를 생성, 수정, 삭제, 조회하는 데 사용됩니다.
API 서버는 클러스터 내부의 다른 구성 요소 및 외부에서의 요청을 처리하기 위해 네트워크 통신을 수행합니다.
포트 "443"은 HTTPS 프로토콜을 사용하는 보안 연결을 위한 포트입니다. Kubernetes API 서버는 일반적으로 TLS (전송 계층 보안) 인증서를 사용하여 안전한 통신을 제공합니다.
따라서 클러스터 관리자 및 사용자는 443 포트를 통해 보안된 연결을 통해 Kubernetes 클러스터에 API 요청을 보낼 수 있습니다.
서비스를 만드는 명령은 expose (노출하다) 가 들어감.
서비스에 연결해서 방금 만든 파드가 잘 만들어졌는지 확인해보기.
# kubectl expose pod nginx-pod --name clusterip --type=ClusterIP --port 80
- "nginx-pod"라는 이름의 파드를 "clusterip"라는 이름의 ClusterIP 유형의 서비스로 노출. 이 서비스는 클러스터 내부에서만 접근 가능하며, 포트 80으로 수신한다. 다
른 파드나 서비스는 해당 서비스를 통해 nginx-pod에 접근할 수 있다.
"kubectl expose pod nginx-pod --name clusterip --type=ClusterIP --port 80" 명령은 Kubernetes에서 nginx-pod라는 이름의 파드를 클러스터 내부에서 접근 가능한 서비스로 노출하는 명령입니다.
각 부분의 역할은 다음과 같습니다:
- "kubectl"은 Kubernetes 클러스터를 제어하는 명령줄 도구입니다.
- "expose pod"는 파드를 서비스로 노출하는 명령입니다.
- "nginx-pod"는 노출할 파드의 이름입니다. 해당 파드를 서비스로 노출합니다.
- "--name clusterip"는 생성되는 서비스의 이름을 "clusterip"로 지정합니다.
- "--type=ClusterIP"는 서비스의 유형을 "ClusterIP"로 설정합니다. 이는 클러스터 내부에서만 접근 가능한 클러스터 IP를 할당하여 서비스를 노출하는 것을 의미합니다.
- "--port 80"은 서비스가 수신할 포트를 80으로 설정합니다. 이는 클라이언트가 서비스에 접근할 때 사용할 포트입니다.
따라서 "kubectl expose pod nginx-pod --name clusterip --type=ClusterIP --port 80" 명령을 실행하면 "nginx-pod"라는 이름의 파드를 "clusterip"라는 이름의 ClusterIP 유형의 서비스로 노출합니다. 이 서비스는 클러스터 내부에서만 접근 가능하며, 포트 80으로 수신합니다. 다른 파드나 서비스는 해당 서비스를 통해 nginx-pod에 접근할 수 있습니다.
서비스 ClusterIP 는 언제 사용할까?
ClusterIP 서비스 유형은 Kubernetes 클러스터 내부에서만 접근 가능한 서비스를 생성할 때 사용됩니다. 일반적으로 다음과 같은 상황에서 ClusterIP 서비스를 사용합니다:
1. 내부 서비스 통신: 클러스터 내부의 다른 컴포넌트 또는 서비스 간의 통신에 사용됩니다. 예를 들어, 웹 애플리케이션과 데이터베이스 사이의 통신이 필요한 경우, 데이터베이스를 ClusterIP 서비스로 노출하고 웹 애플리케이션에서 해당 서비스를 통해 데이터베이스에 접근할 수 있습니다.
2. 로드 밸런싱: 여러 파드 인스턴스를 실행하는 경우, ClusterIP 서비스를 사용하여 이들을 로드 밸런싱합니다. 클라이언트는 ClusterIP 서비스에 접근하여 파드 인스턴스 중 하나에 연결됩니다. 로드 밸런싱은 파드의 부하 분산과 고가용성을 제공합니다.
3. 내부 모니터링: 클러스터 내부의 모니터링 시스템이나 로깅 시스템과 같은 컴포넌트를 ClusterIP 서비스로 노출하여 다른 컴포넌트에서 접근할 수 있게 할 수 있습니다.
ClusterIP 서비스는 클러스터 내부에서만 접근 가능하며, 외부에는 노출되지 않습니다. 따라서 외부에서 해당 서비스에 직접 접근할 수 없고, 내부 컴포넌트 간 통신에 사용됩니다.
# kubectl get service
Nginx라 80포트를 여는 것임.
type의 경우 시작할때는 C대문자로!
curl명령을 통해 확인하기
Welcome to nginx! 가 나오는 것을 보아 nginx 이미지가 잘 들어간 것을 알 수 있다.
외부에서 접속을 해 오는 경우 nodeport 와 loadbalancer 사용!
1. nodeport
# kubectl expose pod nginx-pod --name nodeport --type=NodePort --port 80
type부분은 이미 정해진 이름이라 내가 정할 수 없음!
80은 CLUSTER-IP의 포트 (내부) 31543번은 외부 컨테이너 포트 번호임 / 랜덤하게 잡힘.
랜덤하게 잡한 포트번호를 이용해 아이피가 잡혀 소통함.
내부 클러스터 안에서 내부에서 접속할 수 있는 방법도 제공하고, 외부에서 접속할 수 있는 방법도 제공.
1) 외부에서 접근하기.
[NODE의 IP = minikube의 아이피 = 모바엑스텀에서 연결한 아이피] : [NodePort 서비스의 Port]
2) 내부에서 접근하기 (Curl명령을 통해 Cluster-IP 로 들어가기)
2. loadbalancer
# kubectl expose pod nginx-pod --name loadbalancer --type=LoadBalancer --external-ip [내 vm의 아이피] --port 80
포드번호 넣지 않고 80포트로 접속하고 싶을때 사용해보기
로드벨런서는 EXTERNAL-IP를 채워줘야함.
*vm으로 실습을 하고 있다면, EXTERNAL-IP는 내 VM의 아이피를 넣어주기!!!!
또 Crul 명령을 통해 클러스터 ip로 접속이 가능함. 포드번호 넣지 않고도 external ip로도 바로 접속 가능
외부 아이피로 접속이 가능하다.
로드벨런서는 접근방법
Cluster -IP : curl 명령으로 Cluster IP 로 내부에서 접속
External IP :External ip 로 외부에서 접속
< 쿠버네티스 describe 명령 >
- 리소스의 상세한 상태를 확인할 수 있다.
- get으로 일단 리소스를 조회하여 리소스 이름을 확인한 뒤 적용해야한다.
# kubectl describe pod nginx-pod
run[key]=[value]nginx-pod
labels : 구분짓기 위함. 나중에는 연결과 관련.
run=nginx-pod 내가 주었던 파드의 이름이 라벨에 잡혀있는 것을 볼 수 있따.
IP
# kubectl describe service clusterip
`kubectl describe service clusterip`는 Kubernetes 클러스터에서 실행 중인 ClusterIP 유형의 서비스의 자세한 정보를 조회하는 명령입니다. ClusterIP는 Kubernetes 내부에서 사용되는 가상 IP 주소로, 클러스터 내부에서만 접근 가능한 서비스입니다. 다른 파드나 서비스가 이 ClusterIP를 통해 서비스에 접근할 수 있습니다. 외부로 노출되지 않으며, 주로 내부 서비스 간 통신을 위해 사용됩니다.
`kubectl describe service clusterip` 명령은 지정된 ClusterIP 유형의 서비스에 대한 자세한 정보를 출력합니다. 이를 통해 해당 서비스의 구성, 연결된 엔드포인트, 포트 설정 등을 확인할 수 있습니다.
예를 들어, `kubectl describe service my-service` 명령을 실행하면 다음과 같은 결과를 얻을 수 있습니다:
``` Name: my-service Namespace: default Labels: <none> Annotations: <none> Selector: app=my-app Type: ClusterIP IP: 10.0.0.123 Port: http 80/TCP TargetPort: 8080/TCP Endpoints: 10.0.1.23:8080, 10.0.2.45:8080 Session Affinity: None ```
위 출력에서 `Name`은 서비스의 이름, `Namespace`는 서비스가 속한 네임스페이스, `Type`은 서비스 유형 (ClusterIP), `IP`는 할당된 ClusterIP 주소, `Port`는 서비스가 사용하는 포트, `TargetPort`는 서비스가 연결된 파드의 포트, `Endpoints`는 서비스와 연결된 파드의 엔드포인트 주소를 나타냅니다. 이렇게 자세한 정보를 통해 서비스의 구성과 관련된 세부사항을 확인할 수 있습니다.
get service보다 더 자세한 정보를 얻을 수 있는
# kubectl describe service nodeport
# kubectl describe service loadbalancer
# kubectl exec -it nginx-pod -- bash
만든 pod에 들어가겠다는 명령어
pod이름 뒤에 --를 넣지 않으면 안 될 수 있음. 곧 인식이 안될 것임. 가급적이면 --를 넣어달라고 말함.
"kubectl exec -it nginx-pod -- bash" 명령은 실행 중인 Kubernetes 클러스터의 "nginx-pod" 파드에 대해 대화형 bash 셸 세션을 시작하는 명령입니다.
각 부분의 역할은 다음과 같습니다:
- "kubectl"은 Kubernetes 클러스터를 제어하는 명령줄 도구입니다.
- "exec"는 파드 내에서 명령을 실행하는 명령입니다.
- "-it"는 대화형(TTY를 사용하는 상호 작용 모드)으로 실행되도록 설정하는 옵션입니다.
- "nginx-pod"는 대화형 셸을 실행할 파드의 이름입니다.
- "-- bash"는 실행할 명령을 지정하는 옵션으로, 여기서는 bash 셸을 실행하도록 지정합니다.
따라서 "kubectl exec -it nginx-pod -- bash" 명령을 실행하면 Kubernetes 클러스터의 "nginx-pod" 파드 내에서 대화형 bash 셸 세션이 시작됩니다. 이를 통해 해당 파드에 진입하여 셸 명령을 실행하고, 파드 내부에서 작업을 수행하거나 디버깅할 수 있습니다.
# echo "<h1>web01</h1>" > /usr/share/nginx/html/index.html
파드 안쪽에 컨테이너 하나만 있으면 안쪽으로 들어가서 echo명령으로 웹 html 내용을 바꿀 수 있음!!!
지금 현재 위치(=workspace 디렉터리)에 폴더 하나 만들기
# mkdir html
웹서버에 잘 적용되는지 확인하기 위해 확인용 tar파일을 준비해주어야 이 실습을 따라할 수 있다.
나는 이미 준비해둔 tar파일을 html 디렉터리에 압축을 해제해주었다.
# tar xvf ~/gcp.tar -C html/
# ls html
# kubectl cp html nginx-pod:/usr/share/nginx
`kubectl cp html nginx-pod:/usr/share/nginx`는 Kubernetes 클러스터 내에서 `kubectl` 명령어를 사용하여 로컬 시스템의 `html` 디렉토리를 `nginx-pod`라는 이름의 파드(Pod)의 `/usr/share/nginx` 경로로 복사하는 명령입니다.
여기서 `kubectl`은 Kubernetes 클러스터와 상호 작용하기 위한 커맨드 라인 도구입니다.
`cp`는 `kubectl`의 파일 복사 명령어로, 파일이나 디렉토리를 클러스터 내의 파드와 복사하는 역할을 합니다.
`html`은 로컬 시스템의 복사할 디렉토리 또는 파일을 나타냅니다.
`nginx-pod`는 목적지로 지정할 파드의 이름입니다.
`/usr/share/nginx`는 복사한 파일이나 디렉토리가 저장될 목적지 경로입니다.
따라서, `kubectl cp html nginx-pod:/usr/share/nginx` 명령은 로컬 시스템의 `html` 디렉토리를 `nginx-pod` 파드의 `/usr/share/nginx` 경로로 복사하는 작업을 수행합니다.
앞선 echo 명령으로 띄워준 web01 이 보이는 웹페이지에서 tar파일을 압축해제 해서 적용시킨 부트스트랩 화면이 잘 띄워지고 있는 것을 확인해 볼 수 있다.
쿠버네티스 모든 리소스들 확인하기
# kubectl get all
# kubectl delete svc clusterip
# kubectl delete svc --all
# kubectl get service
pod 들과 service를 한번에 지우고 싶다면 ,로 연결한 후 --all 명령을 쳐준다.
# kubectl delete pod,svc --all
# kubectl options
kubectl을 이용해서 내가 활용할 수 있는 옵션들이 쭉 나옴.
# kubectl api-resources
쿠버네티스 api들의 버전이 있음.
이 명령을 찍었을때 나오는버전이 지금 내 환경이서 이용되는 버전임.
< get 명령으로 node와 service 단축어로 확인하기 >
# kubectl get no
# kubectl get svc
< -o wide명령으로 더 자세한 설명 확인하기 >
# kubectl get no
# kubectl get no -o wide
# kubectl get no -o wide --no-headers
헤더 부분이 싹 사라짐.
< n번째 순서에 해당하는 자원 출력하는 명령어. >
# kubectl get no -o wide --no-headers | awk '{print$6}'
자세한 내용을 살펴보려고 할때 사용.
# kubectl run nginx-pod --image=leees0053/web-site:aws
내가 가지고 있는 도커 허브에 있는 이미지를 가져와서 파드 런칭하기
* 이 실습을 따라하는 분이 계시다면 도커 허브에 이미지를 올려서 활용해보시길 추천드립니다.
내 도커허브 이미지에서 가져와 생성한 파드에 loadbalancer 서비스 붙여주기!
# kubectl expose pod nginx-pod --name loadbalancer --type LoadBalancer --external-ip [내 VM 아이피 넣어주기] --port 80
< -o wide 명령을 덧붙여서 자세한 정보 확인하기 >
# kubectl get pod -o wide
# kubectl get pod
# kubectl get svc -o wide
# kubectl get svc
deployment로 파드 배포하기
https://kimjingo.tistory.com/133
[k8s] 디플로이먼트(Deployment)
디플로이먼트 디플로이먼트(Deployment)는 쿠버네티스에서 상태가 없는(stateless) 앱을 배포할 때 사용하는 가장 기본적인 컨트롤러입니다. 쿠버네티스가 처음 등장했을 때는 Replication Controller에서
kimjingo.tistory.com
도커를 가지고 컨테이너를 배포하는게 run 명령이었는데 deployment는 그 이상의 개념을 가짐.
디플로이먼트는 파드와 레플리카셋에 버전 관리 기능을 추가한 것이라고 생각하면 이해가 쉽다!!!!
# kubectl create deployment nginx-app --replicas=2 --image=nginx
해당 명령어 `kubectl create deployment nginx-app --replicas=2 --image=nginx`는 Kubernetes 클러스터 내에서 `kubectl` 명령어를 사용하여 `nginx-app`라는 이름의 배포(Deployment)를 생성하는 명령입니다.
이 배포는 `nginx`라는 이미지를 사용하며, 두 개의 레플리카(Pod)를 생성합니다.
여기서 `kubectl`은 Kubernetes 클러스터와 상호 작용하기 위한 커맨드 라인 도구입니다.
`create deployment`은 `kubectl`의 배포 생성 명령어로, 이미지를 기반으로 배포를 생성하는 역할을 합니다.
`nginx-app`은 생성할 배포의 이름입니다. 이름을 원하는 대로 지정할 수 있습니다.
`--replicas=2`는 배포 내에서 생성할 레플리카 수를 지정하는 옵션입니다. 이 경우, 두 개의 레플리카를 생성하도록 지정되었습니다. `--image=nginx`는 배포에 사용할 컨테이너 이미지를 지정하는 옵션입니다.
`nginx`는 공식적으로 제공되는 Nginx 컨테이너 이미지를 의미합니다.
따라서, 해당 이미지를 배포의 컨테이너로 실행할 것입니다. 따라서, `kubectl create deployment nginx-app --replicas=2 --image=nginx` 명령은 `nginx` 이미지를 사용하여 `nginx-app`라는 이름의 배포를 생성하고, 두 개의 레플리카를 생성하는 작업을 수행합니다.
deployment 리소스의 이름 - nginx-app
replica -> pod의 갯수는 두개.
--image nginx 이미지로!
아무리 쿠버네티스가 뛰어나더라도 도커의 이미지 없이는 쿠버네티스가 동작하기 어려움.
# kubectl get deployment.apps
# kubectl get deployments.apps -o wide
라벨을 넣지 않으면 알아서 app을 키로 둠.
# kubectl get replicasets.apps
Deployment가 나오기 전에 나왔던 애.
디플로이먼트가 replicaset을 포함하고 있다.
deployment와 replica 둘은 연관성이 있음.
replicaset은 복제와 관련된 내용을 담고 있음. deployment를 만들면 복제와 관련된 부분을 책임을 맡음.
replicaset을 만들면 끝나는 일인데 왜 deployment를 만듬?
replicaset은 업데이트 기능이 안됨.
위에서 말했듯이 롤링 업데이트 전략을 이용하기 위해서 deployment를 이용함!!
= deployment는 pod replica 기능, 업데이트 기능 다 가짐.
pod에 대한 정보를 보기!
# kubectl get pod
deployment , replicasets , pod 연관성
- 하나의 deployment.apps에는 두개의 pod가 있음.
- deployment안에는 복제를 해주는 replicaset이 있고,
- replica 덕분에 pod 목록에는 두개의 pod가 형성되어 있다.
yaml파일 실습을 진행하기 위해 앞서 만들어둔 서비스와 pod들을 미리 다 삭제하기!
▼ 템플릿, yaml파일으로 컨테이너 실행하기
1. pod 생성
# vi nginx-pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: nginx-pod
labels:
app: nginx-pod
spec:
containers:
- name: nginx-pod-container
image: nginx
ports:
- containerPort: 8080 # 별도 지정된 포트가 없다면 8080으로 지정하라 (docker -P 유사)
# kubectl apply -f nginx-pod.yaml
# kubectl get pod -o wide
# kubectl describe pod nginx-pod
2. Cluster IP (service) 생성
# vi clusterip-pod.yaml
apiVersion: v1
kind: Service
metadata:
name: clusterip-pod
spec:
type: ClusterIP
selector:
app: nginx-pod
ports:
- protocol: TCP
port: 80
targetPort: 80
# kubectl apply -f clusterip-pod.yaml
-clusterip-pod.yaml 파일을 appy 명령으로 서비스 생성에 사용.
# kubectl get svc -o wide
-클러스터 아이피 서비스가 잘 만들어 졌는지 확인해보기.
# kubectl describe svc clusterip-pod
- 서비스 자세한 설명 확인하기.
# kubectl edit svc clusterip-pod
-edit 명령으로 vi 편집기를 거치지 않고 수정하기.
3. 노드포트 (service) 생성하기
# vi nodeport-pod.yaml
apiVersion: v1
kind: Service
metadata:
name: nodeport-pod
spec:
type: NodePort
selector:
app: nginx-pod
ports:
- protocol: TCP
port: 80
targetPort: 80
nodePort: 30080
# kubectl apply -f nodeport-pod.yaml
# kubectl get svc -o wide
# kubectl describe svc nodeport-pod
# kubectl edit svc nodeport-pod
wp!
타겟포트 바꿨더니 안됨.
타겟포트를 다시 80포트로 바꾸기!
4. 로드벨런서 만들기
# vi loadbalancer-pod.yaml
apiVersion: v1
kind: Service
metadata:
name: loadbalancer-pod
spec:
type: LoadBalancer
externalIPs: #멀티로 꾸밀때 여러개 필요하고, 우리는 미니큐베할꺼라 ip하나만 넣어주기
- 192.168.1.188
- 192.168.1.211
- 192.168.1.216
selector:
app: nginx-pod
ports:
- protocol: TCP
port: 80
targetPort: 80
nodePort: 30080
# kubectl apply -f loadbalancer-pod.yaml
# kubectl get svc -o wide
포트번호를 넣지 않아도 괜춘!
바로 external-ip를 이용해 접속해볼 수 있다.
# kubectl describe svc loadbalancer-pod
-로드벨런서의 자세한 내용을 보기 위한 명령어
# kubectl edit svc loadbalancer-pod
-로드벨런서 속성을 편집하기 위한 명령어
5. 레플리카 셋 만들기
---yaml파일을 이용해 ReplicaSet 실습하기
# vi replicaset.yaml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: nginx-replicaset
spec:
replicas: 3 # desired state (kube-controller-manager)
selector:
matchLabels:
app: nginx-replicaset
# selector의 matchLabels와 template의 labels부분의 app 이름은 연결고리라 일치해야함.
template: #(aws에서 오토스케일 세팅하기 앞서서 시작템플릿을 만드는 그 느낌처럼 컨테이너에 그 내용을 담음)
metadata:
name: nginx-replicaset
labels:
app: nginx-replicaset #selector와 label부분이 반드시 같아야함. 같지 않으면 에러가남...!
spec: #spec에서는 컨테이너에 대한 정의를 함.
containers:
- name: nginx-replicaset-container
image: nginx
ports:
- containerPort: 80
# kubectl apply -f replicaset.yaml
# kubectl get replicasets.apps -o wide
# kubectl describe replicasets.apps nginx-replicaset
# kubectl edit replicasets.apps nginx-replicaset
- 수정할 일이 있으면 해당 명령을 통해 수정하면 된다.
# vi clusterip-replicaset.yaml # 리플리카 셋에서 사용할 클러스터아이피 야믈
apiVersion: v1
kind: Service
metadata:
name: clusterip-replicaset
spec:
type: ClusterIP
selector:
app: nginx-replicaset
ports:
- protocol: TCP
port: 80
targetPort: 80
# kubectl apply -f clusterip-replicaset.yaml
# kubectl get svc -o wide
# kubectl describe svc clusterip-replicaset
# kubectl edit svc clusterip-replicaset
# vi nodeport-replicaset.yaml # 리플리카 셋에서 사용할 노드포트 야믈
apiVersion: v1
kind: Service
metadata:
name: nodeport-replicaset
spec:
type: NodePort
selector:
app: nginx-replicaset
# nginx-replicaset에서 사용할 노드포트이기 때문에 selector에서 언급해줘야 함.
ports:
- protocol: TCP
port: 80
targetPort: 80
nodePort: 30081
# kubectl apply -f nodeport-replicaset.yaml
# kubectl get svc -o wide
# kubectl describe svc nodeport-replicaset
# kubectl edit svc nodeport-replicaset
# vi loadbalancer-replicaset.yaml # 레플리카 셋에서 사용할 로드밸런서 야믈
apiVersion: v1
kind: Service
metadata:
name: loadbalancer-replicaset
spec:
type: LoadBalancer
externalIPs:
#자신이 실습하고 있는 환경(ex : vm) ip를 넣어주기!
- 192.168.1.188
- 192.168.1.211
- 192.168.1.216
# minikube는 노드가 하나뿐이라 아이피 하나만 넣어주면 된다.
selector:
app: nginx-replicaset
ports:
- protocol: TCP
port: 80
targetPort: 80
# kubectl apply -f loadbalancer-replicaset.yaml
# kubectl get svc -o wide
# kubectl describe svc loadbalancer-replicaset
# kubectl edit svc loadbalancer-replicaset
생성한 로드벨런서에 연결된 pod로 들어가기 위해서는 뒤에 포트를 넣어 구별해야 됨.
라벨이 다른 곳을 가리킴
EXTERNAL 아이피가 같음.
뒤에 포트를 붙여주면 접속이 가능
이를 방지하기 위해 8080포트로 바꿨는데 당연히 접속이 안됨.
< ReplicaSet edit기능을 통해 image 고치기! >
업데이트가 안됨!!!!!!!!!...
Deployment는 선언적 업데이트가 되는지 확인해 볼 것임.
# kubectl api-resources
`kubectl api-resources`는 Kubernetes 클러스터에서 사용 가능한 API 리소스의 목록을 표시하는 명령입니다.
Kubernetes는 API를 통해 클러스터 리소스를 관리합니다. 이 명령을 사용하면 클러스터에서 사용 가능한 리소스의 종류와 이름, 별칭, 그룹, 버전 등을 확인할 수 있습니다. 예를 들어, `kubectl api-resources`를 실행하면 다음과 유사한 결과를 얻을 수 있습니다:
NAME SHORTNAMES APIGROUP NAMESPACED KIND bindings true Binding componentstatuses cs false ComponentStatus configmaps cm true ConfigMap endpoints ep true Endpoints events ev true Event
위의 출력에서 `NAME`은 리소스의 이름을, `SHORTNAMES`는 해당 리소스에 대한 짧은 별칭을 나타냅니다.
`APIGROUP`은 리소스가 속한 API 그룹을 나타내며, `NAMESPACED`는 해당 리소스가 네임스페이스 내에서 사용 가능한지 여부를 나타냅니다.`KIND`는 리소스의 종류를 나타냅니다.
`kubectl api-resources` 명령은 Kubernetes 클러스터의 현재 상태를 이해하고 클러스터 내의 리소스를 조작하는 데 유용한 정보를 제공합니다.
단축어 확인할 수 있음.
# kubectl get replicasets.apps -o wide
< Deployment >
디플로이먼트(Deployment) 는 파드와 레플리카셋(ReplicaSet)에 대한 선언적 업데이트를 제공한다.
디플로이먼트에서 의도하는 상태 를 설명하고, 디플로이먼트 컨트롤러(Controller)는 현재 상태에서 의도하는 상태로 비율을 조정하며 변경한다. 새 레플리카셋을 생성하는 디플로이먼트를 정의하거나 기존 디플로이먼트를 제거하고, 모든 리소스를 새 디플로이먼트에 적용할 수 있다.
# vi deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3
selector:
matchLabels:
app: nginx-deployment
template:
metadata:
name: nginx-deployment
labels:
app: nginx-deployment
spec:
containers:
- name: nginx-deployment-container
image: nginx
ports:
- containerPort: 80
근데 어제 작성한 ReplicaSet이랑 비교했을때 뭐가 다르지?
이름만 다르고 거의 똑같음.
수정(롤백)이 가능.
# kubectl apply -f deployment.yaml
# kubectl get deployments.apps -o wide
# kubectl describe deployments.apps nginx-deployment
# kubectl edit deployments.apps nginx-deployment
# kubectl get pod
이미지가 잘 수정이 되었는지 확인하기 위해서 describe명령으로 자세히 확인해보기
# kubectl describe pod nginx-deployment-85544744f4-njtgx
# vi clusterip-deployment.yaml # 클러스터아이피 야믈
apiVersion: v1
kind: Service
metadata:
name: clusterip-deployment
spec:
type: ClusterIP
selector:
app: nginx-deployment
ports:
- protocol: TCP
port: 8080
targetPort: 80
# kubectl apply -f clusterip-deployment.yaml
# kubectl get svc -o wide
# kubectl describe svc clusterip-deployment
# kubectl edit svc clusterip-deployment
셀렉터 등을 바꿀 수 있다.
클러스터 아이피는 내부에서 접속이 가능하고,
노드포트는 외부에서 vm아이피 + 노드포트의 고유 포트번호 로 웹 접속이 가능함.
# vi nodeport-deployment.yaml # 노드포트 야믈
apiVersion: v1
kind: Service
metadata:
name: nodeport-deployment
spec:
type: NodePort
selector:
app: nginx-deployment
ports:
- protocol: TCP
port: 80
targetPort: 80
nodePort: 32080
*nodePort 충돌나지 않도록 미리 포트 확인해서 넣어주거나, 랜덤으로 받아올 수 있도록 nodePort를 지워줘도 된다.
외부에서 접속할 수 있는 포트번호를 제공해준다.
# kubectl apply -f nodeport-deployment.yaml
# kubectl get svc -o wide
# kubectl describe svc nodeport-deployment
엔드포인트 여러개 잡히면 로드벨런서의 역할을 한다고 볼 수 있음.
# kubectl edit svc nodeport-deployment
보통 온프레미스로 세팅할때는 이 방법으로!
# vi loadbalancer-deployment.yaml # 로드밸런서 야믈
apiVersion: v1
kind: Service
metadata:
name: loadbalancer-deployment
spec:
type: LoadBalancer
externalIPs:
- 192.168.2.53
selector:
app: nginx-deployment
ports:
- protocol: TCP
port: 8888
targetPort: 80
nodePort: 32088
# kubectl apply -f loadbalancer-deployment.yaml
# kubectl get svc -o wide
포트번호 8888 이용
# kubectl describe svc loadbalancer-deployment
엔드포인트가 하나 더 있음. 노드포트와 다른점이 크게 없음.
# kubectl edit svc loadbalancer-deployment
자원 지워주기. * 롤링 업데이트 때문에 deployment빼고 지우기!!! (만약 다 지웠다면 apply로 되살리기...)
# kubectl get all
# kubectl delete pod,svc --all
# kubectl delete replicaset,svc --all
# kubectl delete deployment,svc --all
위 세 명령어 한번에 실행하는 명령어 = 다 지움.
# kubectl delete all --all
# kubectl get all
< Deployment 롤링 업데이트 제어해보기 >
디플로이 먼트 파일 복사해서 로드벨런서 야물 붙이기!
디플로이먼트 파일 가장 아래에 붙여놓기 o 눌러서 맨 아래로 간뒤,
--- (구분을 위해 짝대기 세개 넣어주기)
# vi deployment.yaml 파일에 loadbalancer-deployment.yaml 내용 넣어주기!
# vi loadbalancer-deployment.yaml # 로드밸런서 야믈파일 내용만 붙이기
apiVersion: v1
kind: Service
metadata:
name: loadbalancer-deployment
spec:
type: LoadBalancer
externalIPs:
- [ 내 vm ip로 넣어주기 ]
selector:
app: nginx-deployment
ports:
- protocol: TCP
port: 80 #앞서 서비스들 다 정리했으니까 80으로 설정해주기!
targetPort: 80
nodePort: 32088
디플로이먼트 파일에 디플로이먼트 로드벨런서 야물 붙이기
잘 생성 되었는지 확인해보기
# kubectl get svc -o wide
< 이미지 변경해주기 >
# kubectl describe deployments.apps
컨테이너 이름 확인해주기
# kubectl get pod
# kubectl describe pod nginx-deployment-55cb6f9cb7-k7fcf
이미지의 이름 확인하는 법
# kubectl set image deployment.apps/nginx-deployment nginx-deployment-container=leees0053/web-site:aws
`kubectl set image deployment.apps/nginx-deployment nginx-deployment-container=leees0053/web-site:aws`는 Kubernetes 클러스터에서 실행 중인 `nginx-deployment`라는 이름의 배포(Deployment)에서 `nginx-deployment-container`라는 컨테이너의 이미지를 `leees0053/web-site:aws`로 변경하는 kubectl 명령입니다. Kubernetes에서 Deployment는 컨테이너화된 애플리케이션을 관리하기 위한 리소스 유형 중 하나입니다. Deployment는 여러 개의 Pod를 생성하여 애플리케이션을 실행하고, 필요에 따라 Pod의 수를 조절하고 롤링 업데이트 등의 배포 전략을 수행할 수 있습니다.
`kubectl set image` 명령은 Deployment의 컨테이너 이미지를 업데이트하는 데 사용됩니다.
위의 명령에서 `nginx-deployment`는 업데이트할 Deployment의 이름을 나타내며,
`nginx-deployment-container`는 해당 Deployment 내에서 업데이트할 컨테이너의 이름입니다.
`leees0053/web-site:aws`는 새로운 이미지의 이름을 나타냅니다.
따라서 이 명령은 `nginx-deployment`의 `nginx-deployment-container` 컨테이너 이미지를 `leees0053/web-site:aws`로 변경합니다. 이 명령을 실행하면 Kubernetes는 해당 Deployment의 Pod를 일부 또는 전체 다시 시작하여 새 이미지로 업데이트합니다. 이를 통해 애플리케이션을 새 버전으로 배포하거나 이미지를 업데이트할 수 있습니다.
# kubectl get pod
이미지를 업데이트하면서 기존 이미지를 가진 pod하나를 종료시키고 하나를 running시킴.
다시 바꿔보기
# kubectl set image deployment/nginx-deployment nginx-deployment-container=leees0053/web-site:food
# kubectl get pod
< 롤백으로 버전 관리하기 실습 >
Kubernetes에서 롤백(Rollback)은 이전 상태로 클러스터 리소스를 되돌리는 작업을 말합니다.
롤백은 배포(Deployment)의 이전 버전으로 돌아가는 것을 의미합니다.
배포 시 이전 버전으로 롤백하는 경우, 이전 상태로 애플리케이션을 복원하여 잠재적인 문제나 잘못된 업데이트를 해결할 수 있습니다. 롤백은 일반적으로 다음과 같은 시나리오에서 유용합니다:
1. 애플리케이션 업데이트 중에 문제가 발생한 경우.
2. 새로운 버전의 애플리케이션이 예상대로 작동하지 않는 경우.
3. 애플리케이션의 성능이 이전 버전과 비교하여 저하된 경우.
Kubernetes에서 롤백을 수행하는 방법은 다양한 접근 방식이 있습니다.
가장 일반적인 방법은 `kubectl rollout undo` 명령을 사용하는 것입니다. 이 명령은 배포의 이전 버전으로 롤백하며, 이전 상태로 애플리케이션을 복원합니다. 롤백 작업은 기존 Pod의 종료와 새로운 Pod의 생성을 수행하여 이루어집니다. 롤백은 Kubernetes의 배포(Deployment) 리소스가 제공하는 롤링 업데이트 전략에 의해 지원됩니다. 롤링 업데이트는 기본적으로 새로운 버전의 Pod를 점진적으로 배포하고 이전 버전의 Pod를 제거하여 서비스 중단을 최소화합니다.
롤링 업데이트가 제대로 구성되어 있다면, 롤백 작업은 이전 버전의 Pod를 다시 활성화함으로써 배포를 롤백할 수 있습니다. 롤백은 안정성과 가용성을 유지하면서 애플리케이션 배포의 안전성을 향상시키는 중요한 기능입니다.
롤백을 하는게 undo와 같은 의미로 쓰인다.
예를들어 aws이미지를쓰다가 food로 넘어갔는데 다시 aws로 되돌아가고 싶을때사용함.
- Deployment 롤링 업데이트 제어
여태까지 있었던 rolling업데이트를 리스트로 보여줌
# kubectl rollout history deployment nginx-deployment
1번은 가장 초기, 4번이 가장 최근 업데이트 내용.
# kubectl set image deployment.apps/nginx-deployment nginx-deployment-container=halilinux/web-site:v1.0
# kubectl get all
# kubectl rollout history deployment nginx-deployment
# kubectl rollout history deployment nginx-deployment --revision=2 # 리비전2 상세보기
# kubectl rollout undo deployment nginx-deployment # 롤백(전 단계로 복원)
food > aws
# kubectl rollout history deployment nginx-deployment
# kubectl get all
# kubectl rollout undo deployment nginx-deployment --to-revision=1 # 리비전2로 복원
원하는 단계로 콕 찝어서 돌아가고 싶을때 사용함.
# kubectl rollout history deployment nginx-deployment
# kubectl rollout history deployment nginx-deployment --revision=6
가장 초창기로 돌아가고 싶어서 1번으로 돌아갔고, history 6번은 nginx가 됨. (맨 아래가 최근)
여기까지 미니 큐브 실습 끝!!
'Kubernetes' 카테고리의 다른 글
| 쿠버네티스 443 포트란? (0) | 2023.07.07 |
|---|---|
| [ minikube ] 환경 세팅하기_Minikube 설치 + kubectl 설치 (0) | 2023.07.07 |
| 쿠버네티스 오류 (The connection to the server ...was refused - did you specify the right host or port?) (0) | 2023.07.07 |
| 쿠버네티스 TIL / 따배쿠 5. Pod 강의 정리. (1) | 2023.06.10 |
