토고미의 잡동사니

이번 포스팅은 자세한 설명은 하지 않고 Ingress 컨트롤러가 띄워져있다는 가정하에, Ingress 설정을 어떻게 하는지만 올려본다. apiVersion: extensions/v1beta1 kind: Ingress metadata: name: togomi-api-server-ingress annotations: nginx.ingress.kubernetes.io/rewrite-target: "/destinationAPI" # 어느 API PATH로 보낼지 nginx.ingress.kubernetes.io/ssl-redirect: "true" kubernetes.io/ingress.class: "nginx" nginx.ingress.kubernetes.io/secure-backends: "true" ngi..

k8s에서 하나의 configmap을 이용하여 여러 개의 파일을 마운트하는 법을 알아보자. 아래와 같이 하나의 configmap에서 여러 개의 파일을 만들 수 있다. 이해를 위해 파일이라고 했지만, 사실은 key-value로 저장된다고 하는 것이 정확하다. kind: ConfigMap apiVersion: v1 metadata: name: example-config data: fileOne.conf: |- blahblahblah blahblahblah fileTwo.conf: |- { "sample": { "config" : "example" } } 이렇게 fileOne.conf 라는 key 하나와 fileTwo.conf 라는 key 하나, 총 두개의 key를 만들었다. 이제 이 key값을 파일이름으로하..

operator-sdk는 CRD뿐만 아니라 k8s의 기본 리소스 또한 다룰 수 있다. CRD의 컨트롤러나 웹훅을 만들때와 마찬가지로 group,version,kind만 잘 지정해주면 된다. 아래 예시는 k8s의 기본 리소스 중 하나인 RoleBinding의 컨트롤러를 생성하는 과정이다. 1. API 그룹 확인하기 $ kubectl api-resources | grep rolebinding 왼쪽에 리소스 이름, 중간에는 API 그룹이 나온다. rolebinding의 그룹은 rbac.authorization.k8s.io임을 확인 할 수있다. 2. API 버전 확인하기 $ kubectl api-versions | grep rbac.authorization.k8s.io 1번에서 확인했던 그룹이름으로 grep을 ..

쿠버네티스 구축을하면서 짜증나는 부분 중 하나가 네트워크인데, 이 네트워크 부분이 꼬이면 정말 힘들어진다. yaml파일을 이용해 설치/삭제 할때 단순히 kubectl apply -f 파일이름 kubectl delete -f 파일이름 을 이용하곤 하는데, calico같이 실제 노드에 파일을 생성하거나 iptable을 수정하는 모듈은 kubectl delete -f 만으로는 부족하다. 관련된 파일과 iptables 룰 및 tunl0 인터페이스 등을 삭제해줘야한다. 1. 관련된 파일 삭제 calico가 어떤 파일들을 참조하는지 먼저 확인하자. 설치 yaml을 확인해도 상관없다. 난 오류가 발생한 상태의 pod를 describe했다. $ kubectl describe pod {칼리코 POD} -n kube-sy..

개발을 하다 보면 아이디, 비밀번호 등 민감 정보가 필요할 때가 필연적으로 생긴다. 쿠버네티스에서는 이러한 경우를 위해 시크릿을 사용한다. 공식문서에는 다음과 같이 쓰여있다. 쿠버네티스 시크릿을 사용하면 비밀번호, OAuth 토큰, ssh 키와 같은 민감한 정보를 저장하고 관리할 수 ​​있다. 기밀 정보를 시크릿에 저장하는 것이 파드(Pod) 정의나 컨테이너 이미지 내에 그대로 두는 것보다 안전하고 유연하다. 시크릿을 만들 때는 아래처럼 base64로 인코딩 된 값을 넘겨준다. apiVersion: v1 kind: Secret metadata: name: sample-secret data: sample_key: c2FtcGxlX3ZhbHVl 나는 여기서 의문이 들었다. 아니, 쿠버네티스를 모르는 사람이 ..

책을 읽다가 문득 궁금증이 생겼다. 컨테이너는 linux namespace와 cgroups를 이용해 다른 프로세스들과 격리되어 실행 된다. 그렇다면 쿠버네티스 파드는 어떻게 되는 걸까? 파드 안에는 여러 개의 컨테이너가 들어갈 수 있는데, 그 컨테이너들끼리 격리 돼있다면 사실상 파드의 의미가 없을 것이고, 격리가 돼있지 않다면 컨테이너의 의미가 없지 않나? 이런 생각이 들었다. 구글링을 해서 답을 알아낸 결과를 정리하고자 한다. 먼저, 컨테이너에서의 리눅스 네임스페이스는 아래 그림과 같은 구조이다. 리눅스 네임스페이스에는 총 6가지 종류가 있다. (그림에는 5가지만 표시) 1. IPC namespace (InterProcess Communication) - 말 그대로 프로세스간 통신을 가능케 해주는 네임..

쿠버네티스를 사용하다보면 네임스페이스를 날려야할 때가 많다. 그러면 꼭 terminating 상태에서 멈춰서 안 지워지는 현상이 발생하곤 한다. 이 현상을 구글링 하면 finalizer 제거를 통해 네임스페이스를 강제 삭제하는 방법이 나오지만 바람직한 방법은 아니다. 애초에 네임스페이스가 terminating에서 멈춰 있는 이유는, 잔존하는 리소스들이 해당 네임스페이스에 남아있기 때문이다. 그 잔존 리소스들 또한 terminating에 멈춰 있을 가능성이 높은데, 보통의 경우에 이는 삭제 순서가 꼬였을 때 발생한다. 따라서, 그 잔존 리소스들을 다 지워주기만 한다면 정상적으로 지워질 것이다. 파악하는 방법은 아래 커맨드를 이용하면 된다. $ kubectl get namespace {네임스페이스 이름} -..

컨테이너1은 OS+JAVA8+CODE2 조합의 이미지를, 컨테이너2는 OS+JAVA7+CODE1 조합의 이미지를 사용한다. 컨테이너는 이미지를 계층적으로 관리하기 때문에, 중복되는 이미지 레이어는 1개만 보관하고 있으면 된다. 이는 VM 이미지와의 큰 차이점이다. 이 이미지 레이어들도 결국엔 하나의 파일 시스템이다. 이 계층적 이미지들을 하나의 경로에 쌓아올리는 기술이 union mount이다. 컨테이너를 실행하게 되면, union mount를 통해 하나의 경로에 계층적으로 쌓인다. 그렇게 이미지 레이어가 다 쌓인 후에는, 그 위에 read/write 레이어가 씌워진다. 이 레이어는 이미지에 영향은 안주면서, 컨테이너가 write할 수 있도록 해준다. 하지만, 컨테이너 입장에서는 모든 레이어가 겹쳐 보이..