보배로움

서비스 메시 (Service Mesh)? Mesh ? 이름 그대로의 역할 네트워크 전체에서 흩뿌려져 내부 동작을 손쉽게 제어 서비스 라우팅, 로드밸런싱, 텔레메트리에 대한 아이디어를 재구성 Kubernetes 이전? 관련된 기능을 특정 언어의 라이브러리로 제공했음 (물론 지금도 사용하는 곳도 많음) 무엇이 있었나? Scala - finagle Java - Netflix OSS (hystrix, ribbon), Spring cloud 만약 다른 언어에서 사용하고 싶다면? 사용할 수 없다. 해당 언어에서만 사용이 가능함. 해당 언어 애플리케이션에서 사용할 땐 의존성이 생기는 문제 단순히 import dependency가 아닌 애플리케이션 비즈니스 코드 내부로 깊게 침투해져 있는 경우가 많았다. 만약 이걸 때..

개요 서비스 (East-West) 파드 집합을 단일 유닛 또는 네트워크 서비스로 취급 로드밸런싱/라우팅. 서비스 검색 매커니즘. 레이어 3/4 매커니즘 인그레스 (North-South) 클러스터에서 실행되는 워크로드에 대한 진입점 세분화 된 트래픽 라우팅. 레이어7 로드밸런싱. 서비스 메시 더 진보된 라우팅, 보안, Observability 제공 East-West, North-South 지원 애플리케이션 소스코드 변경없이 Proxy/Sidecar를 이용한 통신 Kubernetes Service 여러 파드에서 걸쳐 트래픽을 로드밸런싱 하는 쿠버네티스의 핵심 API L3/L4 Layer load balancing -> TCP/IP, Port/IP 워크로드/파드는 대체 가능한 특성이기에 IP 대신 서비스를 이..

Secret에 대해 알아보기 전에 Secret이란 애플리케이션이 비밀로 유지하려는 데이터 더 쉽게 말하면 애플리케이션 서비스에서 필요한 비밀 데이터 ex) secret token, password, ... 다음과 같은 운영상의 문제를 고려해야 함 시크릿 순환 정책/키 (암호화) 순환 정책 시크릿의 순환 주기는 어떻게 결정할 것인가? 암호화 키의 순환 주기는 어떻게 결정할 것인가? 시크릿 저장 정책 시크릿 데이터를 저장할 때 어떤 요구사항을 충족해야 하는가? 격리된 하드웨어에 시크릿을 유지해야 하는가? 개선 계획 시크릿 또는 암호화 키가 손상되었을 때 어떻게 해결할 것인가? 애플리케이션에 영향주지 않고 계획 및 자동화를 실행할 수 있는가? 시크릿 관리를 어떤 레이어에서 제공할지 결정도 필요함 쿠버네티스 단..

개요 쿠버네티스 자체는 컨테이너를 생성, 시작, 중지하는 법을 알지 못한다. 대신 이런 작업을 컨테이너 런타임이라는 컴포넌트가 담당해 진행한다. 이 컨테이너 런타임에 대해 알아보자. 컨테이너 런타임을 간단하게 설명하면 다음과 같다. Linux: cgroups 및 namespace 같은 커널 기능을 이용하여 컨테이너 프로세스를 생성하는 녀석 Kubernetes: kubelet과 함께 동작하며 쿠버네티스 node에서 컨테이너를 생성 및 관리하는 녀석 그럼 2가지 의문점이 든다. 왜 쿠버네티스는 몰라야하는가? 명색의 컨테이너 기반 오케스트레이션인데 몰라도 되나? kubelet이 컨테이너를 관리한다고 했다. kubelet 내부에 컨테이너 런타임이 있다고 보면 되나? 이 의문점에 대해 답을 하기 위해 OCI, C..

Kubernetes Secret 은 base64로 인코딩된 값을 data로 갖는다. data 필드의 모든 키(key)에 해당하는 값(value)은 base64로 인코딩된 문자열이어야 한다. https://kubernetes.io/ko/docs/concepts/configuration/secret/#시크릿-개요 그럼 일반적인 string을 base64로 어떻게 인코딩할까? 아주 간단하다. echo, base64 를 사용하면 된다. $ echo 'want-to-encode-this' | base64 d2FudC10by1lbmNvZGUtdGhpcwo= 근데 위와 같이 하는 경우, base64 인코딩 된 값을 비교하거나 할 때 문제가 생길 수 있다. 왜냐하면 echo 는 마지막에 무조건 newline(\n) 을..

Pod spec 에는 restartPolicy 필드가 있다. Pod의 Container가 종료했을 때, 재시작 정책을 정의하는 필드이다. 3가지의 값을 허용한다. Always (default): Container들이 정상적으로 종료(zero exit code)되었더라도 재시작하는 정책. Container가 어떻게 종료되든 간에 무조건 구동 중이여야한다면 해당 옵션을 사용하는 것이 유용하다. OnFailure : Container가 비정상적으로 종료(non-zero exit code)하는 경우에만 재시작하는 정책. Pod가 특정 task를 수행하도록 설게되었고, 그 task가 완료(성공)되면 재시작하지 않는게 정상인 경우라면 해당 옵션을 사용하는 것이 유용하다. Never: Container의 exit c..

잘 모르면 몸이 고생한다고, Deployment replicas를 계속 변경하며 테스트 할 일이 있었는데 `kubectl edit` 으로 replicas를 변경해가며 사용했다. 근데 더 간단하게 CLI 상에서 replicas를 변경할 수 있는 `kubectl scale` 명령어가 있었다. # Scale a replica set named 'foo' to 3 kubectl scale --replicas=3 rs/foo # Scale a resource identified by type and name specified in "foo.yaml" to 3 kubectl scale --replicas=3 -f foo.yaml # If the deployment named mysql's current size i..

해당 글은 Kubernetes 공식문서 Garbage Collection를 토대로 작성한 글입니다. 조금 쉽게 표현하고자 추상적으로 표현한 부분들이 있는데, 자세한 내용은 공식문서를 참조해주세요. 쿠버네티스에서 일부 리소스들은 다른 특정 리소스로 하여금 만들어져 운영되는 경우가 있습니다. 다시 말해서, 특정 리소스가 일부 리소스의 owner 일 수 있고, 이러한 owner 리소스에 대해 일부 리소스가 dependents 리소스 일 수 있습니다. 즉, 리소스 간에 종속적인 관계가 존재할 수 있는 것입니다. 예를 들면, ReplicaSet 은 여러 Pod 들의 owner 라고 말할 수 있을 겁니다. 또한, 이 Pod 들은 ReplicaSet 에 대해 dependents 리소스라고 할 수 있겠죠. Owner ..