/assign @Random-Liu
/assign @yujuhong

I think it is OK as a temporary solution.
However, it can not resolve the problem finally if more and more message (size > 16M), and we have to increase it again.

Perhaps, it can have a final solution, like stream output message, result pagination or something else.

@ceshihao it's a WIP to see if this helps this specific scenario that fails, if it does, then we can try to figure out how to turn it into something acceptable

/assign @derekwaynecarr

cc @runcom @sjenning @feiskyer

/retest

/test pull-kubernetes-e2e-gce

I think bumping the limit is reasonable (although maybe we should have a more concrete example to reason able the size).

As for a long-term solution such as pagination, I am not against the idea, but do feel like we need a better justification (e.g., expected #containers and the size of each container) for adding the complexity.

/approve

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: dims, feiskyer, yujuhong

The full list of commands accepted by this bot can be found here.

The pull request process is described here

/test all [submit-queue is verifying that this PR is safe to merge]

Automatic merge from submit-queue. If you want to cherry-pick this change to another branch, please follow the instructions here.

@dims can this be cherry-picked for 1.10 release?

@mkumatag Done!