[DevOps] 2024 State of DevOps Report Part 1 (AI)

State of DevOps Report는 2014년부터 시작되어 매년 발표되고 있으며, DORA(DevOps Research and Assessment) 팀이 연구를 주도하다가 이후 Google에 인수되어 현재까지 지속적으로 발표되고 있습니다. 해당 보고서에서는 배포 빈도, 변경 실패율, 복구 시간, 리드 타임 등의 핵심 지표를 기준으로 소프트웨어 개발 및 운영 성과의 DevOps 모범 사례와 생산성 향상 전략을 분석하고 있습니다.

2024년도의 State of DevOps Report 중 AI의 내용을 중점으로 한번 알아보는 시간을 가져보겠습니다.

참고자료 - 2023 State of DevOps Report 소개

[DevOps] State of DevOps Report 2023 알아보기 1탄

https://every-up.tistory.com/62

[DevOps] State of DevOps Report 2023 알아보기 2탄

https://every-up.tistory.com/63

[DevOps] State of DevOps Report 2023 알아보기 3탄

https://every-up.tistory.com/64

AI의 영향

2024 State of DevOps Report 내용 중 AI의 내용을 중점으로 알아보겠습니다.
Report 내용은 한글로 번역 후 정리해봤으며, 번역 내용에 따라 원문과 의미가 조금 다를 수 있음을 사전에 알려드립니다.

주요 결과(요약)

AI는 소프트웨어 개발 분야에서 패러다임 전환을 만들어내고 있으며 광범위한 영향을 미치고 있다고 합니다. AI 도입은 업무 흐름, 생산성, 직무 만족도, 코드 품질, 내부 문서 품질, 검토 프로세스, 팀 성과, 조징 성과 등에 이점이 있다고 합니다.

그러나 AI 도입은 몇가지 부정적인 영향도 가져온다고 하는데요. 소프트웨어 제공 성과가 감소하는 것을 관찰했으며, 제품 성과에 미치는 영향은 불확실하다고 합니다. 또한 개인은 AI 도입이 증가함에 따라 가치 있는 작업에 소요되는 시간이 감소한다고 보고하고 있습니다. AI 도입에 대한 실험 및 학습은 아직 많이 이뤄지지 않았기 때문에 계속해서 실험하고 학습이 필요하다고 보고 있습니다.

AI에 대한 조직 우선순위 변화

대다수의 응답자의 81%는 조직이 애플리케이션에 AI를 통합하는 것을 확대하기 위해 우선순위를 변경했다고 보고했습니다. 특히 응답자의 3%가 조직이 AI에 대한 집중도를 줄이고 있다고 보고했으며, 응답자의 78%는 조직이 AI를 신뢰한다고 보고했습니다.

AI에 의존하는 개발 작업 비율

AI의 빠른 도입이 모든 산업 부문에서 균일하게 전개되고 있다고 보고했습니다. 개인 수준에서는 응답자의 75.9%가 일상적인 직업적 책임 중 하나 이상에서 적어도 부분적으로 AI에 의존하고 있다는 것을 발견했습니다. AI에 의존하는 항목은 코드 작성, 정보 요약, 익숙하지 않은 코드 설명, 코드 최적화, 코드 문서화, 테스트 쓰기, 코드 디버깅, 데이터 분석 등이 있습니다.

AI가 생산성에 미치는 영향

AI는 많은 조직과 개발자가 채택하고 있기 때문에 개발 작업에 AI를 사용하는 이점은 상당히 높은 것으로 보입니다. 응답자의 75%가 2024년 초에 실시된 설문 조사에 앞서 3개월 동안 AI로 인해 긍정적인 생산성 향상을 보고했습니다.

AI에서 가장 큰 생산성 향상을 보고한 응답자는 보안 전문가, 시스템 관리자, 풀스택 개발자입니다.
긍정적인 생산성 향상도 보고했지만 모바일 개발자, 사이트 안정성 엔지니어, 프로젝트 관리자는 다른 역할보다는 생산성 혜택의 규모가 낮습니다.

AI가 생성한 코드의 품질 신뢰도

개발 작업에 사용된 AI 생성 코드의 신뢰성에 대한 참여자들의 인식은 복잡했습니다.
대다수의 응답자(87.9%)가 AI 생성 코드의 품질에 대해 어느 정도 신뢰한다고 보고했지만, 응답자가 AI 생성 코드의 품질을 신뢰한다고 보고한 정도는 일반적으로 낮았으며, 39.2%가 거의(27.3%) 신뢰하지 않거나 전혀 신뢰하지 않는다고 보고했습니다(11.9%).

개발자들이 AI를 빠르게 채택하고, AI에 의존하며, AI를 긍정적인 성과 기여 요소로 인식하고 있다는 설문조사의 증거를 감안할 때, 개발자들의 AI에 대한 전반적인 신뢰가 부족하다는 것을 발견했습니다.

AI가 미칠 부정적 영향

조사 결과에 따라 AI가 이미 개발 전문가의 업무에 엄청난 영향을 미쳤음을 시사하며, 이러한 추세는 앞으로도 계속 커질 것으로 예상합니다.

미래에 AI가 개발과 우리 세상에 어떤 영향을 미칠지 정확히 예측하는 것은 불가능하지만, 응답자들에게 향후 1년, 5년, 10년 동안 AI의 영향에 대한 추측과 기대는 그다지 희망적이지 않습니다.

응답자들은 AI가 자신의 경력, 환경, 사회 전체에 부정적인 영향을 미칠 것으로 예상하며, 이러한 부정적인 영향은 약 5년 후에 완전히 실현될 것이라고 보고했습니다.

AI 도입에 따른 성과 비교

AI 도입의 따른 다양한 영향을 측정했습니다.

AI가 개인에게 미치는 영향

개인의 AI 도입이 25% 증가할 경우에 따른 영향입니다.

개인의 AI 도입이 25% 증가하면 생산성은 약 2.1% 증가할 가능성이 높습니다. 이는 작은 것처럼 보일 수 있지만, 이는 개인 수준에서의 결과이며 수십 명의 개발자, 심지어 수만 명의 개발 자에게 확장된다고 상상해보면 이는 큰 영향을 미칠 수 있습니다.

AI 도입으로 생산력뿐만 아니라 직무 만족도 또한 실질적이고 유익한 영향을 미친다는 결과를 확인할 수 있습니다.

AI가 개발 성과에 미치는 영향

AI 도입이 25% 증가할 경우 개발 성과에서의 영향입니다.

개발 성과 측면에서 문서 품질 7.5% 증가, 코드 품질 3.4% 증가, 코드 검토 속도 3.1% 증가, 승인속도 1.3% 증가, 코드 복잡도 1.8% 감소 등 AI 도입에 따른 긍정적인 영향을 보여줍니다.

AI는 코드 품질을 개선하고 코드 복잡성을 줄이는 것으로 보입니다. 또한 오래된 코드의 잠재적인 리팩토링과 결합하면 고품질의 AI 생성 코드는 전반적으로 더 나은 코드베이스로 이어질 수 있습니다.

AI가 배포 성과에 미치는 영향

AI 도입이 여러 측면에서 긍정적인 영향을 보여주지만 배포 성과는 저하시키고 있습니다.
AI 도입이 25% 증가할 경우 배포 측면에서의 영향입니다.

예상과 달리, 우리의 조사 결과는 AI 도입이 소프트웨어 배포 성과에는 부정적인 영향을 미친다는 것을 보여줍니다.

AI 덕분에 응답자는 동일한 시간에 훨씬 더 많은 양의 코드를 생성할 수 있으므로 변경 목록의 크기가 커질 가능성이 있습니다. 따라서 DORA는 지속적으로 더 큰 변경은 더 느리고 불안정성을 유발할 가능성이 더 높다는 것을 보여주었습니다.

AI가 조직, 팀, 제품 성과에 미치는 영향

AI 도입이 25% 증가할 경우 조직, 팀, 제품 성과에에서의 영향입니다.

