kubernetes

[kubernetes] kubectl 동작 방식 확인 [kubernetes] kubelet 동작 방식 확인 [kubernetes] kube-proxy 동작 방식 확인 kubectl 쿠버네티스 클러스터에 명령을 내리는 역할 다른 구성 요소들과 다르게 바로 실행되는 명령 형태인 바이너리로 배포되기 때문에 마스터 노드에 있을 필요는 없음 [vagrant@w3-k8s ~]$ kubectl get nodes The connection to the server localhost:8080 was refused - did you specify the right host or port? 클러스터의 정보가 저장되지 않은 워커 노드에서 클러스터의 정보를 가져오려고 시도할 경우 실패한다. kubectl이 어떤 노드에 있더라도..

마스터 노드 0. kubectl 쿠버네티스 클러스터에 명령을 내리는 역할 다른 구성 요소들과 다르게 바로 실행되는 명령 형태인 바이너리로 배포되기 때문에 마스터 노드에 있을 필요는 없음 1. API 서버 쿠버네티스 클러스터의 중심 역할을 하는 통로(백본처럼) 2. etcd 구성 요소들의 상태 값이 key-value형태로 저장되는 곳 etcd를 제외한 다른 구성 요소들은 상태 값을 따로 관리하지 않음 따라서 etcd의 정보만 백업되어 있으면 클러스터 복구 가능 key-value는 분산 저장이 가능하여 복제해 여러 곳에 저장하면 한 곳에서 장애가 발생해도 시스템의 가용성 확보 가능 리눅스의 구성정보를 가지는 etc 디렉터리 + distributed 3. 컨트롤러 매니저 클러스터의 오브젝트 상태 관리 노드 컨..

# 각 pod에 대한 사양 spec: # 중요. 컨테이너 지정. 여러개 지정 가능. 이름 지정 가능 containers: # 이름 임의로 작성 가능 - name: second-node # 사용할 이미지 image: summer99summer/kub-first-app:2 # 컨테이너가 실행 중인지 확인 livenessProbe: httpGet: path: / port: 8080 # 작업을 수행해야 하는 빈도 periodSeconds: 10 # 기다려야 하는 시간 initialDelaySeconds: 5 k8s에서 yaml 파일 작성 시 spec 아래 livenessProbe 속성을 주면 컨테이너가 실행 중인지 확인하고 아니라면 재시작 시킬 수 있다.

파일 이름은 아무거나 가능하다. # 사용할 버전 apiVersion: apps/v1 # 객체의 종류 kind: Deployment # 이름 같은 중요 데이터(객체 생성시에 정의해주어야 함) metadata: # 이름은 임의로 작성 가능 name: second-app-deployment # 레이블을 붙여 객체의 구별성 주기 labels: group: example # 중요. deployment에 대한 사양 spec: # 복제하여 생성할 pod갯수 replicas: 1 # deployment에서 관리할 pod를 정의 selector: # 관리할 pod의 label. 여러개 가능 # 설정한 label이 모두 맞아야 관리함. 하나라도 다르면 안 함 matchLabels: app: second-app tier: ..

명령적 방식(imperative)과 선언적 방식(declarative)으로 객체를 생성한다. 명령적 방식 imperative - kubectl 명령 사용 - 작업을 위해 개별적인 명령 실행 - docker run으로 모든 명령을 하는 것과 비슷함 선언적 방식 declarative - apply 명령을 사용하여 yaml로 작성한 설정(config) 파일을 읽어옴 - config 파일에 원하는 상태를 정의한다. - Docker Compose와 비슷하다. Pod 쿠버네티스와 상호작용 하는 가장 작은 단위 한 개 이상의 컨테이너를 보유하고 실행시킨다. 일반적으로 한 개를 가진다. 다른 pod들과 공유하는 공유 리소스를 가진다. (e.g. volume) 기본적인 내부 IP 주소를 가진다. localhost 주소를..

Kubernetes를 사용해야하는 이유 보안성과 환경 구성 문제 이전에, 수동 배포는 운영이 어렵다. 컨테이너 내부에서 문제가 발생하여 전체 컨테이너의 충돌이 발생하고 다운되어 교체가 필요할 수 있다. > 수동 배포에서는 충돌이 발생할 대마다 수동으로 모니터링하고 컨테이너도 수동으로 다시 시작시켜야 한다. > 애플리케이션이 크거나 중요할 경우 문제가 커질 수 있다. > 컨테이너 상태 확인과 재배포 필요 트래픽 급증에 따른 컨테이너 인스턴스의 증가가 필요할 수 있다. > 트래픽이 줄어들면 컨테이너의 감소도 필요하다. > 오토스케일링 필요 들어오는 트래픽에 대해서 실행 중인 컨테이너의 인스턴스에 균등한 분배가 필요하다. > 로드 밸런서 필요 특정 CSP(Cloud Service provider)사를 이용하여..