Kubernetes Basics

Reading time: 16 minutes

Kubernetes Basics

이 페이지의 원래 저자는 Jorge (그의 원래 게시물을 읽으려면 여기)

Architecture & Basics

Kubernetes는 무엇을 하나요?

• 컨테이너 엔진에서 컨테이너를 실행할 수 있습니다.
• 스케줄링은 컨테이너의 임무를 효율적으로 수행합니다.
• 컨테이너를 유지합니다.
• 컨테이너 간의 통신을 허용합니다.
• 배포 기술을 허용합니다.
• 정보의 양을 처리합니다.

Architecture

• Node: pod 또는 pods가 있는 운영 체제.
• Pod: 하나의 컨테이너 또는 여러 컨테이너를 감싸는 래퍼입니다. 하나의 pod는 하나의 애플리케이션만 포함해야 합니다(그래서 일반적으로, 하나의 pod는 단지 1개의 컨테이너를 실행합니다). pod는 Kubernetes가 실행 중인 컨테이너 기술을 추상화하는 방법입니다.
• Service: 각 pod는 노드의 내부 범위에서 1개의 내부 IP 주소를 가집니다. 그러나 서비스로 노출될 수도 있습니다. 서비스는 또한 IP 주소를 가지며 그 목표는 pods 간의 통신을 유지하는 것입니다. 따라서 하나가 죽으면 새로운 대체(다른 내부 IP를 가진)가 서비스의 동일한 IP로 노출됩니다. 내부 또는 외부로 구성할 수 있습니다. 서비스는 또한 2개의 pods가 동일한 서비스에 연결될 때 로드 밸런서 역할을 합니다.
  서비스가 생성되면 각 서비스의 엔드포인트를 kubectl get endpoints를 실행하여 찾을 수 있습니다.
• Kubelet: 기본 노드 에이전트. 노드와 kubectl 간의 통신을 설정하는 구성 요소이며, pods만 실행할 수 있습니다(API 서버를 통해). Kubelet은 Kubernetes에 의해 생성되지 않은 컨테이너를 관리하지 않습니다.
• Kube-proxy: apiserver와 노드 간의 통신(서비스)을 담당하는 서비스입니다. 기본적으로 노드를 위한 IPtables입니다. 가장 숙련된 사용자는 다른 공급자의 kube-proxy를 설치할 수 있습니다.
• Sidecar container: 사이드카 컨테이너는 pod의 주요 컨테이너와 함께 실행되어야 하는 컨테이너입니다. 이 사이드카 패턴은 현재 컨테이너의 기능을 변경하지 않고 확장하고 향상시킵니다. 현재 우리는 애플리케이션이 어디에서나 실행될 수 있도록 모든 종속성을 래핑하기 위해 컨테이너 기술을 사용한다는 것을 알고 있습니다. 컨테이너는 단 하나의 작업만 수행하며 그 작업을 매우 잘 수행합니다.
• Master process:
• Api Server: 사용자가 마스터 프로세스와 통신하는 방법입니다. 인증된 요청만 허용되어야 합니다.
• Scheduler: 스케줄링은 Pods가 Kubelet이 실행할 수 있도록 노드에 매칭되도록 하는 것을 의미합니다. 어떤 노드가 더 많은 사용 가능한 자원을 가지고 있는지 결정할 수 있는 충분한 지능을 가지고 있으며, 새로운 pod를 그 노드에 할당합니다. 스케줄러는 새로운 pods를 시작하지 않으며, 단지 노드 내에서 실행 중인 Kubelet 프로세스와 통신하여 새로운 pod를 시작합니다.
• Kube Controller manager: replica sets 또는 deployments와 같은 리소스를 확인하여 예를 들어 올바른 수의 pods 또는 nodes가 실행되고 있는지 확인합니다. pod가 누락된 경우, 새로운 pod를 시작하기 위해 스케줄러와 통신합니다. API에 대한 복제, 토큰 및 계정 서비스를 제어합니다.
• etcd: 데이터 저장소, 지속적이고 일관되며 분산됩니다. Kubernetes의 데이터베이스이며 클러스터의 전체 상태를 유지하는 키-값 저장소입니다(각 변경 사항이 여기에서 기록됩니다). Scheduler 또는 Controller manager와 같은 구성 요소는 어떤 변경 사항이 발생했는지(노드의 사용 가능한 리소스, 실행 중인 pods의 수 등)를 알기 위해 이 데이터에 의존합니다.
• Cloud controller manager: AWS 또는 OpenStack에 클러스터가 있는 경우 흐름 제어 및 애플리케이션을 위한 특정 컨트롤러입니다.

