관심있는것들

내가 알고있는 Container Runtime은 결국 golang으로 만드러진 conmon에게 요청을 위임하면 container를 생성하거나 지운다. container는 runc위에서 동작하는것이고 중요한것은 app 영역에서 namespace 때문에 kernel 영역을 침범하지 못하는것임 namespace 에 mnt , net , uts , ipc 같은것들이 존재하는데 이들은 각자수행하는 역할이 나뉘어져있음 containers/storage/overlay 에서 overlay는 file system을 의미한다. https://bluese05.tistory.com/11 Linux namespace Linux namespace [Contents] 1. Linux namespace 2. Linux namespa..

롤링 업데이트랑 비슷하지만 조금씩 업데이트를 하며 업데이트된 버전이 문제가 있는지 확인하면서 업데이트한다 이런식으로 같이 끼워팔다가 아무 문제없으면 selector 를 변경하여서 새로운 pod만 사용이 가능하다. ConfigMap Configuration 을 pod안에 지니고 있는게 아니라 따로 존재하여 해당 pod가 다운되더라도 남아있게할 수 있고 공통된 configuration을 쉽게 적용할 수 있다. 해당 pod는 랜덤한 id를 만들어 index.html에 뿌리는 존재이다. 기본적으로 Inteveral 이 5초이지만 파란색으로 칠한 부분 때문에 Interval 이 ttabae-config 를 참조하여 2로 override하게 된다. config 파일 전체를 반영할때 명령어는 다르다 config 중 ..

동일한 이름의 pod들을 label을 추가함으로 2차원 matrix로 분류가 가능해졌다 selector는 label을 고르는 툴이다. Node Label pod 의 label과 동일한데 label이 node에 적용된 것이다. -L option으로 key값에 해당되는 disk, gpu만 보여줄 수 있다. nodeSelector에서 선택된 node에게만 해당 pod를 띄운다. 만약 node selector에 조건에 해당되는 pod가 없다면 Pending 상태로 알맞은 node가 생길떄까지 대기할 것이다. Annotation ingress , deployment 같이 특정 resource에 정해진(key) annotation 도 존재한다. 위같은 경우는 rolling update 할때 history에 기록이된..

앞단에서 서비스를 ingerss rules 를 통해 포워딩 해주는 역할을 해준다. 여러가지 오픈소스들이 존재한다. 실습 nginx controller 의 deploy.yaml 에 nodePort svc 를 추가 하였다. controller도 Running중으로 잘 생성이 되었다. 위에서 추가한 http , https 에 해당하는 node port 들이 30100, 30200 에 잘 생성이 되었다. 이미 만들어진 html , appjs 를 그냥 container 안에 Copy 할뿐이다. context 가 새로 추가 되었고 ingress-admin@kuberntes 로 switch 하게 되면 default namespace 가 ingress-nginx가 된다. marvel-home.yaml 에는 deploy..

dns 레코드 가 core dns 에 등록된다. == pod에 대한 endpoint 를 dns resolving service로 요청이 가능해진다. pop~.local 의 DNS주소를 부여해준다. type이 따로 존재하는것이 아니라 clusterip: None 을 해줘야한다. 아니면 random으로 ip하나 생성해준다. cluster ip가 none이지만 endpoint 는 위의 pod 3개를 포함하고 있다. curl 10-36-0-1.default.pod.cluster.local 을 하게 되면 3번 째 pod에 요청을 날리게 된다. https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#stable-network-id Statefu..

service api == app:webui 라는 label을 가지고 (여기서는 3개의 pod)를 하나로 묶는다. 그리고 이 3개를 대표하는 virtual ip (cluster ip)를 하나 만들어준다. 즉 Load Blanacer IP가 만들어진다. 위의 정보는 etcd에 기록이 된다. Service type ClusterIP = Pod 그룹의 단일점 (Virutal IP) 생성, 제일 기본적인 기능 , 내부 통신용 NodePort = ClusterIP 가 생성된 후 , 모든 Worker Node 에 외부에서 접속가능한 포트가 예약 , 밖에 클라이언트가 해당 포트와 worker node 의 ip 에 접속을 시도하면 저 묶인 pod중 하나로 연결을 해준다. 위의 2개는 다 cluster안에서 만 서로 트..

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