Cloud Composer 1 | Cloud Composer 2 | Cloud Composer 3
Halaman ini menjelaskan cara menggunakan KubernetesPodOperator
untuk men-deploy
Pod Kubernetes
dari Cloud Composer ke Google Kubernetes Engine
yang merupakan bagian dari lingkungan Cloud Composer Anda dan untuk memastikan
bahwa lingkungan Anda memiliki
sumber daya yang sesuai.
KubernetesPodOperator
peluncuran
Pod Kubernetes
di cluster lingkungan Anda. Sebagai perbandingan,
Operator Google Kubernetes Engine menjalankan pod Kubernetes dalam pod yang ditentukan
, yang dapat berupa klaster terpisah yang tidak terkait dengan
lingkungan fleksibel App Engine. Anda juga dapat membuat dan
menghapus cluster menggunakan
Operator Google Kubernetes Engine.
KubernetesPodOperator
adalah opsi yang bagus jika Anda memerlukan:
- Dependensi Python kustom yang tidak tersedia melalui PyPI publik repositori resource.
- Dependensi biner yang tidak tersedia Image pekerja Cloud Composer.
Halaman ini memandu Anda melalui contoh DAG Airflow yang menyertakan hal berikut
Konfigurasi KubernetesPodOperator
:
- Konfigurasi minimum: Hanya menetapkan parameter yang diperlukan.
- Konfigurasi template: Menggunakan parameter yang dapat Anda template dengan Jinja.
Konfigurasi variabel secret: Meneruskan objek Secret Kubernetes ke pod.
Di Cloud Composer 3, konfigurasi afinitas Pod tidak tersedia. Sebagai gantinya, menggunakan operator GKE untuk meluncurkan pod di berbagai .
Konfigurasi lengkap: Mencakup semua konfigurasi.
Sebelum memulai
Di Cloud Composer 3, cluster lingkungan Anda melakukan penskalaan secara otomatis. Workload tambahan yang Anda jalankan menggunakan skala
KubernetesPodOperator
secara terpisah dari lingkungan Anda. Lingkungan Anda tidak terpengaruh oleh peningkatan permintaan sumber daya, tetapi cluster lingkungan Anda dapat menaikkan dan menurunkan skala bergantung pada resource permintaan tinggi. Harga untuk beban kerja tambahan yang Anda jalankan di mengikuti cluster Model penetapan harga Cloud Composer 3 dan penggunaan SKU Cloud Composer 3.Di Cloud Composer 3, cluster lingkungan Anda berada dalam project tenant. Namun, KubernetesPodOperator berfungsi dengan cara yang sama, tanpa perlu mengubah kode dibandingkan dengan Cloud Composer 2. Pod dijalankan di cluster lingkungan, dalam namespace terisolasi, tetapi dengan akses ke jaringan VPC Anda (jika diaktifkan).
Cloud Composer 3 menggunakan cluster GKE dengan Workload Identity Federation untuk GKE. Secara default, Pod yang berjalan di namespace yang baru dibuat atau
composer-user-workloads
tidak dapat mengakses resource Google Cloud. Saat menggunakan Workload Identity Federation for GKE, akun layanan Kubernetes yang terkait dengan namespace harus dipetakan ke akun layanan Google Cloud, untuk mengaktifkan otorisasi identitas layanan untuk permintaan ke Google API dan layanan IT perusahaan mereka.Oleh karena itu, jika Anda menjalankan Pod di namespace
composer-user-workloads
atau namespace yang baru dibuat di cluster lingkungan Anda, maka Binding IAM antara Kubernetes dan Google Cloud akun layanan tidak dibuat, dan Pod tersebut tidak dapat mengakses resource dari project Google Cloud Anda.Jika ingin Pod Anda memiliki akses ke resource Google Cloud, lalu gunakan namespace
composer-user-workloads
atau buat sendiri seperti yang dijelaskan lebih lanjut.Untuk memberikan akses ke resource project, ikuti panduan di Workload Identity Federation for GKE dan menyiapkan binding:
- Buat namespace terpisah di cluster lingkungan Anda.
- Buat binding antara
composer-user-workloads/<namespace_name>
Akun Layanan Kubernetes dan akun layanan lingkungan Anda. - Menambahkan anotasi akun layanan lingkungan Anda ke Kubernetes akun layanan Anda.
- Saat menggunakan
KubernetesPodOperator
, tentukan namespace dan Akun layanan Kubernetes dinamespace
dan Parameterservice_account_name
.
Cloud Composer 3 menggunakan cluster GKE dengan Workload Identitas. Server metadata GKE memerlukan waktu beberapa detik untuk mulai menerima permintaan pada Pod yang baru dibuat. Oleh karena itu, upaya untuk mengautentikasi menggunakan Workload Identity dalam beberapa detik pertama Masa pakai pod mungkin akan gagal. Untuk informasi selengkapnya tentang batasan ini, lihat Batasan Workload Identity.
Cloud Composer 3 menggunakan cluster Autopilot yang memperkenalkan konsep class komputasi:
Secara default, jika tidak ada class yang dipilih, class
general-purpose
akan diasumsikan saat Anda membuat Pod menggunakanKubernetesPodOperator
.Setiap class dikaitkan dengan properti dan batas resource tertentu, Anda dapat membacanya di Dokumentasi Autopilot. Misalnya, Pod yang berjalan dalam class
general-purpose
dapat menggunakan memori hingga 110 GiB.
Konfigurasi KubernetesPodOperator
Untuk mengikuti contoh ini, tempatkan seluruh kubernetes_pod_operator.py
dalam folder dags/
lingkungan Anda atau
tambahkan kode KubernetesPodOperator
yang relevan ke DAG.
Bagian berikut menjelaskan setiap konfigurasi KubernetesPodOperator
dalam contoh. Untuk informasi tentang
setiap variabel konfigurasi,
lihat referensi Airflow.
Konfigurasi minimal
Untuk membuat KubernetesPodOperator
, hanya name
Pod, namespace
tempat untuk
menjalankan pod, image
untuk digunakan, dan task_id
diperlukan.
Saat Anda menempatkan cuplikan kode berikut di DAG, konfigurasinya akan menggunakan
default di /home/airflow/composer_kube_config
. Anda tidak perlu memodifikasi
kode agar tugas pod-ex-minimum
berhasil.
Konfigurasi template
Airflow mendukung penggunaan
Template Jinja.
Anda harus mendeklarasikan variabel yang diperlukan (task_id
, name
, namespace
,
dan image
) dengan operator. Seperti yang ditunjukkan dalam contoh berikut, Anda dapat
membuat template semua parameter lainnya dengan Jinja, termasuk cmds
, arguments
,
env_vars
, dan config_file
.
Tanpa mengubah DAG atau lingkungan Anda, tugas ex-kube-templates
gagal karena dua error. Log menunjukkan bahwa tugas ini gagal karena
variabel yang sesuai tidak ada (my_value
). Kesalahan kedua, yang Anda
bisa didapatkan setelah memperbaiki {i>error<i} pertama, menunjukkan bahwa tugas gagal karena
core/kube_config
tidak ditemukan di config
.
Untuk memperbaiki kedua kesalahan tersebut, ikuti langkah-langkah yang dijelaskan lebih lanjut.
Untuk menetapkan my_value
dengan gcloud
atau UI Airflow:
UI Airflow
Di UI Airflow 2:
Buka UI Airflow.
Di toolbar, pilih Admin > Variabel.
Di halaman Daftar Variabel, klik Tambahkan data baru.
Di halaman Add Variable, masukkan informasi berikut:
- Kunci:
my_value
- Nilai:
example_value
- Kunci:
Klik Simpan.
gcloud
Untuk Airflow 2, masukkan perintah berikut:
gcloud composer environments run ENVIRONMENT \
--location LOCATION \
variables set -- \
my_value example_value
Ganti:
ENVIRONMENT
dengan nama lingkungan.LOCATION
dengan region tempat lingkungan berada.
Untuk merujuk ke config_file
kustom (file konfigurasi Kubernetes),
ganti opsi konfigurasi Airflow kube_config
ke
konfigurasi Kubernetes yang valid:
Bagian | Kunci | Nilai |
---|---|---|
core |
kube_config |
/home/airflow/composer_kube_config |
Tunggu beberapa menit sampai lingkungan Anda diperbarui. Selanjutnya
jalankan tugas ex-kube-templates
lagi dan verifikasi bahwa
Tugas ex-kube-templates
berhasil.
Konfigurasi penuh
Contoh ini menunjukkan semua variabel yang dapat Anda konfigurasi dalam
KubernetesPodOperator
. Anda tidak perlu memodifikasi kode untuk
agar tugas ex-all-configs
berhasil.
Untuk mengetahui detail tentang setiap variabel, lihat metode
Referensi KubernetesPodOperator
Airflow.
Informasi tentang Penyedia Kubernetes CNCF
GKEStartPodOperator dan KubernetesPodOperator diimplementasikan dalam
Penyedia apache-airflow-providers-cncf-kubernetes
.
Untuk catatan rilis defailed untuk penyedia Kubernetes CNCF, lihat situs Penyedia Kubernetes CNCF.
Versi 6.0.0
Dalam versi 6.0.0 paket Penyedia Kubernetes CNCF,
koneksi kubernetes_default
digunakan secara default di
KubernetesPodOperator
.
Jika Anda menentukan koneksi kustom di versi 5.0.0, koneksi kustom ini
masih digunakan oleh operator. Untuk beralih kembali menggunakan kubernetes_default
jarak jauh, Anda mungkin perlu
menyesuaikan DAG dengan tepat.
Versi 5.0.0
Versi ini memperkenalkan beberapa perubahan yang tidak kompatibel dengan versi sebelumnya
dibandingkan dengan versi 4.4.0. Yang paling penting
terkait dengan
koneksi kubernetes_default
yang tidak digunakan dalam versi 5.0.0.
- Koneksi
kubernetes_default
perlu diubah. Jalur konfigurasi Kube harus disetel ke/home/airflow/composer_kube_config
(seperti yang ditunjukkan pada Gambar 1) Sebagai alternatif,config_file
harus ditambahkan ke konfigurasiKubernetesPodOperator
(seperti yang ditunjukkan dalam kode berikut contoh).
- Ubah kode tugas menggunakan KubernetesPodOperator dengan cara berikut:
KubernetesPodOperator(
# config_file parameter - can be skipped if connection contains this setting
config_file="/home/airflow/composer_kube_config",
# definition of connection to be used by the operator
kubernetes_conn_id='kubernetes_default',
...
)
Untuk mengetahui informasi selengkapnya tentang Versi 5.0.0, baca Catatan Rilis Penyedia Kubernetes CNCF
Pemecahan masalah
Tips untuk memecahkan masalah kegagalan Pod
Selain memeriksa log tugas di UI Airflow, periksa juga log berikut:
Output scheduler dan pekerja Airflow:
Di Konsol Google Cloud, buka halaman Environments.
Ikuti link DAGs untuk lingkungan Anda.
Naik satu level ke bucket di lingkungan Anda.
Tinjau log di
logs/<DAG_NAME>/<TASK_ID>/<EXECUTION_DATE>
folder tersebut.
Log pod mendetail di konsol Google Cloud di bagian workload GKE. Log ini mencakup pod file YAML definisi, peristiwa pod, dan detail pod.
Kode yang ditampilkan bukan nol saat juga menggunakan GKEStartPodOperator
Saat menggunakan KubernetesPodOperator
dan GKEStartPodOperator
,
kode pengembalian titik masuk container menentukan apakah tugas
dianggap berhasil atau tidak. Kode hasil yang bukan nol menunjukkan kegagalan.
Pola yang umum saat menggunakan KubernetesPodOperator
dan
GKEStartPodOperator
akan menjalankan skrip shell sebagai container
titik entri untuk mengelompokkan beberapa operasi dalam kontainer.
Jika Anda menulis naskah seperti itu, sebaiknya sertakan
perintah set -e
di bagian atas skrip
sehingga perintah yang gagal dalam skrip akan menghentikan skrip dan
menyebarkan kegagalan ke instance tugas Airflow.
Waktu tunggu pod
Waktu tunggu default untuk KubernetesPodOperator
adalah 120 detik, yang
dapat mengakibatkan waktu tunggu habis sebelum download gambar yang lebih besar. Anda dapat
meningkatkan waktu tunggu dengan mengubah startup_timeout_seconds
saat Anda membuat KubernetesPodOperator
.
Saat waktu tunggu pod habis, log spesifik per tugas tersedia di UI Airflow. Contoh:
Executing <Task(KubernetesPodOperator): ex-all-configs> on 2018-07-23 19:06:58.133811
Running: ['bash', '-c', u'airflow run kubernetes-pod-example ex-all-configs 2018-07-23T19:06:58.133811 --job_id 726 --raw -sd DAGS_FOLDER/kubernetes_pod_operator_sample.py']
Event: pod-name-9a8e9d06 had an event of type Pending
...
...
Event: pod-name-9a8e9d06 had an event of type Pending
Traceback (most recent call last):
File "/usr/local/bin/airflow", line 27, in <module>
args.func(args)
File "/usr/local/lib/python2.7/site-packages/airflow/bin/cli.py", line 392, in run
pool=args.pool,
File "/usr/local/lib/python2.7/site-packages/airflow/utils/db.py", line 50, in wrapper
result = func(*args, **kwargs)
File "/usr/local/lib/python2.7/site-packages/airflow/models.py", line 1492, in _run_raw_task
result = task_copy.execute(context=context)
File "/usr/local/lib/python2.7/site-packages/airflow/contrib/operators/kubernetes_pod_operator.py", line 123, in execute
raise AirflowException('Pod Launching failed: {error}'.format(error=ex))
airflow.exceptions.AirflowException: Pod Launching failed: Pod took too long to start
Waktu Tunggu Pod juga dapat terjadi saat Akun Layanan Cloud Composer tidak memiliki izin IAM yang diperlukan untuk menjalankan tugas di tangan. Untuk memverifikasinya, lihat error level pod menggunakan Dasbor GKE untuk melihat log Anda Workload tertentu, atau menggunakan Cloud Logging.
Gagal membuat koneksi baru
Upgrade otomatis diaktifkan secara default di cluster GKE. Jika kumpulan node berada dalam cluster yang sedang diupgrade, Anda mungkin melihat hal berikut {i>error<i}:
<Task(KubernetesPodOperator): gke-upgrade> Failed to establish a new
connection: [Errno 111] Connection refused
Untuk memeriksa apakah cluster Anda diupgrade, di Konsol Google Cloud, buka Halaman Cluster Kubernetes dan cari ikon pemuatan di sebelah Anda nama cluster lingkungan.