조직 수준 성과(AI 도입이 25% 증가할 때마다 약 2.3% 증가)와 팀 수준 성과(AI 도입이 25% 증가할 때마다 약 1.4% 증가)는 AI 도입의 혜택을 받는 것으로 보이지만, 제품 성과는 AI 도입과 명확한 연관성이 없는 것으로 보입니다.

팀과 조직은 커뮤니케이션, 지식 공유, 의사 결 정, 건강한 문화에 크게 의존합니다. AI는 이러한 영역의 일부 병목 현상을 완화하여 팀과 조직에 유익한 영향을 미칠 수 있습니다.

AI 도입 전략

보고서를 통해 AI 사용에 따른 개인, 팀, 조직에 긍정적인 효과를 얻을 수 있다는 점을 확인했습니다.
AI를 대규모로 도입하는 것은 쉽지 않을 수 있습니다. AI 도입 전략을 통해 상당한 이점을 가져올 수 있는 잠재력이 있습니다.

명확한 목표 및 정책 정의

조직과 팀의 역량을 강화하기 위해 직원에게 AI 활용 목표과 정책, 도입 계획에 대한 투명한 정보를 제공합니다.
AI를 어떻게 활용할지에 대한 큰 방향(비전)과 구체적인 실행 방법(정책)을 명확하게 정하면, 사람들이 불안해하는 문제를 줄일 수 있습니다.
그 결과, 모두가 AI의 활용 방식에 대해 걱정하기보다 더 중요한 일이나 가치 있는 작업에 집중할 수 있게 됩니다.

지속적인 학습과 실험 문화 조성

개인과 팀이 스스로 AI를 어떻게 활용할지 결정할 수 있도록 자유를 주고, AI의 유익한 사용법을 찾도록 돕습니다.
AI 도입을 단순한 기술 적용으로 보지 않고, 실제로 직원들의 업무를 돕고, 사용자(고객)에게 긍정적인 영향을 주며, 팀이 더 큰 성과를 낼 수 있도록 하는지를 기준으로 평가합니다.

AI의 단점을 인식하고 활용

AI가 업무를 도와줄 수 있지만, 오히려 중요한 작업 시간이 줄어드는 문제나 AI에 지나치게 의존하는 위험이 생길 수 있습니다.

따라서 어떤 점에서 유익한지뿐만 아니라, 어떻게 하면 부정적인 영향을 줄일 수 있는지도 고민해야 합니다. 즉, AI가 단순한 도구가 아니라, 조직이 성장하는 데 실질적인 도움이 되도록 활용하는 것이 핵심입니다.

2024년도의 State of DevOps Report 중 AI의 내용을 중점으로 주요 내용을 확인해봤는데요.

다음은 플랫폼엔지니어링의 주요 내용에 대해서 상세하게 확인해보는 시간을 가져보겠습니다....! 끝...!

유익하게 보셨다면 공감을 눌러주고, 댓글로 의견을 공유해 남겨주시면 감사하겠습니다!

[Azure] AKS(Azure Kubernetes Service) 클러스터 CLI로 접근 후 Pod 생성하기

Azure AKS(Azure Kubernetes Service)는 Microsoft Azure에서 제공하는 관리형 Kubernetes 서비스로, 클러스터 배포, 관리 및 확장 작업을 자동화하여 애플리케이션을 쉽게 배포하고 운영할 수 있도록 지원합니다.

AKS(Azure Kubernetes Service) 클러스터를 CLI로 접근 후 간단히 Pod를 생성하는 방법을 알아보도록 하겠습니다.

사전 작업 및 참고 자료

AKS(Azure Kubernetes Service) 클러스터 생성하기

https://every-up.tistory.com/101

CLI(az) 설치 및 로그인 방법

https://every-up.tistory.com/77

AKS 클러스터 CLI 접근 및 Pod 생성하기

CLI 접근

AKS 클러스터의 정보를 확인하여 CLI를 통해 접근할 수 있도록 설정합니다.

접근하고자 하는 AKS 클러스터를 선택 후 Connect 버튼을 클릭합니다.

Azure CLI와 kubectl 설치가 필요한 경우 'Prerequisites'의 링크를 참조하여 설치합니다.
cluster context를 설정하기 위해 commands를 확인합니다.

기본적으로 선택한 AKS 클러스터의 정보가 입력되어 있으며, 사전에 Azure CLI 및 kubectl을 구성한 개인 PC 및 서버에서 해당 명령어를 입력합니다.

> az login
Please select the account you want to log in with.

Retrieving tenants and subscriptions for the selection...
### 생략 ###

> az account set --subscription {Subscription ID}

> az aks get-credentials --resource-group {Resource Group} --name TEST_AKS --overwrite-existing
Merged "TEST_AKS" as current context in C:\Users\TestUser\.kube\config

정상적으로 AKS 클러스터에 접근할 수 있는지 확인하기 위해 노드의 상태 정보를 확인해봅니다.

> kubectl.exe get nodes
NAME                                 STATUS   ROLES    AGE   VERSION
aks-systemnode-17324671-vmss000001   Ready    <none>   17m   v1.31.3
aks-usernode-17324671-vmss000001     Ready    <none>   17m   v1.31.3

Pod 생성하기

kubectl run 명령어로 사용하여 간단히 nginx Pod를 생성해보겠습니다.

> kubectl.exe run nginx --image nginx
pod/nginx created

nginx Pod가 정상적으로 생성 및 실행되는지 확인합니다.
기본적으로 사용자 노드에 생성되는지도 확인합니다.

> kubectl.exe get pods -o wide
NAME    READY   STATUS    RESTARTS   AGE   IP             NODE                               NOMINATED NODE   READINESS GATES
nginx   1/1     Running   0          12s   10.244.1.180   aks-usernode-17324671-vmss000001   <none>           <none>

이제 Azure 콘솔을 통해서 AKS 클러스터에 정상적으로 Pod가 생성되었는지 확인해봅니다.
Kubernetes resources -> Workloads 메뉴에서 Pods를 선택 후 namespace는 default로 선택합니다.
nginx Pod가 정상적으로 생성 및 실행되었는지 확인하실 수 있습니다.

AKS(Azure Kubernetes Service) 클러스터를 CLI로 접근 후 간단히 Pod를 생성하는 방법에 대해 알아봤습니다.

Azure CLI를 통해 로그인 및 클러스터 관련 정보를 입력하여 클러스터를 접근할 수 있도록 설정합니다. kubectl run 명령어로 간단히 Pod를 실행할 수 있으며 사전에 생성한 사용자 노드에 정상적으로 생성되었는지도 확인 가능합니다. 또한 Azure 콘솔을 통해서도 AKS 클러스터에 정상적으로 Pod가 생성되었는지 확인 가능합니다.

Microsoft Azure에서 제공하는 Azure AKS(Azure Kubernetes Service) Kubernetes 서비스를 통해 컨테이너화된 애플리케이션을 쉽게 배포하고 운영하여 사용해보시기 바랍니다.

지금까지 AKS(Azure Kubernetes Service) 클러스터를 CLI로 접근 후 간단히 Pod를 생성하는 방법을 알아보는 시간을 가졌습니다.

유익하게 보셨다면 공감을 눌러주고, 댓글로 의견을 공유해 남겨주시면 감사하겠습니다!

[Azure] AKS(Azure Kubernetes Service) 클러스터 생성하기

Kubernetes는 컨테이너화된 애플리케이션을 자동으로 배포, 확장, 관리하는 오픈 소스 플랫폼이며, 다양한 환경에서 일관된 애플리케이션 실행을 가능하게 해주는 컨테이너 오케스트레이션 도구입니다.

Azure AKS(Azure Kubernetes Service)는 Microsoft Azure에서 제공하는 관리형 Kubernetes 서비스로, 컨테이너화된 애플리케이션을 쉽게 배포, 관리 및 확장할 수 있도록 지원합니다. 자동화된 클러스터 관리, 보안 통합, 오토스케일링 및 DevOps 도구와의 연계를 제공하여 운영 부담을 줄이고 생산성을 향상시킵니다.

