da Agency

How Bitmovin is Doing Multi-Stage Canary Deployments with Kubernetes in the Cloud and On-Prem

Editor’s Note: Today’s post is by Daniel Hoelbling-Inzko, Infrastructure Architect at Bitmovin, a company that provides services that transcode digital video and audio to streaming formats, sharing insights about their use of Kubernetes.Running a large scale video encoding infrastructure on multiple public clouds is tough. At Bitmovin, we have been doing it successfully for the last few years, but from an engineering perspective, it’s neither been enjoyable nor particularly fun. So obviously, one of the main things that really sold us on using Kubernetes, was it’s common abstraction from the different supported cloud providers and the well thought out programming interface it provides. More importantly, the Kubernetes project did not settle for the lowest common denominator approach. Instead, they added the necessary abstract concepts that are required and useful to run containerized workloads in a cloud and then did all the hard work to map these concepts to the different cloud providers and their offerings.The great stability, speed and operational reliability we saw in our early tests in mid-2016 made the migration to Kubernetes a no-brainer.And, it didn’t hurt that the vision for scale the Kubernetes project has been pursuing is closely aligned with our own goals as a company. Aiming for >1,000 node clusters might be a lofty goal, but for a fast growing video company like ours, having your infrastructure aim to support future growth is essential. Also, after initial brainstorming for our new infrastructure, we immediately knew that we would be running a huge number of containers and having a system, with the expressed goal of working at global scale, was the perfect fit for us. Now with the recent Kubernetes 1.6 release and its support for 5,000 node clusters, we feel even more validated in our choice of a container orchestration system.During the testing and migration phase of getting our infrastructure running on Kubernetes, we got quite familiar with the Kubernetes API and the whole ecosystem around it. So when we were looking at expanding our cloud video encoding offering for customers to use in their own datacenters or cloud environments, we quickly decided to leverage Kubernetes as our ubiquitous cloud operating system to base the solution on.Just a few months later this effort has become our newest service offering: Bitmovin Managed On-Premise encoding. Since all Kubernetes clusters share the same API, adapting our cloud encoding service to also run on Kubernetes enabled us to deploy into our customer’s datacenter, regardless of the hardware infrastructure running underneath. With great tools from the community, like kube-up and turnkey solutions, like Google Container Engine, anyone can easily provision a new Kubernetes cluster, either within their own infrastructure or in their own cloud accounts. To give us the maximum flexibility for customers that deploy to bare metal and might not have any custom cloud integrations for Kubernetes yet, we decided to base our solution solely on facilities that are available in any Kubernetes install and don’t require any integration into the surrounding infrastructure (it will even run inside Minikube!). We don’t rely on Services of type LoadBalancer, primarily because enterprise IT is usually reluctant to open up ports to the open internet – and not every bare metal Kubernetes install supports externally provisioned load balancers out of the box. To avoid these issues, we deploy a BitmovinAgent that runs inside the Cluster and polls our API for new encoding jobs without requiring any network setup. This agent then uses the locally available Kubernetes credentials to start up new deployments that run the encoders on the available hardware through the Kubernetes API.Even without having a full cloud integration available, the consistent scheduling, health checking and monitoring we get from using the Kubernetes API really enabled us to focus on making the encoder work inside a container rather than spending precious engineering resources on integrating a bunch of different hypervisors, machine provisioners and monitoring systems. Multi-Stage Canary DeploymentsOur first encounters with the Kubernetes API were not for the On-Premise encoding product. Building our containerized encoding workflow on Kubernetes was rather a decision we made after seeing how incredibly easy and powerful the Kubernetes platform proved during development and rollout of our Bitmovin API infrastructure. We migrated to Kubernetes around four months ago and it has enabled us to provide rapid development iterations to our service while meeting our requirements of downtime-free deployments and a stable development to production pipeline. To achieve this we came up with an architecture that runs almost a thousand containers and meets the following requirements we had laid out on day one:Zero downtime deployments for our customersContinuous deployment to production on each git mainline pushHigh stability of deployed services for customersObviously #2 and #3 are at odds with each other, if each merged feature gets deployed to production right away – how can we ensure these releases are bug-free and don’t have adverse side effects for our customers?To overcome this oxymoron, we came up with a four-stage canary pipeline for each microservice where we simultaneously deploy to production and keep changes away from customers until the new build has proven to work reliably and correctly in the production environment.Once a new build is pushed, we deploy it to an internal stage that’s only accessible for our internal tests and the integration test suite. Once the internal test suite passes, QA reports no issues, and we don’t detect any abnormal behavior, we push the new build to our free stage. This means that 5% of our free users would get randomly assigned to this new build. After some time in this stage the build gets promoted to the next stage that gets 5% of our paid users routed to it. Only once the build has successfully passed all 3 of these hurdles, does it get deployed to the production tier, where it will receive all traffic from our remaining users as well as our enterprise customers, which are not part of the paid bucket and never see their traffic routed to a canary track.This setup makes us a pretty big Kubernetes installation by default, since all of our canary tiers are available at a minimum replication of 2. Since we are currently deploying around 30 microservices (and growing) to our clusters, it adds up to a minimum of 10 pods per service (8 application pods + minimum 2 HAProxy pods that do the canary routing). Although, in reality our preferred standard configuration is usually running 2 internal, 4 free, 4 others and 10 production pods alongside 4 HAProxy pods – totalling around 700 pods in total. This also means that we are running at least 150 services that provide a static ClusterIP to their underlying microservice canary tier.A typical deployment looks like this:Services (ClusterIP)Deployments##Podsaccount-serviceaccount-service-haproxy4account-service-internalaccount-service-internal-v1.18.02account-service-canaryaccount-service-canary-v1.17.04account-service-paidaccount-service-paid-v1.15.04account-service-productionaccount-service-production-v1.15.010An example service definition the production track will have the following label selectors:apiVersion: v1kind: Servicemetadata:  name: account-service-production  labels:    app: account-service-production    tier: service    lb: privatespec:  ports:  – port: 8080    name: http    targetPort: 8080    protocol: TCP  selector:    app: account-service    tier: service    track: productionIn front of the Kubernetes services, load balancing the different canary versions of the service, lives a small cluster of HAProxy pods that get their haproxy.conf from the Kubernetes ConfigMaps that looks something like this:frontend http-in  bind *:80  log 127.0.0.1 local2 debug  acl traffic_internal    hdr(X-Traffic-Group) -m str -i INTERNAL  acl traffic_free        hdr(X-Traffic-Group) -m str -i FREE  acl traffic_enterprise  hdr(X-Traffic-Group) -m str -i ENTERPRISE  use_backend internal   if traffic_internal  use_backend canary     if traffic_free  use_backend enterprise if traffic_enterprise  default_backend paidbackend internal  balance roundrobin  server internal-lb        user-resource-service-internal:8080   resolvers dns check inter 2000backend canary  balance roundrobin  server canary-lb          user-resource-service-canary:8080     resolvers dns check inter 2000 weight 5  server production-lb      user-resource-service-production:8080 resolvers dns check inter 2000 weight 95backend paid  balance roundrobin  server canary-paid-lb     user-resource-service-paid:8080       resolvers dns check inter 2000 weight 5  server production-lb      user-resource-service-production:8080 resolvers dns check inter 2000 weight 95backend enterprise  balance roundrobin  server production-lb      user-resource-service-production:8080 resolvers dns check inter 2000 weight 100Each HAProxy will inspect a header that gets assigned by our API-Gateway called X-Traffic-Group that determines which bucket of customers this request belongs to. Based on that, a decision is made to hit either a canary deployment or the production deployment.Obviously, at this scale, kubectl (while still our main day-to-day tool to work on the cluster) doesn’t really give us a good overview of whether everything is actually running as it’s supposed to and what is maybe over or under replicated.Since we do blue/green deployments, we sometimes forget to shut down the old version after the new one comes up, so some services might be running over replicated and finding these issues in a soup of 25 deployments listed in kubectl is not trivial, to say the least.So, having a container orchestrator like Kubernetes, that’s very API driven, was really a godsend for us, as it allowed us to write tools that take care of that.We built tools that either run directly off kubectl (eg bash-scripts) or interact directly with the API and understand our special architecture to give us a quick overview of the system. These tools were mostly built in Go using the client-go library.One of these tools is worth highlighting, as it’s basically our only way to really see service health at a glance. It goes through all our Kubernetes services that have the tier: service selector and checks if the accompanying HAProxy deployment is available and all pods are running with 4 replicas. It also checks if the 4 services behind the HAProxys (internal, free, others and production) have at least 2 endpoints running. If any of these conditions are not met, we immediately get a notification in Slack and by email.Managing this many pods with our previous orchestrator proved very unreliable and the overlay network frequently caused issues. Not so with Kubernetes – even doubling our current workload for test purposes worked flawlessly and in general, the cluster has been working like clockwork ever since we installed it.Another advantage of switching over to Kubernetes was the availability of the kubernetes resource specifications, in addition to the API (which we used to write some internal tools for deployment). This enabled us to have a Git repo with all our Kubernetes specifications, where each track is generated off a common template and only contains placeholders for variable things like the canary track and the names.All changes to the cluster have to go through tools that modify these resource specifications and get checked into git automatically so, whenever we see issues, we can debug what changes the infrastructure went through over time!To summarize this post – by migrating our infrastructure to Kubernetes, Bitmovin is able to have:Zero downtime deployments, allowing our customers to encode 24/7 without interruptionFast development to production cycles, enabling us to ship new features fasterMultiple levels of quality assurance and high confidence in production deploymentsUbiquitous abstractions across cloud architectures and on-premise deploymentsStable and reliable health-checking and scheduling of servicesCustom tooling around our infrastructure to check and validate the systemHistory of deployments (resource specifications in git + custom tooling)We want to thank the Kubernetes community for the incredible job they have done with the project. The velocity at which the project moves is just breathtaking! Maintaining such a high level of quality and robustness in such a diverse environment is really astonishing. –Daniel Hoelbling-Inzko, Infrastructure Architect, BitmovinPost questions (or answer questions) on Stack OverflowJoin the community portal for advocates on K8sPortGet involved with the Kubernetes project on GitHubFollow us on Twitter @Kubernetesio for latest updatesConnect with the community on SlackDownload Kubernetes
Quelle: kubernetes

