# Terway CNI gives every Pod its own IP on Alibaba Cloud ENIs > terway is the self-developed CNI plugin for ACK, built on Elastic Network Interface, so each Pod gets its own IP and stack and cross-node traffic avoids encapsulation. The trade-off is a hard dependency on Alibaba Cloud networking, and one feature that does not travel to self-hosted clusters. **AliyunContainerService/terway** — CNI plugin for Alibaba Cloud VPC/ENI - Repository: https://github.com/AliyunContainerService/terway - Website: https://www.aliyun.com/product/kubernetes - Stars: 617 · Forks: 167 - Language: Go - License: Apache-2.0 - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/aliyuncontainerservice-terway ## Per-Pod addresses instead of a shared node network terway is a CNI plugin for ACK, the Alibaba Cloud managed Kubernetes service, built on top of Elastic Network Interface technology. Its central decision is that each Pod receives its own network stack and its own IP address rather than sharing the address space of the ECS instance it runs on. The README says this optimizes cloud resource usage and improves network performance, and the mechanism follows from the ENI model: an ENI is a virtual interface with its own IP set that attaches to an instance. Pods running on the same ECS instance talk to each other directly. Pods on different ECS instances send traffic straight through VPC ENIs, and the documentation is explicit that this avoids encapsulation with technologies like VxLAN. For a cluster on Alibaba Cloud, that means Pod IPs are VPC addresses, which is why the deprecated modes in the same project were once called VPC network mode and and why VPC routing survives only as the mechanism of that deprecated mode. The audience is narrow: teams already on ACK who have decided that cloud-native routing beats an overlay. ## Three ways to hand ENIs to Pods, one of them deprecated The feature list distinguishes three network arrangements. ENI network mode allocates ENIs to Pods for resource efficiency and network performance. Trunking lets Pods hold independent ENIs so security groups and vSwitch selection can be configured separately for each one. Node pool network mode configuration lets you reserve a node pool for exclusive ENI usage. Two older arrangements are listed as deprecated. VPC network mode, which reached VPC resources through VPC routing, is retired, and Exclusive ENI Mode, which attached an ENI directly to a Pod, is retired in favour of expressing the same idea at the node pool dimension. The migration advice in the README is therefore practical guidance rather than history: if you configured a cluster years ago, the configuration keys you are used to are the deprecated ones, and the supported path now runs through node pool configuration. That is also the sharpest limit on the project, because it is not a plugin you can evaluate on any Kubernetes cluster and assume the answer transfers. ## Security comes from two layers that can disagree The project supports both Kubernetes NetworkPolicy objects and traditional Alibaba Cloud security groups, and the README describes the combination as multi-dimensional control rather than one mechanism. The Kubernetes side covers container-to-container access control. The cloud side covers what the ENI itself is allowed to reach inside the VPC. This matters more in terway than in a typical plugin because each Pod holds a VPC-visible address, so cloud rules apply to Pod traffic directly rather than to a shared node address. The consequence is that a Pod can pass a NetworkPolicy check and still be unable to reach a service, because the security group attached to its ENI refuses the connection, or the reverse. The documentation does not walk through how the two layers are reconciled, so the debugging order is not spelled out anywhere in the README. A dual-stack note also appears in the features, with support for IPv4 and IPv6, which adds one more address dimension to reason about when policies and routes no longer line up as a simple IPv4 assumption. ## Building from source: the Makefile, build tags and the CNI dependency The README does not give an install procedure, and it does not point to a container image or a Helm chart for the plugin itself. The repository does carry a `charts` directory, a `deploy` directory, a `Makefile` and an `eni.conf` file at the top level. The module path and language version are fixed in `go.mod`. ```go module github.com/AliyunContainerService/terway ``` ```go go 1.26.2 ``` The build settings come from the Makefile, which fixes the privileged build tag and the target architectures, and names the registry that images are pushed to. ```bash GO_BUILD_TAGS ?= privileged BUILD_PLATFORMS ?= linux/amd64,linux/arm64 REGISTRY ?= registry.cn-hangzhou.aliyuncs.com/acs ``` The developer targets are ordinary Go tooling wrapped in make targets, so you can check formatting and run the vet pass with the same tag the release build uses. ```bash fmt: ## Run go fmt against code. go fmt ./... ``` ```bash vet: ## Run go vet against code. GOOS=linux go vet --tags "$(GO_BUILD_TAGS)" ./... ``` The test entry point pulls in two suites, and the quick variant regenerates manifests and deepcopy code before running. ```bash test: datapath-test test-quick ## Run tests. ``` The dependency list shows what the plugin is built from: the CNI specification library, netlink for interface manipulation, and nftables and iptables for the network policy path. ```go github.com/containernetworking/cni v1.1.2 ``` ```go github.com/vishvananda/netlink v1.3.1 ``` ```go github.com/google/nftables v0.2.0 ``` A working checkout should report a clean vet pass across linux/amd64 and linux/arm64, with the privileged tag enabled. ## Two release lines and an unusual version scheme The version numbers here need a word of explanation because they do not look like a normal single line. The visible releases are v1.8.19 on 2026-10-16, v1.17.7 on 2026-09-22 and v1.17.6 on 2026-08-20, so a 1.8 series and a 1.17 series were both published within a couple of months of each other. The README does not explain the split, so it is not safe to assume the higher number is the current line or to guess which one a new deployment should take. The safer reading is that the branches track different supported environments, and the project already documents one environment split explicitly: the versions provided by ACK are identical to the open source versions except that trunking is not available in self-hosted clusters. The last push to the repository was on 2026-10-19, three days after the v1.8.19 tag, which tells you the tree was still being worked on. It does not tell you which branch a given ACK release will pick up, and that is the question to ask before you pin. ## Licence, security reporting and the limits of the docs terway is published under the Apache License 2.0, which is permissive for commercial use and carries the usual requirement to preserve the licence and its notices. Vendoring the plugin into an image you distribute therefore does not create an obligation to publish your own source. The project also has a published route for security reports, with an address for vulnerabilities and a `SECURITY.md` file for details, which is a sign of a project with a real downstream in production clusters. Community contact runs through a DingTalk group, with the group id given in the README. What the documentation does not offer is any operational guidance beyond the feature list. There is no upgrade procedure, no rollback note, no guidance on draining a node before changing network mode, and no troubleshooting section that explains the interaction between an ENI that failed to attach and the Pod that is waiting on it. That thinness is the practical reason to treat terway as a component of ACK rather than an independent piece of infrastructure you can adopt on its own terms. ## Conclusion Adopt terway when your workloads run on ACK and you want per-Pod addresses, direct VPC reachability and NetworkPolicy without an overlay. Do not choose it for a self-hosted cluster if you need trunking, since that feature is unavailable outside ACK. Before committing, check that the ENI and security group quotas of your VPC can absorb one address per Pod, and confirm whether your platform still relies on the deprecated VPC network mode. ## FAQ ### What problem does terway solve for Alibaba Cloud Kubernetes clusters? It is the CNI plugin for ACK, built on Elastic Network Interface technology, so every Pod gets its own network stack and IP address. Cross-instance Pod traffic goes through VPC ENIs without VxLAN encapsulation. ### Can I use the terway trunking feature in a self-hosted Kubernetes cluster? No. The README states that the versions provided by ACK are identical to the open source versions except that the trunking feature is not available in self-hosted clusters. ### Does terway support NetworkPolicy and IPv6? Yes. The features list states support for NetworkPolicy alongside traditional Alibaba Cloud security groups, and dual-stack support for both IPv4 and IPv6. ### Which terway network modes are deprecated? VPC network mode, which reached VPC resources through VPC routing, and Exclusive ENI Mode are both listed as deprecated. The README points to node pool level configuration as the replacement for exclusive ENI usage. ## Sources - [AliyunContainerService/terway on GitHub](https://github.com/AliyunContainerService/terway) - [License: Apache-2.0](https://github.com/AliyunContainerService/terway/blob/main/LICENSE) - [Project website](https://www.aliyun.com/product/kubernetes) - [README](https://github.com/AliyunContainerService/terway/blob/main/README.md) - [Releases](https://github.com/AliyunContainerService/terway/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/aliyuncontainerservice-terway