Setting Up a Workstation

This topic provides the requirements and instructions to follow for configuring a workstation to use for creating and managing the EKS infrastructure. The workstation needs to be able to connect to the AWS API. It also needs to have the required AWS and Kubernetes (K8s) software packages as well as the deployment scripts and configuration files supplied by Altair. This workstation will be used to connect to the AWS API and provision the K8s cluster and node groups.

You can use the Graph Studio server as the workstation if the network routing and security policies permit the Graph Studio server to access the AWS and K8s APIs. When deciding whether to use the Graph Studio server as the K8s workstation, consider whether Graph Studio may be migrated to a different server or VPC in the future.

• Review the Requirements and Install the Software
• Download the Cluster Creation Scripts and Configuration Files

Review the Requirements and Install the Software

Component	Requirement
Operating System	The operating system for the workstation must be RHEL/CentOS 7.8 or later.
Networking	The workstation should be in the same VPC as the EKS cluster. If it is not in the same VPC, make sure that it is on a network that is routable from the cluster's VPC.
Software

• AWS-CLI Version 2 is recommended. Version 1.16.156 or later is supported. For instructions, see Install AWS-CLI below.
• EKSCTL Version 0.40.0 or later is required. For instructions, see Install EKSCTL below.
• Kubectl: Altair recommends that you use the same kubectl version as the EKS cluster version. For instructions, see Install Kubectl below.

| | CSI EKSCTL Package | Altair provides eksctl scripts and configuration files to use for provisioning the EKS cluster and node groups. Download the files to the workstation. See Download the Cluster Creation Scripts and Configuration Files for more information about the eksctl package. |

Install AWS-CLI

AWS CLI is the AWS command line interface. Version 2 is recommended. Follow the instructions below to install the latest aws-cli version 2 package. For more information, see Installing, Updating, and Uninstalling the AWS CLI Version 2 on Linux in the AWS CLI documentation.

1. Run the following command to download the latest aws-cli package to the current directory:

   curl "https://awscli.amazonaws.com/awscli-exe-linux-x86\_64.zip" -o "awscliv2.zip"

2. Run the following command to unzip the package:

   unzip awscliv2.zip

3. Then run the following command to run the install program. By default, the files are all installed to /usr/local/aws-cli, and a symbolic link is created in /usr/local/bin.

   sudo ./aws/install

Install EKSCTL

EKSCTL is the AWS EKS command line interface. Version 0.40.0 or later is required. Follow the instructions below to download the eksctl package and place it in the /usr/local/bin directory. For more information, see Installing eksctl in the Amazon EKS documentation.

1. Run the following command to download the eksctl package to the /tmp directory:

   curl --silent --location "https://github.com/weaveworks/eksctl/releases/download//eksctl_$(uname -s)_amd64.tar.gz" | tar xz -C /tmp

   Where is the release that you want to download. For example:

   curl --silent --location "https://github.com/weaveworks/eksctl/releases/download/0.40.0/eksctl\_$(uname -s)_amd64.tar.gz" | tar xz -C /tmp

2. Then run the following command to move eksctl to the /usr/local/bin directory:

   sudo mv /tmp/eksctl /usr/local/bin

Install Kubectl

Follow the instructions below to install kubectl on your workstation. Altair recommends that you install the same version of kubectl as the K8s cluster API. For more information, see Install and Set Up kubectl on Linux in the Kubernetes documentation.

1. Run the following cURL command to download the kubectl binary:

   curl -LO https://dl.k8s.io/release//bin/linux/amd64/kubectl

   Where is the version of kubectl to install. For example, the following command downloads version 1.19.12:

   curl -LO https://dl.k8s.io/release/v1.19.12/bin/linux/amd64/kubectl

2. Run the following command to make the binary executable:

   chmod +x ./kubectl

3. Run the following command to move the binary to your PATH:

   sudo mv ./kubectl /usr/local/bin/kubectl

4. To confirm that the binary is installed and that you can run kubectl commands, run the following command to display the client version:

   kubectl version --client

   The command returns the following type of information. For example:

   Client Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.12", GitCommit:"f3abc15296f3a3f54e4ee42e830c61047b13895f", GitTreeState:"clean", BuildDate:"2021-06-16T13:21:12Z", GoVersion:"go1.13.15", Compiler:"gc", Platform:"linux/amd64"}

Download the Cluster Creation Scripts and Configuration Files

