Container Storage Preferences for Kubernetes – InApps is an article under the topic Devops Many of you are most interested in today !! Today, let’s InApps.net learn Container Storage Preferences for Kubernetes – InApps in today’s post !
Read more about Container Storage Preferences for Kubernetes – InApps at Wikipedia
You can find content about Container Storage Preferences for Kubernetes – InApps from the Wikipedia website
The types of logical storage structures used in today’s Kubernetes deployments offer some deeper revelations into the nature of workloads being deployed. Block storage is king, having been cited by two-thirds (66 percent) of respondents in our survey for The State of the Kubernetes Ecosystem as being involved with their Kubernetes implementations.
Few deployments are relegated to only one type of logical storage, so it is telling that just fewer than half of the respondents (46 percent) cited file storage as the type they’re using. Newer, cloud-native applications with microservices architectures and that utilize databases or data structures, typically don’t need a file system because they are not interacting with data through an operating system. A 46 percent figure is quite high, signaling that more integration with older application types is taking place.
Object storage is used by 29 percent of respondents, which is relatively high compared with adoption rates for object storage that we’ve seen in the past. Since object storage is scalable, developers working on distributed systems likely have experience with it already. In addition, object storage is often used to deliver static content for websites, which is also a common type of workload for Kubernetes.
Providers of Logical Storage Services
We gave respondents a list of specific logical storage system brands, projects and technologies, and asked them to cite any and all that their Kubernetes deployments utilize. We also gave them an opportunity to write in alternatives that we did not list. Some of these are commercial products or services, while others are open source projects.
Partly due to its strong position in the cloud market, Amazon Elastic Block Storage was cited by half (a full 50 percent) of our survey respondents among all Kubernetes implementations. Admittedly, Google’s position of respect among early Kubernetes adopters may have played a greater persuasive role, compared to its own market share in the cloud space, driving the high percentage of respondents (30 percent) who cited GCE Persistent Disk. So these results are not an indicator that, for instance, Google has three-fifths of Amazon’s share.
Another indicator of this probable tilt in Google’s favor among our group is the fact that only six percent of respondents cited using Microsoft Azure-branded logical storage. So Microsoft’s cloud market share was evidently under-represented here. The likely reason is that Kubernetes only became an official Microsoft offering in February 2017. As its Azure Stack becomes more widely available, its customers should have more storage options available to them besides just Azure. As a result, we expect Azure developers will be more likely than customers of other clouds to utilize storage they purchased directly from a source other than a major cloud service provider.
Since cluster operators often belong to IT operations teams, it would logically follow that they would be more likely to use internal storage resources. At least among our survey participants, this isn’t the case. Some 59 percent of cluster operators use AWS storage, but only 43 percent of application operators (DevOps) do the same. Perhaps using the AWS cloud lets SREs focus on infrastructure monitoring, rather than suffer the constant headaches associated with managing hardware.
Many respondents said they used a specific file-based storage system, with NFS being cited most often (30 percent), followed by GlusterFS (16 percent) and CephFS (14 percent). However, the latter two were cited more often by vendors. Omitting these vendors, we’re left with only nine percent of the remainder using GlusterFS, and eight percent using CephFS. Quite likely, many of these vendor respondents are employed by Red Hat (which utilizes all three of these systems) or one of its many partners. This would be in accordance with a trend we’ve seen before where OpenStack vendors have adopted Red Hat-backed storage standards more than others.
Container-specific storage solutions were seldom cited. Perhaps as more persistent workloads move to containers, demand for specialized storage options may increase. Another possibility has to do with convenience. Users may prefer the storage they already know or the storage that’s easiest for them to access. The latter explanation would not portend well for the startups that follow in the footsteps of now-defunct ClusterHQ.
Will AWS Benefit?
We gave survey participants a list of seven container platforms, plus a No Choice option, and asked them to choose any and all that their organizations are presently evaluating, and also that they’re currently using. We saw an interesting set of results among the subset of respondents who had also indicated they were using Amazon AWS storage services in conjunction with their Kubernetes deployments.
Among the Kubernetes evaluators who responded to our survey, nearly three respondents in four (73 percent) who use AWS storage with Kubernetes gave Amazon EC2 Container Service some consideration. The high level of consideration is mostly because of AWS’s overall Infrastructure as a Service (IaaS) market share. However, very few of these people (18 percent) actually ended up using ECS.
Looking into the future, InApps will continue to monitor the uptake of container-related storage solutions. Maybe the problem of persistent storage for containers will be addressed. The alternative may be that existing storage approach will persevere.
See our new eBook, The State of the Kubernetes Ecosystem, for more information.
Google, Microsoft, the OpenStack Foundation and Red Hat are sponsors of InApps.
Feature image by Max Lakutin on Unsplash.
Let’s create the next big thing together!
Coming together is a beginning. Keeping together is progress. Working together is success.