Kubernetes

Pod 안에는 하나의 독립적인 서비스를 구동할 수 있는 Container들이 있다.그 Container들은 서비스가 연결될 수 있도록 port를 가지고 있다.하나의 Container가 하나 이상 가질 수 있지만 한 Pod내에서 Container들끼리 port가 중복될

Service는 기본적으로 자신의 ClusterIP를 가지고 있다. 그리고 이 Service를 Pod에 연결시켜 놓으면 Service의 Ip를 통해서 Pod에 접근할 수 있다. Pod에도 똑같은 Cluster내에서 접근할 수 있는 IP가 있는데 굳이 Service를 달

컨테이너들끼리 데이터를 공유하기 위해서 볼륨을 사용한다.최초 Volume이 생성 될 때는 항상 Volume이 비어있기 때문에 emptyDir라고 명칭되었다.만약 Container1이 Web역할, Container2가 Backend역할을 처리해주는 서버라고 했을 때 이

개발서버에 A라는 Service에는 일반접근과 보안접근을 지원하고 있다고 가정해보자.개발환경에서는 보안접근을 해제할 수 있는 옵션이 있고 보안접근을 한다면 접근User와 key를 세팅할 수 있다.하지만 개발 서버를 운영 서버로 배포를 해야 한다면 이 값들이 변경되어야

쿠버네티스 클러스터에는 Memory, Cpu가 있고 클러스터 안에는 여러 Namespace를 만들 수 있고 Namespace안에는 여러 Pod들을 만들 수 있다.각 Pod는 필요한 자원을 클러스터 자원을 공유해서 사용하는데 만약 한 Namespace안에 있는 Pod가

Controller > 쿠버네티스의 Controller는 Service를 관리하는데 큰 도움을 준다. (Auto Healing, Software Update, Auto Scaling, Job) Auto Healing > Node 위에 Pod가 있는데 이 Pod가 갑

현재 한 Service가 운영중인데 이 Service를 Update해야되서 재배포해야 할 때 많은 도움이 되는 Controller다.Deployment를 만들면 V1의 Pod들이 만들어진다.Pod 하나당 하나씩 자원이 사용된다고 가정하면 (자원사용량 = 2)만약 Rec

Node들이 있고 각각의 Node들에 자원이 각각 다르게 남아 있는 상황에서 ReplicaSet의 경우 Pod를 스케줄링을 통해 배치하기 하기 때문에 자원이 많이 남아 있는 쪽에 많이 배치가 될 가능성이 높다. DaemonSet은 Node의 자원상태와 상관없이 모든 N

Pod가 있고 Status안에 Phase라고해서 Pod의 전체 상태를 대표하는 속성이 있고, Pod가 생성되면서 실행하는 단계들이 있는데 그 단계와 상태를 알려주는 속성이 Condition이다.Pod안에는 Container들이 있는데 Container들도 State라고

우리가 Pod를 만들면 그 안에 Container가 생기고 Pod와 Container의 상태가 Running이 되면서 그 안에 있는 App도 정상적으로 구동이 될 것이다.그리고 Service에 연결 되고 Service의 IP가 외부에 알려지면서 외부에서는 이 Servi

Node에 자원이 있고 Node위에 Pod가 3개 만들어져서 균등하게 자원을 사용하고 있다고 가정해보자.이 상태에서 Pod1이 추가적인 자원을 더 사용해야 하는 상황이 발생했다.Node에는 추가적으로 할당받을 수 있는 자원이 없기 때문에 Node1이 Resource 부

Pod는 기본적으로 쿠버네티스의 스케줄러에 의해서 Node에 할당되지만 사용자에 의해서 직접 Node를 할당하거나 특정 Node에 할당 하지 않도록 지정할 수 있다.NodeName, NodeSelector, NodeAffinity : Pod를 특정 Node에 할당 되도

위의 사진을 예시로 공유기에서 192.168.0.1로 시작하는 IP로 내부망이 형성된다고 가정했을 때 3대의 서버를 이용해서 Master와 Node로 Kubernetes Cluster가 만들어지고 Cluster안에는 Pod를 위한 IP 대역과 Service를 위한 IP

Volume은 데이터를 안정적으로 유지하기 위해서 사용한다.그러기 위해서 실제 데이터는 쿠버네티스 Cluster와 분리되서 관리된다.그리고 이런 방식으로 관리될 수 있는 Volume의 종류들이 많은데 크게 내부망에서 관리하는 경우와 외부망에서 관리하는 경우 2가지로 분

Volume은 데이터를 안정적으로 유지하기 위해서 사용한다.그러기 위해서 실제 데이터는 쿠버네티스 Cluster와 분리되서 관리된다.그리고 이런 방식으로 관리될 수 있는 Volume의 종류들이 많은데 크게 내부망에서 관리하는 경우와 외부망에서 관리하는 경우 2가지로 분

Master Node에 쿠버네티스 API 서버가 있는데 이 API 서버를 통해서만 쿠버네티스의 자원을 조회하거나 만들 수 있다. kubectl로 쿠버네티스의 자원을 조회할 수 있는 것도 API서버에 접근을해서 정보를 가져오는 것이다. 외부에서 API 서버로 접근하려면

Cluster에 6443 Port로 API 서버가 열려있고 사용자가 이 API 서버로 https 접근을 하려면 쿠버네티스 설치 시 kubeconfig 라고해서 이 Cluster에 접근할 수 있는 정보들이 들어있는 파일이 있는데 이 파일안에 인증서 내용(CA crt, C

역할 기반으로 권한을 부여하는 방식이다.쿠버네티스에는 Node나 PV 그리고 Namespace 같이 Cluster 단위로 관리되는 자원과 Pod와 Service같이 Namespace 단위로 관리되는 자원으로 나눌 수 있다.그리고 Namespace를 만들면 자동적으로 S

Application의 종류에는 Stateless Application과 Stateful Application이 있다. Stateless는 대표적으로 Web Server이고 Apache, Nginx 등이 있고 Stateful은 대표적으로 Datebase이고 Mysql,

쇼핑 페이지, 고객센터, 주문서비스를 Pod별로 나누었다고 가정했을 때 쇼핑 페이지가 문제가 생겨도 고객센터나 주문서비스는 가능할 수 있다는 장점이 있다. 그리고 외부에서 연결할 수 있도록 각각 Service를 달아주고 사용자들로 하여금 각각 다른 도메인 path를 주

쿠버네티스에는 Pod의 개수를 늘려주는 HPA와 Pod의 Resources를 증가시키는 VPA 그리고 Cluster의 Node를 추가하는 CA 이렇게 3가지의 AutoScaler가 있다.컨트롤러가 있고 replicas= 1로 Pod가 운영되고 있는 상태에서 Servic

먼저 Master Node에는 etcd, kube-scheduler, kube-API서버가 있는데 일반적인 설치를 했을 때 이 Component들은 Pod의 형태를 띄어져서 구동중인 상태다. /etc/kubernetes/manifests 라는 폴더를 보면 이 Compo

Pod의 네트워크를 담담한다. Pod를 만들게 되면 내가 생성한 Container가 있지만 Pause Container라고 해서 Networking을 담당하는 Container가 자동으로 생성된다.이 컨테이너에 Interface가 달려있고 IP가 생기는데 쿠버네티스가