Devops 기술면접 예상질문

Devops에 대해 설명하시오

DevOps는 **Development(개발)**와 **Operations(운영)**의 합성어로, 소프트웨어 개발과 IT 운영 간의 협업과 통합을 통해 소프트웨어 개발 주기를 단축하고, 품질을 개선하며, 지속적인 배포와 운영을 자동화하는 방법론을 의미합니다. DevOps의 목표는 조직이 빠르게 변화하는 비즈니스 요구에 신속하게 대응할 수 있도록 하기 위해 개발팀과 운영팀 간의 경계를 허물고, 협업과 자동화를 통해 효율적인 소프트웨어 전달을 가능하게 하는 것입니다.

MSA 구조에 대해 설명하시오.

MSA(Microservices Architecture, 마이크로서비스 아키텍처)는 애플리케이션을 독립적으로 배포하고 관리할 수 있는 작은 서비스들로 구성하는 아키텍처 스타일입니다. 전통적인 모놀리식 아키텍처와 달리, MSA는 애플리케이션을 여러 개의 독립적인 마이크로서비스로 분리하여 각 서비스가 독립적으로 개발, 배포, 확장될 수 있도록 설계합니다.

1. MSA의 주요 개념

서비스의 독립성: 각 마이크로서비스는 하나의 작은 애플리케이션처럼 동작하며, 특정 기능을 책임집니다. 예를 들어, 주문 처리, 사용자 관리, 결제와 같은 기능이 각각의 독립된 마이크로서비스로 구현될 수 있습니다.
개별 배포 및 확장: 마이크로서비스는 독립적으로 배포할 수 있으며, 특정 서비스만 확장하거나 업데이트할 수 있습니다. 이를 통해 애플리케이션 전체를 중단시키지 않고 기능을 추가하거나 문제를 해결할 수 있습니다.
API 기반 통신: 각 마이크로서비스는 API를 통해 서로 통신합니다. RESTful API, gRPC, 메시지 큐 등 다양한 통신 방식이 사용될 수 있으며, 서비스 간의 의존성을 최소화합니다.
분산 데이터 관리: 전통적인 모놀리식 구조에서는 하나의 중앙 데이터베이스를 사용하지만, MSA에서는 각 마이크로서비스가 자체 데이터베이스를 관리할 수 있습니다. 이를 통해 데이터 모델이 개별 서비스의 요구에 맞춰 독립적으로 변경될 수 있습니다.

2. MSA의 주요 특징

2.1 모듈화 및 유연성

MSA는 애플리케이션을 여러 개의 작은 모듈로 분리하므로, 기능 추가나 변경이 용이합니다.
새로운 기술이나 프로그래밍 언어를 개별 마이크로서비스에 도입할 수 있어 기술적 유연성이 높습니다.

2.2 독립적인 배포

각 마이크로서비스를 독립적으로 배포할 수 있어, 부분적인 기능 추가 및 업데이트가 가능합니다.
서비스 간의 결합도가 낮아 한 서비스의 변경이 다른 서비스에 미치는 영향을 최소화할 수 있습니다.

2.3 개별 확장 가능

서비스의 부하에 따라 개별 마이크로서비스를 독립적으로 확장할 수 있습니다.
예를 들어, 주문 처리 서비스의 트래픽이 많을 경우 해당 서비스만 확장하여 자원을 효율적으로 사용할 수 있습니다.

3. MSA의 장점

확장성: 개별 서비스의 트래픽 증가에 따라 필요한 서비스만 확장할 수 있어 자원 사용의 효율성이 높습니다.
신속한 배포: 특정 서비스만 수정하고 배포할 수 있어 개발 속도가 빠르며, 롤백도 용이합니다.
개발팀의 독립성: 각 마이크로서비스를 독립적인 팀이 관리할 수 있어 병목 현상을 줄일 수 있습니다. 서비스마다 서로 다른 언어, 프레임워크, 데이터베이스를 사용할 수 있습니다.
탄력적인 장애 대응: 한 서비스에 장애가 발생하더라도 다른 서비스는 계속 동작할 수 있으며, 장애를 국소화할 수 있습니다.

4. MSA의 단점 및 과제

