Feedback on kubernetes support in drone 1.0.0-rc

Drone Support
1

I have some feedback on some aspects of the new kubernetes support. let me know if you want me to create actual issues ( and which repos they should be created in ).

  1. pipeline jobs are created with the default namespace serviceaccount - this means that I have to give the clusteradmin clusterrole (or just a bunch of heightened perms ) to that default serviceaccount. Ideally I’d like to be able to provide an alternative service account that I would have created with the correct permissions that would be used to run the jobs (you would do this in the job’s pod template spec.serviceAccountName. That way I can reduce the footprint of things that get clusteradmin permissions.

  2. the name of the steps in the drone.yaml file become the name of the pods that run those steps, which means the step name needs to match the tight rescriptions k8s has around pod names ( i had a step named “test java” which failed because k8s names can’t have spaces. Ideally you’d name them with a random uuid and put the name of the step in metadata.

  3. Kubernetes runtime options aren’t documented here https://docs.drone.io/server/reference/, only in the few install guides that include kubernetes instructions like github. obvious cantidates are DRONE_KUBERNETES_ENABLED and DRONE_KUBERNETES_NAMESPACE but I’d like to know what other kubernetes options [if any] are configurable.

1 Like
2

Hey Paul, thanks for taking some time to test it out and provide feedback

you can set DRONE_KUBERNETES_SERVICE_ACCOUNT to specify a service account. This is also related to your third feedback item regarding lack of reference documentation for the kubernetes configuration variables. I’ll work on this.

the name of the steps in the drone.yaml file become the name of the pods that run those steps, which means the step name needs to match the tight rescriptions k8s has around pod names

we are tracking this at kubernetes/linting: Enforce naming conventions for objects · Issue #12 · drone/drone-yaml · GitHub

3

This is great! thanks for the quick reply. I’ve got a [mostly working] update for the drone helm charts for v1 based on this.

https://github.com/helm/charts/pull/10614

4

I’m getting similar behavior using drone 1-rc.4 in kubernetes. I’ve created my service in namespace ‘drone’ and when drone starts a build job I get an error "jobs.batch is forbidden: User "system:serviceaccount:drone:default" cannot create jobs.batch in the namespace "drone"" . I’ve tried using DRONE_KUBERNETES_SERVICE_ACCOUNT=drone, but it still used the default account.

5

I believe the service account that drone itself is running as creates the jobs, so you need to make sure that service account has access to create jobs.

Here’s what I have (i don’t think the deployments rule is actually needed though):

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  creationTimestamp: 2019-01-14T16:20:46Z
  labels:
    app: drone
    chart: drone-2.0.0-rc.1
    heritage: Tiller
    release: drone
  name: drone-drone
  namespace: cicd-drone
  resourceVersion: "6187488"
  selfLink: /apis/rbac.authorization.k8s.io/v1/namespaces/cicd-drone/roles/drone-drone
  uid: 58d72b38-1818-11e9-8003-42010a000b0a
rules:
- apiGroups:
  - batch
  resources:
  - jobs
  verbs:
  - '*'
- apiGroups:
  - extensions
  resources:
  - deployments
  verbs:
  - get
  - list
  - patch
  - update
6

Hi! I’d like the jobs that drone creates to be able to hit the kubernetes apiserver, I’ve set DRONE_KUBERNETES_SERVICE_ACCOUNT but the jobs that get spun up aren’t using this service account, only the drone/controller pod. AFAIKT that pod doesn’t do a whole lot… am i overlooking something?