여러 노드(여러 pods 실행 중)가 있을 수 있으므로 Api 서버에 대한 접근이 로드 밸런싱되고 etcd가 동기화된 여러 마스터 프로세스가 있을 수 있습니다.

Volumes:

pod가 사라질 때 잃어버리지 않아야 하는 데이터를 생성할 경우 물리적 볼륨에 저장해야 합니다. Kubernetes는 데이터를 지속하기 위해 pod에 볼륨을 연결할 수 있도록 허용합니다. 볼륨은 로컬 머신에 있거나 원격 저장소에 있을 수 있습니다. 서로 다른 물리적 노드에서 pods를 실행하는 경우 모든 pods가 접근할 수 있도록 원격 저장소를 사용해야 합니다.

Other configurations:

• ConfigMap: 서비스에 접근하기 위한 URLs를 구성할 수 있습니다. pod는 나머지 서비스(pods)와 통신하는 방법을 알기 위해 여기에서 데이터를 가져옵니다. 이곳은 자격 증명을 저장하는 데 권장되는 장소가 아님을 유의하세요!
• Secret: 비밀번호, API 키 등과 같은 비밀 데이터를 저장하는 장소입니다... B64로 인코딩됩니다. pod는 필요한 자격 증명을 사용하기 위해 이 데이터에 접근할 수 있습니다.
• Deployments: Kubernetes가 실행할 구성 요소가 표시되는 곳입니다. 사용자는 일반적으로 pods와 직접 작업하지 않으며, pods는 ReplicaSets(복제된 동일한 pods의 수)로 추상화되어 deployments를 통해 실행됩니다. deployments는 무상태 애플리케이션을 위한 것임을 유의하세요. 배포의 최소 구성은 이름과 실행할 이미지입니다.
• StatefulSet: 이 구성 요소는 데이터베이스와 같은 애플리케이션을 위해 특별히 설계되었습니다. 동일한 저장소에 접근해야 합니다.
• Ingress: 애플리케이션을 URL로 공개적으로 노출하기 위해 사용되는 구성입니다. 이는 외부 서비스를 사용하여 수행할 수도 있지만, 애플리케이션을 노출하는 올바른 방법입니다.
• Ingress를 구현하면 Ingress Controllers를 생성해야 합니다. Ingress Controller는 요청을 수신하고 확인하며 서비스를 로드 밸런싱할 엔드포인트가 될 pod입니다. Ingress Controller는 구성된 ingress 규칙에 따라 요청을 전송합니다. ingress 규칙은 서로 다른 경로 또는 심지어 서로 다른 내부 Kubernetes 서비스에 대한 하위 도메인을 가리킬 수 있습니다.
• 더 나은 보안 관행은 Kubernetes 클러스터의 어떤 부분도 노출되지 않도록 클라우드 로드 밸런서 또는 프록시 서버를 진입점으로 사용하는 것입니다.
• ingress 규칙과 일치하지 않는 요청이 수신되면 ingress controller는 이를 "Default backend"로 안내합니다. 이 매개변수의 주소를 얻으려면 ingress controller를 describe할 수 있습니다.
• minikube addons enable ingress

PKI infrastructure - Certificate Authority CA:

• CA는 클러스터 내 모든 인증서의 신뢰할 수 있는 루트입니다.
• 구성 요소가 서로를 검증할 수 있도록 허용합니다.
• 모든 클러스터 인증서는 CA에 의해 서명됩니다.
• etcd는 자체 인증서를 가지고 있습니다.
• 유형:
• apiserver cert.
• kubelet cert.
• scheduler cert.

Basic Actions

Minikube

Minikube는 전체 Kubernetes 환경을 배포할 필요 없이 Kubernetes에서 일부 빠른 테스트를 수행하는 데 사용할 수 있습니다. 마스터 및 노드 프로세스를 한 머신에서 실행합니다. Minikube는 노드를 실행하기 위해 virtualbox를 사용할 것입니다. 설치 방법은 여기에서 확인하세요.