da Agency

How To Build Planet Scale Mobile App in Minutes with Xamarin and DocumentDB

Most mobile apps need to store data in the cloud, and #Azure DocumentDB is an awesome cloud database for mobile apps. It has everything a mobile developer needs, a fully managed NoSQL database as a service that scales on demand, and can bring your data where your users go around the globe — completely transparently to your application. Today we are excited to announce Azure DocumentDB SDK for Xamarin mobile platform, enabling mobile apps to interact directly with DocumentDB, without a middle-tier.

Here is what mobile developers get out of the box with DocumentDB:

Rich queries over schemaless data. DocumentDB stores data as schemaless JSON documents in heterogeneous collections, and offers rich and fast queries without the need to worry about schema or indexes.
Fast. Guaranteed. It takes only few milliseconds to read and write documents with DocumentDB. Developers can specify the throughput they need and DocumentDB will honor it with 99.99% SLA.
Limitless Scale. Your DocumentDB collections will grow as your app grows. You can start with small data size and 100s requests per second and grow to arbitrarily large, 10s and 100s of millions requests per second throughput, and petabytes of data.
Globally Distributed. Your mobile app users are on the go, often across the world. DocumentDB is a globally distributed database, and with just one click on a map it will bring the data wherever your users are.
Built-in rich authorization. With DocumentDB you can easy to implement popular patterns like per-user data, or multi-user shared data without custom complex authorization code.
Geo-spatial queries. Many mobile apps offer geo-contextual experiences today. With the first class support for geo-spatial types DocumentDB makes these experiences very easy to accomplish.
Binary attachments. Your app data often includes binary blobs. Native support for attachments makes it easier to use DocumentDB as one-stop shop for your app data.

Let's build an app together!

Step #1. Get Started

It&039;s easy to get started with DocumentDB, just go to Azure portal, create a new DocumentDB account,  go to the Quickstart tab, and download a Xamarin Forms todo list sample, already connected to your DocumentDB account. 

Or if you have an existing Xamarin app, you can just add this DocumentDB NuGet package. Today we support Xamarin.IOS, Xamarin.Android, as well as Xamarin Forms shared libraries.

Step #2. Work with data

Your data records are stored in DocumentDB as schemaless JSON documents in heterogeneous collections. You can store documents with different structures in the same collection.

In your Xamarin projects you can use language integtated queries over schemaless data:

Step #3. Add Users

Like many get started samples, the DocumentDB sample you downloaded above authenticates to the service using master key hardcoded in the app&039;s code. This is of course not a good idea for an app you intend to run anywhere except your local emulator. If an attacker gets a hold of the master key, all the data across your DocumentDB account is compromised.

Instead we want our app to only have access to the records for the logged in user. DocumentDB allows developers to grant application read or read/write access to all documents in a collection, a set of documents, or a specific document, depending on the needs.

Here is for example, how to modify our todo list app into a multi-user todolist app, a complete version of the sample is available here: 

