본문 바로가기

도커69

[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] : 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] : 레플리카셋 사용 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.

[TIL] : 140 일일 배움을 위한 Today I Learned ! Spring Boot 스프링 부트 강의를 진도나갔고, 학교에서 배운 내용도 간단하게 정리해 봤다. 2022.03.15 - [Framework/Spring Boot] - [Spring Boot] : ComversionServcie 사용해 보기 2022.03.15 - [Framework/Spring Boot] - [Spring Boot] : myBatis와 JPA 간단 정리 2022.03.15 - [Framework/Spring Boot] - [Spring Boot] : 스프링에 Converter 적용하기 2022.03.15 - [Framework/Spring Boot] - [Spring Boot] : 뷰 템플릿에 컨버터 적용하기 Kubernetes 쿠버네티.. 2022. 3. 15.

[TIL] : 139 일일 배움을 위한 Today I Learned ! R 데이터 프레임을 다루어보고 데이터 개념을 이해하기 위해 예제 파일을 통해 행, 열을 정리하고 그래프를 출력해 봤다. 2022.03.14 - [프로그래밍언어/R] - [R] : 데이터 프레임 다루기(2) 2022.03.14 - [프로그래밍언어/R] - [R] : 데이터 프레임 다루기(3) 2022.03.14 - [프로그래밍언어/R] - [R] : 데이터 개념 이해하기(1) 2022.03.14 - [프로그래밍언어/R] - [R] : 데이터 개념 이해하기(2) 2022.03.14 - [프로그래밍언어/R] - [R] : 데이터 개념 이해하기(3) Spring Boot 스프링 타입 컨버터에 대해 간단하게 코딩하고 조금 더 진화된 버전이 있다는 것을 공부했다. .. 2022. 3. 14.

[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.

[TIL] : 138 일일 배움을 위한 Today I Learned ! Spring Boot 스프링 타입 컨버터를 공부하기 전에 간단한 타입 변환을 코딩하고 앞으로 어떤 부분을 학습하게 될 지 체크해 봤다. 2022.03.13 - [Framework/Spring Boot] - [Spring Boot] : Spring type converter Kubernetes 간단하게 쿠버네티스 설치와 버전 선택에 대해 알아봤다. 2022.03.13 - [Server & System/Kubernetes] - [Kubernetes] : 쿠버네티스 버전 선택 및 설치 2022.03.13 - [Server & System/Kubernetes] - [Kubernetes] : 리눅스 서버에서 도커 엔진만으로 minikube 설치하기 2022. 3. 13.

[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.

[Docker] : 도커와 컨테이너 생태계 [Docker] : 도커와 컨테이너 생태계 컨테이너가 내부적으로 어떻게 구성되어 있는지, 생태계가 어떤 방향으로 나아가고 있는지 이해가 필요하다. 도커 핵심 프로세스라고 하면 dockerd(도커 데몬)을 떠올리기 마련이지만 사실 도커 데몬은 컨테이너가 아니다. 실제로 컨테이너 프로세스라고 부를 것은 runC이다. 컨테이너에 1대1로 매칭되는 런타임 역할을 runC가 담당한다. 그리고 여러 개의 runC 컨테이너 프로세스 및 이미지를 관리하는 주체가 바로 containerd(컨테이너-디)이다. 우리가 알고 있는 도커 엔진(dockerd 프로세스)은 contanerd와 통신을 통해 runC를 사용하게 한다. ps aux | grep contalnerd 도커가 실행중인 호스트에서도 바로 확인이 가능하다. 컨테.. 2022. 3. 12.

[Docker] : 도커 스택 사용하기 networks: {} services: mysql: comand: mysqld image: alicek106/composetest:mysql web: command: apachectl -DFOREGROUND image: alicek106/composetest:web links: - mysql: db ports: - 80:80 version: '3.0' volumes: {} docker-compose.yml 파일을 작성한다. 이제 이 파일을 가지고 스택으로 변환한다. docker stack deploy 명령어에 YAML 파일을 지정하고 마지막에 스택 이름을 입력한다. docker stack deploy -c docker-compose.yml mystack docker-compose.yml 파일에서 mys.. 2022. 3. 12.

[Docker] : 도커 스웜 모드와 함께 사용하기 stack이 도커 엔진 1.13버전에 추가됐다. 스택은 YAML 파일에서 생성된 컨테이너의 묶음으로 YAML로 스택을 생성하면 YAML에 정의된 서비스가 스웜 모드의 클러스터에서 일괄적으로 생성된다. 스택은 도커 컴포즈 명령인 docker-compose가 아닌 docker stack로 제어해야 한다. 📖 ← [ 시작하세요! 도커/쿠버네티스 ] 책을 참고하여 공부하였습니다. 2022. 3. 10.

[Docker] : 도커 컴포즈 네트워크 YAML 파일에 네트워크 항목을 정의하지 않으면 도커 컴포즈는 프로젝트별로 브리지 타입의 네트워크를 생성한다. docker-compose up 명령어뿐 아니라 docker-compose scale 명령어로 생성되는 컨테이너 전부가 이 브리지 타입의 네트워크를 사용한다. —net-alias가 서비스의 이름을 갖도록 자동으로 설정된다. 때문에 이 네트워크에 속한 컨테이너는 서비스의 이름으로 서비스 내의 컨테이너에 접근할 수 있다. 📖 ← [ 시작하세요! 도커/쿠버네티스 ] 책을 참고하여 공부하였습니다. 2022. 3. 10.

이전 1 2 3 4 다음

티스토리툴바