ID localization: replaced {{< codenew ... >}} with {{% codenew ... %}…

…} in all files

content/id/docs/concepts/cluster-administration/logging.md

@@ -21,7 +21,7 @@ Arsitektur _logging_ pada level klaster yang akan dijelaskan berikut mengasumsik
 
 Pada bagian ini, kamu dapat melihat contoh tentang dasar _logging_ pada Kubernetes yang mengeluarkan data pada _standard output_. Demonstrasi berikut ini menggunakan sebuah [spesifikasi pod](/examples/debug/counter-pod.yaml) dengan kontainer yang akan menuliskan beberapa teks ke _standard output_ tiap detik.
 
-{{< codenew file="debug/counter-pod.yaml" >}}
+{{% codenew file="debug/counter-pod.yaml" %}}
 
 Untuk menjalankan pod ini, gunakan perintah berikut:
 
@@ -126,13 +126,13 @@ Dengan menggunakan cara ini kamu dapat memisahkan aliran log dari bagian-bagian
 
 Sebagai contoh, sebuah pod berjalan pada satu kontainer tunggal, dan kontainer menuliskan ke dua berkas log yang berbeda, dengan dua format yang berbeda pula. Berikut ini _file_ konfigurasi untuk Pod:
 
-{{< codenew file="admin/logging/two-files-counter-pod.yaml" >}}
+{{% codenew file="admin/logging/two-files-counter-pod.yaml" %}}
 
 Hal ini akan menyulitkan untuk mengeluarkan log dalam format yang berbeda pada aliran log yang sama, meskipun kamu dapat me-_redirect_ keduanya ke `stdout` dari kontainer.  Sebagai gantinya, kamu dapat menggunakan dua buah kontainer _sidecar_. Tiap kontainer _sidecar_ dapat membaca suatu berkas log tertentu dari _shared volume_ kemudian mengarahkan log ke `stdout`-nya sendiri.
 
 Berikut _file_ konfigurasi untuk pod yang memiliki dua buah kontainer _sidecard_:
 
-{{< codenew file="admin/logging/two-files-counter-pod-streaming-sidecar.yaml" >}}
+{{% codenew file="admin/logging/two-files-counter-pod-streaming-sidecar.yaml" %}}
 
 Saat kamu menjalankan pod ini, kamu dapat mengakses tiap aliran log secara terpisah dengan menjalankan perintah berikut:
 
@@ -175,15 +175,15 @@ Menggunakan agen _logging_ di dalam kontainer _sidecar_ dapat berakibat pengguna
 Sebagai contoh, kamu dapat menggunakan [Stackdriver](/docs/tasks/debug-application-cluster/logging-stackdriver/),
 yang menggunakan fluentd sebagai agen _logging_. Berikut ini dua _file_ konfigurasi yang dapat kamu pakai untuk mengimplementasikan cara ini. _File_ yang pertama berisi sebuah [ConfigMap](/id/docs/tasks/configure-pod-container/configure-pod-configmap/) untuk mengonfigurasi fluentd.
 
