Request json in one batch

[KnVerey]

What are you trying to accomplish with this PR?

Try to make fetching slightly faster by reducing the number of requests we need to make to get the full result set. Take a look at the tests below--WDYT, does this change make sense?

Also removes the -a option, which is ignored for the json format anyway.

Tests

tl;dr The variance in the numbers across runs is pretty big, but the unlimited chunk size seems to consistently be a bit faster relative to the others requests in the same run.

The first two test below tests invoke kubectl get pods -o json twice per chunk size against a production cluster during a deploy. The average sync cycle time for that cluster is 40s (so faster than I get locally with any chunk size, but still brutal).

       user     system      total        real
Chunk size 100  0.860000   0.700000 203.190000 (176.674929)
Chunk size 500  0.720000   0.580000 176.170000 (138.769829)
Chunk size unlimited  0.700000   0.560000 168.100000 (132.555407)

On this run I did the calls in reverse order in case the stage of the deploy was interfering (reordered for ease of comparison):

       user     system      total        real
Chunk size 100  0.840000   0.700000 204.930000 (168.835286)
Chunk size 500  0.830000   0.690000 197.630000 (157.016152)
Chunk size unlimited  0.720000   0.590000 175.170000 (138.644772)

This run is against a cluster that for some reason has a much faster sync cycle in production (~20s), so I did 4 calls for each chunk size instead of 2:

       user     system      total        real
Chunk size 100  0.810000   0.670000 227.190000 (190.841013)
Chunk size 500  0.910000   0.750000 239.420000 (190.814744)
Chunk size unlimited  0.840000   0.680000 223.620000 (181.785822)

And finally here's a test against a smaller cluster using a larger number of runs (15):

       user     system      total        real
Chunk size 100  1.270000   1.050000 477.290000 (404.358225)
Chunk size 500  1.280000   1.090000 477.840000 (383.099241)
Chunk size unlimited  1.260000   1.050000 478.570000 (391.582564)

How is this accomplished?
Changing an option. The chunking was added to improve perceived latency:

This reduces the perceived latency of managing large clusters since the server returns the first set of results to the client much more quickly. A new flag --chunk-size=SIZE may be used to alter the number of items or disable this feature when 0 is passed

What could go wrong?
Things get slightly slower instead of slightly faster.

[fw42]

👍

I imagine this might come back to bite us in the ass at some point in the future when maybe our JSON is too big to be returned in a single call. I'd also be interested to know why this is taking so long in the first place (maybe something to report back to Google or to try to track down and fix in the kubernetes source code).

[dturn]

[beta] Flag --chunk-size={SIZE} is added to kubectl get to customize the number of results returned in large lists of resources. This reduces the perceived latency of managing large clusters because the server returns the first set of results to the client much more quickly. Pass 0 to disable this feature.(#53768, @smarterclayton) (https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.9.md)

I think this is the right thing to do since we don't want reduce latency to the first byte, but the last. I am slightly concerned its a beta-feature.

[KnVerey]

I am slightly concerned its a beta-feature.

I'm not really concerned about that. The deprecation policy for beta is 9 months / 3 releases. Btw prune is technically still an alpha feature, so that is more concerning (but our tests would 100% for sure notice if it was removed!) 🙈

I'd also be interested to know why this is taking so long in the first place (maybe something to report back to Google or to try to track down and fix in the kubernetes source code).

👍