토고미의 잡동사니

쿠버네티스 구축을하면서 짜증나는 부분 중 하나가 네트워크인데, 이 네트워크 부분이 꼬이면 정말 힘들어진다. 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..

문제 Given a string s, return the longest palindromic substring in s. 예시 Input = "babad" / output = "bab" Input = "aca" / output = "a" Input = "cbbd" / output = "bb" string과 DP가 복합적으로 들어간 펠린드롬 문제이다. 풀면서 자꾸 막혔던 부분은, 모든 범위의 펠린드롬을다 확인해야했다는 것이다. 백준에서 풀었던 펠린드롬은 범위가 주어졌었지만, 이번엔 안주어졌기 때문이다. 그래서 이중 for문으로 모두 확인하도록 했다. 왼쪽=i , 오른쪽은=j 라고 할때, 왼쪽 끝은 고정하고 오른쪽 맨끝부터 하나씩 줄여가면서 확인하는 방식이다. 그리고 왼쪽 끝과 오른쪽 끝이 만나면, 왼쪽을 ..

EFK에 OIDC(Keycloak)를 연동하는 일을 맡았다. 구글에 분명히 정보는 많은데, 전부 제각각에다가 안 되는 경우가 대부분이었다. 그래도 어찌저찌 약 2주간의 삽질 끝에 성공시켜서 그 정보를 공유하고자 한다. 0. 주의사항 들어가기에 앞서, 기본 ElasticSearch와 Kibana는 OIDC를 사용할 수 없다. 정확히 말하면 사용할 수는 있지만 무료 라이센스는 사용할 수 없고, 최소 플래티넘 라이센스는 가지고 있어야 사용 가능하다. dockerhub에서 제공하는 공식 image는 trial과 basic 라이센스만 지원하기 때문에 안된다. 아래 링크에 들어가서 OpenID Connect를 검색해보면 알 수 있다. www.elastic.co/kr/subscriptions 그러므로 opendist..

개발을 하다 보면 아이디, 비밀번호 등 민감 정보가 필요할 때가 필연적으로 생긴다. 쿠버네티스에서는 이러한 경우를 위해 시크릿을 사용한다. 공식문서에는 다음과 같이 쓰여있다. 쿠버네티스 시크릿을 사용하면 비밀번호, 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할 수 있도록 해준다. 하지만, 컨테이너 입장에서는 모든 레이어가 겹쳐 보이..

Kibana를 다루던 도중, 아래와 같은 에러가 났다. {"type":"error","@timestamp":"2021-03-11T01:24:23Z","tags":["warning","stats-collection"], "pid":1,"level":"error","error":{"message":"[index_not_found_exception] no such index [.kibana], with { resource.type=\"index_or_alias\" & resource.id=\".kibana\" & index_uuid=\"_na_\" & index=\".kibana\" }","name":"Error","stack":"[index_not_found_exception] no such index [...

Kibana UI에 접속하지 않고 인덱스를 만들 수 있다. curl로 API 콜을 날리는 것이다. 기본 형식은 아래와 같다. curl -f -XPOST -H 'Content-Type: application/json' -H 'kbn-xsrf: anything' 'http://localhost:5601/api/saved_objects/index-pattern/{인덱스패턴} '-d{"attributes":{"title":"인덱스패턴","timeFieldName":"타임필드네임"}}' 예시로, 가장 흔하게 사용하는 logstash 인덱스 패턴을 만들어보자. kibana 컨테이너에 직접 들어가서 아래의 해당 curl 커맨드를 입력한다. $ curl -f -XPOST -H 'Content-Type: applicat..

kibana는 최초 실행 시 /usr/share/kibana/config 경로에 있는 kibana.yml 파일을 읽어서 초기 설정을 수행한다. kibana.yml에 들어갈 수 있는 설정 값들은 아래 링크의 공식문서에서 확인할 수 있다. www.elastic.co/guide/en/kibana/current/settings.html Configure Kibana | Kibana Guide [7.11] | Elastic To reload the logging settings, send a SIGHUP signal to Kibana. www.elastic.co 사용자가 따로 만들지 않아도 kibana가 자동적으로 아래와 같이 kibana.yml 파일을 만든다. (7.2.0 버전 기준) server.name: k..