4 ms·

If anyone is interested in giving k8s a go we've been working on fully supported Kubernetes for Ubuntu: https://www.ubuntu.com/cloud/kubernetes https://www.ubun

by jcastro 10y ago

If anyone is interested in giving k8s a go we've been working on fully supported Kubernetes for Ubuntu: https://www.ubuntu.com/cloud/kubernetes https://www.ubuntu.com/cloud/kubernetes This works on GCE, AWS, Azure, VMWare, bare metal (via MAAS) and LXD containers. We're currently supporting 1.4 but will support 1.5 (and upgrades) in the next week or so. Disclaimer: I'm on the team that works on this.

elcct 10y ago
How do you deal with storage on bare metal?
- marcoceppi 10y ago
  Typically ceph for rbd
- lazypower 10y ago
  As Marco alluded, our only supported storage mechanism to date (Which is represented and managed via the charm) is Ceph backed by RBD storage. We have plans on including other storage vendors and mechanisms, but they aren't on the roadmap for the very near term. If end users start requesting a specific storage solution, it would go in our planning doc and get added to the roadmap. We're quite active with our early adopters that give us feedback and file bugs/requests. To date you could continue to use alternative storage providers such as NFS or Gluster - but we don't have the PV creation+enlistment captured in the charm code just yet, but again, due to priorities. End users pretty much set the priorities for us, and we then circle back with some light weight planning and execution. Hope this helps!
