You are browsing a read-only backup copy of Wikitech. The live site can be found at wikitech.wikimedia.org
Help:Toolforge/Kubernetes: Difference between revisions
imported>BryanDavis |
imported>Dbarratt (→Running Locally: Update command to include enabling PHP support) |
||
Line 3: | Line 3: | ||
'''[[w:Kubernetes|Kubernetes]]''' (often abbreviated '''k8s''') is a platform for running [[w:Operating-system-level virtualization|containers]]. It is used in Toolforge to isolate Tools from each other and allow distributing Tools across a pool of servers. | '''[[w:Kubernetes|Kubernetes]]''' (often abbreviated '''k8s''') is a platform for running [[w:Operating-system-level virtualization|containers]]. It is used in Toolforge to isolate Tools from each other and allow distributing Tools across a pool of servers. | ||
== Kubernetes webservices == | ==Kubernetes webservices== | ||
The Toolforge <code>webservice</code> command has a <code>--backend=kubernetes</code> mode that will start, stop, and restart containers designed to run web services for various languages. See our [[Help:Toolforge/Web|Webservice help]] for more details. | The Toolforge <code>webservice</code> command has a <code>--backend=kubernetes</code> mode that will start, stop, and restart containers designed to run web services for various languages. See our [[Help:Toolforge/Web|Webservice help]] for more details. | ||
== Kubernetes cronjobs == | ==Kubernetes cronjobs== | ||
{{tracked|T158155|resolved}} | {{tracked|T158155|resolved}} | ||
It is possible to run cron jobs on kubernetes (see [https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/ upstream documentation] for a full description), however this functionality is not officially supported by the Wikimedia Cloud Services team and should be considered an experimental feature. | It is possible to run cron jobs on kubernetes (see [https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/ upstream documentation] for a full description), however this functionality is not officially supported by the Wikimedia Cloud Services team and should be considered an experimental feature. | ||
== Kubernetes continuous jobs == | ==Kubernetes continuous jobs== | ||
The basic unit of managing execution on a Kubernetes cluster is called a "deployment". Each deployment is described with a YAML configuration file which describes the container images to be started ("pods" in the Kubernetes terminology) and commands to be run inside them after the container is initialized. A deployment also specifies where the pods run and what external resources are connected to them. The [https://kubernetes.io/docs/concepts/workloads/controllers/deployment/ upstream documentation] is comprehensive. | The basic unit of managing execution on a Kubernetes cluster is called a "deployment". Each deployment is described with a YAML configuration file which describes the container images to be started ("pods" in the Kubernetes terminology) and commands to be run inside them after the container is initialized. A deployment also specifies where the pods run and what external resources are connected to them. The [https://kubernetes.io/docs/concepts/workloads/controllers/deployment/ upstream documentation] is comprehensive. | ||
=== Example deployment.yaml === | ===Example deployment.yaml=== | ||
[[Tool:Stashbot|Stashbot]] is a Python irc bot that runs in a Kubernetes deployment. The [[phab:diffusion/LTST/browse/master/etc/deployment.yaml|deployment.yaml file that it uses]] to tell Kubernetes how to start the bot is reproduced below. This deployment is launched using a [[phab:diffusion/LTST/browse/master/bin/stashbot.sh|<code>stashbot.sh</code> wrapper script]] which runs <code>kubectl create -f /data/project/stashbot/etc/deployment.yaml</code>. | [[Tool:Stashbot|Stashbot]] is a Python irc bot that runs in a Kubernetes deployment. The [[phab:diffusion/LTST/browse/master/etc/deployment.yaml|deployment.yaml file that it uses]] to tell Kubernetes how to start the bot is reproduced below. This deployment is launched using a [[phab:diffusion/LTST/browse/master/bin/stashbot.sh|<code>stashbot.sh</code> wrapper script]] which runs <code>kubectl create -f /data/project/stashbot/etc/deployment.yaml</code>. | ||
Line 54: | Line 54: | ||
This deployment: | This deployment: | ||
=== Monitoring your jobs === | *Uses the 'stashbot' namespace that the tool is authorized to control | ||
*Creates a container using the 'latest' version of the 'docker-registry.tools.wmflabs.org/[[phab:diffusion/ODIT/browse/master/python2/base/Dockerfile.template|toollabs-python2-base]]' Docker image. | |||
*Runs the command <code>/data/project/stashbot/bin/stashbot.sh run</code> when the container starts. | |||
*Mounts the <tt>/data/project/stashbot/</tt> NFS directory as <tt>/data/project/stashbot/</tt> inside the container. | |||
===Monitoring your jobs=== | |||
You can see which jobs you have running with <code>kubectl get pods</code>. Using the name of the pod, you can see the logs with <code>kubectl logs <pod-name></code>. | You can see which jobs you have running with <code>kubectl get pods</code>. Using the name of the pod, you can see the logs with <code>kubectl logs <pod-name></code>. | ||
To restart a failing pod, use <code>kubectl delete <pod-name></code>. If you need to kill it entirely, find the deployment name with <code>kubectl get deployment</code>, and delete it with <code>kubectl delete deployment <deployment-name></code>. | To restart a failing pod, use <code>kubectl delete <pod-name></code>. If you need to kill it entirely, find the deployment name with <code>kubectl get deployment</code>, and delete it with <code>kubectl delete deployment <deployment-name></code>. | ||
== Namespaces == | ==Namespaces== | ||
Each tool has been granted control of a Kubernetes [https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/ "namespace"]. Your tool can only create and control objects in its namespace. A tool's namespace is the same as the tool's name (e.g. <code>admin</code>, <code>stashbot</code>, <code>hay</code>, etc). | Each tool has been granted control of a Kubernetes [https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/ "namespace"]. Your tool can only create and control objects in its namespace. A tool's namespace is the same as the tool's name (e.g. <code>admin</code>, <code>stashbot</code>, <code>hay</code>, etc). | ||
== Container images == | ==Container images== | ||
The Toolforge Kubernetes cluster is restricted to loading Docker images published at <code>docker-registry.tools.wmflabs.org</code> (see [[Portal:Toolforge/Admin/Kubernetes#Docker Images]] for more information). These images are built using the Dockerfiles in the [[phab:diffusion/ODIT/repository/master/|operations/docker-images/toollabs-images]] git repository. | The Toolforge Kubernetes cluster is restricted to loading Docker images published at <code>docker-registry.tools.wmflabs.org</code> (see [[Portal:Toolforge/Admin/Kubernetes#Docker Images]] for more information). These images are built using the Dockerfiles in the [[phab:diffusion/ODIT/repository/master/|operations/docker-images/toollabs-images]] git repository. | ||
=== Available container types === | ===Available container types=== | ||
The <code>webservice</code> command has an optional ''type'' argument that allows you to choose which Docker container to run your Tool in. | The <code>webservice</code> command has an optional ''type'' argument that allows you to choose which Docker container to run your Tool in. | ||
Currently provided types: | Currently provided types: | ||
* golang | |||
* jdk8 | *golang | ||
* nodejs (node.js 6.11) | *jdk8 | ||
* node10 | *nodejs (node.js 6.11) | ||
* php5.6 | *node10 | ||
* php7.2 | *php5.6 | ||
* python (python3.4) | *php7.2 | ||
* python2 | *python (python3.4) | ||
* python3.5 | *python2 | ||
* ruby2 | *python3.5 | ||
* tcl | *ruby2 | ||
*tcl | |||
For example to start a webservice using a php7.2 container, run: | For example to start a webservice using a php7.2 container, run: | ||
Line 92: | Line 94: | ||
As of Feb 2018, we don't support mixed runtime containers. This may change in the future. Also, we don't support "bring your own container" on our kubernetes (yet!). And there is no mechanism for a user to install system packages inside of a container. | As of Feb 2018, we don't support mixed runtime containers. This may change in the future. Also, we don't support "bring your own container" on our kubernetes (yet!). And there is no mechanism for a user to install system packages inside of a container. | ||
=== PHP === | ===PHP=== | ||
{{anchor|php5.6 (Lighttpd + PHP)}} | {{anchor|php5.6 (Lighttpd + PHP)}} | ||
PHP uses lighttpd as a webserver, and looks for files in <code>~/public_html/</code>. | PHP uses lighttpd as a webserver, and looks for files in <code>~/public_html/</code>. | ||
==== PHP versions & packages ==== | ====PHP versions & packages==== | ||
There are two versions of PHP available, PHP 7.2 (on Debian Stretch), and the legacy PHP 5.6 (on Debian Jessie). | There are two versions of PHP available, PHP 7.2 (on Debian Stretch), and the legacy PHP 5.6 (on Debian Jessie). | ||
You can view the installed PHP extensions on the [[toolforge:phpinfo|phpinfo tool]]. This should match the PHP related packages installed on GridEngine exec nodes. Additional packages can be added on request by creating a subtask of [[phab:T140110|T140110]]. | You can view the installed PHP extensions on the [[toolforge:phpinfo|phpinfo tool]]. This should match the PHP related packages installed on GridEngine exec nodes. Additional packages can be added on request by creating a subtask of [[phab:T140110|T140110]]. | ||
==== PHP Upgrade ==== | ====PHP Upgrade==== | ||
To upgrade from PHP 5.6 to PHP 7, run the following two commands:<syntaxhighlight lang="shell-session"> | To upgrade from PHP 5.6 to PHP 7, run the following two commands:<syntaxhighlight lang="shell-session"> | ||
$ webservice stop | $ webservice stop | ||
Line 109: | Line 111: | ||
</syntaxhighlight> | </syntaxhighlight> | ||
=== Node.js === | ====Running Locally==== | ||
You may run the container locally by executing a command like this:<syntaxhighlight lang="shell-session"> | |||
$ docker run --name toolforge -p 8888:80 -v "${PWD}:/var/www/html:cached" -d docker-registry.tools.wmflabs.org/toollabs-php-web sh -c "lighty-enable-mod fastcgi-php && lighttpd -D -f /etc/lighttpd/lighttpd.conf" | |||
</syntaxhighlight>Then the tool will be available at http://localhost:8888 | |||
===Node.js=== | |||
The container images for Node.js, such as <code>docker-registry.tools.wmflabs.org/toollabs-nodejs-base:latest</code> currently come with a current version of Node.js LTS from Wikimedia APT (as of September 2018, this is Node.js 6). This is the same version used by Wikimedia Foundation in production and for continuous integration. | The container images for Node.js, such as <code>docker-registry.tools.wmflabs.org/toollabs-nodejs-base:latest</code> currently come with a current version of Node.js LTS from Wikimedia APT (as of September 2018, this is Node.js 6). This is the same version used by Wikimedia Foundation in production and for continuous integration. | ||
==== Broken npm ==== | ====Broken npm==== | ||
Given npm is not suitable for use in Wikimedia production, the version of Node.js provided by Wikimedia APT is compiled without npm. (Unlike the official Node.js distribution.) And because there is no use for npm in Wikimedia production, there is no "npm" Debian package maintained in Wikimedia APT. The result is that the only "npm" Debian package available is the one from upstream Debian, which is npm 1.4 which was originally bundled in 2014 with Node 0.10 ([https://packages.debian.org/jessie/npm debian/npm], [https://packages.debian.org/jessie/nodejs debian/nodejs]). This version is EOL and is incompatible with most packages on the npmjs.org registry. To update it within your container, follow these steps | Given npm is not suitable for use in Wikimedia production, the version of Node.js provided by Wikimedia APT is compiled without npm. (Unlike the official Node.js distribution.) And because there is no use for npm in Wikimedia production, there is no "npm" Debian package maintained in Wikimedia APT. The result is that the only "npm" Debian package available is the one from upstream Debian, which is npm 1.4 which was originally bundled in 2014 with Node 0.10 ([https://packages.debian.org/jessie/npm debian/npm], [https://packages.debian.org/jessie/nodejs debian/nodejs]). This version is EOL and is incompatible with most packages on the npmjs.org registry. To update it within your container, follow these steps | ||
# Step 1: Start a shell in your Node.js pod (see "Shell" section below) | # Step 1: Start a shell in your Node.js pod (see "Shell" section below) | ||
Line 138: | Line 145: | ||
6.4.1 | 6.4.1 | ||
== Shell == | ==Shell== | ||
To establish a shell inside your Kubernetes pod, run the following two commands from tools-login: | To establish a shell inside your Kubernetes pod, run the following two commands from tools-login: | ||
$ kubectl get pods | $ kubectl get pods | ||
Line 149: | Line 156: | ||
See also [https://kubernetes.io/docs/tasks/debug-application-cluster/get-shell-running-container/ Get a Shell to a Running Container] at kubernetes.io/docs. | See also [https://kubernetes.io/docs/tasks/debug-application-cluster/get-shell-running-container/ Get a Shell to a Running Container] at kubernetes.io/docs. | ||
== Troubleshooting == | ==Troubleshooting== | ||
If <code>kubectl get pods</code> fails with error message <code>runtime: failed to create new OS thread (have 12 already; errno=11)</code>, just use <code>GOMAXPROCS=1 kubectl get pods</code>. | If <code>kubectl get pods</code> fails with error message <code>runtime: failed to create new OS thread (have 12 already; errno=11)</code>, just use <code>GOMAXPROCS=1 kubectl get pods</code>. | ||
== See also == | ==See also== | ||
* [[Portal:Toolforge/Admin/Kubernetes|Kubernetes administration]] | |||
* [https://kubernetes.io/docs/user-guide/kubectl-cheatsheet/ kubectl (Kubernetes command line tool) cheatsheet] | *[[Portal:Toolforge/Admin/Kubernetes|Kubernetes administration]] | ||
*[https://kubernetes.io/docs/user-guide/kubectl-cheatsheet/ kubectl (Kubernetes command line tool) cheatsheet] | |||
[[Category:Toolforge|Kubernetes]] | [[Category:Toolforge|Kubernetes]] |
Revision as of 15:40, 13 June 2019
Kubernetes (often abbreviated k8s) is a platform for running containers. It is used in Toolforge to isolate Tools from each other and allow distributing Tools across a pool of servers.
Kubernetes webservices
The Toolforge webservice
command has a --backend=kubernetes
mode that will start, stop, and restart containers designed to run web services for various languages. See our Webservice help for more details.
Kubernetes cronjobs
It is possible to run cron jobs on kubernetes (see upstream documentation for a full description), however this functionality is not officially supported by the Wikimedia Cloud Services team and should be considered an experimental feature.
Kubernetes continuous jobs
The basic unit of managing execution on a Kubernetes cluster is called a "deployment". Each deployment is described with a YAML configuration file which describes the container images to be started ("pods" in the Kubernetes terminology) and commands to be run inside them after the container is initialized. A deployment also specifies where the pods run and what external resources are connected to them. The upstream documentation is comprehensive.
Example deployment.yaml
Stashbot is a Python irc bot that runs in a Kubernetes deployment. The deployment.yaml file that it uses to tell Kubernetes how to start the bot is reproduced below. This deployment is launched using a stashbot.sh
wrapper script which runs kubectl create -f /data/project/stashbot/etc/deployment.yaml
.
/data/project/stashbot/etc/deployment.yaml (copied 2017-05-15) |
---|
The following content has been placed in a collapsed box for improved usability. |
---
# Run stashbot on kubernetes
kind: Deployment
apiVersion: extensions/v1beta1
metadata:
name: stashbot.bot
namespace: stashbot
spec:
replicas: 1
template:
metadata:
labels:
name: stashbot.bot
spec:
containers:
- name: bot
image: docker-registry.tools.wmflabs.org/toollabs-python2-base:latest
command: [ "/data/project/stashbot/bin/stashbot.sh", "run" ]
workingDir: /data/project/stashbot
env:
- name: HOME
value: /data/project/stashbot
imagePullPolicy: Always
volumeMounts:
- name: home
mountPath: /data/project/stashbot/
volumes:
- name: home
hostPath:
path: /data/project/stashbot/
|
The above content has been placed in a collapsed box for improved usability. |
This deployment:
- Uses the 'stashbot' namespace that the tool is authorized to control
- Creates a container using the 'latest' version of the 'docker-registry.tools.wmflabs.org/toollabs-python2-base' Docker image.
- Runs the command
/data/project/stashbot/bin/stashbot.sh run
when the container starts. - Mounts the /data/project/stashbot/ NFS directory as /data/project/stashbot/ inside the container.
Monitoring your jobs
You can see which jobs you have running with kubectl get pods
. Using the name of the pod, you can see the logs with kubectl logs <pod-name>
.
To restart a failing pod, use kubectl delete <pod-name>
. If you need to kill it entirely, find the deployment name with kubectl get deployment
, and delete it with kubectl delete deployment <deployment-name>
.
Namespaces
Each tool has been granted control of a Kubernetes "namespace". Your tool can only create and control objects in its namespace. A tool's namespace is the same as the tool's name (e.g. admin
, stashbot
, hay
, etc).
Container images
The Toolforge Kubernetes cluster is restricted to loading Docker images published at docker-registry.tools.wmflabs.org
(see Portal:Toolforge/Admin/Kubernetes#Docker Images for more information). These images are built using the Dockerfiles in the operations/docker-images/toollabs-images git repository.
Available container types
The webservice
command has an optional type argument that allows you to choose which Docker container to run your Tool in.
Currently provided types:
- golang
- jdk8
- nodejs (node.js 6.11)
- node10
- php5.6
- php7.2
- python (python3.4)
- python2
- python3.5
- ruby2
- tcl
For example to start a webservice using a php7.2 container, run:
webservice --backend=kubernetes php7.2 start
A list of images is available in the overview page of the images source code repository for the Toolforge (each folder name represents a Docker image) and via the Docker registry catalog.
As of Feb 2018, we don't support mixed runtime containers. This may change in the future. Also, we don't support "bring your own container" on our kubernetes (yet!). And there is no mechanism for a user to install system packages inside of a container.
PHP
PHP uses lighttpd as a webserver, and looks for files in ~/public_html/
.
PHP versions & packages
There are two versions of PHP available, PHP 7.2 (on Debian Stretch), and the legacy PHP 5.6 (on Debian Jessie).
You can view the installed PHP extensions on the phpinfo tool. This should match the PHP related packages installed on GridEngine exec nodes. Additional packages can be added on request by creating a subtask of T140110.
PHP Upgrade
To upgrade from PHP 5.6 to PHP 7, run the following two commands:
$ webservice stop
$ webservice --backend=kubernetes php7.2 start
To switch back:
$ webservice stop
$ webservice --backend=kubernetes php5.6 start
Running Locally
You may run the container locally by executing a command like this:
$ docker run --name toolforge -p 8888:80 -v "${PWD}:/var/www/html:cached" -d docker-registry.tools.wmflabs.org/toollabs-php-web sh -c "lighty-enable-mod fastcgi-php && lighttpd -D -f /etc/lighttpd/lighttpd.conf"
Then the tool will be available at http://localhost:8888
Node.js
The container images for Node.js, such as docker-registry.tools.wmflabs.org/toollabs-nodejs-base:latest
currently come with a current version of Node.js LTS from Wikimedia APT (as of September 2018, this is Node.js 6). This is the same version used by Wikimedia Foundation in production and for continuous integration.
Broken npm
Given npm is not suitable for use in Wikimedia production, the version of Node.js provided by Wikimedia APT is compiled without npm. (Unlike the official Node.js distribution.) And because there is no use for npm in Wikimedia production, there is no "npm" Debian package maintained in Wikimedia APT. The result is that the only "npm" Debian package available is the one from upstream Debian, which is npm 1.4 which was originally bundled in 2014 with Node 0.10 (debian/npm, debian/nodejs). This version is EOL and is incompatible with most packages on the npmjs.org registry. To update it within your container, follow these steps
# Step 1: Start a shell in your Node.js pod (see "Shell" section below) tool@tools-login$ kubectl exec -it podname-123-aaa -- /bin/bash # Step 2: Create $HOME/bin and ensure it is in your PATH podname:/data/project/tool$ mkdir bin/ podname:/data/project/tool$ export PATH="${HOME}/bin:${PATH}" # To avoid having to re-export PATH every time you use your tool, add the export command to your .bashrc file! # Step 3: Use npm to install 'npm' podname:/data/project/tool$ npm install npm .... # This installs the current version of npm at node_modules/.bin/npm # Step 4: Create a symlink in $HOME/bin podname:/data/project/tool$ ln -s $HOME/node_modules/.bin/npm $HOME/bin/npm # Close the shell and create a new shell (to initialise PATH) podname:/data/project/tool$ exit tool@tools-login$ kubectl exec -it podname-123-aaa -- /bin/bash podname:/data/project/tool$ # Step 5: Verify that you now use a current npm instead of npm 1.4 podname:/data/project/tool$ npm --version 6.4.1
Shell
To establish a shell inside your Kubernetes pod, run the following two commands from tools-login:
$ kubectl get pods NAME READY STATUS RESTARTS AGE perflogbot-2167463494-5uqkh 1/1 Running 4 6d
Choose the name of the pod you want to start an interactive shell with, and run kubectl exec -it <podname> -- /bin/bash
. For example:
$ kubectl exec -it perflogbot-2167463494-5uqkh -- /bin/bash <flogbot-2167463494-5uqkh:/data/project/perflogbot$
See also Get a Shell to a Running Container at kubernetes.io/docs.
Troubleshooting
If kubectl get pods
fails with error message runtime: failed to create new OS thread (have 12 already; errno=11)
, just use GOMAXPROCS=1 kubectl get pods
.