How to create a local development environment for Kubernetes?

Kubernetes seems to be about deploying containers in a cloud of clusters. What it does not seem to concern the development environment and the intermediate environment (or such).

During development, you want to be as close to your work environment as possible with some important changes:

  • Deployed locally (or at least somewhere where you and only you can access )
  • Use the latest source code on the update page (suppose that its site, ideally, the page automatically updates when the file is saved locally, which can be done if you mount the source code and use some things like Yeoman ).

Similarly, it may be necessary for a non-public environment to perform continuous integration .

Does Kubernetes support such a development environment or should it be built in the hope that it will work anyway during production?

+107
docker kubernetes google-cloud-platform openshift-origin
Apr 20 '15 at 11:42
source share
13 answers

Update (2016-07-15)

With the release of Kubernetes 1.3, Minikube is now the recommended way to run Kubernetes on your local development machine.




You can run Kubernetes locally through Docker . After starting node, you can start the module, which has a simple web server and mounts the volume from your host computer. When you click the web server, it will read from the volume, and if you modify the file on your local drive, it can serve the latest version.

+62
Apr 21 '15 at 17:15
source share

We are working on a tool for this. The main idea is that you have a remote Kubernetes cluster, actually an intermediate environment, and then you run the code locally and it is passed through the proxy to the remote cluster. You get transparent access to the network, copied environment variables, access to volumes ... as close to the remote environment as possible, but your code works locally and under your full control.

So you can do live development, say. Documents at http://telepresence.io

+9
Apr 13 '17 at 13:43 on
source share

A hot reboot is what we plan to add, but not as simple as it can be today. However, if you feel like an adventurer, you can use rsync with docker exec, kubectl exec or osc exec (all do roughly the same thing) to synchronize the local directory in the container whenever it changes. You can use rsync with kubectl or osc exec like this:

# rsync using osc as netcat $ rsync -av -e 'osc exec -ip test -- /bin/bash' mylocalfolder/ /tmp/remote/folder 
+5
Apr 21 '15 at 19:49
source share

Another great starting point is setting up strollers , especially. if your host OS is Windows. The obvious benefits are

  • quick and painless setup
  • easy to destroy / recreate a car
  • implicit resource limit
  • ability to check horizontal scaling by creating multiple nodes

Disadvantages - you need a lot of RAM, and VirtualBox - VirtualBox ... for better or worse.

A mixed advantage / disadvantage is file mapping via NFS. In our installation, we created two sets of RC definitions - one that simply loads the docker image of our application servers; another with 7 additional lines that configure file mapping from HostOS -> Vagrant -> VirtualBox -> CoreOS -> Kubernetes pod; rewriting the source code from a Docker image.

The disadvantage of this is the NFS cache file - it is problematic with it, without it it slows down problematically. Even setting mount_options: 'nolock,vers=3,udp,noac' does not completely fix caching problems, but it works most of the time. Some Gulp tasks performed in the container can take 5 minutes when they take 8 seconds on the host OS. A good compromise seems to be mount_options: 'nolock,vers=3,udp,ac,hard,noatime,nodiratime,acregmin=2,acdirmin=5,acregmax=15,acdirmax=15' .

Regarding automatic code reloading, this language is specific, but we are happy with Django devserver for Python and Nodemon for Node.js. For projects with an interface, you can, of course, do a lot with something like gulp + browserSync + watch, but for many developers it is not difficult to maintain from Apache and just do the traditional hard update.

We save 4 yaml filesets for Kubernetes. Dev, "devstable", stage, prod. The differences between them:

  • env variables explicitly setting the environment (dev / stage / prod)
  • number of replicas
  • devstable, stage, prod uses docker images
  • dev uses docker images and displays the NFS folder with the source code above them.

It is very useful to create many bash aliases and autocomplete - I can just type rec users and it will execute kubectl delete -f ... ; kubectl create -f ... kubectl delete -f ... ; kubectl create -f ... If I want the whole setup to start, I type recfo and it recreates a dozen services, extracting the latest recfo images, importing the last db dump from Staging env and clearing old Docker files to save space.

+4
Sep 01 '15 at 7:16
source share

I just started with Scaffold

It is really useful to automatically make changes to the code in the local cluster.

To deploy a local cluster, it is best to use Minikube or just Docker for Mac and Windows, both of which include the Kubernetes interface.

