Kubernetes Basic - 2

• Controller Manager는 여러 Controller의 한 덩어리로, 여러개의 Controller를 관리하며, 순차적으로 돌아가게 해준다.
  • Controller Manager가 관리하는 것은 Deployment, ReplicaSet, Node 등이다.
• Controller Manger의 특수한 형태가 kubelet이다. 
• Controller는 kubelet과 같은 역할이지만, 관리해주는게 다르다. (쳐다보는게 다름)
  • kubelet은 주문서인 Pod를 쳐다봄.
  • Controller Manager는 클러스터 전반을 관리하지만, kubelet은 각 개별 노드를 관리한다. 

---

Pod

• 컨테이너를 풀어서 돌게 해준다. 컨테이너를 돌리는 기본 단위이다.
• Pod 안에는 보통 컨테이너가 하나인데, 사실은 Kube-proxy를 합쳐서 두개이다. 
  • Application을 돌리는 컨테이너와 도와주는 Kube-proxy
  • Kube-proxy: Worker Node 안에 있는 Pod를 찾으러 왔을 때, 바로 그 Pod로 가는게 아니라, 물어물어 가도록 되어있다. => Pod1으로 요청이 와도 Pod2와 Pod3로 가게 해준다. (로드밸런싱). 네트워킹을 관리해서 외부와의 통신을 가능하게 해주는 역할을 수행한다.
• 하지만, 꼭 하나의 Pod 안에 하나의 Container만 돌리는 것은 아니다. 
• 컨테이너를 돌게 해주는 것도 Pod이고 주문서도 Pod라 한다.
• Pod에 자동으로 주소가 붙는데 이건 DHCP 같은 애가 한다. 죽었다 살아나면 주소가 바뀐다.

---

ReplicaSet

• 동일한 Pod를 여러개
• 항상 일정한 수의 Pod가 유지되도록 한다. 
• Pod를 몇개 돌릴거냐를 한번에 표현한다.
• ReplicaSet을 쳐다보는게 ReplicaSet Controller
  • ReplicaSet Controller가 주문서 양식인 Pod로 만든다. 
  • Pod라는 주문서 형식으로 만들어야 한다. kubelet은 etcd의 주문서 Pod만 보고 있으니까.

---

Deployment

• ReplicaSet보다 더 편리한 형태의 관리 도구이다.
• 서로 다른 종류의 Pod를 한번에 Deploy하고 싶을 때 사용한다.
  • Deploy의 종합
• Deployment는 ReplicaSet을 관리하는 역할을 한다. 
  • ReplicaSet의 기능인 Pod 수를 유지하는 것만이 아니라, ReplicaSet 구버전과 새버전 간에 업데이트와 롤백도 가능하다.
    • 새로운 버전의 애플리케이션을 배포할 때, 구 버전의 Pod르 하나씩 종료하고, 새 버전의 Pod를 하나씩 실행하여 서비스에 지장을 주지 않도록 한다.
• Deployment는 자체적으로 ReplicaSet을 생성하고, 그에 따라 Pod가 생성되어 배포된다.

① kubectl 명령 실행: kubectl 명령을 통해 K8S 클러스터에 명령을 전달한다. kubectl create 명령어 실행시, HTTP Post 요청으로 API Server에 전달된다. (Deployment manifest를 포함해서) API 서버는 이것을 etcd에 저장하고, kubectl에 응답을 리턴한다.

②, ③: Deployment Controller는 Deployment를 보고 적절한 ReplicaSet을 생성한다.

④, ⑤: ReplicaSet Controller는 변화를 감지해서 pod selector를 이해하고, 적절한 수의 Pod를 생성한다.

⑥, ⑦: K8S는 이제 Pod를 실행시키기 위한 모든 정보를 가지게 되었다. 하지만, 어느 노드가 돌릴지가 중요한데, 이것은 Scheduler가 정해준다. 정해서 etcd에 쓴다.

⑧, ⑨, ⑩: kubelet은 etcd를 보고, etcd에 써있는 Scheduler가 선택한 Node의 kubelet은 Container Runtime에게 컨테이너를 만들라고 명령한다. 이제 Pod가 실행 가능하다. 

---

Service

• Pod가 생성될 때, Pod에는 자동으로 IP 주소가 할당된다. 
• 하지만, Pod는 죽었다가 살아나면 IP 주소가 변경될 수 있다.
• 이러한 불안정함 때문에 외부 클라이언트나 다른 리소스가 직접 Pod의 IP를 참조하기 어렵다.
• 이 Pod가 혼자 돌게 할게 아니라 다른 것과 함께 동작하게 하려면 Service로 만들어야 한다.
  • 주소가 바뀌면 안됨. 죽었다가 살아나도 같은 주소를 갖게 해야 한다.
• Pod IP
  • Pod에 IP가 붙지만, 임시적이다. 죽었다가 살아나면 바뀐다.
• Cluster IP
  
  • Service에 붙는 IP 주소다. 이 주소는 바뀌지 않아 안정적으로 외부나 클러스터 내에서 접근 가능하다.
• 여러개의 Pod를 묶어서 하나의 Service로 접근 가능하게 한다. 
  • 트래픽을 감당하고, 서버의 안정성을 위해
  • 로드 밸런싱
• Pod가 죽었다가 살아나면 IP 주소가 변경될 수 있는데, 이것은 Endpoints가 관리해준다.
• Endpoints
  • Service의 Pod IP를 추적하여 관리해준다.
  • 만약 특정 Pod의 IP 주소가 바뀌면 추적해서 업데이트한다.
• ReplicaSet은 같은 일을 하는 Pod들을 묶고, Service는 그런 Pod들을 하나의 고정된 주소로 접근 가능하게 묶어준다. 
  • 로드 밸런싱과 IP 안정성을 보장한다.

Service 종류

• ClusterIP
  • 클러스터 내부 통신. 클러스터 내부에서만 접근 가능
•  NodePort
  
  • 클러스터 외부에서도 접근 가능
  • Node IP:Port# 로 접근
  • 외부에서 보이는 Public 주소는 하나이지만, 내부에서 사용하는 Private 주소는 여러개.
    • Public 주소의 Port 넘버로 Private 주소를 구별한다 => NAT
  • port
    • Service의 Port
  • targetPort
    • Pod의 Port
    • Service로 묶인 Pod 그룹이 동일한 Port 번호를 가지고, IP로 구별된다. 
  • nodePort
    • Node의 Port
    • 따로 명시하지 않으면 30000 ~ 32767의 범위로 자동 할당

#ClusterIP
 apiVersion: app/v1
 kind: Service
 metadata:
 	name: my-service
 spec:
 	selector:
    	app.kubernetes.io/app: MyApp
    ports:
    	port: 80
        targetPort: 9376

#NodePort
apiVersion: app/v1
kind: Service
metadata:
	name: my-service
spec:
	type: NodePort
    selector:
    	app.kubernetes.io/app: MyApp
    ports:
    	port: 80
        targetPort: 80
        nodePort: 30007

(들여쓰기가 이상합니다..)