diff options
3 files changed, 202 insertions, 0 deletions
diff --git a/community/2017-events/12-contributor-summit/cloud-native-design-refactoring-across-k8s.md b/community/2017-events/12-contributor-summit/cloud-native-design-refactoring-across-k8s.md new file mode 100644 index 00000000..66aadf88 --- /dev/null +++ b/community/2017-events/12-contributor-summit/cloud-native-design-refactoring-across-k8s.md @@ -0,0 +1,60 @@ +**Contributor Summit - KubeCon 2017** + +**Cloud Native Design/Refactoring across Kubernetes** + +*Lead: Joe Beda(**[@jbeda](https://twitter.com/jbeda)*)* + +*Co-lead: Amit Kumar Jaiswal(**[@AMIT_GKP](https://twitter.com/AMIT_GKP)*)* + +**Abstract** + +Explore how to cleanly support cloud-native behaviors, such as standardized Kubernetes logs, injectable configuration and common queryable APIs in Kubernetes components. While this discussion isn't only about containers, orchestrating OpenStack deployment/management within Kubernetes via OpenStack-Helm or Kolla-Kubernetes paves the way for better upgrade capabilities. They will also improve the ability to run individual Kubernetes services independently or in combination with other adjacent technologies. + +**Agenda** + +1. Cloud Native Ecosystems + +2. Kubernetes Abstractions & Primitives + +3. Kubernetes Design Patterns + +4. Refactoring across Kubernetes + +5. Benefits of using Kubernetes + +**Issues** + +** **- We’re looking for someone to help us out on issues related to refactoring across Kubernetes like [Issues#51405](https://github.com/kubernetes/kubernetes/issues/51405), [#46735](https://github.com/kubernetes/kubernetes/issues/46735), [#54090](https://github.com/kubernetes/kubernetes/issues/54090), [#55151](https://github.com/kubernetes/kubernetes/issues/55151) + + - Consolidating volume util files like *pkg/volume/util.go, pkg/volume/util/util.go, pkg/volume/util/volumehelper/volumehelper.go *[need better documentation of each file is to emcompass] + + - Enhancing e2e tests to track cloud provider’s API Quotas + + - Like changing fluentd to use CRI log Path and eventually deprecates the old container path + + - Issues with deploying/adopting Kubernetes for specific applications use-cases + +**Questions** + + - Security and granularity across Kubernetes + + - Kube API issues like it should not depend on *--cloud-provider* and *--cloud-config* + + - Helping us out with API documentation and Configuring Best Practices? + + - What are the new tools to deal with testing frameworks for NFV/SDN across Kubernetes? + + - Kubelet Flag subfields precedence v/s files/ConfigMaps to Kubelet Config + + - How to dynamically provision an AWS EBS volume from a snapshot? + + - Work around Object definition in OpenAPI schema like definition of the *PersistentVolumeSpec, PersistenceVolumeClaimSpec* + + - Work around support for FUSE client for K8s cephfs. + + + +**Audience Feedback** + + - + diff --git a/community/2017-events/12-contributor-summit/current-state-of-client-libraries.md b/community/2017-events/12-contributor-summit/current-state-of-client-libraries.md new file mode 100644 index 00000000..c7ac0bad --- /dev/null +++ b/community/2017-events/12-contributor-summit/current-state-of-client-libraries.md @@ -0,0 +1,38 @@ +Story so far is described at https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/csi-client-structure-proposal.md +- linked from https://github.com/kubernetes-client/community/blob/master/design-docs/clients-library-structure.md + +Would like libs to be more "fluent" - should join up with the native language features e.g. JavaDoc, per-platform + +OpenAPI (Swagger) has limitations which force ugly workarounds. + - e.g. doesn't cover returning different types in response to a call e.g. a result or an error. + - OpenAPI 3 fixes a number of these limitations + +Key difficulty is which verbs apply to which objects - Go doesn't natively have this concept. + +OpenAPI doc is produced by running an api-server, which knows how to dispatch verbs to objects, and having it generate the OpenAPI + +Should we deprecate SPDY in favour of websockets? (probably yes) + +What do people want in a client library? + - Go lib smaller than 40MB + - Go lib with dynamic types (this exists?) + - Rust + - C++ + +Are there client libs for things like service catalog? Where do those live? + +How can clients talk protobufs to api-server? Set the content-type. + +K8s protobuf def uses an 'envelope' type covering things like storage version + +Protobuf not self-describing so not great for api-server CRUD operations + +A few bits of extra information in the protobuf definition would be great - e.g. pluralisation + +Client SIG is relatively under-represented and relatively easy to join in - please come along! + +kubeconfig semantics are not standardised - when reimplemented in different languages this can give unexpected results. Example: URL with no scheme supported by Go but not Java + +How should clients deal with rolling authorisation certificates? + +There are type wrinkles, like "intorstring" and "quantity"
\ No newline at end of file diff --git a/community/2017-events/12-contributor-summit/scaling-up-and-scaling-down-and-addon-management.md b/community/2017-events/12-contributor-summit/scaling-up-and-scaling-down-and-addon-management.md new file mode 100644 index 00000000..d7f3e3a0 --- /dev/null +++ b/community/2017-events/12-contributor-summit/scaling-up-and-scaling-down-and-addon-management.md @@ -0,0 +1,104 @@ +# Scaling Up & Scaling Down & Addon Management Session… + +Notes by @justinsb + +## Scaling Up & Scaling Down + +Lots of users that want to run on a single node cluster - one node, one core +thockin’s position: 1 node 1 core should continue to work (with 3.75GB, but ideally less than 2GB) +Works today but only just - e.g. you only have 0.2 cores left today +Addons / core components written with a different target in mind +Some of the choices not optimal for single node (e.g. fluentd / ES) + +Cluster Proportional Autoscaler tries to solve this + Targets a daemonset / deployment and changes number of pods + +CPVPA Cluster Proportional Vertical Pod Autoscaler + Applies a step function based on the number of cluster cores to change the resources needed by a target deployment / daemonset +Prototype being used today in GKE for calico + Needs a pod per target which leads to higher resource usage + Idea: to have a single pod that uses a CRD to amortize the costs across multiple targets + Problems we want to address: + We want more granularity at the low end, both because it matters more proportionately + We want to avoid constant rescaling - changing resources requires restarting pods + +Q (solly): What is missing from kubernetes today - what is different vs generic HPA/VPA? Why can’t I reuse the existing HPA/VPA? How do I tell the difference from a UI perspective? +A (thockin): We could wrap the autoscaler; or we could have a ref pointing back up; or we could integrate back into HPA/VPA. The third option is mostly what we’ve encouraged - where things are proved out of tree and then merged back in. + +Some changes needed in HPA/VPA - pulling in metrics from a different source e.g. number of cores in cluster. (Do we need a “count” API) + +Q (clayton): Does this indicate that requests / limits are “broken”? Should we instead be thinking about e.g. overcommit to deal with smaller sizes. +A (thockin): No - the step function is defined by the author of e.g. kube-dns based on their knowledge of the requirements. And this is typically for “fundamental” components, not user applications, and so the broader question for users is separate. + +Q (gus): We need to consider architectures (e.g. 64 bit might use more memory). Are we wasting more memory running a pod to right-size the other pods? +A (thockin): That’s why we want one pod with a CRD, but yes … we want to fold it back in. but we have to prove it first. + +Q: Why can’t this be done in e.g. kubeadm +A: Because clusters change size - e.g. cluster autoscaler + +Q (jago): Focusing on small clusters - we should come up with clear guidance for resource requirements. Maybe we need T-shirt sizes which helps us figure out what we can run in various clusters. +A (thockin): We need to start collecting data - that’s part of this effort. + +Q (vish): Is kubernetes the right approach for small clusters +A: Yes! Yes! Yes! Lots of resounding yeses - devs want to run on their laptops, people happily run personal clusters on single nodes etc. + +Q (dawn): It is hard to come up with a single scale function - e.g. with docker on the node team the kernel options have a big impact. But we should still provide a scaling function as a guide, and to allow for operators to tweak it + +Q (chrislovecnm): Key point - we must collect data! + +Q: There is a lack of documentation on resource requirements e.g. memory requirements of apiserver at various sizes. + + +## Add-on Management + +It’s been the can that’s been kicked down the road +Questions: + What is an addon? + Kubeadm says kube-dns, kube-proxy + GKE adds dashboard & heapster + +Thockin: Addons are things we manage vs things you manage. We = administrator, you = User + +Luxas: kubeadm installs minimal addons to get conformance to pass + +solly: Important not to conflate addons with discussion of what is core vs not + +Clayton: Is Istio an addon? What if it becomes super-complicated... + +Mrubin: 3 categories of addons: + Istio, Service Catalog, Service Broker + Network policy + Kube-proxy and kube-dns +Sniff test: Does it have to be tied to a version of kubernetes? + +Robertbailey: Maybe addons should be the minimal set of things required to pass conformance + +Chrislovecnm: What’s our goal - we want something to install a manifest on the cluster? + +Clayton: the challenge isn’t installation - it’s upgrades / updates. Are we really ready to manage this? Addons should be things that we can actually manage, including addons. + +Thockin: we want a simple solution, not a full solution for arbitrarily complicated applications. + +Jago: We want a set of components that as a platform operator we install and upgrade/version together and validated together, and cluster-level. This is distinct from user applications or even application etcd. + +Bboreham: cross-grade between alternatives is a related aspect - e.g. swap out implementation of network policy. In practice today you have to reinstall the cluster, because otherwise it requires the network policies to cooperate. + +Clayton: comparison to runlevels - where it’s very possible to brick your cluster by doing things out of sequence. + +Gus: The installation tools do all differ in what addons they are installing (e.g. AWS and GCE have very different requirements). So the installation tool will have opinions here - what value are we adding? + +Thockin: There is an opportunity here to define something cross-cutting - “apt or yum for kubernetes”. Having each installer do something different is not great. + +Clayton: apt or yum doesn’t get you all the way - you still need to tweak configurations. + +Mrubin: Kubernetes is a bunch of small pods cooperating. The mechanism is the same for installing DNS as it is for network policy - which is good in that we have a harmonized approach. We want to figure out the mechanism by which components can be packaged by authors, discovered, and integrated by installers. + +Mrubin: There is a belief that some pods in kube-system are special + +Dawn: The kube-system namespace is known to be system-managed / updated and critical pods - even if it isn’t actually special in a technical sense. + +Jess: We want to avoid decision paralysis. And there’s odd incentives where people want to monetize their code or their approach. We have to limit the scope as much as possible. + +Robertbailey: Agreed - we have to scope this just to the minimal components needed to install stuff. And then users can install more opinionated things like helm. + +Thockin wrapping up: Still an open question of what we should do here, how the various distributions should avoid duplicating effort. |