0117 MLOPS 수입 필기

01 과제 리뷰

1. 서버컴퓨터와 일반컴퓨터의 차이

• 사용하는 사람이 어떤 목적으로 사용하는가!

• 서버용 운영체계인가?일반 운영체계인가?
  - 윈도우, 맥, 우분투가 일반사용자용과 서버용과 다르다.

  • 근데! 서버용이라도 일반사용자용 운영체계로 만들어도 하등 상관없다

• 특수목적용 하드웨어를 사용하는지? = 안정성 우선!!, 느려도 동시에 많은 일을 안전하게 할수 있는...

  특히 서버용 운영체계인것이 쟁점!
  서버용 운영체계는 기능이 더 적다!! =
  기능을 빼도 안정성에 몰빵한 것

2. S3DOWNLOADER : 별도의 도커파일 없이 도커컴포즈에 이미지를 AWSCLI로 하면 된다

3. AI-API

   • 볼륨 중에 PIP 폴더를 마운트하면 컨테이너 죽였다가 다시 살려도 다시 깔필요없게 만들 수 있다.

4. 깃허브액션

• 깃시크릿에 호스트IP, 유저네임, 키, 포트 설정, sudo git patch, sugo git checkout, sudo pip...이런걸 다해야함

• 마지막에 성공하면 성공했다고 푸시알람 넣기

5. 포트이슈: netstat 내컴퓨터에 어떤 포트가 씌여지고 있는지 알려줘! 라는 명령어 사용해보기

6. vscode에서 wsl 환경으로 사용하는 것을 권장

7. 도커파일에서 RUN명령어는 도커이미지에 포함되는 것.
   CMD는 컨테이너가 될때 이걸 실행해줘!
   그러므로 각종 뭐 까는건 RUN에다 해야함!

8.은근히 타임존이 이슈인 경우가 많다!!
그래서 타임존 맞추는것을 필수로 하는것 추천!!!

02 containerization

소프트웨어를 일종의 완제품으로 만드는 것!! 패키징!!

과거.. 컴퓨터로 새로운 프로그램 뭐하나 하려면 이것저것 깔아야했고... 그러다보면 컴퓨터가 이상해지고, 되던게 안되곤 했다.
containerization 기술 덕분에 더이상 이전 다른 프로그램들과 충동하지 않는다

레지스트리 = 깃헙이 코드를 올려놓는 것이라면 레지스티리는 도커 이미지를 올리는 곳! 가장 대표적인 것이 docker hub이며 aws 같은 메이저 클라우드 사업자도 컨테이너 레지스트리지로 이미지를 불러올 수 있는 저장소를 제공하고 있다.

추천)
도커허브, 깃허브의 다른 사람이 만들어놓은 것들을 적극 사용해보자!
https://hub.docker.com/

03 Kubernetes

쿠버네티스란?

- 도커 = 컨테이너 기술 특화
- 도커컴포즈 = 두개 이상의 컨테이너를 티키타카하게 만들때 사용 = 두 컨테이너를 하나의 네트워크로 묶어줌
- 쿠버네티스 = 스케일아웃을 쉽게할 수 있도록헤줌

스케일링: 스케일업과 스케일아웃

스케일업(Scale-up)과 스케일아웃(Scale-out)은 시스템 성능과 용량을 증가시키기 위한 두 가지 다른 접근 방식입니다.

스케일업 (Scale-up)

• 정의: 기존 시스템의 하드웨어 성능을 업그레이드하여 성능을 향상시키는 방법입니다.
• 방법: CPU, 메모리, 디스크 등의 자원을 추가하거나 교체하여 성능을 개선합니다.
• 장점: 단일 시스템에서 관리가 용이하고, 기존 소프트웨어와의 호환성이 유지되며, 복잡도가 낮습니다.
• 단점: 하드웨어 업그레이드 한계로 인해 확장성에 제한이 있으며, 비용이 많이 들 수 있습니다.

스케일아웃 (Scale-out)

