쿠버네티스(Kubernetes)는 컨테이너 오케스트레이션 도구의 일종이다.
💡컨테이너 오케스트레이션이란?
시스템 전체를 통괄하고 여러 개의 컨테이너를 관리하는 일을 말한다. 여러 개의 컨테이너를 지휘하는 도구가 쿠버네티스다.
쿠버네티스는 k8s라고 줄여쓰기도 하는데, k와 s 사이에 8개의 글자가 있다는 의미의 약칭이다.
쿠버네티스는 여러 개의 컨테이너를 관리하기 위한 도구라고 설명했는데, 여러 개의 컨테이너란 서버를 의미한다. 때문에 일반적인 프로그래머가 쿠버네티스를 사용할 일은 드물다.
때문에 쿠버네티스로 어떤 일을 할 수 있는가에 초점을 맞춰야 한다. 쿠버네티스로 관리되는 시스템은 이를 전제로 개발해야 하는데, 그렇지 않다면 쿠버네티스의 이점을 제대로 살릴 수 없다.
도커는 한 대의 물리적 서버에서 실행되는 경우가 많았지만 쿠버네티스는 여러 대의 물리적 서버가 존재하는 것을 전제로 한다.
도커 컴포즈를 사용한다고 해도 물리적 서버가 여러 대라면 반복 작업은 사라지지 않는데, 쿠버네티스는 번거로운 컨테이너 생성이나 관리의 수고를 덜어주는 도구다. 도커 컴포즈에서 사용되는 컴포즈 파일과 비슷한 정의 파일(매니페스트 파일)만 작성하면 이 정의에 따라 모든 물리적 서버에 컨테이너를 생성하고, 생성한 컨테이너를 관리해 준다.
https://kubernetes.io/ko/docs/concepts/overview/what-is-kubernetes/
쿠버네티스란 무엇인가?
쿠버네티스는 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식할 수 있고, 확장 가능한 오픈소스 플랫폼으로, 선언적 구성과 자동화를 모두 지원한다. 쿠버네티스는 크고 빠르게 성장하
kubernetes.io
🗒 마스터 노드와 워커 노드
쿠버네티스는 전체적인 제어를 담당하는 마스터 노드와 실제 동작을 담당하는 워커 노드 두 가지 유형의 노드로 구성된다.
노드란, 물리적 서버와 일치하는 개념이라고 보면 된다.
마스터 노드란, 감동과 같은 존재다. 마스터 노드에서 컨테이너를 실행하지는 않으며, 워커 노드에서 실행되는 컨테이너를 관리하는 역할을 한다. 때문에 도커 엔진같은 컨테이너 엔진도 설치되지 않는다.
워커 노드는 실제 서버에 해당하는 부분으로, 컨테이너가 실제 동작하는 서버다. 컨테이너 엔진이 설치돼야 한다.
이렇게 마스터 노드와 워커 노드로 구성된 일군의 쿠버네티스 시스템을 클러스터라고 한다. 클러스터는 사람이 개입하지 않아도 마스터 노드에 설정된 내용에 따라 워커 노드가 관리되며 자율적으로 동작한다.
💡쿠버네티스를 사용하려면?
쿠버네티스는 도커 엔진 등의 컨테이너 엔진과는 별개의 소프트웨어다. 때문에 쿠버네티스 소프트웨어와 CNI(가상 네트워크 드라이버)를 설치해야 한다.
마스터 노드를 설정하는 관리자의 컴퓨터에는 kubectl을 설치한다.
마스터 노드에는 컨테이너 등의 상태 관리를 위한 etcd(엣시디)라는 데이터베이스가 설치되는데, 이는 분산형 키-값 스토어 타입의 데이터베이스다. 도커 컴포즈와 가장 큰 차이점은 쿠버네티스의 정의 파일(매니페스트 파일)이 데이터베이스로 관리된다는 점인데, 이 정의 파일을 읽어들이면 그 내용은 etcd에 저장된다. 마스터 노드는 또한 컨트롤 플레인을 통해 워커 노드를 관리한다. 다음의 다섯 가지의 컴포넌트로 구성되어있는데, etcd외에는 쿠버네티스에 포함돼 있다.
- kube-apiserver : 외부와 통신하는 프로세스로, kubectl로부터 명령을 전달받아 실행
- kube-controller-manager : 컨트롤러를 통합 관리, 실행
- kube-scheduler : 파드를 워커 노드에 할당
- cloud-controller-manager : 클라우드 서비스와 연동해 서비스를 생성
- etcd - 클러스터 관련 정보 전반을 관리하는 데이터베이스
워커 노드에는 컨테이너 엔진이 필요하다. 또한 워커 노드에서는 다음의 두 가지가 실행되는데, 이들 역시 쿠버네티스에 기본적으로 포함이 되어있다.
- kube-let : 마스터 노드의 kube-scheduler와 연동해 워커 노드에 컨테이너 또는 볼륨을 배치하고 실행
- kube-proxy - 네트워크 통신의 라우팅 메커니즘
쿠버네티스는 항상 바람직한 상태를 유지한다. 바람직한 상태란, '컨테이너는 OO개, 볼륨은 XX개로 구성한다'와 같은 상태를 YAML 파일에 정의하고, 이 상태를 유지하는 것이 쿠버네티스의 기본적인 아이디어다.
때문에 정의에서 '컨테이너를 4개'인 것을 '컨테이너 3개'로 수정하면 알아서 컨테이너를 한 개 삭제한다. 만약 컨테이너가 하나 망가지는 현상이 발생하면, 해당 컨테이너를 자동 삭제하고 새 컨테이너로 대체한다.
만약 컨테이너를 삭제하고 싶다면, 사람이 개입해서 컨테이너를 삭제하지 말고, 바람직한 정의를 수정하는 것이 맞다. 때문에 만약 컨테이너를 모두 삭제하고 싶다면 '필요한 컨테이너 수는 0'이라고 지정하면 된다.
⚙️쿠버네티스의 구성과 관련 용어
✔️ 파드(Pod)
쿠버네티스에서 컨테이너는 파드(Pod)라는 단위로 관리한다. 이는 쿠버네티스에서 생성하고 관리할 수 있는 배포 가능한 가장 작은 컴퓨팅 단위다.
파드(고래 떼(pod of whales)나 콩꼬투리(pea pod)와 마찬가지)로 하나 이상의 컨테이너 그룹이다. 파드는 컨테이너와 볼륨을 함께 묶은 것으로 기본적으로 파드 하나가 컨테이너 하나이지만, 컨테이너가 여러 개인 파드도 있을 수 있다.
즉 파드는 컨테이너가 모인 집합체로 기본적인 배포 단위다. 쿠버네티스는 하나의 컨테이너를 개별적으로 배포하지 않고 pod 단위로 배포한다. 하지만 위 그림과 같이 같은 pod를 한 node안에 여러 개, 여러 노드에 배치가 가능하지만 한 노드에는 두 개 이상의 파드가 배치될 수 없다.
파드는 기본적으로 파드에 속한 컨테이너에 네트워킹과 스토리지라는 두 가지 종류의 공유 리소스를 제공한다.
또한 파드 내의 컨테이너는 IP, Port를 공유하여 localhost를 통해 통신이 가능하다.
✔️ 서비스(Service)
파드를 모은 것이 서비스로, 여러 개의 파드를 이끄는 것이라고 생각하면 된다. 서비스가 관리하는 파드는 모두 기본적으로 동일한 구성을 가지며, 구성이 다른 파드는 별도의 서비스로 관리한다. 서비스는 여러 개의 파드를 이끄는 것이므로 여러 개의 워커 노드(물리적 서버)에 걸쳐 동작하더라도 이들을 모두 관리한다.
서비스의 역할은 여러 개의 파드를 이끄는 것 뿐만 아니라 로드 밸런서 역할도 하는데, 로드 밸런서는 부하 분산장치다. 한 대의 서버에 모든 요청이 집중되지 않도록 여러 대의 서버를 갖추고 요청을 각 서버에 분산하는 것을 말한다. 쉽게 말해서 요청을 여러 대의 서버에 나눠주는 것이다. 각 서비스는 자동적으로 고정된 IP 주소인 cluster IP를 부여받으며, 서비스에 여러 개의 파드가 있어도 밖에서는 하나의 IP 주소만 보이며, 이 주소로 접근하면 서비스가 통신을 적절히 분배해준다.
하지만 서비스가 분배하는 통신은 한 워커 노드 안으로 국한되는데, 여러 워커 노드 간의 분배는 서비스가 아닌 실제 로드 밸런서 또는 인그레스(ingress)가 담당한다. 이들은 마스터, 워커 노드가 아닌 별도의 노드에서 동작하거나 물리적 전용 하드웨어다.
✔️ 디플로이먼트와 레플리카세트
레플리카세트(ReplicaSet)는 파드의 수를 관리하는 것이다. 파드는 서비스와 레플리카세트에게 관리된다.
레플리카세트가 관리하는 동일한 구성의 파드를 레플리카(replica)라고 하는데, 이는 복제품이라는 단어다. 파드의 수를 조정 및 결정하는 것을 레플리카의 수를 조정 및 결정하는 것이라고 표현한다.
레플리카세트의 목적은 레플리카 파드의 집합 실행을 항상 안정적으로 유지하는 것이다.
레플리카세트는 다루기가 어려워 단독으로 쓰이는 경우가 드물다. 때문에 레플리카세트는 디플로이먼트(deployment)와 함께 쓰일 때가 많다. 이는 파드의 디플로이(배포)를 관리하는 요소로, 파드가 사용하는 이미지 등 파드에 대한 정보를 갖고 있다.
때문에 실제 운영에서는 레플리카 세트를 직접 다루기보다는 디플로이먼트 매니페스트 파일을 통해 운영한다.
지금까지 알아본 파드, 서비스, 디플로이먼트, 레플리카세트 등을 리소스(resource)라고 하는데, 리소스는 모두 합해 50여 종류가 있다.
💡쿠버네티스 설치 및 사용하기
쿠버네티스엔 여러 종류가 있다. 일단 쿠버네티스는 클라우드 네이티브 컴퓨팅 재단(CNCF; Cloud Native Computing Foundation)이라는 단체에서 제정한 표준이다. 그 외 AWS, Azure, GCP같은 클라우드 서비스에서도 자사 서비스에 맞게 커스터마이징된 쿠버네티스를 제공한다. 쿠버네티스는 누구나 수정과 재배포를 할 수 있도록 허락해 자유롭게 사용 가능한 소프트웨어, 즉 오픈소스이고 서버에서 실행되므로 공식 소프트웨어 뿐만 아니라 서드파티 소프트웨어도 나온다는 점을 알아두자. 호환성이 검증된 소프트웨어나 서비스에는 'Certified Kubernetes' 인증을 부여해 공식 웹 사이트에서 소개한다.
https://www.cncf.io/certification/software-conformance/
Certified Kubernetes Software Conformance | Cloud Native Computing Foundation
Software conformance ensures that every vendor’s version of Kubernetes supports the required APIs, as do open source community versions. For organizations using Kubernetes…
www.cncf.io
원조 쿠버네티스를 채택하는 것 자체는 흔하지만, 직접 구축해 사용하는 것은 왠만한 규모의 기업에서도 드물다. 서비스마다 부여되는 클러스터 IP에 로드 밸런싱을 적용하기 위해 이를 지원하는 하드웨어를 갖추거나, 하드웨어 선정부터는 인프라 전문업체에게 맡겨야 하기 때문이다. 향후 있을 유지보수도 쉬운 일이 아니기 때문에, 원조 쿠버네티스는 많이 쓰이지만 직접 구축하기 까다로우며 때문에 초보자가 배우기에도 부적합하다.
일반적으로는 AWS같은 클라우드 컴퓨팅 서비스를 사용해 구축하는 경우가 많은데, 클라우드에서는 앞서 언급한 문제가 이미 해결돼 있으므로 전문적인 지식 없어도 사용 가능하다.
하지만 이럴 필요 없이 도커 데스크톱에는 쿠버네티스가 포함되어 있다. 도커 설정 화면에서 [Kubernetes]에 체크하면 바로 사용할 수 있고, etcd와 CNI 설치도 필요 없다. 참고로 리눅스에서는 Minikube라는 간단히 사용할 수 있는 쿠버네티스가 있다.
오른쪽 상단의 톱니바퀴 모양을 클릭해 설정에 들어가 도커 설정 화면을 연다. [Kubernetes] 탭에서 [Enable Kubernetes] 항목을 체크한다.
다음과 같이 뜬다면 성공이다.
🗒 매니페스트 파일
쿠버네티스는 매니페스트 파일(정의 파일)에 기재된 내용에 따라 파드를 생성한다고 앞서 설명했다. 매니페스트(manifest)란 파드나 서비스에 대한 설정을 말하며, 이를 적은 파일을 매니페스트 파일(정의 파일)이라 한다. YAML이나 JSON 형식으로 기재한다. 이 때, 파일의 이름은 다른 사람도 이해할 수 있는 이름으로 짓자.
매니페스트 파일의 내용을 쿠버네티스에 업로드하면 그 내용이 etcd 데이터베이스에 '바람직한 상태'로 등록되며, 서버 환경을 이 바람직한 상태로 유지한다.
실습에서는 서비스와 디플로이먼트 리소스를 다룰텐데, 파드는 사용하지만 항목은 작성하지 않는다. 개수를 유지하는 기능은 디플로이먼트나 레플리카세트에서 담당하므로 파드가 아닌 디플로이먼트를 만들어야 하는데, 레플리카세트 역시 디플로이먼트에 의해 개수가 관리되므로 항목으로 작성하지 않는다. 디플로이먼트 항목에 레플리카세트와 파드가 포함되어있기 때문이다.
매니페스트 파일은 리소스 단위로 분할해 작성하거나 한 파일에 합쳐 사용한다. 한 파일로 작성 시, 각 리소스를 '---'로 구분하고, 리소스 단위로 파일을 나눌 때는 각 리소스를 구별할 수 있도록 이름을 붙인다.
매니페스트 파일에도 컴포즈 파일과 마찬가지로 주 항목이 있다.
apiVersion: # API 그룹 및 버전
kind: # 리소스 유형
metadata: # 메타데이터
spec: # 리소스 내용메타데이터에는 리소스의 이름이나 레이블을 기재한다.
파드나 서비스 같은 리소스에는 원하는 레이블을 붙일 수 있는데, 레이블은 키-값 쌍의 형태로 메타데이터로 설정한다. 레이블을 부여하면 셀렉터 기능을 사용할 수 있고, 이는 특정 레이블이 부여된 파드만을 배포하는 등 특정 파드를 선택해 설정할 수 있다.
파드, 디플로이먼트, 서비스를 대상으로 메타데이터를 작성하고 싶다면 다음과 같이 작성한다.
파드는 단독으로 매니페스트 파일이 기재되는 경우가 드물며, 대부분 디플로이먼트에 포함되는 형태로 기재된다.
metadata:
name: # 파드의 이름
labels: # 레이블
spec:
containers:
- name:
image:
ports:
위의 형식에 맞게 apa000pod.yml을 작성한다.
apiVersion: v1
kind: Pod
metadata:
name: apa000pod
labels:
app: apa000kube
spec:
containers:
- name: apa000ex91
image: httpd
ports:
- containerPort: 80필요한 주항목(apiVersion, kind, metadata, spec)을 기재한다. apiVersion의 설정값은 'v1', kind의 설정값은 'Pod'이다.
파드의 이름은 apa000pod이며, 레이블은 app: apa000kube이다.
다음 컨테이너의 정보를 spec 항목 밑에 설정한다. 컨테이너의 이름은 apa000ex91, 이미지는 httpd, 포트 설정은 containerPort: 80 이다.
디플로이먼트 매니페스트 파일 기재 방식은 다음과 같다.
apiVersion:
kind:
metadata:
name: # 디플로이먼트 이름
spec:
selector: # 셀렉터 설정
matchLabels: # 셀렉터가 선택할 관리 대상 레이블
replicas: # 레플리카 설정
template: # 템플릿(파드 정보)
metadata: # vkemdml apxkepdlxj rlwo
spec: # 파드의 스펙 기재이 때, replicas를 0으로 설정하면 파드가 사라진다. 즉, 파드 수를 몇 개로 유지할 것인지 설정하는 것이다.
템플릿에는 파드의 정보를 기재하는데, 기재 내용은 파드에 기재된 내용인 메타데이터 및 스펙과 거의 같다. 이 때 파드에서 지정했던 파드 이름은 설정하지 않는데, 파드의 수가 늘어나면 레이블로 관리하는 경우가 많기 때문이다.
apa000dep.yml 파일을 다음과 같이 작성한다.
apiVersion: apps/v1
kind: Deployment
metadata:
name: apa000dep
spec:
selector:
matchLabels:
app: apa000kube
replicas: 3
template:
metadata:
labels:
app: apa000kube
spec:
containers:
- name: apa000ex91
image: httpd
ports:
- containerPort: 80생성 후엔 pod 매니페스트 파일을 삭제한다.
디플로이먼트와 서비스는 거의 세트로 봐도 무방한데, 디플로이먼트의 매니페스트 파일 작성이 끝났으면 서비스의 매니페스트 파일을 작성한다.
설정 내용은 다음과 같다.
apiVersion:
kind:
metadata:
name: # 서비스의 이름
spec:
type: # 서비스의 유형
ports: # 포트 설정
- port: # 서비스의 포트
targetPort: # 컨테이너의 포트
protocol: # 통신에 사용되는 프로토콜
nodePort: # 워커 노드의 포트
selector: # 셀렉터 설정유형은 서비스의 종류를 말한다. 즉 외부로부터 서비스에 어떤 유형의 IP 주소(또는 DNS)로 접근할지를 설정한다.
- ClusterIP - 클러스터 IP를 통해 서비스에 접근하도록 함. 외부에서는 접근 불가하다.
- NodePort - 워커 노드의 IP를 통해 서비스에 접근하도록 함
- LoadBalancer - 로드밸런서의 IP를 통해 서비스에 접근하도록 함
- ExternalName - 파드에서 서비스를 통해 외부로 나가기 위한 설정
클러스터IP는 사설 IP 주소가 설정돼 있어서 클러스터 내부의 통신에만 사용가능하다.
실무에서는 LoadBalancer로 설정하는 경우가 대부분인데, 이는 사용자를 웹 사이트에 접근시키기 위해서다.
유형 이름이 NodePort라면 워커 노드에 직접 접근할 수 있다. 워커 노드가 직접 무언가를 처리하는 구성을 취했거나 개발 목적 등 특정 워커 노드에 접근해야 하는 특수한 경우에 사용한다. 로드밸런서가 없는 경우에는 NodePort를 사용한다. 도한 이 경우 클러스터 외부에서 접속할 수 있는 서비스를 제공한다. ClusterIP를 만들지만 각 노드에서 서비스 포트로 접속하기 위한 글로벌 포트를 개방하는 것이다.
내부에서 외부로 접근해야 할 경우에는 ExternalName으로 한다. 외부 서비스를 쿠버네티스 내부에서 호출하고자 할 때 사용할 수 있다. (RDS, CloudSQL 등 사용 시 이용)
포트 설정은 다음과 같다.
- port - 서비스의 포트
- nodePort - 워커 노드의 포트
- targetPort - 컨테이너포트
nodePort dpsms 30000~32767 사이의 값을 설정할 수 있다.
protocol(프로토콜)은 통신 프로토콜을 말하는데, 일반적으로 TCP를 사용하므로 TCP로 설정한다.
셀렉터는 서비스가 특정 레이블이 부여된 파드를 선택적으로 관리하기 위한 설정이다. 레이블은 파드나 디플로이먼트에서 컨테이너 부분의 설정에 지정된 레이블을 사용한다.
다만 디플로이먼트에서는 'matchLabels:'가 필수 항목인 데 비해 서비스에서는 'matchLabels:'를 사용해서는 안된다. 설정 이름은 똑같이 셀렉터지만 암묵적으로 내부 동작이 다르기 때문이다. 디플로이먼트는 셀렉터를 설정하면 레이블셀렉터를 사용하며, 이 조건에 부합할 때와 같은 설정이 가능하지만, 서비스는 리소스를 직접 지정하기 때문에 해당 레이블을 그대로 기재해야 한다.
서비스 매니페스트 파일은 파드에 대한 접근을 관리하므로, 포트 등 통신과 관련된 내용을 기재한다.
apa000ser.yml 파일을 다음과 같이 작성한다.
apiVersion: v1
kind: Service
metadata:
name: apa000ser
spec:
type: NodePort
ports:
- port: 8099
targetPort: 80
protocol: TCP
nodePort: 30080
selector:
app: apa000kube💡쿠버네티스 명령어
쿠버네티스를 조작할 때는 kubectl 명령어를 사용한다. 명령어의 형식은 다음과 같다.
kubectl command option도커 명령어로 도커 엔진에 명령을 내리듯 kubectl 명령어로 쿠버네티스에 명령을 내리는 것으로, 커맨드와 그 기능이 모두 비슷하다. 하지만 명령을 하나하나 실행하며 컨테이너를 생성하는 도커와 달리, 쿠버네티스는 매니페스트 파일의 내용을 따라 한 번에 모든 리소스를 생성한다.
apply 커맨드로 매니페스트 파일을 읽어 그 내용을 실제 리소스에 반영해 파드의 생성 여부를 확인하자. 다음과 같이 입력한다.
kubectl apply -f /Users/{username}/Documents/kube_folder/apa000dep.yml
다음은 파드의 목록을 화면에 출력해서 파드가 잘 생성되었는지 확인한다. 목록에 세 개의 파드가 출력되면 잘 된 것이다. (replicas: 3)
kubectl get pods
파드가 잘 생성됐는지 확인 후 서비스 매니페스트 파일로 서비스를 생성한다. 서비스는 웹 브라우저에 접근할 수 있다.
- apply -f : 리소스의 변경 사항을 반영
- get : 리소스의 상태를 화면에 출력
kubectl apply -f /Users/{username}/Documents/kube_folder/apa000ser.yml
다음 서비스가 잘 생성되었는지 확인한다.
kubectl get services
Kubernetes 외에 apa000ser이 잘 생성되었음을 볼 수 있다.
잘 생성되었음을 확인할 수 있다. 서비스 매니페스트를 생성 시 기입했던 ports의 nodePort 30080으로 잘 접속됨을 볼 수 있다.
다음은 바람직한 상태를 정의하는 매니페스트 파일을 변경해서 파드가 어떻게 변화하는지 확인해보자. 디플로이먼트 매니페스트 파일을 수정한다.
apiVersion: apps/v1
kind: Deployment
metadata:
name: apa000dep
spec:
selector:
matchLabels:
app: apa000kube
replicas: 5
template:
metadata:
labels:
app: apa000kube
spec:
containers:
- name: apa000ex91
image: httpd
ports:
- containerPort: 80레플리카의 수를 3에서 5로 변경한다. 다음 수정한 매니페스트 파일을 리소스에 반영한다.
kubectl apply -f /Users/{username}/Documents/kube_folder/apa000dep.yml
다음 새로운 파드가 생성되었는지 확인한다.
kubectl get pods
5개로 잘 늘어나있음을 볼 수 있다.
파드의 수 말고도 컨테이너의 종류를 바꿀 수 있는데, 만약 아파치가 아닌 nginx 컨테이너로 바꾸고 싶다면 디플로이먼트 매니페스트 파일에서 이미지 이름을 httpd에서 nginx로 수정하면 된다.
apiVersion: apps/v1
kind: Deployment
metadata:
name: apa000dep
spec:
selector:
matchLabels:
app: apa000kube
replicas: 5
template:
metadata:
labels:
app: apa000kube
spec:
containers:
- name: apa000ex91
image: nginx
ports:
- containerPort: 80
다음은 수동으로 파드를 삭제한 후 자동복구되는지 확인해보자. 이는 쿠버네티스의 바람직한 상태를 유지하는 것을 확인하고자 함이다.
파드의 목록을 확인한 다음, 맨 위의 파드의 ID를 사용해 삭제했다.
재확인을 해보니 삭제했던 ID의 파드는 사라지고 다른 ID의 파드가 보충되어있음을 볼 수 있다. 쿠버네티스에서 관리의 기본 단위는 파드이므로, 파드에 포함된 컨테이너가 어떤 이유로든 망가지거나 삭제된다면 해당 컨테이너뿐만 아니라 파드 전체가 새로 만들어진다.
마지막으로 생성했던 디플로이먼트와 서비스를 삭제해보자. 파드는 레플리카 수를 0으로 수정하면 모두 삭제된다. 하지만 이 때는 디플로이먼트와 서비스가 남아있게 된다.
다음의 명령어로 디플로이먼트를 삭제하자.
kubectl delete -f /Users/{username}/Documents/kube_folder/apa000dep.yml
디플로이먼트의 목록을 다음과 같이 확인한다.
kubectl get deployment
다음은 서비스를 삭제한다.
kubectl delete -f /Users/{username}/Documents/kube_folder/apa000ser.yml
서비스의 목록을 확인해 서비스가 잘 삭제되었는지 확인한다.
kubectl get services
이 내용은 다음의 책 8장을 읽고 정리한 내용이다. 더 자세한 내용을 원한다면 책을 참고하길 바란다.
http://www.yes24.com/Product/Goods/108431011
그림과 실습으로 배우는 도커 & 쿠버네티스 - YES24
컨테이너나 도커를 도통 이해하기 어려운 분들을 위한 본격 도커 입문서!이 책은 컨테이너 기술이 어렵게 느껴지는 엔지니어나 백엔드 기술에 자신이 없는 분들을 위한 도커 입문서다. 자세한
www.yes24.com
'개발 관련 > Docker' 카테고리의 다른 글
| 2장. 테스트 환경 구축하기 (0) | 2022.07.30 |
|---|---|
| 1장. 컨테이너 인프라 환경이란? (0) | 2022.07.28 |
| 도커 컴포즈 (0) | 2022.07.09 |
| 도커의 다양한 명령어들(복사, 볼륨 마운트 등) (0) | 2022.07.02 |
| 여러 개의 컨테이너를 연동해 실행하기 (0) | 2022.06.25 |
