개인코딩개발공장

# 개념 configMap은 머랄까.. 객체같은거다. 자바스크립트에서 그냥 객체.. 키 값 쌍의 데이터가 여러개 묶음으로 관리되는 그런거라고 보면된다. 이런 객체 데이터들을 configMap으로 만들어두고 pod나 이런 리소스들에서 갖다 쓰는거다. 뭐 환경변수나 이런걸로 쓰게되면, 여러 pod들에 모두 적용되는 특정 환경변수, 예를들어 db접근정보라던지.. 이런게 변경되었을경우 모든 pod에서 일일히 수정&적용해줘야하는데, configMap으로 관리하게 된다면 configMap에서만 변경해주면 이에 연결된 모든 pod들에 해당 변경사항이 적용이 될거라 생각했는데.. env는 안된다. pod를 삭제하고 다시만들어줘야 적용이 되더라.. 대신 volume mount는 되고 참,.. 암튼 # configMap ..

# 블루/그린 배포전략 맨처음은 deployment가 blue만 있다. 신버전인 rel: green 태그가 달린 deployment를 배포할때, service의 app: main셀렉터는 유지한채, 각각 deployment에서 rel: blue, rel: green으로 두개의 deployment를 생성하여 배포한다. 만약 신버전인 green버전에서 문제가 생기면, rel: green의 디플로이먼트를 삭제해서 롤백시키면 된다. 하지만 단점은 기존 blue버전말고 green버전을 새로 생성해야하기때문에 리소스가 두 배로 많이 든다. 만약 리소스 3개로 제한할거면.. blue를 2개로 하고, green을 한개로 해서 배포하는것도 맞는것같다. 이게 카나린가. # 블루그린 실제로 해보기 blue버전 deployme..

## NodeLabels 우리는 pod에 라벨링을 해서 service나, deployment 또는 cli 커맨드상에서 selector조건에 맞는 라벨링을 가진 pod들에 대해서 컨트롤하는걸 배웠다. Nodelabels는 이런 pod뿐 아니라, 노드 자체에 라벨링을 하는 기능이다. 바로 예시를 들어보자면, 마스터노드가 pod를 생성하려고 할때, 이 pod가 생성될 노드를 골라야 하는 상황이 생겼다고 하자. 물론 우리는 예전에 pod yaml에서 resource로 cpu나 ram을 지정해줘서 알아서 선택적으로 배치 혹은 펜딩상태가 되도록 조절할 수 있었다. 하지만 nodelabel은 아예 리소스분량뿐 아니라, 여러가지 방향으로 라벨링만으로 리소스들을 배치시킬 수 있다. worker node1는 아주 좋은 컴..

# 레이블 개념 난 라벨링이라고 했는데.. 일본식 발음방법이고 레이블이라고 한다. 컨트롤러와 서비스를 가지고 설명을 할때 써먹었던건데.. 레이블은 셀렉터로 인식할 레이블들을 말한다. 공식문서에서 deployment yaml양식을 가져와보면, apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment labels: app: nginx spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80 저기 d..

실제로 ingress 컨트롤러로 dog.com이라는 사이트를 만들어 볼 예정이다. # 먼저 기본 namespace를 바꾸자. 쿠버네티스 namespace # 기본 개념 네임스페이스는 리소스들을 분리하고 관리하는거다. 그냥 컴퓨터에서 디렉토리 같은 분류라고 보면 될 것같다. 물론 디렉토리안에 또 다른 디렉토리 넣는것처럼 네임스페이스 안에 jacobowl.tistory.com 이전에 namespace를 포스팅하면서 기본 namespace를 바꿀 수 있는걸 봤었는데 실습을 하기위해서 우리는 기본 namespace를 ingress-nginx네임스페이스로 바꿀 예정이다. kubectl get namespace 이전 ingress설치 포스팅에서 deploy.yaml을 create해주면 ingress-nginx라는 ..

# 설치 사실 난 이미 다 설치해놨는데 실제로 설치할때 경로찾는게 중요할것 같아서 조금 자세하게 적어볼거다. k8s공식문서에서 ingress controller를 검색하고 저 링크로 들어간다. 그리고 저기에 쿠버네티스가 서포트 하고 있따는 aws,gce,nginx중 선택해야하는데 우리는 온프레미스 환경에서 텍스트할거니까 nginx를 선택하자. 그럼 깃헙 페이지가 뜨고 저기서 getting started를 누르면 Installation Guide - Ingress-Nginx Controller Installation Guide There are multiple ways to install the Ingress-Nginx Controller: with Helm, using the project reposit..

# 개념 얘는 서비스타입이라곤 뭐한데.. 실제 한가지 서비스처럼 사용하는거다. 일단 clusterIP타입 service이지만, clusterIP를 None으로 해놔서 단일진입점이 없다. 그럼 얘는 어따가 쓰는걸까? # yaml양식 apiVersion: v1 kind: Service metadata: name: headless-service spec: type: ClusterIP clusterIP: None selector: pod-service: muzzi #clusterIP: 10.96.1.1 ports: - protocol: TCP port: 80 targetPort: 80 기초적인 clusterIP타입인 yaml양식과 같지만 저기 clusterIP필드에 None으로 명시적으로 적어줬다. 만약 clu..

## 쿠버네티스 환경에서 도메인서버 # 일단 뜯어볼까? 쿠버네티스 환경에서는 도메인으로 서로 통신 할 수 있다. 도메인 서버를 확인하려면, kubectl get pods --all-namespace -o wide 모든 네임스페이스에서 모든 pod를 확인해보았다. 저기 보이는 core dns가 쿠버네티스 환경에서 dns서버 역할을 하는것이다. 난 master node에 있을줄 알았는데 worker노드에도 있는것같음.. 참고로 얘는 kube-system 네임스페이스에서 동작한다. 여기서 보이는 coredns파드들은 또한 clusterIP서비스로 묶이는데, 이게 바로 kube-dns서비스이다. kubectl get service -n kube-system 이 kube-dns서비스는 clusterIP타입이고, ..

## clusterIP service/ 개념 & test # deployment를 쓰는이유? 고가용성! 이렇게 deployment로 생성된 세개의 nginx pod들이 있다고 가정하자. 일단 우리가 deployment컨트롤러로 동일한 pod 세 개를 운영하는 목적은 뭐였니? 고가용성을 보장하 jacobowl.tistory.com 이전 포스팅에서 실제로 서비스를 만들어보면서 만든게 clusterIP타입 서비스이다. 서비스를 만들때 type을 딱히 안정해주면 알아서 clusterIP타입 서비스를 만들어준다. 떄문에 자세한 설명은 생략을 하려한다. 부족한부분을 몇개 추가하자면.. # yaml형식 + clusterIP 커스텀 apiVersion: v1 kind: Service metadata: name: my-..

# deployment를 쓰는이유? 고가용성!이렇게 deployment로 생성된 세개의 nginx pod들이 있다고 가정하자.일단 우리가 deployment컨트롤러로 동일한 pod 세 개를 운영하는 목적은 뭐였니?고가용성을 보장하기 위해서다. 고가용성이란 만약 노드 하나가 죽거나 한가지 pod가 죽거나 등등 뭐 ㅈ같은 일이 생겼을 경우 서비스가 죽게 될 것인데, 이거를 대비하려고 deployment컨트롤러로 동일한 pod들을 replicas 설정을 통해 만들어줬다.  # 헐이렇게 세개의 동일한 pod들을 배포해줬고 deployment컨트롤러가 가용성을 보장해준다. 근데 이 세개의 pod들안에서 nginx컨테이너가 띄운 웹사이트들은 다 똑같지만 접속하려면 서로 다른 아이피로 접속을 해야한다. 그러면 의미가..