Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

[오픈소스컨설팅]쿠버네티스를 활용한 개발환경 구축

2,334 views

Published on

1. Why Cloud?
2. What is Cloud Native?
3. Kubernetes 소개
4. Kubernetes 실습
5. Kubernetes Objects
6. 개발환경 구축하기
컨테이너 기반 CI/CD 환경으로 전환되고 멀티클라우드의 요구사항 수용에 적합한 쿠버네티스에 대한 실습 과정 예제입니다.

Published in: Software

[오픈소스컨설팅]쿠버네티스를 활용한 개발환경 구축

  1. 1. c M ,F E BB M H d p Wu M g ( T - S i T ( - i hR l L m Ox V Wy r c dam oy W M nm - - c- P v W X W W m W Kf e ( bt D AFE dam xs p i oy Wy P v W X W m W o dam y ID D C C ,D ) Wu W C C DD ADIDE ) A D + FH + FH E- /( , / AF8 E AC F6 C E D / 8 ( E -B E A AB - - W g W Wu M Wu M
  2. 2. 스토리지 SAN Network Management AppS 스토리지 SAN / - A 가상화 VM VM 가상화 VM VM 별도의 클러스터 솔루션 필요 Scale-up 방식 Network P - I ( )
  3. 3. M A N A G E M E N T 스토 리지 노드 N E T W O R K 스토 리지 노드 스토 리지 노드 스토 리지 노드 컴퓨 트 노드 컴퓨 트 노드 컴퓨 트 노드 컴퓨 트 노드 네트 워크 노드 네트 워크 노드 네트 워크 노드 네트 워크 노드 컨트 롤러 노드 컨트 롤러 노드 컨트 롤러 노드 컨트 롤러 노드 저가의 하드웨어 로 통일 (X86) 벤더 종속성 제거 /Admin이 직접 관리 모두 API 통신 증설 시,도입 시와 같은 비용으로 무한 확장 밴더 종속성 제거 / Admin이 직접 관리 하드웨어 장애에서 탈피하게 된 서비스중심의 인프라 가상화 비율 4배 이상으로 1/4규모의 서버로 운영 추가 작업 없이 무한가능한 리소스의 확장 시스템 Admin (장애 시 제거) HW L2 만으로 구성
  4. 4. Containers Cloud Native Open Source IaaS PaaS Open Source PaaS Virtualiza- tion 2000 2001 2006 2009 2010 2011 Non- Virtualized Hardware 2013 2015 IaaS https://github.com/cncf/presentations
  5. 5. 특징 • 표준 : Docker는 컨테이너에 대한 산업 표준을 만들었으므로 어디에서나 휴대 할 수 있습니다. • 경량 : 컨테이너는 시스템의 OS 시스템 커널을 공유하므로 응용 프로그램 당 OS가 필요하지 않으므로 서버 효율성을 높이고 서버 및 라이센스 비용을 줄입니다. • 보안 : 컨테이너에서 애플리케이션이 더 안전하고 Docker는 업계에서 가장 강력한 기본 격리 기능을 제공합니다
  6. 6. CRI-O Containerd CRI plugin Docker Engine (native) gVisor CRI plugin CRI-O Kata Containers sponsors CNCF CNCF Docker Inc Google Intel started 2016 2015 Mar 2013 2015 2017 version 1.12 1.2 18.06 runc 1.3 runtime runc (default) containerd managing runc runc runsc kata-runtime kernel shared shared shared partially shared isolated syscall filtering no no no yes no kernel blobs no no no no yes footprint - - - - 30mb start time <10ms <10ms <10ms <10ms <100ms io performance host performance host performance host performance slow host performance network performance host performance host performance host performance slow (see comment) close to host performance Docs https://github.com/kubernetes-sigs/cr i-o/ https://github.com/containerd/cri https://github.com/moby/moby https://github.com/google/gvisor https://github.com/kata-containers/ru ntime Why? 경량 쿠버네 티스 전용. Docker 데몬이 필요하지 않습니다. OpenShift의 기본 값입니다. 아마도 최고의 컨테이너 기 반 런타임입니다. 최신 Docker Engine과 함께 기본적으 로 설치됩니다. Kubernetes는 이제 Co ntainerD를 직접 사용할 수 있습니다. Docker는 동일한 호스트에서 직접 사 용할 수도 있습니다. DockerD 데몬을 실행할 필요가 없습니다. Google GKE 의 베타. 대한 수의 사용자가 테스트하고 반복 한 가장 성숙한 런타임. seccomp, SELi nux 및 AppArmor를 사용하여 강화할 수 있습니다. 가장 빠른 시작 시간. 메 모리 사용량이 가장 적습니다. gcloud appengine에서 고객 간의 격 리 계층으로 사용합니다. stateless we b apps에 적합합니다. 표준 컨테이너 에 두 개의 보안 계층을 추가합니다. 아마도 가장 안전한 옵션입니다. 보안 에 대한 주요 절충은 실제로 그렇게 나 쁘지 않은 것으로 보입니다. 누구나 마 이크로 서비스에서 100ms의 시작 시 간이 증가했음을 알 수 있습니까? 또는 컨테이너 당 추가 30MB? 불안한. Why not? Same security issues as native Docker Engine. Still need to manage a bunch of security policy stuff that nobody e ver does. This is slightly newer as it has been t hrough a few iterations of being inst alled differently. Kubernetes is moving to the CRI plug in architecture. Hardening is too com plex for most to manage. DockerD is quite bloated and running it as root i s bad. Not versioned and shouldn't be used in production yet on Kubernetes. Not good for applications that make lots of syscalls. Not all 400 Linux syscalls i mplemented causing some apps to n ot work (e.g. postgres). The kata-runtime itself is v1 however I'm not sure how this translates to Ku bernetes readiness. Less efficient binp acking due to 30mb memory overhea d. Slower start times.
  7. 7. 전통적인 배포 시대 가상화된 배포 시대 컨테이너 개발 시대
  8. 8. 장점 기민한 애플리케이션 생성과 배포 지속적인 개발, 통합 및 배포 개발과 운영의 관심사 분리. 개발, 테스팅 및 운영 환경에 걸친 일관성 클라우드 및 OS 배포판 간 이식성 애플리케이션 중심 관리. 느슨하게 커플되고, 분산되고, 유연하며, 자유로운 마이크로서비스 자원 격리 자원 사용량
  9. 9. $ docker run -d redis:latest $ docker ps CONTAINER ID IMAGE COMMAND CREATE D STATUS $ docker inspect redis:latest $ docker logs f13 $ docker run -d --name redisHostPort -p 6379:6379 redis:latest // -p local-machine-p ort:internal-container-port $ docker run -d --name test -v "$PWD/data":/data redis // -v local-machine-path:i nternal-container-path $ docker run ubuntu ps PID TTY TIME C
  10. 10. $ ls Dockerfile index.html == FROM nginx:alpine COPY . /usr/share/nginx/html == $ docker build -t webserver-image:v1 . Sending build context to Docker daemon 3.072kB Step 1/2 : FROM nginx:alpine ---> d87c83ec7a66 Step 2/2 : COPY . /usr/share/nginx/html ---> f607fcf3df87 Successfully built f607fcf3df87 Successfully tagged webserver-image:v1 $ docker images REPOSITORY TAG IMAGE ID CREATED SIZE webserver-image v1 f607fcf3df87 7 seconds ago 21.2MB $ docker run -d -p 80:80 webserver-image:v1
  11. 11. $ cat Dockerfile FROM nginx:1.11-alpine COPY index.html /usr/share/nginx/html/index.html EXPOSE 80 CMD ["nginx", "-g", "daemon off;"] $ cat index.html <h1>Hello World</h1> $ docker build -t my-nginx-image:latest . $ docker run -d -p 80:80 my-nginx-image:latest
  12. 12. Containers Cloud Native •Cloud native computing 은 오픈소스 소프트웨어로 아래 의 목적을 이루고자 함. – applications을 microservices형태로 변환 – package를 container 형태로 변환 – 리소스 최적화를 위하여 containers를 orchestration Open Source IaaS PaaS Open Source PaaS Virtualiza- tion 2000 2001 2006 2009 2010 2011 Non- Virtualized Hardware 2013 2015 IaaS https://github.com/cncf/presentations
  13. 13. https://github.com/cncf/presentations 콘테이너화 오케스트레이션 확장서비스 분산 DB/스토리지 콘테이너 관리 CI/CD 네트워크 상태분석 내부통신 소프트웨어 분산
  14. 14. 소개 • 구글의 15여년에 걸친 대규모 상용 워크로드 운영 경험에 의해 만들어짐. • 키잡이(helmsman)이나 파일럿을 뜻하는 그리스어에서 유래 • 구글이 2014년에 쿠버네티스 프로젝트를 오픈소스화 • Container orchestration tool 서비스 디스커버리와 로드 밸런싱 • DNS 이름을 사용하거나 자체 IP 주소를 사용하여 컨테이너를 노출할 수 있음. 컨테이너에 대한 트래픽이 많으면, 쿠버 네티스는 네트워크 트래픽을 로드밸런싱하고 배포하여 배포가 안정적으로 이루어질 수 있다. 스토리지 오케스트레이션 • 로컬 저장소, 공용 클라우드 공급자 등과 같이 원하는 저장소 시스템을 자동으로 탑재 할 수 있다. 자동화된 롤아웃과 롤백 • 배포된 컨테이너의 원하는 상태를 서술할 수 있으며 현재 상태를 원하는 상태로 설정한 속도에 따라 변경할 수 있음. 자동화된 복구(self-healing) • 실패한 컨테이너를 다시 시작하고, 컨테이너를 교체하며, ‘사용자 정의 상태 검사’에 응답하지 않는 컨테이너를 죽이고, 서비스 준비가 끝날 때까지 그러한 과정을 클라이언트에 보여주지 않는다. 시크릿과 구성 관리 • 암호, OAuth 토큰 및 ssh 키와 같은 중요한 정보를 저장하고 관리 할 수 있다. 컨테이너 이미지를 재구성하지 않고 스택 구성에 비밀을 노출하지 않고도 비밀 및 애플리케이션 구성을 배포 및 업데이트 할 수 있다.
  15. 15. $ kubectl run http --image=katacoda/docker-http-server:latest --replicas=1 $ kubectl expose deployment http --external-ip="172.17.0.40" --port=8000 --target-po rt=80 $ curl http://172.17.0.40:8000 $ kubectl scale --replicas=3 deployment http $ curl http://172.17.0.40:8000
  16. 16. apiVersion: apps/v1 # the API endpoint on the API server kind: Deployment # Deployment, Pod, Replicaset, Namespace, Service metadata: name: nginx-deployment #name, labels, namespace labels: app: nginx spec: #the desired state of the Deployment object replicas: 3 selector: matchLabels: app: nginx template: # using the Pods Template defined in spec.template metadata: labels: app: nginx spec: # desired state of the Pod containers: - name: nginx image: nginx:1.15.11 ports: - containerPort: 80
  17. 17. apiVersion: v1 # object definition kind: Pod # object type metadata: # object's name and label name: nginx-pod labels: app: nginx spec: #the block defining the desired state of the Pod object containers: - name: nginx image: nginx:1.15.11 ports: - containerPort: 80 [root@idc02 exercise]# kubectl get pod nginx-pod -o yaml [root@idc02 exercise]# kubectl logs nginx-pod [root@idc02 exercise]# kubectl logs nginx-pod -c nginx
  18. 18. 값 의미 Completed 완료된 잡(Job)과 같이 다 실행되어서 더 작동하고 있을 필요 없이 완료된 상태가 되었다. CrashLoopBack Off 파드 내 컨테이너 중 하나가 예상과는 달리 종료(exit)되었고, restart policy에 따라 재시작된 뒤에도 0이 아닌 에러 코드가 발생했을 것이다. Failed 파드에 있는 모든 컨테이너들이 종료되었고, 적어도 하나 이상의 컨테이너가 실패로 종료되었다. 즉, 해당 컨테이너는 non-zero 상태로 빠져나왔거나(exited) 시스템에 의해서 종료(terminated) 되었다. Pending 파드가 쿠버네티스 시스템에 의해서 승인되었지만, 파드를 위한 하나 또는 하나 이상의 컨테이너 이미지 생성이 아직 완료되지 않았다. 여기에는 스케줄되기 이전까지의 시간 뿐만 아니라 오래 걸 릴 수 있는 네트워크를 통한 이미지 다운로드 시간도 포함된다. Running 파드가 한 노드에 결합되었고, 모든 컨테이너들의 생성이 완료되었다. 적어도 하나의 컨테이너가 동작 중이거나, 시작 또는 재시작 중에 있다. Succeeded 파드에 있는 모든 컨테이너들이 성공으로 종료되었고, 재시작되지 않을 것이다. Unknown 어떤 이유에 의해서 파드의 상태를 얻을 수 없다. 일반적으로 파드 호스트와의 통신 오류에 의해서 발생한다.
  19. 19. hojinuicBookPro:~ hojinkim$ kubectl get namespaces NAME STATUS AGE default Active 14h ==> 관리자와 개발자에 의해 생성 된 객체와 리소스가 포함 kube-node-lease Active 14h ==> 마스터 노드가 문제가 생겼거나(네트워크) 등의 문제를 해결하기 위해서 새로 포함된 것으로, 기존의 NodeStatus에 nodelease가 추가되어 둘다 heartbeat역할을 하며, 경량으로 구현되었고, 더 자주 개신된다. kube-public Active 14h ==> 클러스터에 대한 보안이 필요업는 공개 네임 스페이스 kube-system Active 14h ==> Kubernetes 시스템, 주로 컨트롤 플레인 에이전트에 의해 생성 된 개체를 포함 What about kube-node-lease? •Starting with Kubernetes 1.14, there is a kube-node-lease namespace (or in Kubernetes 1.13 if the NodeLease feature gate is enabled) •That namespace contains one Lease object per node •Node leases are a new way to implement node heartbeats (i.e. node regularly pinging the control plane to say "I'm alive!")
  20. 20. kind: Service apiVersion: v1 metadata: name: frontend-svc spec: selector: app: frontend ports: - protocol: TCP port: 80 targetPort: 5000
  21. 21. livenessProbe: httpGet: path: /healthz port: 8080 httpHeaders: - name: X-Custom-Header value: Awesome initialDelaySeconds: 3 periodSeconds: 3 Liveness HTTP Request 다음 예제에서 kubelet은 HTTP GET 요청을 포트 8080 의 응용 프로그램 / healthz 끝점으로 보냅니다 . 실패하면 Kubelet이 영향을받는 컨테이너를 다시 시작합니다. 그렇지 않으면 응용 프로그램이 살아 있다고 간주합니다. livenessProbe: tcpSocket: port: 8080 initialDelaySeconds: 15 periodSeconds: 20 TCP Liveness Probe TCP Liveness Probe를 사용하면 kubelet 이 애플리케 이션을 실행하는 컨테이너에 대한 TCP 소켓 을 열려고 시도 합니다. 성공하면 응용 프로그램은 정상적인 것으 로 간주되고, 그렇지 않으면 kubelet이 비정상으로 표시 되어 영향을받는 컨테이너를 다시 시작합니다. readinessProbe: exec: command: - cat - /tmp/healthy initialDelaySeconds: 5 periodSeconds: 5 Readiness Probes 경우에 따라 응용 프로그램은 트래픽을 처리하기 전에 특정 조건을 충족해 야합니다. 이러한 조건에는 종속 된 서비스가 준비되었는지 확인하거나 대 형 데이터 집합을로드해야한다는 점을 인정하는 것이 포함됩니다. 이러한 경우 준비 프로브를 사용 하여 특정 조건이 발생할 때까지 기다립니다. 그래 야만 응용 프로그램이 트래픽을 처리 할 수 있습니다.
  22. 22. •사용자는유형,액세스모드및크기에따라PersistentVolume리소스를요청합니다.ReadWriteOnce(단일노드에의한읽기-쓰기),ReadOnlyMan y(많은노드에의한읽기전용)및ReadWriteMany(많은노드에의한읽기-쓰기)의세가지액세스모드가있습니다.적합한PersistentVolume이 발견되면PersistentVolumeClaim에바인드됩니다.
  23. 23. •ToallowtheinboundconnectiontoreachtheclusterServices,IngressconfiguresaLayer7HTTP/HTTPSloadbalancerforServicesandprovidesthefollowi ng: • TLS(TransportLayerSecurity) • Name-basedvirtualhosting • Fanoutrouting • Loadbalancing • Customrules
  24. 24. T. 02-516-0711 E. sales@osci.kr 서울시강남구테헤란로83길32,5층(삼성동,나라키움삼성동A빌딩) THANK YOU

×