1. 소개 네임스페이스는 쿠버네티스의 리소스들을 분리하기 위해 사용하는 방법이다. 쿠버네티스를 설치하면 기본적으로 default 네임스페이스, 쿠버네티스 시스템 자원들이 있는 kube-system, 모든 사용자가 접속할 수 있는 kube-public의 3가지 네임스페이스가 생성된다. 유저가 중요한 내부 객체를 건드리는 것을 막기 위해 시스템 자원들을 별도의 네임스페이스로 구분한 것이다. 네임스페이스로 얻을 수 있는 또 다른 이점은 자원 리밋 지정이다. 네임스페이스 별로 자원들의 최대 할당량을 지정하여 다른 네임스페이스에 영향을 끼치지 않도록 할 수 있다. LimitRange 오브젝트로 네임스페이스에 실행되는 단일 컨테이너에 대한 리소스 요청량, 상한크기의 기본값(default)이나 최소, 최대 제한값을 ..
쿠버네티스를 접근하는 사용자는 관리자, 개발자, 서드파티 프로그램들로 분류할 수 있다. (어플리케이션 엔드유저에 대한 인증은 어플리케이션 단에서 수행한다) 쿠버네티스에서는 자체적인 사용자 인증 기능은 제공하지 않고 파일을 이용하거나 LDAP 등 별도 계정 기능을 이용해야 한다. 단 외부 서비스들이 사용하는 '서비스 계정(sa)'은 생성하는 기능을 제공한다. 아래 파일 기반으로 한 인증 방식은 보안에 취약하므로 권장하지 않는 방식이다. 1. File 파일을 이용한 인증 방법은 csv형태로 패스워드, 계정, uid, group 을 담은 파일을 생성 후 kube-apiserver 정의 파일에 옵션으로 파일을 지정하는 것이다. —basic-auth-file=user-details.csv apiVersion: v..
쿠버네티스의 파드도 컨테이너와 마찬가지로 삭제/생성을 반복하므로 데이터를 별도 볼륨에 저장할 필요가 있다. 1. Volumes & Mounts 가장 간단하게 호스트 디렉터리를 마운트하는 방법 spec: containers: - image: alpine name: alpine volumeMounts: - mountPath: /opt name: data-volume volumes: - name: data-volume hostPath: path: /data type: Directory위와 같은 방법으로는 여러 노드의 클러스터 구성에서 사용이 불가능하다. 각 호스트마다 데이터가 공유되지 않기 떄문이다. 실제 클러스터 환경에서 운영하려면 스토리지 솔루션을 사용해야 한다. NFS GlusterFS AWS EBS v..
1. Network Policy Network Policy는 쿠버네티스의 Pod에 적용할 수 있는 방화벽 정책 기능이라고 볼 수 있다. 기본적으로 쿠버네티스 클러스터 내부의 모든 파드와 객체간에는 네트워크 상으로 통신이 가능하다. 감사나 내부 정보보안 규정으로 Web 서버에서 DB서버로의 접근을 차단해야 하는 경우와 같은 상황에서 사용할 수 있다.적용하는 Pod 기준으로 들어오는 트래픽을 Ingress, 나가는 트래픽을 Egress라고 한다. #policy-definition.yaml apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: db-policy spec: podSelector: matchLabels: role: db poli..
1. API Groups 권한관리를 이해하기 전에 API Groups에 대해 알아야 한다. kube-apiserver는 [API]-[Resources]-[Verbs] 구조로 API를 제공한다. 예를 들어 가장 자주 사용하는 kubectl get deployment 커맨드를 보면 /apps/v1/deployments/get를 호출하는 것을 알 수 있다. 이 동작과 관련된 API를 이해해야 권한을 관리 할 수 있다. 2. Authorization 앞선 인증 절차를 거쳐 접근을 허용한 사용자가 어떤 동작까지 수행할 수 있는지에 대해 관리하는 것이 권한 관리이다. 권한 모드에는 6가지가 있고 kube-apiserver의 yaml 파일에서 설정할 수 있다. NODE : 클러스터의 다른 노드(kubelet)에 대한..
1. 백업 대상 1-1. 리소스 설정 파일 yml 파일을 github과 같은 리파지터리를 이용한다면 별도 백업을 걱정할 필요없고 장애 시에 설정 파일을 이용해 복구가 가능하다. 그러나 명령어를 통한 선언적 방식으로 객체들을 생성했다면 yml 파일이 남아있지 않을 것이다. 이 때는 kube-apiserver에 질의하여 현재 설정된 모든 값들을 파일로 생성할 수 있다. 이런 질의와 설정파일 백업을 해주는 상용툴(VELERO 등)도 있다. kubectl get all —all-namespaces -o yaml > all-deploy-services.yaml 1-2. ETCD 클러스터 다른 방법으로는 현재 상태값에 대한 데이터가 저장되어 있는 ETCD 클러스터 자체를 백업하는 방법이 있다. etcd 클러스터가 ..