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

K3sContainer: expose kubeConfig for docker network access #5097

Merged

Conversation

johnathana
Copy link
Contributor

The getKubeConfigYaml method has been extended to expose the kubeConfig with a k3s container network alias as server URL. This would enable Kubernetes cluster access from other containers in the docker network.

@kiview
Copy link
Member

kiview commented Feb 21, 2022

Thanks for providing the PR @johnathana. Besides the comment, it looks good to me, but we need someone with more k3s experience (such as @rnorth) to have another look 🙂.

@@ -47,8 +49,8 @@ public K3sContainer(DockerImageName dockerImageName) {
}

@SneakyThrows
@Override
protected void containerIsStarted(InspectContainerResponse containerInfo) {
public String getKubeConfigYaml(String networkAlias) {
Copy link
Member

Choose a reason for hiding this comment

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

To avoid confusion, IMO we should rename this method to something that will tell that the returned config is for internal communication, as otherwise someone may call getKubeConfigYaml("k3s") and then expect it to work from their machine (in addition to in-network usage)

Copy link
Member

Choose a reason for hiding this comment

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

Yeah, my main thought with this PR is the risk of user confusion. This will be, I think, the first time in a module that we're outputting an address which is specifically not usable by the test host machine itself.

I think we need this method to be named to reflect that this returns a kubeconfig that is for use inside of the docker network.

We should also enhance the documentation here - both Javadocs and the md docs, so that people can understand when to use this. As @bsideup suggested, including the test into the docs would be a good way to demonstrate it.

Copy link
Member

Choose a reason for hiding this comment

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

@rnorth BTW how do you feel about changing from containerIsStarted to "get file every time"? IMO getKubeConfigYaml should return pre-calculated value from containerIsStarted, while generateInternalKubeConfigYaml (or whatever the name is) can do it on demand (or maybe from the same file, just by changing the host)

Copy link
Member

Choose a reason for hiding this comment

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

I agree that getKubeConfigYaml being a side-effect-free simple getter would feel better and be the more intuitive API.

Copy link
Member

Choose a reason for hiding this comment

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

Yeah, I think it would be nicer to keep the fetch of the kubeconfig file in containerIsStarted. It would make it clearer that the file is effectively immutable rather than something that k3s might be changing over time.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I have updated the code. The documentation part is missing, I will include it on another commit.

Copy link
Member

@rnorth rnorth left a comment

Choose a reason for hiding this comment

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

This is a nice PR - have just suggested a couple of trivial wording tweaks but am otherwise pretty happy with it.

Copy link
Member

@bsideup bsideup left a comment

Choose a reason for hiding this comment

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

👍

@bsideup bsideup requested a review from a team as a code owner May 17, 2022 23:14
@bsideup bsideup added this to the next milestone May 17, 2022
@kiview kiview merged commit 5533447 into testcontainers:master May 18, 2022
@kiview
Copy link
Member

kiview commented May 18, 2022

Merged, thanks a lot for your contribution @johnathana 🙌

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

Successfully merging this pull request may close these issues.

None yet

5 participants