또한, Azure Monitor 및 Azure Security Center와 통합되어 모니터링, 로깅, 보안 정책 적용이 용이합니다.

Azure 콘솔을 통해서 간단히 AKS(Azure Kubernetes Service) 클러스터를 생성하는 방법을 알아보도록 하겠습니다.

AKS(Azure Kubernetes Service) 클러스터 생성하기

Azure 콘솔에서 'Kubernetes Services' 또는 'AKS'를 검색하여 Kubernetes Services를 클릭합니다.

AKS(Azure Kubernetes Service) 클러스터를 생성하기 위해 'Create' 버튼 클릭 후 'Kubernetes cluster' 옵션을 선택합니다.

Basics 설정

AKS(Azure Kubernetes Service) 클러스터를 구성하는 기본 옵션을 설정합니다.

'Cluster preset configuration' 값에 따라 클러스터에서 사용할 수 있는 기능과 node의 수가 다릅니다.
간단하게 클러스터를 구성하는 것 이므로 'Dev/Test' 값으로 선택합니다.
[참고링크] Cluster preset 정보

'Kubernetes cluster name', 'Region', 'AKS pricing tier', 'Kubernetes version'를 설정합니다.

AKS pricing tier(Free, Standard, Premium)는 Kubernetes 컨트롤 플레인 관리를 위한 가격 계층이며 저는 'Free'를 선택하였습니다.
[참고링크] AKS pricing tier 정보

Kubernetes version은 현재 기준으로 최신 버전인 1.31.3 버전을 선택하였습니다.

Automatic upgrade 설정과 Node security channel type 사용하지 않도록 선택하였습니다.

마지막으로 인증 방법인 'Authentication and Authorization' 설정은 AKS 클러스터를 배포할 때 생성되는 기본 Kubernetes 사용자 계정을 활용하여 인증을 수행하도록 설정하였습니다.

Node Pools 설정

Azure Kubernetes Service(AKS)에서 Node Pools 설정은 클러스터 내의 가상 머신(노드) 그룹으로, 워크로드를 실행하는 기본 단위입니다.

Node Pools은 System Node Pool(시스템 노드 풀)과 User Node Pool(사용자 노드 풀)이 존재합니다.

• System Node Pool(시스템 노드 풀)
  • 클러스터의 기본 노드 풀이며, AKS 시스템 서비스(예: CoreDNS, kube-proxy, metric-server 등)가 실행되며 최소 1개 이상 존재해야 하고 제거할 수 없습니다.
• User Node Pool(사용자 노드 풀)
  • 워크로드를 실행하는 전용 노드 풀이며, 여러 개 생성 가능하며, 다양한 VM 크기 및 스케일링 설정을 적용할 수 있습니다.

기본 설정으로 'agentpool' 이름의 시스템 노드 풀이 생성된 상태로 존재합니다.
최소 사양으로 AKS를 구성할 것이므로 해당 시스템 노드 풀을 제거하고, 다시 만들어보겠습니다.

'Node pool name', 'Mode', 'Scale method', 'Node count'를 설정합니다.

'Mode'는 시스템 노드 풀을 만들기 위해 System을 선택합니다.

최소 사양을 위해 'Scale method'는 Manual로 선택하고 1개의 Node만 생성되도록 'Node count'를 설정합니다.

'Node size' 설정을 통해 노드 풀 구성 시 사용할 컴퓨팅 리소스인 가상머신(VM)의 타입을 선택해보도록 하겠습니다.
Choose a size 버튼을 클릭합니다.

vCPU 2, RAM 4 GiB인 D2lds_v5 타입을 선택하였습니다.

'Node size' 설정을 완료하면 아래와 같이 선택한 타입을 확인하실 수 있습니다.

동일한 방법으로 사용자 노드 풀도 생성합니다.

Networking 설정

Azure Kubernetes Service(AKS)의 Container Networking Interface (CNI) 설정을 통해 Pod와 노드 간 네트워크 통신을 설정할 수 있습니다.

AKS는 'Network configuration' 설정을 통해 기본적으로 3가지 네트워크 모델을 지원합니다.

• 1. Azure CNI Overlay
  • Pod는 VNET 외부의 Overlay 네트워크에서 IP를 할당받아 VNET의 IP 주소 소모를 줄임
  • NAT을 통해 외부와 연결되며, 대규모 클러스터에 적합하고 성능이 우수함
• 2. Azure CNI (Node Subnet 방식)
  • Pod는 VNET의 IP를 직접 할당받아 Azure 리소스와 네트워크 통합이 원활함
  • VNET의 IP를 많이 소모하지만, 네트워크 성능이 가장 우수하며 NSG/UDR 적용 가능
• 3. Kubenet
  • Pod는 노드의 IP를 공유하며, NAT을 통해 외부와 통신하여 IP 사용량이 적음
  • Azure VNET과의 직접 연결이 어려워 소규모 클러스터나 테스트 환경에 적합

각 모델의 특징이 있으며 구성 환경에 따라 모델을 선택하여 사용합니다.

'DNS name prefix' 설정을 통해 Kubernetes API 서버의 DNS 이름을 설정합니다.

AKS 생성 (Review + create)

Basics 설정, Node Pools 설정, Networking 설정까지 완료하면 Review + create 버튼을 클릭하여 AKS를 생성합니다.

프로비저닝에 시간이 좀 소요되며 정상적으로 AKS 클러스터가 생성됨을 확인하실 수 있습니다.

AKS 상태 확인

Azure 콘솔의 Kubernetes 서비스에서 상태를 확인하고자 하는 AKS 클러스터를 클릭합니다.

AKS 클러스터의 시작 및 종료를 할 수 있는 버튼이 있습니다.
클러스터의 상태를 확인할 수 있으며 Kubernetes의 버전 정보 또한 확인하실 수 있습니다.

Azure 콘솔을 통해서 간단히 AKS(Azure Kubernetes Service) 클러스터를 생성하는 방법에 대해 알아봤습니다.

AKS(Azure Kubernetes Service) 클러스터는 기본 설정(Basics), 노드 풀(Node Pools), 네트워킹(Networking) 설정을 통해 구성되며, 필요에 따라 기타 설정 및 정책 등을 적용할 수 있습니다. 설정 완료 후 "Review + create" 버튼을 클릭하여 AKS를 생성하며, 생성된 클러스터의 상태 및 버전을 Azure 콘솔에서 확인할 수 있습니다.

Microsoft Azure에서 제공하는 Azure AKS(Azure Kubernetes Service) Kubernetes 서비스를 통해 컨테이너화된 애플리케이션을 쉽게 배포하고 운영해보시기 바랍니다.

지금까지 AKS(Azure Kubernetes Service) 클러스터를 생성하는 방법을 알아보는 시간을 가졌습니다.

유익하게 보셨다면 공감을 눌러주고, 댓글로 의견을 공유해 남겨주시면 감사하겠습니다!

[Reference]
https://learn.microsoft.com/ko-kr/azure/aks/automatic/quick-automatic-managed-network?pivots=azure-portal

[kubernetes] Pod 스케줄링 조건 및 정책

Kubernetes는 컨테이너화된 애플리케이션을 자동으로 배포, 확장, 관리하는 오픈 소스 플랫폼이며, 다양한 환경에서 일관된 애플리케이션 실행을 가능하게 해주는 컨테이너 오케스트레이션 도구입니다.

Kubernetes에서 스케줄링은 Kubelet이 Pod를 실행할 수 있도록 Pod가 Node에 적합한지 확인하는 것을 말합니다.
Pod가 배포될 때 적용되는 조건과 정책은 Pod의 배치, 리소스 할당, 네트워크, 보안 등 다양한 측면에서 영향을 미칩니다.

Kubernetes에서 다양한 환경과 조건에 유연하게 Pod를 배포하기 위한 스케줄링 조건 및 정책에 대해 알아보도록 하겠습니다.

스케줄링 조건 및 정책

Node Selector

Node Selector는 Pod가 특정 Node에 배치되도록 하기 위해 사용됩니다.
Node에 Key-Value 형태로 라벨을 추가하고, Pod의 nodeSelector 필드에 해당 라벨을 지정합니다.
지정된 라벨을 가진 Node가 없으면 Pod 배포가 불가합니다.

