Kubernetes Submit Queue 3b787c9b3d Merge pull request #34526 from colemickens/colemickens-azure-specify-availabilityset
Automatic merge from submit-queue

azure: filter load balancer backend nodes to PrimaryAvailabilitySet (if set)

<!--  Thanks for sending a pull request!  Here are some tips for you:
1. If this is your first time, read our contributor guidelines https://github.com/kubernetes/kubernetes/blob/master/CONTRIBUTING.md and developer guide https://github.com/kubernetes/kubernetes/blob/master/docs/devel/development.md
2. If you want *faster* PR reviews, read how: https://github.com/kubernetes/kubernetes/blob/master/docs/devel/faster_reviews.md
3. Follow the instructions for writing a release note: https://github.com/kubernetes/kubernetes/blob/master/docs/devel/pull-requests.md#release-notes
-->

**What this PR does / why we need it**:
- Adds a new field (`PrimaryAvailabilitySetName`) to the Azure CloudProvider config struct
- If the field is set, only machines who are in that availabilitySet are added to the load balancer backend pool.

This is required to:
- Support more than 100 nodes in Azure (only can have 100 nodes per availability set)
- Support multiple availability sets per cluster (An Azure L4 LoadBalancer can only be pointed at nodes in a single availability set)

Without this PR, or if the field is **not** set in a cluster that contains two availabilitysets, then the following is observed:
- Azure resources are created (LB, LB rules, NSG rules, public IP)
- Azure throws errors when trying to add nodes from the "other" availability set
- The service winds up exposed to the outside world (if you manually retrieve the public ip from Azure API)
- Kubernetes controller-manager's service loop keeps retrying forever because it never finishes fully successfully
- The "external ip" property field is never updated.

**Which issue this PR fixes**: Fixes #34293

**Unknowns**:
- Naming convention: `LoadBalancedAvailabilitySet` might be more descriptive than `PrimaryAvailabilitySet`, but is also a misnomer since `kube-proxy` will still end up routing requests to all relevant nodes.
- Is it worth trying to be "smart" about it in the case the user hasn't set this field in the config? Save the first availability set name and try not to add any nodes that aren't also in that one? It may simply be better to just let this fail so the user has to choose the right setting for their use-case.

**Release note**:
<!--  Steps to write your release note:
1. Use the release-note-* labels to set the release note state (if you have access) 
2. Enter your extended release note in the below block; leaving it blank means using the PR title as the release note. If no release note is required, just write `NONE`. 
-->
```release-note
azure: add PrimaryAvailabilitySet to config, only use nodes in that set in the loadbalancer pool
```

CC: @brendandburns, @anhowe
2016-10-13 02:23:21 -07:00
2016-10-10 12:04:24 -07:00
2016-09-20 21:55:41 -04:00
2016-08-16 23:06:21 -07:00

Kubernetes

Submit Queue Widget GoDoc Widget Coverage Status Widget

Are you ...


Kubernetes is an open source system for managing containerized applications across multiple hosts, providing basic mechanisms for deployment, maintenance, and scaling of applications.

Kubernetes is:

  • lean: lightweight, simple, accessible
  • portable: public, private, hybrid, multi cloud
  • extensible: modular, pluggable, hookable, composable
  • self-healing: auto-placement, auto-restart, auto-replication

Kubernetes builds upon a decade and a half of experience at Google running production workloads at scale, combined with best-of-breed ideas and practices from the community.


Kubernetes is ready for Production!

With the 1.0.1 release Kubernetes is ready to serve your production workloads.

Kubernetes can run anywhere!

You can run Kubernetes on your local workstation under Vagrant, cloud providers (e.g. GCE, AWS, Azure), and physical hardware. Essentially, anywhere Linux runs you can run Kubernetes. Checkout the Getting Started Guides for details.

Concepts

Kubernetes works with the following concepts:

Cluster
A cluster is a set of physical or virtual machines and other infrastructure resources used by Kubernetes to run your applications. Kubernetes can run anywhere! See the Getting Started Guides for instructions for a variety of services.
Node
A node is a physical or virtual machine running Kubernetes, onto which pods can be scheduled.
Pod
Pods are a colocated group of application containers with shared volumes. They're the smallest deployable units that can be created, scheduled, and managed with Kubernetes. Pods can be created individually, but it's recommended that you use a replication controller even if creating a single pod.
Replication controller
Replication controllers manage the lifecycle of pods. They ensure that a specified number of pods are running at any given time, by creating or killing pods as required.
Service
Services provide a single, stable name and address for a set of pods. They act as basic load balancers.
Label
Labels are used to organize and select groups of objects based on key:value pairs.

Documentation

Kubernetes documentation is organized into several categories.

Community, discussion, contribution, and support

See which companies are committed to driving quality in Kubernetes on our community page.

Do you want to help "shape the evolution of technologies that are container packaged, dynamically scheduled and microservices oriented?"

You should consider joining the Cloud Native Computing Foundation. For details about who's involved and how Kubernetes plays a role, read their announcement.

Code of conduct

Participation in the Kubernetes community is governed by the Kubernetes Code of Conduct.

Are you ready to add to the discussion?

We have presence on:

You can also view recordings of past events and presentations on our Media page.

For Q&A, our threads are at:

Want to contribute to Kubernetes?

If you're interested in being a contributor and want to get involved in developing Kubernetes, start in the Kubernetes Developer Guide and also review the contributor guidelines.

Or, if you just have an idea for a new feature, see the Kubernetes Features repository for details on how to propose it.

Also, please see our expectations for members of the Kubernetes community.

Support

While there are many different channels that you can use to get ahold of us, you can help make sure that we are efficient in getting you the help that you need.

If you need support, start with the troubleshooting guide and work your way through the process that we've outlined.

That said, if you have questions, reach out to us one way or another. We don't bite!

Community resources

You can find more projects, tools and articles related to Kubernetes on the awesome-kubernetes list. Add your project there and help us make it better.

Instructive & educational resources for the Kubernetes community. By the community.

  • Community Documentation

Here you can learn more about the current happenings in the kubernetes community.

Analytics

Description
Production-Grade Container Scheduling and Management
Readme Apache-2.0 1.3 GiB
Languages
Go 97%
Shell 2.6%
PowerShell 0.2%