-{{< codenew file="admin/logging/fluentd-sidecar-config.yaml" >}}
+{{% codenew file="admin/logging/fluentd-sidecar-config.yaml" %}}
 
 {{< note >}}
 Konfigurasi fluentd berada diluar cakupan artikel ini. Untuk informasi lebih lanjut tentang cara mengonfigurasi fluentd, silakan lihat [dokumentasi resmi fluentd ](http://docs.fluentd.org/).
 {{< /note >}}
 
 _File_ yang kedua mendeskripsikan sebuah pod yang memiliki kontainer _sidecar_ yang menjalankan fluentd. Pod ini melakukan _mount_ sebuah volume yang akan digunakan fluentd untuk mengambil data konfigurasinya.
 
-{{< codenew file="admin/logging/two-files-counter-pod-agent-sidecar.yaml" >}}
+{{% codenew file="admin/logging/two-files-counter-pod-agent-sidecar.yaml" %}}
 
 Setelah beberapa saat, kamu akan mendapati pesan log pada _interface_ Stackdriver.
 

content/id/docs/concepts/cluster-administration/manage-deployment.md

@@ -17,7 +17,7 @@ Kamu telah melakukan _deploy_ pada aplikasimu dan mengeksposnya melalui sebuah _
 
 Banyak aplikasi memerlukan beberapa _resource_, seperti Deployment dan Service. Pengelolaan beberapa _resource_ dapat disederhanakan dengan mengelompokkannya dalam berkas yang sama (dengan pemisah `---` pada YAML). Contohnya:
 
-{{< codenew file="application/nginx-app.yaml" >}}
+{{% codenew file="application/nginx-app.yaml" %}}
 
 Beberapa _resource_ dapat dibuat seolah-olah satu _resource_:
 

content/id/docs/concepts/overview/working-with-objects/kubernetes-objects.md

@@ -64,7 +64,7 @@ akan mengubah informasi yang kamu berikan ke dalam format JSON ketika melakukan
 
 Berikut merupakan contoh _file_ `.yaml` yang menunjukkan _field_ dan _spec_ objek untuk _Deployment_:
 
-{{< codenew file="application/deployment.yaml" >}}
+{{% codenew file="application/deployment.yaml" %}}
 
 Salah satu cara untuk membuat _Deployment_ menggunakan _file_ `.yaml`
 seperti yang dijabarkan di atas adalah dengan menggunakan perintah

content/id/docs/concepts/policy/pod-security-policy.md

@@ -146,7 +146,7 @@ alias kubectl-user='kubectl --as=system:serviceaccount:psp-example:fake-user -n
 
 Beri definisi objek contoh PodSecurityPolicy dalam sebuah berkas. Ini adalah kebijakan yang mencegah pembuatan Pod-Pod yang _privileged_.
 
-{{< codenew file="policy/example-psp.yaml" >}}
+{{% codenew file="policy/example-psp.yaml" %}}
 
 Dan buatlah PodSecurityPolicy tersebut dengan `kubectl`:
 
@@ -297,11 +297,11 @@ podsecuritypolicy "example" deleted
 
 Berikut adalah kebijakan dengan batasan paling sedikit yang dapat kamu buat, ekuivalen dengan tidak menggunakan _admission controller_ Pod Security Policy:
 
-{{< codenew file="policy/privileged-psp.yaml" >}}
+{{% codenew file="policy/privileged-psp.yaml" %}}
 
 Berikut adalah sebuah contoh kebijakan yang restriktif yang mengharuskan pengguna-pengguna untuk berjalan sebagai pengguna yang _unprivileged_, memblokir kemungkinan eskalasi menjadi _root_, dan mengharuskan penggunaan beberapa mekanisme keamanan.
 
-{{< codenew file="policy/restricted-psp.yaml" >}}
+{{% codenew file="policy/restricted-psp.yaml" %}}
 
 ## Referensi Kebijakan
 

content/id/docs/concepts/scheduling-eviction/assign-pod-node.md

@@ -52,7 +52,7 @@ spec:
 
 Kemudian tambahkan sebuah `nodeSelector` seperti berikut:
 
-{{< codenew file="pods/pod-nginx.yaml" >}}
+{{% codenew file="pods/pod-nginx.yaml" %}}
 
 Ketika kamu menjalankan perintah `kubectl apply -f https://k8s.io/examples/pods/pod-nginx.yaml`, pod tersebut akan dijadwalkan pada node yang memiliki label yang dirinci. Kamu dapat memastikan penambahan nodeSelector berhasil dengan menjalankan `kubectl get pods -o wide` dan melihat "NODE" tempat Pod ditugaskan.
 
@@ -110,7 +110,7 @@ Afinitas node dinyatakan sebagai _field_ `nodeAffinity` dari _field_ `affinity`
 
 Berikut ini contoh dari pod yang menggunakan afinitas node:
 
-{{< codenew file="pods/pod-with-node-affinity.yaml" >}}
+{{% codenew file="pods/pod-with-node-affinity.yaml" %}}
 
 Aturan afinitas node tersebut menyatakan pod hanya bisa ditugaskan pada node dengan label yang memiliki kunci `kubernetes.io/e2e-az-name` dan bernilai `e2e-az1` atau `e2e-az2`. Selain itu, dari semua node yang memenuhi kriteria tersebut, mode dengan label dengan kunci `another-node-label-key` and bernilai `another-node-label-value` harus lebih diutamakan.
 
@@ -151,7 +151,7 @@ Afinitas antar pod dinyatakan sebagai _field_ `podAffinity` dari _field_ `affini
 
 #### Contoh pod yang menggunakan pod affinity:
 
-{{< codenew file="pods/pod-with-pod-affinity.yaml" >}}
+{{% codenew file="pods/pod-with-pod-affinity.yaml" %}}
 
 Afinitas pada pod tersebut menetapkan sebuah aturan afinitas pod dan aturan anti-afinitas pod. Pada contoh ini, `podAffinity` adalah `requiredDuringSchedulingIgnoredDuringExecution`
 sementara `podAntiAffinity` adalah `preferredDuringSchedulingIgnoredDuringExecution`. Aturan afinitas pod menyatakan bahwa pod dapat dijadwalkan pada node hanya jika node tersebut berada pada zona yang sama dengan minimal satu pod yang sudah berjalan yang memiliki label dengan kunci "security" dan bernilai "S1". (Lebih detail, pod dapat berjalan pada node N jika node N memiliki label dengan kunci `failure-domain.beta.kubernetes.io/zone`dan nilai V sehingga ada minimal satu node dalam klaster dengan kunci `failure-domain.beta.kubernetes.io/zone` dan bernilai V yang menjalankan pod yang memiliki label dengan kunci "security" dan bernilai "S1".) Aturan anti-afinitas pod menyatakan bahwa pod memilih untuk tidak dijadwalkan pada sebuah node jika node tersebut sudah menjalankan pod yang memiliki label dengan kunci "security" dan bernilai "S2". (Jika `topologyKey` adalah `failure-domain.beta.kubernetes.io/zone` maka dapat diartikan bahwa pod tidak dapat dijadwalkan pada node jika node berada pada zona yang sama dengan pod yang memiliki label dengan kunci "security" dan bernilai "S2".) Lihat [design doc](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md) untuk lebih banyak contoh afinitas dan anti-afinitas pod, baik `requiredDuringSchedulingIgnoredDuringExecution`

content/id/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md

@@ -68,7 +68,7 @@ Selain _boilerplate default_, kita dapat menambahkan entri pada berkas
 `bar.remote` pada `10.1.2.3`, kita dapat melakukannya dengan cara menambahkan
 HostAliases pada Pod di bawah _field_ `.spec.hostAliases`:
 
-{{< codenew file="service/networking/hostaliases-pod.yaml" >}}
+{{% codenew file="service/networking/hostaliases-pod.yaml" %}}
 
 Pod ini kemudian dapat dihidupkan dengan perintah berikut:
 

content/id/docs/concepts/services-networking/connect-applications-service.md

@@ -25,7 +25,7 @@ Panduan ini menggunakan server *nginx* sederhana untuk mendemonstrasikan konsepn
 
 Kita melakukan ini di beberapa contoh sebelumnya, tetapi mari kita lakukan sekali lagi dan berfokus pada prespektif jaringannya. Buat sebuah *nginx Pod*, dan perhatikan bahwa templat tersebut mempunyai spesifikasi *port* kontainer:
 
-{{< codenew file="service/networking/run-my-nginx.yaml" >}}
+{{% codenew file="service/networking/run-my-nginx.yaml" %}}
 
 Ini membuat aplikasi tersebut dapat diakses dari *node* manapun di dalam klaster kamu. Cek lokasi *node* dimana *Pod* tersebut berjalan:
 ```shell
@@ -66,7 +66,7 @@ service/my-nginx exposed
 
 Perintah di atas sama dengan `kubectl apply -f` dengan *yaml* sebagai berikut:
 
-{{< codenew file="service/networking/nginx-svc.yaml" >}}
+{{% codenew file="service/networking/nginx-svc.yaml" %}}
 
 Spesifikasi ini akan membuat *Service* yang membuka *TCP port 80* di setiap *Pod* dengan label `run: my-nginx` dan mengeksposnya ke dalam *port Service* (`targetPort`: adalah port kontainer yang menerima trafik, `port` adalah *service port* yang dapat berupa *port* apapun yang digunakan *Pod* lain untuk mengakses *Service*).
 
@@ -253,7 +253,7 @@ nginxsecret           Opaque                                2         1m
 
 Sekarang modifikasi replika *nginx* untuk menjalankan server *https* menggunakan *certificate* di dalam *secret* dan *Service* untuk mengekspos semua *port* (80 dan 443):
 
-{{< codenew file="service/networking/nginx-secure-app.yaml" >}}
+{{% codenew file="service/networking/nginx-secure-app.yaml" %}}
 
 Berikut catatan penting tentang manifes *nginx-secure-app*:
 
@@ -281,7 +281,7 @@ node $ curl -k https://10.244.3.5
 
 Perlu dicatat bahwa kita menggunakan parameter `-k` saat menggunakan *curl*, ini karena kita tidak tau apapun tentang *Pod* yang menjalankan *nginx* saat pembuatan seritifikat, jadi kita harus memberitahu *curl* untuk mengabaikan ketidakcocokan *CName*. Dengan membuat *Service*, kita menghubungkan *CName* yang digunakan pada *certificate* dengan nama pada *DNS* yang digunakan *Pod*. Lakukan pengujian dari sebuah *Pod* (*secret* yang sama digunakan untuk agar mudah, *Pod* tersebut hanya membutuhkan *nginx.crt* untuk mengakses *Service*)
 
-{{< codenew file="service/networking/curlpod.yaml" >}}
+{{% codenew file="service/networking/curlpod.yaml" %}}
 
 ```shell
 kubectl apply -f ./curlpod.yaml

content/id/docs/concepts/services-networking/dns-pod-service.md

@@ -225,7 +225,7 @@ pada _field_ `dnsConfig`:
 
 Di bawah ini merupakan contoh sebuah Pod dengan pengaturan DNS kustom:
 
-{{< codenew file="service/networking/custom-dns.yaml" >}}
+{{% codenew file="service/networking/custom-dns.yaml" %}}
 
 Ketika Pod diatas dibuat, maka Container `test`
 memiliki isi berkas `/etc/resolv.conf` sebagai berikut:

content/id/docs/concepts/services-networking/dual-stack.md

@@ -96,19 +96,19 @@ Kubernetes akan mengalokasikan alamat IP (atau yang dikenal juga sebagai
 "_cluster IP_") dari `service-cluster-ip-range` yang dikonfigurasi pertama kali
 untuk Service ini.
 
-{{< codenew file="service/networking/dual-stack-default-svc.yaml" >}}
+{{% codenew file="service/networking/dual-stack-default-svc.yaml" %}}
 
 Spesifikasi Service berikut memasukkan bagian `ipFamily`. Sehingga Kubernetes
 akan mengalokasikan alamat IPv6 (atau yang dikenal juga sebagai "_cluster IP_") 
 dari `service-cluster-ip-range` yang dikonfigurasi untuk Service ini.
 
-{{< codenew file="service/networking/dual-stack-ipv6-svc.yaml" >}}
+{{% codenew file="service/networking/dual-stack-ipv6-svc.yaml" %}}
 
 Sebagai perbandingan, spesifikasi Service berikut ini akan dialokasikan sebuah alamat
 IPv4 (atau yang dikenal juga sebagai "_cluster IP_") dari `service-cluster-ip-range` 
 yang dikonfigurasi untuk Service ini.
 
-{{< codenew file="service/networking/dual-stack-ipv4-svc.yaml" >}}
+{{% codenew file="service/networking/dual-stack-ipv4-svc.yaml" %}}
 
 ### Tipe _LoadBalancer_
 

content/id/docs/concepts/services-networking/ingress.md

@@ -132,7 +132,7 @@ akan diarahkan pada *backend default*.
 Terdapat konsep Kubernetes yang memungkinkan kamu untuk mengekspos sebuah Service, lihat [alternatif lain](#alternatif-lain).
 Kamu juga bisa membuat spesifikasi Ingress dengan  *backend default* yang tidak memiliki *rules*.
 
-{{< codenew file="service/networking/ingress.yaml" >}}
+{{% codenew file="service/networking/ingress.yaml" %}}
 
 Jika kamu menggunakan `kubectl apply -f` kamu dapat melihat:
 

content/id/docs/concepts/workloads/controllers/daemonset.md

@@ -37,7 +37,7 @@ Kamu bisa definisikan DaemonSet dalam berkas YAML. Contohnya, berkas
 `daemonset.yaml` di bawah mendefinisikan DaemonSet yang menjalankan _image_ Docker
 fluentd-elasticsearch:
 
-{{< codenew file="controllers/daemonset.yaml" >}}
+{{% codenew file="controllers/daemonset.yaml" %}}
 
 * Buat DaemonSet berdasarkan berkas YAML:
 ```

content/id/docs/concepts/workloads/controllers/deployment.md

@@ -41,7 +41,7 @@ Berikut adalah penggunaan yang umum pada Deployment:
 
 Berikut adalah contoh Deployment. Dia membuat ReplicaSet untuk membangkitkan tiga Pod `nginx`:
 
-{{< codenew file="controllers/nginx-deployment.yaml" >}}
+{{% codenew file="controllers/nginx-deployment.yaml" %}}
 
 Dalam contoh ini:
 

content/id/docs/concepts/workloads/controllers/garbage-collection.md

@@ -22,7 +22,7 @@ Kamu juga bisa menspesifikasikan hubungan antara pemilik dan dependen dengan car
 
 Berikut adalah berkas untuk sebuah ReplicaSet yang memiliki tiga Pod:
 
-{{< codenew file="controllers/replicaset.yaml" >}}
+{{% codenew file="controllers/replicaset.yaml" %}}
 
 
 Jika kamu membuat ReplicaSet tersebut dan kemudian melihat metadata Pod, kamu akan melihat kolom OwnerReferences:

content/id/docs/concepts/workloads/controllers/job.md

@@ -33,7 +33,7 @@ Berikut merupakan contoh konfigurasi Job. Job ini melakukan komputasi π hingga
 digit ke 2000 kemudian memberikan hasilnya sebagai keluaran. Job tersebut memerlukan 
 waktu 10 detik untuk dapat diselesaikan.
 
-{{< codenew file="controllers/job.yaml" >}}
+{{% codenew file="controllers/job.yaml" %}}
 
 Kamu dapat menjalankan contoh tersebut dengan menjalankan perintah berikut:
 

content/id/docs/concepts/workloads/controllers/replicaset.md

@@ -29,7 +29,7 @@ Hal ini berarti kamu boleh jadi tidak akan membutuhkan manipulasi objek ReplicaS
 
 ## Contoh
 
-{{< codenew file="controllers/frontend.yaml" >}}
+{{% codenew file="controllers/frontend.yaml" %}}
 
 Menyimpan _manifest_ ini dalam `frontend.yaml` dan mengirimkannya ke klaster Kubernetes akan membuat ReplicaSet yang telah didefinisikan beserta dengan Pod yang dikelola.
 
@@ -131,7 +131,7 @@ Walaupun kamu bisa membuat Pod biasa tanpa masalah, sangat direkomendasikan untu
 
 Mengambil contoh ReplicaSet _frontend_ sebelumnya, dan Pod yang ditentukan pada _manifest_ berikut: 
 
-{{< codenew file="pods/pod-rs.yaml" >}}
+{{% codenew file="pods/pod-rs.yaml" %}}
 
 Karena Pod tersebut tidak memiliki Controller (atau objek lain) sebagai referensi pemilik yang sesuai dengan selektor dari ReplicaSet _frontend_, Pod tersebut akan langsung diakuisisi oleh ReplicaSet.
 
@@ -257,7 +257,7 @@ Jumlah Pod pada ReplicaSet dapat diatur dengan mengubah nilai dari _field_ `.spe
 
 Pengaturan jumlah Pod pada ReplicaSet juga dapat dilakukan mengunakan [Horizontal Pod Autoscalers (HPA)](/docs/tasks/run-application/horizontal-pod-autoscale/). Berikut adalah contoh HPA terhadap ReplicaSet yang telah dibuat pada contoh sebelumnya.
 
-{{< codenew file="controllers/hpa-rs.yaml" >}}
+{{% codenew file="controllers/hpa-rs.yaml" %}}
 
 Menyimpan _manifest_ ini dalam `hpa-rs.yaml` dan mengirimkannya ke klaster Kubernetes akan membuat HPA tersebut yang akan mengatur jumlah Pod pada ReplicaSet yang telah didefinisikan bergantung terhadap penggunaan CPU dari Pod yang direplikasi.
 

content/id/docs/concepts/workloads/controllers/replicationcontroller.md

@@ -36,7 +36,7 @@ Sebuah contoh sederhana adalah membuat sebuah objek ReplicationController untuk
 
 Contoh ReplicationController ini mengonfigurasi tiga salinan dari peladen web nginx.
 
-{{< codenew file="controllers/replication.yaml" >}}
+{{% codenew file="controllers/replication.yaml" %}}
 
 Jalankan contoh di atas dengan mengunduh berkas contoh dan menjalankan perintah ini:
 

content/id/docs/concepts/workloads/pods/pod-topology-spread-constraints.md

@@ -114,7 +114,7 @@ node2 dan node3 (`P` merepresentasikan Pod):
 Jika kita ingin Pod baru akan disebar secara merata berdasarkan Pod yang telah ada pada semua zona,
 maka _spec_ bernilai sebagai berikut:
 
-{{< codenew file="pods/topology-spread-constraints/one-constraint.yaml" >}}
+{{% codenew file="pods/topology-spread-constraints/one-constraint.yaml" %}}
 
 `topologyKey: zone` berarti persebaran merata hanya akan digunakan pada Node dengan pasangan label 
 "zone: <nilai apapun>". `whenUnsatisfiable: DoNotSchedule` memberitahukan penjadwal untuk membiarkan
@@ -161,7 +161,7 @@ Ini dibuat berdasarkan contoh sebelumnya. Misalkan kamu memiliki klaster dengan
 
 Kamu dapat menggunakan 2 TopologySpreadConstraint untuk mengatur persebaran Pod pada zona dan Node:
 
-{{< codenew file="pods/topology-spread-constraints/two-constraints.yaml" >}}
+{{% codenew file="pods/topology-spread-constraints/two-constraints.yaml" %}}
 
 Dalam contoh ini, untuk memenuhi batasan pertama, Pod yang baru hanya akan ditempatkan pada "zoneB",
 sedangkan untuk batasan kedua, Pod yang baru hanya akan ditempatkan pada "node4". Maka hasil dari 
@@ -224,7 +224,7 @@ sesuai dengan nilai tersebut akan dilewatkan.
     berkas yaml seperti di bawah, jadi "mypod" akan ditempatkan pada "zoneB", bukan "zoneC".
     Demikian juga `spec.nodeSelector` akan digunakan.
 
-    {{< codenew file="pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml" >}}
+    {{% codenew file="pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml" %}}
 
 ### Batasan _default_ pada tingkat klaster
 

content/id/docs/tasks/administer-cluster/dns-debugging-resolution.md

@@ -21,7 +21,7 @@ kube-dns.
 
 ### Membuat Pod sederhana yang digunakan sebagai lingkungan pengujian
 
-{{< codenew file="admin/dns/dnsutils.yaml" >}}
+{{% codenew file="admin/dns/dnsutils.yaml" %}}
 
 Gunakan manifes berikut untuk membuat sebuah Pod:
 

content/id/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md

@@ -40,7 +40,7 @@ kubectl create namespace constraints-mem-example
 
 Berikut berkas konfigurasi untuk sebuah LimitRange:
 
-{{< codenew file="admin/resource/memory-constraints.yaml" >}}
+{{% codenew file="admin/resource/memory-constraints.yaml" %}}
 
 Membuat LimitRange:
 
@@ -85,7 +85,7 @@ Berikut berkas konfigurasi Pod yang memiliki satu Container. Manifes Container
 menentukan permintaan memori 600 MiB dan limit memori 800 MiB. Nilai tersebut memenuhi
 batasan minimum dan maksimum memori yang ditentukan oleh LimitRange.
 
-{{< codenew file="admin/resource/memory-constraints-pod.yaml" >}}
+{{% codenew file="admin/resource/memory-constraints-pod.yaml" %}}
 
 Membuat Pod:
 
@@ -127,7 +127,7 @@ kubectl delete pod constraints-mem-demo --namespace=constraints-mem-example
 Berikut berkas konfigurasi untuk sebuah Pod yang memiliki satu Container. Container tersebut menentukan
 permintaan memori 800 MiB dan batas memori 1.5 GiB.
 
-{{< codenew file="admin/resource/memory-constraints-pod-2.yaml" >}}
+{{% codenew file="admin/resource/memory-constraints-pod-2.yaml" %}}
 
 Mencoba membuat Pod:
 
@@ -148,7 +148,7 @@ pods "constraints-mem-demo-2" is forbidden: maximum memory usage per Container i
 Berikut berkas konfigurasi untuk sebuah Pod yang memiliki satu Container. Container tersebut menentukan
 permintaan memori 100 MiB dan limit memori 800 MiB.
 
-{{< codenew file="admin/resource/memory-constraints-pod-3.yaml" >}}
+{{% codenew file="admin/resource/memory-constraints-pod-3.yaml" %}}
 
 Mencoba membuat Pod:
 
@@ -171,7 +171,7 @@ pods "constraints-mem-demo-3" is forbidden: minimum memory usage per Container i
 Berikut berkas konfigurasi untuk sebuah Pod yang memiliki satu Container. Container tersebut tidak menentukan
 permintaan memori dan juga limit memori.
 
-{{< codenew file="admin/resource/memory-constraints-pod-4.yaml" >}}
+{{% codenew file="admin/resource/memory-constraints-pod-4.yaml" %}}
 
 Mencoba membuat Pod: