해당 포스팅은 "쿠버네티스 인 액션"을 공부하고 정리한 글입니다. 모든 내용은 해당 도서를 기준으로 합니다. ⬛ 5장 서비스:클라이언트가 파드를 검색하고 통신을 가능하게 함 쿠버네티스가 아닌 세계에서는시스템 관리자가 클라이언트 구성 파일에 서비스를 제공하는 서버의 정확한 IP 주소나 호스트 이름을 지정해 각 클라이언트 애플리케이션을 구성함. 쿠버네티스에서는동일한 작업을 수행하면 다음과 같은 이유로 동작하지 않음,파드는 일시적임. 노드에서 제거되거나 누군가 파드 수를 줄이거나 클러스터 노드의 장애로 언제든 다른 노드로 이동할 수 있음.쿠버네티스는 노드에 파다를 스케줄링한 후 파드가 시작되기 바로 전에 파드의 IP 주소를 할당함클라이언트는 서버인 파드의 IP 주소를 미리 알 수 없음.수평 스케일링은 여러 파..
해당 포스팅은 "쿠버네티스 인 액션"을 공부하고 정리한 글입니다. 모든 내용은 해당 도서를 기준으로 합니다.⬛ 4장 레플리케이션과 그 밖의 컨트롤러 : 관리되는 파드 배포 파드배포 가능한 기본 단위레플리케이션컨트롤러 또는 디플로이먼트와 같은 유형의 리소스를 생성해 실제 파드를 생성하고 관리함관리되지 않은 파드를 생성하면 파드를 실행할 클러스터 노드가 선택되고 파드의 컨테이너가 해당 노드에서 실행 됨노드 전체에 장애가 발생하면 노드에 있는 파드는 유실되며 레플리케이션컨트롤러나 그와 유사한 기능을 하는 컨트롤러가 해당 파드를 관리하지 않는 한 새로운 파드로 대체되지 않음 ◼️ 4.1 파드를 안정적으로 유지하기 쿠버네티스 주요 이점쿠버네티스에 컨테이너 목록을 제공하면 해당 컨테이너를 클러스터 어딘가에서 계속 ..
해당 포스팅은 "쿠버네티스 인 액션"을 공부하고 정리한 글입니다. 모든 내용은 해당 도서를 기준으로 합니다.⬛ 3장 파드 쿠버네티스에서 컨테이너 실행 ◾ 3.1 파드 소개파드는 함께 배치된 컨테이너 그룹으로 쿠버네티스가 컨테이너를 가진 파드를 배포하고 운영함.일반적으로 파드는 하나의 컨테이너만 포함하지만 파드가 여러 컨테이너를 가지고 있을 때 모든 컨테이너는 항상 하나의 워커 노드에서 실행됨. ▪️ 3.1.1 파드가 필요한 이유컨테이너는 단일 프로세스를 실행하는 것을 목적으로 설계함.그렇지 않으면 모든 프로세스를 실행하고 로그를 관리하는 건 모두 사용자 책임이다. 또, 어떤 프로세스가 남긴 로그인지 파악이 힘들기 때문에 각 프로세스를 자체의 개별 컨테이너로 실행해야 함.여러 프로세스를 단일 컨테이너로 묶..
해당 포스팅은 "쿠버네티스 인 액션"을 공부하고 정리한 글입니다. 모든 내용은 해당 도서를 기준으로 합니다. ⬛ 2장 도커와 쿠버네티스 첫걸음◼️ 2.1 도커를 사용한 컨테이너 이미지 생성, 실행, 공유하기 ◾2.1.1 도커 설치와 Hello World 컨테이너 실행하기도커 설치 : https://docs.docker.com/engine/install/ InstallLearn how to choose the best method for you to install Docker Engine. This client-server application is available on Linux, Mac, Windows, and as a static binary.docs.docker.com Hello World 컨테..
해당 포스팅은 "쿠버네티스 인 액션"을 공부하고 정리한 글입니다. 모든 내용은 해당 도서를 기준으로 합니다.⬛ 1장 쿠버네티스 소개몇 년 전만 해도 대부분의 소프트웨어 애플리케이션은 하나의 프로세스 또는 몇 개의 서버에 분산된 프로세스로 실행되는 거대한 모놀리스였음.→ 점차 마이크로서비스라는 독립적으로 실행되는 더 작은 구성 요소로 세분화되고 있음. 마이크로서비스서로 분리 돼 있기 때문에 개별적으로 개발, 배포, 업데이트, 확장을 할 수 있음.하지만 배포 가능한 구성 요소 수가 많아지고 데이터 센터의 규모가 커지면서 전체 시스템을 원활하게 구성, 관리, 유지하는 일이 점점 어려워짐.이런 구성 요소의 서버 배포를 자동으로 스케줄링하고 구성, 관리, 장애 처리를 포함하는 자동화가 필요해 짐.⇒ 쿠버네티스 등..
우분투 터미널에서 exec -it로 접속한 도커 컨테이너에서는 pip 명령어가 제대로 작동하는데 vscode에서 attach한 도커 컨테이너에서는 pip 명령어가 동작하지 않고 bash: pip3: command not found이런 에러가 발생할 때가 있다. vscode에서 바라보는 PATH와 터미널에서 접속한 컨테이너의 PATH가 일치하지 않기 때문에 일어나는 문제이다.echo $PATHvscode에서 위 명령어를 이용해 PATH를 출력하면 다음과 같이 나올 것이다.root/.vscode-server/bin/8b3775030ed1a69b13e4f4c628c612102e30a681/bin/remote-cli:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sb..
도커 컨테이너를 새로 생성 후 기본 설정을 하기 위해 apt-get update 명령어 입력시 두가지 에러를 마주 했다. 1️⃣ Couldn’t create temporary file /tmp/apt.conf이 에러는 /tmp 권한이 잘못 설정 되어 있어서 생기는 문제로 컨테이너 터미널에서 '/' 경로로 이동 후 해당 폴더의 권한을 확인해 보고 777 권한으로 수정 해 주면 된다.# / 경로로 이동 cd / # 파일 권한 확인 ll/tmp 권한이 777(drwxrwxrwx)이 아니라면 777로 변경 해 주자.# 777로 권한 변경 chmod 777 tmp # 변경 되었는지 확인 ll 2️⃣ NO_PUBKEY 에러 발생위 에러를 해결하고 다시 apt-get update를 해주었더니 이번엔 NO_PUBKEY..
항상 쓰던 서버에서 새로운 도커 컨테이너를 생성 후 vscode에서 remote를 사용하여 원격으로 컨테이너에 접속하기 위해 몇가지 파일들을 수정 해 주고 마지막으로 " /etc/init.d/ssh restart " 해당 명령어를 입력하면 문제없이 원격으로 접속이 가능했는데 서버 재부팅 후부터는 Permissions 0755 for '{key_name}' are too open. 이러한 에러가 발생했다. 이 에러는 오류를 발생시킨 key에 대한 권한이 너무 많이 부여되어 있어서 생긴 문제이다. (확인 해 보면 해당 key가 777 권한 또는 write 권한이 부여 되어 있을 것.) 따라서, 해당 key에는 write 권한이 없어야 하기에 400 권한으로 수정 해 주면 해결 된다. 컨테이너 터미널 창에서 ..
도커를 사용하면서 자주 썼던 명령어들 중 미쳐 외우지 못한 명령어들을 계속 검색해서 찾아보거나 손으로 적어둔 종이를 찾는 것이 귀찮아서 블로그에 정리 해 두려고 한다. 1. 도커 버전 확인 $ docker version 2. 도커 이미지 목록 확인 # 중간 이미지까지 모든 이미지 표시 $ docker image ls -a # 도커 id만 표시 $ docker image ls -q 3. 도커 이미지 삭제 $ docker rmi -f "이미지 id" 4. 도커 컨테이너 목록 확인 $ docker container ps -a 4. 도커 컨테이너 삭제 $ docker rm -f "컨테이너 이름" 5. 컨테이너 가동 확인 $ docker container stats "컨테이너 id" 6. 실행 중인 컨테이너 상태..
