Run The Bridge

kubernetes를 사용하다 보면 환경변수를 적용하게 되는데 ConfigMap 또는 Secret 을 생성해서 env에 key, value를 적용하는 방식인 ConfigMapRef와 secretKeyRef를 선언하는 방식을 많이 사용하고 있다. 해당 방식은 1:1 대응이기 때문에 N개 이상의 환경변수를 적용하기 위해서는 yaml에 정의해야 할 값이 늘어난다는 단점이 있다. 그래서 우리는 envFrom을 통해 N개 이상의 환경변수를 Pod내에 Mount 해보려고 한다. 1. ConfigMap 생성 아래와 같이 꽃, 동물, 과일에 대한 key를 넣고 key에 맞는 value를 선언해주었다. apiVersion: v1 data: FLOWER: "ROSE" ANIMAL: "DOG" FRUITS: "APPLE" ..

일요일에도 시험을 응시할 수 있어 4월 23일 일요일에 시험 응시 4월 24일 월요일 합격 발표를 받았다. CKA 공부 방법이라던지 그런 건 다른 블로그들이 친절하게 써놔서 별도로 적진 않겠다. 점수는 81점으로 합격하였다. 커트라인이 74점으로 알고 있는데, 66점으로 내려갔네... 이 정도면 웬만하면 다 합격할 수 있을 듯하다. 물론 나는 실무에 있으면서 kubernetes 명령어도 많이 쓰고 트러블 슈팅도 많이 해보면서 경험을 많이 쌓았지만 처음 도전하시는 분들도 Udemy(유명한 거 아시죠? ㅎㅎ) 강의도 듣고 killer.sh도 풀어보면 할만한데?라고 충분히 생각이 든다. 특히 killer.sh는 실무에서도 사용할만한 명령어라던지 응용 방법을 잘 알려줘서 꼭 풀어보길 바란다. 처음 시험 등록은 ..

네임스페이스를 구분하여 작업할 때가 많은데 그때마다 "-n"을 붙여서 Pod를 조회하는 게여간 번거로운 일이 아니다. 이렇게 많은 namespace를 일일히 언제 옵션 주고 있을까..? root@p-iskim-master ~ # kubectl get namespace NAME STATUS AGE acc-global Active 23d acc-system Active 23d default Active 23d iskim Active 23d kube-node-lease Active 23d kube-public Active 23d kube-system Active 23d 그래서 kubens라는 오픈소스가 있는데, kubens는 외부망이 되어야 하는 환경에서 사용이 가능하다 ㅠㅠ.. kubens도 결국 kuber..

Kubernetes Cluster를 운영하다 보면 개발, 스테이징, 운영 이렇게 나눠서 운영하는 경우가 매우 많다. 예시로 node1, node2, node3이 있다면 node1(개발), node2(스테이징), node3(운영)으로 지정할 텐데 node1에는 개발을 위한 Pod만 배포되어야 하고 node2, node3번도 각 역할에 맞게 앱들이 서비스되어야 한다. 물론 taint, toleration 설정을 해줘도 되지만, taint, toleration은 DaemonSet으로 배포된 Pod들도 설정해주어야 하는 번거로움이 존재한다. 우리는 그것보다 편한 네임스페이스를 구분하여 Pod들을 배포해 본다. 1. Node에 label 부여 먼저 나의 Cluster 구성은 worker01, 02, 03이 존재하..

0. 들어가기에 앞서 kubernetes에는 yaml 파일로 pod을 생성할 때 다양한 명령어들이 존재하는데 apply, create를 많이 사용하고 있다. 또한 그렇게 생성된 pod에 편집을 할 때는 patch, replcae와 같은 명령어들을 사용하여 편집을 한다. 이번에는 각 명령어들의 차이점을 알아보고 정리한다. 1. Pod 생성 명령어의 간단한 테스트를 위해 kubernets docs에 있는 nginx pod를 이용한다. 이름은 nginx-apply로 주고 apply 명령어로 생성한다. apiVersion: v1 kind: Pod metadata: name: nginx-apply spec: containers: - name: nginx-apply image: nginx:1.14.2 ports: ..

0. 들어가기에 앞서 쿠버네티스상에서 한 Pod안에 두 개의 앱이 들어가면 사이드카라고 부르는데, 통상적으로 하나의 앱은 로그를 관리하거나 healthcheck를 하는 데 사용하는 걸로 알고 있다. 쿠버네티스의 원칙은 1개의 Pod에는 1개의 앱만 올라가는 것을 원칙으로 삼고 있다. 여기까지 간단하게 서론 이야기를 하고, 만약 사이드카로 구성된 컨테이너 중 하나의 앱이 오류가 나서 올라오지 않을 때, 전체 Pod를 재시작할까? 아니면 오류난 앱만 재시작할까? 한 번 테스트해본다. 1. 사이드카 앱 구성하기 kubernetes docs에서 지원하는 사이드카 컨테이너 yaml을 사용한다. apiVersion: v1 kind: Pod metadata: name: counter spec: containers: ..

0. 들어가기에 앞서 podman이란? podman컨테이너 작업을 위한 오픈 소스 Linux 도구 docker.io 및 quay.io와 같은 registry의 컨테이너가 포함된다. Red Hat Enterprise Linux 8 / CentOS 8부터는 Docker 대신 Podman Pod라고 하는 컨테이너 및 컨테이너 그룹을 관리할 수 있는 libpod 라이브러리 기반 https://docs.podman.io/en/latest/# ← 공식문서 링크 1. Docker vs Podman 컨테이너를 올리기 위해서 가장 많이 사용되는 기술로는 docker가 제일 유명하다. Dokcer 엔진을 통해 생성된 컨테이너를 관리하는 소프트웨어가 바로 kubernetes일 것이다. 처음 docker를 배우기 전에 아래 ..

0. 들어가기에 앞서 kubernetes를 사용하면 생각보다 namespace를 많이 입력하게 된다. 물론 '-n {namespace}'으로 그리 긴 명령어는 아니지만, 생각보다 오타도 많이 나고 '-'이랑 'n'이 생각보다 떨어져 있어서 누르기도 귀찮다.... 또 namespace 이름이 이상하면 그거 또한 힘들어진다. 이러한 상황을 쉽게 타게할 수 있게 만들어진 플러그인(?) kubens을 소개한다. 1. kubens https://github.com/ahmetb/kubectx GitHub - ahmetb/kubectx: Faster way to switch between clusters and namespaces in kubectl Faster way to switch between clusters..