SEJeff 10y ago
What does Canonical work on in upstream Kubernetes? I see hundreds+ of commits from Redhat and CoreOS in Kubernetes and the associated projects? In the main kubernetes git repo, I see 39 non-merge from @canonical commits, 99% of which are under cluster/juju/* and 1 doc fix for juju, so not really a value add to Kubernetes at all. How can I, as someone deploying kubernetes on bare metal, trust you to manage a difficult project when Canonical doesn't seem to contribute much at all to the project or ecosystem? It is great that you're making kubernetes easy to manage and deploy, but other than ease of use (which GKE does an excellent job of as well from the authors of k8s), what is Canonical's actual value add for paying you to manage k8s? Sorry for the terseness, but I'm genuinely curious what value add there is here. As a purely tech focused person, I simply don't see it. Even other firms doing exactly what you do (Apcera) have actual code change commits. I don't see a single one from Canonical that does.
- gkop 10y ago
  In defense of Canonical, it's preferable that an organization leave the code alone rather than influence it for their own benefit. If Canonical is able to offer a useful embellishment upon k8s without changing much k8s code, good for them. (I have no stake in this personally, though I am still a bit spiteful toward Canonical over Unity :p )
- marcoceppi 10y ago
  Unlike other companies, we don't jump in to upstream projects and throw weight around to influence a project to make it more marketable for us. Kubernetes has a vibrant, and powerful core contributor base already. When it makes sense, for any changes we make, we'll be happy to package those back upstream. Primarily, our contributions to Kubernetes is around operations. What happens 1 week, 1 month, 1 year after setting up a cluster. GKE is great, but GKE is Google only. It's not on-prem, it's not cross cloud, and it's not portable. That's important to some people. Our contributions to cluster/juju is the distillation of our operational knowledge in running Kubernetes everywhere. The same upstream k8s, deployed with the same tooling, everywhere. Not all value can be measured in commits :)
  - SEJeff 10y ago
    The way you start this off is a pretty poor response to my original question, whereas the rest is fantastic. It isn't about throwing one's weight around or even making it more marketable, but about improving the product for new use cases (such as Apprenda wanting to better Kubernetes via the on-premise sig). Thanks for your response, I was curious as to the value add and this helps.
    - jcastro 10y ago
      We're participating in the on-prem sig now that it's been acked, along with Apprenda, CoreOS, Mirantis, and I'm sure some others.
    - marcoceppi 10y ago
      Thanks for the feedback, my original sentence may have been a bit hasty, but the core of the message is there. I see Canonical's role as the expediter/server in a kitchen instead of donning another chef hat when dish are piling up to go out. We want to celebrate and get the amazing work of the community into as many hands as possible. We participate in SIGs as well, sig-on-premise being one we co-chair and co-founded. We've planning on helping the project in ways other than code contributions.
AlexGrs 10y ago
Is a something we could use in production ? I am looking for a kubernetes solution on azure: using persistant disk etc.
- lazypower 10y ago
  You certainly could. You'd be incurring another service running on azure to act as the disk broker. A lot of end users prefer to use things like the providers persistent disk and acknowledge the limitations there in (like 16 disk maximum per instance, and heightened costs for having managed storage) But there's nothing stopping you from enlisting Azure PV's as a resource, Ceph managed PV's, and other incantations of durable storage. I only ask that you really consider the cost/benefit of each, and pick what makes the most sense to you. My thoughts would be to use the azure PV disk type, and if that's not dynamic enough to meet your needs, then enlist ceph + large volumes and carve those up into RDB's to share among your workloads. I'm sure there are others with differing opinions, and I'm happy to help you work through them (but not on a HN comment thread) Seek me out in Slack as @lazypower, or ping me on the Juju IRC channel irc.freenode.net #juju I'm @lazypower there as well. And finally, our juju user mailing list is another great resource for supporting questions like the above: juju@lists.ubuntu.com

by jcastro 10y ago

elcct 10y ago

How do you deal with storage on bare metal?

marcoceppi 10y ago
Typically ceph for rbd
lazypower 10y ago
As Marco alluded, our only supported storage mechanism to date (Which is represented and managed via the charm) is Ceph backed by RBD storage. We have plans on including other storage vendors and mechanisms, but they aren't on the roadmap for the very near term. If end users start requesting a specific storage solution, it would go in our planning doc and get added to the roadmap. We're quite active with our early adopters that give us feedback and file bugs/requests. To date you could continue to use alternative storage providers such as NFS or Gluster - but we don't have the PV creation+enlistment captured in the charm code just yet, but again, due to priorities. End users pretty much set the priorities for us, and we then circle back with some light weight planning and execution. Hope this helps!

SEJeff 10y ago

What does Canonical work on in upstream Kubernetes? I see hundreds+ of commits from Redhat and CoreOS in Kubernetes and the associated projects? In the main kubernetes git repo, I see 39 non-merge from @canonical commits, 99% of which are under cluster/juju/* and 1 doc fix for juju, so not really a value add to Kubernetes at all. How can I, as someone deploying kubernetes on bare metal, trust you to manage a difficult project when Canonical doesn't seem to contribute much at all to the project or ecosystem? It is great that you're making kubernetes easy to manage and deploy, but other than ease of use (which GKE does an excellent job of as well from the authors of k8s), what is Canonical's actual value add for paying you to manage k8s? Sorry for the terseness, but I'm genuinely curious what value add there is here. As a purely tech focused person, I simply don't see it. Even other firms doing exactly what you do (Apcera) have actual code change commits. I don't see a single one from Canonical that does.

gkop 10y ago
In defense of Canonical, it's preferable that an organization leave the code alone rather than influence it for their own benefit. If Canonical is able to offer a useful embellishment upon k8s without changing much k8s code, good for them. (I have no stake in this personally, though I am still a bit spiteful toward Canonical over Unity :p )
marcoceppi 10y ago
Unlike other companies, we don't jump in to upstream projects and throw weight around to influence a project to make it more marketable for us. Kubernetes has a vibrant, and powerful core contributor base already. When it makes sense, for any changes we make, we'll be happy to package those back upstream. Primarily, our contributions to Kubernetes is around operations. What happens 1 week, 1 month, 1 year after setting up a cluster. GKE is great, but GKE is Google only. It's not on-prem, it's not cross cloud, and it's not portable. That's important to some people. Our contributions to cluster/juju is the distillation of our operational knowledge in running Kubernetes everywhere. The same upstream k8s, deployed with the same tooling, everywhere. Not all value can be measured in commits :)
- SEJeff 10y ago
  The way you start this off is a pretty poor response to my original question, whereas the rest is fantastic. It isn't about throwing one's weight around or even making it more marketable, but about improving the product for new use cases (such as Apprenda wanting to better Kubernetes via the on-premise sig). Thanks for your response, I was curious as to the value add and this helps.
  - jcastro 10y ago
    We're participating in the on-prem sig now that it's been acked, along with Apprenda, CoreOS, Mirantis, and I'm sure some others.
  - marcoceppi 10y ago
    Thanks for the feedback, my original sentence may have been a bit hasty, but the core of the message is there. I see Canonical's role as the expediter/server in a kitchen instead of donning another chef hat when dish are piling up to go out. We want to celebrate and get the amazing work of the community into as many hands as possible. We participate in SIGs as well, sig-on-premise being one we co-chair and co-founded. We've planning on helping the project in ways other than code contributions.

AlexGrs 10y ago

Is a something we could use in production ? I am looking for a kubernetes solution on azure: using persistant disk etc.

lazypower 10y ago
You certainly could. You'd be incurring another service running on azure to act as the disk broker. A lot of end users prefer to use things like the providers persistent disk and acknowledge the limitations there in (like 16 disk maximum per instance, and heightened costs for having managed storage) But there's nothing stopping you from enlisting Azure PV's as a resource, Ceph managed PV's, and other incantations of durable storage. I only ask that you really consider the cost/benefit of each, and pick what makes the most sense to you. My thoughts would be to use the azure PV disk type, and if that's not dynamic enough to meet your needs, then enlist ceph + large volumes and carve those up into RDB's to share among your workloads. I'm sure there are others with differing opinions, and I'm happy to help you work through them (but not on a HN comment thread) Seek me out in Slack as @lazypower, or ping me on the Juju IRC channel irc.freenode.net #juju I'm @lazypower there as well. And finally, our juju user mailing list is another great resource for supporting questions like the above: juju@lists.ubuntu.com