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

fix(kubernetes): remove usage of deprecated API endpoints, v1beta #6543

Merged
merged 1 commit into from
Oct 23, 2019

Conversation

rawkode
Copy link
Contributor

@rawkode rawkode commented Oct 18, 2019

Required for all PRs:

  • Signed CLA.
  • Associated README.md updated.
  • Has appropriate unit tests.

Closes #6542

@rawkode rawkode force-pushed the bugfix/kube_inventory branch 2 times, most recently from 011bccd to afa81c1 Compare October 18, 2019 14:08
Copy link
Contributor

@goller goller left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks !

@danielnelson
Copy link
Contributor

Based on your comments on the issue then this would break compatibility with k8s <1.9, is the 1.8 version something that was previously supported by this plugin? If so, we probably need to add an option to opt into this change. Either way we should document the first version this plugin supports. Were these new APIs also added in 1.9?

@danielnelson danielnelson added area/k8s feat Improvement on an existing feature such as adding a new setting/mode to an existing plugin labels Oct 18, 2019
@rawkode
Copy link
Contributor Author

rawkode commented Oct 18, 2019

1.8 has been EOL for a year. Of course, that doesn't mean people aren't still on it.

These changes will break for <= 1.8

We could check the API version and act accordingly, but I'd be worried about how long that code would be there and how many code paths we'll have after another year of Kubernetes releases (minor release every 16 weeks)

What do you think is best?

@danielnelson
Copy link
Contributor

If it used to work, but now it doesn't, we ought to keep it around. Unless we have a strong belief that no one is using it with 1.8 or older. When was 1.9 released?

Either way I'd really like to set the bar with a minimum supported version in the documentation.

@rawkode
Copy link
Contributor Author

rawkode commented Oct 18, 2019

1.9 was released December 2017

@danielnelson
Copy link
Contributor

As we discussed offline, let's document in the README (last paragraph of the first section) the minimum version that we are going to support going forward with this plugin. Set it to the oldest version supported by AWS+GCP+Azure, we can use the new API from this PR without keeping around the legacy support.

@rawkode
Copy link
Contributor Author

rawkode commented Oct 22, 2019

TL;DR

No major cloud provider allows for a version that wouldn't include support for the v1 APIs


AWS

Q: Which Kubernetes versions does Amazon EKS support?

A: Amazon EKS supports Kubernetes version 1.11, 1.12, 1.13, and 1.14 and will continue to add support for additional Kubernetes versions in the future.


GKE

gcloud container get-server-config --zone us-west2

While worker versions can use from >= 1.6.13, master nodes (which the API Server runs on) only supports >= 1.12.10

validMasterVersions:
- 1.14.7-gke.10
- 1.14.6-gke.13
- 1.14.6-gke.2
- 1.14.6-gke.1
- 1.13.11-gke.5
- 1.13.10-gke.7
- 1.13.10-gke.0
- 1.13.9-gke.11
- 1.13.9-gke.3
- 1.13.7-gke.24
- 1.12.10-gke.15

AKS

Azure supports 4 minor versions, which means >= 1.13.0

@rawkode
Copy link
Contributor Author

rawkode commented Oct 22, 2019

@danielnelson Updated. Please let me know if this is what you had in mind, or if you'd like further changes. Thanks for your continued assistance 👍

@danielnelson
Copy link
Contributor

So let's say 1.11 is the first version we will support. Can you verify your changes are working with 1.11 then and add a paragraph to the readme:

This plugin supports Kubernetes 1.11 and later.

@rawkode
Copy link
Contributor Author

rawkode commented Oct 22, 2019

Confirmed working. Steps to reproduce:

Get a Kubernetes 1.11 cluster

minikube start --vm-driver=kvm2 --kubernetes-version=v1.11.0

Save Dockerfile to Telegraf local clone:

#Dockerfile
FROM ubuntu:18.10
COPY ./telegraf /bin/telegraf

ENTRYPOINT ["/bin/telegraf"]

Build custom Telegraf from branch:

eval $(minikube docker-env)
# This builds it within your minikube cluster
docker image build -t telegraf:kube111 .

Deploy Telegrafs

git clone https://github.com/rawkode/influxdb-examples
cd influxdb-examples/kubernetes

# YOU NEED TO UPDATE ALL THE `telegraf.yaml` FILES TO USE `image: telegraf:kube111` AND ADD `imagePullPolicy: IfNotPresent` to the line after each

make

Check it's working:

kubectl port-forward -n monitoring svc/influxdb 9999:9999

Browsing to http://localhost:9999 and you should be able to explore metrics for apps/v1 resources, such as statefulsets, deployments, and daemonsets

@rawkode
Copy link
Contributor Author

rawkode commented Oct 22, 2019

This plugin supports Kubernetes 1.11 and later.

Added to both README.md's

@danielnelson danielnelson added this to the 1.13.0 milestone Oct 23, 2019
@danielnelson danielnelson merged commit 47a708e into influxdata:master Oct 23, 2019
@rawkode rawkode deleted the bugfix/kube_inventory branch October 23, 2019 22:42
athoune pushed a commit to bearstech/telegraf that referenced this pull request Apr 17, 2020
idohalevi pushed a commit to idohalevi/telegraf that referenced this pull request Sep 29, 2020
arstercz pushed a commit to arstercz/telegraf that referenced this pull request Mar 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/k8s feat Improvement on an existing feature such as adding a new setting/mode to an existing plugin
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Kubernetes 1.16 v1beta1 Removed
3 participants