쿠버강의 with practice tests_2
api server
● 요청의 인증 / 유효성 확인
● 데이터 etcd 데이터 스토어에서 데이터를 검색 / 업데이트
==> etcd 데이터 스토어와 직접 상호작용하는 유일한 구성요소
==> 다른 요소들의 업데이트는 api server를 통해서 수행
다양한 옵션이 있음
개중에 etcd-server= ~~~
=> 서버의 위치를 알려줌
kubeadm => apiserver-master를 배포함
=> kube-system 네임스페이스에 포드로
k get pods -n kube-system
=> pod 확인할 수 있음
/etc/kubernetes/manifests/kube-apiserver
=> 사용하지 않을경우
/etc/systemd/system/kube-apiserver
ps -aux | grep kube-apiserver
=> 실행중인 관련 프로세스에 대해서 확인
++
모든 구성요소는 연결된 인증서를 가지고 있음
kube-controller manager
-> 쿠버네티스 릴리스 페이지에서 다운로드, 활성화
다양한 컨트롤러를 관리
=> 굉장히 많은 컨트롤러 들이 있음
ex)
노드 컨트롤러 node-controller
: 시스템내 노드의 다양한 구성 요소의 상태를 지속적으로 모니터링 / 시스템 전체를 원하는 상태로 만들기 위해서 노력
복제 컨트롤러 replication-controller
: 시스템내 replicaset / replica 들의 상태를 모니터링
설정한 수의 pod가 세트 내에서 잘 작동하고 있는지 확인 => 문제시 조치
k get pods -n kube-system
=> pod 확인할 수 있음
=> 마찬가지로 kubeadm 을 사용하면 kube-system 네임스페이스에 포드로 마스터/관리자를 배포함
/etc/kubernetes/manifests/kube-controller-manager
=> 사용하지 않을경우
/etc/systemd/system/kube-controller-manager
ps -aux | grep kube-controller-manager
scheduler
일정관리자
=> 포드의 일정관리를 책임짐
==> 어떤 포드가 어떤 노드에 들어갈지만 결정함
왜 필요함?
알맞은 컨테이너를 알맞은 배(노드)에 실어야하기때문에
=> 각 컨테이너(pod)마다 요구 리소스가 다르고 / 노드마다 사양이 다르기 때문에
==> 효율적으로 관리하기 위해서는 알맞는 매칭을 해줄 필요가 있음
1. 노드 필터링(필요 리소스에따른 필터링)
2. 우선 순위 함수 -> 순위를 매겨서 최적의 노드를 찾음
ex) pod 설치 후 남아있어야될 리소스양 - 기준
설치방법
마찬가지로 쿠버네티스 릴리스 페이지에서 다운로드 wget http://~
=> kubeadm 을 사용하면 kube-system 네임스페이스에 포드로 마스터/관리자를 배포함
k get pods -n kube-system
=> pod 확인할 수 있음
kubeadm
/etc/kubernetes/manifests/kube-schuduler.yaml
ps -aux | grep kube-scheculer
kebelet
=> 배(node)의 선장 => 선 내의 모든 활동을 지휘
=> master의 유일한 연락망
=> 스케줄러의 지시에 따라서 node에서 pod/container를 관리함
=> 런타임 엔진(ex - docker)을 요청
=> 이미지 끌어와서 -> pod 생성
=> pod / container의 상태 모니터링
=> api-server => 결과 보고
클러스터 - 노드 등록
마찬가지로 쿠버네티스 릴리스 페이지에서 다운로드 wget http://~
but
kubeadm이 자동으로 kubelet을 배포하지 x
==> 작업노드에 반드시 kubelet을 수동으로 설치해야함
ps -aux | grep kubelet
kube-proxy
pod-networking solution -> cluster에 배포함으로써
=> node/pod끼리 서로 통신할 수 있음
==> 어떤 pod에 앱이 있을 때 -> 물론 pod의 ip로 손쉽게 db나 다른 서비스에 접근이 가능하지만 => ip / pod가 언제까지 일정하다고 보증할 수 없기 때문에
=> service 만들어서 - cluster ip / serviec name -> 앱에서 db에 접근
그러면 service는 ip를 어떻게 얻을까 ?
pod의 네트워크에 접근하는 것을까? x => service는 pod네트워크에 접근할 수 없음 => 왜? 서비스는 실제로 존재하는게 아니기 때문에
=> 인터페이스를 가지지 x / 실제 프로세스를 가지지 x
=> 그냥 쿠버 메모리에 있는 가상의 존재임
===> 그려면 어떻게 접근하냐고? ===> kube-proxy
proxy -> 각 운영중인 노드에서 실행되는 프로세스임 / 클러스터 안에서
===> 할일 -> 새 서비스를 찾는거 => 새거 찾으면 -> 각 노드에 접근 룰을 만듬
트래픽 -> 서비스 => 백엔드 pod/node로 접근이 가능해지는것임
iptable 규칙을 생성 -> 아웃바운드 트래픽을 서비스로 향하게 설정
마찬가지로 쿠버네티스 릴리스 페이지에서 다운로드 wget http://~
k get pods -n kube-system
=> pod 확인할 수 있음
k get daemonset -n kube-system
=> 데몬 세트로 kube-proxy
pod
앱 - docker로 개발 - docker hub repository를 통해서
-> cluster 도 준비된 상태
node - > single or multi
앱 -> 컨테이너의 형태로 배포 -> cluster 내의 worker node에
그렇지만, 쿠버는 worker node에 앱/container를 바로 배포하지 않음
===> pod로 캡슐화해서 배포함
트래픽의 증가에 따라서 애플리케이션 인스턴스를 증가시켜야 할때
=> 같은 pod에 새로운 인스턴스를 추가하는게 아니라
==> 똑같은 pod를 새로 하나 더 만들어서 스케일 업 하면 됨
===> 더 추가가 된다면 / 클러스터 내에 node를 하나 더 생성해서 pod를 만들면 됨
==> instance(app/container) : pod ==> 기본적으로 1 : 1
==> 같은 pod 안에 여러개의 container를 두는경우는 거의 없고
===> 둔다면 helper container를 두는 경우를 들 수 있다
===> helper container는 메인 container와 상태를 공유함 -> main이 죽으면 helper도 죽음
=> 둘은 같은 네트워크와 같은 저장공간을 사용함
==> 어떤 헬퍼 컨테이너가 어떤 메인 컨테이너의 헬퍼인지 이런 관계를 표시할 때도 pod를 사용하는게 효율적임
=> 그래야 상태를 공유하는 두 컨테이너를 적절하게 만들고 / 죽일 수있기 때문에
=====> 쿠버에서 이미지를 가지고 pod를 배포하면
====> k run nginx --image nginx
===> kube가 pod를 만들고, 그 안에 nginx이미지(docker hub에 있는)를 가지고 인스턴스를 생성함
k get pods
---> 그러면 사용자가 nginx 인스턴스에 어떻게 접근하는가 -> 바로 접근할 수 없음(node 내부로 바로 접근 할 수 없음)
=> 다음 강의에서는 서비스가 어떻게 유저들을 접근시키는지에 대해서 알아볼 것임
==> hands-on 할때 배웠던 내용도, 아닌 내용도 섞여 있었지만 기초부분이니만큼 다시한번 잡고 간다는 생각으로 아는 부분에 대해서도 한번더 들었음
==> 확실히 처음 들을때보다 이해가 잘됐음