Category: Kubernetes

2026
0
Kubernetes

[쿠버네티스 DevOps 구축] - Ingress NGINX 대신 Traefik 적용하기

목차 [쿠버네티스 DevOps 구축] - Ingress NGINX 대신 Traefik 적용하기 [쿠버네티스 DevOps 구축] - OpenSearch 설치하기 [쿠버네티스 DevOps 구축] - Prometheus 와 Grafana 설치하기 [쿠버네티스 DevOps 구축] - Keycloak 설치하기 [쿠버네티스 DevOps 구축] - Ingress Nginx Controller 설치하기 [쿠버네티스 DevOps 구축] - Local PC 쿠버네티스 동적 프로비저닝을 위한 StorageClass 설치 [쿠버네티스 DevOps 구축] - Local PC 에 쿠버네티스 설치하기 Ingress Nginx 의 서비스 종료2025년 11월 11일자 기준으로 쿠버네티스 공식문서에 Ingress Nginx 에 대한 서비스 지원 종료 관련 공지가 올라왔습니다. 때문에, Ingress Nginx 를 다른 서비스로 교체를 이번 전환의 목적은 단순히 Ingress Controller를 교체하는 것보다, 라우팅 설정을 조금 더 선언적으로 관리하고 HTTPS 리다이렉션, Middleware, 대시보드, CRD 기반 라우팅을 한 곳에서 정리하는 데 있었다. Ingress NGINX도 충분히 많이 쓰이는 안정적인 선택지지만, 실제 운영에서 다음과 같은 요구가 생기면 Traefik이 더 편하게 느껴질 수 있다. Ingress annotation보다 더 명확한 라우팅 구성이 필요할 때 경로 재작성, 인증, 리다이렉트 같은 기능을 재사용 가능한 단위로 관리하고 싶을 때 표준 Ingress와 전용 CRD 방식을 함께 쓰고 싶을 때 Kubernetes 외에도 Docker, Swarm, Nomad 같은 여러 provider와 비슷한 방식으로 운영하고 싶을 때 Traefik 이란

0
KubernetesIstio

Istio Ambient Mesh - ztunnel과 HBONE 동작

목차 Istio Ambient Mesh Istio Ambient Mesh - ztunnel과 HBONE 동작 Istio 란? 개요Ambient Mesh를 볼 때 가장 헷갈리는 지점은 이것입니다. sidecar가 없는데 트래픽을 어떻게 메시에 태우는가 mTLS는 어디서 적용되는가 L4와 L7은 어디서 갈라지는가 핵심은 istio-cni, ztunnel, HBONE 세 가지를 같이 보는 것입니다. 전체 흐름Ambient 환경에서 기본 데이터 경로는 아래처럼 이해하면 됩니다. source pod -> source node ztunnel -> HBONE tunnel -> destination node ztunnel -> destination pod

0
KubernetesIstio

Istio Ambient Mesh

목차 Istio Ambient Mesh Istio Ambient Mesh - ztunnel과 HBONE 동작 Istio - Istio 설치 및 addon 설치 Istio - Sidecar Injection Istio 란? Istio Ambient Mesh란Istio Ambient Mesh는 sidecar 없이 서비스 메시에 참여할 수 있게 만든 Istio의 데이터 플레인 모드입니다.기존 Istio가 Pod마다 Envoy sidecar를 주입하는 방식이었다면, Ambient Mesh는 노드 단위 L4 프록시(ztunnel) 와 필요할 때만 추가하는 L7 프록시(waypoint) 로 기능을 분리합니다. Istio 공식 기준으로 Ambient Mode는 2024-11-07 공개된 Istio 1.24에서 GA(General Availability) 상태가 되었고, 현재는 Istio의 정식 운영 옵션 중 하나로 보는 것이 맞습니다. 왜 Ambient Mesh가 나왔나기존 sidecar 방식은 강력하지만 운영 부담이 분명합니다. Pod마다 프록시가 하나씩 붙으므로 리소스 사용량이 커짐 애플리케이션 배포 시 sidecar injection과 재시작이 필요함 언어나 런타임, 초기화 방식에 따라 sidecar 호환성 이슈가 생길 수 있음 대규모 클러스터에서는 프록시 개수가 급격히 늘어나 운영 복잡도가 커짐 Ambient Mesh는 이런 문제를 줄이기 위해, “기본은 가볍게 L4 보안만 적용하고, 필요할 때만 L7 기능을 추가” 하는 구조를 선택했습니다.

