colemickens/azure-kubernetes-status

Status of Kubernetes on Azure (DEPRECATED! See https://github.com/Azure/ACS)

azure-kubernetes-status's Issues

Add/update status information about AzurePersistentDisk

See: https://huaminchen.wordpress.com/2016/08/01/use-azure-block-storage-comming-to-kubernetes/

Corresponding issue for demo repo: colemickens/azure-kubernetes-demo#1

Add information about khenidak/kubernetes-azure

See: https://github.com/khenidak/kubernetes-azure

cc: @khenidak

Azure subnet reserved IPs

Does the Azure cloud provider correctly assign the pod-cidrs taking into account that Azure reserves some IPs on each subnet? I ask this because I think I ran into this issue while manually creating subnets before Kube 1.4.

Azure documentation:

Are there any restrictions on using IP addresses within these subnets?
Azure reserves some IP addresses within each subnet. The first and last IP addresses of the subnets are reserved for protocol conformance, along with 3 more addresses used for Azure services.

I created subnet 10.2.10.0/24 for a node's podCIDR and specified --pod-cidr=10.2.10.0/24 but this pod in particular could not be routed:

Name:       ...
Namespace:  ...
Node:       10.0.3.10/10.0.3.10
Start Time: Fri, 09 Sep 2016 10:02:02 +0100
Labels:     ...
Status:     Running
IP:     10.2.10.4

10.2.10.4 is still a reserved IP, right?

Azure Platform: Only 5 Frontend IPConfigurations are allowed

Currently, Azure ARM limits you to 5 frontend ipconfigurations per load balancer, and allows you to raise that limit to 30 by contacting support.

These limits seems low.

@theobolo (and any other users): Can you please comment on your deployment metrics - avg cluster size (number of machines, vm size) as well as the number of external-facing Services you have deployed.

---

This issue is relevant to:

• Kubernetes 1.4 users using the native Azure cloudprovider support
• Users who are manually reconfiguring the Azure loadbalancer in front of a VMSS

Clarify limitations of Azure Load Balancers in Kubernetes in combination with Availabilitty Sets

Today I got two different errors when trying to use the Azure Cloud Provider and a service of type LoadBalancer. Unfortunately I did not make a copy of the log output. Basically the errors told me that there are limitations when using LBs in combination with Availability Sets.

In my current deployment, I have 2 Availability Sets. One for the master nodes and one for the minion nodes. If I understand the cloud provider correctly, it tries to add all nodes to the Azure LB and then fails because the nodes are not in the same Availability Sets.

Can someone clarify the limitations here? Would it be possible to have more control about the behaviour of the Azure cloud provider? For example, only attach nodes to the LB when they have a desired label set? Or would it be possible that the cloud provider creates one LB per Availability Set?

This repo will be deleted. Please see https://github.com/Azure/AKS

This repo will be deleted. Please see https://github.com/Azure/AKS.

Add information about DXFrance/AzureKubernetes

Document this alongside the other bring-ups.

https://blogs.msdn.microsoft.com/stephgou/2016/07/11/kubernetes-cluster-automated-deployment-on-azure-first-step/

https://github.com/DXFrance/AzureKubernetes

CC: @stephgou

Recommended way to deploy a production ready cluster

Hi.

I can see in the description that one of the recommended deployment option is to use Azure Container Service.

I tested it, it indeed deploy a full featured cluster but with only one master. So there cluster is, in my opinion, not really production ready.

For you, what is the best solution today to deploy a production ready kubernetes on azure ?

Rgds.

kubernetes on azure is broken with docker version 1.13.0

I see that Kubernetes v1.5.1 is deployed on azure nodes and I am hitting the below bug.

kubernetes/kubeadm#102

Kube version:

Client Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.1", GitCommit:"82450d03cb057bab0950214ef122b67c83fb11df", GitTreeState:"clean", BuildDate:"2016-12-14T00:57:05Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.1", GitCommit:"82450d03cb057bab0950214ef122b67c83fb11df", GitTreeState:"clean", BuildDate:"2016-12-14T00:52:01Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"}

Question : how to upgrade a cluster in Azure ACS ?

Now that the recommended way of deploying a cluster is by using ACS, is there a recommended way to upgrade an existing kubernetes cluster ?

Right now, all the cluster I deployed were in 1.4.6 but I would like to benefit from the great work you made with 1.5 in azure.

Take advantage of local node disks for data that can be recreated

Since nodes have a fast local disk attached, wouldn't it be possible to store docker images and/or container filesystems in this disk? Upon a restart containers are recreated anyway and images can be fetched again.

Virtual Machine Scale Set Support

Hi Cole,

This repo is great by the way, good to see a sort of road map or to-do list! :)

I'm wondering what's needed here in terms of supporting Scale Sets? I'm just having a look at some of the code in the Azure Cloud Provider and the only code i can see is this. Is there some work that needs to be done in the way persistent disks are managed too? I'm interested in picking this up :)

Clarify path forward for Kubernetes 1.4 on Azure (kube-anywhere/kube-up/etc)

Right now, kube-up uses azkube, but most of the effort invested for Kubernetes 1.4 is around kubernetes-anywhere.

This issue will track updating this status once the path forward for kube-up and kubernetes-anywhere is determined. That should be known by the end of this week. (Aug 7th, 2016).