{"id":11860,"date":"2019-03-17T16:09:25","date_gmt":"2019-03-17T16:09:25","guid":{"rendered":"https:\/\/www.appservgrid.com\/paw92\/?p=11860"},"modified":"2019-03-17T16:30:54","modified_gmt":"2019-03-17T16:30:54","slug":"linux-today-7-pieces-of-contrarian-kubernetes-advice","status":"publish","type":"post","link":"https:\/\/www.appservgrid.com\/paw92\/index.php\/2019\/03\/17\/linux-today-7-pieces-of-contrarian-kubernetes-advice\/","title":{"rendered":"Linux Today – 7 pieces of contrarian Kubernetes advice"},"content":{"rendered":"
\n
\n
\n
\n
\n
\"Kubernetes\"<\/figure>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n
<\/div>\n
\n
\n
\n
\n
\n
\n

You can find many great resources for\u00a0getting smarter about Kubernetes<\/a>\u00a0out there. (Ahem, we\u2019ve written\u00a0a few\u00a0<\/a>ourselves.)<\/p>\n

That\u2019s good news for IT teams and professionals looking to boost their knowledge and consider how\u00a0Kubernetes<\/a>\u00a0might solve problems in their organization. The excited chatter about Kubernetes has gotten so loud, however, that it can become difficult to make sense of it all. Moreover, it can be challenging to sort the actual business and technical benefits from the sales pitches.<\/p>\n

[ Need\u00a0to help others understand Kubernetes? Check out our related article,\u00a0<\/b>How to explain Kubernetes in plain English.<\/b><\/a>\u00a0]<\/b><\/p>\n

So we asked several IT leaders and Kubernetes users to share some advice that goes against the grain.<\/p>\n

If you always take conventional wisdom \u2013 or straight-up hype \u2013 at face value, you\u2019re bound to be disappointed at some point. So consider these bits of contrarian thinking as another important dimension of your Kubernetes learning.<\/p>\n

1. Don\u2019t treat Kubernetes as a silver bullet<\/h2>\n

Interest in Kubernetes is astronomical for good reason: It\u2019s a powerful tool when properly used. But if you treat Kubernetes as a cure-all for anything and everything that ails your applications and infrastructure, expect new challenges ahead.<\/p>\n

\u201cKubernetes is not a silver bullet for all solutions,\u201d Raghu Kishore Vempati, principal systems engineer at\u00a0Aricent<\/a>. \u201cUnderstand and use it carefully.\u201d<\/p>\n

Indeed, the spotlight on Kubernetes has grown so bright as to suggest that it\u2019s some kind of IT sorcery: Just put and everything in containers, deploy \u2019em to production, and let Kubernetes handle the rest while you plan your next vacation.<\/p>\n

Even if you\u2019re more realistic about it, it may be tempting to assume Kubernetes will automatically solve existing issues with, say, your application design. It won\u2019t. (Even Kubernetes\u2019 original\u00a0co-creators agree with this<\/a>.) Focus on what it\u2019s good at rather than trying to use it as a blanket solution.<\/p>\n

\u201cContainers<\/a>\u00a0and Kubernetes provide an opportunity to create solutions that previously would have required a lot of effort and code plumbing with higher costs,\u201d Vempati says. \u201cWhile Kubernetes can provide orchestration, it doesn\u2019t solve any of the inherent design problems or limitations of the applications hosted on it. In short, application overheads cannot be addressed using Kubernetes.\u201d<\/p>\n

[ Related read:\u00a0Getting started with Kubernetes: 5 misunderstandings, explained<\/a>.\u00a0]<\/strong><\/p>\n

2. You don\u2019t have to immediately refactor everything for microservices<\/h2>\n

Microservices<\/a>\u00a0and containers\u00a0pair well together<\/a>, so it\u2019s reasonable to assume that Kubernetes and containerized microservices are a good match, too.<\/p>\n

\u201cKubernetes is ideal for new and refactored applications that don\u2019t carry the baggage \u2013 and requirements \u2013 of traditional and monolithic applications,\u201d says Ranga Rajagopalan, CTO and cofounder at\u00a0Avi Networks<\/a>.<\/p>\n

Just don\u2019t mistake the ideal scenario as the only scenario.<\/p>\n

\u201cThe conventional wisdom is to refactor or rewrite your monoliths before deploying them within a Kubernetes environment,\u201d Rajagopalan says. \u201cHowever, this can be a massive undertaking that risks putting your team in analysis paralysis.\u201d<\/p>\n

Rajagopalan notes that you can indeed run a monolith in a container and then begin to incrementally break off pieces of the application as microservices, rather than trying to do everything at once.<\/p>\n

\u201cThis can jumpstart your modernization efforts and deliver value well before the application has been completely refactored,\u201d Rajagopalan says. \u201cYou don\u2019t have to be a purist about microservices.\u201d<\/p>\n

Vempati concurs, noting that there might be some legacy applications that you never refactor because the costs outweigh the benefits.<\/p>\n

3. Account for feature differences on public clouds<\/h2>\n

One of the overarching appeals of containers is greater portability among environments, especially as multi-cloud and hybrid cloud environments proliferate. Indeed, Vempati notes that it\u2019s a common scenario for a team to deploy Kubernetes clusters on public cloud platforms. But you can\u2019t always assume “vendor-neutral”\u00a0as a default.<\/p>\n

\u201cThe native Kubernetes capabilities on public clouds differ. It is important to understand the features and workflows carefully,\u201d Vempati advises. \u201cAll the key public cloud service providers provide native Kubernetes cluster services. While these are much similar, there will be certain features that are different. When designing the solution with an aim to keep it vendor-neutral, while still choosing one of the vendors, such differences must be taken into account.\u201d<\/p>\n

Vempati shares as an example that one public cloud provider will assign public (or external) IPs to nodes when a cluster is created with its Kubernetes service, while another does not. \u201cSo if there is any dynamic behavior of the apps to infer\/use external IP, it may work with [one platform] but not on [another],\u201d Vempati says.<\/p>\n

4. It will take time\u00a0to get automation right<\/h2>\n

A basic selling point of Kubernetes and orchestration in general is that it makes manageable the operational burden of running production containers at scale, largely through\u00a0automation<\/a>. So this is one of those times where it\u2019s best to be reminded that \u201cautomation\u201d is not a synonym of \u201ceasy,\u201d especially as you\u2019re setting it up. Expect some real effort to get it right, and you\u2019ll get a return on that investment over time.<\/p>\n

\u201cKubernetes is a wonderful platform for building highly scalable and elastic solutions,\u201d Vempati says. \u201cOne of the key [selling points] of this platform is that it very effectively supports continuous delivery of microservices hosted in containers for cloud scale.\u201d<\/p>\n

This sounds great to any IT team working in multi-cloud or hybrid cloud environments, especially as their cloud-native development increases. Just be ready to do some legwork to reap the benefits.<\/p>\n

\u201cTo support automated continuous delivery for any Kubernetes-based solution is not [as] simple as it may [first] appear,\u201d Vempati says. \u201cIt involves a lot of preparation, simulation of multiple scenarios based on the solution, and several iterations to achieve the [desired results.]\u201d<\/p>\n

Red Hat<\/a>\u00a0VP and CTO\u00a0Chris Wright<\/a>\u00a0recently\u00a0wrote<\/a>\u00a0about four emerging tools that play into this need for simplification. Read also\u00a0What\u2019s next for Kubernetes and hybrid cloud<\/a>.<\/p>\n

5. Be judicious in your use of persistent volumes<\/h2>\n

The original conventional wisdom that containers should be stateless has changed, especially as it has become easier to manage stateful applications such as databases.<\/p>\n

[ Read also\u00a0How to explain Kubernetes Operators in plain English<\/a>.\u00a0]<\/strong><\/p>\n

Persistent volumes<\/a>\u00a0are the Kubernetes abstraction that enables storage for stateful applications running in containers. In short, that\u2019s a good thing. But Vempati urges careful attention to avoid longer-term issues, especially if you\u2019re in the earlier phases of adoption.<\/p>\n

\u201cThe use of persistent volumes in Kubernetes for data-centric apps is a common scenario,\u201d Vempati says. \u201cUnderstand the storage primitives available so that using persistent volumes doesn\u2019t spike costs.\u201d<\/p>\n

Factors such as the type of storage you\u2019re using can lead to cost surprises, especially when PVs are created dynamically in Kubernetes. Vempati offers an example scenario:<\/p>\n

\u201cPersistent volumes and their claims can be dynamically created as part of a deployment for a pod. Verify the storage class to make sure that the right kind of storage is used,\u201d Vempati advises. \u201cSSDs on public cloud will have a higher cost associated with them, compared to a standard storage.\u201d<\/p>\n

6. Don\u2019t evangelize Kubernetes by\u00a0shouting \u201cKubernetes!\u201d<\/h2>\n

If you\u2019re trying to\u00a0make the case for Kubernetes<\/a>\u00a0in your organization, it may be tempting to simply ride the surging wave of excitement around it.<\/p>\n

\u201cThe common wisdom out there is that simply mentioning Kubernetes is enough to gain someone\u2019s interest in how you are using it to solve a particular problem,\u201d says Glenn Sullivan, co-founder at\u00a0SnapRoute<\/a>, which uses Kubernetes as part of its cloud-native networking software\u2019s underlying infrastructure. \u201cMy advice would be to spend less time pointing to Kubernetes as the answer and piggybacking on the buzz that surrounds the platform and focus more on the results of using Kubernetes. When you present Kubernetes as the solution for solving a problem, you will immediately elate some [people] and alienate others.\u201d<\/p>\n

One reason they might resist it or tune out is that they simply don\u2019t understand what Kubernetes is. You can explain it to them in plain terms, but Sullivan says the lightbulb moment \u2013 and subsequent buy-in \u2013 is more likely to occur when you show them the results.<\/p>\n

\u201cWe find it more advantageous to promote the [benefits] gained from using Kubernetes instead of presenting the integration into Kubernetes itself as the value-add,\u201d Sullivan says.<\/p>\n

7. Kubernetes is not an island<\/h2>\n

Kubernetes is an important piece of the\u00a0cloud-native<\/a>\u00a0puzzle, but it\u2019s only one piece. As\u00a0Red Hat<\/a>\u00a0technology evangelist\u00a0Gordon Haff<\/a>\u00a0notes, \u201cThe power of the\u00a0open source cloud-native ecosystem<\/a>\u00a0comes only in part from individual projects such as Kubernetes. It derives, perhaps even more, from the breadth of complementary projects that come together to create a true cloud-native platform.\u201d<\/p>\n

This includes service meshes like \u00a0Istio<\/a>, monitoring tools like\u00a0Prometheus<\/a>, command-line tools like\u00a0Podman<\/a>, distributed tracing from the likes of\u00a0Jaeger\u00a0<\/a>and\u00a0Kiali<\/a>, enterprise registries like\u00a0Quay<\/a>, and inspection utilities like\u00a0Skopeo<\/a>, says Haff. And, of course,\u00a0Linux<\/a>, which is the foundation for the containers orchestrated by Kubernetes.<\/p>\n

[ Want to learn more about automation and building cloud-native apps? Get the guide:\u00a0Principles of container-based application design<\/a>. ]<\/strong><\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n

Source<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

You can find many great resources for\u00a0getting smarter about Kubernetes\u00a0out there. (Ahem, we\u2019ve written\u00a0a few\u00a0ourselves.) That\u2019s good news for IT teams and professionals looking to boost their knowledge and consider how\u00a0Kubernetes\u00a0might solve problems in their organization. The excited chatter about Kubernetes has gotten so loud, however, that it can become difficult to make sense of … <\/p>\n

Continue reading “Linux Today – 7 pieces of contrarian Kubernetes advice”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-11860","post","type-post","status-publish","format-standard","hentry","category-linux"],"_links":{"self":[{"href":"https:\/\/www.appservgrid.com\/paw92\/index.php\/wp-json\/wp\/v2\/posts\/11860","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.appservgrid.com\/paw92\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.appservgrid.com\/paw92\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.appservgrid.com\/paw92\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.appservgrid.com\/paw92\/index.php\/wp-json\/wp\/v2\/comments?post=11860"}],"version-history":[{"count":2,"href":"https:\/\/www.appservgrid.com\/paw92\/index.php\/wp-json\/wp\/v2\/posts\/11860\/revisions"}],"predecessor-version":[{"id":11862,"href":"https:\/\/www.appservgrid.com\/paw92\/index.php\/wp-json\/wp\/v2\/posts\/11860\/revisions\/11862"}],"wp:attachment":[{"href":"https:\/\/www.appservgrid.com\/paw92\/index.php\/wp-json\/wp\/v2\/media?parent=11860"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.appservgrid.com\/paw92\/index.php\/wp-json\/wp\/v2\/categories?post=11860"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.appservgrid.com\/paw92\/index.php\/wp-json\/wp\/v2\/tags?post=11860"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}