...
| 코드 블럭 |
|---|
root@k8s-master01:~/kb# kubectl get pod NAME READY STATUS RESTARTS AGE configmap-test-779ff45747-f4969 1/1 Running 0 80s root@k8s-master01:~/kb# kubectl exec -it configmap-test-779ff45747-f4969 -- bash root@configmap-test-779ff45747-f4969:/# env | grep LOG_LEVEL LOG_LEVEL=info |
...
4.
...
시크릿
비밀번호, OAuth 토큰, ssh 키와 같은 민감한 정보를 저장하는 용도로 사용됩니다.
시크릿 생성 시 데이터는 base64로 인코딩되어 저장됩니다.
컨피그맵은 보안/암호화를 제공하지 않기 때문에, 저장하려는 데이터가 기밀인 경우, Secret을 사용하여 데이터를 비공개로 유지합니다.
시크릿은 ETCD에 암호화되지 않은 상태로 저장되기 때문에, API 접근 권한이 있는 모든 사용자는 시크릿을 조회/수정 할 수 있습니다.
TLS 인증서를 시크릿으로 저장하여 사용하는 경우도 많습니다.
secret 리소스의 type 필드로 타입을 명시 할 수 있습니다.
빌트인 타입 | 사용처 |
|---|---|
| 임의의 사용자 정의 데이터 |
| 서비스 어카운트 토큰 |
| 직렬화 된(serialized) |
| 직렬화 된 |
| 기본 인증을 위한 자격 증명(credential) |
| SSH를 위한 자격 증명 |
| TLS 클라이언트나 서버를 위한 데이터 |
| 부트스트랩 토큰 데이터 |
...
4.1 불투명(Opaque) 시크릿 사용
...
(1
...
) 명령어로 시크릿 생성
| 코드 블럭 |
|---|
root@k8s-master01:~/kb# cat prod-user.txt prod-user root@k8s-master01:~/kb# cat prod-pass.txt prod-pass root@k8s-master01:~/kb# kubectl create secret generic prod-user --from-file=./prod-user.txt --from-file=./prod-pass.txt secret/prod-user-secret created root@k8s-master01:~/kb# kubectl get secrets NAME TYPE DATA AGE prod-user-secret Opaque 2 4s root@k8s-master01:~/kb# kubectl get secrets prod-user-secret -o yaml apiVersion: v1 data: prod-pass.txt: cHJvZC1wYXNzCg== prod-user.txt: cHJvZC11c2VyCg== kind: Secret metadata: creationTimestamp: "2023-03-13T02:35:54Z" name: prod-user-secret namespace: default resourceVersion: "1226226" uid: 41a2cb2d-97f2-41bc-824f-c0c2783ec678 type: Opaque *원래 값 확인방 root@k8s-master01:~/kb# echo cHJvZC11c2VyCg== | base64 --decode prod-user |
...
(2) yaml 파일로 시크릿 생성
yaml 파일로 생성시 필요 값들을 base64로 인코딩된 값을 넣어야 합니다.
...
| 코드 블럭 |
|---|
root@k8s-master01:~/kb# kubectl apply -f prod-user-secret.yaml
root@k8s-master01:~/kb# kubectl get secrets
NAME TYPE DATA AGE
prod-user Opaque 2 5s
root@k8s-master01:~/kb# kubectl get secrets prod-user -o yaml
apiVersion: v1
data:
password: cHJvZC1wYXNz
username: cHJvZC11c2Vy
kind: Secret
metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"v1","data":{"password":"cHJvZC1wYXNz","username":"cHJvZC11c2Vy"},"kind":"Secret","metadata":{"annotations":{},"name":"prod-user","namespace":"default"},"type":"Opaque"}
creationTimestamp: "2023-03-13T02:49:45Z"
name: prod-user
namespace: default
resourceVersion: "1228228"
uid: a5eff12c-2329-4697-92f7-f252a4f724ba
type: Opaque
|
...
(3) 시크릿 사용
| 코드 블럭 |
|---|
apiVersion: apps/v1
kind: Deployment
metadata:
name: secretapp
labels:
app: secretapp
spec:
replicas: 1
selector:
matchLabels:
app: secretapp
template:
metadata:
labels:
app: secretapp
spec:
containers:
- name: testapp
image: nginx:1.19
ports:
- containerPort: 8080
env:
- name: SECRET_USERNAME
valueFrom:
secretKeyRef:
name: prod-user
key: username
- name: SECRET_PASSWORD
valueFrom:
secretKeyRef:
name: prod-user
key: password |
| 코드 블럭 |
|---|
root@k8s-master01:~/kb# kubectl exec -it secretapp-69d4797f86-7r95g -- bash root@secretapp-69d4797f86-7r95g:/# env | grep SECRET SECRET_USERNAME=prod-user SECRET_PASSWORD=prod-pass |
2. Label & Selector
Label
Label은 Pod와 같은 객체에 연결된 키/값 쌍입니다.
리소스를 논리적인 그룹으로 나누거나, 식별의 편의를 위해 붙이는 이름표입니다.
Label은 생성 시 객체에 첨부할 수 있으며 나중에 언제든지 추가 및 수정할 수 있습니다.
Selector
특정 Label에 해당하는 객체를 식별하고 검색할 수 있습니다.
2.1 Node Label
...
| 코드 블럭 |
|---|
# Node Label 확인
kubectl get nodes --show-labels
# Node Label 추가
kubectl label nodes k8s-worker01 svc=web |
2.2 Pod Selector
pod-label.yml
| 코드 블럭 |
|---|
apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
env: test
spec:
containers:
- name: nginx
image: nginx
imagePullPolicy: IfNotPresent
nodeSelector:
svc: web |
3. 쿠버네티스 볼륨
PV(PersistentVolume): PV는 관리자가 프로비저닝했거나 스토리지 클래스를 사용해 동적으로 프로비저닝한 클러스터의 스토리지입니다. PV는 볼륨과 같은 볼륨 플러그인이지만 PV를 사용하는 개별 Pod와 독립적인 수명 주기를 가집니다.
PVC(PersistentVolumeClaim): PVC는 사용자가 볼륨을 사용하기 위해 PV에 하는 스토리지 요청입니다. Pod와 유사하게 Pod는 노드 리소스를 소비하고, PVC는 PV 리소스를 소비합니다.
3.1 PV의 Lifecycle
...
3.1.1 Provisioning
PV를 생성하는 단계로 프로비저닝 방법에는 두 가지가 있습니다.
정적 프로비저닝
정적 프로비저닝은 클러스터 관리자가 미리 적정 용량의 PV를 만들어 두고 사용자의 요청이 있을 시 미리 만들어 둔 PV를 할당하는 방식입니다.
사용할 수 있는 스토리지 용량에 제한이 있을 때 유용합니다.
동적 프로비저닝
동적 프로비저닝은 사용자가 PVC를 거쳐서 PV를 요청했을 때 생성해 제공합니다.
클러스터에 사용자가 원하는 만큼의 스토리지 용량이 있다면, 원하는 용량만큼을 생성해서 사용할 수 있습니다.
3.1.2 Binding
바인딩은 프로비저닝으로 생성된 PV를 PVC와 연결하는 단계입니다. PVC에서 원하는 스토리지 용량과 접근방법을 명시해서 용청하면 거기에 맞는 PV가 할당됩니다. PV와 PVC의 매핑은 1대1 관계입니다.
3.1.3 Using
PVC는 Pod에 설정되고, Pod는 PVC를 볼륨으로 인식해서 사용합니다. 클러스터는 PVC를 확인하여 바인딩된 PV를 찾고 해당 볼륨을 Pod에서 사용할 수 있도록 해줍니다. 할당된 PVC는 파드를 유지하는 동안 계속 사용되며, 시스템에서 임의로 삭제할 수 없습니다.
3.1.4 Reclaiming
사용이 끝난 PVC는 삭제되고, PV를 초기화(reclaim)하는 과정을 거칩니다. PV는 기존에 사용했던 PVC가 아니더라도 다른 PVC로 재활용이 가능합니다.
PV 초기화 정책
Retain: PV의 데이터를 그대로 보존합니다.
Recycle: 재사용하게 될 경우 기존의 PV 데이터들을 모두 삭제 후 재사용합니다.
Delete: 사용이 종료되면 해당 볼륨을 삭제합니다.
3.2 PV 생성
| 코드 블럭 |
|---|
apiVersion: v1
kind: PersistentVolume
metadata:
name: test-pv
labels:
name: test-pv
spec:
capacity:
storage: 1Gi
accessModes:
- ReadWriteMany
hostPath:
path: "/test/volume"
# Value
- capacity: 사용할 용량을 설정합니다.
- accessModes:특정 접근 모드를 선택합니다.
- hostPath: 노드에 저장되는 디렉토리를 설정합니다.
# 적용하기
kubectl apply -f test-pv.yaml
# PV 조회
kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
test-pv 1Gi RWX Retain Available 15s |
3.3 PVC 생성
| 코드 블럭 |
|---|
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: test-pvc
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 1Gi
kubectl apply -f test-pvc.yaml
# PV, PVC 조회
kubectl get pv,pvc
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
persistentvolume/test-pv 1Gi RWX Retain Bound default/test-pvc 2m22s
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
persistentvolumeclaim/test-pvc Bound test-pv 1Gi RWX 18s
=> PV와 PVC가 연결되어 PV가 Bound 상태로 변경된 것을 확인할 수 있습니다. |
3.4 PVC를 사용할 Pod 생성
...