Support upgrading to protobuf

[smarterclayton]

Starting with 1.3, it will be possible to use protobuf for internal communications between node, masters, and controllers. To configure this, the following stanzas need to be altered in the following configurations:

# master-config.yaml:

masterClients:
  externalKubernetesClientConnectionOverrides:
    acceptContentTypes: application/vnd.kubernetes.protobuf,application/json
    contentType: application/vnd.kubernetes.protobuf
    burst: 400
    ops: 200
  externalKubernetesKubeConfig: ""
  openshiftLoopbackClientConnectionOverrides:
    acceptContentTypes: application/vnd.kubernetes.protobuf,application/json
    contentType: application/vnd.kubernetes.protobuf
    burst: 600
    ops: 300
  openshiftLoopbackKubeConfig: openshift-master.kubeconfig

# node-config.yaml:

masterClientConnectionOverrides:
  acceptContentTypes: application/vnd.kubernetes.protobuf,application/json
  contentType: application/vnd.kubernetes.protobuf
  burst: 40
  ops: 20

Note that if you run create-nodeconfig or create a master config directly, you will get these stanzas set automatically. However, existing clusters must be upgraded.

If you try to upgrade these at the same time as rolling out 1.3 code, you will need to do the following:

1. Update the masters to have new code
2. Update clients:
   1. Update the controllers and change their config
   2. Update the nodes and change their config

Otherwise, you can make these changes after all components are running 1.3.

[smarterclayton]

@timothysc @jeremyeder

[smarterclayton]

From trello card https://trello.com/c/vFxMon41/768-turn-on-protobuf-for-server-to-server-communication-in-origin-and-kubernetes

[timothysc]

@smarterclayton Is this going out dev-preview (default off), or defaulting on?

/cc @mffiedler

[detiber]

@dgoodwin We need to add this by default for 1.3/3.3 installs and also need to enable it on the upgrade, which will require using the yaml module that @abutcher created.

[sdodson]

@smarterclayton Just to be clear, you expect this to be the default for 3.3 installations? At first you say it's possible, but then you say that new node config will get it by default. A newly created node that has protobuf enabled speaking to an API server that doesn't have it enabled will fail?

[dgoodwin]

@detiber comparing the above to our templates it looks like we're just adding in new sections and properties. Is this just a matter of modifying template, conditionally including new sections if release is > 1.3 or 3.3? or am I missing something? That would cover new 3.3 installs as well as upgrade as far as I can see.

[smarterclayton]

A newly created node that has protobuf enabled speaking to an API server
that is 1.2 will fail. Enablement just tells clients to use it.

Using protobuf (on) should be default for all 3.3+ clusters.

On Wed, Jul 27, 2016 at 1:30 PM, Devan Goodwin notifications@github.com
wrote:

@detiber https://github.com/detiber comparing the above to our
templates it looks like we're just adding in new sections and properties.
Is this just a matter of modifying template, conditionally including new
sections if release is > 1.3 or 3.3? or am I missing something? That would
cover new 3.3 installs as well as upgrade as far as I can see.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#2214 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABG_p8esxfqjk69G5Ljl7fCCMgmzkTbqks5qZ5WngaJpZM4JUZ8Q
.

[dgoodwin]

Upgrade playbooks handle all masters first, and then each node serially, so I think this should roll out ok per the above.

[dgoodwin]

@detiber possibly disregard the above, I think the answer came to me in the night in a vision. We don't run master/node roles on upgrade, so the config file is not managed in that regard then. I'm guessing that's why we need the yaml module to ensure the values are set.