Add Login to your app, using Facebook, Active Directory or any other provider.
Create a DocumentDB UserItems collection with /userId as a partition key. Specifying partition key for your collection allows DocumentDB to scale infinitely as the number of our app users growth, while offering fast queries.
Add DocumentDB Resource Token Broker, a simple Web API that authenticates the users and issues short lived tokens to the logged in users with access only to the documents within the user&039;s partition. In this example we host Resource Token Broker in App Service.
Modify the app to authenticate to Resource Token Broker with Facebook and request the resource tokens for the logged in Facebook user, then access users data in the UserItems collection.  

This diagram illustrates the solution. We are investigating eliminating the need for Resource Token Broker by supporting OAuth in DocumentDB first class, please upvote this uservoice item if you think it&039;s a good idea!

Now if we want two users get access to the same todolist, we just add additional permissions to the access token in Resource Token Broker. You can find the complete sample here.

Step #4. Scale on demand.

DocumentDB is a managed database as a service. As your user base grows, you don&039;t need to worry about provisioning VMs or increasing cores. All you need to tell DocumentDB is how many operations per second (throughput) your app needs. You can specify the throughput via portal Scale tab using a measure of throughput called Request Units per second (RUs). For example, a read operation on a 1KB document requires 1 RU. You can also add alerts for "Throughput" metric to monitor the traffic growth and programmatically change the throughput as alerts fire.

  

Step #5. Go Planet Scale!

As your app gains popularity, you may acquire users accross the globe. Or may be you just don&039;t want to be caught of guard if a meteorite strkes the Azure data centers where you created your DocumentDB collection. Go to Azure portal, your DocumentDB account, and with a click on a map, make your data continuously replicate to any number of regions accross the world. This ensures your data is available whereever your users are, and you can add failover policies to be prepared for the rainy day.

We hope you find this blog and samples useful to take advantage of DocumentDB in your Xamarin application. Similar pattern can be used in Cordova apps using DocumentDB JavaScript SDK, as well as native iOS / Android apps using DocumentDB REST APIs.

As always, let us know how we are doing and what improvements you&039;d like to see going forward for DocumentDB through UserVoice, StackOverflow azure-documentdb, or Twitter @DocumentDB.
Quelle: Azure

da Agency

How to avoid a self-inflicted DDoS Attack – CRE life lessons

Posted by Dave Rensin, Director of Customer Reliability Engineering, and Adrian Hilton, Software Engineer, Site Reliability Engineering

Editor’s note: Left unchecked, poor software architecture decisions are the most common cause of application downtime. Over the years, Google Site Reliability Engineering has learned to spot code that could lead to outages, and strives to identify it before it goes into production as part of its production readiness review. With the introduction of Customer Reliability Engineering, we’re taking the same best practices we’ve developed for internal systems, and extending them to customers building applications on Google Cloud Platform. This is the first post in a series written by CREs to highlight real-world problems — and the steps we take to avoid them.

Distributed Denial of Service (DDoS) attacks aren’t anything new on the internet, but thanks to a recent high profile event, they’ve been making fresh headlines. We think it’s a convenient moment to remind our readers that the biggest threat to your application isn’t from some shadowy third party, but from your own code!

What follows is a discussion of one of the most common software architecture design fails — the self-inflicted DDoS — and three methods you can use to avoid it in your own application.

Even distributions that aren’t
There’s a famous saying (variously attributed to Mark Twain, Will Rogers, and others) that goes:

“It ain’t what we don’t know that hurts us so much as the things we know that just ain’t so.”
Software developers make all sorts of simplifying assumptions about user interactions, especially about system load. One of the more pernicious (and sometimes fatal) simplifications is “I have lots of users all over the world. For simplicity, I’m going to assume their load will be evenly distributed.”

To be sure, this often turns out to be close enough to true to be useful. The problem is that it’s a steady state or static assumption. It presupposes that things don’t vary much over time. That’s where things start to go off the rails.

Consider this very common pattern: Suppose you’ve written a mobile app that periodically fetches information from your backend. Because the information isn’t super time sensitive, you write the client to sync every 15 minutes. Of course, you don’t want a momentary hiccup in network coverage to force you to wait an extra 15 minutes for the information, so you also write your app to retry every 60 seconds in the event of an error.

Because you’re an experienced and careful software developer, your system consistently maintains 99.9% availability. For most systems that’s perfectly acceptable performance but it also means in any given 30-day month your system can be unavailable for up to 43.#2 minutes.

So. Let’s talk about what happens when that’s the case. What happens if your system is unavailable for just one minute?

When your backends come back online you get (a) the traffic you would normally expect for the current minute, plus (b) any traffic from the one-minute retry interval. In other words, you now have 2X your expected traffic. Worse still, your load is no longer evenly distributed because 2/15ths of your users are now locked together into the same sync schedule. Thus, in this state, for any given 15-minute period you’ll experience normal load for 13 minutes, no load for one minute and 2X load for one minute.

Of course, service disruptions usually last longer than just one minute. If you experience a 15-minute error (still well within your 99.9% availability) then all of your load will be locked together until after your backends recover. You’ll need to provision at least 15X of your normal capacity to keep from falling over. Retries will also often “stack” at your load balancers and your backends will respond more slowly to each request as their load increases. As a result, you might easily see 20X your normal traffic (or more) while your backends heal. In the worst case, the increased load might cause your servers to run out of memory or other resources and crash again.

Congratulations, you’ve been DDoS’d by your own app!

The great thing about known problems is that they usually have known solutions. Here are three things you can do to avoid this trap.

#1 Try exponential backoff
When you use a fixed retry interval (in this case, one minute) you pretty well guarantee that you’ll stack retry requests at your load balancer and cause your backends to become overloaded once they come back up. One of the best ways around this is to use exponential backoff.

In its most common form, exponential backoff simply means that you double the retry interval up to a certain limit to lower the number of overall requests queued up for your backends. In our example, after the first one-minute retry fails, wait two minutes. If that fails, wait four minutes and keep doubling that interval until you get to whatever you’ve decided is a reasonable cap (since the normal sync interval is 15 minutes you might decide to cap the retry backoff at 16 minutes).

Of course, backing off of retries will help your overall load at recovery but won’t do much to keep your clients from retrying in sync. To solve that problem, you need jitter.

2 Add a little jitter

Jitter is the random interval you add (or subtract) to the next retry interval to prevent clients from locking together during a prolonged outage. The usual pattern is to pick a random number between +/- a fixed percentage, say 30%, and add it to the next retry interval.

In our example, if the next backoff interval is supposed to be 4 minutes, then wait between +/- 30% of that interval. Thirty percent of 4 minutes is 1.2 minutes, so select a random value between 2.8 minutes and 5.2 minutes to wait.

Here at Google we’ve observed the impact of a lack of jitter in our own services. We once built a system where clients started off polling at random times but we later observed that they had a strong tendency to become more synchronized during short service outages or degraded operation.

