관심있는것들

reliability 를 증가시키기 위해서 master node가 여러개이다. etcd 끼리 항상 동기화되어 있다. worker 노드들은 마스터와 직접 통신하는 것이 아니라 load balancer 와 통신하게 된다. master 3개 load balancer 1개 worker 2개 총 컴퓨터 갯수가 7개다. Load Balancer docker run --name proxy -v /etc/nginx/nginx.conf:/etc/nginx/nginx.conf:ro --restart=always -p 6443:6443 -d nginx --restart=always == docker daemon과 함께 항상 같이 실행이 된다. volume mount를 통해 lb 로 동작하게 한다. -p == port for..

kubectl run testpod --image=centos:7 --command sleep 5 5초후에 컨테이너가 종료가 된다. 하지만 kubenetes 의 가장 기본기능이 24/7 pod 가 살아있게(Running) 하는거니까 Restart 시킨다. RESTARTS 가 계속해서 증가한다. 해당 pod가 batch 작업 (로그를 db로 다 옴기거나) 이 정상적으로 끝났다면 pod가 종료되더라도 다시 실행 안시키고 만약 batch 작업을 완료하지 못하고 비정상적으로 끝났다면 다시 실행시킨다. 50초후에 종료 되는 job이다 restartPolicy :Never = 해당 컨테이너에 문제가 생기면 아예 새로운 pod를 실행시킨다. restartPolicy: OnFailure + backoffLimit:3 ..

DemonSet은 노드당 pod가 한개가 운영되는 것을 보장해준다. 처음에 노드가 2개 였을 때 1개가 더 추가되면 추가된 노드에도 pod를 1개 실행시켜준다. 주로 monitoring , log 와 관련된 pod 에 쓰인다. kubeproxy , CNI network 도 내부적으로는 Daemonset이 쓰인다. kind 만 다르고 replicas는 항상 1임으로 명시하지 않는다. 해당 nginx version 을 1.15로 업그레이드 하고 저장하면 rolling update 가 이루어진다. rollback 도 동일하게 이루어진다. StatefulSet 중간에 node2의 1번 pod가 down 되면 node3에 이름이 1번 pod인 녀석을 실행시켜줄 수있다. daemonSet 처럼 노드당 1개의 pod..

Deployment , ReplicaSet , pods 계층적인 구조를 이루는 것을 확인 kind 이름 만 빼고 다 똑같다. ReplicaSet 의 부모이기 때문이다. deployment를 실행시키니 이에 해당하는 replicaset도 저절로 생겨났다. 이름을 보면 deploy-nginx , replicaset , pod 순으로 구성된것을 확인할 수 있다. 동일한 deployment , 동일한 replicaset 서로다른 3개의 pod가 생겼구나 를 확인 Rolling Update = pod instance들을 점진적으로 업그레이드하여 서비스 중단 없이 배포를 하는것 set 명령어를 통해 rolling update 를 하게 된다. 새로운 replicaset yyy 를 생성하고 처음에는 replicas =..

기존의 replicationController 와 동일한 역할을 하지만 좀 더 selector를 구체적으로 작성할 수 있도록 도와 준다. {key:version , operator: In, value:["1.14","1.15"]} 의 의미는 label 중 version:1.14 , version:1.15 둘다 를 의미하게 된다. kubectl delete rc rc-nginx 명령어를 통해 replicationController를 죽이게 되면 기존의 실행중이던 3개의 pod들도 terminate되게 된다. kubectl delete rs rs-nginx --cascade=false 명령어는 replica set만 삭제시키는 명령어이다. 기존에 동작하고 있는 pod들은 잘 동작하게 놔둔다. kubectl ..

Controller의 역할 pod의 개수를 보장 api에게 요청을 날리면 etcd에서 worker node의 정보를 얻어와서 scheduler에게 어디에 다가 배치를 해야하나를 api에 응답해준다. controller에게 nginx container 3개를 보장해줘라고 요청을 한다. 만약 중간에 하나가 고장나면 controller가 api보고 하나를 더 추가해라 하고 api는 다시 위의 과정을 거쳐서 하나를 추가로 실행한다. Controller의 종류들 Replication Controller 요구하는 Pod의 개수를 보장하며 파드 집합의 실행을 항상 안정적으로 유지하는 것을 목표 selector 가 구분자 역할을 하게 된다. template 은 recepie kind 에서 replicationContr..

livenessProbe = 일종의 건강검진이다. Application 이나 Container의 상태를 지속적으로 확인한다. 지속적으로 포트 80번으로 Get Request를 보내서 잘 동작하는지 지속적으로 확인해준다. 하지만 각 application Container 마다 건강검진의 방식이 다를 것이다. linvessProbe 매커니즘 httpGet probe = 지정한 IP주소 , port , path 에 HTTP GET 요청을 보내 , 해당 컨테이너가 응답하는 지 확인한다. 반환코드가 200이 아닌 값이 나오면 오류라 생각하고 컨테이너를 다시 시작한다. nginx , nodejs , apache 등등 tcpSocket probe = 지정한 포트에 TCP 연결을 시도 , 연결되지 않으면 컨테이너를 다..

Container app.js 로 간단한 web application 을 작성한다. Dockerfile 을 base image 로 Node 12 버전으로 app.js를 빌드 해준다. public ,private hub 에 push를 통해서 저장을 해준다. 이렇게 만들어진 컨테이너를 사용할때는 Docker 가 설치된 리눅스 시스템에서 불러와서 동작시킬 수 있다. Pod = 컨테이너를 표현하는 Kubernetes API의 최소단위 pod에는 하나 또는 여러 개의 컨테이너가 포함될 수 있음 pod를 실행시키는 2가지 방법 1. kubectl run webserver --image=nginx:1.14 --port=80 =webserver 라는 이름의 pod를 실행해주되 안의 container는 nginx:1.1..

docker compose = 여러개의 container를 설정(docker compose yaml) 해준 값에 따라 알아서 실행해 준다. version: "3.9" services: db: image: mysql:5.7 volumes: - db_data:/var/lib/mysql restart: always environment: MYSQL_ROOT_PASSWORD: somewordpress MYSQL_DATABASE: wordpress MYSQL_USER: wordpress MYSQL_PASSWORD: wordpress wordpress: depends_on: - db image: wordpress:latest volumes: - wordpress_data:/var/www/html ports: - "..

docker0 = network interface , NAT 와 포트포워딩 서비스를 지원한다. (iptables를 통해) bridge = docker host1의 네트워크 인터페이스와 veth0,1 을 연결해주는 역할을 한다. enp0s3가 현재 VM의 host ip 가 된다. docker0 는 브릿지 역할을 한다. host로부터 80포트로 들어오는 모든 패킷은 nginx 컨테이너 80port로 다 포트포워딩이 된다. 포트는 항상 일대일 매핑이다. docker0 네트워크 인터페이스안에는 static하게 고정ip 를 주는게 불가능하다. 새로운 bridge를 만들면된다. default gateway 는 subnet이 저런 상태일때는 192.168.100.1 이 된다. 0은 identifier ,255는 br..