https://kubernetes.io/ko/docs/tasks/tools/
도구 설치
컴퓨터에서 쿠버네티스 도구를 설정한다.
kubernetes.io
프로그램을 개발해서 배포한다. 여기서 이 "배포" 및 관리를 위해 컨테이너, 도커, 쿠버네티스를 사용할 수 있습니다.
Kubernetes 클러스터 구성 요소
- kube-apiserver: Kubernetes API 서버로, 클러스터의 모든 요청 처리. 마스터 노드에서 실행. == 컨트롤 플레인.
- etcd: 모든 클러스터의 데이터. Kubernetes의 분산 키-값 저장소로, 클러스터의 상태 정보를 저장.
- kube-controller-manager: 컨트롤러 프로세스를 실행하는 컨트롤 플레인 컴포넌트.
- kube-scheduler: 새로운 파드를 클러스터의 적절한 노드에 스케줄링.
- kube-proxy: 클러스터 내 네트워크 프록시를 관리하여 서비스와 파드 간의 네트워크 요청을 라우팅합니다.
- 컨테이너 런타임 (CRI) : 컨테이너를 실제로 실행하는 sw. 각 노드에서 실행.
- kubelet: 각 노드에서 실행되는 에이전트.
노드 : 가상 서버 / 마스터 노드와 워커 노드
파드 : 컨테이너의 집합.
클러스터: 파드 생성, 관리
애드온:
[ 실습 코드]
kubectl cluster-info --> 쿠버네티스 클러스터의 정보 출력.
Kubernetes control plane -> 마스터 노드
kube-apiserver == 마스터 노드 == 컨트롤 플랜
cmd 관리자 모드로 실행.
cd :\windows\system32
curl.exe -LO "https://dl.k8s.io/release/v1.30.0/bin/windows/amd64/kubectl.exe"
dir kubectl.exe --> 현재 디렉토리에 존재하는지 확인.
whoami
cd c:\Users\508-17\.kube
없으면 mkdir c:\Users\508-17\.kube
scp root@192.168.108.3:/root/.kube/config . --> 원격서버에서 로컬머신으로 파일 복사.
yes
notepad config --> 파일 여는 명령어. / 시스템 설정 정보가 담긴 파일.
어느 위치던 kubectl을 사용할 수 있어야함.
kubectl get nodes --> 클러스터 노드 상태 모니터링
kubectl cluster-info
cd root에 가서도 kubelctl이 되는 것을 확인.
kubectl run nginx --image nginx: 1.14 --> 새로운 파드 생성 / 사용할 컨테이너 이미지
kubectl run nginx2 --image nginx
kubectl get pods --> 실행 중인 파드 상태 조회
pods
po 축약어
이런식으로 다양한 축약어 사용 가능.
창을 하나 더 띄워서 watch kubectl get pods -o wide로 모니터링 가능.
--dry-run : 데모. 실제 생성이 되는 것은 아니고 결과 시뮬레이션.
kubectl describe pod webserver --> webserver pods 정보 조회
-> 10.11.51.71 메모
확인.
실행
kubectl exec webserver -- cat /etc/hostname
kubectl exec webserver -- cat /etc/hosts
IP 주소와 호스트 이름 매핑
kubectl delete pods nginx
-> 이걸로 다 삭제
kubectl get pods -A
-> 모든 네임 스페이스
kubectl get pods -n default
-> default를 가져옴
kubectl get pods -n kube-system
-> 네임스페이스 내의 모든 파드 조회.
kubectl get pods -o yaml --> 네임스페이스 내의 모든 파드를 yaml로 출력
kubectl get pods -o json --> json 형태
kubectl describe pod nginx --> nginx 이름의 파드 정보 제공
kubectl get cm --> 파드의 구성 데이터 저장.
kubectl get pvc
kubectl get namespace --> 모든 네임스페이스 조회
apt install elinks --> 터미널에서 웹 페이지 탐색
elinks http://10.11.51.71
elinks http://localhost:80
kubectl exec -it webserver -- /bin/bash
kubectl describe pods web-apaches-565df8cd7f-cptch
kubectl edit deploy web-apaches
kubectl delete deploy web-apaches
-> 삭제할때 pod가 아니라 deploy role 이름
포트 포워딩 명령체제
kubectl run webserver --image nginx:1.14 --port 80 --dry-run client -o yaml > webserver.yaml
vi webserver.yaml
파드 이름 / 컨테이너 이름
kubectl create -f webserver.yaml --> 최초에 create 그 이후 apply
kubectl apply -f webserver.yaml
최초가 아니라 잇는것
wget kubectl apply -f https://k8s.io/examples/pods/simple-pod.yaml
vi simple-pod.yaml
node1로 이동해서
cd /etc/kubernetes/manifests/
vi static-pod.yaml
kubectl delete -f simple-pod.yaml --> 삭제
selector -> 에 의해 가진 것 모니터링
rc 세개 유지 관리에 사용
labes -> 셀렉터가 수집하는 값을 지정해야 rc가 이 값을 기반으로 관리
matchLabels:
tier: frontend --> key value
스케일링 / 이미지 업데이트 / 파드 삭제 / 정보 확인.
kubectl scale rc nginx --replicas=3 --> 복제본 3으로 조정 / ReplicationController
replicationcontroller/nginx scaled --> 스케일 성공적 완료를 나타냄.
kubectl set image rc nginx nginx=nginx:1.16.1
replicationcontroller/nginx image updated
kubectl delete pods nginx-h8stg --> 파드 삭제 / 새로운 파드로 대체
pod "nginx-h8stg" deleted --> 성공적으로 삭제
kubectl describe pods nginx-c84vc | grep -i 'image'
리플리카셋
mv replication.yaml rs.yaml
vi rs.yaml
kubectl explain rs.yaml
kubectl explain replicaset
<vi rs.yaml>
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: nginx
namespace: default
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
name: nginx
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14
ports:
- containerPort: 80
kubectl apply -f rs.yaml
kubectl get rs --> ReplicaSet 리소스 조회
watch ->
실습 필기 날아갔음 ㅜ^ㅜ 대충 기억나는데로 정리.
kubectl exec -it <pod-name> -- rm /usr/share/nginx/html/index.html
index.html 삭제하면 404 오류가 발생하지만 다른 pod로 라우팅 되는 실습 진행.
로드밸런싱, Deployment
- Deployment는 여러 Pod를 관리하고, Service는 이 Pod들에 대한 로드 밸런싱을 제공합니다.
- index.html 파일을 삭제하면 해당 Pod에서 404 오류가 발생하지만, Service는 다른 Pod로 트래픽을 분산시켜 서비스의 가용성을 유지합니다.
- 이 과정에서 Service의 로드 밸런싱 기능 덕분에 사용자는 계속해서 애플리케이션에 접근할 수 있습니다.
이와 같은 구조를 통해 Kubernetes는 애플리케이션의 가용성을 높이고, 단일 Pod의 문제로 인해 전체 서비스가 중단되지 않도록 보장합니다.