Amazon AWS 概念及相关操作步骤
AWS 虚拟私有云 VPC
在进入具体的网络配置前，必须理解 AWS 的地理隔离：
区域 (Region) ：地理上的独立区域（如新加坡、弗吉尼亚）。区域之间完全隔离。
可用区 (Availability Zone, AZ) ：一个区域内由多个物理机房组成。AZ 之间通过高速、低延迟光纤连接。高可用架构必须跨 AZ 部署。跨 AZ 之间的流量需要付费。
VPC 是你在 AWS 云中的逻辑隔离网络。你可以完全控制其 IP 地址范围、子网、路由表和网络网关。
核心组件：
CIDR 范围 ：你为 VPC 定义的私有 IP 地址块（如
10.0.0.0/16）。子网 (Subnets) ：将 VPC 划分为更小的网段。子网必须位于特定的可用区内。
公有子网 (Public Subnet) ：路由指向互联网网关 (IGW)，实例可以有公网 IP。
私有子网 (Private Subnet) ：没有指向 IGW 的直接路由，通常通过 NAT 网关 访问外网 。
公有子网 和 私有子网 在配置上几乎一摸一样，唯一区别在于： 该子网关联的路由表（Route Table）中默认路由（0.0.0.0/0）是如何配置的。
- 公有子网 (Public Subnet) 其路由表中默认路由（0.0.0.0/0）指向 互联网网关 (Internet Gateway, ID 格式通常为 igw-xxxxxx) 。由于它直接连接到互联网大门，且子网内的实例拥有公网 IP，因此外部用户可以主动访问它，它也可以直接访问外部。
- 私有子网 (Private Subnet) 其路由表中默认路由（0.0.0.0/0）指向 NAT 网关 (NAT Gateway, ID 格式通常为 nat-xxxxxx)，或者干脆没有任何去往外网的路由 。它没有直通互联网的大门。它通过 NAT 网关（单向出口）实现“能出不能进”的效果。
下图所示子网为 公有子网
- 路由表（Route Tables） 分为主路由表和自定义路由表
- 主路由表（Main route table） 随 VPC 自动生成，它控制未与任何其他路由表显式关联的所有子网的路由，也就是 VPC 中的默认路由。
- 自定义路由表 为新建的路由表。
- 一个子网只能关联一个路由表，一个路由表可以关联多个子网
流量如何进出
VPC 与外界互联网通信可以使用以下方式：
| 组件 | 作用 | 流量方向 | 用法说明｜ |
|---|---|---|---|
| Internet Gateway (IGW，互联网网关) | 允许 VPC 连接互联网。 | 双向 (In/Out) | 实例必须分配公网 IP 或弹性 IP (EIP) |
| NAT Gateway (NAT 网关) | 允许私有实例上外网，但防止外部主动连接。 | 单向 (Outbound only) | 仅需私有 IP |
| VPC Peering （对等连接） | 连接两个不同的 VPC，使其像在一个网络内通信。 | 跨 VPC | |
| Transit Gateway | 充当“中央枢纽”，连接数千个 VPC 和本地网络。 | 复杂网络拓扑 | |
| Virtual Private Gateway | 用于建立 VPN 连接。 | 混合云 |
部署 NAT Gateway 网关并关联子网
通过 NAT Gateway 可以实现子网中的实例的对外互联网出口 IP 都是 NAT Gateway 绑定的 EIP，子网中的实例对互联网不可见。NAT Gateway 典型使用场景：
- 为了安全，生产环境通常将 EKS 工作节点、RDS 数据库 或 缓存服务器（Redis） 放在私有子网中，这些资源不需要（也不应该）被互联网直接访问。
- 应用需要调用外部服务（如支付网关、银行接口或第三方 API）时，对方的防火墙通常需要你提供一个白名单 IP。由于 EKS 节点是动态变化的，IP 并不固定。
- 减少受攻击面，防止外部扫描。
以下为创建 NAT Gateway 并关联子网的相关步骤：
VPC |
关键点：
- NAT Gateway 必须在公有子网
- 私有子网的默认路由指向 NAT Gateway
确认 Public Subnet 存在
VPC 默认的 Main Route Table 已经满足这个条件，其默认网关为 Internet Gateway
创建 NAT Gateway
在 NAT gateways 标签页面中，点击 Create NAT gateway ， Connectivity type 选择 Public ， Elastic IP (EIP) association 选择 手动分配 EIP（Manual）
创建完成后，状态应为 Available 。在路由表（Route Tables）中，这时会多一个路由表，其 Edge associations（边缘关联） 关联到了刚刚创建的 NAT Gateway
创建一个新的子网（私有、Private Subnet）
在 VPC → Subnets → Create subnet 标签页面中创建新的子网， 不要勾选 Auto-assign public IPv4 ，如此处于此子网中的实例，不会为其分配公网地址
创建 Private Route Table
在 VPC → Route tables → Create route table 标签页面中创建新的路由表，本示例名为
private-rt配置路由规则
选择刚刚创建的新路由表
private-rt，在 Routes 中 编辑路由（Edit Routes） ，添加一条路由规则：| Destination | Target |
| ----------- | --------------- |
| 0.0.0.0/0 | NAT Gateway |
关联 Private Subnet
选择刚刚创建的新路由表
private-rt，在 Subnet associations(子网关联) 中 Edit subnet associations（编辑子网关联） ，选择目标子网进行关联
最终的 VPC 整体路由可以在 VPC 的 Resource map 中进行检查
EKS 中的授权机制
Kubernetes 原生提供 RBAC（Role-Based Access Control） 来控制集群中的 用户和服务账户（ServiceAccount） 对资源的访问权限。
| 对象 | 描述 |
|---|---|
| Role | 命名空间级别（Namespace）权限，指定某个命名空间内允许的操作和资源类型。 |
| ClusterRole | 集群级别权限，可以跨命名空间使用。 |
| RoleBinding | 将 Role 绑定到一个用户或 ServiceAccount。 |
| ClusterRoleBinding | 将 ClusterRole 绑定到一个用户或 ServiceAccount。 |
核心字段
apiGroups：资源所属 API 组，例如""代表 core API 。resources：允许访问的资源类型，如 pods、deployments。verbs：允许的操作，如get, list, create, delete。
RBAC 示例：
apiVersion: rbac.authorization.k8s.io/v1 |
RBAC 控制的是 Kubernetes 资源访问权限 。
RBAC 对象绑定的是 Kubernetes 用户或 ServiceAccount，而不是 AWS IAM 用户 。
| 概念 | 全称 | 解决的问题 | 作用范围 |
|---|---|---|---|
| RBAC | Role-Based Access Control | 决定 “用户/进程” 在 K8s 集群内能做什么（如：查看 Pod） | K8s 集群内部 |
| Role | Kubernetes Role | RBAC 的一部分，定义一组具体的集群内操作权限 | 命名空间 (Namespace) |
| IRSA | IAM Roles for Service Accounts | 决定 “Pod 里的应用” 对 AWS 外部资源（如 S3/RDS）的访问权限 | AWS 云环境 |
AWS IAM Role 是 AWS 层面的权限机制，用于授权 AWS 资源访问，例如 S3、DynamoDB、Secrets Manager 等。
AWS IAM Role 的特点：
可以被 IAM 用户、服务或 EC2/EKS Pod 假设（Assume）。
权限通过 IAM Policy 定义。
AWS IAM Role 在 EKS 中的应用:
管理集群本身访问 AWS 资源，例如节点组（NodeGroup）访问 S3。
可以通过 IAM 用户/Role 管理集群级别的操作权限，例如
eks:DescribeCluster。
💡 核心点：IAM Role 本身无法直接控制 Kubernetes 资源，它管理的是 AWS 资源访问。
IRSA（IAM Roles for Service Accounts） 是 AWS EKS 引入的将 Kubernetes ServiceAccount 与 AWS IAM Role 绑定，实现 Pod 级别的 AWS 权限控制的机制。其大致原理如下：
- EKS 集群开启 OIDC Provider
- 创建 IAM Role 并信任该 OIDC Provider
- Role 上定义 IAM Policy（如访问 S3）
- Kubernetes ServiceAccount 指定注解
eks.amazonaws.com/role-arn。 - Pod 使用该 ServiceAccount 时自动获取 Role 权限
实践建议：
不要在 Pod 内放 AWS AccessKey，使用 IRSA。
最小权限原则：
RBAC：只给 Pod 或用户真正需要的 Kubernetes 权限。
IAM Role / IRSA：只给访问 AWS 资源的最小权限。
多集群管理：可以通过 ClusterRole + RoleBinding 管理跨命名空间权限。
审计：
使用 CloudTrail 监控 IRSA 调用。
Kubernetes API Server 日志审计 RBAC 权限。