apiVersion: v1
kind: Pod
metadata:
  name: node-selector-pod
spec:
  nodeSelector:
    disktype: ssd

Node Affinity

Node Affinity는 Node Selector보다 유연한 방식으로, Node에 대한 강제(required) 조건과 선호(preferred) 조건을 정의할 수 있습니다.

requiredDuringSchedulingIgnoredDuringExecution : 반드시 조건을 만족해야만 배포
preferredDuringSchedulingIgnoredDuringExecution : 조건을 선호하지만, 만족하지 않아도 배포 가능

apiVersion: v1
kind: Pod
metadata:
  name: node-affinity-pod
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: disktype
            operator: In
            values:
            - ssd
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: zone
            operator: In
            values:
            - us-west-1

Taint & Toleration

Taint는 특정 Node에 Pod 배치를 제한하거나 허용하기 위한 정책으로 사용됩니다.
Node에 Taint를 설정하고, Pod에 해당 Taint를 허용하는 Toleration을 추가하면 해당 Node에 Pod 배치가 가능합니다.
이를 통해 클러스터의 리소스를 효율적으로 활용하고, 특정 Node에서 실행할 Pod를 제어할 수 있습니다.

Node에 Taint를 추가하는 명령어입니다.

# kubectl taint nodes node1 key=value:NoSchedule

Master(Control) Node에 Pod가 배포되지 않는 이유는 아래와 같이 Taint가 설정되어 있기 때문입니다.

# kubectl describe node node1 | grep Taint
Taints:             node-role.kubernetes.io/control-plane:NoSchedule

Toleration 설정을 통해 NoSchedule Taint가 설정된 Node에만 Pod를 배치할 수 있도록 허용합니다.

apiVersion: v1
kind: Pod
metadata:
  name: taint-toleration-pod
spec:
  tolerations:
  - key: "key"
    operator: "Equal"
    value: "value"
    effect: "NoSchedule"

Resource request & limit

Pod의 CPU, Memoery 등의 리소스 요청(requests) 및 제한(limits)을 설정하여, 해당 요구사항을 만족하는 Node에 배포되도록 합니다.
Pod에서 요청한 CPU/Memory를 수용할 수 없는 Node에는 배치 불가하며, 수용할 수 있는 Node가 없으면 Pod 배포는 불가합니다.
Pod가 사용하는 CPU와 메모리 리소스를 효율적으로 관리하기 위해 사용됩니다.

apiVersion: v1
kind: Pod
metadata:
  name: resource-pod
spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

Pod Affinity & Anti-Affinity

Pod Affinity는 특정 Pod가 클러스터 내의 다른 Pod와 가까운 위치(같은 Node 또는 같은 영역(zone))에 배치되도록 스케줄링하는 기능입니다.
서비스 간 네트워크 지연을 최소화하거나, 동일한 하드웨어 리소스를 공유하여 성능을 최적화해야 하는 경우 유용합니다.
반대로, Pod Anti-Affinity는 특정 Pod가 특정 조건을 가진 다른 Pod와 떨어진 위치에 배치되도록 합니다.

Pod Affinity requiredDuringSchedulingIgnoredDuringExecution : 반드시 조건을 만족해야만 배포
Pod Affinity preferredDuringSchedulingIgnoredDuringExecution : 조건을 선호하지만, 만족하지 않아도 배포 가능

예시) app=frontend 라벨을 가진 Pod가 반드시 app=backend 라벨을 가진 Pod와 같은 Node에 배치되도록 설정합니다.

apiVersion: v1
kind: Pod
metadata:
  name: frontend-pod
  labels:
    app: frontend
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchExpressions:
            - key: app
              operator: In
              values:
              - backend
          topologyKey: "kubernetes.io/hostname"
  containers:
  - name: nginx
    image: nginx

예시) app=frontend 라벨을 가진 Pod가 가능하면 app=backend 라벨을 가진 Pod와 같은 Node에 배치되도록 선호합니다.

apiVersion: v1
kind: Pod
metadata:
  name: frontend-pod
  labels:
    app: frontend
spec:
  affinity:
    podAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
        - weight: 1
          podAffinityTerm:
            labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - backend
            topologyKey: "kubernetes.io/hostname"
  containers:
  - name: nginx
    image: nginx

예시) app=frontend 라벨을 가진 Pod가 반드시 app=frontend 라벨을 가진 다른 Pod와 다른 Node에 배치되도록 설정합니다.

apiVersion: v1
kind: Pod
metadata:
  name: frontend-pod
  labels:
    app: frontend
spec:
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchExpressions:
            - key: app
              operator: In
              values:
              - frontend
          topologyKey: "kubernetes.io/hostname"
  containers:
  - name: nginx
    image: nginx

다영한 스케줄링 조건 및 정책을 사용하는 이유?

Kubernetes에서 다양한 스케줄링 조건 및 정책을 사용하는 이유는 클러스터의 자원 효율성, 애플리케이션 안정성, 운영 유연성을 극대화하기 위해서입니다. Kubernetes는 온프레미스, 클라우드, 하이브리드 환경 등 다양한 인프라에서 운영될 수 있으며, 각 환경과 워크로드의 요구 사항에 최적화된 배포를 지원하는 것이 중요합니다. 이러한 목적을 달성하기 위해 다양한 스케줄링 조건과 정책이 조합되어 사용됩니다.

예시 시나리오

• 고성능 워크로드 배포
  • Node Affinity를 사용해 GPU를 장착한 Node에만 배포.
  • Taints/Tolerations로 일반 워크로드가 GPU Node에 배치되지 않도록 설정.
  • Resource Limits로 GPU 리소스를 효율적으로 할당.
• 웹 애플리케이션 배포
  • Pod Affinity를 사용하여 backend 서버와 DB 서버를 같은 Node에 배포.
  • Pod Anti-Affinity를 사용하여 backend 서버와 frontend 서버를 다른 Node에 배포.
  • Node Selector를 사용하여 disk가 ssd인 Node에 DB 서버 배포.
• 데이터 분석 워크로드 배포
  • Node Affinity로 SSD를 사용하는 Node에만 배치.
  • Resource Requests로 대량의 메모리와 CPU 확보.
  • Anti-Affinity로 동일한 Node에 과도한 분석 작업 배치 방지.

결론적으로는 Kubernetes의 스케줄링 조건과 정책은 클러스터의 자원 활용을 최적화하고, 다양한 환경과 워크로드에 맞춰 배포를 유연하게 조정하며, 장애 복원력과 안정성을 강화하여 전체적인 운영 효율성을 높이는 데 중요한 역할을 합니다. 이를 통해 클라우드 네이티브 환경에서의 워크로드 배포를 효과적으로 관리할 수 있습니다.

스케줄링 사용 유의점

Kubernetes에서 스케줄링을 사용할 때는 다양한 조건과 정책을 적절히 설정해야 하는데, 잘못된 설정이나 과도한 복잡성은 클러스터의 성능 저하, 운영상의 문제, 리소스 낭비 등을 초래할 수 있습니다.

Pod의 Resource Requests와 Limits를 잘못 설정하면 스케줄링 가능한 Node가 부족해지거나, Limits를 너무 낮게 설정하면 Pod이 리소스를 초과해 비정상동작할 수 있습니다. 또한 Node Affinity, Pod Affinity/Anti-Affinity, Taints와 Tolerations 등의 조건은 배포를 세밀하게 제어할 수 있지만, 너무 복잡한 조건을 설정하면 오히려 스케줄링 가능한 Node가 줄어드는 문제가 발생할 수 있습니다.

이러한 문제를 방지하기 위해 애플리케이션의 실제 리소스 요구 사항을 모니터링한 후 적절한 값을 설정하거나 필수 조건과 선호 조건을 적절히 분리하여 설정하고, 필요 이상의 복잡성을 피하는 것이 중요합니다.

Kubernetes에서 Pod 스케줄링 조건 및 정책에 대해 알아봤습니다.