복잡한 통신 관리: 서비스 간의 통신이 많아질 수 있으며, API 게이트웨이 및 메시지 브로커 등 복잡한 통신 인프라를 관리해야 합니다.
데이터 일관성 문제: 각 서비스가 독립적인 데이터베이스를 사용하기 때문에 분산된 트랜잭션이나 데이터 일관성 유지가 어렵습니다.
운영 및 모니터링 복잡성: 많은 마이크로서비스를 개별적으로 모니터링하고 관리해야 하므로 DevOps 도구와 운영 인프라가 필요합니다.
테스트 어려움: 독립적인 서비스의 조합으로 애플리케이션이 구성되기 때문에 통합 테스트가 까다롭습니다.

5. MSA와 모놀리식 아키텍처의 비교

특성모놀리식 아키텍처마이크로서비스 아키텍처

구성	하나의 애플리케이션 코드베이스	여러 개의 독립적인 서비스
배포 방식	애플리케이션 전체를 한 번에 배포	개별 서비스 별로 독립적으로 배포
확장성	전체 애플리케이션을 수평 확장해야 함	특정 서비스만 독립적으로 확장 가능
개발팀 구조	한 팀이 전체 애플리케이션을 개발	여러 팀이 각 서비스별로 독립적인 개발
기술적 일관성	동일한 언어와 프레임워크를 사용	서비스마다 서로 다른 기술 스택 사용 가능
데이터 관리	하나의 중앙 데이터베이스 사용	각 서비스가 독립적인 데이터베이스 관리

6. MSA 적용 사례

넷플릭스(Netflix): 마이크로서비스를 적극적으로 도입하여 유저 프로필 관리, 추천 시스템, 스트리밍 서비스 등 수백 개의 마이크로서비스로 애플리케이션을 구성했습니다.
아마존(Amazon): 마이크로서비스를 통해 결제 시스템, 상품 검색, 주문 처리 등을 분리하여 확장성과 가용성을 높였습니다.
우버(Uber): 다양한 마이크로서비스를 통해 지도 서비스, 결제 서비스, 사용자 인증 등을 관리하며 빠른 개발과 배포를 지원합니다.

MSA는 큰 애플리케이션을 더 작고 관리 가능한 단위로 나눔으로써 확장성과 유연성을 제공하지만, 이를 구현하고 운영하는 데 따른 복잡성도 고려해야 합니다. MSA를 성공적으로 구현하려면 서비스 간 통신, 데이터 일관성, 모니터링 등 다양한 운영적 과제를 해결할 수 있는 기술적 준비가 필요합니다.

Network

Kubernetes

Service에 대해 설명하시오

다양한 쿠버네티스 구성요소 간의 통신을 가능하게 해주는 역할

네트워크 종류 3가지에 대해 설명하시오

cluster IP: 클러스터 안에 가상의 ip를 만들어 다른 서비스 간의 통신이 가능하도록 하는것(내부 통신용)
nodeport: 서비스가 내부포트를 노드의 포트에 액세스 할 수 있게 하는곳(외부 통신용)
Loadbalancer: 클라우드에서 공급하는 로드밸런서를 프로비저닝 하는것

kube-proxy에 대해 설명하시오

포드네트워크는 모든 노드에 걸쳐있는 가상의 내부네트워크

daemonset, deployment, statefulset에 대해 설명하시오

1. DaemonSet

개념: DaemonSet은 클러스터 내의 모든 노드에서 특정 애플리케이션의 복사본을 실행하도록 보장합니다. 새로운 노드가 클러스터에 추가되면, 해당 노드에도 자동으로 Pod가 생성됩니다. 마찬가지로 노드가 클러스터에서 제거되면 그 노드에서 실행 중인 Pod도 제거됩니다.
주요 특징:
- 클러스터의 모든 노드 또는 특정 레이블이 있는 노드에 애플리케이션을 배포합니다.
- 로그 수집 에이전트, 모니터링 에이전트, 네트워크 플러그인 등 노드별로 실행해야 하는 작업에 적합합니다.
- 노드 수에 따라 자동으로 Pod가 추가되거나 제거됩니다.
사용 사례:
- 로그 수집 도구(예: Fluentd, Logstash).
- 모니터링 에이전트(예: Prometheus Node Exporter).
- 네트워크 플러그인(Calico, Flannel 등).

2. Deployment

