Skaffold’s version pinning is less about locking down your build tool and more about ensuring consistent development environments across your team.
Let’s see Skaffold in action, building and deploying a simple Go application. First, we’ll start with a basic skaffold.yaml that doesn’t pin a version:
apiVersion: skaffold/v2beta29
kind: Config
build:
local:
push: false
artifacts:
- image: my-go-app
docker:
dockerfile: Dockerfile
deploy:
kubectl:
manifests:
- k8s/*.yaml
And a simple Dockerfile:
FROM golang:1.19-alpine
WORKDIR /app
COPY . .
RUN go build -o main .
CMD ["/app/main"]
With this setup, when you run skaffold dev, Skaffold will use whatever version of the skaffold binary is present in your PATH. If one developer has v2.0.0 and another has v2.1.0, their skaffold dev commands might behave subtly differently, especially if there were breaking changes between those versions.
Now, let’s introduce version pinning. We’ll modify skaffold.yaml to explicitly request a specific Skaffold version:
apiVersion: skaffold/v2beta29
kind: Config
version: v2.7.0 # <-- Pinned version
build:
local:
push: false
artifacts:
- image: my-go-app
docker:
dockerfile: Dockerfile
deploy:
kubectl:
manifests:
- k8s/*.yaml
When you run skaffold dev with this skaffold.yaml, Skaffold will detect the version field. If your currently installed skaffold binary is not v2.7.0, it will attempt to download and run v2.7.0 specifically for that command. This ensures that regardless of what’s in your PATH, the Skaffold execution environment is precisely v2.7.0.
The core problem Skaffold version pinning solves is environment drift. Imagine you have a complex CI/CD pipeline or a team of developers. Without version pinning, each person or machine might be running a slightly different version of Skaffold. This can lead to:
- Inconsistent Builds: Different Skaffold versions might interpret build configurations or artifact definitions in subtly different ways.
- Unpredictable Deployments: Changes in Skaffold’s deployment logic or its interaction with Kubernetes APIs between versions can cause your deployments to succeed on one machine and fail on another.
- Debugging Headaches: When an issue arises, it’s hard to pinpoint if it’s a bug in your application, your Kubernetes manifests, or an unexpected behavior in the Skaffold version being used.
By pinning the version, you effectively create a contract: "This project is known to work with Skaffold v2.7.0."
When Skaffold detects the version field in your skaffold.yaml, it checks your current binary’s version. If there’s a mismatch, it downloads the specified version from its releases page. This downloaded binary is then used for the duration of that skaffold command. It doesn’t permanently install that version; it’s a temporary, per-command execution. This is crucial for ensuring that your local development experience mirrors what’s expected in your CI/CD environment, which should also be configured to use the pinned version.
The skaffold.yaml version field is a request, not a strict enforcement mechanism on your local machine’s installed binaries. If you have skaffold v2.8.0 installed and run skaffold dev with a skaffold.yaml requesting v2.7.0, Skaffold will download and run v2.7.0. However, if you have v2.7.0 installed and the skaffold.yaml requests v2.7.0, it will simply use your existing binary. The true power comes when you apply this to your CI/CD environment, ensuring that the build and deploy process always uses the pinned version, regardless of what might have been installed previously.
One of the less obvious benefits of version pinning is how it interacts with Skaffold’s plugin system. If your project relies on a specific Skaffold plugin that has version compatibility requirements, pinning the Skaffold version ensures that the correct Skaffold binary is invoked, which in turn correctly loads and executes compatible plugins. Without pinning, a newer Skaffold binary might be installed that is incompatible with your plugin, leading to silent failures or unexpected errors that are difficult to trace back to the root cause.
The next concept you’ll likely encounter is managing Skaffold’s configuration for different environments (development, staging, production) using profiles.