데센프 11주차 5/25, 27

[월: 컨트롤러]

노드 포트란 것이 있었는데 이것 관련한 개념?이 인그레스

맥은 버추얼박스 말고 VMware Fusion이란 소웨가 있따,

하이퍼키트 HyperKit: 도커 밑에도, 위에도 있는 도커 머신의 일종.

7: 얌파일 속 상태가 desired state = IaC. observed state 도 desired state 로 맞춰준다! 컨트롤러가 무슨 역할 하는지 설명하도록 하겠다

8: 로거는 로거를 만든다..?

9:

마운트 : 외부 장치를 갖고와서 운체에 연결하는 것

2개 컨테이너와 하나의 볼륨이 있는 상태. 이걸 spec 밑에 기술한다.

쿠버네티스 apiVersion 이란게 있고 버전 1을 쓴다.

10: 걍 한번씩 읽어봐. 키값은 유니크 해야함

11: 군으로 나눈다 -> 내 프로그램에 여러 소웨가 섞여있. 프론트에 섞인 애들만 빼고 싶을 때, 백에 ~, 캐시에 들어간 애들만 빼고 싶을 떄 이런 식으로 군으로 나눌 수도 있. => 그룹핑!

그래서 이 라벨을 갖고 목적에 따라 원하는 애들만 골라 추출 가능!!

시스템 파라미터라 하는 -  운체에 있는 값들 설정도 라벨을 준다고 볼 수 있.

12: 군을 강조한 이유? 왜 이걸 중요하게 생각하라 했는지에 대한 이야기

mortal ->immortal 이 아니다 즉 죽을 수도 있다. 수명이 존재.

그럼 처음 팟 3개가 서비스 종료 전까지 계속 유지될 수 있느냐? 그럴수도, 안그럴수도 있다.

우린 저번에 3개 팟을  띄우는 서비스를 만들었는데, 안 변하는 것은 내가 3개를 띄워달라는 디자이어드 스테이트.

쿠버네티스는 3개만 유지한다. 예를 들어 2번쨰 컴이 셧다운되거나 전원 오버된다? 그러면 여깄던 팟도 죽는다. 근데 3개를 유지해야 하니 다른 컴을 쓸 수 있음 또 하나의 팟을 띄운다. 전혀 다른 컴에서 팟이 부활하기도 한다는 것

->이 경우 아이피 주소도 바뀐다!! 전혀 다른 팟이 만들어지기 때문

특정 팟을 지칭하기 위해 라벨을 쓴다

팟들이 통신하면 아이피가 계속 바뀐다. 이걸 추적, 관리하는 것은 힘든 일이다.

노드 포트: 외부와 통신하기 위한 포트. 외부서 요청이 들어오면 받아서 로드밸런싱,

 

 

이제 실습을 위한 이론들. 이제부터가 진짜 본격적 쿠버.

14: 레블리카셋이라고 하는 소웨가 쿠버 안에 있다. 컨트롤러 소웨

팟을 3개 유지해주세요 하는 요청을 이 레플리카셋이 받아주는거임. 그래갖고 그 역할을 해주는거임. 도커는 걍 음... 컨테이너 n개 띄워주세요 하면 ... 걍 그렇게 되는... 긍까 딱 이 역할을 하는 추상화된 단위 하나가 없다는 말로 이해해야 하는 건가?

아이피 주소를 붙이기보단 라벨을 붙여서 사용할 것이다.

레플리카 셋에서 우리가 만드는 팟이 여러 개로 정해질건데 이에 대해 어떻게 이름을 정하고 붙여줄 것인지.

그리고 요청하지 않은 부분들 (얌파일에 안쓴 것들)에 대해선 스스로 할 것이다.

15: 필요한 정보 줄줄이 쓸 수 있음

18: -l 은 라벨을 주는 것. 환경이 프로덕션이고 티어가 프론트인 경우에 대해 팟을 보여달라는 말.

19: apps/v1이나 그냥 v1이나 동일하다.

글고 걸러낼 조건을 selector 밑의 matchLabels 밑에 적는다. 내가 걸렀을 때 얘가 걸렸음 좋겠다는 의미에서!

20: 그 결과가 그림으로 나와있음. 레플리케이션 컨트롤러의 셀렉터에 라벨이 뭐라 적혀있는지 유심히 보라!

21:

버전업/다운, 롤링백 같이 도커에서 했던 것들을 쿠버에선 '레플리카셋'이 하며, 이를 더 안정적으로 한다.

블루그린이란? 버전1로 돌아가고있는 소웨가 레플리카셋 위에서 돌아가고 있을 때 그냥 새로 만들어버리는 거다. 레플리카셋 뉴 라고 해서, 버전 3개에 해당하는 새로운 컨트롤러를 만들어버리는 것.

첨에 왼쪽 회색에서 팟에 띄운 컨테이너가 어떤 것에 대한 버전 1,1,1인데 2가 나온 경우, 도커는 이미지를 업데이트 하여 해결했는데,

쿠버는 첫번째 방법으로 블루그린이란 방법으로 해결 가능하다.

왼쪽에 있는 것의 버전 2에 해당하는 것을 새롭게 만들어버린다 (그게 녹색). 어차피 외부에서 접촉하는 애는 따로 있기에

service가 새로 만든 3개를 바라보도록 바꾸어 버리는 것이 한 가지 방법일 것.

단 서비스가 중단될 위험이 있는 위험한 기법이고, 흔하지 않다.

 

22~23: 레플리카 셋이 많은 기능을 한다고 이야기하는 이유다. 도커보다 똑똑하다

롤링, 서비스가 천천히 바뀌는 것. 앞에서 이야기 한 그 죽은애 아님 필요없는 애 n개 대신 새거 n개 만드는 거 말함. 중요한건 필요없는 그 애들을 잠깐 멈추고...? 새로 생긴 애들이 완전히 대신 일을 할 때까지 기다렸다가 그렇게 되기 시작하면 그 때 이전 애들을 지운다고 한다. 이게 롤링 업이 될 수도 있고, 이전 버전으로 돌아가는 롤링백이 될 수도 있따.

이런걸 직접 할 일이 없다는거!!!! 그리고 무중단 상태로! 이걸 한다는것도!

 

25: 팟에 명령을 주면 9쪽의 파일 기준으로 컨테이너 둘, 볼륨 하나 있는데 디폴트로 두 컨테이너 중 하나를 선택한다 맨 위에 있는 애로.

그래서 팟 안의 누구에게 명령을 구체적으로 내릴 수도 있는데, 마이 리틀 팟 안의 엔진엑스에게 (25쪽 5번쨰 줄 명렁)

이 팟에게 시키는 명령이 딱 한 줄로 끝나야 한다면 5번째 줄의 sh(쉘 실행) 이거 하나만 붙이면 된다. 그런데 내가 실행할 명령이 여러 줄이면 6번째줄 redis 뒤에 좌라락 붙인 부분처럼 한다.

쿠버 안의 팟 안으로 들어가려는 것이므로 쉘을 실행하고 엔진엑스 안으로 들어간다.

했다가 엑싯해서 나온다, 그리고 똑같은 익스큐트 명령을 한번 더 실행한다.

그러면 디폴트 컨테이너 어쩌고 하면서 디폴트로 맨 위, 첫쨰 컨테이너에게 명령을 보냈다는 것을 알 수 있다.

이 팟 안에 있는 컨트롤러를 구경해보세요!

 

한번 얌 파일을 어플라이 하면 이걸 수정하면 안된다. 나중에 깨끗하게 지워지지 않는다고 한다.

딜리트 안하고 컴을 끄면? 경험을 권한다. 다양한 일이 벌어질 수 있따.

 

영상 후반부 1시간 34분 대에 그 팟 하나 죽였을 때 하나 더 생겨서 4개 되고 다시 3개로 되는 과정을 볼 수 있다



 

 

[수: 쿠버네티스 객체와 명령어]

레플리카 컨트롤, 레플리카 셋에서 팟 등을 아이피 주소로 조정하는 것이 어려운 이유를 설명한 뒤 라벨로 조정한다는 설명을 했었다.

내가 관심 있는 애들을 그룹핑할 때 많이 쓴다. 얌파일에 라벨 혹은 셀렉터라는 이름으로 기입했었다.

deployment = 도입. 이 개념이 젤 중요

복제된 뭔가를 n개 돌려라. 더 많은걸 제공하되, 서비스 운용하는 사람 입장에서 가진게 아닐까....

클러스터라는 것은 여러 노드가 붙어갖고 우리가 작업을 시킬 운동장에 해당하는 것이 클러스터다.