Pod를 배포할 때 다양한 조건과 정책을 사용하여 클러스터의 자원 활용을 최적화하고, 애플리케이션의 안정성과 운영 효율성을 높일 수 있습니다. Node Selector와 Node Affinity를 통해 특정 Node에 Pod를 배치하거나, Taints와 Tolerations을 통해 특정 Node에서만 실행되도록 제어할 수 있습니다. 또한, Resource Request와 Limits를 활용해 Pod의 리소스를 관리하고, Pod Affinity 및 Anti-Affinity로 Pod 간의 배치 관계를 세밀히 조정할 수 있습니다.

이러한 설정을 통해 Kubernetes는 다양한 환경에서 워크로드를 유연하고 안정적으로 배포할 수 있으며, 클라우드 네이티브 애플리케이션의 관리를 더욱 간편하게 만듭니다.

지금까지 Deployment를 통해 pod를 배포하는 방법을 알아보는 시간을 가졌습니다.

유익하게 보셨다면 공감을 눌러주고, 댓글로 의견을 공유해 남겨주시면 감사하겠습니다!

[Reference]
https://kubernetes.io/docs/concepts/scheduling-eviction/
https://kubernetes.io/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/
https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/
https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/

[kubernetes] Deployment로 pod 배포하기

Kubernetes는 컨테이너화된 애플리케이션을 자동으로 배포, 확장, 관리하는 오픈 소스 플랫폼이며, 다양한 환경에서 일관된 애플리케이션 실행을 가능하게 해주는 컨테이너 오케스트레이션 도구입니다.

Kubernetes에서 Deployment는 애플리케이션을 선언적으로 배포하고 관리하는 리소스로, Pod의 생성, 업데이트, 확장 및 롤백을 자동화합니다. 이를 통해 안정적인 상태를 유지하며 원하는 개수의 Pod를 보장하고 애플리케이션의 지속적인 배포를 지원합니다.

Kubernetes에서 Deployment를 통해 pod를 배포하는 방법을 알아보도록 하겠습니다.

주요 기능

Kubernetes Deployment는 애플리케이션 배포, 업데이트, 확장 및 롤백을 자동화하는 Kubernetes의 핵심 리소스입니다.
Deployment는 선언적 접근 방식을 사용하여 애플리케이션의 원하는 상태를 정의하고, 이를 기반으로 Kubernetes가 클러스터에서 해당 상태를 유지하도록 관리합니다.

• Pod의 선언적 관리 : 사용자는 YAML 파일로 애플리케이션의 상태를 정의하고, Deployment는 이를 자동으로 관리합니다.
• 롤링 업데이트 : 애플리케이션 버전을 순차적으로 업데이트하여 무중단 배포를 지원합니다.
• 롤백 : 문제가 발생하면 이전 버전으로 쉽게 되돌릴 수 있습니다.
• 자동 복구 : Pod가 비정상 상태일 경우 자동으로 재생성하거나 복제본을 유지합니다.
• 확장 : 수평 확장을 통해 애플리케이션의 Pod 개수를 조정할 수 있습니다.

Deployment를 사용하는 이유

직접 배포된 Pod는 클러스터 내에서 특정 노드가 다운되거나 문제가 발생할 경우 자동으로 재생성되지 않으며, 확장성과 관리의 어려움이 있습니다.또한 새로운 버전의 애플리케이션을 배포하거나 설정을 변경하는 경우, 기존 Pod를 삭제하고 새로운 Pod를 수동으로 생성하고 롤백도 수동 작업이 필요합니다.

이와 같이 직접 Pod를 배포하는 것은 여러 문제점과 관리에 비효율적이기 때문에 Deployment를 사용하여 Pod를 배포하는 것이 좋습니다.

실행 방법

kubectl 명령을 사용하여 Deployment를 생성하거나 YAML 파일을 사용하여 Deployment를 생성할 수 있습니다.

kubectl 명령을 사용한 Deployment 생성

kubectl 명령은 간단한 방식으로 Deployment를 생성할 수 있습니다.

# kubectl create deployment nginx-deployment --image=nginx:1.21 --replicas=3
deployment.apps/nginx-deployment created

YAML 파일을 사용한 Deployment 생성

YAML 파일은 Deployment의 세부 설정을 명시적으로 작성할 때 유용합니다.

# cat nginx-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.21


kubectl create -f nginx-deployment.yaml
deployment.apps/nginx-deployment created

확인

kubectl get deployments 명령어를 통해 deployment의 상태를 확인할 수 있으며 -o wide 옵션을 추가하면 추가 정보 또한 확인할 수 있습니다.

# kubectl get deployments -o wide
NAME               READY   UP-TO-DATE   AVAILABLE   AGE    CONTAINERS   IMAGES       SELECTOR
nginx-deployment   3/3     3            3           114s   nginx        nginx:1.21   app=nginx

• NAME : deployments의 이름
• READY : Ready 상태인 Pod의 수와 Deployment가 관리하는 총 Pod 수를 표시
  • x/y x/y 형식으로 표시되며, x는 Ready 상태(정상 실행 중)인 Pod의 수이고, y는 Deployment가 관리하는 총 Pod의 수를 나타냅니다
• UP-TO-DATE : 업데이트된 템플릿(이미지, 설정 등)을 기반으로 생성된 Pod의 수
• AVAILABLE : 사용자 요청을 처리할 준비가 된 Pod의 수
• AGE : Deployment가 생성된 후 경과된 시간
• CONTAINERS : Deployment에서 관리하는 Pod 내 컨테이너 이름
• IMAGES : Deployment에서 사용된 컨테이너 이미지
• SELECTOR : Deployment가 관리하는 Pod를 식별하기 위한 Label

kubectl get deployments 명령어를 통해 deployment를 통해 생성된 pod를 확인할 수 있습니다.
설정한 replicas 값 만큼 총 3개의 pod가 생성되었습니다.

# kubectl get pod
NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-6c789f6549-42gqp   1/1     Running   0          6m50s
nginx-deployment-6c789f6549-qtn8b   1/1     Running   0          6m50s
nginx-deployment-6c789f6549-zpv46   1/1     Running   0          6m50s

Kubernetes에서 Deployment를 통해 pod를 배포하는 방법을 알아봤습니다.

직접 Pod를 배포할 경우 여러 문제점과 관리에 비효율적이기 때문에 Deployment를 사용하여 Pod를 배포하는 것이 좋습니다. kubectl 명령을 사용하면 빠르게 Deployment를 통해 pod를 배포할 수 있으며, YAML 파일을 활용하면 세부 설정과 재사용 가능한 구성을 작성할 수 있습니다. 또한, kubectl get deployments 명령어를 통해 Pod의 배포 상태 및 상세 정보를 확인할 수 있습니다.

지금까지 Deployment를 통해 pod를 배포하는 방법을 알아보는 시간을 가졌습니다.

유익하게 보셨다면 공감을 눌러주고, 댓글로 의견을 공유해 남겨주시면 감사하겠습니다!

[Reference]
https://kubernetes.io/ko/docs/concepts/workloads/controllers/deployment/

[kubernetes] pod 실행하기

Kubernetes는 컨테이너화된 애플리케이션을 자동으로 배포, 확장, 관리하는 오픈 소스 플랫폼이며, 다양한 환경에서 일관된 애플리케이션 실행을 가능하게 해주는 컨테이너 오케스트레이션 도구입니다.

Kubernetes에서 Pod는 하나 이상의 컨테이너와 스토리지, 네트워크를 공유하며 동일한 환경에서 동작하며 컨테이너를 실행하기 위한 가장 작은 단위입니다. Kubernetes에서 Pod를 실행하는 방법은 간단하며, kubectl 명령줄 도구를 사용하거나 YAML 파일을 작성하여 Pod를 생성할 수 있습니다.

실행 방법

kubectl 명령을 사용한 Pod를 실행하거나 YAML 파일을 사용하여 Pod를 실행할 수 있습니다.

kubectl 명령을 사용한 Pod 실행