Eventually we saw very uneven load across a poll interval — with most clients polling the service at the same time — resulting in peak load that was easily 3X the average. Here’s a graph from the postmortem from an outage in the aforementioned system. In this case the clients were polling at a fixed 5-minute interval, but over many months became synchronized:

Observe how the traffic (red) comes in periodic spikes, correlating with 2x the average backend latency (green) as the servers become overloaded. That was a sure sign that we needed to employ jitter. This monitoring view is also significantly under-counting the traffic peaks because of its sample interval. Once we added a random factor of +/- 1 minute (20%) to each retry the latency, traffic flattened out almost immediately, with the periodicity disappearing:

and the backends were no longer overloaded. Of course, we couldn’t do this immediately — we had to build and push a new code release to our clients with this new behavior, so we had to live with this overload for a while.

At this point, we should also point out that in the real world, usage is almost never evenly distributed — even when the users are. Nearly all systems of any scale experience peaks and troughs corresponding with the work and sleep habits of their users. Lots of people simply turn off their phones or computers when they go to sleep. That means that you’ll see a spike in traffic as those devices come back online when people wake up.

For this reason it’s also a really good idea to add a little jitter (perhaps 10%) to regular sync intervals, in addition to your retries. This is especially important for first syncs after an application starts. This will help to smooth out daily cyclical traffic spikes and keep systems from becoming overloaded.

#3 Implement retry marking
A large fleet of backends doesn’t recover from an outage all at once. That means that as a system begins to come back online, its overall capacity ramps up slowly. You don’t want to jeopardize that recovery by trying to serve all of your waiting clients at once. Even if you implement both exponential backoff and jitter you still need to prioritize your requests as you heal.

An easy and effective technique to do this is to have your clients mark each attempt with a retry number. A value of zero means that the request is a regular sync. A value of one indicates the first retry and so on. With this in place, the backends can prioritize which requests to service and which to ignore as things get back to normal. For example, you might decide that higher retry numbers indicate users who are further out-of-sync and service them first. Another approach is to cap the overall retry load to a fixed percentage, say 10%, and service all the regular syncs and only 10% of the retries.

How you choose to handle retries is entirely up to your business needs. The important thing is that by marking them you have the ability to make intelligent decisions as a service recovers.

You can also monitor the health of your recovery by watching the retry number metrics. If you’re recovering from a six-minute outage, you might see that the oldest retries have a retry sequence number of 3. As you recover, you would expect to see the number of 3s drop sharply, followed by the 2s, and so on. If you don’t see that (or see the retry sequence numbers increase), you know you still have a problem. This would not be obvious by simply watching the overall number of retries.

Parting thoughts
Managing system load and gracefully recovering from errors is a deep topic. Stay tuned for upcoming posts about important subjects like cascading failures and load shedding. In the meantime, if you adopt the techniques in this article you can help keep your one minute network blip from turning into a much longer DDoS disaster.
Quelle: Google Cloud Platform

da Agency

Announcing Docker Global Mentor Week 2016

Building on the the success of the Docker Birthday #3 Celebration and Training events earlier this year, we’re excited to announce the Docker Global Mentor Week. This global event series aims to provide Docker training to both newcomers and intermediate Docker users. More advanced users will have the opportunity to get involved as mentors to further encourage connection and collaboration within the community.

The Docker Global Mentor Week is your opportunity to either #learndocker or help others learndocker. Participants will work through self paced labs that will be available through an online Learning Management System (LMS). We’ll have different labs for beginners and intermediate users, Developers and Ops and Linux or Windows users.
Are you an advanced Docker user?
We are recruiting a network of mentors to help guide learners work through the labs. Mentors will be invited to attend local events to help answer questions attendees may have while completing the self-paced beginner and intermediate labs. To help mentors prepare for their events, we’ll be sharing the content of the labs and hosting a Q&A session with the Docker team before the start of the global mentor week.
 
Sign up as a Mentor!
 
With over 250 Docker Meetup groups worldwide, there is always an opportunity for collaboration and knowledge sharing. With the launch of Global Mentor Week, Docker is also introducing a Sister City program to help create and strengthen partnerships between local Docker communities which share similar challenges.
Docker NYC Organiser Jesse White talks about their collaboration with Docker London:
“Having been a part of the Docker community ecosystem from the beginning, it&8217;s thrilling for us at Docker NYC to see the community spread across the globe. As direct acknowledgment and support of the importance of always reaching out and working together, we&8217;re partnering with Docker London to capture the essence of what&8217;s great about Docker Global Mentor week. We&8217;ll be creating a transatlantic, volunteer-based partnership to help get the word out, collaborate on and develop training materials, and to boost the recruitment of mentors. If we&8217;re lucky, we might get some international dial-in and mentorship at each event too!”
If you’re part of a community group for a specific programming language, open source software projects, CS students at local universities, coding institutions or organizations promoting inclusion in the larger tech community and interested in learning about Docker, we&8217;d love to partner with you. Please email us at meetups@docker.com for more information about next steps.
We&8217;re thrilled to announce that there are already 37 events scheduled around the world! Check out the list of confirmed events below to see if there is one happening near you. Make sure to check back as we’ll be updating this list as more events are announced. Want to help us organize a Mentor Week training in your city? Email us at meetups@docker.com for more information!
 
Saturday, November 12th

New Delhi, India

Sunday, November 13th

Mumbai, India

Monday, November 14th

Auckland, New Zealand
London, United Kingdom
Mexico City, Mexico
Orange County, CA

Tuesday, November 15th

Atlanta, GA
Austin, TX
Brussels, Belgium
Denver, CO
Jakarta, Indonesia
Las Vegas, NV
Medan, Indonesia
Nice, France
Singapore, Singapore

Wednesday, November 16th

Århus, Denmark
Boston, MA
Dhahran, Saudia Arabia
Hamburg, Germany
Novosibirsk, Russia
San Francisco, CA
Santa Barbara, CA
Santa Clara, CA
Washington, D.C.
Rio de Janeiro, Brazil

Thursday, November 17th

Berlin, Germany
Budapest, Hungary
Glasgow, United Kingdom
Lima, Peru
Minneapolis, MN
Oslo, Norway
Richmond, VA

Friday, November 18th

Kanpur, India
Tokyo, Japan

Saturday, November 19th

Ha Noi, Vietnam
Mangaluru, India
Taipei, Taiwan

Excited about Docker Global Mentor Week? Let your community know!

Excited to learndocker during @docker Global Mentor Week! Get involved by signing up for…Click To Tweet

The post Announcing Docker Global Mentor Week 2016 appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

da Agency

Six DevOps myths and the realities behind them

