Skip to content
This repository has been archived by the owner on Jan 11, 2023. It is now read-only.

Commit

Permalink
Update custom vnet doc (#2128)
Browse files Browse the repository at this point in the history
  • Loading branch information
JiangtianLi authored and jackfrancis committed Jan 23, 2018
1 parent 2e57c9c commit 5ad7fbb
Show file tree
Hide file tree
Showing 2 changed files with 3 additions and 1 deletion.
2 changes: 1 addition & 1 deletion docs/custom-vnet.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@ By doing this, you will be able to control the properties of the virtual network

*Note: This article describes the procedure with Docker Swarm but it will work in the exact same way with the all the orchestrators available with ACS Engine: Docker Swarm, Kubernetes and DC/OS.*

*For Kubernetes, the cluster should be deployed in the same resource group than the virtual network and the service principal you use for the cluster needs permissions on the VNET resource's group too*
*For Kubernetes, the cluster should be deployed in the same resource group than the virtual network and the service principal you use for the cluster needs permissions on the VNET resource's group too. Custom VNET for Kubernetes Windows cluster has a [known issue](https://github.com/Azure/acs-engine/issues/1767).*

## Prerequisites
You can run this walkthrough on OS X, Windows, or Linux.
Expand Down
2 changes: 2 additions & 0 deletions docs/kubernetes/features.md
Original file line number Diff line number Diff line change
Expand Up @@ -167,6 +167,8 @@ Per default Calico still allows all communication within the cluster. Using Kube

## Custom VNET

*Note: Custom VNET for Kubernetes Windows cluster has a [known issue](https://github.com/Azure/acs-engine/issues/1767).*

ACS Engine supports deploying into an existing VNET. Operators must specify the ARM path/id of Subnets for the `masterProfile` and any `agentPoolProfiles`, as well as the first IP address to use for static IP allocation in `firstConsecutiveStaticIP`. Please note that in any azure subnet, the first four and the last ip address is reserved and can not be used. Additionally, each POD now gets the IP address from the Subnet. As a result, for the master nodes, enough IP addresses (equal to `ipAddressCount`) should be available beyond `firstConsecutiveStaticIP`. By default, the `ipAddressCount` has a value of 30, and can be changed if desired. Furthermore, to prevent source address NAT'ing within the VNET, we assign to the `vnetCidr` property in `masterProfile` the CIDR block that represents the usable address space in the existing VNET.

See below profiles as an example:
Expand Down

0 comments on commit 5ad7fbb

Please sign in to comment.