Kubernetes 용 로컬 개발 환경을 만드는 방법은 무엇입니까?

Kubernetes 용 로컬 개발 환경을 만드는 방법은 무엇입니까?

---

Kubernetes 는 클러스터 클라우드에 컨테이너를 배포하는 것입니다. 건드리지 않는 것처럼 보이는 것은 개발 및 스테이징 환경입니다.

개발 중에는 다음과 같은 몇 가지 중요한 변경 사항을 포함하여 프로덕션 환경에 최대한 가깝게되기를 원합니다.

• 로컬로 배포 (또는 최소한 귀하와 귀하 만 액세스 할 수있는 곳 )
• 페이지 새로 고침시 최신 소스 코드 를 사용 합니다 (웹 사이트라고 가정하고 소스 코드를 마운트하고 Yeoman 과 같은 것을 사용하면 수행 할 수있는 로컬 파일 저장시 페이지 자동 새로 고침 ).

마찬가지로 비공개 환경에서 지속적인 통합 을 수행하기를 원할 수 있습니다 .

Kubernetes는 이러한 종류의 개발 환경을 지원합니까, 아니면 프로덕션 중에 여전히 작동하기를 바라면서 구축해야하는 것이 있습니까?

---

업데이트 (2016-07-15)

Kubernetes 1.3 출시와 함께 Minikube 는 이제 개발을 위해 로컬 머신에서 Kubernetes를 실행하는 권장 방법입니다.

---

Docker를 통해 Kubernetes를 로컬에서 실행할 수 있습니다 . 노드가 실행되면 간단한 웹 서버가있는 포드를 시작하고 호스트 머신에서 볼륨을 마운트 할 수 있습니다. 웹 서버에 접속하면 볼륨에서 읽고 로컬 디스크의 파일을 변경 한 경우 최신 버전을 제공 할 수 있습니다.

---

이를위한 도구를 개발 중입니다. 기본 아이디어는 원격 Kubernetes 클러스터, 효과적으로 스테이징 환경이 있고 로컬에서 코드를 실행하고 원격 클러스터에 프록시되는 것입니다. 투명한 네트워크 액세스, 환경 변수 복사, 볼륨 액세스 ... 원격 환경에 최대한 가깝지만 코드가 로컬에서 실행되고 전체 제어하에 실행됩니다.

그래서 당신은 라이브 개발을 할 수 있습니다. http://telepresence.io의 문서

---

일종의 "핫 리로드"는 추가 할 계획이 있지만 오늘날만큼 쉽지는 않습니다. 그러나 모험심이 든다면 docker exec, kubectl exec 또는 osc exec와 함께 rsync를 사용하여 변경 될 때마다 로컬 디렉터리를 컨테이너에 동기화 할 수 있습니다. 다음과 같이 kubectl 또는 osc exec와 함께 rsync를 사용할 수 있습니다.

# rsync using osc as netcat
$ rsync -av -e 'osc exec -ip test -- /bin/bash' mylocalfolder/ /tmp/remote/folder

---

또 다른 좋은 출발점은이 Vagrant 설정 , esp입니다. 호스트 OS가 Windows 인 경우. 명백한 이점은

• 빠르고 간편한 설정
• 기계를 쉽게 파괴 / 재생성
• 자원에 대한 암시 적 제한
• 여러 노드를 생성하여 수평 확장을 테스트하는 기능

단점-많은 RAM이 필요하고 VirtualBox는 VirtualBox입니다 ...

혼합 된 장점 / 단점은 NFS를 통한 파일 매핑입니다. 설정 과정에서 두 세트의 RC 정의를 만들었습니다. 하나는 애플리케이션 서버의 도커 이미지 만 다운로드하는 것입니다. 다른 하나는 HostOS-> Vagrant-> VirtualBox-> CoreOS-> Kubernetes pod에서 파일 매핑을 설정하는 7 개의 추가 라인이 있습니다. Docker 이미지에서 소스 코드를 덮어 씁니다.

이것의 단점은 NFS 파일 캐시입니다. 그것 없이는 문제가 있습니다. 설정조차도 mount_options: 'nolock,vers=3,udp,noac'캐싱 문제를 완전히 제거하지는 못하지만 대부분의 경우 작동합니다. 컨테이너에서 실행 된 일부 Gulp 작업은 호스트 OS에서 8 초가 걸리지 만 5 분이 걸릴 수 있습니다. 좋은 타협은 mount_options: 'nolock,vers=3,udp,ac,hard,noatime,nodiratime,acregmin=2,acdirmin=5,acregmax=15,acdirmax=15'.

자동 코드 재로드는 언어별로 다르지만 Django의 Python 용 devserver와 Node.js 용 Nodemon에 만족합니다. 프론트 엔드 프로젝트의 경우 물론 gulp + browserSync + watch와 같은 작업을 통해 많은 작업을 수행 할 수 있지만 많은 개발자에게 Apache에서 제공하는 것은 어렵지 않고 기존의 하드 새로 고침 만 수행합니다.

Kubernetes 용 yaml 파일 4 세트를 보관합니다. Dev, "devstable", stage, prod. 그들 사이의 차이점은

• 환경을 명시 적으로 설정하는 env 변수 (dev / stage / prod)
• 복제본 수
• devstable, stage, prod는 docker 이미지를 사용합니다.
• dev는 도커 이미지를 사용하고 그 위에 소스 코드가있는 NFS 폴더를 매핑합니다.