클러스터: 작업할 운동장

6: 오브젝트는 이 중 하나가 되는 셈.

9: 쿠버네티스와 대화하는 방법 1.CLI에 필요한 명령을 바로 요청. 모니터링 용도, 긴급상황에 요청하기 위한 용도.

2. API. 커맨드라인에서 할 수 있는 일과 동일한 작업을 할 수 있다. 프로그램에서 호출하는 함수. 사람이 하는게 아니고 이상 동작시 뭘해야할지 프로그램을 미리 짜놓는 것. cpu, 메모리가 내가 원하는 것 이상/이하로 쓰는지 감지하는 프로그램 만들어두고 이거 발견 => cli로 보내야 할 명령을 바로 api로 호출

cpu, 메모리가 간당간당하니 새로운 팟을 하나 더 만드는게 맞는 것 같애, 혹은 네트워크 설정 이렇게 바꾸자, 혹은 소위 버전 바꿀까? 이런 다양한 일을 직접 개발자 운영자가 커맨드라인 인터페이스로 매뉴얼하게 할 수 있지만 이를 별도의 프로그램을 짜서 할 수도 있다. 이걸 쿠버네티스 api라고 한다.

10: 실제로 이 api 확인 가능

이번에 읽으라고 한 문서 둘 중 하나인데... 내려가보면 <Alteratives to ReplicaSet>제목과 내용이 나온다. Deployment는 Replicaset를 갖고 있는 오브젝트다. 

디플로이먼트는 레플리카셋의 좀더 상위개념인것처럼 써있고, 레플리카셋 자체, 그 안의 팟들까지 업뎃할 수 있고, 롤링 업뎃까지 할 수 있다고 써있다.

디플로이먼트 컨트롤러는 ?가 아닌 디플로이먼트를 쓰도록 권장되고 있고, 레플리카셋은 기술적으로 일정 개수의 팟을 유지해야 했따면 디플로이먼트는 그런 기능 포함해셔 실제로 내가 서비스 운용할 때 가장 많이 나오는업뎃 혹은 롤링. 버전 업 등 다양한 것까지 포괄적으로 갖고 있음.

디플로이먼트 자체가 버전을 가질 수 있음. 했다가 이전으로 디플로이 할 수도 있다.

그래서 이름 자체가 지난번에 이야기한 것처럼 레플리카 셋은 매우 기능적이다. 운영자 입장에서 똘똘한 기능을 믾이 힌디. 문서에 구체적인 기능들이 다 나와있다! 

디플로이먼트를 갖고 어플라이 이걸로 서비스를 만든다는 것은 레플리카 셋으로 어플이 돌아간다는 것도 포함하고 있고, 개수가 유지되고 있고...

15: 그러나 레플레카셋은 렉처 20 이후로 잘 쓰지 않는다

16: 팟, 볼륨, 리플리카, 디플로이먼트 순.

17: 라벨 같은거 어떻게 바꿧는지 양쪽 코드 차이점 알기

18:

카인드: 우리가 만들 오브젝트 종류. deployment/replicaset

apiversion

metadata

19:

명령어가 어떻게 달라졌는지 볼 수 있는 부분이 빨간색.

바깥에서 우리가 운영하는 엔진엑스 안으로 들어가보기 위한 것 실습하며 설명해볼 것

 

<실습>

--record 옵션 검색해볼 것. 디버그할 떄 도움되는 부분. 마지막 플젝에서.

38~9분 영상 설명 뭔소리인지...

글고 강의노트 19쪽 빨간색 줄친 명령어들이 매우 중요한 부분.

일단 거기 서비스의 포트넘버와  쿠버 마스터의 ip

우리가 만든 클러스터, 디플로이먼트 안으로 들어가기 위해 info 명령어 이용해서 ip 알아내서 임차하려고 한다.

에 근데 나 그 빨간색 줄 명령어 하면 나는 internal에서 돈다고 나오지 교수님 컴처럼 정석적인 ip 주소 안나옴.. 왜지?

 

우린 3개의 엔진엑스가 올라간 파일을 준다. 

구멍이 expose로 뚫렸고, 

 

그럼 4번째 줄의 curl 명령어를 입력한 뒤 내가 3개의 팟 중 어느 팟에 들어가있는지 알아내는 방법이 있다.

좀더 단순한 방법은 .... 뭬?

 

25: 로그 명령