✔ 쿠버네티스 스터디 16 일차

혜

관리 하는 방식 알아서 좋고 이런 게 기동이 잘 되고 있는지 모니터링이 항상 중요하잖아요. 
그래서 이런 거 설정 잘해가지고 학교 장애 안 생기게 대응해야겠다. 
생각했습니다.

 

솜
저도 헬스체크라는 용어를 처음 접한 거는 그때 데이터 허브 그거 poc 할 때였거든요. 
그래서 근데 거기 자체에는 헬스 체크가 아예 그냥 자기네 자체 명령으로 돼 있는데 이게 쿠버네티스에서 아이디어를 가져온 건가 싶기도 하고 아니면 원래 dev os 있는 용어인가 잘 모르겠고요 근데 뭔가 보면서 이런 되게 세부적으로 헬스 체크를 할 수 있다는 게 참 다행이라는 생각이 들었어요. 뭔가 이 컨테이너를 운영하는 팀마다 뭔가 원하는 게 다를 것 같아서 어떤 팀은 리드니스 방법을 활용할 수도 있고 어떤 팀은 진짜 프로세스가 꺼지면 안 되는 경우에는 라이브니스를 사용할 수도 있고 아니면 한 번만 확인하고 싶으면 스타트업도 사용할 수도 있고 뭔가 팀마다 이게 사용하는 게 다를 것 같아서 뭔가 여기를 보면서 이제 약간 이게 좀 생기는 것 같아요. 쿠버맨티스 파드를 분리하는 게 약간 팀별로 뭔가 이렇게 분리가 된다고 하더라고요.

앗 네임 스페이스를 이렇게 팀별로 분리하게 될 때 뭔가 이렇게 정말 특성이 다 달라서 이렇게 분류가 되겠구나 뭔가 떠올랐던 것 같아요. 
저희 팀하고 약간 오버랩 되면서 떠올랐던 것 같습니다.

 

윤
솔직히 이거 관리를 하는 거는 진짜 대부 쪽이나 백단 유저들은 그렇게 어려울 것 같지는 않은데 이거를 이제 한 번에 관리를 하려면 이거를 그림을 그려야 하는데 웹 쪽이 빡시지 않았을까 웹쪽이 빡시지 않을까 구현을 해야 될 거 아니야 볼 수 있게 그렇다고요.
우리 회사 특성상 왠지 이거를 웹으로 관리할 것 같기는 하거든

 

혜

너무 힘들지 않을까 그러면

 

주

그렇게 되면 쿠버네티스를 쓰는 의미가 없어질 수도 있어요. 
왜냐하면 제 생각은 우리 회사에서는 이거를 완벽하게 핸들링 할 수 있는 웹을 만들 거다라고 보기에는
힘들 것 같아.. 사실 조금 힘들 ..그거를 만드는 거를 저기 봤어 제품을 저기 저기 소프트웨어 걔네들 거가 저기 이쿠먼티스를 그렇게 으로 구현을 해놨거든요. 
그 매치 뷰 무슨 미팅할 때 봤는데 쉽지 않을 것 같아요.

 

윤
그러니까 그 이게 프록 메테우스로 그라페나로도 표현이 안 되더라고 그게 그래서 왠지 딱딱 빨간불 녹색 불 주황불 해가지고 모니터 컨테이너 리스트 쫙 나오게 해가지고

 

수
노드나 파드가 실행되다보면 안죽을 수가 없는것 같다고 생각하는데 alays 로 설정해서 그냥 죽어도 계속 살아라고 말하고 싶을 것 같아요. 밑에 워크로드 리소스의 자동 파장 계상 일회 명령어 실행을 성공적 워크로드일 경우에는 이거는 그냥 저거 완전 단순한 뭐 한 번 딱 실행하고 끝내는 그런 데이터 프로세스 배치 개념에 그런 경우에 시간되면 안 되는 거예요. 그거 어차피 크론으로 되지 아닌가 .. 예를 들어 크론으로 하다가 실패됐을 경우에 실행시키지 않는다가

 

윤
크론을 안 쓰지

 

수

그래요 네 일단 다시 한번 공부하겠습니다.

 

주
그래서 이런 배치성 프로젝트 같은 경우에는 에어플로우를 쓰는 이유가 그것 때문에 그래요 이게 여기서도 보이는 게 ales를 선택할 수 없다는 거는 데이터가 만약에 프로세스가 100개가 떴는데 하나가 분명히 실패를 할 확률이 굉장히 높거든요.
근데 그거를 재실행을 안 할 수가 없는데 그걸 재실행을 안 해주니까 아예 그냥 하나를 실패하면 다 실패한 걸로 처리하고 에어플로우 같은 경우에는 그걸 다시 실행을 시켜주는 그런 툴을 다시 도입을 하기는 해요.  그래서 에어플로우가 많이 쓰는 이유가 그런 재시동을 많이 또 그런 역할도 있습니다. 

저는 오늘 여기 헬스체크가 로드 밸런스 할 때 한 번 언급된 적이 있는데 로드 밸런스에서 그 헬스체크가 도대체 뭔데 그래서 저는 그때까지만 해도 로드 밸런스의 하나의 기능이라고 생각했는데 이렇게 별도의 서비스라는 걸 알아서 그때 조금 의문점이 해결이 좀 됐네요. 그건 잘 모르겠습니다. 근데 로드밸런서
그  L7 계층에서 로드 밸런싱 그래서 이렇게 했습니다.