가장 간단한 방법은 kubectl 명령을 사용하는 것입니다. 예를 들어, Nginx 컨테이너를 실행하려면 다음 명령을 사용할 수 있습니다:

# kubectl run nginx-pod --image=nginx
pod/nginx-pod created

YAML 파일을 사용한 Pod 실행

더 복잡한 설정이 필요하거나 재사용 가능한 구성을 원한다면 YAML 파일을 작성하여 Pod를 생성할 수 있습니다.

# cat nginx-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
  - name: nginx-pod
    image: nginx


# kubectl create -f nginx-pod.yaml
pod/nginx-pod created

확인

kubectl get pods 명령어를 통해 pod의 상태를 확인할 수 있으며 -o wide 옵션을 추가하면 추가 정보 또한 확인할 수 있습니다.

# kubectl get pods nginx-pod -o wide
NAME        READY   STATUS    RESTARTS   AGE   IP          NODE         NOMINATED NODE   READINESS GATES
nginx-pod   1/1     Running   0          23m   10.85.0.4   k8s-wn-001   <none>           <none>

• NAME : Pod의 이름
• READY : Pod 내의 컨테이너가 실행 중인지와 준비 상태인지의 비율
  • x/y 형식으로 표시되며, x는 준비 상태(Ready)인 컨테이너의 수이고, y는 Pod에 포함된 총 컨테이너 수를 나타냅니다.
• STATUS : Pod의 현재 상태
  • Pending : Pod가 스케줄링 중이거나 아직 실행 준비가 되지 않은 상태
  • Running : Pod의 모든 컨테이너가 실행 중이며 최소한 하나가 준비 상태
  • Succeeded : Pod가 정상적으로 종료됨(모든 컨테이너 종료)
  • Failed : 하나 이상의 컨테이너가 비정상적으로 종료됨
  • Unknown : Pod 상태를 알 수 없는 경우
• RESTARTS : Pod 내 컨테이너가 재시작된 횟수
• AGE : Pod가 생성된 후 경과된 시간
• IP : Pod의 내부 IP 주소
• NODE : Pod가 실행 중인 워커 노드의 이름
• NOMINATED NODE : Pod가 스케줄링될 예정인 노드
• READINESS GATES : 추가적인 준비 상태 조건(옵션).

Kubernetes에서 Pod를 실행하는 방법에 대해 알아봤습니다.

kubectl 명령을 사용하면 빠르게 Pod를 실행할 수 있으며, YAML 파일을 활용하면 재사용 가능한 구성을 작성할 수 있습니다. 또한, kubectl get pods 명령어를 통해 Pod의 상태를 확인하고 디버깅할 수 있으며 -o wide 옵션을 사용하면 Pod가 실행 중인 노드와 IP 정보 등 추가 정보를 확인할 수 있습니다.

지금까지 Kubernetes에서 Pod를 실행하는 방법을 알아보는 시간을 가졌습니다.

유익하게 보셨다면 공감을 눌러주고, 댓글로 의견을 공유해 남겨주시면 감사하겠습니다!

[Reference]
https://kubernetes.io/docs/concepts/workloads/pods/

[kubernetes] kubectl explain 명령어

Kubernetes는 컨테이너화된 애플리케이션을 자동으로 배포, 확장, 관리하는 오픈 소스 플랫폼이며, 다양한 환경에서 일관된 애플리케이션 실행을 가능하게 해주는 컨테이너 오케스트레이션 도구입니다.

kubectl explain 명령어는 Kubernetes 리소스의 API 정보를 조회하는 데 사용됩니다. Kubernetes에서 관리하는 리소스와 해당 필드에 대한 상세한 정보를 확인할 수 있으며 사용 방법을 파악하기 위해 활용됩니다.

kubectl explain 명령어 사용을 알아봅시다

명령어 형식

# kubectl explain {리소스} {필드} {옵션}

kubectl explain 명령어는 위와 같은 형식을 사용합니다.

특정 리소스의 구조와 가능한 필드를 파악하고, 특정 필드가 무엇을 의미하는지 설명을 제공합니다.
리소스의 하위 필드로 점진적으로 탐색할 수 있으며, Kubernetes API 버전에 맞는 최신 정보를 제공합니다.

출력 예시

# kubectl explain pods
KIND:       Pod
VERSION:    v1

DESCRIPTION:
    Pod is a collection of containers that can run on a host. This resource is
    created by clients and scheduled onto hosts.

FIELDS:
  apiVersion    <string>
    ##### 설명 #####

  kind  <string>
    ##### 설명 #####

  metadata      <ObjectMeta>
    ##### 설명 #####

  spec  <PodSpec>
    ##### 설명 #####

  status        <PodStatus>
    ##### 설명 #####

출력 필드 설명

• KIND: 리소스의 유형(Type)을 나타내며 기본적인 배포 단위를 의미합니다.
• VERSION: Kubernetes API의 버전을 나타내며 버전에 따라 리소스의 구조나 기능이 달라질 수 있습니다.
• DESCRIPTION: 리소스의 전반적인 설명을 제공하며 목적, 동작 방식, 및 기본 개념을 간략히 설명합니다.
• FIELDS: 리소스의 세부 필드 목록과 각 필드의 목적 및 설명을 제공하며 필드 이름, 데이터 유형 등을 설명합니다.

추가 옵션

--recursive 옵션을 사용하여 하위 필드 정보 한번에 보기

# kubectl explain pods.spec.containers  --recursive
KIND:       Pod
VERSION:    v1

FIELD: containers <[]Container>


DESCRIPTION:
    ##### 생략 #####

FIELDS:
  args  <[]string>
  command       <[]string>
  env   <[]EnvVar>
    name        <string> -required-
    value       <string>
    valueFrom   <EnvVarSource>
      configMapKeyRef   <ConfigMapKeySelector>
        key     <string> -required-
        name    <string>
        optional        <boolean>
      ##### 생략 #####

--api-version 옵션을 사용하여 특정 API 버전의 리소스 정보 확인

API 버전에 따라 빌드 정보가 다른 것을 확인할 수 있습니다.

# kubectl explain hpa.spec --api-version=autoscaling/v1

##### 생략 #####
FIELDS:
  maxReplicas   <integer> -required-
    ##### 생략 #####

  minReplicas   <integer>
    ##### 생략 #####

  scaleTargetRef        <CrossVersionObjectReference> -required-
    ##### 생략 #####

  targetCPUUtilizationPercentage        <integer>
    ##### 생략 #####


# kubectl explain hpa.spec --api-version=autoscaling/v2

##### 생략 #####
FIELDS:
  behavior      <HorizontalPodAutoscalerBehavior>
    ##### 생략 #####

  maxReplicas   <integer> -required-
    ##### 생략 #####

  metrics       <[]MetricSpec>
    ##### 생략 #####

  minReplicas   <integer>
    ##### 생략 #####

  scaleTargetRef        <CrossVersionObjectReference> -required-
    ##### 생략 #####

활용

kubectl explain 명령어의 가장 큰 활용 방법은 리소스 정의를 이해하고, YAML 파일을 작성하거나 디버깅할 때 매우 유용하다는 것입니다. 특히 리소스의 구조, 필드, 그리고 필드의 올바른 이름과 사용법 등을 상세히 확인할 수 있습니다.

필드의 리소스 타입이 <[]string>인지 <string>인지 구분하여 타입에 맞는 구조로 YAML 파일을 작성할 수 있습니다. 또한 하위 필드에 필요한 옵션 및 정보들을 확인하여 리소스를 생성하거나 디버깅할 때 유용하며 YAML 파일에서 오류가 발생했을 때, 잘못된 필드 이름이나 누락된 필드를 찾을 때 사용할 수 있습니다.

Kubernetes 공식 문서를 통해서 각 리소스의 필드에 대한 정보를 확인할 수 있지만, kubectl explain 명령어를 통해서도 상세하게 확인할 수 있으며 명령어를 통해 바로 확인할 수 있다는 장점이 있을 것 같습니다.

Kubernetes에서 kubectl explain 명령어를 통해 리소스 정의를 이해하고 활용하는 방법을 알아봤습니다.

