A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://docs.aws.amazon.com/eks/latest/userguide/launch-windows-workers.html below:

Create self-managed Microsoft Windows nodes

Create self-managed Microsoft Windows nodes

This topic describes how to launch Auto Scaling groups of Windows nodes that register with your Amazon EKS cluster. After the nodes join the cluster, you can deploy Kubernetes applications to them.

Important

Enable Windows support for your cluster. We recommend that you review important considerations before you launch a Windows node group. For more information, see Enable Windows support.

You can launch self-managed Windows nodes with either of the following:

eksctl

Launch self-managed Windows nodes using eksctl

This procedure requires that you have installed eksctl, and that your eksctl version is at least 0.210.0. You can check your version with the following command.

eksctl version

For instructions on how to install or upgrade eksctl, see Installation in the eksctl documentation.

Note

This procedure only works for clusters that were created with eksctl.

  1. (Optional) If the AmazonEKS_CNI_Policy managed IAM policy (if you have an IPv4 cluster) or the AmazonEKS_CNI_IPv6_Policy (that you created yourself if you have an IPv6 cluster) is attached to your Amazon EKS node IAM role, we recommend assigning it to an IAM role that you associate to the Kubernetes aws-node service account instead. For more information, see Configure Amazon VPC CNI plugin to use IRSA.

  2. This procedure assumes that you have an existing cluster. If you don’t already have an Amazon EKS cluster and an Amazon Linux node group to add a Windows node group to, we recommend that you follow Get started with Amazon EKS – eksctl. This guide provides a complete walkthrough for how to create an Amazon EKS cluster with Amazon Linux nodes.

    Create your node group with the following command. Replace region-code with the AWS Region that your cluster is in. Replace my-cluster with your cluster name. The name can contain only alphanumeric characters (case-sensitive) and hyphens. It must start with an alphanumeric character and can’t be longer than 100 characters. The name must be unique within the AWS Region and AWS account that you’re creating the cluster in. Replace ng-windows with a name for your node group. The node group name can’t be longer than 63 characters. It must start with letter or digit, but can also include hyphens and underscores for the remaining characters. You can replace 2019 with 2022 to use Windows Server 2022. Replace the rest of the example values with your own values.

    Important

    To deploy a node group to AWS Outposts, AWS Wavelength, or AWS Local Zone subnets, don’t pass the AWS Outposts, Wavelength, or Local Zone subnets when you create the cluster. Create the node group with a config file, specifying the AWS Outposts, Wavelength, or Local Zone subnets. For more information, see Create a nodegroup from a config file and Config file schema in the eksctl documentation.

    eksctl create nodegroup \
    --region region-code \
    --cluster my-cluster \
    --name ng-windows \
    --node-type t2.large \
    --nodes 3 \
    --nodes-min 1 \
    --nodes-max 4 \
    --managed=false \
    --node-ami-family WindowsServer2019FullContainer

    Note

    An example output is as follows. Several lines are output while the nodes are created. One of the last lines of output is the following example line.

    [✔]  created 1 nodegroup(s) in cluster "my-cluster"

  3. (Optional) Deploy a sample application to test your cluster and Windows nodes.

  4. We recommend blocking Pod access to IMDS if the following conditions are true:

    For more information, see Restrict access to the instance profile assigned to the worker node.

AWS Management Console

Prerequisites

Step 1: Launch self-managed Windows nodes using the AWS Management Console

  1. Wait for your cluster status to show as ACTIVE. If you launch your nodes before the cluster is active, the nodes fail to register with the cluster and you need to relaunch them.

  2. Open the AWS CloudFormation console

  3. Choose Create stack.

  4. For Specify template, select Amazon S3 URL.

  5. Copy the following URL and paste it into Amazon S3 URL.

    https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2023-02-09/amazon-eks-windows-nodegroup.yaml

  6. Select Next twice.

  7. On the Quick create stack page, enter the following parameters accordingly:

  8. Acknowledge that the stack might create IAM resources, and then choose Create stack.

  9. When your stack has finished creating, select it in the console and choose Outputs.

  10. Record the NodeInstanceRole for the node group that was created. You need this when you configure your Amazon EKS Windows nodes.

Step 2: Enable nodes to join your cluster

  1. Check to see if you already have an aws-auth ConfigMap.

    kubectl describe configmap -n kube-system aws-auth

  2. If you are shown an aws-auth ConfigMap, then update it as needed.

    1. Open the ConfigMap for editing.

      kubectl edit -n kube-system configmap/aws-auth

    2. Add new mapRoles entries as needed. Set the rolearn values to the NodeInstanceRole values that you recorded in the previous procedures.

      [...]
data:
  mapRoles: |
- rolearn: <ARN of linux instance role (not instance profile)>
      username: system:node:{{EC2PrivateDNSName}}
      groups:
        - system:bootstrappers
        - system:nodes
    - rolearn: <ARN of windows instance role (not instance profile)>
      username: system:node:{{EC2PrivateDNSName}}
      groups:
        - system:bootstrappers
        - system:nodes
        - eks:kube-proxy-windows
[...]

    3. Save the file and exit your text editor.

  3. If you received an error stating "Error from server (NotFound): configmaps "aws-auth" not found, then apply the stock ConfigMap.

    1. Download the configuration map.

      curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm-windows.yaml

    2. In the aws-auth-cm-windows.yaml file, set the rolearn values to the applicable NodeInstanceRole values that you recorded in the previous procedures. You can do this with a text editor, or by replacing the example values and running the following command:

      sed -i.bak -e 's|<ARN of linux instance role (not instance profile)>|my-node-linux-instance-role|' \
    -e 's|<ARN of windows instance role (not instance profile)>|my-node-windows-instance-role|' aws-auth-cm-windows.yaml

      Important

      • Don’t modify any other lines in this file.

      • Don’t use the same IAM role for both Windows and Linux nodes.

    3. Apply the configuration. This command might take a few minutes to finish.

      kubectl apply -f aws-auth-cm-windows.yaml

  4. Watch the status of your nodes and wait for them to reach the Ready status.

    kubectl get nodes --watch

    Enter Ctrl+C to return to a shell prompt.

    If nodes fail to join the cluster, then see Nodes fail to join cluster in the Troubleshooting chapter.

Step 3: Additional actions

  1. (Optional) Deploy a sample application to test your cluster and Windows nodes.

  2. (Optional) If the AmazonEKS_CNI_Policy managed IAM policy (if you have an IPv4 cluster) or the AmazonEKS_CNI_IPv6_Policy (that you created yourself if you have an IPv6 cluster) is attached to your Amazon EKS node IAM role, we recommend assigning it to an IAM role that you associate to the Kubernetes aws-node service account instead. For more information, see Configure Amazon VPC CNI plugin to use IRSA.

  3. We recommend blocking Pod access to IMDS if the following conditions are true:

    For more information, see Restrict access to the instance profile assigned to the worker node.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4