-
Notifications
You must be signed in to change notification settings - Fork 0
User FAQ
This is covered by our getting-started guide.
We recommend you do not use binaries from http://storage.googleapis.com/kubernetes
, as these are neither official releases nor maintained.
Kubernetes expects an argv array for the command. If you put your command and its arguments all in one string, that is interpreted as the command name. Put the arguments into separate array elements instead.
As discussed in Docker's documentation, the container's command is not necessarily executed in a shell, in which case environment variables are not expanded in command-line arguments. In particular, non-default commands are specified via Kubernetes's API using the array form of Docker's Cmd
argument, which causes the command to be exec
ed directly. You can cause environment variables to be evaluated by simply making your command a shell, with your application's command line as its argument. For example:
{ "command": [ "sh", "-c", "redis-server /etc/redis/redis.conf --slaveof $SERVICE_HOST $REDIS_MASTER_SERVICE_PORT"] }
The Kubernetes scheduler spreads pods with the same labels (e.g., spawned by the same ReplicationController) and pods targeted by the same Service by default. However, if you need a hard guarantee that no two of the pods will schedule on the same node, request a hostPort
for one of the containers in the pod. The scheduler will ensure that at most one pod uses a given host port on any node. For example:
apiVersion: v1
kind: Pod
metadata:
name: hello
labels:
app: hello
environment: testing
spec:
containers:
- name: hello
image: quay.io/kelseyhightower/hello
ports:
- containerPort: 80
hostPort: 80
You need to create the service before creating the pods that will connect to the service.
Also ensure you are using the correct environment variable names.
If neither of these is your problem, see the Debugging-FAQ.
Change NUM_MINIONS in the platform-specific config-default.sh file, such as GCE's.
Currently, NUM_MINIONS needs to be changed before turning up the cluster.
Kubernetes has native support for the Google Container Regisry, when running on Google Compute Engine. If you are running your cluster on Google Compute Engine or Google Container Engine, simply use the full image name (e.g. gcr.io/my_project/image:tag
) and the kubelet will automatically authenticate and pull down your private image.
If you are using a private registry that requires authentication, you need to create a .dockercfg file on all of your machines.
Running docker login -u xxx -p yyy -e zzz@zzzz https://registry.com
will automatically create dockercfg at $HOME/.dockercfg. You may need to place this in a specific directory on different providers. Further details here
Update February 2015: The Google Container Regisry (see above) is a hosted private Docker registry, backed by Google Cloud Storage.
To use the google/docker-registry
container image:
- Create a replication controller with 1 or more pods and the google cloud storage registry image
- Create a Kubernetes service with a PortalIP address of your choice within the portal IP range, and use that IP address for the registry name.