The post Six DevOps myths and the realities behind them appeared first on Mirantis | The Pure Play OpenStack Company.
At OpenStack Days Silicon Valley 2016, Puppet Founder and CEO Luke Kanies dispelled the six most common misconceptions he’s encountered that prevent organizations from adopting and benefiting from DevOps.

Over a five-year period, Puppet conducted market research of 25,000 people that shows the adoption of DevOps is critical to building a great software company. Unfortunately, however, many companies find that the costs of the cultural change are too high. The result is that these firms often fail to become great software companies — sometimes because even though they try to adopt the DevOps lifestyle, they do it in a such way that the change in a way doesn’t have enough real value because the changes don’t go deep enough.

You see, all companies are becoming software companies, Kanies explained, and surveys have shown that success requires optimization of end-to-end software production. Organizations that move past barriers to change and go from the old processes to the new way of using DevOps tools and practices will be able to make the people on their team happy, spend more time on creating value rather than on rework, and deliver software faster.

Key points in the 2016 State of DevOps Report survey show that high-performing teams deploy 200 times more frequently than average teams, with over #2,500 times shorter lead times, so the time between idea and production is minimal. Additionally, these teams see failure rates that are #3 times lower than their non-DevOps counterparts, and they recover 24 times faster. The five-year span of the survey has also shown that the distance between top performers and average performers is growing.

In other words, the cost of not adopting DevOps processes is also growing.

Despite these benefits, however, for every reason to adopt DevOps, there are plenty of myths and cultural obstacles that hold organizations back.
Myth #1: There&8217;s no direct value to DevOps
The first myth Kanies discussed is that there’s no direct customer or business value for adopting DevOps practices. After all, how much good does it do customers to have teams deploying 200 times more frequently?

Quite a lot, as it happens. DevOps allows faster delivery of more reliable products and optimizes processes, which results in developing software faster. That means responding to customer problems more quickly, as well as drastically slashing time to market for new ideas and products. This increased velocity means more value for your business.
Myth 2: There&8217;s no ROI for DevOps in the legacy world
The second myth, that there’s no return on investment in applying DevOps to legacy applications, is based on the idea that DevOps is only useful for new technology. The problem with this view, Kanies says, is that the majority of the world still runs in legacy environments, effectively ruling out most of the existing IT ecosystem.

There are really good reasons not to ignore this reality when planning your DevOps initiatives. The process of DevOps doesn’t have to be all-or-nothing; you can make small changes to your process and make a significant difference, removing manual steps, and slow, painful, and error-prone processes.

What&8217;s more, in many cases, you can’t predict where returns will be seen, so there’s value in working across the entire organization. Kanies points out that it makes no sense to only utilize DevOps for the new, shiny stuff that no one is really using yet and neglect the production applications that users care about &8212; thus leaving them operating slowly and poorly.
Myth 3: Only unicorns can wield DevOps
Myth number three is that DevOps only works with “unicorn” companies and not traditional enterprise. Traditional companies want assurances that DevOps solutions and benefits work for their very traditional needs, and not just for new, from-scratch companies.

Kanies points out that DevOps is the new normal, and no matter where organizations are in the maturity cycle, they need to be able to figure out how to optimize the entire end-to-end software production, in order to gain the benefits of DevOps: reduced time to market, lower mean time to recovery, and higher levels of employee engagement.
Myth #4: You don&8217;t have enough time or people
The fourth myth is that improvement via DevOps requires spare time and people the organization doesn’t have. Two concepts at the root of this myth are the realities that no matter what you do, software must be delivered faster and more often and that costs must be maintained or decreased, and organizations don’t see how to do this &8212; especially if they take time to retool to a new methodology.

But DevOps is about time reclamation. First, it automates many tasks that computers can accomplish faster and more reliably and an overworked IT engineer. That much is obvious.  

But there&8217;s a second, less obvious way that DevOps enables you to reclaim time and money. Studies have shown that on average, SREs, sysadmins, and so on get interrupted every fifteen minutes &8212; and that it takes about thirty minutes to fully recover from an interruption. This means many people have no time to spend hours on a single, hard problem because they constantly get interrupted. Recognizing this problem and removing the interruptions can free up time for more value-added activity and free up needed capacity in the organization.
Myth #5: DevOps doesn&8217;t fit with regulations and compliance
Myth number five comes from companies subject to regulation and compliance who believe this precludes adoption of DevOps. However, with better software, faster recovery, faster deployments, and lower error rates, you can automate compliance as well. Organizations can integrate all of the elements of software development with auditing, security, and compliance to deliver higher value, and in fact, if these aren’t all done at once, companies are more than likely to experience a failure of some sort.
Myth #6: You don&8217;t really need it
Kanies says he hasn’t heard the sixth myth often, but once in a while, a company concludes it doesn’t have any problems that adopting DevOps would fix. But DevOps is really about being good at getting better, moving faster, and eliminating the more frustrating parts of the work, he explains.

The benefits of adopting DevOps are clear from Kanies’ points and from the data presented by the survey. As he says, the choice is really about whether to invest in change or to let your competitors do it first. Because the top performers are pulling ahead faster and faster, Kanies says, and “organizations don’t have a lot of time to make a choice.”

You can hear the entire talk on the OpenStack Days Silicon Valley site.The post Six DevOps myths and the realities behind them appeared first on Mirantis | The Pure Play OpenStack Company.
Quelle: Mirantis

da Agency

How does the world consume private clouds?

The post How does the world consume private clouds? appeared first on Mirantis | The Pure Play OpenStack Company.
In my previous blog, why the world needs private clouds, we looked at ten reasons for considering a private cloud. The next logical question is how a company should go about building a private cloud.
In my view, there are four consumption models for OpenStack. Let’s look at each approach and then compare.

