Skip to content

docs: add cluster prerequisites and troubleshooting for node join - #247

Open
nnamuhcs wants to merge 1 commit into
Azure:mainfrom
nnamuhcs:docs/cluster-prerequisites
Open

docs: add cluster prerequisites and troubleshooting for node join#247
nnamuhcs wants to merge 1 commit into
Azure:mainfrom
nnamuhcs:docs/cluster-prerequisites

Conversation

@nnamuhcs

Copy link
Copy Markdown
Contributor

Summary

Follow-up to #244. That PR rewrote Getting Started into a guided quickstart for the node side. This PR adds the cluster-side setup that the node steps depend on, plus a Troubleshooting section.

Today the docs walk a user through generate-node-configinstallstart, but they don't mention the cluster-side components the agent needs. Against a plain AKS cluster, aks-flex-node start hangs and then fails with:

Error: create daemon credential provider: wait for daemon controller certificate: context deadline exceeded

The cause is that nothing approves the node's daemon certificate: the in-cluster aks-flex-controller (CSR approver) isn't deployed, or the machine isn't registered. The daemon CSRs (kubernetes.io/kube-apiserver-client) sit Pending and the agent times out.

What this PR adds

  • Prepare the cluster section, placed before the node steps, covering the three cluster-side requirements:
    1. a Flex-compatible CNI (Unbounded-Net), with a pointer to the lab guides;
    2. the aks-flex-controller deployed in kube-system with --enable-csr-approver=true (the checked-in manifest defaults to false), including the kubectl apply -k hack/controller-deployment/ command;
    3. a registered machine per node in the kube-system/aks-flex-machines ConfigMap, pointing to docs/design/in-cluster-machine.md and hack/e2e/.
  • Troubleshooting section that maps the certificate-timeout symptom and Pending CSRs to a missing or misconfigured controller, with the exact kubectl checks.

Documentation only; no code or command changes. Since the cluster-side setup is currently exercised mainly through hack/e2e, I'd welcome a maintainer sanity-check on the Prepare the cluster steps, and any preference on whether this belongs in the README quickstart or the lab guides.

The node steps assume an existing AKS cluster is already prepared with the
Flex Node cluster-side components (CNI, aks-flex-controller with the CSR
approver enabled, and a registered machine per node). On a plain cluster
that is not the case, and 'aks-flex-node start' fails with 'wait for daemon
controller certificate: context deadline exceeded'.

- Add a Prepare the cluster section listing the three cluster-side
  requirements, with the controller deploy command and pointers to the
  lab guides, controller-deployment assets, and design docs.
- Add a Troubleshooting section mapping the certificate-timeout symptom
  and Pending CSRs to the missing or misconfigured controller.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: a3bcbde4-d79a-489e-98fa-fcc66643363e
Copilot AI review requested due to automatic review settings July 21, 2026 18:26
@github-actions

Copy link
Copy Markdown

Thanks for the contribution! This pull request comes from a fork, so the Azure E2E workflow is intentionally skipped for security reasons.

Merge will remain blocked until the E2E tests have been run from a branch in the Azure/AKSFlexNode repository by a maintainer/contributor with access to this repo.

Maintainer options:

  1. Review the fork changes.
  2. Push the trusted commit to a branch in Azure/AKSFlexNode.
  3. Run the E2E Tests workflow from that same-repository branch, or open a same-repository PR so the workflow can run automatically.

We do not run Azure E2E directly from fork PR code because it requires Azure OIDC access.

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR updates the project’s primary quickstart documentation to include required cluster-side prerequisites for successfully joining Flex Nodes, and adds a focused Troubleshooting section for the most common node-join failure mode (daemon certificate approval timeouts).

Changes:

  • Adds a new Prepare the cluster section documenting cluster-side requirements (CNI, aks-flex-controller deployment, machine registration).
  • Adds a Troubleshooting section mapping wait for daemon controller certificate: context deadline exceeded to missing/disabled controller CSR approval or missing machine registration.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread README.md
Comment on lines +63 to +68
2. **The AKS Flex Controller** in `kube-system`, with the CSR approver enabled. It approves each node's daemon certificate and serves machine goal state. Deploy it from [`hack/controller-deployment/`](hack/controller-deployment/), ensuring the deployment runs with `--enable-csr-approver=true` (the checked-in manifest defaults to `false`):

```bash
kubectl apply -k hack/controller-deployment/
kubectl -n kube-system rollout status deployment/aks-flex-controller
```
Comment thread README.md
Comment on lines +354 to +355
# Is this node registered as a machine?
kubectl -n kube-system get configmap aks-flex-machines -o json | jq -r '.data | keys[]?'
Comment thread README.md

### Prepare the cluster

Before you join any nodes, the target AKS cluster must be set up with the Flex Node cluster-side components. A plain AKS cluster does **not** have them, and `aks-flex-node start` (Step 6) will hang, then fail with `wait for daemon controller certificate: context deadline exceeded` (see [Troubleshooting](#troubleshooting)).

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't hanging the process is true? We could say the lifecycle daemon controller will be in crashing state, but this is not blocking the kubelet bootstrapping

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and user can get it working by manually approving the CSR generated by the lifecycle daemon controller

Comment thread README.md
The cluster needs three things:

1. **A Flex-compatible CNI.** A default AKS CNI does not route pod traffic to Flex nodes. The validated CNI is [Unbounded-Net](https://github.com/Azure/unbounded); the [lab guides](docs/labs/README.md) create the cluster with `--network-plugin none` and install it.
2. **The AKS Flex Controller** in `kube-system`, with the CSR approver enabled. It approves each node's daemon certificate and serves machine goal state. Deploy it from [`hack/controller-deployment/`](hack/controller-deployment/), ensuring the deployment runs with `--enable-csr-approver=true` (the checked-in manifest defaults to `false`):

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we should remove mentioning for this aks-flex-controller because it's not expected to deploy on user's own

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants