Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Has anyone tried this admission controller with success? #2

Open
filmil opened this issue Sep 26, 2017 · 9 comments
Open

Has anyone tried this admission controller with success? #2

filmil opened this issue Sep 26, 2017 · 9 comments

Comments

@filmil
Copy link

filmil commented Sep 26, 2017

The issue I'm having with it is that it installs the admission controller service with a fixed clusterIP: 10.0.0.231. In the webhook code, the address resolver will resolve the webhook to https://10.0.0.231:443. But, this IP address is not accessible to the API server, so I don't see a request to this URL succeeding. How is this supposed to work?

@caesarxuchao
Copy link
Owner

I'll update the example this week. The problem you saw is due to a recent change in the upstream: kubernetes/kubernetes#50476.

@caesarxuchao
Copy link
Owner

Try again? You need to use it with the latest Kubernetes release (v1.8.0 or v1.9.0-alpha.1)

@patrickshan
Copy link

Just tested with this example and it works with Kubernetes v1.8.0 after some small changes for the ExternalAdmissionHookConfiguration config which I put it into a PR. My test also disabled client cert verification as described in README.

@caesarxuchao
Copy link
Owner

Merged the PR. Thanks.

@patrickshan
Copy link

@caesarxuchao will apiserver send the whole pod object to webhook admission controller in this example ? I am trying to parse some data inside pod.Annotations which seems to be always empty. I suspected it was sent through by different operation. But it behaves the same even if I turned on all operations "*" related with pods resource. Is this something expected ?

@caesarxuchao
Copy link
Owner

caesarxuchao commented Oct 16, 2017

What annotations specifically? I have some hypothesis but need to know the specific fields.

@patrickshan
Copy link

patrickshan commented Oct 16, 2017

It's just a self-defined pod annotation included inside deployment, like this one:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  namespace: kube-system
  name: toolbox
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: debian-test
      annotations:
        kitt.com/department: "INF"
    spec:
      containers:
      - name: debian-test
        image: debian
        command:
          - sleep
          - infinity

In theory it should creat a pod with kitt.com/department: INF annotation like this:

$ kubectl get pod toolbox-594df444bc-dhwkg -o yaml
apiVersion: v1
kind: Pod
metadata:
  annotations:
    kitt.com/department: INF

@caesarxuchao
Copy link
Owner

It's caused by the mismatching object version: the apiserver encodes the pod as api.Pod, and the webhook decodes the pod as v1.Pod. The issue will be fixed by the beta version webhook, the apiserver will encode v1.pod. See kubernetes/kubernetes#49733

For workaround, you can get the annotations by parsing the ar.Spec.Object.Raw directly, the metadata is lost later during the decoding.

@patrickshan
Copy link

Thanks @caesarxuchao for looking into this. I'll try the workaround for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants