1. Probe 개념 1.1. Readiness, Startup 파드의 상태를 체크 할 수 있는 2가지의 지표가 존재 get을 통해 확인 가능한 STATUS 정보 describe을 통해 확인 가능한 Conditions 정보 STATUS와 Conditions이 Running/True 상태임에도 불구하고 컨테이너가 초기화 프로세스(cold start)를 거치는 경우 파드에 정상적으로 접근 불가 컨테이너 생성 및 HTTP 요청에 대한 응답을 할 수 있는지 확인하기 위해 Readiness Probe를 활용 컨테이너에 배포된 서비스의 초기화 프로세스(cold start)가 완료되어 서비스를 제공할 수 있는지 확인하기 위해 Startup Probe를 활용 1.2. Liveness 파드에 장애가 발생하는 경우 k8s..
1. 개념 NetworkPolicy의 Ingress와 개념은 같지만 컨셉이 다름 클러스터 외부에서 HTTP/s를 통한 클러스터 내부로의 요청을 처리하는 규칙 예를들어 클러스터에 /member 와 /product 두 개의 애플리케이션을 운영중이고 개별적인 요청을 핸들링하고자 할 때 Ingress 활용 2. 실습 링크 참고 3. Ingress 핸들링 Ingress 리소스 확인 : kubectl get ingress -A Ingress 리소스 설정 확인 : kubectl describe ingress [인그레스_이름]
1. 개념 PVC를 이용해 볼륨을 손쉽게 요청할 수 있으나 운영자는 PV로 사용할 볼륨을 수동으로 프로비저닝해야 함(Static Provisioning 방식) 이런 불편함을 해결하기 위해 자동으로 볼륨을 생성·할당하는 StorageClass를 사용(Dynamic Provisioning 방식) 2. StorageClass 생성 StorageClass 생성 apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: demo-sc volumeBindingMode: WaitForFirstConsumer provisioner: kubernetes.io/aws-ebs parameters: type: io1 iopsPerGB: "10" fsType: ext4 ..
1. 개념 영속성을 보장할 수 없는 파드에 데이터를 저장할 경우 언제든 데이터가 사라질 가능성 존재 따라서 파드의 생명주기와 무관하게 저장이 유지되는 데이터 저장소가 필요한데 이런 요구사항을 만족하기 위한 개념이 PV(PersistentVolume)와 PVC(PersistentVolumeClaim) PV : 데이터를 저장할 볼륨. 볼륨을 생성하고 이를 클러스터에 등록한 것 PVC : 필요한 저장 공간·RW모드 등 요청사항을 기술한 명세로서 PV에 전달하는 요청. PV와 바인딩을 하는 목적으로 사용 2. PV 생성 demo-pv라는 PV 생성 apiVersion: v1 kind: PersistentVolume metadata: name: demo-pv spec: capacity: storage: 100Mi..
1. 개념 쿠버네티스에서 각 파드는 기본적으로 서로간에 모든 통신이 가능한 상태 때문에 DB처럼 보안적으로 중요한 파드에 대해 접근을 제어하기 위하여 NetworkPolicy 서비스 활용 파드 생성 시 labels에 명시한 key : value를 기준으로 NetworkPolicy 적용 2. NetworkPolicy 상황별 설정 NetworkPolicy를 설정하지 않은 경우 모든 파드에서 DB로 접근 가능 특정 파드에서만 접근을 허용하고자 하는 경우 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: db-policy namespace: prod spec: podSelector: matchLabels: role: db policyTyp..
1. 개념 쿠버네티스는 컨테이너 실행 시 기본으로 root 권한으로 실행 root 권한에서의 컨테이너 실행을 방지하기 위해 파드 또는 컨테이너 단위로 실행시킬 PID를 지정 2. SecurityContext 적용 비교 SecurityContext를 적용하지 않은 경우(root로 실행) apiVersion: v1 kind: Pod metadata: name: security-context-demo-1 spec: containers: - name: sec-ctx-demo image: busybox:1.28 command: [ "sh", "-c", "sleep 1h" ] PID 확인 SecurityContext를 파드 단위로 적용한 경우(PID 1000으로 실행) apiVersion: v1 kind: Pod ..
1. 개념 애플리케이션 배포 시 애플리케이션의 이미지를 도커등 퍼블릭 레포에서 다운 애플리케이션 이미지 변조에 따른 리스크를 없애기 위해 프라이빗 레포지토리 사용 가능 2. 시크릿 설정 프라이빗 레포지토리에 접속하기 위해 크레덴셜을 저장한 시크릿 생성 kubectl create secret docker-registry private-reg-cred --docker-username=[레포지토리_유저네임] --docker-password=[레포지토리_패스워드] --docker-server=[레포지토리_주소] 시크릿 생성 확인 3. 이미지 풀 설정 애플리케이션 이미지를 프라이빗 레포지토리에서 다운받도록 설정 imagePullSecrets : 앞서 생성한 시크릿 image : 프라이빗 레포지토리 주소와 다운받을..
1. 개념 쿠버네티스의 계정에는 2종류(유저 어카운트, 서비스 어카운트)가 존재 유저 어카운트 : 운영자 또는 개발자 등이 클러스터를 운영하는데 활용 서비스 어카운트 : 쿠버네티스 서비스 또는 써드파티 서비스(프로메테우스, 젠킨스 등)가 사용하는 계정 서비스 어카운트 생성 시 자동으로 secret을 생성하고, JWT 값의 토큰을 생성(예전) 서비스 어카운트 생성 후 서비스 어카운트가 사용할 토큰을 생성해야함(현재) 모든 네임스페이스에는 default 서비스 어카운트가 존재하며, 서비스 어카운트를 별도로 지정하지 않는 경우 자동으로 default 서비스 어카운트를 사용 서비스 어카운트 생성 후 추가적으로 RBAC 또는 클러스터 롤로 권한을 부여해야 함 2. ServiceAccount 핸들링 서비스 어카운트..
1. 개념 네임스페이스 단위에서의 리소스 접근을 핸들링하는 RBAC과는 다르게 클러스터 단위로 접근권한을 제어 2. ClusterRole Role & RoleBinding YAML ClusterRole apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: secret-reader rules: - apiGroups: [""] resources: ["secrets"] verbs: ["get", "watch", "list"] 9번 라인 : 핸들링할 API가 포함된 그룹 10번 라인 : 핸들링할 API 종류 11번 라인 : 핸들링하고자 하는 액션 ClusterRoleBinding apiVersion: rbac.authorizatio..
1. 개념 쿠버네티스는 네임스페이스 단위에서의 유저 리소스 접근을 핸들링하기 위한 4가지 접근제어 방식이 존재 Node : 스케줄링 된 파드의 kubelet에서 접근제어 ABAC : 속성기반 접근제어 RBAC : 역할기반 접근제어 Webhook : POST 요청에 대한 접근제어 2. RBAC Role & RoleBinding YAML Role apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: default name: test-pod-reader rules: - apiGroups: [""] # "" means api resources: ["pods"] verbs: ["get", "watch", "list"] resourceNa..
