Oracle Container Native Platform è una soluzione open source e guidata dalla comunità che include un registro container gestito (Oracle Cloud Infrastructure Registry) e un servizio Kubernetes gestito (Oracle Container Engine). La piattaforma sfrutta Oracle Cloud Infrastructure per performance e disponibilità elevate, sicurezza e affidabilità. Oracle prevede di aggiungere Oracle Container Functions e Oracle Container Microservices alla piattaforma nel prossimo futuro.

Con questa piattaforma, Oracle offre una suite completa e di livello enterprise di servizi cloud per creare, distribuire e gestire microservizi nativi per container e applicazioni serverless. Man mano che gli sviluppatori adottano rapidamente tecnologie native per container per le nuove applicazioni native cloud e per le applicazioni tradizionali migrate, sono sempre più preoccupati di rimanere vincolati ai loro fornitori cloud e ai loro fornitori di piattaforme di sviluppo delle applicazioni. Inoltre, stanno cercando il vero cloud ibrido, utilizzando lo stesso stack in qualsiasi cloud e on-premise. Oracle Container Native Platform evita il crearsi di accordi esclusivi con i fornitori adottando standard open source e supportando lo sviluppo della piattaforma guidato dalla comunità in modo che i suoi componenti possano essere eseguiti in qualsiasi ambiente cloud.

Container Engine per Kubernetes ti consente di creare, gestire e utilizzare rapidamente cluster Kubernetes che sfruttano i servizi di elaborazione, rete e archiviazione sottostanti senza la necessità di installare e mantenere complesse infrastrutture Kubernetes di supporto.

Dovresti usare Container Engine for Kubernetes quando vuoi sfruttare Kubernetes per distribuire e gestire le tue applicazioni container basate su Kubernetes. Ti consente di abbinare l'orchestrazione container di livello produttivo di standard upstream di Kubernetes con il controllo, la sicurezza e le performance altamente prevedibili di Oracle Cloud Infrastructure.

Non è previsto alcun addebito dedicato per Container Engine for Kubernetes. Paghi solo le risorse che usi per il calcolo, l'archiviazione e la rete sottostanti utilizzati dai cluster Kubernetes. Inoltre, ti vengono addebitati solo i nodi "worker" in esecuzione nella tua tenancy, i tuoi nodi principali vengono eseguiti nella tenancy gestita da Oracle per te.

• Phoenix
• Ashburn
• Francoforte
• Londra
• Toronto
• Tokyo
• Seul