Approach #1: DIY
For the most sophisticated users, where OpenStack is super-strategic to the business, a do-it-yourself approach is appealing. Walmart, PayPal, and so on are examples of this approach.
In this approach, the user has to grab upstream OpenStack bits, package the right projects, fix bugs or add features as needed, then deploy and manage the OpenStack lifecycle. The user also has to “self-support” their internal IT/OPS team.
This approach requires recruiting and retaining a very strong engineering team that is adept at python, OpenStack, and working with the upstream open-source community. Because of this, I don’t think more than a handful companies can or would want to pursue this approach. In fact, we know of several users who started out on this path, but had to switch to a different approach because they lost engineers to other companies. Net-net, the DIY approach is not for the faint of heart.
Approach #2: Distro
For large sophisticated users that plan to customize a cloud for their own use and have the skills to manage it, an OpenStack distribution is an attractive approach.
In this approach, no upstream engineering is required. Instead, the company is responsible for deploying a known good distribution from a vendor and managing its lifecycle.
Even though this is simpler than DIY, very few companies can manage a complex, distributed and fast moving piece of software such as OpenStack — a point made by Boris Renski in his recent blog Infrastructure Software is Dead. Therefore, most customers end up utilizing extensive professional services from the distribution vendor.
Approach #3: Managed Services
For customers who don’t want to deal with the hassle of managing OpenStack, but want control over the hardware and datacenter (on-prem or colo), managed services may be a great option.
In this approach, the user is responsible for the hardware, the datacenter, and tenant management; but OpenStack is fully managed by the vendor. Ultimately this may be the most appealing model for a large set of customers.
Approach #4: Hosted Private Cloud
This approach is a variation of the Managed Services approach. In this option, not only is the cloud managed, it is also hosted by the vendor. In other words, the user does not even have to purchase any hardware or manage the datacenter. In terms of look and feel, this approach is analogous to purchasing a public cloud, but without the “noisy neighbor” problems that sometimes arise.
Which approach is best?
Each approach has its pros and cons, of course. For example, each approach has different requirements in terms of engineering resources:

DIY
Distro
Managed Service
Hosted  Private Cloud

Need upstream OpenStack engineering team
Yes
No
No
No

Need OpenStack IT architecture team
Yes
Yes
No
No

Need OpenStack IT/ OPS team
Yes
Yes
No
No

Need hardware & datacenter team
Yes
Yes
Yes
No

Which approach you choose should also depend on factors such as the importance of the initiative, relative cost, and so on, such as:

DIY
Distro
Managed Service
Hosted  Private Cloud

How important is the private cloud to the company?
The business depends on private cloud
The cloud is extremely strategic to the business
The cloud is very strategic to the business
The cloud is somewhat strategic to the business

Ability to impact the community
Very direct
Somewhat direct
Indirect
Minimal

Cost (relative)
Depends on skills & scale
Low
Medium
High

Ability to own OpenStack operations
Yes
Yes
Depends if the vendor offers a transfer option
No

So as a user of an OpenStack private cloud you have four ways to consume the software.
The cost and convenience of each approach vary as per this simplified chart and need to be traded-off with respect to your strategy and requirements.
OK, so we know why you need a private cloud, and how you can consume one. But there’s still one burning question: who needs it?
The post How does the world consume private clouds? appeared first on Mirantis | The Pure Play OpenStack Company.
Quelle: Mirantis

da Agency

Live from LinuxCon – Sharing the latest news and learnings on Microsoft’s open journey

Greetings from LinuxCon North America in Toronto, where I am representing Microsoft as a keynote speaker for the first time! I'm excited to share exciting new open source developments from Microsoft and things we&039;ve learned from our journey with Linux and open source. Of course, I also look forward to catching up with old friends and meeting up with some customers and partners.

Over the past few months I’ve been asked more times than I can count, “Wim, why did you join Microsoft?” As a Linux guy who has watched the company from afar, I am the first to admit that Microsoft hasn’t always been the most open company. After talking to some of the executives at the company, I found that the days of a closed Microsoft are over.

The reality is customers use more than one tool and more than one platform to operate their businesses. They need tools that support Linux and Windows, and they need a cloud that allows them to run any application. One of the things I shared with linux.com recently was how blown away I was to see how large Microsoft&039;s investment in Linux already is. We brought .NET Core, PowerShell, and SQL Server to Linux. We also open sourced Visual Studio Code and just recently PowerShell. And, we are contributing to and participating in numerous community projects. It’s incredible to be a part of it.

Our latest open source and Linux advancements

One of the areas we are focused on is delivering open management solutions. In today’s multi-cloud, multi-OS world, customers need simple, unified tools to reduce complexity. That’s why just last week, we announced that we’re open sourcing PowerShell and making it available on Linux. Now PowerShell users across Windows and Linux can use our popular command-line shell and scripting language to manage almost everything from almost anywhere. My colleague Jeffrey Snover wrote a fantastic story about the journey to open source PowerShell and how customer-centricity brought us here – go check it out!

We’re also investing in making Microsoft Operations Management Suite (OMS), which gives you visibility and control of your applications and workloads across Azure and other clouds, a first-class tool for managing Linux environments. Last week, we announced that the OMS Monitoring Agent for Linux is generally available, delivering rich insights and real-time visibility into customers’ Linux workloads to quickly remediate issues. A lot of the tools we use and integrate with are open source-based, such as fluentd and integration with auditd and the like.

Today, I’m also excited to share that OMS Docker Container monitoring is available in preview. By nature, containers are lightweight and easily provisioned, so without a centralized approach to monitoring, customers may find it difficult to manage and respond to critical issues quickly. With OMS Docker Container monitoring, you get visibility into your container inventory, performance, and logs from one place, get a simplified view of containers’ usage, and can diagnose issues whether your containers are running in the cloud or on-premises. You may have seen Mark Russinovich demo this live at DockerCon in June, and we’re thrilled you can try it for yourself.

What we’ve learned on our journey and what’s next

These are all important milestones for Microsoft that reflect our journey of learning and the thoroughness of our open source approach across infrastructure investments; new governance processes that work with and for the community; new ways to incorporate customer and partner feedback; and the deepening of partnerships to make great experiences possible for organizations of all types. In my keynote tomorrow, I will talk about how we are applying our learnings into the Linux ecosystem, what our approach to open source is, what it means for Linux users, and how me and my team are working to take this to the next level.

Our experiences with Linux in Azure, where nearly 1 in #3 VMs today are Linux, have brought us closer to our customers and what they need to succeed in a rapidly advancing world. We have made significant investments in making Microsoft&039;s platform a great place to run open source software, and I will be working with my team to accelerate this effort over the coming months.

Choice and flexibility are important tenets of our platform. Also critical are our efforts to contribute to open source projects, integrate open source technologies in our platform, and forge commercial and community partnerships with the ecosystem. It’s not just about what we’re open sourcing or making available on Linux. Microsoft is committed to contributing and participating in open source projects, like our investments in OMI and fluentd, our focus on Chakra and TypeScript, and many other projects including the fantastic work from our Microsoft Research organization. To take it a step further, one of the things my team and I have learned is how to partner with the community to make our contributions viable and sustainable, in ways that work for the community. I will be sharing many of those examples in my keynote.

It’s now been a few months since I joined Microsoft. It’s an exciting time to be at this company. I have to say that Linux and open source have become a normal part of our day-to-day business at Microsoft – from our people, our products, our vision, and our investments. I’m excited at what the future will bring with more first- and third-party projects, technologies, and partnerships that will bring great experiences to our customers using Linux and open source technologies.