개념: Deployment는 애플리케이션의 스케일링, 업데이트, 롤백을 관리합니다. 기본적으로 무상태(Stateless) 애플리케이션을 배포하는 데 적합하며, 원하는 수의 복제본을 실행하도록 보장합니다.
주요 특징:
- 애플리케이션의 스케일링과 롤링 업데이트를 지원합니다.
- Pod 템플릿을 정의하여 동일한 템플릿을 따르는 여러 복제본을 실행할 수 있습니다.
- 새로운 버전의 애플리케이션을 배포할 때 기존 버전을 점진적으로 교체하면서 무중단 업데이트를 수행할 수 있습니다.
- 롤백 기능을 제공하여 이전 버전으로 쉽게 되돌릴 수 있습니다.
사용 사례:
- 무상태 웹 서버, API 서버 등 동일한 인스턴스가 여러 개 필요한 애플리케이션.
- 애플리케이션의 업데이트 및 롤백이 자주 필요한 경우.

3. StatefulSet

개념: StatefulSet은 상태가 있는(Stateful) 애플리케이션을 배포하고 관리하는 데 사용됩니다. 각 Pod는 고유한 네트워크 ID와 스토리지를 가지며, 순서가 보장되는 생성 및 종료 동작을 제공합니다.
주요 특징:
- 각 Pod는 고유한 네트워크 ID(예: my-app-0, my-app-1)를 가지며, 이 ID는 순서대로 할당됩니다.
- 각 Pod에 대해 고유한 PersistentVolumeClaim(PVC)을 생성하여, Pod가 삭제되더라도 데이터는 유지됩니다.
- Pod의 생성과 종료가 순차적으로 이루어지므로, 순서가 중요한 애플리케이션에 적합합니다.
- 클러스터 간 복제 또는 데이터베이스의 리더-팔로워 설정 등 상태가 중요한 애플리케이션에 유용합니다.
사용 사례:
- 데이터베이스(MySQL, PostgreSQL 등)와 같은 상태가 필요한 애플리케이션.
- 분산 파일 시스템(Cassandra, HDFS).
- 상태가 있는 서비스를 실행해야 하거나, 각 인스턴스의 식별이 중요한 경우.

4. 정리 및 비교

특성DaemonSetDeploymentStatefulSet

목적	모든 노드에서 애플리케이션의 인스턴스를 실행	무상태 애플리케이션의 관리와 스케일링	상태가 있는 애플리케이션의 배포와 관리
Pod 배포 방식	모든 노드 또는 특정 노드에서 실행	원하는 수의 복제본을 생성하여 무작위로 배포	순서에 따라 Pod를 생성하고 종료하며, 고유한 네트워크 ID 부여
스토리지 관리	일반적으로 스토리지와 관련 없음	스토리지 필요 시 외부 스토리지와 연결	각 Pod에 대해 고유한 PVC를 사용, 데이터 유지 보장
업데이트 전략	Pod가 추가/삭제될 때 자동 관리	Rolling Update 및 롤백 지원	순차적 업데이트, 상태가 중요한 애플리케이션에 적합
주요 사용 사례	로그 수집, 모니터링 에이전트, 네트워크 플러그인	무상태 웹 서버, API 서버 등	데이터베이스, 분산 시스템 등 상태 유지가 중요한 애플리케이션

쿠버네티스에서 Node Affinity는 파드가 특정 노드에 스케줄링되도록 제어하는 메커니즘입니다. 이는 주로 워크로드를 특정 노드에서 실행해야 하는 경우나, 하드웨어 특성, 노드 라벨 등과 같은 이유로 파드를 특정 노드에 배치하고자 할 때 사용됩니다. 이는 NodeSelector의 발전된 형태로, 더 세밀한 제어를 제공하는 기능입니다.

Node Affinity의 주요 구성 요소

Node Affinity는 크게 두 가지로 나뉩니다:

필수 조건 (RequiredDuringSchedulingIgnoredDuringExecution)
- 이 조건을 만족하는 노드에서만 파드가 스케줄링됩니다. 즉, 파드를 특정 노드에 반드시 배치해야 할 때 사용됩니다.
- 파드가 실행 중일 때는 이 조건이 더 이상 영향을 미치지 않으며, 노드 상태 변화에 따라 다시 스케줄링되지 않습니다.
선호 조건 (PreferredDuringSchedulingIgnoredDuringExecution)
- 파드를 특정 노드에 선호해서 배치하는 조건을 나타냅니다. 필수는 아니지만, 가능한 경우 해당 노드에 파드를 배치하려고 시도합니다.
- 노드가 해당 조건을 만족하지 않더라도, 파드는 스케줄링될 수 있습니다.