kubectl explain 명령어는 Kubernetes에서 관리하는 리소스와 해당 필드의 구조, 데이터 타입, 그리고 사용 방법을 상세히 확인할 수 있도록 도와줍니다. 이를 통해 YAML 파일 작성 시 참고하거나, 디버깅 및 리소스 학습 시 유용하게 사용할 수 있습니다.

특정 리소스의 구조와 필드를 점진적으로 탐색할 수 있으며, --recursive 옵션을 통해 모든 하위 필드 정보를 한 번에 출력하거나, --api-version 옵션을 통해 API 버전에 따른 차이를 확인할 수 있습니다. 특히 필드의 데이터 타입(<[]string>, <string> 등)를 명확히 파악하여 YAML 파일을 올바르게 작성할 수 있고, 공식 문서를 참조하지 않아도 명령어를 통해 바로 리소스 정보를 확인할 수 있다는 장점이 있습니다.

지금까지 Kubernetes에서 kubectl explain 명령어의 사용법과 활용 방법에 대해 알아보는 시간을 가졌습니다.

유익하게 보셨다면 공감을 눌러주고, 댓글로 의견을 공유해 남겨주시면 감사하겠습니다!

[Reference]
https://kubernetes.io/docs/reference/kubectl/generated/kubectl_explain/

[kubernetes] kubectl api-resources 명령어

Kubernetes는 컨테이너화된 애플리케이션을 자동으로 배포, 확장, 관리하는 오픈 소스 플랫폼이며, 다양한 환경에서 일관된 애플리케이션 실행을 가능하게 해주는 컨테이너 오케스트레이션 도구입니다.

kubectl api-resources 명령어는 Kubernetes 클러스터에서 사용할 수 있는 API 리소스 목록을 확인하는 데 사용됩니다. Kubernetes에서 지원하는 리소스와 해당 리소스의 범위(네임스페이스 포함 여부) 및 가능한 동작(verbs)을 표시합니다.

kubectl api-resources 명령어 사용을 알아봅시다

출력 예시

# kubectl api-resources
NAME                                SHORTNAMES   APIVERSION                        NAMESPACED   KIND
bindings                                         v1                                true         Binding
componentstatuses                   cs           v1                                false        ComponentStatus
configmaps                          cm           v1                                true         ConfigMap
endpoints                           ep           v1                                true         Endpoints
events                              ev           v1                                true         Event
limitranges                         limits       v1                                true         LimitRange
namespaces                          ns           v1                                false        Namespace
nodes                               no           v1                                false        Node
persistentvolumeclaims              pvc          v1                                true         PersistentVolumeClaim
persistentvolumes                   pv           v1                                false        PersistentVolume
pods                                po           v1                                true         Pod
podtemplates                                     v1                                true         PodTemplate
replicationcontrollers              rc           v1                                true         ReplicationController
resourcequotas                      quota        v1                                true         ResourceQuota
secrets                                          v1                                true         Secret
serviceaccounts                     sa           v1                                true         ServiceAccount
services                            svc          v1                                true         Service
mutatingwebhookconfigurations                    admissionregistration.k8s.io/v1   false        MutatingWebhookConfiguration
validatingadmissionpolicies                      admissionregistration.k8s.io/v1   false        ValidatingAdmissionPolicy
validatingadmissionpolicybindings                admissionregistration.k8s.io/v1   false        ValidatingAdmissionPolicyBinding
validatingwebhookconfigurations                  admissionregistration.k8s.io/v1   false        ValidatingWebhookConfiguration
customresourcedefinitions           crd,crds     apiextensions.k8s.io/v1           false        CustomResourceDefinition
apiservices                                      apiregistration.k8s.io/v1         false        APIService
controllerrevisions                              apps/v1                           true         ControllerRevision
daemonsets                          ds           apps/v1                           true         DaemonSet
deployments                         deploy       apps/v1                           true         Deployment
replicasets                         rs           apps/v1                           true         ReplicaSet
statefulsets                        sts          apps/v1                           true         StatefulSet
selfsubjectreviews                               authentication.k8s.io/v1          false        SelfSubjectReview
tokenreviews                                     authentication.k8s.io/v1          false        TokenReview
localsubjectaccessreviews                        authorization.k8s.io/v1           true         LocalSubjectAccessReview
selfsubjectaccessreviews                         authorization.k8s.io/v1           false        SelfSubjectAccessReview
selfsubjectrulesreviews                          authorization.k8s.io/v1           false        SelfSubjectRulesReview
subjectaccessreviews                             authorization.k8s.io/v1           false        SubjectAccessReview
horizontalpodautoscalers            hpa          autoscaling/v2                    true         HorizontalPodAutoscaler
cronjobs                            cj           batch/v1                          true         CronJob
jobs                                             batch/v1                          true         Job
certificatesigningrequests          csr          certificates.k8s.io/v1            false        CertificateSigningRequest
leases                                           coordination.k8s.io/v1            true         Lease
endpointslices                                   discovery.k8s.io/v1               true         EndpointSlice
events                              ev           events.k8s.io/v1                  true         Event
flowschemas                                      flowcontrol.apiserver.k8s.io/v1   false        FlowSchema
prioritylevelconfigurations                      flowcontrol.apiserver.k8s.io/v1   false        PriorityLevelConfiguration
ingressclasses                                   networking.k8s.io/v1              false        IngressClass
ingresses                           ing          networking.k8s.io/v1              true         Ingress
networkpolicies                     netpol       networking.k8s.io/v1              true         NetworkPolicy
runtimeclasses                                   node.k8s.io/v1                    false        RuntimeClass
poddisruptionbudgets                pdb          policy/v1                         true         PodDisruptionBudget
clusterrolebindings                              rbac.authorization.k8s.io/v1      false        ClusterRoleBinding
clusterroles                                     rbac.authorization.k8s.io/v1      false        ClusterRole
rolebindings                                     rbac.authorization.k8s.io/v1      true         RoleBinding
roles                                            rbac.authorization.k8s.io/v1      true         Role
priorityclasses                     pc           scheduling.k8s.io/v1              false        PriorityClass
csidrivers                                       storage.k8s.io/v1                 false        CSIDriver
csinodes                                         storage.k8s.io/v1                 false        CSINode
csistoragecapacities                             storage.k8s.io/v1                 true         CSIStorageCapacity
storageclasses                      sc           storage.k8s.io/v1                 false        StorageClass
volumeattachments                                storage.k8s.io/v1                 false        VolumeAttachment

출력 필드 설명

• NAME: 리소스 이름
• SHORTNAMES: 리소스의 단축 이름(별칭) / 예시) po는 pods, svc는 services의 단축형
• APIVERSION: 리소스를 제공하는 API 그룹과 버전
• NAMESPACED: 해당 리소스가 네임스페이스 범위인지 여부.
  • true: 네임스페이스 내부에 존재
  • false: 클러스터 범위에 존재
• KIND: 리소스의 오브젝트 종류

추가 동작

특정 API 그룹에 속한 리소스 보기

# kubectl api-resources --api-group=apps
NAME                  SHORTNAMES   APIVERSION   NAMESPACED   KIND
controllerrevisions                apps/v1      true         ControllerRevision
daemonsets            ds           apps/v1      true         DaemonSet
deployments           deploy       apps/v1      true         Deployment
replicasets           rs           apps/v1      true         ReplicaSet
statefulsets          sts          apps/v1      true         StatefulSet

지원되는 동작(verbs) 확인

