- 오일러투어트리
- 2023 SW - IT Contest
- Delaunay triangulation
- CodeForces
- fortune's algorithm
- BOJ 30026
- BOJ 30029
- 27173
- 누텔라트리(hard)
- 세그먼트 트리
- voronoi diagram
- 2023 Engineering Pair
- 수열과 쿼리 43
- 알고리즘
- BOJ 31226
- 2025acpc
- boj 30788
- BOJ 30028
- solved.ac
- BOJ17139
- hhs2003
- 컴퓨터융합학부
- K8s
- 27114
- dx dy
- 느리게 갱신되는 세그먼트 트리
- BOJ 30027
- 충남대학교 2023 SW - IT
- boj23054
- 백준
황현석 일지
Kubernetes - 01 본문
Kubernetes를 한번 써본 적은 있었다. Skill Level 어쩌구에 ID를 받아서, 여러가지 배우고 있지만, Kubernates를 빠르게 원리부터 응용까지 배워 놓고자 한다. 하루에 한 셋트씩 보면 14일컷은 나겠지.. 대충 목표가 그러하다.
대충 대충 흘겨듣는 식으로 인강을 보는데, 짜잘하게 암기해야 하는 내용들이 많길래, 빠른 인강 시청과, 내용 정리 주된 공부는 복습으로 방향을 잡았다. 인강 볼 때, 좀 따라쳐보고 직접 노드 파드 실행해보는데, 공부 시간대비 공부량이 생각보다 적은 것 같다.
apiVersion: v1
kind: Pod
metadata:
name: nginx-pod
labels:
app: nginx-app
spec:
containers:
- name: nginx-container
image: nginx:latest
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: nginx-service
spec:
selector:
app: nginx-app
type: NodePort
ports:
- port: 80 # ClusterIP에서 사용할 포트
targetPort: 80 # Pod의 컨테이너 포트
nodePort: 30080 # 외부에서 접근 가능한 노드 포트 (30000~32767 사이)
namespace 는 말그대로 분리를 위한 개념이다. 한 컴퓨터에 여러가지 서비스를 운영할 수 있는데, namespace로 분리를 해놓아 관리가 쉽게 하기 위한 것이다.
CLI로 선언형 프로그래밍을 하는 것은 별로 선호 하지 않고, 유지 보수에 정말 최악이라고 생각하기 때문에 웬만하면 yaml파일을 만들어 놓고, 적용시키는 쪽으로 공부 할 것 같다.
kubectl create ns <namespace_name>
kubectl apply -f <file_name> -n <namespace_name>
- metadata.name : 리소스 자체의 이름
- metadata.labels.app : 리소스를 분류 하고 찾을 때 쓰는 라벨, 값.
yaml파일을 보면 두개의 리소스를 정의하기 위해 '---' 를 넣어서 분리해서 인식시킬 수 있음.
하나의 pod에는 여러개의 컨테이너가 들어갈 수 있음. 따라서, Pod를 명시적으로 선언 할 때는, spec.containers 는 배열타입이고 여러개의 컨테이너를 동시에 넣을 수 있음.
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
- name: sidecar
image: my-sidecar-image
ports:
- containerPort: 9000
kubectl의 Service 리소스는 마지막에 ports로 3가지를 넣는다.
port : 다른 노드에서 내부적으로 사용하기 위한 포트
targetPort : pod로 매핑시켜줄 포트
nodePort : 외부 에서 들어오는 포트 client 단에서 30000-32767 사이의 포트를 선택해야하며, 이것은 kube-apiserver 옵션의 --service-node-port-range의 기본설정을 바꾸면 변경 시킬 수 있다.
Configmap 은 일단 같은 네임스페이스에 있어야 참조할 수 있다.
apiVersion: v1
kind: ConfigMap
metadata:
name: my-config
data:
key: "This is a config value"
Configmap은 다음과 같이 키를 가져다가 원하는 이름으로 하나하나씩 환경변수로 넣어줄 수 있다.
containers:
- name: nginx-container
image: nginx:latest
env:
- name: CONFIG_VALUE_1
valueFrom:
configMapKeyRef:
name: my-config
key: key1
- name: CONFIG_VALUE_2
valueFrom:
configMapKeyRef:
name: my-config
key: key2
아니면 다음과 같이 Configmap 자체의 모든 key들을 한번에 넣어 줄 수도 있다.
containers:
- name: nginx-container
image: nginx:latest
envFrom:
- configMapRef:
name: my-config
Kubernetes에서 ConfigMap을 볼륨으로 마운트하면, 컨테이너 내부의 지정한 마운트 경로에 ConfigMap의 각 key가 파일명으로 생성되고, 해당 key의 value가 그 파일 내용으로 들어갑니다.
예를 들어, 다음과 같은 ConfigMap이 있다고 가정해봅니다.
Kubernetes에서 ConfigMap을 볼륨으로 마운트하는 방법과 예시를 소개합니다. 이렇게 하면 ConfigMap에 저장된 데이터를 컨테이너 내 파일로 사용할 수 있습니다.
1. ConfigMap 예시
apiVersion: v1
kind: ConfigMap
metadata:
name: myconfigmap
data:
app.properties: |
mode=production
log_level=info
database.url: "mysql://user:pass@host:3306/dbname"
2. Pod에 ConfigMap 볼륨 마운트 예시
apiVersion: v1
kind: Pod
metadata:
name: example-pod
spec:
containers:
- name: app-container
image: busybox
command: ["/bin/sh", "-c", "cat /etc/config/app.properties && sleep 3600"]
volumeMounts:
- name: config-volume
mountPath: /etc/config
readOnly: true
volumes:
- name: config-volume
configMap:
name: myconfigmap
위 예시에서 myconfigmap에 저장된 각 키는 컨테이너 내 /etc/config 경로에 파일로 생성됩니다. 예를 들어, app.properties와 database.url 파일이 생성되고, 각 파일 내용은 ConfigMap의 값과 동일합니다.
컨테이너 내에서 cat /etc/config/app.properties 명령어로 파일 내용을 확인할 수 있습니다.
이 방법은 애플리케이션이 파일 기반 설정을 요구할 때 유용하며, ConfigMap을 쉽게 업데이트하고 적용할 수 있는 좋은 방법입니다.
apiVersion: v1
kind: ConfigMap
metadata:
name: example-config
data:
my-key: "hello world"
config.json: '{ "port": 8080 }'
이 ConfigMap을 컨테이너 내부의 /etc/config 경로에 마운트하면, 아래와 같이 파일들이 생성됩니다.
/etc/config/my-key파일에는hello world라는 내용이 들어갑니다./etc/config/config.json파일에는{ "port": 8080 }라는 JSON 내용이 들어갑니다.
컨테이너 내에서 해당 파일을 조회하는 예시는 다음과 같습니다.
cat /etc/config/my-key
# 출력: hello world
cat /etc/config/config.json
# 출력: { "port": 8080 }
따라서, 애플리케이션이나 스크립트는 마운트된 디렉터리 내 파일들을 읽어 ConfigMap에 저장된 설정 값을 활용할 수 있습니다.
이 방법은 특히 환경변수로 전달하기 어려운 복잡한 설정 파일이나 다수의 설정 값을 전달할 때 매우 유용합니다.
1. Kubernetes Secret은 기본적으로 Base64 인코딩만 한다
Secret 리소스에 저장된 데이터는 base64 인코딩 되어 저장됩니다.
base64는 암호화가 아니라 단순히 인코딩 방식일 뿐이라서,
누구나 쉽게 디코딩해서 원본 데이터를 볼 수 있습니다.
2. 그렇다면 왜 Secret을 사용할까?
(1) Kubernetes 리소스와 통합된 관리
Secret은 ConfigMap과 같이 쿠버네티스 네이티브 리소스라서,
Pod, Deployment, ServiceAccount 등 쿠버네티스 리소스와 쉽게 연동됩니다.
예를 들어 Pod에 환경변수 또는 볼륨으로 손쉽게 주입할 수 있습니다.
(2) RBAC를 통한 접근 통제
Secret은 Kubernetes API 서버에서 RBAC(Role-Based Access Control) 정책으로 접근 권한을 관리할 수 있습니다.
ConfigMap보다 민감한 데이터라는 점을 감안해 별도의 권한 관리가 가능합니다.
(3) 클러스터 내 안전한 저장소
Secret은 etcd에 저장되는데, etcd 자체에 대해 암호화(Encryption at Rest)를 적용할 수 있습니다.
즉, 클러스터 설정에 따라 etcd 내에서는 Secret 데이터를 암호화할 수 있습니다.
(4) 네트워크 통신 시 암호화
Kubernetes API 서버와 클라이언트 간 통신은 TLS(암호화)로 보호됩니다.
따라서 Secret이 API 서버를 통해 전달될 때는 네트워크에서 암호화됩니다.
(5) 편리한 관리와 자동화 지원
Secret은 kubectl create secret 같은 CLI 커맨드로 쉽게 생성하고 업데이트할 수 있습니다.
CI/CD, Helm, Kustomize 등 도구에서 Secret을 별도로 관리할 수 있어 편리합니다.
Kubernetes Secret을 이용한 MySQL 루트 계정 초기화
MySQL 컨테이너를 Kubernetes에서 구동할 때, 보안상 중요한 루트 계정 비밀번호와 사용자 계정 정보를 직접 YAML에 평문으로 넣는 것은 위험합니다. 이를 위해 Kubernetes Secret 리소스를 사용해 민감 정보를 안전하게 관리할 수 있습니다.
1. Secret 정의
Secret은 base64 인코딩된 key-value 쌍으로 데이터를 저장합니다. 아래 예제는 username과 password를 저장한 Secret입니다.
apiVersion: v1
kind: Secret
metadata:
name: my-secret
type: Opaque
data:
username: aHkzb25z # "hy3ons"를 base64 인코딩한 값
password: MWYyZDFlMmU2N2Rm # "1f2d1e2e67df"를 base64 인코딩한 값
2. MySQL Deployment 예제
Secret에 저장한 데이터를 환경 변수로 컨테이너에 주입해 MySQL 루트 및 사용자 계정을 초기화할 수 있습니다.
apiVersion: apps/v1
kind: Deployment
metadata:
name: mysql-deployment
spec:
replicas: 1
selector:
matchLabels:
app: mysql
template:
metadata:
labels:
app: mysql
spec:
containers:
- name: mysql
image: mysql:latest
env:
- name: MYSQL_USER
valueFrom:
secretKeyRef:
name: my-secret
key: username
- name: MYSQL_PASSWORD
valueFrom:
secretKeyRef:
name: my-secret
key: password
- name: MYSQL_ROOT_PASSWORD
valueFrom:
secretKeyRef:
name: my-secret
key: password
ports:
- containerPort: 3306
'Kubernates' 카테고리의 다른 글
| 클라우드 서버 구축 트러블 슈팅 - 01 K3s API Server Connection (0) | 2026.01.14 |
|---|