ECR
ECR - Private Repository 생성
Elastic Container Registry
AWS 에서 활용할 수 있는 이미지 저장소로 Public , Private 모두 다 지원 한다
- EKS 에 들어가서 ECR 에 들어가자
- 프라이빗 지정 및 리포지토리 이름 지정
- 생성되면 URI 를 복사하자
ECR - Image Push
aws ecr get-login-password --region ap-northeast-2 | docker login --username AWS --password-stdin 225437145491.dkr.ecr.ap-northeast-2.amazonaws.com/jaehong/myapp
- ECR 로그인을 하자
docker pull httpd
- docker hub 로 부터 Image 를 받아오자
docker tag httpd:latest 225437145491.dkr.ecr.ap-northeast-2.amazonaws.com/jaehong/myapp:1.0
- 받아온 Image 의 tag 를 변경해주자
docker push 225437145491.dkr.ecr.ap-northeast-2.amazonaws.com/jaehong/myapp:1.0
- Image 를 Push 해주자
- 리포지토리에 잘 Push 되었다
CNCF
출처 : http://www.opennaru.com/kubernetes/cloud-native-computing-foundation-cncf/
CNCF (cloud native computing foundation)
- 클라우드 환경에서 애플리케이션을 배포하고 작은 서비스를 패키징하는 기술로 리눅스 컨테이너가 각광받고 있습니다. 하지만 컨테이너 세계는 컨테이너 엔진에서 부터 레지스트리, 오케스트레이션 ,보안,네트워크,스토리지, 애플리케이션 관리까지 다양한 기술이 뒤섞여 혼란스러운 상황입니다. 기업들은 컨테이너 환경에서 마이크로서비스 아키텍처로 애플리케이션 개발하려고 해도 무엇을 어떻게 설계하고 어떤 기술을 결합하여 환경을 구축해야하는지 혼돈스러울 뿐입니다.
- 2015 년 7 월에 발표된 2016 년 1 월에 정식 출범 한 Cloud Native Computing Foundation (이하 CNCF)는 혼돈스러운 컨테이너와 관련된 다양한 기술적인 문제들을 오픈소스로 해결하는 하는 것을 목표로하고 있습니다
Cloud Native Computing Foundation 는 대표적으로 Kubernetes 와 Prometheus 와 같은 클라우드 네이티브 오픈소스 기술들을 추진하고 관리하는 단체입니다
Cloud Native Computing Foundation는 2015 년에 Linux Foundation 산하에 설립되어 첫 번째 프로젝트로 Kubernetes 를 Google에서 기증하였습니다
K8S 연결 Interface
K8S 에 연결하여 사용하기 위한 인터페이스
- Container Runtime Interface ( CRI ) : Kubelet 을 통해 kubelet 과 연결하기 위한 인터페이스
- Container Network Interface ( CNI ) : Kubenet 이 기본적으로 K8S 에 포함되어 있으나, K8S 의 다양한 Network 기능을 제공하기에는 무리가 있어 3rd Party 에서 참여를 시작하게 되었고, CNI 에 맞는 인터페이스들이 배포되었다 -> Calico , Weavenet , flannel 등이 있다
- Container Storage Interface ( CSI ) : CSI 를 통해 NFS 와의 연결을 테스트 할 수있다
EBS 를 이용한 PV & PVC
K8S & AWS Volume 연결 방법
AWS 에서는 BlockStorage 인 EBS 와의 연결을 통해 Pod 에게 Volume 을 제공할 수 있다
정적인 방법
- 관리자는 EBS 에서 필요한 만큼의 Volume 을 미리 생성한다
- 개발자는 관리자에게 문의하여 PV 를 확인한다
- 개발자는 관리자에게 확인한 ID 정보를 PVC 내에 포함시키고, 최종적으로 해당 PVC 를 POD 에 연결시킨다
동적인 방법
- Storage Class , Provisioner 를 이용
AWS PV & PVC - 정적인 방법
- ec2 에서 볼륨에 들어가서 생성해주자
- 볼륨 ID 를 확인하자
apiVersion: v1
kind: PersistentVolume
metadata:
name: ebs-pv
spec:
capacity:
storage: 1Gi
accessModes:
- ReadWriteOnce
awsElasticBlockStore:
fsType: ext4
volumeID: vol-02497f9f460de48f6
- pv.yaml 작성. aws 에서 생성한 볼륨을 이용해 PV 를 배포하였다
pvc 를 작성하면 pv 와 Bound 될 것이다
AWS PV & PVC - 동적인 방법
# touch ebsscpvc.yml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: fastdisk
provisioner: kubernetes.io/aws-ebs
parameters:
type: gp2
fsType: ext4
zones: ap-northeast-2a
---
apiVersion : v1
kind: PersistentVolumeClaim
metadata:
name: pvc-fast-sc
spec:
storageClassName: fastdisk
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
- StorageClass 를 통해 동적 프로비저너를 지정하고, PVC 로 해당 StorageClass 를 지정하면 된다
root@master:~# kubectl get pv,pvc
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
persistentvolume/ebs-pv 1Gi RWO Retain Available 33m
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
persistentvolumeclaim/pvc-fast-sc Pending fastdisk 5s
root@master:~# kubectl get pv,pvc
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
persistentvolume/ebs-pv 1Gi RWO Retain Available 33m
persistentvolume/pvc-ad521941-8bce-4b9f-99b3-467e2ac043dc 1Gi RWO Delete Bound default/pvc-fast-sc fastdisk 5s
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
persistentvolumeclaim/pvc-fast-sc Bound pvc-ad521941-8bce-4b9f-99b3-467e2ac043dc 1Gi RWO fastdisk 11s
- 배포하면 Bound 된 것을 확인할 수 있다
멋진 엔지니어가 될 때까지