3탄!! Kubernetes 구성도 알아보자!

1탄!! 쿠버네티스 구성준비/Master & Node

2탄!! 쿠버네티스와 컨테이너를 쉽게 이해하기

3탄!! Kubernetes 구성도 알아보자!

4탄!! NFS 설정입니다.

5탄!! helm install 방법

6탄 !! 도커 컴포즈 VS 쿠버네티스 컴포즈

7탄!! 쿠버네티스에 pod 올리자! pod? 뭐에요?

8탄!! K8S 대시보드 설치

9탄!! 쿠버네티스 오토스케일링(kubernetes autoscaling)

10탄!! K8S Namespace 생성방법

11탄!! 쿠버네티스 용어 정리

12탄!! 도커 깔끔히 삭제하기

# 부록!! 쿠버네티스 장애 처리5탄부록!! 쿠버네티스 장애 처리

#기타 참고하기  

마이크로 쿠버네티스 설치 해보기

쿠버네티스(컨테이너) 환경 구축의 어려운점~!

쿠버네티스(튜토리얼 실습)

쿠버네티스 초기설치및  볼트 디비 올리기[샘플]

헬름챠트로 올리기[샘플]11) 쿠버네티스 가상스토리지(Ceph) 설치

Kubernetes 구성도 알아보자!

마스터 노드 마스터 노드 안에 있는 핵심 쿠버네티스 구성 요소는 컨테이너가 필요한 리소스와 함께 충분한 횟수로 실행되도록하는 중요한 작업을 처리합니다. kube-apiserver 쿠버네티스 클러스터와 상호 작용해야 하나요? API에 요청하세요. 쿠버네티스 API는 쿠버네티스 컨트롤 플레인의 프론트엔드로, 내부 및 외부 요청을 처리합니다. API 서버는 요청이 유효한지 판별하고 유효한 요청을 처리합니다. REST 호출이나 kubectl 커맨드라인 인터페이스 또는 kubeadm과 같은 기타 CLI(command-line interface)를 통해 API에 액세스할 수 있습니다. kube-scheduler 클러스터가 양호한 상태인가? 새 컨테이너가 필요하다면 어디에 적합한가? 쿠버네티스 스케줄러는 이러한 것들을 주로 다룹니다. 스케줄러는 CPU 또는 메모리와 같은 포드의 리소스 요구 사항과 함께 클러스터의 상태를 고려합니다. 그런 다음 포드를 적절한 작업자 노드에 예약합니다. kube-controller-manager 컨트롤러는 실제로 클러스터를 실행하고 쿠버네티스 controller-manager에는 여러 컨트롤러 기능이 하나로 통합되어 있습니다. 하나의 컨트롤러는 스케줄러를 참고하여 정확한 수의 포드가 실행되게 합니다. 포드에 문제가 생기면 또 다른 컨트롤러가 이를 감지하고 대응합니다. 컨트롤러는 서비스를 포드에 연결하므로 요청이 적절한 엔드포인트로 이동합니다. 또한 계정 및 API 액세스 토큰 생성을 위한 컨트롤러가 있습니다. etcd 설정 데이터와 클러스터의 상태에 관한 정보는 키-값 저장소 데이터베이스인 etcd에 상주합니다. 내결함성을 갖춘 분산형 etcd는 클러스터에 관한 궁극적 SOT(Source Of Truth)가 되도록 설계되었습니다. 쿠버네티스 작업자 노드에서는 어떤 일이 일어날까요? 작업자 노드 쿠버네티스 클러스터에는 최소 1개 이상의 작업자 노드가 필요하지만 일반적으로 여러 개의 작업자 노드가 있습니다. 포드는 작업자 노드에서 실행되도록 예약 및 오케스트레이션됩니다. 클러스터의 용량을 확장해야 하나요? 더 많은 작업자 노드를 추가하세요. 포드 포드는 쿠버네티스 오브젝트 모델에서 가장 작고 단순한 유닛으로, 애플리케이션의 단일 인스턴스를 나타냅니다. 각 포드는 컨테이너 실행 방식을 제어하는 옵션과 함께 컨테이너 하나 또는 긴밀히 결합된 일련의 컨테이너로 구성되어 있습니다. 포드를 퍼시스턴트 스토리지에 연결하여 스테이트풀(stateful) 애플리케이션을 실행할 수 있습니다. 컨테이너 런타임 엔진 컨테이너 실행을 위해 각 작업자에는 컨테이너 런타임 엔진이 있습니다. 그중 한 가지 예가 Docker입니다. 하지만 쿠버네티스는 rkt, CRI-O와 같은 다른 Open Container Initiative 호환 런타임도 지원합니다. kubelet 각 작업자 노드에는 마스터 노드와 통신하는 매우 작은 애플리케이션인 kubelet이 있습니다. kublet은 컨테이너가 포드에서 실행되게 합니다. 마스터 노드에서 작업자 노드에 작업을 요청하는 경우 kubelet이 이 작업을 실행합니다.  kube-proxy 각 작업자 노드에는 쿠버네티스 네트워킹 서비스를 용이하게 하기 위한 네트워크 프록시인 kube-proxy도 있습니다. kube-proxy는 운영 체제의 패킷 필터링 계층에 의존하거나 트래픽 자체를 전달하여 클러스터 내부 또는 외부의 네트워크 통신을 처리합니다. 그밖에 쿠버네티스 클러스터에 필요한 것은 무엇일까요? 퍼시스턴트 스토리지 쿠버네티스는 애플리케이션을 실행하는 컨테이너를 관리할 뿐만 아니라 클러스터에 연결된 애플리케이션 데이터도 관리할 수 있습니다. 쿠버네티스를 사용하면 사용자가 기본 스토리지 인프라에 관한 상세 정보를 알지 못해도 스토리지 리소스를 요청할 수 있습니다. 퍼시스턴트 볼륨은 포드가 아닌 클러스터에 따라 다르므로 포드보다 수명이 오래 지속될 수 있습니다. 컨테이너 레지스트리 쿠버네티스가 의존하는 컨테이너 이미지는 컨테이너 레지스트리에 저장됩니다. 이러한 레지스트리를 직접 구성하거나  제 3사가 구성할 수 있습니다. 기본 인프라 쿠버네티스를 원하는 곳에서 실행할 수 있습니다. 즉 베어 메탈 서버, 가상 머신, 퍼블릭 클라우드 제공업체, 프라이빗 클라우드, 하이브리드 클라우드 환경 등에서 실행할 수 있습니다. 쿠버네티스의 주요 이점 중 하나는 다양한 종류의 인프라에서 작동한다는 것입니다.