# kubectl api-resources --verbs=list,get
NAME                                SHORTNAMES   APIVERSION                        NAMESPACED   KIND
componentstatuses                   cs           v1                                false        ComponentStatus
configmaps                          cm           v1                                true         ConfigMap
endpoints                           ep           v1                                true         Endpoints
events                              ev           v1                                true         Event
limitranges                         limits       v1                                true         LimitRange
namespaces                          ns           v1                                false        Namespace
nodes                               no           v1                                false        Node
persistentvolumeclaims              pvc          v1                                true         PersistentVolumeClaim
persistentvolumes                   pv           v1                                false        PersistentVolume
pods                                po           v1                                true         Pod
podtemplates                                     v1                                true         PodTemplate
replicationcontrollers              rc           v1                                true         ReplicationController
resourcequotas                      quota        v1                                true         ResourceQuota
secrets                                          v1                                true         Secret
serviceaccounts                     sa           v1                                true         ServiceAccount
services                            svc          v1                                true         Service
mutatingwebhookconfigurations                    admissionregistration.k8s.io/v1   false        MutatingWebhookConfiguration
validatingadmissionpolicies                      admissionregistration.k8s.io/v1   false        ValidatingAdmissionPolicy
validatingadmissionpolicybindings                admissionregistration.k8s.io/v1   false        ValidatingAdmissionPolicyBinding
validatingwebhookconfigurations                  admissionregistration.k8s.io/v1   false        ValidatingWebhookConfiguration
customresourcedefinitions           crd,crds     apiextensions.k8s.io/v1           false        CustomResourceDefinition
apiservices                                      apiregistration.k8s.io/v1         false        APIService
controllerrevisions                              apps/v1                           true         ControllerRevision
daemonsets                          ds           apps/v1                           true         DaemonSet
deployments                         deploy       apps/v1                           true         Deployment
replicasets                         rs           apps/v1                           true         ReplicaSet
statefulsets                        sts          apps/v1                           true         StatefulSet
horizontalpodautoscalers            hpa          autoscaling/v2                    true         HorizontalPodAutoscaler
cronjobs                            cj           batch/v1                          true         CronJob
jobs                                             batch/v1                          true         Job
certificatesigningrequests          csr          certificates.k8s.io/v1            false        CertificateSigningRequest
leases                                           coordination.k8s.io/v1            true         Lease
endpointslices                                   discovery.k8s.io/v1               true         EndpointSlice
events                              ev           events.k8s.io/v1                  true         Event
flowschemas                                      flowcontrol.apiserver.k8s.io/v1   false        FlowSchema
prioritylevelconfigurations                      flowcontrol.apiserver.k8s.io/v1   false        PriorityLevelConfiguration
ingressclasses                                   networking.k8s.io/v1              false        IngressClass
ingresses                           ing          networking.k8s.io/v1              true         Ingress
networkpolicies                     netpol       networking.k8s.io/v1              true         NetworkPolicy
runtimeclasses                                   node.k8s.io/v1                    false        RuntimeClass
poddisruptionbudgets                pdb          policy/v1                         true         PodDisruptionBudget
clusterrolebindings                              rbac.authorization.k8s.io/v1      false        ClusterRoleBinding
clusterroles                                     rbac.authorization.k8s.io/v1      false        ClusterRole
rolebindings                                     rbac.authorization.k8s.io/v1      true         RoleBinding
roles                                            rbac.authorization.k8s.io/v1      true         Role
priorityclasses                     pc           scheduling.k8s.io/v1              false        PriorityClass
csidrivers                                       storage.k8s.io/v1                 false        CSIDriver
csinodes                                         storage.k8s.io/v1                 false        CSINode
csistoragecapacities                             storage.k8s.io/v1                 true         CSIStorageCapacity
storageclasses                      sc           storage.k8s.io/v1                 false        StorageClass
volumeattachments                                storage.k8s.io/v1                 false        VolumeAttachment

네임스페이스 범위 리소스 확인

# kubectl api-resources --namespaced=false
NAME                                SHORTNAMES   APIVERSION                        NAMESPACED   KIND
componentstatuses                   cs           v1                                false        ComponentStatus
namespaces                          ns           v1                                false        Namespace
nodes                               no           v1                                false        Node
persistentvolumes                   pv           v1                                false        PersistentVolume
mutatingwebhookconfigurations                    admissionregistration.k8s.io/v1   false        MutatingWebhookConfiguration
validatingadmissionpolicies                      admissionregistration.k8s.io/v1   false        ValidatingAdmissionPolicy
validatingadmissionpolicybindings                admissionregistration.k8s.io/v1   false        ValidatingAdmissionPolicyBinding
validatingwebhookconfigurations                  admissionregistration.k8s.io/v1   false        ValidatingWebhookConfiguration
customresourcedefinitions           crd,crds     apiextensions.k8s.io/v1           false        CustomResourceDefinition
apiservices                                      apiregistration.k8s.io/v1         false        APIService
selfsubjectreviews                               authentication.k8s.io/v1          false        SelfSubjectReview
tokenreviews                                     authentication.k8s.io/v1          false        TokenReview
selfsubjectaccessreviews                         authorization.k8s.io/v1           false        SelfSubjectAccessReview
selfsubjectrulesreviews                          authorization.k8s.io/v1           false        SelfSubjectRulesReview
subjectaccessreviews                             authorization.k8s.io/v1           false        SubjectAccessReview
certificatesigningrequests          csr          certificates.k8s.io/v1            false        CertificateSigningRequest
flowschemas                                      flowcontrol.apiserver.k8s.io/v1   false        FlowSchema
prioritylevelconfigurations                      flowcontrol.apiserver.k8s.io/v1   false        PriorityLevelConfiguration
ingressclasses                                   networking.k8s.io/v1              false        IngressClass
runtimeclasses                                   node.k8s.io/v1                    false        RuntimeClass
clusterrolebindings                              rbac.authorization.k8s.io/v1      false        ClusterRoleBinding
clusterroles                                     rbac.authorization.k8s.io/v1      false        ClusterRole
priorityclasses                     pc           scheduling.k8s.io/v1              false        PriorityClass
csidrivers                                       storage.k8s.io/v1                 false        CSIDriver
csinodes                                         storage.k8s.io/v1                 false        CSINode
storageclasses                      sc           storage.k8s.io/v1                 false        StorageClass
volumeattachments                                storage.k8s.io/v1                 false        VolumeAttachment

활용

Kubernetes의 여러가지 기능은 API 리소스를 통해 구현할 수 있습니다.

Kubernetes 버전에 따라 사용할 수 있는 기능과 API의 버전은 다릅니다.
기본적으로 Kubernetes 공식 릴리즈 노트를 통해 해당 정보를 확인할 수 있지만 kubectl api-resources 명령어를 통해 현재 사용할 수 있는 API 리소스 리스트를 확인하는 목적이 가장 클 것 같습니다.

특정 리소스에 대해 지원되는 API 버전을 확인할 수 있으며, 특정 API 버전이 제거되거나 업데이트될 경우 대체 API로 전환할 수 있습니다. 네임스페이스 범위와 클러스터 범위의 리소스를 명확히 구분하고 싶을 때 kubectl api-resources 명령어를 사용하여 확인할 수 있습니다.

Kubernetes에서 kubectl api-resources 명령어를 통해 클러스터에서 사용할 수 있는 API 리소스를 확인하는 방법을 알아봤습니다.

kubectl api-resources 명령어는 Kubernetes에서 지원하는 리소스의 이름, 단축 이름(SHORTNAMES), API 그룹과 버전(APIVERSION), 네임스페이스 범위 여부(NAMESPACED), 오브젝트 종류(KIND) 등을 확인할 수 있습니다. 이를 통해 현재 클러스터에서 활성화된 리소스를 쉽게 탐색할 수 있습니다.

특정 API 그룹에 속한 리소스를 조회하거나, 네임스페이스 범위의 리소스만 확인하는 등 다양한 옵션을 활용하여 필요한 리소스 정보를 빠르게 얻을 수 있습니다. 또한 Kubernetes 버전별로 지원되는 API 리소스와 버전을 확인할 때 유용하며, 특정 API가 제거되거나 업데이트될 경우 대체 API로 전환하는 데에도 도움을 줍니다.

지금까지 Kubernetes에서 kubectl api-resources 명령어의 사용법과 활용 방법에 대해 알아보는 시간을 가졌습니다.

유익하게 보셨다면 공감을 눌러주고, 댓글로 의견을 공유해 남겨주시면 감사하겠습니다!

[Reference]
https://kubernetes.io/docs/reference/kubectl/generated/kubectl_api-resources/