Tool used to deploy and bootstrap a Kubernetes cluster in Azure.
```
docker run -it \
colemickens/azkube:latest /opt/azkube/azkube \
--tenant-id="{your tenant id}" \
--subscription-id="{subscription id}"
```
[ insert generated output from cobra's command facilities ]
- Existing shell script was fragile.
- azure-xplat-cli changes out from underneath of us, and is slow, and doesn't handle errors well.
- Need a tool and process to create service principals and configure them appropriately.
- Need a tool to consume scripts, interweave ARM template variables/parameters, and output a "deployable" template.
As Azure lands support for managed service identity and metadata facilities, some of the need for this tool will be alleviated.
- Needs tests
scale
is not implementeddestroy
is not implemented
- Add an Ubuntu 16.04 Flavor (lets us avoid
upstart
) - Validate
location
,master-size
,node-size
against the live services
-
kube-controller-manager
seems to flat out ignore mykubeconfig
file. The other components all read thekubeconfig
file and connect correctly. Skimming the source, I see a lack of warning about missingkubeconfig
file, and no permission or opening errors, so I'm wondering if there's a bug in thehyperkube:v1.1.8
image. -
As a result of #1, the insecure port is still open on the apiserver. (Though it is firewalled to the outside world.
-
The user who executes the application must have permission to provision additional applications. This is difficult to achieve unless you're using the device auth method (
--auth-method=device
which is the default). If you wish to automate the use of this tool to remove all interactivity, you must create a new Application in your Azure Active Directory Tenant. Then you must use the ADAL Powershell Toolkit to grant the service principal associated with the application the AD Role "Company User". -
The resulting "templates" are fully parameterized and generic. They can be uploaded and used by others. The values that are entered for the parameters are interpolated into the cloud-config scripts which are then interpolated into the ARM Templates. These are copied to the deployment directory so that they might be reused (if desired).