• 정의: 여러 대의 시스템을 추가로 배치하여 성능과 용량을 분산시키는 방법입니다.
• 방법: 다수의 서버 또는 노드를 네트워크로 연결하여 작업을 분산 처리합니다.
• 장점: 무한에 가까운 확장성을 제공하며, 고가용성(High Availability)과 장애 복구(Fault Tolerance)에 유리합니다.
• 단점: 시스템 간의 네트워크 통신과 데이터 일관성 유지가 복잡할 수 있으며, 관리와 설정이 더 어려울 수 있습니다.

스케일아웃(Scale-out)은 흔히 "분산 시스템"이라고도 불립니다. 이는 여러 대의 서버나 노드를 통해 작업을 분산 처리하는 방식이기 때문이에요.
서비스에 유저가 많아지는데 스케일아웃이 안되면 자칫 프로그램을 처음부터 새로 만들어야할 수도 있다!

클러스터링

클러스터링 (Clustering)
뭉탱이로 묶어서 하나인것처럼 운영한다

• 정의: 여러 대의 컴퓨터(노드)를 하나의 시스템처럼 동작하도록 결합하는 기술입니다.
• 목적: 성능 향상, 고가용성, 부하 분산 등을 목적으로 사용됩니다.
• 방법: 노드 간의 네트워크를 통해 상호작용하며, 작업을 분산 처리하고 데이터를 공유합니다.
• 대표적인 예시:
  - Hadoop: 빅데이터 처리를 위한 분산 클러스터링 시스템입니다.
  - Kubernetes: 컨테이너화된 애플리케이션을 관리하는 클러스터링 도구입니다.
  - Apache Kafka: 분산 스트리밍 플랫폼으로, 실시간 데이터 스트림을 처리하는 데 사용됩니다.

쿠버네티스를 사용하는 이유

• 도커컨테이너 단독역할 : 컨테이너 생성, 시크릿 및 환경변수 관리

• 도커컴포즈의 역할과 장점 : 선언적인 방식?, 네트워크와 스토리지 공유 편리함, 서비스간의 의존성 관리 (depends on)

• 쿠버네티스의 역할과 장점

  • 서비스디스커버리
    도커 컴포즈는 컨테이너 간의 네트워크를 설정할 수 있지만, 기본적인 서비스 디스커버리 기능은 제한적입니다.
    쿠버네티스는 서비스라는 개념을 사용하여 클러스터 내의 모든 포드(컨테이너 그룹)가 다른 포드를 쉽게 찾고 통신할 수 있도록 합니다. DNS를 통해 서비스 디스커버리가 가능하며, 클러스터 내에서 동적으로 변하는 IP 주소를 처리할 수 있습니다.
    

  • 로드밸런싱
    도커 컴포즈도 기본적인 로드밸런싱 기능을 제공하지만, 복잡한 트래픽 분산 요구사항을 처리하기 어렵습니다.
    쿠버네티스는 각 서비스에 대해 로드밸런서를 자동으로 생성하여 트래픽을 여러 포드에 고르게 분산시킵니다. 내부 로드밸런싱뿐만 아니라 클라우드 기반 외부 로드밸런싱도 지원합니다.
    

  • 셀프힐링
    도커 컴포즈는 컨테이너가 비정상 종료되면 수동으로 다시 시작해야 합니다.
    반면 쿠버네티스는 자동 복구 기능을 제공합니다. 포드가 실패하거나 응답하지 않을 때 자동으로 다시 시작하며, 필요에 따라 재배포합니다. 헬스 체크를 통해 비정상적인 포드를 감지하고 대체할 수 있습니다.
    

  • 다중노드리소스관리
    도커 컴포즈는 단일 호스트에서의 리소스 관리가 주로 이루어집니다.
    쿠버네티스는 클러스터 전체에서 여러 노드에 걸쳐 리소스를 효율적으로 관리합니다. 스케줄러를 통해 작업을 여러 노드에 분산시키고, 각 노드의 CPU, 메모리, 디스크 등의 자원을 최적화합니다. 또한, 필요에 따라 자동으로 스케일링하여 추가 리소스를 활용할 수 있습니다.

  • 탄탄한 오케스트레이션 생태계
    쿠버네티스는 수많은 오픈 소스 도구와의 통합 및 확장이 용이합니다. 예를 들어, 모니터링을 위한 Prometheus, 로그 관리를 위한 ELK 스택, 서비스 메시(Service Mesh)를 위한 Istio 등을 쉽게 통합할 수 있습니다.
    또한 대규모 오픈 소스 커뮤니티가 지원하며, 다양한 클라우드 제공업체들이 쿠버네티스를 네이티브로 지원합니다. 이는 쿠버네티스를 중심으로 다양한 도구와 서비스가 개발되고 있음을 의미합니다.