$ minikube start
😄  minikube v1.19.0 on Ubuntu 20.04
✨  Automatically selected the virtualbox driver. Other choices: none, ssh
💿  Downloading VM boot image ...
> minikube-v1.19.0.iso.sha256: 65 B / 65 B [-------------] 100.00% ? p/s 0s
> minikube-v1.19.0.iso: 244.49 MiB / 244.49 MiB  100.00% 1.78 MiB p/s 2m17.
👍  Starting control plane node minikube in cluster minikube
💾  Downloading Kubernetes v1.20.2 preload ...
> preloaded-images-k8s-v10-v1...: 491.71 MiB / 491.71 MiB  100.00% 2.59 MiB
🔥  Creating virtualbox VM (CPUs=2, Memory=3900MB, Disk=20000MB) ...
🐳  Preparing Kubernetes v1.20.2 on Docker 20.10.4 ...
▪ Generating certificates and keys ...
▪ Booting up control plane ...
▪ Configuring RBAC rules ...
🔎  Verifying Kubernetes components...
▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5
🌟  Enabled addons: storage-provisioner, default-storageclass
🏄  Done! kubectl is now configured to use "minikube" cluster and "default" namespace by defaul

$ minikube status
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured

---- ONCE YOU HAVE A K8 SERVICE RUNNING WITH AN EXTERNAL SERVICE -----
$ minikube service mongo-express-service
(This will open your browser to access the service exposed port)

$ minikube delete
🔥  Deleting "minikube" in virtualbox ...
💀  Removed all traces of the "minikube" cluster

Kubectl 기본

**Kubectl**은 kubernetes 클러스터를 위한 명령줄 도구입니다. 이는 마스터 프로세스의 Api 서버와 통신하여 kubernetes에서 작업을 수행하거나 데이터를 요청합니다.

kubectl version #Get client and server version
kubectl get pod
kubectl get services
kubectl get deployment
kubectl get replicaset
kubectl get secret
kubectl get all
kubectl get ingress
kubectl get endpoints

#kubectl create deployment <deployment-name> --image=<docker image>
kubectl create deployment nginx-deployment --image=nginx
#Access the configuration of the deployment and modify it
#kubectl edit deployment <deployment-name>
kubectl edit deployment nginx-deployment
#Get the logs of the pod for debbugging (the output of the docker container running)
#kubectl logs <replicaset-id/pod-id>
kubectl logs nginx-deployment-84cd76b964
#kubectl describe pod <pod-id>
kubectl describe pod mongo-depl-5fd6b7d4b4-kkt9q
#kubectl exec -it <pod-id> -- bash
kubectl exec -it mongo-depl-5fd6b7d4b4-kkt9q -- bash
#kubectl describe service <service-name>
kubectl describe service mongodb-service
#kubectl delete deployment <deployment-name>
kubectl delete deployment mongo-depl
#Deploy from config file
kubectl apply -f deployment.yml

Minikube 대시보드

대시보드를 통해 minikube가 무엇을 실행하고 있는지 더 쉽게 확인할 수 있으며, 접근할 수 있는 URL은 다음과 같습니다:

minikube dashboard --url


🔌  Enabling dashboard ...
▪ Using image kubernetesui/dashboard:v2.3.1
▪ Using image kubernetesui/metrics-scraper:v1.0.7
🤔  Verifying dashboard health ...
🚀  Launching proxy ...
🤔  Verifying proxy health ...
http://127.0.0.1:50034/api/v1/namespaces/kubernetes-dashboard/services/http:kubernetes-dashboard:/proxy/

YAML 구성 파일 예제

각 구성 파일은 3부분으로 구성됩니다: 메타데이터, 사양 (실행해야 할 내용), 상태 (원하는 상태).
배포 구성 파일의 사양 안에는 실행할 이미지를 정의하는 새로운 구성 구조로 정의된 템플릿을 찾을 수 있습니다:

같은 구성 파일에 선언된 배포 + 서비스의 예 (from here)

서비스는 일반적으로 하나의 배포와 관련이 있으므로 두 가지를 같은 구성 파일에 선언할 수 있습니다 (이 구성에서 선언된 서비스는 내부에서만 접근 가능합니다):