If you’re at LinuxCon, please join me and the open source team in booth 3 at LinuxCon this week, and follow us on Twitter for more details about my keynote. If you’re not attending, make sure you visit the Azure.com website on Linux to learn more about our work with Linux and open source technologies.
Quelle: Azure

da Agency

Azure SQL Database Threat Detection, your built-in security expert

Azure SQL Database Threat Detection has been in preview for a few months now. We’ve onboarded many customers and received some great feedback. We would like to share a few customer experiences that demonstrate how Azure SQL Database Threat Detection helped address their concerns about potential threats to their database.

What is Azure SQL Database Threat Detection?

Azure SQL Database Threat Detection is a new security intelligence feature built into the Azure SQL Database service. Working around the clock to learn, profile and detect anomalous database activities, Azure SQL Database Threat Detection identifies potential threats to the database.

Security officers or other designated administrators can get an immediate notification about suspicious database activities as they occur. Each notification provides details of the suspicious activity and recommends how to further investigate and mitigate the threat.

Currently, Azure SQL Database Threat Detection detects potential vulnerabilities and SQL injection attacks, as well as anomalous database access patterns. The following customer feedback attests to how Azure SQL Database Threat Detection warned them about these threats as they occurred and helped them improve their database security.

Case #1: Attempted database access by former employee

Borja Gómez, architect and development lead at YesEnglish

“Azure SQL Database Threat Detection is a useful feature that allows us to detect and respond to anomalous database activities, which were not visible to us beforehand. As part of my role designing and building Azure-based solutions for global companies in the Information and Communication Technology field, we always turn on Auditing and Threat Detection, which are built-in and operate independently of our code. A few months later, we received an email alert that "Anomalous database activities from unfamiliar IP (location) was detected." The threat came from a former employee trying to access one of our customer’s databases, which contained sensitive data, using old credentials. The alert allowed us to detect this threat as it occurred, we were able to remediate the threat immediately by locking down the firewall rules and changing credentials, thereby preventing any damage. Such is the simplicity and power of Azure.”

Case #2: Preventing SQL Injection attacks

Richard Priest, architectural software engineer at Feilden Clegg Bradley Studios and head of the collective at Missing Widget

“Thanks to Azure SQL Database Threat Detection, we were able to detect and fix code vulnerabilities to SQL injection attacks and prevent potential threats to our database. I was extremely impressed how simple it was to enable the threat detection policy using the Azure portal, which required no modifications to our SQL client applications. A while after enabling Azure SQL Database Threat Detection, we received an email notification about ‘An application error that may indicate a vulnerability to SQL injection attacks.’  The notification provided details of the suspicious activity and recommended concrete actions to further investigate and remediate the threat. The alert helped me to track down the source my error and pointed me to the Microsoft documentation that thoroughly explained how to fix my code. As the head of IT, I now guide my team to turn on Azure SQL Database Auditing and Threat Detection on all our projects, because it gives us another layer of protection and is like having a free security expert on our team.”

Case #3: Anomalous access from home to production database

Manrique Logan, architect and technical lead at ASEBA

“Azure SQL Database Threat Detection is an incredible feature, super simple to use, empowering our small engineering team to protect our company data without the need to be security experts. Our non-profit company provides user-friendly tools for mental health professionals, storing health and sales data in the cloud. As such we need to be HIPAA and PCI compliant, and Azure SQL Database Auditing and Threat Detection help us achieve this. These features are available out of the box, and simple to enable too, taking only a few minutes to configure. We saw the real value from these not long after enabling Azure SQL Database Threat Detection, when we received an email notification that ‘Access from an unfamiliar IP address (location) was detected.'  The alert was triggered as a result of my unusual access to our production database from home. Knowing that Microsoft is using its vast security expertise to protect my data gives me incredible peace of mind and allows us to focus our security budget on other issues. Furthermore, knowing the fact that every database activity is being monitored has increased security awareness among our engineers. Azure SQL Database Threat Detection is now an important part of our incident response plan. I love that Azure SQL Database offers such powerful and easy-to-use security features.

Turning on Azure SQL Database Threat Detection

Azure SQL Database Threat Detection is incredibly easy to enable. You simply navigate to the Auditing and Threat Detection configuration blade for your database in the Azure management portal. There you switch on Auditing and Threat Detection, and configure at least one email address for receiving alerts.

Click the following links to:

Learn more about Azure SQL Database Threat Detection.
Learn more about Azure SQL Database.

We&039;ll be glad to get feedback on how this feature is serving your security requirements. Please feel free to share your comments below.
Quelle: Azure

da Agency

Kubernetes Namespaces: use cases and insights