필수 키워드

<기본단위>

• 1. 파드 : 쿠버네티스에서 가장 작은 배포 단위, 가장 작은 논리적 단위로 하나의 '도커 컴포즈'를 뜻합니다. 즉, 하나 이상의 컨테이너를 포함하며 이들은 동일한 네트워크 네임스페이스를 공유하고, 같은 노드에서 실행됩니다.

• 2. 노드 : 쿠버네티스 클러스터의 구성 요소로, 애플리케이션을 실행하는 머신(물리적이거나 가상)입니다. 예를 들어 서버실에 물리적 서버 컴퓨터 2개를 돌아가고있다면, 이는 노드가 2개라는 뜻입니다. 노드에 파드들이 호스팅되고 쿠버네티스 전체 작업 부하를 분산받아 처리하게됩니다.

<코드구조>

• 1. apiVersion:
  이 객체가 속한 쿠버네티스api의 버전을 지정합니다. 쿠버네티스는 객체별로 버전을 지정할 수 있습니다. 시간이 지남에 따라 권장되는 버전이 달라지며, 쿠버네티스 버전이 크게 업데이트가 되면, 코드를 아예 수정하거나 구-코드를 상요하기 위해 이전버전으로 지정해줘야합니다. 아래 예시에 사용된 apps/v1은 1.9버전 이후로 권장되는 버전으로 가장 최신기능과 향상된 안정성 제공합니다. extensions/v1beta1는 이전 쿠버네티스 버전에서 사용된 구버전입니다.

• 2. kind:
  생성하려는 쿠버네티스의 종류/유형을 지정/명시합니다. 대표적인 객체로 Deployment, Service, Replicaset, Ingrass가 있습니다.

