본문 바로가기
반응형

DevOps/Kubernetes23

[Kubernetes] : Configmap과 Secret 쿠버네티스 YAML 파일과 설정값을 분리할 수 있는 Configmap과 secret이라는 오브젝트가 있다. Configmap에서는 설정 값을 저장하고, Secret에서는 노출되면 안 되는 값을 저장한다. 이 두 개를 사용하면 애플리케이션과 설정값을 별도로 분리해 관리할 수 있는 장점이 생기게 된다. 📖 ← [ 시작하세요! 도커/쿠버네티스 ] 책을 참고하여 공부하였습니다. 2022. 3. 24.
[Kubernetes] : 네임스페이스에 종속되는 쿠버네티스 오브젝트와 독립적인 오브젝트 네임스페이스를 사용하면 쿠버네티스 리소스 사용 목적에 따라 논리적 격리가 가능하지만 모든 리소스가 네임스페이스에 의해 구분되진 않는다. A 네임스페이스에서 포드를 만들면 A 네임스페이스에만 보인다. 이것을 오브젝트가 네임스페이스에 속한다고 하는데 이 반대로 속하지 않는 오브젝트도 있다. Nodes가 그 중 하나이다. Nodes는 쿠버네티스 클러스터에서 사용되는 저수준의 오브젝트이며, 네임스페이스에 의해 구분되지 않는다. kubectl api-resoucres --namespaced=false 네임스페이스에 속하지 않는 오브젝트의 종류는 위 명령어로 확인이 가능하다. 확인해 보면 Nodes는 물론이고 네임스페이스 자체도 네임스페이스에 종속되지 않는다는 것을 확인할 수 있다. 📖 ← [ 시작하세요! 도커/쿠.. 2022. 3. 24.
[Kubernetes] : 네임스페이스의 서비스에 접근하기 쿠버네티스 클러스터 내부에서는 같은 네임스페이스 내의 서비스에 접근할 때에는 서비스 이름으로만으로 접근할 수 있다. 다른 네임스페이스에 존재하는 서비스에는 서비스 이름만으로는 접근이 불가능하다. 다른 네임스페이스에 존재하는 서비스에 접근하는 방법은 다음과 같다. ..svc처럼 서비스 이름 뒤에 네임스페이스 이름을 붙이면 다른 네임스페이스의 서비스에도 접근이 가능하다. kubetcl delete namespace 이름 kubectl delete -f YAML파일명 두 명령어로 네임스페이스를 삭제할 수 있다. 네임스페이스를 삭제하면 모든 리소스도 같이 삭제된다. 📖 ← [ 시작하세요! 도커/쿠버네티스 ] 책을 참고하여 공부하였습니다. 2022. 3. 24.
[Kubernetes] : 네임스페이스 사용하기 네임스페이스는 YAML 파일에 정의해 사용이 가능하다. apiCersion: v1 kind: Namespace metadata: name: production YAML 파일을 적어준다. kubectl apply -f production-namespace.yaml kubectl create namespace production 둘 중 하나의 명령어로 생성이 가능하다. kubectl get ns | grep production production이라는 네임스페이스가 정상 생성이 되었는지 체크한다. kubectl get pods --all-namespaces 모든 네임스페이스의 리소스를 확인할 수 있다. 📖 ← [ 시작하세요! 도커/쿠버네티스 ] 책을 참고하여 공부하였습니다. 2022. 3. 24.
[Kubernetes] : 네임스페이스 기본 이해 네임스페이스를 간단하게 사용해 본다. 네임스페이스는 쿠버네티스에서 namespace 또는 ns라는 이름으로 사용할 수 있고 kubectl get namespaces 명령어로 확인이 가능하다. kubectl get namespaces kubectl get ns 둘 중 아무거나 사용해도 상관없다. 기본적으로 네임스페이스는 생성하지 않아도 3개가 존재한다. 각 논리적인 리소스 공간이라서 각 네임스페이스에는 포드, 레플리카셋, 서비스 같은 리소스가 따로 존재한다. kubectl get pods --namespace default default라는 이름의 네임스페이스에 생성된 포드를 확인해 본다. 이 default 네임스페이스는 쿠버네티스를 설치하면 자동으로 사용되도록 설정되어 있는 네임스페이스이다. —names.. 2022. 3. 23.
[Kubernetes] : 네임스페이스(Namespace) 언급. 도커, 도커 스웜 모드는 컨테이너를 논리적으로 구분하는 방법이 없었다. 용도에 따라 컨테이너와 그에 관련된 리소스를 구분해 관리할 수 있는 논리적 그룹이 있으면 좀 더 편할 것이다. 쿠버네티스에서 이런 일을 네임스페이스(Namespace)가 해준다. 네임스페이스는 포드, 레플리카셋, 디플로이먼트, 서비스와 같은 쿠버네티스 리소스들이 묶여 있는 하나의 가상 공간이나 그룹으로 이해하면 된다. 여러 개의 네임스페이스를 사용하면 마치 하나의 클러스터에서 여러 개의 가상 클러스터들을 동시에 사용하는 것 처럼 느낄 수 있다. 📖 ← [ 시작하세요! 도커/쿠버네티스 ] 책을 참고하여 공부하였습니다. 2022. 3. 23.
[Kubernetes] : 온프레미스 환경에서 LoadBalancer 타입의 서비스 사용 LoadBalancer 타입의 서비스는 클라우드 플랫폼에서 사용되지만 필요에 따라 직접 보유하고 있는 온프레미스 서버에서도 LoadBalancer 타입을 사용할 수 있다. 쿠버네티스가 직접 제공하는 기능은 아니고 MetaILB라는 오픈소스 프로젝트를 사용하면 된다. 단, 유지보수가 지속적이지 않을 수 있으므로 유의해야 하고 공식 문서를 참고하면 된다. 📖 ← [ 시작하세요! 도커/쿠버네티스 ] 책을 참고하여 공부하였습니다. 2022. 3. 22.
[Kubernetes] : Service 종류 포드에 접근할 수 있는 규칙을 정의하는 서비스 리소스를 생성해야 하는데 어떻게 접근할 것인지에 따라 종류가 여러 개로 세분화 된다. 자주 사용되는 서비스 타입은 아래와 같다. ClusterIP 타입 쿠버네티스 내부에서만 포드에 접근할 때 사용한다. 외부에 노출하지 않아 클러스터 내부에서 사용되는 포드에 적합하다. NodePort 타입 포드에 접근할 수 있는 포트를 클러스터의 모든 노드에 동일하게 개방해 외부에서 포드에 접근할 수 있다. 접근 가능한 포트는 랜덤이고 특정 포트로 접근하게 설정도 할 수 있다. LoadBalancer 타입 클라우드 플랫폼에서 제공하는 로드 밸런서를 동적으로 프로비저닝해 포드에 연결한다. 외부에서 포드에 접근할 수 있지만 AWS, GCP 등 클라우드 플랫폼에서만 사용이 가능하다.. 2022. 3. 21.
[Kubernetes] : Service : 포드를 연결하고 외부에 노출하기 디플로이먼트를 통해 생성된 포드에 접근하기 위해 kubectl describe 명령어로 포드의 내부 IP를 직접 확인해 포드로 직접 접근을 할 수 있었지만 문제가 있다. 먼저, 로컬 개발 환경이나 쿠버네티스 클러스터 내부에서만 사용할 수 있다는 점하고 영속적이지 않아 항상 변할 수 있따는 점이다. 때문에 여러 개의 디플로이먼트를 하나의 애플리케이션으로 연동하기 위해 서로를 발견(Discovery)할 수 있는 방법이 필요하다. YAML 팡리 중 containerPort 항목이 포드 애플리케이션이 사용할 내부 포트를 정의하는데 이 항목을 정의했다고 해서 포드가 외부로 노출되는 것은 아니다. 노출되기 위해서는 Service 오브젝트를 생성해야 한다. 이 Service 오브젝트는 여러 기능이 있지만 핵심 기능은.. 2022. 3. 21.
[Kubernetes] : 디플로이먼트를 사용하는 간단한 이유 디플로이먼트를 사용하는 이유는 애플리케이션의 업데이트와 배포를 편리하게 하기 위함이다. 디플로이먼트는 컨테이너 애플리케이션을 배포하고 관리하는 역할을 담당한다. 쿠버네티스에서도 공식적으로 디플로이먼트를 사용할 것을 권장하고 있다. 📖 ← [ 시작하세요! 도커/쿠버네티스 ] 책을 참고하여 공부하였습니다. 2022. 3. 21.
[Kubernetes] : 디플로이먼트 사용하기 레플리카셋으로 마이크로서비스 구조의 컨테이너를 구성할 수 있을 것 같지만 실제 쿠버네티스 운영 환경에서 레플리카셋을 YAML 파일에서 사용하는 경우는 거의 없다. Deployment라는 오브젝트를 YAML 파일에 정의해서 사용한다. 이 디플로이먼트 오브젝트는 레플리카셋의 상위 오브젝트여서 생성 시 이에 대응하는 레플리카셋도 생성된다. kubectl get deploy 생성된 디플로이먼트의 목록을 확인한다. kubectl get replicasets kubectl get pods 포드 개수를 유지시켜주는 것은 레플리카셋이다. 디플로이먼트와 같이 레플리카셋이 생성된 것임을 알 수 있다. kubectl delete deploy my-nginx-deployment 디플로이먼트를 삭제하면 레플리카셋과 포드도 삭제.. 2022. 3. 21.
[Kubernetes] : 레플리케이션 컨트롤러 vs 레플리카셋 이전 쿠버네티스에서는 레플리카셋이 아니라 레플리케이션 컨트롤러(Replication Controller)라는 오브젝트를 통해 포드의 개수를 유지했다. 하지만 지금은 레플리카셋을 사용한다. 이 두 오브젝트의 차이는 표현식 기반의 라벨 셀럭터를 사용할 수 있다는 것이다. 예를 들면 아래와 같다. selector: matchExpressions: - key: app values: - my-nginx-pods-label - your-nginx-pods-label operator: In template: ... key가 app인 라벨을 가지고 있는 포드들 중 values 항목에 정의돈 값들이 존재(In)하는 포드들을 대상으로 한다는 의미이다. app: my-nginx-pods-label 라벨을 가지는 포드뿐만 아.. 2022. 3. 19.
[Kubernetes] : 레플리카셋의 동작 원리 레플리카셋의 동작 원리 레플리카셋을 생성,삭제하면 포드도 생성,삭제가 되니 연결된 것 처럼 보이지만 실제로는 연결되어 있지 않고 느슨한 연결을 유지하고 있다. 이런 느슨한 연결은 Label Selector를 통해 이루어진다. 라벨은 포드 등 쿠버네티스 리소스를 분류할 때 유용하게 사용할 수 있는 메타데이터이다. 라벨은 쿠버네티스 리소스의 부가적인 정보를 현할 수 있고 서로 다른 오브젝트가 서로를 찾아야 할 때 사용되기도 한다. 레플리카셋은 정의된 라벨을 통해 생성해야 하는 포드를 찾는다. 예를 들어 A라벨을 가지는 포드의 개수가 replicas항목에 3개로 정의되어 있는데 개수가 일치하지 않다면 포드를 정의하는 포드 템플릿 항목의 내용으로 포드를 생성한다. kubectl apply -f nginx-pod.. 2022. 3. 19.
[Kubernetes] : 레플리카셋 사용 Nginx 포드를 생성하는 레플리카셋을 만들어본다. apiVersion: apps/v1 kind: ReplicaSet metadata: name: replicaset-nginx spec: replicas: 3 selector: matchLabels: app: my-nginx-pods-label template: metadata: name: my-nginx-pod labels: app: my-nginx-pods-label spec: containers: - name: nginx image: nginx:latest ports: - containerPort: 80 replicaset-nginx.yaml 파일을 작성한다. 리소스의 고유한 이름은 쿠버네티스 오브젝트에서도 설정이 가능하다. kubectl apply.. 2022. 3. 18.
[Kubernetes] : Replica Set, 레플리카 셋을 사용하는 이유 포드는 여러 컨테이너를 추상화해 하나의 애플리케이션으로 동작하게 하는 컨테이너 묶음이다. YAML에 포드만 정의해 생성하면 이 포드의 Lifecycle은 어떻게 될까? kubectl delete -f nginx-pod-ubuntu.yaml kubectl get pods kubectl delete pods my-nginx-pod 포드를 삭제하면 그 포드의 컨테이너도 삭제되어 쿠버네티스에서 영원히 사라지게 된다. 이렇게 YAML에 정의해 생성하면 오직 쿠버네티스 사용자에 의해 관리된다. 하지만 외부 사용자의 요청을 처리해야 하는 마이크로 서비스 구조의 포드면 이런 방식을 사용하기 어렵다. 이렇게 YAML 파일에 정의해 사용하는 것은 여러 문제와 한계가 있고 이런 점을 해결해 사용하기 위해 replica se.. 2022. 3. 17.
[Kubernetes] : 완전한 애플리케이션으로서의 pod 완전한 애플리케이션으로서의 포드 K8s는 1개의 컨테이너로 구성된 포드를 사용하는 경우가 많다. 그렇다면 왜 하나의 포드에 여러 개의 컨테이너가 포함되어야 하는지 의문점이 생기게 된다. 여기서 유의점은 하나의 포드는 하나의 완전한 애플리케이션이라는 점이다. Nginx 컨테이너는 그 자체로 완전한 애플리케이션이다. 떄문에 하나의 포드에 2개의 Nginx 컨테이너가 정의되는 것은 옳지 못 하다. 하지만 Nginx 컨테이너가 실행되기 위해 부가적인 기능이 필요하다면 추가 컨테이너를 포드에 포함시킬 수 있다. 이렇게 포드에 정의된 부가적인 컨테이너를 Sidecar(사이드카) 컨테이너라고 한다. 사이드카 컨테이너는 포드 내 다른 컨테이너와 네트워크 환경을 공유한다. 포드에 포함된 컨테이너들은 모두 같은 워커 노드.. 2022. 3. 17.
[Kubernetes] : 포드 vs 도커 컨테이너 단일 컨테이너와 크게 다르지 않은 것 같지만 왜 포드를 사용할까? 쿠버네티스가 포드를 사용하는 이유는 여러 리눅스 네임스페이스를 공유하는 여러 컨테이너들을 추상화된 집합으로 사용하기 위해서이다. kubectl get pods 명령어를 출력했을 때 READY 항목에 1/1이 출력되었을텐데 Nginx 포드에 1개의 컨테이너가 정의되어 있고 준비되었다. 라는 뜻이다. 이처럼 보통 1개의 컨테이너로 포드를 구성해 사용하지만 꼭 1개로 구성해야 하는 것은 아니다. 네트워크 네임스페이스는 컨테이너의 고유한 네트워크 환경을 제공해 주는 역할을 담당한다. 다른 컨테이너를 추가해 2/2로 만든 뒤 하나의 컨테이너의 접속해서 HTTP 요청을 전송하면 다른 서버에서 응답이 도착하는 것을 확인할 수 있다. 📖 ← [ 시작하세.. 2022. 3. 16.
[Kubernetes] : 포드, Pod 사용하기 포드, Pod 사용하기 애플리케이션을 구동하기 위해 필수적으로 알아야 하는 몇 가지 오브젝트가 있는데 그것이 바로 포드, 레플리카셋, 서비스, 디플로이먼트이다. 쿠버네티스에서 컨테이너 애플리케이션의 기본 단위를 포드라고 한다. 포드는 1개 이상의 컨테이너로 구성된 컨테이너의 집합이다. 도커 엔진에서 기본 단위가 도커 컨테이너, 스웜 모드에서 기본 단위는 서비스인 것 처럼 쿠버네티스는 기본 단위로 포드를 사용한다. 1개의 포드엔 1개의 컨테이너가 존재 할 수도 있고 여러 개의 컨테이너가 존재 할 수도 있다. apiVersion: v1 kind: Pod metadata: name: my-nginx-pod spec: containers: - name: my-nginx:latest ports: - contain.. 2022. 3. 16.
[Kubernetes] : 쿠버네티스에 대한 간단한 설명 모든 리소스는 오브젝트 형태로 관리된다. 쿠버네티스는 리소스를 오브젝트라고 불리는 형태로 관리한다. 오브젝트는 간단히 추상화된 집합 정도로 생각하면 된다. 쿠버네티스의 오브젝트 개념은 생각보다 넓고 세밀한 단위로 사용한다. kubectl api-resources 쿠버네티스에서 사용할 수 있는 오브젝트 종류를 확인하는 명령어이다. 이 오브젝트들을 전부 다 다루지도 않고 전부 다 외울 필요도 없다. 또, 쿠버네티스 공식 문서에서 대부분의 리소스 오브젝트 사용법이 적혀있다. kubectl explatin pod 특정 오브젝트의 설명을 확인할 수 있는 명령어이다. pod 오브젝트를 확인해 본다. 쿠버네티스는 명령어보다 YAML 파일을 더 많이 사용한다. 쿠버네티스에서는 kubectl 명령어로 쿠버네티스를 사용할.. 2022. 3. 15.
[Kubernetes] : kops로 AWS에서 쿠버네티스 설치 kops는 클라우드 플랫폼에서 쉽게 쿠버네티스를 설치할 수 있게 도와주는 도구이다. kubeadm은 쿠버네티스를 설치할 서버 인프라를 직접 마련해야 하지만 kops는 서버 인스턴스와 네트워크 리소스 등을클라우드에서 자동으로 생성해 쿠버네티스를 설치한다. kops는 AWS, GCP 등 클라우드 플랫폼에서 설치를 지원하고 있다. wget -O kops chmod +x ./kops sudo mv ./kops /usr/local/bin/ wget -O kubectl \\ chmod +x kubectl sudo mv kubectl /usr/local/bin/ kopos 및 kubectl 실행 바이너르를 내려받는다. AWS 사용자를 생성하고 정책 연결 및 AWS CLI를 설정한다. 번거로워서 책에서는 따로 🔗링크를.. 2022. 3. 14.
[Kubernetes] : 리눅스 서버에서 도커 엔진만으로 minikube 설치하기 리눅스 서버에서 가상 머신 없이 도커 엔진만으로 minikube 설치 curl -Lo minikube \\ && \\ chmod +x minikube && \\ sudo mv minikube /usr/local/bin/ curl -Lo kubectl \\ && \\ chmod +x kubectl && \\ sudo mv kubectl /usr/local/bin/ minikube와 kubectl을 내려받는다. minikube start --vm-driver=none kubectl version --short 설치를 확인한다. minikube delete Minikube를 삭제할 수 있다. 📖 ← [ 시작하세요! 도커/쿠버네티스 ] 책을 참고하여 공부하였습니다. 2022. 3. 13.
반응형

티스토리툴바