The radical shift towards DevOps and the continuous everything movement have changed how organizations develop and deploy software. As the consolidation and standardization of continuous integration and continuous delivery (CI/CD) processes and tools occur in the enterprise, a standardized DevOps model helps organizations deliver faster software functionality at a large scale.
Starting this week, we will do a series of four blogposts on the intersection of Spark with Kubernetes. The first blog post will delve into the reasons why both platforms should be integrated. The second will deep-dive into Spark/K8s integration. The third will discuss usecases for Serverless and Big Data Analytics. The last post will round off with insights on best practices.
Kubernetes is the de facto open source container orchestration tool for enterprises. It provides application deployment, scaling, container management, and other capabilities, and it enables enterprises to optimize hardware resource utilization and increase production uptime through fault-tolerant functionality at speed. The project was initially developed by Google, which donated the project to the Cloud-Native Computing Foundation. In 2018, it became the first CNCF project to graduate.
This is a guest post written by Appranix. Now that Red Hat OpenShift 4 has officially been released, it’s time to start thinking about migration from Red Hat OpenShift Container Platform 3 to OpenShift Container Platform 4. You can check out the details about the differences between OpenShift 3 and 4 here. One of the biggest differences between OpenShift 3 and 4 is how OpenShift 4 clusters operate using immutable and automated infrastructure enabled by RHEL CoreOS and automation.
Service mesh provides a dedicated network for service-to-service communication in a transparent way. Istio aims to help developers and operators address service mesh features such as dynamic service discovery, mutual transport layer security (TLS), circuit breakers, rate limiting, and tracing. Jaeger with Istio augments monitoring and tracing of cloud-native apps on a distributed networking system.
Two years ago, Pusher started building an internal Kubernetes based platform. As we transitioned from a single product to multiproduct company, we wanted to help our product teams spend less time worrying about shared concerns such as infrastructure and be able to focus more on writing business logic for our products. Over this period, our platform team have solved many of the problems that Kubernetes doesn’t solve out of the box. Until recently, we had not solved the problem of configuration.
We are very excited to announce Calico v3.8. Here are some highlights from the release. You can now view IP address usage for each IP pool using calicoctl. This allows you to more easily manage the IP space in your cluster, providing a simple way to see which IP pools have addresses available and which are running low. See the calicoctl reference documentation for more detailed information on how to use this feature.
This article originated from http://leebriggs.co.uk///blog/2018/11/07/kr8-kubernetes-config-mgmt.html Previous visitors to this blog will remember I wrote about configuration mgmt for Kubernetes clusters, and how the space was lacking. For those not familiar, the problem statement is this: it’s really hard to maintain and manage configuration for components of multiple Kubernetes clusters.
One of these problems is that Kubernetes has no login process. Ordinarily, the client software would initiate this login flow, but kubectl does not have this built in. Kubernetes leaves it up to you to design the login experience. In this post, I will explain the journey we took to get engineers logged in from the terminal and the challenges we faced along the way. The first step to SSO was to set up Dex as our Identity Provider.
Early adopter enterprises across verticals such as Retail, Manufacturing, Oil & Gas are looking to incorporate containers and Kubernetes as a way of modernizing their applications. Choosing k8s as a standard ensures that these applications can be deployed these on different data center infrastructures (bare metal/VMware/KVM on OpenStack etc) or on public clouds (AWS/Azure/GCP etc).
