일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |
- 스프링 데이타 JPA
- 우분투 시간 변경
- 중첩배열
- 단어 제거
- 중복문자제거
- ubuntu타임존
- 중첩배열평탄화
- @Moditying @Query
- 5.3.8 Modifying Queries
- 코딩 어?
- 프론트엔드 스쿨
- 제로베이스
- 재귀스왑
- 깃 토큰 만료
- 중복단어제거
- 시퀄 문법
- 중복 문자열
- indexOf()
- ...점점점문법
- 문자열 중복
- 중복된 단어
- js 문자열을 문자배열로
- 객체의 밸류값만 찾기
- 문자열순서바꾸기
- sql like연산자
- 객체의키값만 찾기
- 레디스 확인
- 배엘에서 스왑
- lastIndexOf()
- sql 문자열 패턴 검색
- Today
- Total
코딩기록
쿠버네티스 도커 deprecation. 쿠버네티스에서 도커 못쓰나? ---'유튜브 - 코드팩토리Kubernetes 에서 Docker 를 이제 못쓴다고? 팩트체크! ' 정리글 본문
쿠버네티스 도커 deprecation. 쿠버네티스에서 도커 못쓰나? ---'유튜브 - 코드팩토리Kubernetes 에서 Docker 를 이제 못쓴다고? 팩트체크! ' 정리글
뽀짝코딩 2022. 9. 15. 17:46
구글에서 쿠버네티스 만듬 - CNCF(Cloud Native Computing Foundation)
벤더락이 되지 않기위해 구글이 CNCF에 오픈소스로 쿠버네티스를 기부함.
aws, Google Cloud Platform, Azure 등 메이저 클라우드 회사에서 클라우드 소프트웨어나 서비스가 서로 호환되지 않는걸 벤더락(Vendor Lock)이라고 하는데 그런 프로세스를 없애고자 하는게 CNCF의 목표다.
[6:00]- 쿠버네티스 아키텍쳐
1). kubectl 커맨드를 보내면 kube apiServer에서 노드와 통신한다.
2). 워커노드에 있는 각각의 kubelet(쿠블렛)이 노드를 운영하고 컨테이너 런타임(컨테이너 실행 도구)과 소통을 한다.
쿠버네티스가 도커 컨테이너(컨테이너런타임은 도커말고도 종류가 굉장히 많음.)를 기본으로 지원했는데 도커에 벤더락(vendor lock-공급업체 잠금)이 되지 않기 위해 즉, kubelet과 container runtime 사이에 어떤 컨테이너든 사용 가능하게 하기 위해 일반화된 인터페이스가 필요했고 그래서 CRI(Container Runtime Interface)를 만들었다. 도커 의존성이 없어진것!
CRI
쿠버네이스에서 컨터이너 런타임(Container Runtime ) 을 플러그처럼 (Pluggable) 교체 가능한 방법을 제공하기 위해 CRI (컨테이너 런타임 인터페이스: Container Runtime interface) 라고 부르는 API 를 만들었다.
Kubelet은 CRI 인터페이스를 사용하여 컨테이너를 조작할 수 있다. CRI 표준을 따르는 어떠한 컨테이너 런타임이라도 Kubernetes 와 통합하여 사용할 수 있다.
OCI
OCI 표준에 대한 구현체가 컨테이너 런타임이다. 초기에는 도커만 있었으나 그 이후로 CRI-O 와 RKT, Containerd 가 등장 했다.
컨테이너 런타임을 제어하는 오케스트레이션의 표준은 CNCF( Cloud Native Computing Foundation) 이며 구현체는 “kubernetes”이다.
'도커 의존성이 없어졌다' 무슨말인가?
도커는 CRI를 지원하지 않아 쿠버네티스에서 도커를 사용하려면 Dockershim을 거쳐 통신했는데 이 과정을 생략하고(도커심 지원 중단) Docker 외에 cri-o, containerd 등 다양한 종류의 컨테이너를 사용할 수 있고 도커업뎃에 따라 쿠버네티스를 업뎃 해야하는 상황을 피할수 있다.
그럼 컨테이너 런타임에서 도커를 사용하지 못하면 도커파일도 사용하지 못하나?
도커를 쓸 수 있다. 정확히 말하면 도커 이미지를 쓰는데 도커에서 만드는 컨테이너는 OCI(Open Container Initiative)라는 기준을 따르고 있다.
기존처럼 로컬 컴퓨터에서 도커파일(Dockerfile)을 사용해 컨테이너를 생성하고 이미지를 빌드, 도커허브에 푸쉬한 후 쿠버네티스에서 풀해 컨테이너를 만든다. 쿠버네티스(k8s)에서 이미지를 받을 때 도커런타임이 아니어도 도커파일로 컨테이너를 실행할 수 있다. CRI-O는 OCI를 준수한 컨테이너를 빌드하고 배포 할 수 있다.
✅정리하자면 쿠버네티스 클러스터 내부에는 컨테이너 이미지를 가져오고 실행하는 역할을 담당하는 컨테이너 런타임이 있고 앞으로 쿠버네티스 1.24 버전 이상은 컨테이너를 돌릴때 도커가 아닌 CRI를 준수한 컨테이너런타임(cri-o, containerd 등)을 써야한다. 단, 도커에서 생성한 이미지는 OCI를 준수한 이미지이기 때문에 계속 쓸수 있다.
쿠버네티스 클러스터 어드민이 아닌 매니지 서비스를 쓰는 사람들은 지금처럼 Dockerfile를 쓰면 되고 AWS EKS Admin, 로컬에서 이터널로 쿠버네티스를 쓰는 경우면 따로 cri-o, containerd(컨테이너디) 등 다른 컨테이너런타임을 이용해야한다. 나를 포함한 대부분의 사람들은 AKS(Azure), EKS(AWS), GKE(GCP)등 클라우드의 회사의 쿠버네티스 클러스터 Managed 서비스를 사용하기에 지금처럼 도커파일을 이용해 이미지를 빌드, 푸쉬해도 된다. 다른 블로그 글은 조금 설명이 부족했는데 코드팩토리 유투브가 명료하게 설명을 해서 정리 해봤다.
도커에서 생성한 이미지 사용가능! Dockerfile계속 쓰자! (OCI를 준수한 이미지라서)
컨테이너런타임으로 도커 사용 불가능! (cri-o, containerd 등 다른 컨테이너 런타임 써야함)
내 컨테이너런타임 확인
kubectl get nodes -o wide
맨 끝에 docker://20.10.17
도커 컨테이너런타임을 쓴다는 뜻이다.
이제 도커로 설정된 컨테이너런타임을 다른걸로 변경해야한다.
참고
*유튜브 - 코드팩토리
Kubernetes 에서 Docker 를 이제 못쓴다고? 팩트체크!
https://www.youtube.com/watch?v=XXH0Ocm_9Ro
*CRI-O소개
http://www.opennaru.com/kubernetes/cri-o/
*컨테이너, 쿠버네티스
https://www.cloocus.com/insight-kubernetes_1/
*도커와 컨테이너 생태계의 변화과정
https://blog.siner.io/2021/10/23/container-ecosystem/
* 쿠버네티스 컨테이너 런타임 마이그레이션 docker -> containerd