+4
May 21 '18 at 16:31
source share

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

 docker run -v hostPath:ContainerPath 
+2
Feb 16 '16 at 7:17
source share

A good local development feedback loop is a topic of rapid development of the Kubernetes ecosystem.

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

Docker for Mac Kubernetes

Docker for Mac Kubernetes ( Docker Desktop is the common name for cross-platform) provides an excellent opportunity for local development. For virtualization, it uses HyperKit, which is built on its own Hypervisor platform in macOS instead of VirtualBox.

Kubernetes was first released as a beta version on the border channel in January 2018 and has since come a long way, becoming Kubernetes certified in April 2018 and switching to a stable channel in July 2018 .

In my experience, working with Minikube is much easier, especially on macOS, especially when it comes to issues such as RBAC, Helm, hypervisor, private registry, etc.

Helmet

As for distributing your code and getting updates locally, Helm is one of the most popular options. You can publish your applications via CI / CD in the form of Helm diagrams (as well as the basic Docker images to which they refer). You can then extract these diagrams from the Helm map registry locally and update them in your local cluster.

Azure draft

You can also use a tool such as Azure Draft to perform simple local deployments and create Helm basic diagrams from common language templates, such as buildpacks, to automate this part of the puzzle.

Skaffold

Skaffold is like a draft of Azure, but more mature, much wider in size and made by Google. It has a very plug-in architecture. I think that in the future more and more people will use it to develop local applications for Kubernetes.

If you used React, I think of Scaffold as " Create a React Application for Kubernetes."

Composition or Composition on Kubernetes

Docker Compose , although not affiliated with Kubernetes, is one of the alternatives that some companies use to provide a simple, lightweight, and portable local development environment similar to the Kubernetes environment they use in production. However, following this path means a discrepancy between your production and local development settings.

Kompose is a Docker Compose to Kubernetes converter. This can be a useful way for those who are already running their applications as collections of containers locally.

Compose in Kubernetes is a recently opened (from December 2018) offer from Docker, which allows you to deploy Docker Compose files directly to a Kubernetes cluster through a special controller.

+2
Feb 02 '19 at 3:58
source share

Kubespary is useful when setting up local clusters. I mainly used a vagrant cluster on a local machine.

Kubespray configuration You can configure these variables to get the desired version of kubernetes.

+1
Jan 25 '18 at 11:21
source share

Take a look at https://github.com/okteto/okteto and the Okteto cloud . The value of the proposal is to have the experience of classic development, than to work locally, to a docker, where you can have hot reboots, incremental builds, debuggers ... but all your local changes are immediately synchronized with the remote container. Remote containers give you access to cloud speed, provide a new level of collaboration, and integrate development into your production environment. In addition, this eliminates the burden of local installations.

+1
Aug 08 '19 at 13:58 on
source share

As stated earlier by Robert, a minicube is the way to go.

Here is a quick guide to get started with Minikube. The main steps:

  • Install minicube

  • Create a cluster of mini-cubes (in a virtual machine, which can be VirtualBox or Docker for Mac or HyperV in case of Windows)

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

  • Launch the image by creating a deployment

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

0
Oct. 15 '18 at 16:29
source share

You can use the remote kubernetes cluster and configure your local machines to connect to this cluster. Use kubectl cp commands to copy code to running modules to hot-load the code during development.

0
Nov 25 '18 at 17:12
source share

The downside of using minkube is that it spawns another virtual machine on top of your machine. In addition, the latest version of minikube requires a minimum of 2 CPUs and 2 GB of RAM from your system, which makes it quite difficult if you do not have enough system resources.

For this reason, I switched to microk8s for development on kubernetes, and I like it. microk8s supports DNS, local storage, dashboard, istio, login and more, all you need to test your microservices.

It is designed to quickly and easily install Kubernetes upstream, isolated from your local environment. This isolation is achieved by packing all the binaries for Kubernetes, Docker.io, iptables and CNI into a single package with binding.

One kubernetes cluster node can be installed in one minute with a single command:

 snap install microk8s --classic 

Make sure that no docker or clet service is running on your system. Microk8s install all the necessary services automatically.

Please see the following link for 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 
0
Jan 04 '19 at 10:47
source share

it's hidden here , I sped up my local development in less than 5 minutes

0
Jul 09 '19 at 11:56 on
source share



All Articles