“Who’s on first, What’s on second, I Don’t Know’s on third” Who’s on First? by Abbott and CostelloIntroductionKubernetes is a system with several concepts. Many of these concepts get manifested as “objects” in the RESTful API (often called “resources” or “kinds”). One of these concepts is Namespaces. In Kubernetes, Namespaces are the way to partition a single Kubernetes cluster into multiple virtual clusters. In this post we’ll highlight examples of how our customers are using Namespaces. But first, a metaphor: Namespaces are like human family names. A family name, e.g. Wong, identifies a family unit. Within the Wong family, one of its members, e.g. Sam Wong, is readily identified as just “Sam” by the family. Outside of the family, and to avoid “Which Sam?” problems, Sam would usually be referred to as “Sam Wong”, perhaps even “Sam Wong from San Francisco”.  Namespaces are a logical partitioning capability that enable one Kubernetes cluster to be used by multiple users, teams of users, or a single user with multiple applications without concern for undesired interaction. Each user, team of users, or application may exist within its Namespace, isolated from every other user of the cluster and operating as if it were the sole user of the cluster. (Furthermore, Resource Quotas provide the ability to allocate a subset of a Kubernetes cluster’s resources to a Namespace.)For all but the most trivial uses of Kubernetes, you will benefit by using Namespaces. In this post, we’ll cover the most common ways that we’ve seen Kubernetes users on Google Cloud Platform use Namespaces, but our list is not exhaustive and we’d be interested to learn other examples from you.Use-cases coveredRoles and Responsibilities in an enterprise for namespacesPartitioning landscapes: dev vs. test vs. prodCustomer partitioning for non-multi-tenant scenariosWhen not to use namespacesUse-case #1: Roles and Responsibilities in an EnterpriseA typical enterprise contains multiple business/technology entities that operate independently of each other with some form of overarching layer of controls managed by the enterprise itself. Operating a Kubernetes clusters in such an environment can be done effectively when roles and responsibilities pertaining to Kubernetes are defined. Below are a few recommended roles and their responsibilities that can make managing Kubernetes clusters in a large scale organization easier.Designer/Architect role: This role will define the overall namespace strategy, taking into account product/location/team/cost-center and determining how best to map these to Kubernetes Namespaces. Investing in such a role prevents namespace proliferation and “snowflake” Namespaces.Admin role: This role has admin access to all Kubernetes clusters. Admins can create/delete clusters and add/remove nodes to scale the clusters. This role will be responsible for patching, securing and maintaining the clusters. As well as implementing Quotas between the different entities in the organization. The Kubernetes Admin is responsible for implementing the namespaces strategy defined by the Designer/Architect. These two roles and the actual developers using the clusters will also receive support and feedback from the enterprise security and network teams on issues such as security isolation requirements and how namespaces fit this model, or assistance with networking subnets and load-balancers setup.Anti-patternsIsolated Kubernetes usage “Islands” without centralized control: Without the initial investment in establishing a centralized control structure around Kubernetes management there is a risk of ending with a “mushroom farm” topology i.e. no defined size/shape/structure of clusters within the org. The result is a difficult to manage, higher risk and elevated cost due to underutilization of resources.Old-world IT controls choking usage and innovation: A common tendency is to try and transpose existing on-premises controls/procedures onto new dynamic frameworks .This results in weighing down the agile nature of these frameworks and nullifying the benefits of rapid dynamic deployments.Omni-cluster: Delaying the effort of creating the structure/mechanism for namespace management can result in one large omni-cluster that is hard to peel back into smaller usage groups. Use-case #2: Using Namespaces to partition development landscapesSoftware development teams customarily partition their development pipelines into discrete units. These units take various forms and use various labels but will tend to result in a discrete dev environment, a testing|QA environment, possibly a staging environment and finally a production environment. The resulting layouts are ideally suited to Kubernetes Namespaces. Each environment or stage in the pipeline becomes a unique namespace.The above works well as each namespace can be templated and mirrored to the next subsequent environment in the dev cycle, e.g. dev->qa->prod. The fact that each namespace is logically discrete allows the development teams to work within an isolated “development” namespace. DevOps (The closest role at Google is called Site Reliability Engineering “SRE”)  will be responsible for migrating code through the pipelines and ensuring that appropriate teams are assigned to each environment. Ultimately, DevOps is solely responsible for the final, production environment where the solution is delivered to the end-users.A major benefit of applying namespaces to the development cycle is that the naming of software components (e.g. micro-services/endpoints) can be maintained without collision across the different environments. This is due to the isolation of the Kubernetes namespaces, e.g. serviceX in dev would be referred to as such across all the other namespaces; but, if necessary, could be uniquely referenced using its full qualified name serviceX.development.mycluster.com in the development namespace of mycluster.com.Anti-patternsAbusing the namespace benefit resulting in unnecessary environments in the development pipeline. So; if you don’t do staging deployments, don’t create a “staging” namespace.Overcrowding namespaces e.g. having all your development projects in one huge “development” namespace. Since namespaces attempt to partition, use these to partition by your projects as well. Since Namespaces are flat, you may wish something similar to: projectA-dev, projectA-prod as projectA’s namespaces.Use-case #3: Partitioning of your CustomersIf you are, for example, a consulting company that wishes to manage separate applications for each of your customers, the partitioning provided by Namespaces aligns well. You could create a separate Namespace for each customer, customer project or customer business unit to keep these distinct while not needing to worry about reusing the same names for resources across projects.An important consideration here is that Kubernetes does not currently provide a mechanism to enforce access controls across namespaces and so we recommend that you do not expose applications developed using this approach externally.Anti-patternMulti-tenant applications don’t need the additional complexity of Kubernetes namespaces since the application is already enforcing this partitioning.Inconsistent mapping of customers to namespaces. For example, you win business at a global corporate, you may initially consider one namespace for the enterprise not taking into account that this customer may prefer further partitioning e.g. BigCorp Accounting and BigCorp Engineering. In this case, the customer’s departments may each warrant a namespace.When Not to use NamespacesIn some circumstances Kubernetes Namespaces will not provide the isolation that you need. This may be due to geographical, billing or security factors. For all the benefits of the logical partitioning of namespaces, there is currently no ability to enforce the partitioning. Any user or resource in a Kubernetes cluster may access any other resource in the cluster regardless of namespace. So, if you need to protect or isolate resources, the ultimate namespace is a separate Kubernetes cluster against which you may apply your regular security|ACL controls.Another time when you may consider not using namespaces is when you wish to reflect a geographically distributed deployment. If you wish to deploy close to US, EU and Asia customers, a Kubernetes cluster deployed locally in each region is recommended.When fine-grained billing is required perhaps to chargeback by cost-center or by customer, the recommendation is to leave the billing to your infrastructure provider. For example, in Google Cloud Platform (GCP), you could use a separate GCP Project or Billing Account and deploy a Kubernetes cluster to a specific-customer’s project(s).In situations where confidentiality or compliance require complete opaqueness between customers, a Kubernetes cluster per customer/workload will provide the desired level of isolation. Once again, you should delegate the partitioning of resources to your provider.Work is underway to provide (a) ACLs on Kubernetes Namespaces to be able to enforce security; (b) to provide Kubernetes Cluster Federation. Both mechanisms will address the reasons for the separate Kubernetes clusters in these anti-patterns. An easy to grasp anti-pattern for Kubernetes namespaces is versioning. You should not use Namespaces as a way to disambiguate versions of your Kubernetes resources. Support for versioning is present in the containers and container registries as well as in Kubernetes Deployment resource. Multiple versions should coexist by utilizing the Kubernetes container model which also provides for auto migration between versions with deployments. Furthermore versions scope namespaces will cause massive proliferation of namespaces within a cluster making it hard to manage.Caveat GubernatorYou may wish to, but you cannot create a hierarchy of namespaces. Namespaces cannot be nested within one another. You can’t, for example, create my-team.my-org as a namespace but could perhaps have team-org.Namespaces are easy to create and use but it’s also easy to deploy code inadvertently into the wrong namespace. Good DevOps hygiene suggests documenting and automating processes where possible and this will help. The other way to avoid using the wrong namespace is to set a kubectl context. As mentioned previously, Kubernetes does not (currently) provide a mechanism to enforce security across Namespaces. You should only use Namespaces within trusted domains (e.g. internal use) and not use Namespaces when you need to be able to provide guarantees that a user of the Kubernetes cluster or ones its resources be unable to access any of the other Namespaces resources. This enhanced security functionality is being discussed in the Kubernetes Special Interest Group for Authentication and Authorization, get involved at SIG-Auth. –Mike Altarace & Daz Wilkin, Strategic Customer Engineers, Google Cloud PlatformDownload KubernetesGet involved with the Kubernetes project on GitHub Post questions (or answer questions) on Stack Overflow Connect with the community on SlackFollow us on Twitter @Kubernetesio for latest updates
Quelle: kubernetes