Ingress와 Ingress controller에 대해 설명하시오

Kubernetes에서 Ingress Controller는 클러스터 외부에서 내부 서비스로의 HTTP 및 HTTPS 요청을 관리하는 컴포넌트입니다. Ingress 리소스를 사용하여 애플리케이션에 대한 접근을 정의하고 제어하는 역할을 합니다. Ingress Controller는 이 Ingress 리소스를 해석하여 요청을 적절한 서비스로 라우팅합니다.

1. Ingress와 Ingress Controller 개념

Ingress:
- 클러스터 외부에서 내부 서비스로 HTTP(S) 트래픽을 라우팅하는 규칙을 정의하는 Kubernetes 리소스입니다.
- URL 경로나 호스트 이름에 따라 트래픽을 특정 서비스로 분배할 수 있습니다.
- 로드 밸런싱, SSL 종료, 리다이렉션 및 인증과 같은 고급 라우팅 기능을 지원합니다.
Ingress Controller:
- Ingress 리소스를 실제 네트워크 트래픽 제어로 변환하는 컴포넌트입니다.
- 클러스터에 배포되어, Ingress 리소스에 정의된 규칙에 따라 HTTP(S) 요청을 적절한 서비스로 라우팅합니다.
- 다양한 오픈 소스 및 클라우드 기반 Ingress Controller가 있으며, NGINX, HAProxy, Traefik, AWS ALB Ingress Controller 등이 있습니다.

2. Ingress Controller의 주요 기능

HTTP/HTTPS 라우팅:
- Ingress 리소스의 규칙을 바탕으로 URL 경로, 도메인 이름 등에 따라 트래픽을 올바른 서비스로 라우팅합니다.
- 여러 서비스를 하나의 공용 IP 주소로 노출할 수 있습니다.
로드 밸런싱:
- 여러 백엔드 서비스 인스턴스 간에 트래픽을 분산시켜 애플리케이션의 확장성을 지원합니다.
- Ingress Controller는 로드 밸런서 역할을 하여, 요청을 백엔드 서비스의 여러 Pod로 분배합니다.
SSL/TLS 종료:
- HTTPS 트래픽을 처리할 때 SSL 인증서를 사용하여 암호화를 종료(TLS Termination)하고, 클러스터 내부로는 HTTP로 트래픽을 전달할 수 있습니다.
- 이를 통해 클라이언트와의 통신 보안을 확보할 수 있습니다.
호스트 기반 및 경로 기반 라우팅:
- 여러 도메인이나 서브도메인에 대해 다른 서비스를 라우팅할 수 있습니다(호스트 기반 라우팅).
- URL 경로에 따라 트래픽을 분기시킬 수 있습니다(경로 기반 라우팅).
리다이렉션 및 인증:
- 특정 경로에 대해 HTTP 요청을 HTTPS로 리다이렉트하거나, 사용자 인증을 추가할 수 있습니다.
- 일부 Ingress Controller는 기본 인증이나 OAuth와 같은 인증 기능을 지원합니다.

3. Ingress Controller의 작동 방식

Ingress 리소스 정의:
- 사용자가 Ingress 리소스를 생성하여, 클러스터 외부에서 내부 서비스로의 라우팅 규칙을 정의합니다. 이 규칙에는 호스트 이름, 경로, 백엔드 서비스 정보 등이 포함됩니다.
Ingress Controller 설치:
- 클러스터에 하나 이상의 Ingress Controller를 설치합니다. Ingress Controller는 클러스터 내의 모든 Ingress 리소스를 감시하고, 변경 사항에 따라 설정을 자동으로 업데이트합니다.
트래픽 처리:
- Ingress Controller는 클러스터 외부에서 오는 HTTP/HTTPS 요청을 수신하고, Ingress 리소스에 정의된 규칙에 따라 적절한 서비스로 트래픽을 전달합니다.

4. 주요 Ingress Controller 예시

