**Bantu meningkatkan halaman ini ** 

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Untuk berkontribusi pada panduan pengguna ini, pilih GitHub ** tautan ** Edit halaman ini di yang terletak di panel kanan setiap halaman.

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

# Siapkan cluster Amazon EKS lokal di AWS Pos terdepan dikonfigurasi dengan penyimpanan instans EC2 untuk pemutusan jaringan
<a name="eks-outposts-instance-store-network-disconnects"></a>

Jika tautan layanan AWS Outposts yang menghubungkan jaringan lokal Anda ke AWS Cloud kehilangan konektivitas, Anda dapat terus menggunakan cluster Amazon EKS lokal Anda di Outpost. Topik ini mencakup cara mempersiapkan cluster lokal Anda untuk pemutusan jaringan dan pertimbangan terkait.
+ Cluster lokal memungkinkan stabilitas dan operasi lanjutan selama pemutusan jaringan sementara dan tidak direncanakan. AWS Outposts tetap merupakan penawaran yang terhubung sepenuhnya yang bertindak sebagai perpanjangan AWS Cloud di pusat data Anda. Jika jaringan terputus antara Outpost Anda dan AWS Cloud, kami sarankan mencoba memulihkan koneksi Anda. Untuk petunjuk, lihat daftar periksa [AWS pemecahan masalah jaringan rak Outposts ](https://docs.aws.amazon.com/outposts/latest/userguide/network-troubleshoot.html) di Panduan * AWS Pengguna Outposts. *
+ Pos terdepan memancarkan `ConnectedStatus` metrik yang dapat Anda gunakan untuk memantau status konektivitas Pos Terdepan Anda. Untuk informasi selengkapnya, lihat Metrik [ Pos Terdepan ](https://docs.aws.amazon.com/outposts/latest/userguide/outposts-cloudwatch-metrics.html#outposts-metrics) di Panduan Pengguna * AWS Pos Terdepan. *

## Otentikasi selama jaringan terputus
<a name="eks-outposts-instance-store-network-disconnects-authentication"></a>

Cluster lokal mendukung beberapa mekanisme otentikasi. Ketersediaannya selama pemutusan jaringan bervariasi:


| Mekanisme autentikasi | Tersedia selama pemutusan hubungan? | 
| --- | --- | 
|  AWS IAM (entri akses, `aws-auth` ConfigMap) | Tidak. IAM membutuhkan konektivitas ke Wil AWS ayah. | 
| OIDC (penyedia yang disediakan pelanggan) | Tergantung pada lokasi penyedia. Jika penyedia OIDC dapat dijangkau dari jaringan lokal Outpost, otentikasi terus berfungsi. | 
| sertifikat klien x.509 | Ya. Sertifikat divalidasi secara lokal oleh server API Kubernetes. | 
| IRSA (Peran IAM untuk Akun Layanan) | Tidak. Lihat[Identitas IRSA dan Pod selama pemutusan](#eks-outposts-instance-store-network-disconnects-irsa). | 
| Identitas Pod EKS | Tidak. Lihat[Identitas IRSA dan Pod selama pemutusan](#eks-outposts-instance-store-network-disconnects-irsa). | 

### sertifikat klien x.509
<a name="eks-outposts-instance-store-network-disconnects-x509"></a>

Untuk mempertahankan `kubectl` akses selama pemutusan jaringan, buat sertifikat x.509 klien sebelum pemutusan terjadi.

Untuk membuat sertifikat admin:

1. Hasilkan kunci pribadi dan permintaan penandatanganan sertifikat (CSR):

   ```
   openssl req -new -newkey rsa:4096 -nodes \
       -keyout admin.key -out admin.csr -subj "/CN=admin"
   ```

1. Buat `CertificateSigningRequest` sumber daya Kubernetes dan setujui:

   ```
   cat admin.csr | base64 | tr -d '\n' > admin.csr.b64
   ```

   ```
   apiVersion: certificates.k8s.io/v1
   kind: CertificateSigningRequest
   metadata:
     name: admin-csr
   spec:
     request: <base64-encoded-csr>
     signerName: kubernetes.io/kube-apiserver-client
     usages:
       - client auth
   ```

   ```
   kubectl apply -f admin-csr.yaml
   kubectl certificate approve admin-csr
   ```

1. Ambil sertifikat yang ditandatangani:

   ```
   kubectl get csr admin-csr -o jsonpath='{.status.certificate}' | base64 --decode > admin.crt
   ```

1. Buat `ClusterRoleBinding` untuk memberikan akses admin:

   ```
   kubectl create clusterrolebinding admin --clusterrole=cluster-admin \
       --user=admin --group=system:masters
   ```

1. Buat `kubeconfig` yang menggunakan sertifikat:

   ```
   kubectl config --kubeconfig admin.kubeconfig set-cluster my-cluster \
       --certificate-authority=ca.crt --server $APISERVER_ENDPOINT --embed-certs
   kubectl config --kubeconfig admin.kubeconfig set-credentials admin \
       --client-certificate=admin.crt --client-key=admin.key --embed-certs
   kubectl config --kubeconfig admin.kubeconfig set-context admin@my-cluster \
       --cluster my-cluster --user admin
   kubectl config --kubeconfig admin.kubeconfig use-context admin@my-cluster
   ```

### Resolusi DNS titik akhir cluster selama pemutusan
<a name="eks-outposts-instance-store-network-disconnects-cluster-dns"></a>

Titik akhir server API Kubernetes untuk cluster lokal dihosting di Amazon Route 53 dan diselesaikan ke alamat IP pribadi antarmuka jaringan elastis lintas akun (ENI) yang dibuat Amazon EKS di subnet Anda. ENI ini memiliki alamat IP pribadi statis yang tidak berubah selama operasi cluster normal.

Selama pemutusan jaringan, Outpost tidak dapat mencapai Route 53, sehingga nama host titik akhir cluster tidak diselesaikan kecuali Anda telah menyiapkan jalur resolusi lokal. Tiga kategori klien perlu mencapai server API:
+  **Administrator cluster ** berjalan`kubectl`.
+  **Worker node ** (`kubelet`) mengirimkan detak jantung node dan menarik spesifikasi.
+  **`kube-proxy`**pada setiap node, yang mengatur IP Layanan cluster.

#### Opsi 1: solusi DNS lokal (disarankan)
<a name="_option_1_local_dns_solution_recommended"></a>

 AWS merekomendasikan penerapan solusi DNS lokal yang menyimpan catatan titik akhir cluster dan melayaninya saat Outpost terputus. Anda dapat menjalankan server DNS Anda sendiri di lingkungan lokal yang menyimpan catatan titik akhir cluster dalam cache.

Jika Anda menggunakan solusi DNS lokal, sebaiknya arahkan AMI Anda `kubeconfig` dan node pekerja Anda ke nama host titik akhir cluster (bukan pada alamat IP ENI) sehingga resolusi konsisten dengan solusi DNS lokal.

#### Opsi 2: IP-based akses statis
<a name="_option_2_static_ip_based_access"></a>

Jika Anda tidak ingin menjalankan solusi DNS lokal, Anda dapat menggunakan IP-based akses statis.
+  **Administrator: ** Konfigur `kubeconfig` asikan agar mengarah langsung ke alamat IP pribadi ENI lintas akun. Temukan ENI dengan mencari antarmuka jaringan dengan deskripsi `Amazon EKS {{cluster-name}} ` di AWS akun Anda. Setiap alamat IP ENI stabil selama masa pakai cluster dalam operasi normal.
+  **Node pekerja (AMI yang dioptimalkan Amazon EKS): ** Saat Anda meluncurkan node pekerja dari AMI yang dioptimalkan Amazon EKS, skrip bootstrap menambahkan titik akhir cluster ke `/etc/hosts` alamat IP ENI. Tidak diperlukan konfigurasi tambahan.
+  **Node pekerja (AMI khusus): ** Tambahkan nama host titik akhir cluster dan alamat IP ENI ke `/etc/hosts` dalam bootstrap kustom Anda. Jika tidak, `kubelet` dan tidak `kube-proxy` dapat menjangkau server API selama pemutusan hubungan.

**penting**  
Jika ENI lintas akun dihapus atau alamat IP-nya berubah — misalnya, jika Anda menghapusnya atau memodifikasinya dengan cara yang mencegah Amazon EKS melampirkannya kembali — setiap node dan setiap administrator yang menggunakan IP-based akses statis harus diperbarui secara manual. Dengan solusi DNS lokal, tidak diperlukan intervensi manual.

### Resolusi Pod DNS selama pemutusan
<a name="eks-outposts-instance-store-network-disconnects-pod-dns"></a>

Untuk mencegah kegagalan DNS selama operasi terputus, konfigurasikan template peluncuran node pekerja Anda untuk mengganti `kubelet’s `resolvConf` setelan. Di data pengguna Anda, buat `resolv.conf` file khusus (misalnya,`/etc/kubernetes/resolv.conf`) yang hanya berisi `nameserver 10.0.0.2` (tanpa domain pencarian VPC), lalu atur `spec.kubelet.config.resolvConf: /etc/kubernetes/resolv.conf` di file Anda. `NodeConfig` Ini menghapus domain ` {{region-code}}.compute.internal` pencarian dari konfigurasi DNS pod, mencegah kueri diteruskan ke resolver DNS VPC yang tidak dapat dijangkau saat terputus.

Contoh berikut menunjukkan data pengguna node pekerja:

```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="BOUNDARY"

--BOUNDARY
Content-Type: text/x-shellscript; charset="us-ascii"

#!/bin/bash
mkdir -p /etc/kubernetes
echo "nameserver 10.0.0.2" > /etc/kubernetes/resolv.conf

--BOUNDARY
Content-Type: application/node.eks.aws

---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
  cluster:
    name: my-cluster
    ...
  kubelet:
    config:
      resolvConf: /etc/kubernetes/resolv.conf

--BOUNDARY--
```

### Identitas IRSA dan Pod selama pemutusan
<a name="eks-outposts-instance-store-network-disconnects-irsa"></a>

**penting**  
IRSA dan EKS Pod Identity bergantung pada AWS STS, yang berjalan di Wil AWS ayah. Selama pemutusan jaringan, beban kerja yang menggunakan IRSA atau Pod Identity tidak dapat memperoleh kredenSIAL baru. KredenSIAL yang ada kedaluwarsa setelah jangka waktu tertentu.

Kami tidak merekomendasikan mengambil dependensi fungsional atau operasional pada Region-based AWS layanan untuk beban kerja yang harus tetap tersedia selama pemutusan jaringan.

## ``perilaku etcd selama pemutusan
<a name="eks-outposts-instance-store-network-disconnects-etcd"></a>

Selama jaringan terputus, `etcd` snapshot tidak dapat dicadangkan. Jika lebih dari satu `etcd` instans menjadi tidak tersedia selama pemutusan hubungan, kuor `etcd` um hilang dan operasi API Kubernetes tidak tersedia sampai Outpost Anda terhubung kembali dan kuorum telah dipulihkan. `etcd` Beban kerja yang sudah berjalan terus beroperasi.

## Kontrol pencatatan pesawat selama pemutusan
<a name="eks-outposts-instance-store-network-disconnects-cp-logs"></a>

Selama pemutusan jaringan, log bidang kontrol di-cache secara lokal pada instance bidang kontrol. Saat konektivitas dipulihkan, log dikirim ke Amazon CloudWatch Logs di Wil AWS ayah induk. Anda tidak perlu menginstal atau memelihara agen logging apa pun di bidang kontrol.

## Pengamatan lokal
<a name="eks-outposts-instance-store-network-disconnects-local-observability"></a>

Anda dapat memantau cluster secara lokal selama pemutusan koneksi dengan menggunakan [ Prometheus](https://prometheus.io/), [ Grafana](https://grafana.com/), atau solusi pihak ketiga lainnya untuk mengikis titik akhir metrik server API Kubernetes.

## Repositori gambar lokal
<a name="eks-outposts-instance-store-network-disconnects-image-repo"></a>

Untuk menskalakan penerapan dengan replika tambahan atau memulihkan dari kegagalan pod selama pemutusan, Anda harus memiliki repositori image kontainer lokal (seperti registri Docker), atau gambar harus di-cache pada node sebelum pemutusan. Amazon ECR tidak tersedia selama pemutusan jaringan.

## Menyetel perilaku failover pod Kubernetes
<a name="eks-outposts-instance-store-network-disconnects-pod-failover"></a>

Selama pemutusan jaringan, bidang kontrol Kubernetes tidak dapat berkomunikasi dengan Wilayah. AWS Jika node menjadi tidak dapat dijangkau, perilaku Kubernetes default adalah mengusir pod setelah periode batas waktu. Anda dapat menyetel perilaku ini menggunakan toleransi dan `tolerationSeconds` spesifikasi pod untuk mengontrol seberapa cepat pod dijadwal ulang selama partisi. Untuk panduan dan contoh terperinci, lihat https://docs.aws.amazon.com/eks/latest/best-practices/hybrid-nodes-network-disconnection-best-practices.html \# * tune\_kubernetes\_pod\_failover\_behavior [Menyetel perilaku failover pod Kubernetes] di Panduan Praktik Terbaik \_Amazon EKS. *

## Simulasikan pemutusan jaringan
<a name="eks-outposts-instance-store-network-disconnects-simulate"></a>

Sebelum Anda masuk ke produksi dengan cluster lokal Anda, simulasikan pemutusan untuk memverifikasi bahwa Anda dapat mengakses cluster saat berada dalam keadaan terputus.

1. Terapkan aturan firewall pada perangkat jaringan yang menghubungkan Pos Terdepan Anda ke Wil AWS ayah. Ini memutuskan tautan layanan Pos Terdepan.

1. Uji koneksi ke cluster lokal Anda menggunakan sertifikat x.509 yang Anda buat:

   ```
   kubectl --kubeconfig admin.kubeconfig get nodes
   ```

**catatan**  
Jika Anda memiliki layanan yang sudah diproduksi di Outpost Anda, jangan mensimulasikan pemutusan. Memutuskan sambungan layanan akan mempengaruhi semua layanan yang berjalan di Outpost.