Kubernetes: Planned Changes / Deprecation / Replacement about drone-runtime HOT 10 CLOSED

closing this issue. old kubernetes runner scrapped. new kubernetes runner moved to drone-runners/drone-runner-kube.

from drone-runtime.

@tboerger perhaps we should just close this and let the community create kubernetes runners using our custom runner definitions and our runner framework? Is there any reason to provide an official Drone kubernetes runner? So far we seem to lack consensus on how to design and build a kubernetes runner, which perhaps means we are not ready to have an official implementation.

from drone-runtime.

example that shows all supported fields:

kind: pipeline
type: kubernetes
name: default

metadata:
  namespace: default
  labels:
    key1: value1
    key2: value2
  annotations:
    key1: value1
    key2: value2

steps:
- jobs:
  - name: build
    image: golang
    privileged: false
    pull: if-not-exists
    failure: ignore
    user: root
    commands:
    - go build
    - go test
  services:
  - name: redis
    image: redis
    environment:
      KEY1: value1
    entrypoint: [ /bin/redis ]
    command: [ --some-flag ]
    working_dir: /tmp
    devices:
    - name: data
      path: /dev/xda1
    mounts:
    - path: /test-ebs
      name: test-volume
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
  when:
    branch:
    - master
    - develop

- jobs:
  - name: test
    image: golang
    commands:
    - go build
    - go test

volumes:
- name: test-volume
  aws_elastic_block_store:
      volume_id: <volume-id>
      fs_type: ext4

node_selector:
  key1: value1
  key2: value2

tolerations:
- key: "key"
  operator: "Equal"
  value: "value"
  effect: "NoSchedule"

image_pull_secrets:
- secret1

questions are

1. how to handle secrets? how to differentiate between drone secrets and kubernetes secrets?
2. how to ensure the pipeline is scheduled to run on a machine with enough resources

from drone-runtime.

Regarding question 2, in my ideal world I would actually not need to guarantee that a whole pipeline runs on a single machine. I'd rather let kube figure out where to schedule pods for me based on their own resource constraints and the resources available which is one area where kube really shines. This would allow me to efficiently schedule even very large pipelines across whatever spare resources are available.

from drone-runtime.

@stevecrozz this kind of scheduling requires also some other things, like readwritemany volumes. Maybe this should be a config option for the server as not all clusters provide these storage classes.

from drone-runtime.

@tboerger why does I need a readwritemany volume? currently considering a pipeline with multiple jobs/services
currently postgres or redis does not need to run on the same node as the rest of the job and also multiple jobs don't need the same storage.

so consider the following:

• job1
• job2
• redis
• postgres

all 4 resources could run on another maschine if done correctly. (btw. gitlab-ci won't do this)

in gitlab-ci considering:

• job1 + redis
• job2 + postgres

only job1+redis / job2+postgres can on different nodes since they are a pod. but thats only a limitation since you should call your services with localhost and not with a service. if a good service handling is created one could easily use that.

from drone-runtime.

I'm not sure there's no reason to provide an official kube runner, but there are competing priorities and as much as I love kube, it would be a bummer to see precious core maintainer resources spent on maintaining a runner for every process scheduler under the sun. So I tend to agree.

from drone-runtime.

closing this issue. old kubernetes runner scrapped. new kubernetes runner moved here:
#69

Your comment points to this issue itself. Is that intentional? 😕

from drone-runtime.

oops, wrong link. the new kubernetes runner can be found here:
https://github.com/drone-runners/drone-runner-kube

documentation should be live some time tomorrow at docs.drone.io. They syntax is very close to the docker runner syntax, with the exception that you have to specify type: kubernetes. There are also some minor behavior differences. The most notable is that services are available at localhost instead of a custom hostname.

For example:

kind: pipeline
type: kubernetes
name: default

clone:
  disable: true

steps:
- name: test
  pull: if-not-exists
  image: redis
  commands:
  - sleep 5
  - redis-cli -h localhost ping
  - redis-cli -h localhost set FOO bar
  - redis-cli -h localhost get FOO

services:
- name: redis
  pull: if-not-exists
  image: redis

from drone-runtime.

link to first-draft of kubernetes runner documentation:
https://kube-runner.docs.drone.io/

from drone-runtime.