NGINX Ingress Controller:
- 가장 널리 사용되는 Ingress Controller 중 하나로, NGINX를 기반으로 하여 높은 성능과 다양한 기능을 제공합니다.
- 커스터마이징이 용이하며, 다양한 로드 밸런싱 옵션과 함께 SSL/TLS, 인증, 리다이렉션 등을 지원합니다.
Traefik Ingress Controller:
- 경량화된 Ingress Controller로, Kubernetes의 Ingress 리소스 외에도 Custom Resource Definitions(CRDs)를 사용하여 보다 세밀한 설정이 가능합니다.
- 자동화된 TLS 인증서 발급(Let's Encrypt 통합) 및 고급 로드 밸런싱 기능을 제공하여 인기를 끌고 있습니다.
AWS ALB Ingress Controller:
- Amazon Web Services(AWS)에서 제공하는 Application Load Balancer(ALB)를 기반으로 한 Ingress Controller입니다.
- ALB의 네이티브 기능을 활용하여 Kubernetes 클러스터에서 HTTP/HTTPS 트래픽을 처리할 수 있습니다.
Istio Ingress Gateway:
- 서비스 메쉬 솔루션인 Istio의 Ingress 기능을 활용하여, 클러스터 외부와 내부의 통신을 제어합니다.
- 고급 트래픽 관리와 보안 정책을 설정할 수 있으며, 마이크로서비스 아키텍처와 잘 어울립니다.

5. Ingress Controller의 장점

단일 진입점 관리: 여러 서비스에 대한 트래픽을 하나의 공용 IP 주소를 통해 관리할 수 있어, 인프라 설정과 관리가 간소화됩니다.
고급 라우팅 기능: 다양한 호스트 및 경로 기반의 라우팅 규칙을 정의할 수 있어 유연한 트래픽 제어가 가능합니다.
보안 강화: SSL/TLS 설정과 인증 기능을 통해 클러스터 외부와의 통신 보안을 강화할 수 있습니다.

6. Ingress Controller의 단점 및 고려 사항

설정 복잡성: 고급 기능을 사용할 때 Ingress 리소스와 Controller의 설정이 복잡할 수 있습니다.
제한된 트래픽 관리: 기본적인 Ingress 리소스는 정교한 트래픽 관리 기능이 부족할 수 있으며, 이를 보완하기 위해 추가적인 설정이나 Custom Resource Definitions(CRDs)가 필요할 수 있습니다.
클라우드 플랫폼 종속성: 특정 클라우드 플랫폼에 특화된 Ingress Controller(AWS ALB, GCP HTTP Load Balancer 등)를 사용할 경우 클라우드 종속성이 생길 수 있습니다.

Ingress Controller는 Kubernetes에서 외부 트래픽을 내부 서비스로 안전하고 효율적으로 라우팅하는 핵심 컴포넌트입니다. 다양한 구현체와 기능을 활용하여 애플리케이션의 네트워크 트래픽을 효과적으로 관리할 수 있습니다.

Kubernetes 버전 업데이트

Kubernetes의 버전 업데이트는 클러스터의 안정성을 유지하면서 최신 기능과 보안 패치를 적용하기 위한 중요한 작업입니다. 업데이트 과정은 클러스터의 구성 요소인 **Control Plane(제어 평면)**과 **Worker Node(작업자 노드)**를 순차적으로 업그레이드하는 절차로 나뉩니다. 안전한 업데이트를 위해서는 다음과 같은 단계를 따르는 것이 일반적입니다.

1. 업데이트 계획 수립

현재 버전 확인: 클러스터의 현재 Kubernetes 버전을 확인합니다. kubectl version 명령어를 사용하여 클라이언트 및 서버 버전을 조회할 수 있습니다.
업데이트 경로 검토: Kubernetes는 각 버전 간에 단계별로 업데이트해야 합니다. 예를 들어, 1.22 버전에서 1.24로 바로 업그레이드할 수 없으며, 중간 버전인 1.23을 거쳐야 합니다.
백업 수행: 데이터와 클러스터 구성을 안전하게 백업합니다. etcd 데이터베이스를 백업하고, 클러스터 구성 파일을 보관해 두는 것이 좋습니다.

2. Control Plane 업그레이드

Control Plane을 먼저 업그레이드해야 합니다. Control Plane에는 kube-apiserver, kube-controller-manager, kube-scheduler, etcd 등 클러스터의 중심 구성 요소가 포함됩니다.

API 서버의 업그레이드:
- kube-apiserver를 새로운 버전으로 업그레이드합니다. 이 단계에서 API 서버의 다운타임을 최소화하기 위해 고가용성 구성된 클러스터에서는 순차적으로 업그레이드할 수 있습니다.
컨트롤러 매니저와 스케줄러 업그레이드:
- kube-controller-manager와 kube-scheduler를 새로운 버전으로 업그레이드합니다.
etcd 업그레이드(필요한 경우):
- etcd 데이터베이스의 버전도 클러스터와 호환되는지 확인하고, 필요한 경우 업그레이드합니다.
Control Plane 구성 요소 검증:
- 모든 Control Plane 구성 요소가 새로운 버전으로 정상 동작하는지 검증합니다. kubectl get componentstatuses 명령을 사용하여 확인할 수 있습니다.

3. Worker Node 업그레이드

Control Plane 업그레이드가 완료되면 Worker Node의 업그레이드를 진행할 수 있습니다. 노드 업그레이드는 하나씩 순차적으로 수행하여 서비스 중단을 방지합니다.

노드 cordon 및 drain:
- kubectl cordon <노드 이름> 명령어를 사용해 특정 노드를 일정에서 제외합니다.
- kubectl drain <노드 이름> --ignore-daemonsets 명령어를 통해 노드에서 실행 중인 Pod를 다른 노드로 이동시킵니다.
Kubelet 및 Kubeadm 업그레이드:
- kubeadm을 업그레이드하여 클러스터 업그레이드 도구를 최신 버전으로 맞춥니다.
- kubelet을 업그레이드하여 노드의 Kubelet 버전을 클러스터 버전에 맞춥니다.
노드 재부팅 및 재조인:
- 업그레이드 후 노드를 재부팅하고 클러스터에 다시 추가합니다(kubectl uncordon <노드 이름> 사용).
모든 노드에 대해 반복:
- 클러스터의 모든 Worker Node가 새로운 버전으로 업그레이드될 때까지 반복합니다.

4. 애드온 및 컴포넌트 업데이트

네트워크 플러그인, 대시보드, 모니터링 등 애드온도 Kubernetes의 새로운 버전에 맞추어 업그레이드해야 합니다.
kubectl 클라이언트도 새로운 버전으로 업그레이드하여 클라이언트와 서버 버전 간의 호환성을 유지합니다.

5. 클러스터 검증

업그레이드가 완료되면, 클러스터 상태를 확인하고 애플리케이션이 예상대로 동작하는지 검증합니다. kubectl get nodes, kubectl get pods --all-namespaces 등을 사용하여 노드와 Pod 상태를 점검합니다.
로그를 확인하여 오류나 경고 메시지가 있는지 살펴봅니다.

6. 롤백 전략

업그레이드 도중 문제가 발생할 경우를 대비해, 롤백 계획을 마련해야 합니다.
etcd 백업을 사용하여 업그레이드 이전 상태로 복원할 수 있으며, Control Plane 구성 요소와 kubelet 버전을 다운그레이드하여 복구할 수 있습니다.

주요 고려 사항

Kubernetes 릴리스 주기: Kubernetes는 자주 새로운 버전을 릴리스하므로 최신 릴리스 노트를 검토하고, 새로운 기능과 변경 사항을 파악해야 합니다.
버전 호환성: Control Plane과 Worker Node의 버전 차이가 두 단계 이상 나지 않도록 유지해야 합니다(예: Control Plane이 1.24라면, Worker Node는 최소 1.22 이상이어야 함).
무중단 서비스 보장: 노드 업그레이드 시 Pod를 다른 노드로 이동하여 서비스의 무중단성을 유지해야 합니다.

Kubernetes 버전 업데이트는 철저한 계획과 점진적인 업그레이드를 통해 안정적으로 수행할 수 있습니다.

'DevOps' 카테고리의 다른 글

프로파일링 프로그램 (0)	2023.07.06
[Vagrant] windows에서 설치시 SSH auth method: private key 멈춤 (0)	2023.03.12
[Vagrant 에러]VBOX_E_OBJECT_NOT_FOUND (0)	2023.03.09
[Ubuntu] pinpoint 설치 (0)	2022.11.16