Change:
`sample-apiserver` is synced from https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/sample-apiserver. Code changes are made in that location, merged into `k8s.io/kubernetes` and later synced here. <ins> ## Fetch sample-apiserver and its dependencies Like the rest of Kubernetes, sample-apiserver has used [godep](https://github.com/tools/godep) and `$GOPATH` for years and is now adopting go 1.11 modules.  There are thus two alternative ways to go about fetching this demo and its dependencies. ### Fetch with godep When NOT using go 1.11 modules, you can use the following commands. ```sh go get -d k8s.io/sample-apiserver cd $GOPATH/src/k8s.io/sample-apiserver  # assuming your GOPATH has just one entry godep restore ``` ### When using go 1.11 modules When using go 1.11 modules (`GO111MODULE=on`), issue the following commands --- starting in whatever working directory you like. ```sh git clone https://github.com/kubernetes/sample-apiserver.git cd sample-apiserver ``` Note, however, that if you intend to [generate code](#changes-to-the-types) then you will also need the code-generator repo to exist in an old-style location.  One easy way to do this is to use the command `go mod vendor` to create and popdulate the `vendor` directory. ### A Note on kubernetes/kubernetes If you are developing Kubernetes according to https://github.com/kubernetes/community/blob/master/contributors/guide/github-workflow.md then you already have a copy of this demo in `kubernetes/staging/src/k8s.io/sample-apiserver` and its dependencies --- including the code generator --- are in usable locations. ## Normal Build and Deploy ### Changes to the Types If you change the API object type definitions in any of the `pkg/apis/.../types.go` files then you will need to update the files generated from the type definitions.  To do this, first [create the vendor directory if necessary](#when-using-go-111-modules) and then invoke `hack/update-codegen.sh` with `sample-apiserver` as your current working directory; the script takes no arguments. ### Authentication plugins The normal build supports only a very spare selection of authentication methods.  There is a much larger set available in https://github.com/kubernetes/client-go/tree/master/plugin/pkg/client/auth .  If you want your server to support one of those, such as `oidc`, then add an import of the appropriate package to `sample-apiserver/main.go`.  Here is an example: ``` go import _ "k8s.io/client-go/plugin/pkg/client/auth/oidc" ``` Alternatively you could add support for all of them, with an import like this: ``` go import _ "k8s.io/client-go/plugin/pkg/client/auth" ``` ### Build the Binary With `sample-apiserver` as your current working directory, issue the following command: ``` CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -a -o artifacts/simple-image/kube-sample-apiserver ``` ### Build the Container Image With `sample-apiserver` as your current working directory, issue the following commands with `MYPREFIX` and `MYTAG` replaced by something suitable. ``` docker build -t MYPREFIX/kube-sample-apiserver:MYTAG ./artifacts/simple-image docker push MYPREFIX/kube-sample-apiserver:MYTAG ``` ### Deploy into a Kubernetes Cluster Edit `artifacts/example/rc.yaml`, updating the pod template's image reference to match what you pushed and setting the `imagePullPolicy` to something suitable.  Then call: ``` kubectl apply -f artifacts/example ``` </ins> ## Running it stand-alone During development it is helpful to run sample-apiserver stand-alone, i.e. without

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks!--What happened: I wanted to test the latest version of the sample-apiserver. I still did not find instructions or a script for building it. I found the script, but that relies on the directory produced when building k/k. What you expected to happen: I expected this sample to have standalone build instructions or scripting. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
I created a script of my own to build it:
Also: since the file has a fixed image reference, only someone who pushes to that image can use that file unmodified. The README should say something about this.
Also, the existing is not designed to be invoked by a developer who has done but rather is designed to work only in the context of a full build of k/k.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale Being addressed by