많은 bash 별칭과 자동 완성을 만드는 것은 매우 유용합니다 . 입력 만하면 rec users됩니다 kubectl delete -f ... ; kubectl create -f .... 전체 설정을 시작하려면을 입력 recfo하고 12 개의 서비스를 다시 생성하여 최신 도커 이미지를 가져오고 Staging 환경에서 최신 db 덤프를 가져오고 공간을 절약하기 위해 오래된 Docker 파일을 정리합니다.

---

Skaffold로 시작했습니다.

코드 변경 사항을 로컬 클러스터에 자동으로 적용하는 것은 정말 유용합니다.

로컬 클러스터를 배포하는 가장 좋은 방법은 Minikube 또는 Mac 및 Windows 용 Docker이며 둘 다 Kubernetes 인터페이스를 포함합니다.

---

See https://github.com/kubernetes/kubernetes/issues/12278 for how to mount a volume from the host machine, the equivalent of:

docker run -v hostPath:ContainerPath

---

Having a nice local development feedback loop is a topic of rapid development in the Kubernetes ecosystem.

Breaking this question down, there are a few tools that I believe support this goal well.

Docker for Mac Kubernetes

Docker for Mac Kubernetes (Docker Desktop is the generic cross platform name) provides an excellent option for local development. For virtualization, it uses HyperKit which is built on the native Hypervisor framework in macOS instead of VirtualBox.

The Kubernetes feature was first released as beta on the edge channel in January 2018 and has come a long way since, becoming a certified Kubernetes in April 2018, and graduating to the stable channel in July 2018.

In my experience, it's much easier to work with than Minikube, particularly on macOS, and especially when it comes to issues like RBAC, Helm, hypervisor, private registry, etc.

Helm

As far as distributing your code and pulling updates locally, Helm is one of the most popular options. You can publish your applications via CI/CD as Helm charts (and also the underlying Docker images which they reference). Then you can pull these charts from your Helm chart registry locally and upgrade on your local cluster.

Azure Draft

You can also use a tool like Azure Draft to do simple local deploys and generate basic Helm charts from common language templates, sort of like buildpacks, to automate that piece of the puzzle.

Skaffold

Skaffold is like Azure Draft but more mature, much broader in scope, and made by Google. It has a very pluggable architecture. I think in the future more people will use it for local app development for Kubernetes.

If you have used React, I think of Skaffold as "Create React App for Kubernetes".

Kompose or Compose on Kubernetes

Docker Compose, while unrelated to Kubernetes, is one alternative that some companies use to provide a simple, easy, and portable local development environment analogous to the Kubernetes environment that they run in production. However, going this route means diverging your production and local development setups.

Kompose is a Docker Compose to Kubernetes converter. This could be a useful path for someone already running their applications as collections of containers locally.

Compose on Kubernetes is a recently open sourced (December 2018) offering from Docker which allows deploying Docker Compose files directly to a Kubernetes cluster via a custom controller.

---

Kubespary is helpful setting up local clusters. Mostly, I used vagrant based cluster on local machine.

Kubespray configuration You could tweak these variables to have the desired kubernetes version.

---

Have a look at https://github.com/okteto/okteto and Okteto Cloud. The value proposition is to have the classical development experience than working locally, prior to docker, where you can have hot-reloads, incremental builds, debuggers... but all your local changes are immediately synchronized to a remote container. Remote containers give you access to the speed of cloud, allow a new level of collaboration, and integrates development in a production-like environment. Also, it eliminates the burden of local installations.

---

As specified before by Robert, minikube is the way to go.

Here is a quick guide to get started with minikube. The general steps are:

• Install minikube

• Create minikube cluster (in a Virtual Machine which can be VirtualBox or Docker for Mac or HyperV in case of Windows)

• Create Docker image of your application file (by using Dockerfile)

• Run the image by creating a Deployment

• Create a service which exposes your application so that you can access it.

---

The disadvantage of using minkube is that it spawns another virtual machine over your machine. Also, with latest minikube version it minimum requires to have 2 CPU and 2GB of RAM from your system, which makes it pretty heavy If you do not have the system with enough resources.

This is the reason I switched to microk8s for development on kubernetes and I love it. microk8s supports the DNS, local-storage, dashboard, istio, ingress and many more, everything you need to test your microservices.

It is designed to be a fast and lightweight upstream Kubernetes installation isolated from your local environment. This isolation is achieved by packaging all the binaries for Kubernetes, Docker.io, iptables, and CNI in a single snap package.

A single node kubernetes cluster can be installed within a minute with a single command:

snap install microk8s --classic

Make sure your system doesn't have any docker or kubelet service running. Microk8s will install all the required services automatically.

Please have a look at the following link to enable other add ons in microk8s.

https://github.com/ubuntu/microk8s

You can check the status using:

velotio@velotio-ThinkPad-E470:~/PycharmProjects/k8sClient$ microk8s.status
microk8s is running
addons:
ingress: disabled
dns: disabled
metrics-server: disabled
istio: disabled
gpu: disabled
storage: disabled
dashboard: disabled
registry: disabled

참고URL : https://stackoverflow.com/questions/29746926/how-to-create-a-local-development-environment-for-kubernetes