Clever Geek Handbook

Skaffold Review for Kubernetes Development





A year and a half ago, on March 5, 2018, Google released the first alpha version of its Open Source project for CI / CD called Skaffold , whose goal was to create a “simple and reproducible development for Kubernetes” so that developers could focus on development, and not on administration. What might be of interest to Skaffold? As it turned out, he has a few trump cards in his sleeve, thanks to which he can become a powerful tool for the developer, and maybe an operating engineer. We will get acquainted with the project and its capabilities.



NB : By the way, we already talked briefly about Skaffold in our general overview of tools for developers whose life is connected with Kubernetes.



Theory. Purpose and features



So, speaking generally, Skaffold solves the problem of automating the CI / CD cycle (at the stages of build, push, deploy), offering the developer prompt feedback, i.e. the ability to quickly get the result of the next code changes - in the form of an updated application running in the Kubernetes cluster. And it can work in different contours (dev, stage, production ...), for which Skaffold helps to describe the appropriate pipelines for roll-out.



The source code for Skaffold is written in Go, and is distributed under the free Apache License 2.0 ( GitHub ).



Consider the main functions and features. The first include the following:





Now about the features:





Illustration of the latter:





Thanks to this, Skaffold can be called a kind of framework for building CI / CD . Here is an example of a workflow when using it (from the project documentation):







What does Skaffold's work look like in general?



  1. The utility monitors changes in the source directory. If modifications are made to the files, they are synchronized with the application pod in the Kubernetes cluster. If possible, without reassembling the image. Otherwise, a new image is going.
  2. The assembled image is checked using container-structure-test, tagged and sent to the Docker Registry.
  3. After that, the image is deployed - it is deployed in a Kubernetes cluster.
  4. If the launch was initialized using the skaffold dev



    command, then we begin to receive logs from the application, and Skaffold expects changes to repeat all the steps again.






Skaffold milestones illustration



Practice. Trying Skaffold



To demonstrate the use of Skaffold, I’ll take an example from the project ’s GitHub repository . By the way, there you can find many other examples that take into account various specifics. All actions will be performed locally in Minikube. Installation is simple and takes a few minutes, and kubectl is required to get started.



Install Skaffold: 



 curl -Lo skaffold https://storage.googleapis.com/skaffold/releases/latest/skaffold-linux-amd64 chmod +x skaffold sudo mv skaffold /usr/local/bin skaffold version v0.37.1


Let's clone the Skaffold repository with the necessary examples: 



 git clone https://github.com/GoogleContainerTools/skaffold cd skaffold/examples/microservices


I chose an example with two pods, each of which contains one small application on Go. One application is the frontend (leeroy-web), a redirect request to the second application is the backend (leeroy-app). Let's see how it looks: 



 ~/skaffold/examples/microservices # tree . ├── leeroy-app │ ├── app.go │ ├── Dockerfile │ └── kubernetes │ └── deployment.yaml ├── leeroy-web │ ├── Dockerfile │ ├── kubernetes │ │ └── deployment.yaml │ └── web.go ├── README.adoc └── skaffold.yaml 4 directories, 8 files


leeroy-app and leeroy-web contain Go code and simple Dockerfiles for building this code locally: 



 ~/skaffold/examples/microservices # cat leeroy-app/Dockerfile FROM golang:1.12.9-alpine3.10 as builder COPY app.go . RUN go build -o /app . FROM alpine:3.10 CMD ["./app"] COPY --from=builder /app .


I will not give the application code - it is enough to know that leeroy-web



accepts requests and proxies them to leeroy-app



. Therefore, in the Deployment.yaml



files, there is Service only for the app



(for internal routing). The web



pod port will be thrown to us for quick access to the application.



What skaffold.yaml



looks skaffold.yaml



: 



 ~/skaffold/examples/microservices # cat skaffold.yaml apiVersion: skaffold/v1beta13 kind: Config build: artifacts: - image: leeroy-web context: ./leeroy-web/ - image: leeroy-app context: ./leeroy-app/ deploy: kubectl: manifests: - ./leeroy-web/kubernetes/* - ./leeroy-app/kubernetes/* portForward: - resourceType: deployment resourceName: leeroy-web port: 8080 localPort: 9000


All the steps mentioned above are described here. In addition to this config, there is also a file with global settings - ~/.skaffold/config



. It can be edited manually or through the CLI - for example, like this: 



 skaffold config set --global local-cluster true


This command sets the local-cluster



global variable to true



, after which Skaffold will not attempt to 'push' the images into the remote registry. If you are developing locally, you can use this command to add images locally as well.



Back to skaffold.yaml



:





It's time to start skaffold dev



: the team will create an ongoing “feedback loop”, i.e. not only collects everything and installs in a cluster, but also tells about the status of pods at the moment, will monitor the changes and update the status of pods.



Here is the result of running skaffold dev --port-forward



when reassembling:







Firstly, it’s clear that the cache is being used. Next - the application is assembled, deployed, ports are forwarded. Since --port-forward



is specified, Skaffold forwarded the port to the web



, as requested, but he forwarded the app



at its own discretion (chose the nearest free one). After that, we get the first logs from the applications.



Check performance? 



 ~/skaffold/examples/microservices # kubectl get po NAME READY STATUS RESTARTS AGE leeroy-app-6998dfcc95-2nxvf 1/1 Running 0 103s leeroy-web-69f7d47c9d-5ff77 1/1 Running 0 103s ~/skaffold/examples/microservices # curl localhost:9000 leeroooooy app!!!


Modify the leeroy-app/app.go



- it takes a few seconds ... and: 



 ~/skaffold/examples/microservices # kubectl get po NAME READY STATUS RESTARTS AGE leeroy-app-ffd79d986-l6nwp 1/1 Running 0 11s leeroy-web-69f7d47c9d-5ff77 1/1 Running 0 4m59s ~/skaffold/examples/microservices # curl localhost:9000 leeroooooy Habr!!!


At the same time, Skaffold itself brought to the console the same thing as before, with the exception of one point: it rolled out only the leeroy-app



, and not all at once.



More practice



It is worth mentioning that when creating a new project, the configs for Skaffold can be bootstrap using the init



command, which is very convenient. In addition, you can write several configs: develop on the default config, and then roll out to the stage with the run



command (the same process as dev



, just does not follow the changes), using a different config.



Katacoda has a tutorial with an example even simpler. But it offers a ready-made sandbox with Kubernetes, the application and Skaffold. A great option if you are interested to try the very basics on your own.



One possible use case for Skaffold is to conduct development on a remote cluster. Not everyone is comfortable running Minikube on their own hardware, and then rolling out the application and waiting for its proper functioning ... In this case, Skaffold perfectly solves the task, which, for example, Reddit engineers can confirm, as we already wrote about in our blog.



And in this publication from Weaveworks you can find an example of creating a pipeline for production.



Conclusion



Skaffold is a convenient tool for building pipelines, implying rollout of applications in Kubernetes and focused primarily on development needs. With it, it’s quite simple to create a “short” pipeline that takes into account the basic needs of the developer, but you can also organize larger processes if you wish. One of the illustrative examples of using Skaffold in CI / CD processes is a test project of 10 microservices that use the capabilities of Kubernetes, gRPC, Istio and OpenCensus Tracing.



Skaffold has already received almost 8000+ stars on GitHub, is being developed by Google and is part of GoogleContainerTools - in general, at the moment there is every reason to believe that the project will develop happily ever after.



PS



Read also in our blog:





More articles:


All Articles