No, quando crei un cluster Kubernetes gestito, Oracle crea e gestisce automaticamente un insieme di più nodi master su diversi domini di disponibilità (datacenter logici) nel piano di controllo Oracle per tuo conto (e l'infrastruttura Kubernetes associata come nodi etcd) per assicurarsi di disporre di un piano di controllo Kubernetes gestito ad alta disponibilità. Puoi anche aggiornare senza problemi questi nodi principali a nuove versioni di Kubernetes senza tempi di inattività.

Sì, i cluster Kubernetes sono creati con versioni standard upstream di Kubernetes. Queste versioni sono anche certificate dal programma di conformità della Cloud Native Computing Foundation (CNCF).

Quando crei un cluster Kubernetes gestito, Oracle crea e gestisce automaticamente un insieme di più nodi master su diversi domini di disponibilità (datacenter logici) nel piano di controllo Oracle per tuo conto (e l'infrastruttura Kubernetes associata come nodi etcd) per assicurarsi di disporre di un piano di controllo Kubernetes gestito ad alta disponibilità. Puoi anche aggiornare senza problemi questi nodi principali a nuove versioni di Kubernetes senza tempi di inattività. I nodi di lavoro forniti vengono inoltre etichettati automaticamente con etichette Kubernetes ben note su regione e dominio di disponibilità per consentire ai clienti di sfruttare i meccanismi di pianificazione di Kubernetes per creare e distribuire applicazioni basate su container resilienti.

Sì, i cluster gestiti di Kubernetes sono abilitati con Kubernetes RBAC. i cluster gestiti di Kubernetes sono inoltre integrati con Oracle Identity and Access Management (IAM), offrendo agli utenti potenti controlli per l'accesso ai propri cluster.

Sì, puoi distribuire un cluster Kubernetes gestito in una VCN esistente, per avere un controllo dettagliato sull'uso delle sottoreti e degli elenchi di sicurezza sottostanti.

Sì, hai la possibilità di creare il tuo cluster Kubernetes gestito con nodi di lavoro in sottoreti private. Questi nodi di lavoro hanno solo indirizzi IP privati e richiedono un gateway NAT per le connessioni in uscita ai master del cluster e a Internet.

Sì, è possibile distribuire un cluster Kubernetes gestito su nodi bare metal puri. Puoi anche sfruttare il concetto di "pool di nodi" (un insieme di nodi che condividono un'immagine/dimensione di nodo comune) per creare un cluster di macchine bare metal e virtuali e indirizzare i carichi di lavoro Kubernetes in modo appropriato.

Sì. Container Engine for Kubernetes consente agli utenti di esporre i servizi Kubernetes di tipo "LoadBalancer" e creare bilanciatori di carico Oracle. Gli utenti possono anche creare volumi persistenti e rivendicazioni di volume persistenti di Kubernetes supportati da Oracle Block Volumes.

Sì, quando si crea un cluster, è possibile fornire una coppia di chiavi SSH pubbliche/private al fine di accedere tramite SSH ai nodi di lavoro, se lo si desidera.

Sì, i nodi lavoratore eseguono il runtime Docker standard, in modo che gli utenti possano sfruttare i comandi Docker familiari.

Oracle Cloud Infrastructure Customer Service Broker for Kubernetes (OSB o "Service Broker") è un'implementazione dell'API Open Service Broker che può essere utilizzata per interagire con Oracle Cloud Infrastructure Services. Con Oracle Cloud Infrastructure Service Broker, puoi gestire il ciclo di vita dei servizi Oracle Cloud Infrastructure in modo nativo da Kubernetes tramite le API Kubernetes. Ciò comporta quanto segue:

Non è necessario passare a un sistema separato per fornire servizi dipendenti dall'applicazione durante la distribuzione di un'applicazione in Kubernetes.

Il ciclo di vita dei servizi dipendenti Oracle Cloud Infrastructure può essere collegato alle applicazioni che dipendono da essi.

Le applicazioni diventano più accessibili poiché le dipendenze possono essere facilmente codificate nelle procedure DevOps.

Per usare Oracle Cloud Infrastructure Service Broker, installalo nel tuo cluster Kubernetes insieme a Kubernetes Service Catalog. È quindi possibile utilizzare i comandi kubectl che vengono interpretati nei comandi CLI di Oracle Cloud Infrastructure.

Consulta https://github.com/oracle/oci-service-broker per maggiori informazioni.

Al momento della stesura di questo documento, è possibile utilizzare Oracle Cloud Infrastructure Service Broker per effettuare il provisioning e creare i collegamenti di servizio ai seguenti tipi di servizio Oracle Cloud Infrastructure:

• Database autonomo di elaborazione delle transazioni
• Database autonomo di data warehouse
• Bucket Object Storage Service

Puoi usare Oracle Cloud Infrastructure Service Broker all'interno di un cluster Kubernetes creato su Oracle Linux (usando Oracle Container Services for Kubernetes) in esecuzione in locale per creare istanze di servizi su Oracle Cloud Infrastructure, ma non puoi utilizzare Oracle Cloud Infrastructure Service Broker per eseguire il provisioning di servizi eseguiti in locale.

Oracle Cloud Infrastructure Service Broker viene normalmente distribuito come pod nel cluster Kubernetes. Con ciò, il modo più semplice per risolvere il problema è ottenere i registri dal pod con i seguenti comandi:

• Utilizzare kubectl get pods per ottenere un elenco di pod in esecuzione nel cluster.
• Da quell'elenco, copiare l'ID pod per Oracle Cloud Infrastructure Service Broker.
• Usa i registri di kubectl per ottenere i registri dal pod.

Gli utenti che utilizzano Oracle Cloud Infrastructure Service Broker per creare istanze di servizio Oracle Cloud Infrastructure, come un'istanza del database ATP, devono avere un ruolo che disponga dell'autorizzazione per creare tali servizi. Ad esempio, assicurati di avere una politica nella tua tenancy Oracle Cloud Infrastructure che somigli alla seguente policy:

Consentire al gruppo OCI-Service-Broker-Group di gestire un database autonomo nel compartimento

Vedi https://github.com/oracle/oci-service-broker/tree/master/charts/oci-service-broker/docs/security.md