kubectl  ReplicaSet 명세를 yml파일로 정의하고 kubectl 도구를 이용하여 API Server에 명령을 전달  API Server는 새로운 ReplicaSet Object를 etcd에 저장 Kube Controller  Kube Controller에 포함된 ReplicaSet Controller가 ReplicaSet을 감시하다가 ReplicaSet에 정의된 Label Selector 조건을 만족하는 Pod이 존재하는지 체크  해당하는 Label의 Pod이 없으면 ReplicaSet의 Pod 템플릿을 보고 새로운 Pod(no assign)을 생성. 생성은 역시 API Server에 전달하고 API Server는 etcd에 저장 Scheduler  Scheduler는 할당되지 않은(no assign) Pod이 있는지 체크  할당되지 않은 Pod이 있으면 조건에 맞는 Node를 찾아 해당 Pod을 할당 Kubelet  Kubelet은 자신의 Node에 할당되었지만 아직 생성되지 않은 Pod이 있는지 체크  생성되지 않은 Pod이 있으면 명세를 보고 Pod을 생성  Pod의 상태를 주기적으로 API Server에 전달

 

자주 사용하는 command : get, describe, edit, create, delete, top get : 리소스 리스트를 출력할 때 사용 describe : 리소스와 name에 해당하는 자세한 정보 출력( IP, 작업내용 등) edit : Pod, Service, PVC 등 resource에 설정을 변경할 때 사용 create : resource를 생성할 때 사용 apply : resource를 적용할 때 사용 delete : resource를 제거할 때 사용 top : node의 cpu, memory 사용량 확인 kubectl describe node {node명} -> 해당 node pod 사용량 확인 자주 사용하는 resource : pods, nodes, services(svc), storageclass(sc), pvc(영구볼륨클레임), pv(영구볼륨)     탭 키로 명령어 자동완성하는 방법 source <(kubectl completion bash) echo 'source <(kubectl completion bash)' >>~/.bashrc   여러 리소스에 한번에 명령 내리기 1. 똑같은 operation을 여러 같은 type의 리소스에 명령하는 경우 -> kubectl get pods pods1 pods2 2. 똑같은 operation을 다른 type의 리소스에 명령하는 경우 -> kubectl get pods/pods1 replicationcontroller/rc1 azure cli에서 cluster 설정  az aks get-credentials --resource-group ( 리소스 그룹 명 ) --name ( 클러스터 명 )    모든 namespace의 pods 정보 확인  -> kubectl get pods -o wide --all-namespaces 특정 namespace의 pods 정보 확인 -> kubectl get pods -o wide -n [namespace 명] 특정 node에 배포된 pod 정보 출력 -> kubectl get pods --field-selector=spec.nodeName=prd 특정 노드의 정보 출력 -> kubectl describe nodes  특정 파드의 정보 출력 -> kubectl describe pods example.yaml 파일이름의 서비스를 생성 -> kubectl create -f example.yaml  특정 replicaset이 제어하는 pod들의 정보 출력 -> kubectl describe pods  특정 을 가진 pod의 첫번째 container에 bash shell 실행 -> kubectl exec -it  /bin/bash 특정 이름을 가진 pod의 로그 조회 -> kubectl logs  특정 pod의 컨테이너에 접근   kubectl -n [네임스페이스명] exec -it [pod이름] /bin/bash ********************* kubectl api-resources --namespaced=true -----------------------