쿠버강의 hands-on _ 3
강의를 쭉 듣다보니까, 어제 내가 괜히 어려웠던게 아니였던 것 같다.
어제 본적도 없는 명령어들을 힌트 봐가면서 구글링을 해가면서 했었는데, 오늘 영상을 보니까 그 내용들이 다 나오는걸 볼 수 있었다 ㅎㅎㅎ
실습이 쭉 이어져있어서 배운 내용보다 더 많은 내용을 실습을 한것 같다.
그래도 실습을 해본 다음에 강의를 들어서 그런가 강의도 쭉쭉 잘 들렸고 이해도 잘 됐다
강의를 마저 들은후에 다시 실습을 진행했을때, 어제랑 다르게 무리 없이 잘 넘어가는것이 기분이 좋았다.
Pods
앱의 단일 인스턴스로, 쿠버네티스에서 만들수 있는 가장 작은 단위
보통 컨테이너와 포드는 1대1 상관관계를 가지고 있음
=> 사용자가 늘어나서 추가적으로 필요하다면, 한 포드내에 컨테이너를 더 추가하는 것이 아니라, 포드를 하나 더 추가함
=> 이런 식으로 말이다 | 기존 포드에 컨테이너를 추가하지 않음(같은 종류의)
=> 하지만 도우미 컨테이너는 같이 있을 수 있음
=> 물론 메인인 컨테이너가 죽으면 도우미 컨테이너(helper)도 같이 다운됨
+ 둘은 같은 네트워크를 공유하기 때문에 서로를 localhost취급하며 / 같은 저장공간을 공유함
앱 컨테이너의 상태를 모니터링 하기 위해서
+
'앱과 헬퍼컨테이너'가 어떤 것들이 연결되어있는지 알기위해서
+
'앱과 핼퍼 컨테이너'가 같은 공간을 공유하기 위해서
=> pod 사용함 => 구성을 정의
==> 쿠버네티스가 후속 처리를 알아서 해줌
ex)헬퍼가 죽으면 새로운 헬퍼를 붙여준다거나 하는 행동들
=> ++ 앱이 죽으면 헬퍼를 같이 죽이는 것(앱과 핼퍼 컨테이너의 상태를 동기화? 하는 것 같음)
ocker run python-app
docker run python-app
docker run python-app
docker run helper -link app1
docker run helper -link app2
docker run helper -link app3
==> 대략적으로 이런식으로 사용함
kubectl => k
배포방법
k run nginx --image=nginx(docker hub에 등록되어있는 이미지여야함)
=> docker hub 리포지토리에서 다운로드
pod 자동생성 + nginx 도커 이미지 인스턴스 배포
k get pod
pod 확인
=> 간단한 pod들의 정보를 볼 수 있음 => 실습에서는 보통 pod의 개수, 이름, read상태의 컨테이너가 몇개인지 / 총 컨테이너가 몇개인지 확인할떄 사용을 했었음
**
어제 진짜 혼자 해보느라고 많이 헤맸는데 강의를 들으니까 궁금했던 부분들이 많이 풀리는 기분이 들었음
kube get ~(구성요소) -o wide
=> 얻을 수 있는 정보에 추가적인 정보를 제공
관련된 상세하고 추가적인 정보를 얻기 위해서는 describe를 사용함
controlplane ~ ➜ k describe pod
Name: nginx
Namespace: default
Priority: 0
Service Account: default
Node: controlplane/192.4.161.3
Start Time: Sat, 14 Oct 2023 03:14:41 +0000
Labels: run=nginx
Annotations: <none>
Status: Running
IP: 10.42.0.9
IPs:
IP: 10.42.0.9
Containers:
nginx:
Container ID: containerd://352641aea8a15958f29111c16bfc9a3f51bef93bd3da846e5533ae0373d5e013
Image: nginx
Image ID: docker.io/library/nginx@sha256:b4af4f8b6470febf45dc10f564551af682a802eda1743055a7dfc8332dffa595
Port: <none>
Host Port: <none>
State: Running
Started: Sat, 14 Oct 2023 03:14:48 +0000
Ready: True
Restart Count: 0
Environment: <none>
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-9zchr (ro)
Conditions:
Type Status
Initialized True
Ready True
ContainersReady True
PodScheduled True
Volumes:
kube-api-access-9zchr:
Type: Projected (a volume that contains injected data from multiple sources)
TokenExpirationSeconds: 3607
ConfigMapName: kube-root-ca.crt
ConfigMapOptional: <nil>
DownwardAPI: true
QoS Class: BestEffort
Node-Selectors: <none>
Tolerations: node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 10m default-scheduler Successfully assigned default/nginx to controlplane
Normal Pulling 10m kubelet Pulling image "nginx"
Normal Pulled 10m kubelet Successfully pulled image "nginx" in 5.440852227s (5.440879881s including waiting)
Normal Created 10m kubelet Created container nginx
Normal Started 10m kubelet Started container nginx
=> 굉장히 다양한 정보들을 얻을 수 있고, event를 통해서 과정을 살펴볼 수 있음
=> 만약에 문제가 생긴다면 문제에 대한 해결방안도 에러를 통해서 찾아볼 수 있음
https://kubernetes.io/docs/concepts/
https://kubernetes.io/docs/concepts/workloads/pods/
=> 관련 설명들
yaml
키 : 값 형태의 언어임
=> 종속 관계? 올바른 형식의 구분을 띄어쓰기로 함
==> 부모/자식의 관계로 생각하면 편할듯함
==> 부모와 자식이 동일한 선상에 있으면 안되며, 동일한 선상에 있는 것들은 같은 속성의 것들이여야함
같은 속성을 쭉 나열하기 위해서 list를 사용하고
- a
- b
- c
- d
list에서 상/하위 속성들에 대한 정리가 필요하거나 하면 dictionary를 사용하는게 효과적임
alphabet:
- a
order: 1
- b
order: 2
- c
order: 3
- d
order: 4
dictionary : 선별되지 않은 컬렉션
unordered correction
=> 순서에 영향을 받지 않음
list : 선별된 컬렉션
ordered correction
=> 순서에 영향을 받음
주석 : #
yaml파일 실습
=> 이런식의 간단한 지침을 수행하는 실습을 하는 것임
=> yaml 파일의 구조를 익히는데 도움이 될 수 있을 듯 함
=> 기존에 존재하는 테이블 형태의 데이터를 이용해서 이런걸 만드는 스크립트도 있고
문제
내가 생각한 답
정답
=> 같은 속성에 대한 나열을 할때는 무조건 리스트를 사용하고 그 하위에 속성에 대한 걸 다시 딕셔너리 적는것 같음
문제에서 각 payslips이 month랑 wage를 둘다 가지고 있어야 해서 이런식으로 적어준것 같다는 생각이 들었음
===>
쿠버에서 yaml파일은 pod, replica, deployment, service, 등등 생성을 위해서 사용됨
=> 항상 이 4개의 최상위 필드를 지님 => 필수적으로 있어야함
=> 구성할때 무조건 들어가야 한다는 것
apiVersion
=> 쿠버네티스티 api버전을 지정
metadata
=> 딕셔너리 형태로 쓰여지는데, 속성 앞의 공백의 개수는 상관이 없지만, 같은 속성의 것들과는 동일해야함
label은 메타데이터 안의 딕셔너리임 => 원하는 대로 키:값의 쌍을 지닐 수 있음
metadata의 하위에는 아래에 오기로 지정된 것들만 올 수 있지만. label밑에는 아무거나 와도 상관이 없음
spec => 말그대로 스펙에 대한 내용을 담고 있음
=> 무슨 이미지. 무슨 ~ 를 사용했는지에 대해
==> 당연하게도 dictionary임
=> 컨테이너는 여러개가 속할 수 있기 때문에 리스트/배열의 형태를 띄고 있음
- 하나당 하나의 컨테이너가 존재한다고 생각하면 편함
위에 한번 써놨지만, 정리를 해보자면
kubectl create -f ~~~작성한파일~~~.yml
=> 쿠버네티스가 작성한 .yml파일을 가지고 pod을 생성함
kubectl get pod
=> 기본정보 - 이름 / 준비상태 / 상태 / 실행시간 등등
kubectl describe pod 'pod이름'
=> 문제에서 좀 더 자세한 설정에 대한것을 물어볼때 사용하면 됨 어제 문제를 풀때도 애용했던 명령어
.yml 파일을 텍스트 편집기 아무거나 이용해서 작성 할 수 있음
apiversion: v1
kind: Pod
metadata:
name: nginx
labels:
app: nginx
tier: frontend
spec:
containers:
- name: nginx
image: nginx
- name: busybox
image: busybox
=> 여러개면 ㅇ이런식으로 적으면 됨
==> 여기서 만약 Docker hub말고 다른 저장소를 사용한다면 그것으로 향하는 전체경로를 다 적어놓아야함
=> 그게 아니라면 그냥 이렇게 적으면 됨
*** 새로운 pod을 생성할때는 kubectl apply / create 두개가 동일하게 작동함
적용 생성
apply같은 경우는 vi / edit을 통해서 편집한 내용을 적용하기 위해서 사용할것 같은 생각이 듬
위의 명령어를 통해서 생성하고
kubectl get pod
=> 확인
kubectl desribe pod nginx
=> 자세하게 확인
.yaml 작성툴
잘 작성할줄 안다면 아무곳에서나 작성해도 상관없지만, 또 잘 작성한다면 => 더 효율적으로 작성하는게 좋기 때문에 관련 툴을 추천해줬음
=> visual code => phyton / django 수업을때 사용했던거라 무리 없이 사용할 수 있을듯함
=> yaml파일 작성을 도와주는 확장
스키마 설정 => .jason
=> 대소문자 구문해서 작성할 수 있음
=> 설정해주고 재실행해야함
ctrl + p => 파일에 접근 가능
=> 데모때 작성했던 yaml 내용을 가지고 파일을 만들어서 넣어놓음
이걸 통해서 작성하니까 확실히 자동완성에 대한 부분도 그렇고, 잘못된 부분에 대해서 집어주기 때문에 편하다는 생각이 들었음
왼쪽에 있는 outline을 통해서 파일에 들어있는 요소들에 대한 구조를 확인가능하고, 오류찾는게 조금이나마 더 수월함
가장 보편적인 형태라고 설명을 해줬음
apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
spec:
containers:
- name : nginx
image: nginx
이렇게 문제가 나왔을때, 작성할 줄 알아야함
=> 비밀번호에 대한 내용을 새로 넣으라는건데.. 이건 강의에서 배운 부분이 아니라서 좀 헤맸다
apiVersion: v1
kind: Pod
metadata:
name: postgres
labels:
tier: db-tier
spec:
containers:
- name: postgres
image: postgres
env:
POSTGRES_PASSWORD: mysecretpassword
=> 일단 첫번쨰 답 => 틀림
spec:
containers:
- name: postgres
image: postgres
- env:
POSTGRES_PASSWORD: mysecretpassword
=> 두번째
spec:
containers:
- name: postgres
image: postgres
env:
- name: POSTGRES_PASSWORD
value: mysecretpassword
=> 답
공부..열심히..
k delete pod webapp
=> webapp이라는 pod를 삭제해라
| -> 이 뒷부분을 보고 처음에는 굉장히 당황을 했는데, 강의에서 말하는 내용을 보니
k run redis --image=redis123 --dry-run=client-o yaml
=> 그니까 실제로 만들지 말고 돌렸을때 어떤 결과값이 나오는 지만 출력해라 yaml의 형태로
=> 이거를 > 명령어를 통해서 .yaml파일로 만들어준거고
k run redis --image=redis123 --dry-run=client-o yaml > redis.yaml
=> dry-run -> 일종의 결과에 대한 미리보기 -> 를 redis.yaml 파일로 작성해라
이미 만들어진 pod을 변경하는 법 => k edit / vi