Kubernetes 이야기

Jenkins는 소프트웨어 개발 시 지속적 통합(CI) 서비스를 제공하는 툴로써 대시보드,Pipeline, 다양한 플러그인 등을 지원한다. Jenkins는 Kubernetes환경이 나오기 전부터 사용되던 툴로 PC 또는 VM 환경에 설치하여 운영을 많이 해 왔고, 다양한 플러그인을 제공, Groovy Script를 기반으로 다양한 프로세스를 만들 수 있다는게 장점이다. 이번 글에서는 Jenkins를 Kubernetes의 Pod로 실행하고, Container image build 후 Kubernetes에 Deploy하는 절차를 알아보자. Jenkins는 Master 단독으로도 CI/CD 환경을 구축할 수 있지만, 빌드하는 프로젝트가 많은 경우 Master / Slave 구조로 운영한다. Jenkins설치는..

Deployment나 ReplicaSet으로 Pod를 여러개 생성하는 경우 Service 를 이용하여 Load Balancer 하도록 설정한다. Service는 Label을 사용하여 트래픽을 라우팅할 Pod를 선택하는 Kubernetes 추상화이다. 아래와 같은 Service 를 만든 경우 apiVersion: v1 kind: Service metadata: labels: app: production name: production namespace: test spec: ports: - name: http port: 80 protocol: TCP targetPort: 8080 selector: app: production type: ClusterIP 생성된 서비스의 상세정보를 보면 아래와 같다. # k d..

기본적으로 Pod는 kube-dns 서비스에 쿼리를 보냅니다 . Pod의 /etc/resolv.conf 에 nameserver가 자동으로 세팅된다. # cat /etc/resolv.conf search test.svc.cluster.local svc.cluster.local cluster.local nameserver 10.96.0.10 options ndots:5 Kubernetes 클러스터에서 DNS를 구현하는 가장 일반적인 방법은 서비스 추상화를 사용하는 것이다. 기본적으로 서비스 추상화는 DNAT를 사용하여 Service ClusterIP로 들어오는 요청을 DNS Pod로 균형을 맞추는 iptables 규칙 집합이다. 이 메커니즘은 conntrack 모듈을 사용하여 커널에서 처리된다. Linux ..

Canary 배포는 새 버전이 모든 사용자에게 릴리스되기 전에 초기 테스트로 일부 사용자에게 점진적으로 롤아웃하는 방법이다. 자세한 내용은 다음을 참고한다. https://kmaster.tistory.com/9 Kubernetes의 다양한 배포방식 (3) Canary 배포 Canary 배포 Canary 라는 용어는 옛날 탄광에서 나오는 유독 가스에 죽거나 다치는 일을 피하고자 광부들이 유독 가스에 민감한 카나리아를 데리고 갱도로 내려간 일에서 나온 용어로 다가온 위험 kmaster.tistory.com Nginx에서는 Canary 배포를 위한 다양한 Annotation 을 지원한다. Nginx Ingress Controller 에서 제공하는 Canary 배포 annotation 은 다음과 같다. ngin..

Prometheus 는 Kubernetes 환경에서 모니터링을 위한 사실상 표준 솔루션이다. Prometheus의 아키텍처는 다음과 같다. Prometheus는 기본적으로 Pull 방식의 모니터링 솔루션이다. 즉 모니터링 대상 App에서 Prometheus로 모니터링 수집 데이터를 Push 하는 것이 아닌 Prometheus에서 App에게 모니터링 수집 데이터를 요청하여 저장하는 방식이다. 이 Push 모드와 Pull 모드의 장단점이 있기 때문에 어느쪽이 더 아키텍처인지는 판단할 수 없다. Prometheus의 주요 기능은 다음과 같다. 메트릭 이름 및 키/값 쌍으로 식별되는 시계열 데이터가 있는 다차원 데이터 모델 이 차원을 활용 하는 유연한 쿼리 언어 인 PromQL 분산 스토리지에 의존하지 않음 단..

Kubernetes v1.22에는 Pod 보안 승인 (PSA)이라는 새로운 승인 컨트롤러가 내장되어 있다. ( 기존 Pod Security Policy ( PSP ) 는 Kubernetes 1.21부터 더 이상 사용되지 않으며 1.25버전부터 제거될 예정이다. ) PSA 컨트롤러의 목적은 Pod 보안 정책 (PSP)을 효과적으로 대체하지만 PSS( Pod 보안 표준 ) 라고 하는 공식 제어를 사용하는 것이다. PSS는 이름에서 알 수 있듯이 기술이 아니고 표준에 불과하다. 표준은 어떤 일이 일어나야 하는지를 지시하는 반면 기술(예: PSP)은 표준을 방법으로 구현한 것이다.. PSA는 PSS를 구현하는 기술로, 이 모든 것이 Kubernetes API 서버에 직접 내장되어 있다. Kubernetes v1..