• 3. metadata:
  객체에 대한 메타데이터, 즉 객체 이름, 네임스페이스 레이블, 아노테이션 등이 포함됩니다.

  • label: 객체에 붙이는 키-값 쌍으로 이뤄진 꼬리표입니다. (종류) : (이름)으로 구성되며, 하나의 객체에 여러 라벨이 붙을 수 있습니다. 아래와 같은 예시의 경우, 총 3개의 라벨이 붙었으며, 각각 라벨에 특정 명령이 들어올 경우 적용을 받습니다. 만약 클러스트 내 모든 tier: frontend에게 명령을 내릴 경우 이 객체는 그 명령에 해당되는 것이지요.

    	(하나의 객체에 여러 라벨 예시) 
     
     metadata:
    labels:
     app: my-app
     env: production
     tier: frontend
    	```  
    ,
    

  • annotation: 아노테이션. 쿠버네티스 객체에 추가되는 비구조적 데이터를 저장하는 키-값 쌍입니다. 즉 부가적인 정보들에 대한 기록/메모를 남기는데 사용됩니다.

• 4. spec:
  객체를 원하는 상태로 정의합니다. 이 부분은 위의 kind에 명시된 객체 유형에 따라 달라지며 객체가 어떤 모양으로 만들어지고 어떻게 동작해야하는지에 대한 세부사항을 포함합니다. 대표적인 구성요소로, 파드의 템플릿(이미지 등), 레플리카 수, 서비스 포트, 셀렉터 등의 설정이 포함됩니다.
  - selector: 이 객체가 관리할 파드를 '선택'하여 관리하는데 사용됩니다. 아래의 예시에서 디플로이먼트는 3개의 레플리카를 생성하고, 이 레플리카들이 모두 app: example-app이라는 레이블을 가지고도록 보장합니다. 이로써 이 디플로이먼트는 오직 app: example-app의 레이블을 가진 파드들만 관리하는 역할을 하게됩니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-deployment
  labels:
    app: example-app
  annotations:
    description: "This is an example deployment."
spec:
  replicas: 3
  selector:
    matchLabels:
      app: example-app
  template:
    metadata:
      labels:
        app: example-app
    spec:
      containers:
      - name: example-container
        image: nginx:latest
        ports:
        - containerPort: 80

<객체종류> = kind

• 1. Deployment : 쿠버네티스에서 애플리케이션의 이상적인 상태를 정의하고, 그 상태로 배포 및 유지, 관리하는 데 사용되는 객체입니다. 디플로이먼트는 다음과 같은 정보를 포함하는 템플릿을 통해 원하는 애플리케이션 상태를 정의합니다:

  • 파드 템플릿: 파드에 포함될 컨테이너 이미지, 환경 변수, 볼륨 등을 지정합니다.
  • 레플리카 수: 동시에 실행되어야 하는 파드의 수를 지정합니다.
  • 업데이트 전략: 롤링 업데이트와 같은 방식을 통해 애플리케이션을 점진적으로 업데이트하는 방법을 정의합니다.
    - 롤백 전략: 문제가 발생했을 때 이전 상태로 되돌리는 방법을 정의합니다.

  즉, 디플로이먼트는 "우리 서비스는 이렇게 생겨야 한다"는 것을 정의하고 이 상태를 유지하기 위해 필요한 모든 작업을 자동으로 처리하는 역할입니다. 특히 애플리케이션을 배포하는 과정에서 디플로이먼트는 새로운 파드를 생성하고, 이전 파드를 점진적으로 대체합니다. 이는 무중단 배포를 가능하게 합니다. 또한 디플로이먼트를 통해 파드의 수를 동적으로 조정하여 트래픽 증가에 대응할 수 있는 스케일링 역할도 합니다.

• 2. Replicaset
  지정된 수의 파드 복제본이 항상 실행되도록 보장하는 컨트롤러/객체입니다. Deployment와 ReplicaSet 둘 다 파드를 복제하여 여러 개의 파드가 실행되도록 합니다. 하지만 레플리카 세트는 단순히 파드를 복제하고 파드수를 유지하는 역할만 합니다. 디플로이먼트는 배포 전략, 업데이트, 롤벱, 헬스체크, 변수설정 등 좀더 다양한 고급기능을 제공하죠. 그리고 Replicaset는 그 자체로도 있을 수 있지만, 주로 Deployment에 의해 생성되고 관리됩니다. 즉, Depoloyment가 Replicaset의 상위객체입니다.

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: my-replicaset
  labels:
    app: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-container
        image: nginx:latest
        ports:
        - containerPort: 80

• 3. Service:
  서비스는 클러스터 내에서 실행 중인 파드를 네트워크 서비스로 노출하는 역할을 합니다. 이를 통해 파드 간 통신을 쉽게 하고, 로드 밸런싱을 통해 트래픽을 분산시킬 수 있습니다. 즉, 클러스트 내부의 네트워크를 관리하는 역할을 합니다. 서비스는 대표적으로 4개의 종류가 있습니다.
  • 클러스터IP (ClusterIP):기본 서비스 유형으로, 클러스터 내에서만 접근 가능한 내부 IP 주소를 할당합니다. 같은 클러스터 내 다른 파드가 이 서비스에 접근할 때 사용합니다.
  • 노드포트 (NodePort): 각 노드에서 고정된 포트를 열어 외부에서 접근할 수 있게 합니다.외부 네트워크에서 쿠버네티스 클러스터 내부의 파드로 접근할 때 사용합니다.
  • 로드밸런서 (LoadBalancer): 클라우드 제공업체의 로드 밸런서를 사용하여 외부 트래픽을 분산시킵니다. 클라우드 환경에서 애플리케이션을 외부에 노출할 때 사용합니다.
  • ExternalName: 외부 DNS 이름을 사용하여 서비스에 접근할 수 있게 합니다. 외부 서비스(예: 데이터베이스)를 클러스터 내부에서 접근할 때 사용합니다.

apiVersion: v1
kind: Service
metadata:
  name: my-service
  labels:
    app: my-app
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: ClusterIP

• 4. Ingrass:
  인그레스는 외부 HTTP 및 HTTPS 트래픽을 클러스터 내의 서비스로 라우팅하는 규칙을 정의합니다. 이를 통해 도메인 기반의 라우팅 규칙을 설정하고, 외부 트래픽을 관리할 수 있습니다. 즉, 외부 네트워크에서 오는 명령을 적절한/알맞는 포드가 받아가도록 분배해주는 역할입니다 (= 라우팅) 인그레스의 기능은 다음과 같습니다:
  • 라우팅: 도메인 이름과 경로를 기반으로 요청을 적절한 서비스로 라우팅합니다. 예시) example.com/api 경로의 요청을 특정 서비스로 라우팅.
  • SSL/TLS: SSL/TLS 인증서를 사용하여 보안 통신을 설정할 수 있습니다. 예시) HTTPS 트래픽을 처리하여 클라이언트와의 통신을 암호화.
  • 로드밸런싱: 인그레스 컨트롤러를 통해 여러 서비스 간에 트래픽을 분산시킵니다. 예시) 여러 파드로 트래픽을 분산시켜 부하를 줄임.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
    - host: example.com
      http:
        paths:
          - path: /myapp
            pathType: Prefix
            backend:
              service:
                name: my-service
                port:
                  number: 80

(비교) 인그레스와 서비스의 차이:

• 서비스는 클러스터 내부에서 파드 간의 통신을 관리하고, 내부 또는 외부 트래픽을 서비스로 라우팅합니다.
• 인그레스는 주로 외부 트래픽을 관리하며, 도메인 기반의 라우팅 규칙을 설정하여 다양한 경로의 트래픽을 적절한 서비스로 분배합니다.

사용방법 (정리중)

도커데스크탑 > 설정 > 쿠버네티스에서 바로 사용가능
쿠버네티스로 실행하면 내가 만든 파드말고도 정말 많은 시스템을 위한 컨테이너=파드들이 띄워져서 돌아간다

쿠버네티스를 사용하면 이제 더이상 도커, 도커컴포즈를 사용하지 않고
이미지만 가지고 올린다

만들기
한파일에 여러 파드들을 한번에 정의한다
---로 구분짓기

1. 메니페스트 파일 만들기
   파드
   메타데이터 이름=파드의 id역할,
   - 이름이 겹치지 않는 것이 중요하다 ; 아니면 namespce 활용
   레이블 : 딱지붙이기, 대상에 딱지이름을 붙인다
   스펙 : 컨에티너스에 이름, 사용할 이미지, 포트... 여러 컨테이너를 (서로다른 포트사용해서 열수 있다)

   서비스
   이름주의
   셀렉터 : 위의 파드쪽에 적은 어떤 app을 연결대상으로 삼을 건지
   포트
   서비스는 노드 > 서비스 > 파드 순으로 3단계를 거쳐 통신한다
   포트 : 나 서비스의 포트는 80으로 받을래
   타겟포트 : 최종 도착지인 파드는 80에 있으니까 그리로 보내줄게

   레플리카셋 : 별도의 파일을 만든다... 복붙해주는 역할

2. kubectl 명령하면 실행됨!