controller
두뇌 => 모니터링하고 그에 따라 반응하는 프로세스
일단은 복제 컨트롤러
복제컨트롤러 replication controller
앱에대한 고가용성을 통해서 서비스의 연속성을 유지하기 위해서
복제본을 사용하는 개념 같은데
=> 이런식으로 한 노드 안에서 여러개의 pod을 사용해서 하는 방법도 있고
포드를 한개만 사용하려한다면
=> 포드가 다운됐을떄, 복젝본을 이용해서 새로운 pod를 불러오는 방식도 있음
=> pod의 개수는 상관이 없다는 것임
=> 여러 노드에 걸쳐서 사용될 수도 있어서, 로드밸런싱 및 스케일링에 도움을 줌
replicaton controller | replicaset
apiVsersion
: v1 apps/v1
=> 용도는 같음
=> controller가 오래된것 -> replica set으로 교체되고 이씅ㅁ
replication controller
=> 레플리카의 spec영역 안에는 내가 복제할 pod에 대한 상세 내용들이 들어가있어야함(metadata / spec)
=> 그리고 이 내용들은 레플리카의 spec아래의 template의 자식속성이여야함
==> 두개의 metadata 와 spec이 존재함
replica controller의 속성 -> 부모
pod의 속성 -> 자식
=> 이렇게 개수도 지정을 해줘야하는데, 개수도 물론 spec의 하위 속성임
k create -f 파일명.yaml
=> replica controller 생성 ===> 당연히 자연스럽게 이것들이 담겨있는 pod도 생성이 된 것임
k get replicacontroller
k get pod
모든 pod의 이름이 복제 컨트롤러 yml에서 지정해준 myapp-rc로 시작하는걸보니, replica controller에 의해서 만들어진것을 알 수 있음
replicatset
apiVersion이 틀리면 이렇게 오류가 나올 가능성이 큼
기본 v1은 replicaset을 지원하지 않기 때문에ㅔㅔ
controller와 다르게 selector라는 부분을 필수적으로 작성해줘야함
레플리카세트는 pod의 상태를 모니터링하기 위해서 사용함
=> 수 많은 pod중에서 필요한 것들에 대한 모니터링을 잘 수행하기 위해서 라벨링한 정보를 지정하는것임
=> 이건 controller랑 똑같음
scaling
1)
vi / edit => relicas : n 으로 변경
k replace -f ~~~~~~~.yml
=> 복제본의 숫자가 변경됨
2)
k scale --relicas=n -f ~~~~~~~~.yml
=> 복제본의 숫자를 짖어한대로 적용하고 동일하게 작동
++
3)
k scale --relicas=n relicaset(type) ~~~~~(set name)
=> 이렇게 지정해줄 수도 있지만, 파일을 통한 자동 업데이트는 불가능함
=> 아 그니까 이말이 파일을 고쳐주는게 아니라 명령어를 통해서 지정해주는거는 파일을 바꾸는 게 아니라서 파일을 통한 무언가를 하면 바꾼내용이 계속 적용되지 않는다거나 그런말을 하는거구나, 방금 해본거 마지막처럼 apply 하면 다시 원래대로 돌아온다는 ㅇㅇㅇㅇ ㅇㅇㅇㅇㅇ 이해해씅ㅁ
이걸 실제로 해보자고
=> 지금 3개지?
4개
파일은 그대로 ㅇㅇ
=> 이것도 잘되긴하는데 자동 업데이트에 대한 명령은 받지 못한다는거지..? 파일에 따른
code를 통해서 파일을 작성하고, terminal에서 확인
replicaset가 항상 충분한수의 복제본 / 포드를 제공
이제 pod 하나를 삭제해볼 것임
지웠음에도 여전히 3개이고 지운 이름의 Pod는 없는것이 보임
=> 로그를 확인해보면 처음 3개가 만들어지고, 하나를 지운 뒤 새롭게 하나가 생성된것을 볼 수 있음
=> 실행된 레플리카세트가 하나여서 그냥 검색해도 됐지만, 여러개가 있으면 이름도 추가해서 해줘야함
이제 같은 라벨이 달린 pod를 생성해볼것임
=> pod이 생성됐지만, 돌아가지않는것을 볼 수 있음
=> 보려했더니 바로 종료 시켜버림 => 지정된 pod의 개수가 3개라서 그럼
==> 같은 라벨이 달린 pod는 다 관리하는것을 알 수 이씅ㅁ
edit으로 열게되면 vim으로 열리는데 실제 파일을 여는것이 아니라 쿠버가 메모리에서 만든 임시 파일로 개체를 수정할 수 있게 만들어놓은것임 => 실제로 작성한거보다 많은 구성요소들이 있는것을 볼 수 있음 => 그래서 변경할때 조심해야함
내가 vi로 파일을 변경해서 apply를 했을때는 지정한 숫자만큼 바로 pod가 생성되서 의미가 없긴했음 ㅇㅇ.. pod수 늘려보려했는데 ㅇㅇㅇ
=> 근데 이것도 마찬가지네 ㅋㅋㅋ / 명령어들도 위에 쓴거보면 바꾸자마자 pod개수 쭉쭉늘ㄹ던데
이제 코딩 데모
굵은 글씨가 내가 삽입해야하는 내용들이구나 ㅇㅎ
get ~~~ -o wide => 무슨 이미지를 사용했는지도 나옴 ㅇㅇ
=> 이 문제가 나왔을 떄
controlplane ~ ➜ k describe replicaset new-replica-set
Name: new-replica-set
Namespace: default
Selector: name=busybox-pod
Labels: <none>
Annotations: <none>
Replicas: 4 current / 4 desired
Pods Status: 0 Running / 4 Waiting / 0 Succeeded / 0
=> 작동안되는것 을 볼 수 있었고
Failed
Pod Template:
Labels: name=busybox-pod
Containers:
busybox-container:
Image: busybox777
Port: <none>
Host Port: <none>
Command:
sh
-c
echo Hello Kubernetes! && sleep 3600
Environment: <none>
Mounts: <none>
Volumes: <none>
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulCreate 2m5s replicaset-controller Created pod: new-replica-set-rbvnj
Normal SuccessfulCreate 2m5s replicaset-controller Created pod: new-replica-set-5r7mh
Normal SuccessfulCreate 2m5s replicaset-controller Created pod: new-replica-set-l7jjj
Normal SuccessfulCreate 2m5s replicaset-controller Created pod: new-replica-set-82tng
controlplane ~ ➜ k get pod
NAME READY STATUS RESTARTS AGE
new-replica-set-rbvnj 0/1 ImagePullBackOff 0 2m25s
new-replica-set-5r7mh 0/1 ImagePullBackOff 0 2m25s
new-replica-set-82tng 0/1 ImagePullBackOff 0 2m25s
new-replica-set-l7jjj 0/1 ImagePullBackOff 0 2m25s
=> 상태각 메롱한것을 봤음
=> 그래서 pod를 확인함
controlplane ~ ➜ k describe pod
State: Waiting
Reason: ImagePullBackOff
Ready: False
Restart Count: 0
Environment: <none>
Mounts:
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 3m14s default-scheduler Successfully assigned default/new-replica-set-l7jjj to controlplane
Normal Pulling 100s (x4 over 3m13s) kubelet Pulling image "busybox777"
Warning Failed 100s (x4 over 3m13s) kubelet Failed to pull image "busybox777": rpc error: code = Unknown desc = failed to pull and unpack image "docker.io/library/busybox777:latest": failed to resolve reference "docker.io/library/busybox777:latest": pull access denied, repository does not exist or may require authorization: server message: insufficient_scope: authorization failed
=> 이미지를 찾지 못해서 에러가 발생하는것을 알 수 있었음
Warning Failed 100s (x4 over 3m13s) kubelet Error: ErrImagePull
Warning Failed 88s (x6 over 3m13s) kubelet Error: ImagePullBackOff
Normal BackOff 73s (x7 over 3m13s) kubelet Back-off pulling image "busybox777"
생성을 하려고 했더니 오류가 떠서 들어가서 이유를 찾아봄
=> replicaset 은 apps/v1에서 돌아감
다음 문제
=> 이미지를 바꾸고 지우거나, 새로만들어서 업데이트하라는데, 지금 있는 파일에 이 레플리카셋 관련된 파일이 없었기 떄문에 edit을 사용하기로 판단
k explain ~~~ ex) replicaset ===> 관련 정보
를 알 수 있음 물론 버전도
=> yml파일에 문제가 있을떄는 그냥 생성해보고 -> 오류를 보고 파일로 들어가서 고치는게 효율적인가보네 ==> 선생님이 그런 방식을 사용하네
** 그니까 selector에 있는 matchLabels = 만들려고 하는 템플릿의 labels
가 무조건 되어어야함 다른건 상관없음
replicaset => rs
replicaset의 옵션을을 변경했을떄 pod은 자동으로 재생성 되지 않음 => 따로 만들어줘야허ㅏㅁ
아 그리고 ㅅㅂ 리눅스에서 하듯이 k delete pod pod1 pod2 pod3 pod4
이렇게 지워도대네 ㅋㅋㅋㅋㅋㅋㅋ
deployment
롤링업데이트 : 여러개의 서버를 한번에 업데이트하는게 아니라, 하나씩 차근차근 업데이트하는것
롤백 : 업데이트 버전에 문제가 생겼을떄 이전버전으로 다시 되돌리는것
파일 형식 자체는 replicaset와 크게 다르지 않음
=> 배포가 더 상위의 개념이기 때문에, 배포를 생성하면 replicaset는 자동으로 생성됨
===> replicaset를 생성하면 pod가 자동으로 생성되는것 처럼 ㅇㅇㅇ
k get all
=> 최상위인 deploy => replicaset => pod까지 모든걸 다 보여줌
deployment demo
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp-deployment
labels:
tier: frontend
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: myapp
template:
metadata:
name: nginx-2
labels:
app: myapp
spec:
containers:
- name: nginx
image: nginx
=> 잘 생성된것을 볼 수 있음
]
=> 생성된 모든것에 대한 대략적인 정보를 가져올 수 있음
강의 코딩 테스트를 통해 작성한 코드
apiVersion: apps/v1
kind: Deployment
metadata:
name: frontend
labels:
app: mywebsite
tier: frontend
spec:
replicas: 4
template:
metadata:
name: myapp-pod
labels:
app: myapp
spec:
containers:
- name: nginx
image: nginx
selector:
matchLabels:
app: myapp
kind는 무조건 대문자로 시작해야함
=> 그리고 나는 그냥 문서를 작성해서 해버렸지만, 문제에서 원하는건 그게 아닝엿음
k create deployment httpd-frontend --image=httpd:2.4-alpine --replicas=3
controlplane ~ ➜ k describe deployment
Name: httpd-frontend
Namespace: default
CreationTimestamp: Mon, 16 Oct 2023 04:35:26 +0000
Labels: app=httpd-frontend
Annotations: deployment.kubernetes.io/revision: 1
Selector: app=httpd-frontend
Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 25% max unavailable, 25% max surge
Pod Template:
Labels: app=httpd-frontend
Containers:
httpd:
Image: httpd:2.4-alpine
Port: <none>
Host Port: <none>
Environment: <none>
Mounts: <none>
Volumes: <none>
Conditions:
Type Status Reason
---- ------ ------
Available True MinimumReplicasAvailable
Progressing True NewReplicaSetAvailable
OldReplicaSets: <none>
NewReplicaSet: httpd-frontend-5497fbb8f6 (3/3 replicas created)
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ScalingReplicaSet 38s deployment-controller Scaled up replica set httpd-frontend-5497fbb8f6 to 3
deployment - update & roll back
roll out
versioning
=> 상태 / 히스토리
배포전략
- 원래 버전의 배포 인스턴스 다운 => 새 버전의 인스턴스 생성/실행
===> 다운 타임이 길어짐
===> recreate => 기본적인 전략은 아님
- 하나씩 내리고, 올리고를 반복함 => 앱이 다운되지 않음
===> 기본적인 전략임
k apply -f ~~.yaml => 변경한 내용을 가지고 배포
=> 롤링 업데이트의 과정을 볼 수 있엇음
k rollout undo deployment/~~~배포 이름
=> 관련 명령어들
demo
==> 생성되는 과정을 확인할 수 있었음
이번에는 기록하는 옵션을 통해서 제대로 기록이 남게해봤음
=> 확인
=> 오래된것이 없어지고, 새로운 것이 생성되는것을 볼 수 있음
k set iamage deployment 배포 이름 nginx=nginx:1.18-perl --record
=> 이런식으로 이미지를 지정해줄 수도 있음
k set image deployment myapp-deployment nginx=nginx:1.18-perl --record
k rollout undo deployment/myapp-deployment
2번이 없어진것을 볼 수 잇음 => 2번과 지금 4번이 같은 내용이기 때문에
k set image deploy frontend simple-webapp=kodekloud/webapp-color:v2
networking
=> 미니 큐브
kube => pod에 ip가 할당됨
=> 같은 ip를 사용하면 안됨 당연하게도 충돌이 발생함
=> 다른 대역을 잡아서 라우팅을 진행
'도커 & 쿠버 > CKA를 취득하자' 카테고리의 다른 글
| 쿠버강의 hands-on _ 6 (0) | 2023.10.18 |
|---|---|
| 쿠버강의 hands-on _ 5 (0) | 2023.10.17 |
| 쿠버강의 hands-on _ 3 (0) | 2023.10.13 |
| 쿠버강의 hands-on _ 2 (0) | 2023.10.12 |
| 쿠버강의 hands-on _ 1 (0) | 2023.10.11 |
