3 ms·

Would anybody like to shed some light about how openshift origin relates to K8S in general? I would like to better understand which path to follow. Which advant

Would anybody like to shed some light about how openshift origin relates to K8S in general? I would like to better understand which path to follow. Which advantages has openshift origin over "pure" K8S? Thanks!

gtirloni 10y ago
You may want to check the section "Kubernetes is not": https://github.com/kubernetes/kubernetes/blob/release-1.4/docs/whatisk8s.md https://github.com/kubernetes/kubernetes/blob/release-1.4/do...
pat2man 10y ago
OpenShift adds a lot of features around building applications from source and authoring those applications as pods in Kubernetes. If you already have a build pipeline set up you may want to stick with pure Kubernetes. They also have an ansible based installation process that makes your cluster a lot more production ready than the basic Kubernetes scripts. For me OpenShift is comparable to Heroku or Elastic Beanstalk where developers can deploy applications from source without knowing a lot about the underlying infrastructure. Of course you still need an ops team to manage OpenShift.
- smarterclayton 10y ago
  Another significant scenario is tenancy - if you are just using Kube for a single team / set of apps, most of the security and policy in OpenShift isn't useful for you. But if you want to share access to that cluster, the security and policy and integrated rbac can allow many teams to collaborate on their own applications and self-service. So platform for others vs platform for ops. (I work on OpenShift and Kubernetes)
  - SEJeff 10y ago
    Isn't much / most of that RBAC upstream in k8s 1.3 (code from Openshift written by redhat engineers like yourself)? What is still in Openshift related to AAA that isn't upstream now?
    - smarterclayton 10y ago
      Still a fair amount of the glue and interspersed code that wires it together sits outside, plus the user management code (user, group, identity integration to all the various providers). Also all the out of the box default security. Part of the benefit of being slightly apart from Kube initially (which we did because we had way too many things we wanted to bring together to put into Kube at the time) is that we could be opinionated and say things like: * every component will use client cert + TLS + specific authorization roles to interconnect * no ability to configure the cluster without those on * default to secure by default, be opinionated about authz/n * lock down everything that could be abused (like letting end users change ingress IPs on services, or direct volume mounting) * make namespaces the unit of tenancy and restrict regular users from modifying most things in namespaces that impact policy The raw pieces are in Kube now, but effecting the same opinionated defaults while still preserving the flexibility many in the community want (like direct Keystone integration, or no restrictions on pods by default) will take some time. Our goal is to get there in a way that also makes Kube more extensible and flexible - I don't believe everyone needs everything we believe in, but by doing it in pieces we do get to ensure it's possible for someone else to do it.
      - SEJeff 10y ago
        Nice! Well I'm a huge fan and follower of your work, so do please keep it up. I appreciate your willingness to eradicate ignorance (mine!).

gtirloni 10y ago

You may want to check the section "Kubernetes is not": https://github.com/kubernetes/kubernetes/blob/release-1.4/docs/whatisk8s.md https://github.com/kubernetes/kubernetes/blob/release-1.4/do...

pat2man 10y ago

OpenShift adds a lot of features around building applications from source and authoring those applications as pods in Kubernetes. If you already have a build pipeline set up you may want to stick with pure Kubernetes. They also have an ansible based installation process that makes your cluster a lot more production ready than the basic Kubernetes scripts. For me OpenShift is comparable to Heroku or Elastic Beanstalk where developers can deploy applications from source without knowing a lot about the underlying infrastructure. Of course you still need an ops team to manage OpenShift.

smarterclayton 10y ago
Another significant scenario is tenancy - if you are just using Kube for a single team / set of apps, most of the security and policy in OpenShift isn't useful for you. But if you want to share access to that cluster, the security and policy and integrated rbac can allow many teams to collaborate on their own applications and self-service. So platform for others vs platform for ops. (I work on OpenShift and Kubernetes)
- SEJeff 10y ago
  Isn't much / most of that RBAC upstream in k8s 1.3 (code from Openshift written by redhat engineers like yourself)? What is still in Openshift related to AAA that isn't upstream now?
  - smarterclayton 10y ago
    Still a fair amount of the glue and interspersed code that wires it together sits outside, plus the user management code (user, group, identity integration to all the various providers). Also all the out of the box default security. Part of the benefit of being slightly apart from Kube initially (which we did because we had way too many things we wanted to bring together to put into Kube at the time) is that we could be opinionated and say things like: * every component will use client cert + TLS + specific authorization roles to interconnect * no ability to configure the cluster without those on * default to secure by default, be opinionated about authz/n * lock down everything that could be abused (like letting end users change ingress IPs on services, or direct volume mounting) * make namespaces the unit of tenancy and restrict regular users from modifying most things in namespaces that impact policy The raw pieces are in Kube now, but effecting the same opinionated defaults while still preserving the flexibility many in the community want (like direct Keystone integration, or no restrictions on pods by default) will take some time. Our goal is to get there in a way that also makes Kube more extensible and flexible - I don't believe everyone needs everything we believe in, but by doing it in pieces we do get to ensure it's possible for someone else to do it.
    - SEJeff 10y ago
      Nice! Well I'm a huge fan and follower of your work, so do please keep it up. I appreciate your willingness to eradicate ignorance (mine!).