0
Kubernetes

[쿠버네티스] Kubernetes 인증서들의 만료로 인한 접속 불가 및 해결

1. 원인 - kubeadm 인증서의 유효기간kubeadm 으로 구성한 쿠버네티스 클러스터는 내부 통신에 사용하는 TLS 인증서들을 자동으로 생성합니다.그런데 이 인증서들의 기본 유효기간이 1년 으로 설정되어 있습니다. 반면 CA (Certificate Authority) 인증서는 10년 유효기간으로 발급되기 때문에, 매년 하위 인증서들만 갱신해줘야 합니다. 클러스터를 운영하다 보면 이 1년이라는 만료 시점을 놓쳐서 갑자기 클러스터 접속이 불가능해지는 상황이 발생할 수 있습니다. 2. 상황 파악 - 쿠버네티스 클러스터 접속 안됨외부에서 쿠버네티스 클러스터로 접속이 안돼 쿠버네티스 control plane 이 설치된 node 로 가서 kubelet 로그를 확인해 보니 다음과 같이 TLS 핸드셰이크시 오류가 발생하는 로그가 찍히고 있었습니다. kubelet 로그 확인> sudo systemctl status kubelet kubelet[1435]: I0222 08:40:59.656171 1435 log.go:245] http: TLS handshake error from 101.198.0.183:19517: tls: client requested unsupported application protocols ([http/0.9 http/1.0 spdy/1 spdy/2 spdy/3>kubelet[1435]: I0222 08:40:59.758452 1435 log.go:245] http: TLS handshake error from 101.198.0.135:34088: tls: client requested unsupported application protocols ([hq h2c spdy/3 spdy/2 spdy/1 http/1.0 h>kubelet[1435]: I0222 08:40:59.857735 1435 log.go:245] http: TLS handshake error from 101.198.0.172:36328: tls: client offered only unsupported versions: [302 301]

2025
0
Kubernetes워크로드

[쿠버네티스] - Health Probes (Startup, Liveness, Readiness)

개요쿠버네티스는 컨테이너의 상태를 모니터링하고 관리하기 위해 세 가지 유형의 Health Probe를 제공합니다: Startup Probe: 컨테이너가 시작되었는지 확인 Liveness Probe: 컨테이너가 정상적으로 실행 중인지 확인 Readiness Probe: 컨테이너가 트래픽을 받을 준비가 되었는지 확인 Probe 메커니즘모든 Probe는 다음 세 가지 방식 중 하나로 동작합니다: 1. HTTP GET 요청httpGet: path: /healthz port: 8080 httpHeaders: - name: Custom-Header value: Awesome scheme: HTTP # or HTTPS 지정된 경로로 HTTP GET 요청을 보냅니다 200-399 범위의 상태 코드를 반환하면 성공 그 외의 코드는 실패로 간주 2. TCP Socket 연결

0
Kubernetes

Kubernetes Node 재실행 후 swap 으로 인한 kubelet 무한 재시작

최근 홈 서버에 Kubernetes 클러스터를 구성하던 중, 노드가 재실행한 후에 노드가 NotReady 상태로 떨어지며 kubelet 이 계속 재시작되는 문제를 겪었다.systemd 로그를 확인해 보니, kubelet 이 무한 재시작되며 restart counter 가 6500회를 넘는 심각한 상태였다. 🔍 문제 상황계속 재시작 되는 노드로 들어가서 kubelet 서비스 상태를 확인하면 다음과 같은 메시지가 반복적으로 출력된다. > sudo systemctl status kubelet● kubelet.service - kubelet: The Kubernetes Node Agent Loaded: loaded (/usr/lib/systemd/system/kubelet.service; enabled; preset: enabled) Drop-In: /usr/lib/systemd/system/kubelet.service.d └─10-kubeadm.conf Active: activating (auto-restart) (Result: exit-code) since Sun 2025-11-23 10:52:13 KST; 1s ago Docs: https://kubernetes.io/docs/ Process: 150004 ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS (code=exited, status=1/FAILURE) Main PID: 150004 (code=exited, status=1/FAILURE) CPU: 90ms> sudo journalctl -u kubelet -n 50 --no-pagerNov 23 10:52:54 systemd[1]: kubelet.service: Main process exited, code=exited, status=1/FAILURE Nov 23 10:52:54 systemd[1]: kubelet.service: Failed with result 'exit-code'. Nov 23 10:53:04 systemd[1]: kubelet.service: Scheduled restart job, restart counter is at 6578. Nov 23 10:53:04 systemd[1]: Started kubelet.service - kubelet: The Kubernetes Node Agent. Nov 23 10:53:04 kubelet[150116]: Flag --container-runtime-endpoint has been deprecated, This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information. Nov 23 10:53:04 kubelet[150116]: Flag --pod-infra-container-image has been deprecated, will be removed in a future release. Image garbage collector will get sandbox image information from CRI. Nov 23 10:53:04 kubelet[150116]: I1123 10:53:04.710817 150116 server.go:209] "--pod-infra-container-image will not be pruned by the image garbage collector in kubelet and should also be set in the remote runtime" Nov 23 10:53:04 kubelet[150116]: I1123 10:53:04.715367 150116 server.go:492] "Kubelet version" kubeletVersion="v1.29.15" Nov 23 10:53:04 kubelet[150116]: I1123 10:53:04.715402 150116 server.go:494] "Golang settings" GOGC="" GOMAXPROCS="" GOTRACEBACK="" Nov 23 10:53:04 kubelet[150116]: I1123 10:53:04.715759 150116 server.go:924] "Client rotation is on, will bootstrap in background" Nov 23 10:53:04 kubelet[150116]: I1123 10:53:04.716990 150116 certificate_store.go:130] Loading cert/key pair from "/var/lib/kubelet/pki/kubelet-client-current.pem". Nov 23 10:53:04 kubelet[150116]: I1123 10:53:04.718180 150116 dynamic_cafile_content.go:157] "Starting controller" name="client-ca-bundle::/etc/kubernetes/pki/ca.crt" Nov 23 10:53:04 kubelet[150116]: I1123 10:53:04.727293 150116 server.go:750] "--cgroups-per-qos enabled, but --cgroup-root was not specified. defaulting to /" Nov 23 10:53:04 kubelet[150116]: E1123 10:53:04.727405 150116 run.go:74] "command failed" err="failed to run Kubelet: running with swap on is not supported, please disable swap! or set --fail-swap-on flag to false. /proc/s 핵심 에러 메시지는 아래 한 줄이다. running with swap on is not supported, please disable swap! 즉, swap 이 활성화된 상태에서 kubelet이 실행되고 있기 때문에 강제로 종료되고 있었던 것이다. 초기 설정때 껏는데.. 재실행되면서 켜진 모양이다. 😭 ❗ Kubernetes 는 왜 swap을 허용하지 않을까?Kubernetes 는 노드 리소스를 엄격하게 관리하기 위해 메모리 관리 정책을 자체적으로 수행한다. 하지만 swap 이 활성화되어 있으면 다음과 같은 문제가 발생한다.

0
Kubernetes인증/인가

[쿠버네티스] 인증/인가 - OIDC 를 이용한 Keycloak 연동

목차 [쿠버네티스] 인증/인가 - OIDC 를 이용한 Keycloak 연동 [쿠버네티스] 인증/인가 - ServiceAccount [쿠버네티스] 인증/인가 - X.509 인증서를 사용한 사용자 추가 및 인증 [쿠버네티스] 인증/인가 - Role 과 ClusterRole 참고 https://wlsdn3004.tistory.com/62 앞서 말했듯이, 쿠버네티스는 사용자 정보를 저장하지 않습니다. 사용자를 관리하고 싶으면, 쿠버네티스에서 제공하는 OIDC 를 통해 별도의 인증 서버와 연계를 하면 사용자를 관리할 수 있습니다. 인증서버로 유명한 Keycloak 을 이용해 사용자를 관리하고 쿠버네티스에서 인증을 진행할 수 있도록 설정을 진행하려고 합니다. ✅ 1. Keycloak Client 추가쿠버네티스에서 Keycloak 을 이용해 인증을 진행하기 위해서는 Client 생성(등록) 이 필요합니다. Client 단위로 Keycloak 에서는 쿠버네티스 사용자들을 관리하고 권한을 매핑해줄 수 있습니다.

0
Kubernetes인증/인가

[쿠버네티스] 인증/인가 - Role 과 ClusterRole

목차 [쿠버네티스] 인증/인가 - OIDC 를 이용한 Keycloak 연동 [쿠버네티스] 인증/인가 - ServiceAccount [쿠버네티스] 인증/인가 - X.509 인증서를 사용한 사용자 추가 및 인증 [쿠버네티스] 인증/인가 - Role 과 ClusterRole 쿠버네티스에서 Role과 ClusterRole은 RBAC(역할 기반 접근 제어)를 통해 사용자나 서비스 계정에 권한을 부여하는 중요한 리소스입니다. 아래에 각각의 특징과 차이점을 정리해 보았습니다. Role네임스페이스 범위: Role은 특정 네임스페이스 내에서만 유효합니다. 따라서 한 네임스페이스의 자원에만 접근 권한을 부여할 수 있습니다. 정책 정의: Role 안에는 API 리소스(예: Pods, Services 등)에 대한 특정 동작(예: get, list, create 등)이 정의되어 있습니다. 바인딩: Role은 RoleBinding을 통해 사용자나 서비스 계정에 연결됩니다. 이때 RoleBinding 역시 특정 네임스페이스에 속합니다.

0
Kubernetes인증/인가

[쿠버네티스] 인증/인가 - X.509 인증서를 사용한 사용자 추가 및 인증

목차 [쿠버네티스] 인증/인가 - OIDC 를 이용한 Keycloak 연동 [쿠버네티스] 인증/인가 - ServiceAccount [쿠버네티스] 인증/인가 - X.509 인증서를 사용한 사용자 추가 및 인증 [쿠버네티스] 인증/인가 - Role 과 ClusterRole 쿠버네티스는 사용자를 “인증”하는 방식만 알면 되고, 사용자 정보를 자체를 저장하지 않습니다. X.509 인증서 를 사용하는 방식은 사용자 인증서를 만들고 클러스터에 등록해서 인증하는 방식입니다. ✅ 1. 사용자 인증서 및 키 생성1. 개인 키 (Private Key) 생성RSA 알고리즘으로 개인 키 생성 하게 되면 dev-user.key 파일이 생성됩니다. 개인 키는 인증서 서명 요청(CSR)을 만들 때 필요하며 이후 쿠버네티스 API 서버와 통신 시 이 키로 서명된 인증서를 사용해 본인을 증명

0
Kubernetes

[쿠버네티스 DevOps 구축] - OpenSearch 설치하기

목차 [쿠버네티스 DevOps 구축] - OpenSearch 설치하기 [쿠버네티스 DevOps 구축] - Prometheus 와 Grafana 설치하기 [쿠버네티스 DevOps 구축] - Keycloak 설치하기 [쿠버네티스 DevOps 구축] - Ingress Nginx Controller 설치하기 [쿠버네티스 DevOps 구축] - Local PC 쿠버네티스 동적 프로비저닝을 위한 StorageClass 설치 [쿠버네티스 DevOps 구축] - Local PC 에 쿠버네티스 설치하기 참고 https://blog.pages.kr/2844 https://opendistro.github.io/for-elasticsearch-docs/docs/security/access-control/api/#reserved-and-hidden-resources https://forum.opensearch.org/t/default-password-reset/102/10 Admin Password 변경 https://github.com/opendistro-for-elasticsearch/opendistro-build/issues/558 https://opendistro.github.io/for-elasticsearch-docs/docs/security/configuration/yaml/#internal_usersyml https://github.com/opensearch-project/helm-charts/issues/161 ✅ OpenSearch 설치# Helm Repo 추가helm repo add opensearch https://opensearch-project.github.io/helm-charts/# OpenSearch 설치helm upgrade --install opensearch \ -f ./values-opensearch.yaml opensearch/opensearch \ -n logging --create-namespace Release "opensearch" has been upgraded. Happy Helming!NAME: opensearchLAST DEPLOYED: Thu Jan 18 15:55:28 2024NAMESPACE: loggingSTATUS: deployedREVISION: 2TEST SUITE: NoneNOTES:Watch all cluster members come up. $ kubectl get pods --namespace=logging -l app.kubernetes.io/component=opensearch-cluster-master -w ✅ OpenSearch Dashboard 설치helm upgrade --install opensearch-dashboard \ -f ./values-opensearch-dashboards.yaml opensearch/opensearch-dashboards \ -n logging --create-namespace

0
Kubernetes

[쿠버네티스 DevOps 구축] - Prometheus 와 Grafana 설치하기

목차 [쿠버네티스 DevOps 구축] - OpenSearch 설치하기 [쿠버네티스 DevOps 구축] - Prometheus 와 Grafana 설치하기 [쿠버네티스 DevOps 구축] - Keycloak 설치하기 [쿠버네티스 DevOps 구축] - Ingress Nginx Controller 설치하기 [쿠버네티스 DevOps 구축] - Local PC 쿠버네티스 동적 프로비저닝을 위한 StorageClass 설치 [쿠버네티스 DevOps 구축] - Local PC 에 쿠버네티스 설치하기 ✅ 메트릭 수집을 위한 Prometheus서비스를 올렸다고 해서 끝이 아니다! 서비스를 운용하는 입장에서는 시스템이 안정적인지 지속적으로 확인을 해야 하는데, 운영하는 서비스의 CPU 사용률, 메모리 사용률과 같은 메트릭 정보를 지속적으로 수집하는 시스템을 구축해야 합니다. 저는 대중적으로 많이 알려진 Prometheus 를 이용해 쿠버네티스에서 운영중인 서비스에 대한 메트릭 정보를 수집하려고 합니다. Helm 을 이용한 Prometheus 설치# helm repo 추가helm repo add prometheus-community https://prometheus-community.github.io/helm-charts# prometheus 설치helm upgrade --install -f ./values-prometheus.yaml prometheus prometheus-community/prometheus -n monitoring --create-namespace Release "prometheus" does not exist. Installing it now.NAME: prometheusLAST DEPLOYED: Fri Nov 15 10:11:47 2024NAMESPACE: monitoringSTATUS: deployedREVISION: 1TEST SUITE: NoneNOTES:The Prometheus server can be accessed via port 80 on the following DNS name from within your cluster:prometheus-server.monitoring.svc.cluster.localGet the Prometheus server URL by running these commands in the same shell: export POD_NAME=$(kubectl get pods --namespace monitoring -l "app.kubernetes.io/name=prometheus,app.kubernetes.io/instance=prometheus" -o jsonpath="{.items[0].metadata.name}") kubectl --namespace monitoring port-forward $POD_NAME 9090####################################################################################### WARNING: Persistence is disabled!!! You will lose your data when ########### the Server pod is terminated. ######################################################################################The Prometheus alertmanager can be accessed via port 9093 on the following DNS name from within your cluster:prometheus-alertmanager.monitoring.svc.cluster.localGet the Alertmanager URL by running these commands in the same shell: export POD_NAME=$(kubectl get pods --namespace monitoring -l "app.kubernetes.io/name=alertmanager,app.kubernetes.io/instance=prometheus" -o jsonpath="{.items[0].metadata.name}") kubectl --namespace monitoring port-forward $POD_NAME 9093####################################################################################### WARNING: Persistence is disabled!!! You will lose your data when ########### the AlertManager pod is terminated. ############################################################################################################################################################################# WARNING: Pod Security Policy has been disabled by default since ########### it deprecated after k8s 1.25+. use ########### (index .Values "prometheus-node-exporter" "rbac" ########### . "pspEnabled") with (index .Values ########### "prometheus-node-exporter" "rbac" "pspAnnotations") ########### in case you still need it. ######################################################################################The Prometheus PushGateway can be accessed via port 9091 on the following DNS name from within your cluster:prometheus-prometheus-pushgateway.monitoring.svc.cluster.localGet the PushGateway URL by running these commands in the same shell: export POD_NAME=$(kubectl get pods --namespace monitoring -l "app=prometheus-pushgateway,component=pushgateway" -o jsonpath="{.items[0].metadata.name}") kubectl --namespace monitoring port-forward $POD_NAME 9091For more information on running Prometheus, visit:https://prometheus.io/ ✅ 모니터링을 위한 Grafana메트릭 수집을 위한 Prometheus 를 설치 했는데! 단순 메트릭 정보만 있으면 운영하는 입장에서 가시적으로 와 닿지 않습니다.

0
Kubernetes

[쿠버네티스 DevOps 구축] - Ingress Nginx Controller 설치하기

목차 [쿠버네티스 DevOps 구축] - OpenSearch 설치하기 [쿠버네티스 DevOps 구축] - Prometheus 와 Grafana 설치하기 [쿠버네티스 DevOps 구축] - Keycloak 설치하기 [쿠버네티스 DevOps 구축] - Ingress Nginx Controller 설치하기 [쿠버네티스 DevOps 구축] - Local PC 쿠버네티스 동적 프로비저닝을 위한 StorageClass 설치 [쿠버네티스 DevOps 구축] - Local PC 에 쿠버네티스 설치하기 참고 https://kubernetes.github.io/ingress-nginx/ https://github.com/nginxinc/kubernetes-ingress https://artifacthub.io/packages/helm/ingress-nginx/ingress-nginx https://www.nginx.com/blog/guide-to-choosing-ingress-controller-part-4-nginx-ingress-controller-options/ https://kubernetes.github.io/ingress-nginx/deploy/#bare-metal-clusters Ingress Controller 설치현재 설치된 쿠버네티스에서는 Ingress 를 생성 하더라도 외부 요청을 Ingress 설정에 맞게 외부 요청을 내부 서비스로 전달해주는 Controller 가 따로 없습니다. 다시 말해, 규칙을 생성하더라도 규칙을 읽어서 적용시켜주는 모듈이 없는 상태입니다. 보통, 클라우스 서비스에서는 ALB 나 NLB 와 같은 서비스를 이용해 Ingress 정책을 읽어 Load Balancing 규칙을 적용해주는데, 개인 쿠버네티스 서비스에서는 저런 시스템을 기대하기 힘듦으로 저는 Nginx 에서 제공해주는 Ingress Controller 를 이용하려고 합니다. Helm 설치helm upgrade --install ingress-nginx ingress-nginx \ --repo https://kubernetes.github.io/ingress-nginx \ --namespace ingress-nginx --create-namespace

0
Kubernetes

[쿠버네티스 DevOps 구축] - Local PC 쿠버네티스 동적 프로비저닝을 위한 StorageClass 설치

목차 [쿠버네티스 DevOps 구축] - OpenSearch 설치하기 [쿠버네티스 DevOps 구축] - Prometheus 와 Grafana 설치하기 [쿠버네티스 DevOps 구축] - Keycloak 설치하기 [쿠버네티스 DevOps 구축] - Ingress Nginx Controller 설치하기 [쿠버네티스 DevOps 구축] - Local PC 쿠버네티스 동적 프로비저닝을 위한 StorageClass 설치 [쿠버네티스 DevOps 구축] - Local PC 에 쿠버네티스 설치하기 참고 https://github.com/rancher/local-path-provisioner 🔎 로컬 쿠버네티스 동적 프로비저닝로컬 쿠버네티스 환경에서는 기본적으로 동적 PV 프로비저닝을 지원하지 않습니다. 다시 말해, 사용자가 직접 PV 를 생성한 후 PVC 에 수동으로 PV 를 연결해야 합니다. EKS 에서는 CSI 드라이버를 통해 동적 프로비저닝을 제공하는데, 로컬 환경에서 동일한 기능을 제공해주는 플러그인을 찾다가 local-path-provisioner 를 발견했습니다. 1. local-path-provisioner 설치아래 명령어를 사용해 local-path-provisioner를 설치합니다.

0
Kubernetes

[쿠버네티스 DevOps 구축] - Local PC 에 쿠버네티스 설치하기

목차 [쿠버네티스 DevOps 구축] - OpenSearch 설치하기 [쿠버네티스 DevOps 구축] - Prometheus 와 Grafana 설치하기 [쿠버네티스 DevOps 구축] - Keycloak 설치하기 [쿠버네티스 DevOps 구축] - Ingress Nginx Controller 설치하기 [쿠버네티스 DevOps 구축] - Local PC 쿠버네티스 동적 프로비저닝을 위한 StorageClass 설치 [쿠버네티스 DevOps 구축] - Local PC 에 쿠버네티스 설치하기 참고 https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/ https://cocococo.tistory.com/entry/k8s-%EC%BF%A0%EB%B2%84%EB%84%A4%ED%8B%B0%EC%8A%A4-%EC%82%AC%EC%9A%A9%EC%9D%84-%EC%9C%84%ED%95%9C-kubeadm-kubelet-%EB%B0%8F-kubectl-%EC%84%A4%EC%B9%98-%EB%B0%A9%EB%B2%95 https://jongsky.tistory.com/112 https://www.youtube.com/watch?v=Wr6nrBRqYYE 📝 회고Vitality 팀에 있을때 EKS 로 구축된 시스템을 운영했었습니다. 지금은 해당 팀이 해체 되면서 운영하고 있지는 않지만 그때 내부적으로 진행했던 프로젝트들의 기억을 되살리고자 포스트로 남기려고 합니다. 🤔 쿠버네티스 운영환경 선택지속적으로 쿠버네티스 환경을 운영도 하면서 공부도 하고 싶어 여러가지 환경을 검토해봤는데, EKS 는 일단 컨트롤 플레인 자체만으로도 한달에 7만원 정도가 나와 Pass (너무 비싸 😭), 로컬 PC 에 Minikube 를 이용하는 방법은 노트북을 너무 핫하게 만드는 방법이라 Pass 요즘 알리에서 미니 PC 가 싸게 풀리고 있고 시스템 초기 구입 비용 빼면 운용하는데는 매월 전기세만 내면 돼 크게 부담이 안될 것 같아 미니 PC 를 이용한 서버를 구축하기로 했습니다.

2023
0
Kubernetes인증/인가

[쿠버네티스] 인증/인가 - ServiceAccount

목차 [쿠버네티스] 인증/인가 - OIDC 를 이용한 Keycloak 연동 [쿠버네티스] 인증/인가 - ServiceAccount [쿠버네티스] 인증/인가 - X.509 인증서를 사용한 사용자 추가 및 인증 [쿠버네티스] 인증/인가 - Role 과 ClusterRole 참고 https://findstar.pe.kr/2023/04/09/access-k8s-api-from-pod/ https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/ https://kubernetes.io/ko/docs/reference/access-authn-authz/service-accounts-admin/ 🔎 ServiceAccount 란? ServiceAccount 는 쿠버네티스 API 서버와 통신하고 클러스터 내의 다른 리소스에 접근하기 위한 인증 정보를 제공합니다. ServiceAccount 는 Pod 가 Kubernetes API Server 에 인증 하기 위한 Account 입니다. 때문에 Pod 를 생성할때 ServiceAccount 를 할당해야 하며 지정하지 않을 경우 default 가 자동으로 할당됩니다. Rule 과 RuleBinding 을 이용해 ServiceAccount 에 권한을 부여함으로써 Pod 가 다른 리소스에 접근할 수 있게 해줍니다. ServiceAccount 는 Namespace 단위로 생성되는 리소스며 다른 Namespace 에서 정의된 ServiceAccount 를 사용할 수 없습니다.