기타/K8S
udemy)CKA 강의 듣고 따라하기_2장_핵심개념 :: mightytedkim
MightyTedKim
2022. 3. 26. 15:01
728x90
반응형
+ 후기
기간 : 20220322 ~ 20220326 (5일)
이번 챕터는 문제만 풀고 넘어가도 괜찮았을 것 같다.
특별히 모르는 개념은 없었지만, 그래도 복습한다는 기분이 느껴져서 좋았다 ㅎ
10 ~ 18
- master, worker, control_plane, scheudler, etcd, kube-apiserver 등을 하나씩 알려줘서 좋음
- 설치할 대 따라하기만 했는데, 개념을 알고 다시 보니까 이해도가 높아졌다.
20 ~ 46
- 복습한다는 느낌으로 봤는데, 명령어들에 익숙한 사람들이면 스킵해도 될 것 같다. 나는 아래 정보들을 얻어서 좋았다.
- label selector matchlabel
- replicacontroller vs replicaset -> replicaset이 최신
- service loadbanacer -> 설명이 부족해서 아쉬웠음
- k run --dry-run -> 실행하지 않고 yaml을 얻을 수 있다는 게 꿀팁
Core Concepts 40 lectures • 2hr 57min
8. Core Concepts Section Introduction Preview00:30'
이 부분은 쉽기 때문에, 익숙한 사람들은 테스트 문제로 바로 넘어가라고함
하지만 난 다 들어야함 ㅜ
야매 구글링으로 배워가지고
9. Download Presentation Deck for this section 00:05
pdf download link
10. Cluster Architecture Preview08:48
k8s는 컨테이너 환경에서 여러 서비스를 운영하는 것을 목적으로 함
[master node] : control ship : 모니터, 커뮤니케이션을 담당함, control plane component를 사용
- ETCD Cluster : key value 형식으로 데이터를 저장하는 data base
- kube-scheduler : 컨테이너를 특정 노드로 할당하는 객체
- controller-manager: 컨테이너의 상태를 확인하고, 재실행하는 서비스
- node controller : node
- replication-controller : replication
- [kube-apiserver] : 모든 객체들을 통신하도록 관리함. 모든 요소가 컨테이너 호환되도록 지원함.
- [kubelet] : cluster의 각 node에서 실행되는 선장같은 존재, kube-api와 통신하면 container를 생성/파괴하는 역할을 함
- [kube-proxy] : worker node끼리 통신할 수 있게 됨
- container runtime engine : ex) docker, containerd, etc
11. ETCD For Beginners 03:02
> distributed reliable kvalue store
기존 db는 row, column으로 구성됨
key value는 1:1 대응함, key는 unique 함.
빨라서 설정값들 관리할 때 많이 사용함
12. ETCD in Kubernetes 03:16
> 2가지 설치 방법이 있음
cluster의 정보들을 저장함. nodes, pods, configs, secrets, accounts 등
cluster 설정에 따라 다르게 배포됨
1. scratch
- wget etcd binary
-- advertise-client-url : 내부 IP 설정이 되어야함
2. kubeadm tool
- pod로 배포가능. -n kube-system etcd-master
- k exec etcd-master -n kube-system etcdctl get / --prefiex -keys-only
- etcd.service -> --initial cluster controller-0=0_ip:2380,controller-1=1_ip:2380 \
13. ETCD - Commands (Optional) 00:57
> cli툴도 있음
etcdctl 이라는 cli xnfdl dlTdma
버전2, 3 이 있는데, 각각 명령어가 좀 다름
export ETCDCTL_API=3 으로 설정 가능(default=2)
#3
etcdctl snapshot save
etcdctl endpoint health
etcdctl을 위해서 인증도 설정해야함
--cacert /etc/kubernetes/pki/etcd/ca.crt
--cert /etc/kubernetes/pki/etcd/server.crt
--key /etc/kubernetes/pki/etcd/sever.key
14. Kube-API Server 04:50
> kube-api가 핵심임. 각 객체들이 통신하는데 api를 사용함
kubectl을 생각하면 되는데, post 방식으로 요청을 보낼 수 도 있음
ETCD와 직접적으로 접촉함
pod 생성 순서
1. authenticate user
2. validate request
3. retrieve data -> api로 pod 생성 명령어 인식
4. update ETCD -> 상태 업데이트 (아직 node 할당 안됨)
5. scheduler -> node 할당 되어있지 않다는 것을 체크하고, api-server에 요청보내면 worker node의 kubelet에 요청
6. kubeletet -> container runtime engine에 image로 pod 만듦
+ update etcd -> 상태 업데이트
kubeapiserver.service의 설정
-etcd-cafile, etcd-certfile, etcd-keyfile
-kubelet-certificate-authority, kubeletpclient-certificate, kubelet-client-key, kubelet-https
-etcd-servers=https://127.0.0.1:2379
#kubeadmin
-n kube-system kube-apiserver-master
15. Kube Controller Manager 04:14
> controller는 모니터링하고, 조치를 취하는 역할을 함
역할
- Watch Status
- Remediate Situation
[대표1]Node-controller
> kube-apiserver와 체크
# node monitor period = 5s
$ k get nodes
worker-1 Ready
# node monitor grace period=40s
worker-2 NotReady
# POD Eviction Timeout = 5m
[대표2]Replication-controller
> pod가 죽으면 새로 띄움
+ Deployment, Namespace, CronJob, Stateful-Set, PV-protection etc
kube-Controller-Manager 보는 방법
- kube-controller-manager.service -> 커스텀 가능함
- controller 가 만약 없다면 여기를 보는 방법 추천
$ k get pod -n kube-systm kube-contoller-manager-master # kube-controller-manager.yam
16. Kube Scheduler 03:52
> 어느 POD가 어느 Node에 갈지만 결정함. 직접 위치시키지는 않음, 위치시키는 작업은 Kubelet
node에 위치시키는 기준
- pod 요구사항 -> cpu 10
1. filter Nodes : cpu 부족한 node 제외
2. rank Nodes : 적용후 남는 리소스가 많은 순으로 랭킹
#kubeadmin
#-n kube-system kube-scheudker
17. Kubelet 01:42
> worker node의 컨택 포인트 및 관리자
역할
1. Register node
2. create node
3. monitor node, pod
#kubelet 은 항상 직접 설정해야함. kubeadm이 직접 설치해주지 않음
# kubelet.service
18. Kube Proxy 03:41
> POD Network를 이용해서 다른 worker들이 통신할 수 있음
작동 방식
- service를 이용해 ip를 할당받아 노출함 -> 내부 네트워크에서 활용하는 것으로 K8s 메모리에서 살아있음
- kube-proxy는 각 node에서 실행되고, 새로운 서비스가 생성되면 각 노드에도 업데이트가 됨
- iptable rule을 이용해서 forwarding을 진행함
$ k get pods -n kube-system
$ k get daemonset -n kube-system
19. Recap - PODs 09:12
> k8s 가 다루는 가장 작은 단위
보통 pod와 container는 1:1
- multi-container pods 도 있음 -> helper containers
* 맞음 log 보려고하면 container 선택하라고 함
$ k get pods
# ContainerCreating, Running
$ k exec pod *** -- bash
20. PODs with YAML 07:04
> yaml 작성하는 방법
- metada와 spec의 name/label은 같아야함
- label -> 사전 (key: value)
- metadata > name, labels
- spec > containers: - , - , -
$ k create -f *.yaml
$ k get pod
$ k describe pod my-pod
21. Demo - PODs with YAML 06:17
> yaml 적는 방법 알려줌
contianers에 복수의 값을 입력할 수 있음
22. Practice Test Introduction Preview 05:51
> demo 사이트 사용법 소개
23. Demo: Accessing Labs 02:55
> demo 사이트 사용법 소개 2
24. Accessing the Labs 00:14
> demo 사이트 사용법 소개3
Link: https://uklabs.kodekloud.com/courses/labs-certified-kubernetes-administrator-with-practice-tests/
Apply the coupon code *****
25. Practice Test - Pods 00:01
> 사이트에서 테스트 진행
26. Practice Test - Solution (Optional) 07:39
> 틀린거 없어서 패스
27. Recap - ReplicaSets 16:09
> HQ + loadbalancing & scaling
1. HA
replica가 필요 이유 - pod 죽을 때 대비
pod가 1개여도 가능 - 바로 교체하는 방식으로
2. load balancing & scaling
* replication controller(old), replicaset(new)
$ k get replciationcontroller
apiVersion: v1
kind: ReplicationController
spec.template에 pod를 넣는 방식임(api, kind 제외하고)
spec.template.spec (spec이 두개임)
spec.replicas: 3
$ k get replicaset
appVersion: apps/v1
Kind: ReplicaSet
spec.template에 pod를 넣는 방식임(api, kind 제외하고)
spec.template.spec (spec이 두개임)
spec.replicas: 3
selector.matchLabels.type: (어느 pod인지 명시적으로 표현)
label, selectors 사용 이유
ex) pod가 3개가 있음, replicaset으로 관리하고 있음
- 수백개의 pod가 있을 때 어떤 pod를 볼지 filter할 수 있음
- 이미 해당 label의 pod가 있으면, Replicaset이 새로 만들지 않지만 미래의 fail에 대비할 수 있음
$ k replace -f replicaset-definition.yml
$ k scale --replicas=6 -f replicaset-definition.yml
$ k scale --replicas=6 -f replicaset myapp-replicaset
28. Practice Test - ReplicaSets 00:04
> 문제 품
29. Practice Test - ReplicaSets - Solution (Optional) 07:45
> 모르는 문제 없었음
30. Deployments 04:26
> replicaset과 비슷하지만 상위 개념
deployment > pod > replicaset
- rollingupdate, pause 등의 기능을 화용할 수 있음
같은 ns에 있으면 service 이름으로 접근할 수 있음
- ns : default
- service-name : db-service
다른 ns에 이어도 접근가능하지만 규칙이 있음
- db-service.dev.svc.cluster.local
- (service-name).(ns).(service).(domain)
$ k get pods -A
default ns를 바꾸는 방법이 있음
$ k config set-context $(kubectl config current-contex) --namespace=dev
Resource Quota
- limit resource in namespace
| apiVersion: v1 kind: ResourceQuota metada: name: compute-quota namespace: dev spec: hard: pods: "10" requests.cpu: "4" requests.memory: 5Gi limits.cpu: "10" limits.memory: 10Gi |
31. Certification Tip! 01:07
> kubectl run 명령어 알려줌
32. Practice Test - Deployments 00:03
> 문제 품
33. Solution - Deployments (optional) 05:07
> 모르는거 없엇음
34. Namespaces 08:22
> 리소스를 격리하는 범위
$ k get ns
kube-system, kube-public, Default
35. Practice Test - Namespaces 00:04
> 문제품
36. Solution - Namespaces (optional) 05:03
> 모르는거 없엇음
37. Services 13:50
> 외부 접근 가능하도록 설정하는 서비스
종류
1. NodePort
- port(서비스) vs targetport(컨테이너)
- 3000 - 32767
- selector를 이용해 pod와 연결
2. ClusterIp (내부)
3. Loadbalancer (분산)
운영환경에서는 pod가 여러개 있음
- 모두 같은 label을 가지고 있음
38. Services Cluster IP 04:01
> cluster안에서 통신할 수 있도록 해주는 것이 cluster ip
pod의 IP는 언제든 초기화될 수 있음.
single interface가 필요함.
- svc의 default
39. Services - Loadbalancer 03:42
> single endpoint를 만들 수 있는데, cloud에서 제공하는 기능 사용하라 이야기해줌
nodeport가 많으면 관리가 안되니, single-url이 필요함
loadbalancer가 이 역할을 해줌
cloud 사용하면, load-balancer 쉽게 구현할 수 있음 (난 온프렘인데 ㅜ)
40. Practice Test - Services 00:01
> 문제품
41. Solution - Services (optional) 05:00
> 모르는 거 없었음
42. Imperative vs Declarative 13:05
> 직접 vs 선언
infa를 관리하는 2가지 방법
imperative : kubectl run, create, scale, edit, expose, set, replace, delete
> history가 남겨지지 않아서, 관리가 힘듦
declatrative: k apply -f nginx.yaml
43. Certification Tips - Imperative Commands with Kubectl 02:03
> dry-run config 설명
대부분 declarative 방법을 사용할거임
참고하며 좋은 명령어들이 있으
-o yaml -> yaml 볼 수 잇음
--dry-run -> 바로 적용됨
--drt-run=client -> 테스트를 해볼 수 있음, 실제 만들어지지는 않음
kubectl vs yaml
예시)
kubectl run nginx --image=nginx --dry-run=client -o yaml
kubectl create deployment --image=nginx nginx --dry-run=client -o yaml
kubectl create deployment nginx --image=nginx --dry-run=client -o yaml > nginx-deployment.yaml
참고
44. Practice Test - Imperative Commands 00:05
> 처음으로 헷갈렸음
kubectl run --help
kubectl create --help
를 이용해서 커닝하.
pod는 create 가 아닌 run으로 실행해야한다는 것을 배움
- 이 부분으 docker와 똑같음
45. Solution - Imperative Commands (optional) 07:52
> 다른 풀이법을 보고 도움이됨
Expose 80에서
정답: k run httpd --image=httpd:alpine --port 80 --expose
내답: k run svc clusterip httpd --tcp=80:80
46. Kubectl Apply Command 04:38
> 내가 좋아하는 명령어
last applied configuration이 json형식으로 저장됨
- 현재 적용하느 설정 파일과 비교해서 적용함
Here's some inspiration to keep going Preview00:00
728x90
반응형