apiVersion: apps/v1
kind: Deployment
metadata:
name: mongodb-deployment
labels:
app: mongodb
spec:
replicas: 1
selector:
matchLabels:
app: mongodb
template:
metadata:
labels:
app: mongodb
spec:
containers:
- name: mongodb
image: mongo
ports:
- containerPort: 27017
env:
- name: MONGO_INITDB_ROOT_USERNAME
valueFrom:
secretKeyRef:
name: mongodb-secret
key: mongo-root-username
- name: MONGO_INITDB_ROOT_PASSWORD
valueFrom:
secretKeyRef:
name: mongodb-secret
key: mongo-root-password
---
apiVersion: v1
kind: Service
metadata:
name: mongodb-service
spec:
selector:
app: mongodb
ports:
- protocol: TCP
port: 27017
targetPort: 27017

외부 서비스 구성 예시

이 서비스는 외부에서 접근할 수 있습니다 (nodePort 및 type: LoadBlancer 속성을 확인하세요):

---
apiVersion: v1
kind: Service
metadata:
name: mongo-express-service
spec:
selector:
app: mongo-express
type: LoadBalancer
ports:
- protocol: TCP
port: 8081
targetPort: 8081
nodePort: 30000

Ingress 구성 파일의 예

이것은 http://dashboard.com에서 애플리케이션을 노출합니다.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: dashboard-ingress
namespace: kubernetes-dashboard
spec:
rules:
- host: dashboard.com
http:
paths:
- backend:
serviceName: kubernetes-dashboard
servicePort: 80

비밀 구성 파일의 예

비밀번호가 B64로 인코딩되어 있는 것을 주목하세요(안전하지 않습니다!).

apiVersion: v1
kind: Secret
metadata:
name: mongodb-secret
type: Opaque
data:
mongo-root-username: dXNlcm5hbWU=
mongo-root-password: cGFzc3dvcmQ=

ConfigMap의 예

A ConfigMap은 포드에 제공되는 구성으로, 포드가 다른 서비스를 찾고 접근하는 방법을 알 수 있도록 합니다. 이 경우, 각 포드는 mongodb-service라는 이름이 그들이 통신할 수 있는 포드의 주소임을 알게 됩니다(이 포드는 mongodb를 실행할 것입니다):

apiVersion: v1
kind: ConfigMap
metadata:
name: mongodb-configmap
data:
database_url: mongodb-service

그런 다음, 배포 구성 내에서 이 주소는 다음과 같은 방식으로 지정되어 포드의 env 내에서 로드될 수 있습니다:

[...]
spec:
[...]
template:
[...]
spec:
containers:
- name: mongo-express
image: mongo-express
ports:
- containerPort: 8081
env:
- name: ME_CONFIG_MONGODB_SERVER
valueFrom:
configMapKeyRef:
name: mongodb-configmap
key: database_url
[...]

볼륨 구성 예시

다양한 저장소 구성 yaml 파일의 예시는 https://gitlab.com/nanuchi/youtube-tutorial-series/-/tree/master/kubernetes-volumes에서 찾을 수 있습니다.
볼륨은 네임스페이스 안에 있지 않다는 점에 유의하세요.

네임스페이스

Kubernetes는 동일한 물리적 클러스터를 기반으로 하는 다수의 가상 클러스터를 지원합니다. 이러한 가상 클러스터를 네임스페이스라고 합니다. 이는 여러 팀이나 프로젝트에 걸쳐 많은 사용자가 있는 환경에서 사용하기 위해 설계되었습니다. 몇 명에서 수십 명의 사용자가 있는 클러스터의 경우, 네임스페이스를 생성하거나 고려할 필요가 없습니다. Kubernetes에 배포된 애플리케이션의 각 부분을 더 잘 제어하고 조직하기 위해서만 네임스페이스를 사용하기 시작해야 합니다.

네임스페이스는 이름에 대한 범위를 제공합니다. 리소스의 이름은 네임스페이스 내에서 고유해야 하지만, 네임스페이스 간에는 고유할 필요는 없습니다. 네임스페이스는 서로 중첩될 수 없으며, 각 Kubernetes 리소스는 하나의 네임스페이스에만 존재할 수 있습니다.

기본적으로 minikube를 사용하는 경우 4개의 네임스페이스가 있습니다:

kubectl get namespace
NAME              STATUS   AGE
default           Active   1d
kube-node-lease   Active   1d
kube-public       Active   1d
kube-system       Active   1d

• kube-system: 사용자 사용을 위한 것이 아니며 건드리지 말아야 합니다. 마스터 및 kubectl 프로세스를 위한 것입니다.
• kube-public: 공개적으로 접근 가능한 데이터. 클러스터 정보를 포함하는 configmap이 포함되어 있습니다.
• kube-node-lease: 노드의 가용성을 결정합니다.
• default: 사용자가 리소스를 생성하는 데 사용할 네임스페이스입니다.

#Create namespace
kubectl create namespace my-namespace

kubectl api-resources --namespaced=true #네임스페이스에 있음
kubectl api-resources --namespaced=false #네임스페이스에 없음

해당 컨텍스트에서 모든 후속 kubectl 명령에 대한 네임스페이스를 저장할 수 있습니다.

kubectl config set-context --current --namespace=<insert-namespace-name-here>

Helm

Helm은 Kubernetes의 패키지 관리자입니다. YAML 파일을 패키징하고 이를 공용 및 개인 저장소에 배포할 수 있습니다. 이러한 패키지를 Helm Charts라고 합니다.

helm search <keyword>

Helm은 변수를 사용하여 구성 파일을 생성할 수 있는 템플릿 엔진이기도 합니다:

Kubernetes 비밀

**비밀(Secret)**은 민감한 데이터(예: 비밀번호, 토큰 또는 키)를 포함하는 객체입니다. 이러한 정보는 Pod 사양이나 이미지에 포함될 수 있습니다. 사용자는 비밀을 생성할 수 있으며 시스템에서도 비밀을 생성합니다. 비밀 객체의 이름은 유효한 DNS 서브도메인 이름이어야 합니다. 공식 문서를 참조하세요.

비밀은 다음과 같은 것일 수 있습니다:

• API, SSH 키.
• OAuth 토큰.
• 자격 증명, 비밀번호(일반 텍스트 또는 b64 + 암호화).
• 정보 또는 주석.
• 데이터베이스 연결 코드, 문자열… .

Kubernetes에는 다양한 유형의 비밀이 있습니다.

비밀이 작동하는 방식:

다음 구성 파일은 mysecret이라는 비밀을 정의하며, 2개의 키-값 쌍 username: YWRtaW4= 및 password: MWYyZDFlMmU2N2Rm을 포함합니다. 또한 mysecret에서 정의된 username 및 password를 환경 변수 SECRET_USERNAME __ 및 __ SECRET_PASSWOR로 노출하는 secretpod라는 pod를 정의합니다. 또한 mysecret 내의 username 비밀을 /etc/foo/my-group/my-username 경로에 0640 권한으로 마운트합니다.

apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
username: YWRtaW4=
password: MWYyZDFlMmU2N2Rm
---
apiVersion: v1
kind: Pod
metadata:
name: secretpod
spec:
containers:
- name: secretpod
image: nginx
env:
- name: SECRET_USERNAME
valueFrom:
secretKeyRef:
name: mysecret
key: username
- name: SECRET_PASSWORD
valueFrom:
secretKeyRef:
name: mysecret
key: password
volumeMounts:
- name: foo
mountPath: "/etc/foo"
restartPolicy: Never
volumes:
- name: foo
secret:
secretName: mysecret
items:
- key: username
path: my-group/my-username
mode: 0640

kubectl apply -f <secretpod.yaml>
kubectl get pods #Wait until the pod secretpod is running
kubectl exec -it  secretpod -- bash
env | grep SECRET && cat /etc/foo/my-group/my-username && echo

Secrets in etcd

etcd는 모든 클러스터 데이터에 대한 Kubernetes 백업 저장소로 사용되는 일관성 있고 고가용성 키-값 저장소입니다. etcd에 저장된 비밀에 접근해 봅시다:

cat /etc/kubernetes/manifests/kube-apiserver.yaml | grep etcd

인증서, 키 및 URL이 파일 시스템에 위치해 있는 것을 볼 수 있습니다. 이를 얻으면 etcd에 연결할 수 있게 됩니다.

