Search

[스터디] Docker & Kubernetes Study #8

요약

파드 내에서 실행되는 어플레케이션이 어플리케이션 자신, 다른 파드, 클러스터에 배포된 다른 구성 요소의 데이터를 얻는 방법을 살펴봤다. 배운 내용을 정리하면 다음과 같다
파드의 이름, 네임스페이스 및 기타 메타데이터가 환경변수 또는 downward API 볼륨의 파일로 컨테이너내부의 프로세스에 노출되는 방법
CPU 와 메모리의 요청 및 제한이 필요한 단위로 애플리케이션에 전달되는 방법
파드에서 downward API 볼륨을 사용해 파드가 살아 있는 동안 변경될 수 있는 최신 메타데이터를 얻는 방법
kubectl proxy로 쿠버네티스 REST API 를 탐색하는 방법
쿠버네티스에 정의된 다른 서비스와 같은 방식으로 파드가 환경변수 또는 DNS 로 API 서버의 위치를 찾는 방법
파드에서 실행되는 애플리케이션이 API 서버와 통신하는지 검증하고 자신을 인증하는 방법
앰버서터 컨테이너를 사용해 애플리케이션 내에서 API 서버와 훨신 간단하게 communication 하는 방법
클라이언트 라이브러리로 쉽게 쿠버네티스와 상호작용할 수 있는 방법

Questions (뭔가 근본 질문이 많네요 ㅋㅋ)

CPU 개수 요청을 시간 단위로 하는 개념이 이해가 잘 안감 → CPU 는 물리적 개수인데 어떻게 시간 단위?
CPU사용률의 계산방법
CPU의 사용률은 보통 이렇게 측정된다.
(각 단위시간 중에 CPU가 사용된 총 시간의 합) / (단위 시간) * (cpu의 코어 갯수) = CPU 사용률
예를 들어 조금 더 쉽게 설명하자면 이렇다.
1.
컴퓨터에는 코어가 4개인 CPU가 장착되어있다.
2.
단위시간은 1초이다
3.
지난 1초간 코어1의 활동시간은 0.3초 / 2의 활동 시간은 0.2초 / 3의 활동 시간은 1초 / 4의 활동 시간은 0초 이다
그러면 단위시간은 1초이고 이 1초동안 4개의 cpu가 활동한 시간은 0.3 + 0.2 + 1 + 0 = 1.5 가 된다.
그럼 지난 1초간 CPU의 사용률은 1.5 / 4 * 100 = 37.5 37.5퍼센트가 되는것이다. 또한 시간은 쏜살같이 흘러가고 있기 때문에, 다음 1초의 CPU사용률은 100%가 될 수도 있고, 50%가 될수도있고, 10% 가 될 수도 있다. 그렇기 때문에 이런 순간순간의 CPU사용률이 매우 높게 책정된다고 해서 내가 돌리고있는 프로그램의 성능을 크게 의심해 볼 필요는 없다.
HTTP와 HTTPS 간의 프로토콜 차이 (안전하다는 것은 알지만.. 그 이상은..ㅋㅋ)

https의 원리 - 공개키 방식(PKI,Public Key Infrastructure)

공개키는 두개의 키를 갖게 되며, A키로 암호화 하면 B키로 복호화가 가능하며, 반대로 B키로 암호화 하면 A키로 복호화가 가능하다. 여기서 두개의 키중 하나는 공개키(public key)가 되며, 하나는 비공개키(private key)가 된다. 두개의 키가 동작되는 원리를 간단히 살펴보면, 비공개키는 소유자 즉 굉장히 private한 사용자가 가지고 있게 되며, 공개키는 소유자외 타인에게 공개되는 키이다.
타인은 공개키를 이용하여 데이터를 암호화 해서 소유자에게 전달하면, 소유자는 비공개키로 복호화 하여 그 데이터를 얻을수 있게 되는 간단한 원리이다.
인증서를 이용해서 Man-in-the-middle 공격을 막을 수 있는 원리는 무엇일까?
(준성) 위 설명을 기반으로 생각해 보면, client 측에서 공개된 암호키로 암호화 하고 전송하면 중간에 누가 가로채도 decrypt 할 수 있는 key 가 server 측에만 존재하기 때문에 중간자는 내용을 알 수 없음!
Q. 추가 질문 : 위에서 암호키와 인증서는 어떻게 다른가? 동일한건가?
(답변) 암호키와 인증서는 일단 거의 비슷한 개념인데, 인증서는 보통 비대칭키를 생성하고 인증에 필요한 내용을 비밀키로 암호화해서 복호화할 수 있는 공개키와 함께 전달해요
이렇게 되면 다른 사람들은 모두 이 인증서를 받아보면 공개키를 통해 복호화는 할 수 있지만, 개인키로 암호화는 못하기 때문에 내가 발급했다는걸 인증할 수 있게 되는거죠
추가로, 암호키나 인증서는 누구나 발급할 수 있어요. 그렇기 때문에 내가 연결을 요청하면 그 서버에서 인증서를 던져주더라도 이 인증서가 정말 믿을만한건지? 네트워크상에 이미 흩뿌려진 안전하지 않은 인증서는 아닌지? 모르잖아요?
그래서 서버에서 보내준 인증서를 "신뢰"하기 위해서 인증서 파일을 curl에 함께 던져주는거에요.
같은 이유로 insecure 옵션 구현이 있는거고.. (인증서를 무조건 신뢰)
조금 더 TMI를 얹자면 그래서 SSL 인증서를 구매할 수 있는거에요. SSL 인증서를 판매하는 기업에서 이 인증서를 통해 통신하다가 만약 사고가 난다면 보상을 해준다는 증서를 파는거죠
결국 ambassador pattern 을 사용하면서 새로운 컨테이너를 띄우는 오버해드가 더 크지 않나? 클라이언트 라이브러리를 사용해서 접근하는게 무조건 좋은거 아닌가? 어떤 케이스에서 더 좋을까?
(답변) 그냥 불편해서 그런거 아닐까요 ㅋㅋㅋㅋ 맨날 인증서 설정하고 Basic 인증 헤더 붙여주기 귀찮아서
(답변) Docker Image의 범용성이 증가하게 되어요. 앰배서더를 띄움으로써 어플리케이션은 내가 누구와 어떻게 통신하는지를 신경쓰지 않고 주어진 Endpoint로 요청만 하면 되기에, 어플리케이션의 실행 환경이 어떻든지에 관계없이 독립적으로 구현할 수 있다는 아주아주 큰 장점이 있습니다.