Docker kubernetes fundamental(pod_service)_190307
13 likes•1,564 views
The document discusses several challenges with traditional IT infrastructure including lack of agility due to long development times, aging infrastructure with outdated hardware and software, and high costs associated with monolithic architectures. It then introduces containers and microservices as ways to address these challenges by enabling faster development and deployment, using modern infrastructure, and developing applications in a more modular way. Key concepts covered include containerizing existing applications, rearchitecting apps for scale with containers, and moving to a container platform and microservices.
![$ docker build -t helloworld:0.1 .
$ docker run -d -p 80:80 nginx
$ curl ifconfig.co
$ curl <IP-Address>
$ docker build -t dazdaz/gallery3 .
Creating Containers - Dockerfile
Example of a Dockerfile
FROM nginx:alpine
LABEL author=“Inhye Park"
COPY ./dist /usr/share/nginx/html
EXPOSE 80 443
ENTRYPOINT ["nginx", "-g", "daemon off"]
Create the Dockerfile and run :
Creating Containers - Dockerfile](https://image.slidesharecdn.com/dockerkubernetesfundamentalpodservice190307-190314054216/85/Docker-kubernetes-fundamental-pod_service-_190307-19-320.jpg)
Docker kubernetes fundamental(pod_service)_190307
- 2. Lack of agility • 새로운 서비스에 대한 개발 시간 • 운영시간이 Budget과 연결 • Innovation is happening outside IT inside business areas Aging infrastructure • 데이터 센터의 Hardware, Operating systems, Business applications 의 노후화에 따른 영향 • 운영 비용, 효율성 및 안정성 • 자본 지출, 요구 사항 • 보안감사 및 규정 준수 High Cost • Longer release cycles, monolithic and highly coupled architecture • Highly IT dependent • Low application performance and time-to- market compromise business agility
- 3. From traditional app to modern app APP Containerize Applications Re-architect apps for scale with containers. Containers Container Platform Existing Application On-Premises Infrastructure Platform PaaS Application Platform Modern Microservices Add new services or start peeling off services from monolithic code. Serverless Modern Infrastructure rehost as VMs or refresh to modern container platform. IaaS Infrastructure Platform “lift & shift”
- 5. Sock-Shop
- 9. • VM보다 가벼운 형식으로 애플리케이션을 pack, ship, run • 컨테이너는 프로세스 격리를 기반으로 하는 애플리케이션 전달 메커니즘 • Linux Kernel 기술 사용 : cgroups, namespaces + overlay fs + tooling • 컨테이너 이미지를 사용하면 응용 프로그램 코드, 런타임 및 모든 Dependency들을 Pre- Defined Format으로 제한 가능 • Container 는 새로운 것이 아닙니다 - 리눅스 LXC, Solaris Zones, BSD Jails 처럼 기존에 있던 개념!!! ✓ Docker 는 기존의 있는 것을 사용하여 빌드하고 관리할 오픈소스 소프트웨어를 만들었음
- 11. Virtual Machines Each VM has independent, full OS Full isolation Separate app frameworks Support features such as live migration Slow to boot Containers Shared Host OS Near instant start-up Processes in containers are isolated Dependent app services and libraries are tied to container (layers) Every container has an isolated view and gets it ’s own file system, it ’s own PID0 and eth0 network interface Virtual Machine Container Containers vs. VM’s
- 12. The container advantage Fast iteration Agile delivery Immutability Cost savings Elastic bursting Efficient deployment For ITFor developers
- 13. 2013년 3월 PyCon Conference – Docker (Solomon Hykes) 컨테이너 기반의 오픈소스 가상화 플랫폼 Docker - Build, Ship, and Run Any App, Anywhere
- 18. $ docker search ubuntu $ docker pull ubuntu:latest $ docker images $ docker run – i – t --name hello ubuntu /bin/bash $ docker ps – a $ docker stop ubuntu $ docker # remove container $ docker # remove image
- 19. $ docker build -t helloworld:0.1 . $ docker run -d -p 80:80 nginx $ curl ifconfig.co $ curl <IP-Address> $ docker build -t dazdaz/gallery3 . Creating Containers - Dockerfile Example of a Dockerfile FROM nginx:alpine LABEL author=“Inhye Park" COPY ./dist /usr/share/nginx/html EXPOSE 80 443 ENTRYPOINT ["nginx", "-g", "daemon off"] Create the Dockerfile and run : Creating Containers - Dockerfile
- 20. Docker Volumes • When the container dies, the data is destroyed, containers are ephemeral • Docker Volume 은 Data 를 Persistent하게 유지하기 위해 Docker Container에서 사용 됨 $ docker create volume myvol1 $ docker volume ls $ docker volume inspect myvol1 $ docker run -d --name devtest --mount source=myvol1,target=/app nginx:latest
- 21. Docker Compose • Compose 는 multi-container docker를 구동시키고 Define 하기 위한 Tool • Compose 는 Docker compose 파일을 사용하여 애플리케이션 서비스를 구동시킬 수 있음 $ cd project-directory $ docker-compose up -d $ docker-compose ps $ docker-compose logs wordpress $ az vm open-port -g u1804-rg -n u1804 --port 8000 --priority 1001 $ curl ifconfig.co $ docker-compose down --volumes
- 27. Container Management at Scale Load Balancing: evenly distribute traffic Lifecycle and Health: keep containers running despite failure Cluster Management: deploy and manage cluster resources Scheduling: where containers run Naming and Discovery: where are my containers Logging and Monitoring: track what’s happening in containers and cluster Image repository: centralized, secure Docker container images Storage volumes: persistent data for containers Scaling: make sets of containers elastic in number Continuous Delivery: CI/CD pipeline and workflow At the end of the day we need something to help us with all the orchestration.. An orchestrator!
- 31. What is Kubernetes(k8s)? • Kubernetes is "an open-source software for automating deployment, scaling, and management of containerized applications“. • Kubernetes, in Greek κυβερνήτης, means the Helmsman, or pilot of the ship. • Keeping with the maritime theme of Docker containers, Kubernetes is the pilot of a ship of containers. History • Google open sourced Borg. Google still actively involved • Kubernetes v1.0 was released on July 21, 2015 by Joe Beda, Brendan Burns and Craig McLuckie • Most discussed repo in Github last year. Over 1,700 authors; releases every three month • To learn more about the ideas behind Kubernetes: read the Large-scale cluster management at Google with Borg paper
- 32. Kubernetes Features • Self-Healing 자동으로 문제가 발생한 노드의 컨테이너를 대체(룰/정책에 따른 헬스 체크) • Horizontal Scaling CPU 와 메모리와 같은 리소스 사용에 따라 자동으로 어플리케이션을 확장 경우에 따라서, 사용자 정의 측정 값을 기준으로 한 동적인 확장 가능 • Service Discovery and Load Balancing Container에 고유한 IP를 부여 여러 개의 Container를 묶어 단일 Service로 부여하는 경우 단일 DNS Name으로 접근하도록 로드 밸런스를 제공 • Automatic bin packing 가용성에 대한 희생 없이, 리소스 사용과 제약 사항을 기준으로 자동으로 컨테이너를 스케줄링
- 33. Kubernetes Features • Automated rollouts and rollbacks 다운타임없이 애플리케이션의 새로운 버전 및 설정에 대한 롤아웃/롤백 가능 • Storage orchestration 소프트웨어 정의 저장장치를 기반으로 로컬, 외부 및 저장소 솔루션 등을 동일한 방법으로 컨테이너에 마운트 할 수 있음 • Secret and configuration management 애플리케이션의 secret과 configuration 정보를 이미지와 독립적으로 구분하여 별도의 이미지 재생산 없이 관리 • Batch execution CI 워크로드와 같은 Batch 성 작업 지원 Crontab 형식으로 스케줄링도 가능
- 35. Kubernetes Architecture kubectl API server controller-manager (replication, namespace, serviceaccounts,…) scheduler etcd Internet Master node kubelet Pod Pod docker Worker node kubelet Kube-proxy Pod Pod docker Worker node Kube-proxy
- 36. Master Components • Kube-api-server • Front-end control plane. Exposes API • controller-manager • Runs controllers, e.g. replication controller, node controller • scheduler • assigns pods to nodes • etcd • Highly available, distributed Cluster database. • add-ons • DNS, Heapster (enables monitoring and performance analysis), Dashboard, Logging
- 37. Worker Node Components • Kubelet • Primary node agent • Watches and runs assigned pods • Executes health probes and reports status • Kube-proxy • Enables network services • Container Runtime • Docker, rkt(deprecated) ..
- 38. kubectl • CLI to run commands against a Kubernetes cluster • Swiss Army Knife: run deployments, exec into containers, view logs, etc. • Pronounced “koob sea tee el” or “koob cuddle” • Available for Windows and Linux – of course available in Azure Cloud Shell
- 39. Declarative vs Imperative • Commands like kubectl run and kubectl expose are imperative commands (do this thing now) • Declarative way – Describe the state of resources in a file(JSON or YAML). Kubectl apply –f webresource.yaml
- 41. Kubernetes Resources pod service deployment volumes ingress daemon set, job namespace secret, config-map
- 42. What is a pod? • Kubernetes 에서 최소 논리 단위 • 하나의 애플리케이션을 표현하는 최소 논리 단위 • Worker 노드에서 실행하는 Container의 집합 • 하나의 Pod내에서는 1…N개의 Container를 가질 수 있음 • 주로 Tightly Coupled 되는 Container들을 하나의 Pod에 묶음 예: NginX + Tomcat 예: Tomcat + Memcached • Pod에 있는 Container 는 물리적으로 같은 서버에 생성됨 • 하나의 Pod내에서는 PID Namespace , network 와 호스트를 공유함 Content Manager Consumers File Puller Web Server Volume Pod
- 43. Kubernetes manifest: Pod apiVersion: v1 kind: Pod metadata: name: redis-django labels: app: web spec: containers: - name: key-value-store image: redis ports: - containerPort: 6379 - name: frontend image: django ports: - containerPort: 8000 pod name: redis-django Container key-value-store Port 6379 Image: redis- django Container frontend Port 8000 Image: django
- 44. Interact with pods $ kubectl get pod --all-namespaces $ kubectl describe pod/my-pod $ kubectl logs my-pod # Run bash in container $ kubectl exec -it my-pod bash
- 45. Kubernetes Services • Defines a logical set of pods • Identified/selected using Labels • Essentially a virtual load balancer in front of pods Client Kube-proxy apiserver Backend Pod 1 labels: app=My App port: 9376 Backend Pod 2 labels: app=My App port: 9376 Backend Pod 3 labels: app=My App port: 9376 ServiceIP (iptables) Node
- 46. • Service Type LoadBalancer • Basic Layer4 Load Balancing (TCP/UDP) • Each service has assigned an IP on the ALB apiVersion: v1 kind: Service metadata: name: frontendservice spec: loadBalancerIP: X.X.X.X type: LoadBalancer ports: - port: 80 selector: app: frontend Azure AKS VNet AKS subnet AKS cluster FrontEndService Pod1 label:Frontend Pod2 label:Frontend Pod3 label:Frontend Public LB Public IP
- 47. • Used for internal services that should be accessed by other VNETs or On- Premise only apiVersion: v1 kind: Service metadata: name: internalservice annotations: service.beta.kubernetes.io/azure-load-balancer-internal: "true" spec: type: LoadBalancer loadBalancerIP: 10.240.0.25 ports: - port: 80 selector: app: internal Azure AKS VNet AKS subnet AKS cluster InternalService Pod1 label:Internal Pod2 label:Internal Pod3 label:Internal Internal LB Internal IP Other peered VNets VNet B VNet peering On-premises infrastructure Enterprise system Azure Express Route
- 48. Other Service Types • ClusterIP • Exposes the service on a cluster-internal IP. Choosing this value makes the service only reachable from within the cluster • NodePort • Exposes the service on each Node’s IP at a static port (the NodePort) • Connect from outside the cluster by requesting <NodeIP>:<NodePort>
- 49. Kubernetes manifest: Service apiVersion: v1 kind: Service metadata: name: my-service spec: selector: app: MyApp type: ClusterIP ports: - protocol: TCP port: 80 targetPort: 9376 Backend Pod 1 labels: app=MyApp port: 9376 Backend Pod 2 labels: app=MyApp port: 9376 Backend Pod 3 labels: app=MyApp port: 9376 ClusterIP w.x.y.z:80 Note! Services using ClusterIP are only reachable from within the cluster.