#ETCDCTL_API=3 etcdctl --cert <path to client.crt> --key <path to client.ket> --cacert <path to CA.cert> endpoint=[<ip:port>] health

ETCDCTL_API=3 etcdctl --cert /etc/kubernetes/pki/apiserver-etcd-client.crt --key /etc/kubernetes/pki/apiserver-etcd-client.key --cacert /etc/kubernetes/pki/etcd/etcd/ca.cert endpoint=[127.0.0.1:1234] health

통신을 설정하면 비밀을 얻을 수 있습니다:

#ETCDCTL_API=3 etcdctl --cert <path to client.crt> --key <path to client.ket> --cacert <path to CA.cert> endpoint=[<ip:port>] get <path/to/secret>

ETCDCTL_API=3 etcdctl --cert /etc/kubernetes/pki/apiserver-etcd-client.crt --key /etc/kubernetes/pki/apiserver-etcd-client.key --cacert /etc/kubernetes/pki/etcd/etcd/ca.cert endpoint=[127.0.0.1:1234] get /registry/secrets/default/secret_02

ETCD에 암호화 추가하기

기본적으로 모든 비밀은 암호화 계층을 적용하지 않는 한 etcd 내부에 일반 텍스트로 저장됩니다. 다음 예시는 https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/를 기반으로 합니다.

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources:
- secrets
providers:
- aescbc:
keys:
- name: key1
secret: cjjPMcWpTPKhAdieVtd+KhG4NN+N6e3NmBPMXJvbfrY= #Any random key
- identity: {}

그 후, 생성된 구성 파일의 위치를 가리키도록 kube-apiserver에서 --encryption-provider-config 플래그를 설정해야 합니다. /etc/kubernetes/manifest/kube-apiserver.yaml를 수정하고 다음 줄을 추가할 수 있습니다:

containers:
- command:
- kube-apiserver
- --encriyption-provider-config=/etc/kubernetes/etcd/<configFile.yaml>

volumeMounts에서 아래로 스크롤하세요:

- mountPath: /etc/kubernetes/etcd
name: etcd
readOnly: true

volumeMounts에서 hostPath로 스크롤하세요:

- hostPath:
path: /etc/kubernetes/etcd
type: DirectoryOrCreate
name: etcd

데이터가 암호화되었는지 확인하기

데이터는 etcd에 기록될 때 암호화됩니다. kube-apiserver를 재시작한 후, 새로 생성되거나 업데이트된 비밀은 저장될 때 암호화되어야 합니다. 확인하려면 etcdctl 명령줄 프로그램을 사용하여 비밀의 내용을 검색할 수 있습니다.

1. default 네임스페이스에 secret1이라는 새 비밀을 생성합니다:

kubectl create secret generic secret1 -n default --from-literal=mykey=mydata

2. etcdctl 명령줄을 사용하여 etcd에서 해당 비밀을 읽습니다:

ETCDCTL_API=3 etcdctl get /registry/secrets/default/secret1 [...] | hexdump -C

여기서 [...]는 etcd 서버에 연결하기 위한 추가 인수여야 합니다.

3. 저장된 비밀이 k8s:enc:aescbc:v1:로 접두사가 붙어 있는지 확인합니다. 이는 aescbc 제공자가 결과 데이터를 암호화했음을 나타냅니다.
4. API를 통해 검색할 때 비밀이 올바르게 복호화되었는지 확인합니다:

kubectl describe secret secret1 -n default

mykey: bXlkYXRh와 일치해야 하며, mydata는 인코딩되어 있습니다. 비밀을 완전히 복호화하려면 비밀 복호화를 확인하세요.

비밀은 기록 시 암호화되므로 비밀을 업데이트하면 해당 내용이 암호화됩니다:

kubectl get secrets --all-namespaces -o json | kubectl replace -f -

최종 팁:

• FS에 비밀을 보관하지 마세요. 다른 곳에서 가져오세요.
• 비밀을 보호하기 위해 https://www.vaultproject.io/ 를 확인하세요.
• https://kubernetes.io/docs/concepts/configuration/secret/#risks
• https://docs.cyberark.com/Product-Doc/OnlineHelp/AAM-DAP/11.2/en/Content/Integrations/Kubernetes_deployApplicationsConjur-k8s-Secrets.htm

참고문헌

kubesectips v1 | sickrov.github.io

- YouTube