The Cambridge Semantics GitHub repository, k8s-genesis (https://github.com/cambridgesemantics/k8s-genesis.git), includes all of the files that are needed to manage the configuration, creation, and deletion of the EKS cluster and node groups.

You can clone the repository to any location on the workstation or download the k8s-genesis package as a ZIP file, copy the file to the workstation, and extract the contents. The k8s-genesis directory includes three subdirectories (one for each supported Cloud Service Provider), the license information, and a readme file:

k8s-genesis ├── aws ├── azure ├── gcp ├── LICENSE └── README.md

Navigate to /aws/k8s/eksctl. The eksctl directory contains all of the EKS cluster and node group configuration files. You can remove all other directories from the workstation. The eksctl files and subdirectories are shown below:

eksctl ├── aws_cli_common.sh ├── common.sh ├── conf.d │   ├── iam_serviceaccounts.yaml │   ├── k8s_cluster.conf │   ├── nodepool_anzograph.yaml │   ├── nodepool_common.yaml │   ├── nodepool_dynamic.yaml │   ├── nodepool_operator.yaml │   └── nodepool.yaml ├── create_k8s.sh ├── create_nodepools.sh ├── delete_k8s.sh ├── delete_nodepools.sh ├── README.md ├── reference │   ├── ca_autodiscover-patch-file.yaml │   ├── ca_autodiscover.yaml │   ├── cluster-autoscaler-policy.json │   ├── nodepool_anzograph_tuner.yaml │   ├── nodepool_dynamic_tuner.yaml │   ├── versions │   └── warm_ip_target.yaml └── sample_use_cases ├── 1_existing_vpc_private_cluster │   └── k8s_cluster.conf ├── 2_new_vpc_public_cluster │   └── k8s_cluster.conf └── 3_nat_ha_private_cluster └── k8s_cluster.conf

The following list gives an overview of the files. Subsequent topics describe the files in more detail.

• The aws-cli-common.sh and common.sh scripts are used by the create*.sh and delete*.sh scripts during EKS cluster and node group creation and deletion.
• The conf.d directory contains the configuration files that supply the specifications to follow when creating the EKS cluster and node groups.
  • iam_serviceaccounts.yaml: Supplies optional IAM roles for Service Account specifications for use as part of cluster creation if you would like to assign permissions for the applications that run on EKS.
  • k8s_cluster.conf: Supplies the specifications for the EKS cluster.
  • nodepool_anzograph.yaml: Supplies the specifications for the AnzoGraph node group.
  • nodepool_common.yaml: Supplies the specifications for the Common node group.
  • nodepool_dynamic.yaml: Supplies the specifications for the Dynamic node group.
  • nodepool_operator.yaml: Supplies the specifications for the Operator node group.
  • nodepool.yaml: This file is supplied as a reference. It contains the superset of node group parameters and includes comments that provide additional information.
• The create_k8s.sh script is used to deploy the EKS cluster.
• The create_nodepools.sh script is used to deploy node groups in the EKS cluster.
• The delete_k8s.sh script is used to delete the EKS cluster.
• The delete_nodepools.sh script is used to remove node groups from the EKS cluster.
• The reference directory contains crucial files that are referenced by the cluster and node group creation scripts. The files in the directory should not be edited, and the reference directory must exist on the workstation at the same level as the create*.sh and delete*.sh scripts.
• The sample_use_cases directory contains sample EKS cluster configuration files that you can refer to or use as a template for configuring your EKS cluster depending on your use case:
  • The k8s_cluster.conf file in the 1_existing_vpc_private_cluster directory is a sample file for a use case where you want to deploy the EKS cluster in an existing VPC that does not have public internet access.
  • The k8s_cluster.conf file in the 2_new_vpc_public_cluster directory is a sample file for a use case where you want to deploy the EKS cluster into a new VPC with public internet access that is restricted to specific IP ranges.
  • The k8s_cluster.conf file in the 3_nat_ha_private_cluster directory is a sample file for a use case where you want to create a private EKS cluster in an existing VPC and deploy highly available NAT gateways.

Kubernetes Static Provisioning with AWS EFS CSI Driver (Addon Version > 2.0.0) and TLS Encryption

This README provides the sample raw YAML manifests for statically provisioning Amazon EFS on an EKS cluster using the EFS CSI driver (addon version 2.0.0 or later), which natively supports encryption in transit (TLS). It includes updated StorageClass, PersistentVolume (PV), and PersistentVolumeClaim (PVC) definitions for secure, static provisioning.

Prerequisites

• Amazon EFS file system and mount targets in the desired VPC/subnets.
• Optional but recommended: EFS Access Point for isolation and managed POSIX permissions.
• Creating and Assigning IAM Policies set up using either IRSA or node role.
• EKS nodes must be able to reach EFS mount targets (port 2049).
• EFS CSI driver (addon) version 2.0.0 or higher enabled on your EKS cluster.
• EFS automatically enforces encryption in transit by default in CSI driver >= 2.0.0 (no need for extra mount options or external proxy).
• AWS EFS CSI Addon Reference
• EFS Encryption in Transit

StorageClass YAML (for Static Provisioning)

For static provisioning, the StorageClass should typically be set to WaitForFirstConsumer and should not reference parameters such as provisioningMode or fileSystemId, as those are handled at the PV level.

apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: efs-static-sc provisioner: efs.csi.aws.com volumeBindingMode: WaitForFirstConsumer

PersistentVolume (PV) YAML

apiVersion: v1 kind: PersistentVolume metadata: name: efs-static-pv spec: capacity: storage: 5Gi volumeMode: Filesystem accessModes: - ReadWriteMany persistentVolumeReclaimPolicy: Retain storageClassName: efs-static-sc csi: driver: efs.csi.aws.com volumeHandle: fs-12345678::fsap-abcdef0123456789 # :: or fs-12345678 (if not using access point)

Replace fs-12345678 and fsap-abcdef0123456789 with your actual EFS FileSystemId and AccessPointId. You can omit ::fsap-... if NOT using access points.

PersistentVolumeClaim (PVC) YAML

apiVersion: v1 kind: PersistentVolumeClaim metadata: name: efs-static-pvc spec: accessModes: - ReadWriteMany storageClassName: efs-static-sc resources: requests: storage: 5Gi volumeName: efs-static-pv

Key Points

• Encryption in transit (TLS) is enforced by default on mount with EFS CSI Driver version >= 2.0.0; you do NOT need to specify `tls` in `mountOptions`.

• For static provisioning, the StorageClass is linked to manually created PVs; dynamic provisioning fields are omitted.

• Always use the correct volumeHandle format in the PV:

• For access points: fs-<filesystem-id>::fsap-<access-point-id>

• For just the filesystem: fs-<filesystem-id>

References

• Amazon EFS CSI Driver Official Docs
• EFS Encryption in Transit
• EFS Access Points
• EFS CSI Driver GitHub

Once the workstation is configured, see Planning the Graph Studio and EKS Network Architecture to review information about the network architecture that the eksctl scripts create. See Creating and Assigning IAM Policies for instructions on creating the IAM policies that are needed for assigning permissions to create and use the EKS cluster.