참조:https://captcha.tistory.com/78 [#1. Kubernetes 시리즈] 3. CNI란? (Container Network Interface) 이번 글에서는 쿠버네티스를 설치하기 전에 간략하게 CNI(Container Network Interface)에 대하여 알아보겠습니다. 무작정 문서대로 설치만 하기 보다는 내가 설치하는 애가 무엇인지 알고 가는게 좋을 captcha.tistory.com 참조: https://coffeewhale.com/packet-network2 [번역]쿠버네티스 패킷의 삶 - #2 쿠버네티스 패킷의 삶 #1에서 살펴 봤듯이, CNI plugin은 쿠버네티스 네트워킹에서 중요한 역할을 차지합니다. 현재 많은 CNI plugin 구현체들이 존재합니다. 그 중..

Kubernetes Deployment 버전 업데이트를 위해 사용한다. Replica set의 상위 오브젝트로서 생성 시, 대응되는 Replica set도 자동 생성된다. 따라서 Replica set을 생성하는 경우는 거의 없다. Deployment는 애플리케이션을 업데이트할 때 레플리카셋의 변경 사항을 저장하는 리비전을 남겨 롤백을 가능하게 해주고, 무중단 서비스를 위한 롤링 업데이트 전략을 적용할 수 있다. 하나씩 없애고 v2에 새로 생성한다. 트래픽을 점차 v2 pod들로 옮겨주면, 서비스 중단 없는 무중단 서비스가 실현이 된다. Deployment 생성해 보기 # deployment.yaml cat > deployment.yaml apiVersion: apps/v1 kind: Deployment#..

Kubernetes Replicasets 일정 개수의 파드를 유지하는 컨트롤러이다. 동일한 여러 개의 파드를 유지해야 할 때, 파드들을 일일이 정의해서 직접 생성하기 보다는 Replica set이라는 오브젝트를 사용한다. Replicaset을 사하면 더 이상 파드의 상태를 관리할 필요가 없어지고, Replica set이 자동으로 일정 개수만큼 유지해 준다. Replica set 또한 Pod처럼yaml파일로 정의 후에 apply 시키면 된다. # 테스트 레플리카 # replicaset.yaml cat > replicaset.yaml apiVersion: apps/v1 kind: ReplicaSet# kind가 레플리카 셋 metadata: name: replicaset-cloud spec:# 레플리카의 스..

파드의 상태(STATUS) 파드는 자신의 상태를 스스로 판단해서 모니터링에게 데이터 던져줄 수 있다. • Pending: 포드를 생성하는 요청이API서버에의해승인됐지만, 어떠한 이유로인해아직 실제로 생성되지 않은 상태입니다. 예를 들어, 포드가 아직 노드에 스케줄링되지 않았을 때는 포드의 상태가 Pending으로 출력됩니다. • Running: 포드에 포함된 컨테이너들이 모두 생성돼 포드가 정상적으로 실행된 상태입니다. 일반적으로 쿠버네티스에서 바람직한 상태(Desired)로 간주하는 포드의 상태 • Completed: 포드가 정상적으로 실행돼 종료됐 음을 의미합니다. 포드 컨테이너의 init 프로세스가 종료코드로서0을 반환한 경우에 해당 • Error: 포드가 정상적으로 실행되지 않은 상태로 종료됐 음..

Pod 생성 후 동작 # 파드 실행 kubectl run myweb --image=nginx 현재 세팅 중인 디폴트 Namespace에 생긴다. kubectl delete pod myweb yaml 파일로 실행 한땀한땀 커맨드 넣기는 명령형은 힘들다. 그냥 yaml로 만들어 버리자. k run myweb --image nginx --dry-run -o yaml --dry-run 옵션은 실제로 만드는게 아니라 리허설 옵션 실행되지 않고 yaml 파일만 생성한다. 없는 내용은 디폴트값으로 만들어진다. apiVersion은 적합한 것으로 맞춰지게 생성된다. # yaml 파일에 출력 결과 저장 k run myweb --image nginx --dry-run -o yaml > myweb.yaml #yaml 파일로..

Kubectl 기본 명령어 마스터 노드에 설치한, 쿠버네티스의 클라이언트인 kubectl의 기본 명령어들을 살펴보자. #node 확인 kubectl get nodes kubectl get nodes -o wide #추가적인 정보도 확인 kubectl get pod 현재 네임 스페이스에 파드를 출력하지만 파드가 없다. kubectl get pod -A 모든 네임스페이스의 파드를 출력 #특정 네임스페이스의 파트 출력 kubectl get pod -n kubectl-calico 사용하기 # kubectl-calico 명령어 사용을 위한 세팅 curl -L https://github.com/projectcalico/calico/releases/latest/download/calicoctl-linux-amd64 ..

쿠버네티스 네임스페이스 네임스페이스는 쿠버네티스에서 용도에 따라서 리소스를 논리적으로 구분하기 위해 사용하는 오브젝트이다. 리눅스의 네임스페이스와 같은 이름이기 때문에 동일한 것으로 생각할 수 있지만, 완전히 다른 것이다. 단순히 파드를 그룹화하여 관리하기 위해 사용하는 것으로 이해하면 쉽다. 리눅스의 네임스페이스는 컨테이너의 격리 공간을 만들기 위해 리눅스 커널의 자체 기능을 활용한다. 일반적으로는 네트워크와 마운트, 프로세스 네임스페이스 등을 의미한다. 리눅스 네임스페이스 프로세스를 실행할 때 시스템의 리소스를 분리해서 실행할 수 있도록 도와주는 기능. 리눅스는 기본적으로 하나의 시스템의 프로세스들은 리소스를 공유하여 실행한다. 예를 들어 자식 프로세스는 부모 프로세스의 네임스페이스에 속하므로 자원을..

** 아래의 게시글을 참조해서 설치하였습니다. ** https://lewis-kku.tistory.com/112 Kubernetes | Kubespray 설치 방법 Kubespray 이번엔 kubeadm이 아닌 Kubespray를 설치해본다. kubeadm은 수동으로 모듈을 하나씩 설치하지만 kubespray는 Ansible 기반의 배포툴로 매우 간단하다. https://kubernetes.io/ko/docs/setup/production-environment/tool lewis-kku.tistory.com KubeSpary Kubespray는 Ansible을 통해 쿠버네티스 클러스터를 유연하고 쉽게 배포 및 관리하기 위한 강력한 오픈 소스 툴이다. Kubespray는 Ansible 플레이북, 인벤토리,..

Kubeadm으로 쿠버네티스 직접 설치하기 Kubeadm은 직접 서버와 네트워크 인프라를 구축하여 그 위에 쿠버네티스를 설치한다. VM에 직접 설치하는 표준 방법이지만, 버전에 따른 정확한 절차를 따라야 하기 때문에 어렵다. 또한 자동화가 불가능하기 때문에 관리가 힘들다. 하나하나 따라가며 설치해 보자. Vagrantfile로 VM 올리기 일단 Vagrant와 Virtual box의 설치가 필요하다. [Window] Vagrant 설치 및 활용 (synced_folder, Docker) SCRIPT에 ssh 보안 관련 설정이 등장한다. /etc/ssh/sshd_config sed -i "s/^PasswordAuthentication no/PasswordAuthentication yes/g" /etc/ss..

쿠버네티스란? 쿠버네티스(Kubernetes)는 쿠버네티스는 컨테이너의 배포, 관리, 확장, 네트워킹을 자동화하는 컨테이너 오케스트레이션 플랫폼이다. MSA 발전과 함께 성장한 쿠버네티스 과거에 서버 관리를 코드로 하는 툴들이 먼저 등장했다. 여기에 서버 자원들을 논리적인 나누어 효율적으로 사용하는 가상화 기술들이 도입되기 시작한다. 이러한 가상화 자원들은 여전히 많이 사용되지만, 가상화가 가진 한계(오버헤드)로 프로비저닝과 서비스 속도가 떨어진다. 그래서 등장한 것이 컨테이너로, 컨테이너들은 각각이 커널을 가지지 않기 때문에 가볍고 프로비저닝과 서비스 속도에서 우수하다. 하지만 점점 증가하는 컨테이너 개수를 모두 관리하는 것은 쉽지 않은 일이다. 예를 들어 트래픽 부하로 새로운 도커 컨테이너를 실행시켜..