Oracle Natywna platforma kontenerowa to otwarte i oparte na społeczności rozwiązanie, które obejmuje zarządzany rejestr kontenerów (Oracle Cloud Infrastructure Registry) oraz zarządzaną usługę Kubernetes (Oracle Container Engine). Platforma wykorzystuje Oracle Cloud Infrastructure dla wysokiej wydajności, wysokiej dostępności, bezpieczeństwa i niezawodności. Oracle planuje dodać Oracle funkcje kontenera i Oracle mikrousług kontenerowych w najbliższej przyszłości.

Dzięki tej platformie Oracle zapewnia kompletny pakiet usług w chmurze klasy korporacyjnej do tworzenia, wdrażania i obsługi natywnych kontenerów mikrousług i aplikacji Serverless. Ponieważ programiści szybko wdrażają technologie natywne dla kontenerów w przypadku nowych aplikacji natywnych w chmurze i migrowanych aplikacji tradycyjnych, coraz bardziej obawiają się, że zostaną zablokowani przez swoich dostawców usług w chmurze i platformę tworzenia aplikacji. Co więcej, szukają prawdziwej chmury hybrydowej, używając tego samego stosu w dowolnej chmurze i lokalnie. Oracle Natywna platforma kontenerowa zapobiega blokowaniu się dostawcy, przyjmując standardy open source i wspierając rozwój platformy oparty na społeczności, aby jej komponenty mogły działać w dowolnym środowisku chmurowym.

Container Engine for Kubernetes umożliwia szybkie tworzenie klastrów Kubernetes, zarządzanie nimi i korzystanie z nich, które wykorzystują podstawowe usługi obliczeniowe, sieciowe i magazynowe bez potrzeby instalowania i utrzymywania złożonej obsługi infrastruktury Kubernetes.

Powinieneś użyć silnika kontenera dla Kubernetes, jeśli chcesz wykorzystać Kubernetes do wdrażania i zarządzania aplikacjami kontenerowymi opartymi na Kubernetes. Pozwala łączyć produkcyjną klasyczną aranżację kontenerów standardowego Kubernetes z kontrolą, bezpieczeństwem i wysoką przewidywalną wydajnością Oracle Cloud Infrastructure.

Nie ma specjalnej opłaty za silnik kontenerowy dla Kubernetes. Płacisz tylko za zasoby, których używasz do obliczeń, pamięci i sieci wykorzystywanych przez klastry Kubernetes. Ponadto naliczane są tylko opłaty za węzły „robocze” działające w Twojej dzierżawie, a węzły główne są uruchamiane w zarządzanej dzierżawie Oracle.

• Phoenix
• Ashburn
• Frankfurt
• Londyn
• Toronto
• Tokio
• Seul

Nie. Kiedy tworzysz zarządzany klaster Kubernetes, Oracle automatycznie tworzy i zarządza zestawem wielu węzłów głównych w różnych Domenach dostępności (logicznych centrach danych) w płaszczyźnie sterowania Oracle w Twoim imieniu (i powiązaną infrastrukturę Kubernetes, taką jak węzły etcd) upewnij się, że masz wysoce dostępny zarządzany samolot kontrolny Kubernetes. Możesz także bezproblemowo uaktualnić te węzły główne do nowych wersji Kubernetes przy zerowym przestoju.

Tak. Klastry Kubernetes są tworzone ze standardowymi wcześniejszymi wersjami Kubernetes. Te wersje są również certyfikowane przez Cloud Native Computing Foundation (CNCF) program zgodności.

Nie. Kiedy tworzysz zarządzany klaster Kubernetes, Oracle automatycznie tworzy i zarządza zestawem wielu węzłów głównych w różnych Domenach dostępności (logicznych centrach danych) w płaszczyźnie sterowania Oracle w Twoim imieniu (i powiązaną infrastrukturę Kubernetes, taką jak węzły etcd) upewnij się, że masz wysoce dostępny zarządzany samolot kontrolny Kubernetes. Możesz także bezproblemowo uaktualnić te węzły główne do nowych wersji Kubernetes przy zerowym przestoju. Zaopatrzone węzły robocze są również automatycznie oznaczane ich domeną i regionem dostępności dobrze znane etykiety Kubernetes aby umożliwić klientom wykorzystanie mechanizmów planowania Kubernetes do budowania i wdrażania odpornych aplikacji opartych na kontenerach.

Tak. Zarządzane klastry Kubernetes są włączone w Kubernetes RBAC. Managed Kubernetes jest również zintegrowany z Oracle Identity and Access Management (IAM), umożliwiając użytkownikom kontrolę nad dostępem do ich klastrów.

Tak. Możesz wdrożyć zarządzany klaster Kubernetes w istniejącej sieci VCN, co daje dużą kontrolę nad wykorzystaniem podsieci i list zabezpieczeń.

Tak, masz opcję utworzenia zarządzanego klastra Kubernetes z węzłami roboczymi w prywatnych podsieciach. Te węzły robocze mają tylko prywatne adresy IP i będą wymagały bramy NAT dla połączeń wychodzących z wzorcami klastra i Internetem.

Tak. Możesz wdrożyć zarządzany klaster Kubernetes na czystych węzłach bez systemu metalowego. Możesz także wykorzystać koncepcję „pul węzłów” (zestaw węzłów współużytkujących wspólny rozmiar / obraz węzła), aby utworzyć klaster zarówno maszyn typu bare metal, jak i maszyn wirtualnych i odpowiednio ukierunkować obciążenia Kubernetes.

Tak. Mechanizm kontenera dla Kubernetes pozwala użytkownikom ujawniać usługi Kubernetes typu „LoadBalancer” i tworzyć Oracle równoważenia obciążenia. Użytkownicy mogą również tworzyć trwałe woluminy Kubernetes i roszczenia dotyczące trwałych woluminów wspierane przez Oracle blokowych woluminów.

Tak. Podczas tworzenia klastra można podać publiczną / prywatną parę kluczy SSH, aby w razie potrzeby połączyć się z SSH w węzłach roboczych.

Tak. Węzły robocze uruchamiają standardowe środowisko wykonawcze Docker, dzięki czemu użytkownicy mogą korzystać ze znanych poleceń Docker.

Oracle Cloud Infrastructure Service Broker dla Kubernetes (OSB lub „Service Broker”) to implementacja interfejsu API Open Service Broker, którego można używać do interakcji z usługami Oracle Cloud Infrastructure. Za pomocą Oracle Cloud Infrastructure Service Broker możesz zarządzać cyklem życia usług Oracle Cloud Infrastructure natywnie z poziomu Kubernetes za pośrednictwem interfejsów API Kubernetes, co oznacza:

Podczas wdrażania aplikacji w Kubernetes nie trzeba przechodzić do osobnego systemu, aby świadczyć usługi zależne od aplikacji.

Cykl życia zależnych usług Oracle Cloud Infrastructure można połączyć z aplikacjami, które od nich zależą.

Aplikacje stają się bardziej przenośne, ponieważ zależności można łatwo zakodować w procedurach DevOps.

Aby użyć Oracle Cloud Infrastructure Service Broker, zainstaluj go w klastrze Kubernetes wraz z katalogiem usług Kubernetes. Następnie możesz użyć poleceń kubectl, które zostaną zinterpretowane w Oracle Cloud Infrastructure CLI.

Widzieć https://github.com/oracle/oci-service-broker po więcej informacji.

Od tego momentu możesz używać Oracle Cloud Infrastructure Service Broker do udostępniania i tworzenia powiązań usług z następującymi typami usług Oracle Cloud Infrastructure:

• Autonomous Transaction Processing database
• Autonomous Data Warehouse database
• Wiadro usługi przechowywania obiektów

Możesz użyć Oracle Cloud Infrastructure Service Broker z klastra Kubernetes utworzonego na Oracle Linux (przy użyciu Oracle usług kontenerowych dla Kubernetes) uruchomionych lokalnie, aby utworzyć instancje usługi na Oracle Cloud Infrastructure, ale nie możesz użyć tej usługi na terenie.

Oracle Cloud Infrastructure Service Broker jest zwykle wdrażany jako kapsuła w klastrze Kubernetes. Dzięki temu najłatwiejszym sposobem rozwiązania problemu z zasobnikiem jest pobranie dzienników z zasobnika za pomocą następujących poleceń:

• Użyj kubectl get strąki, aby uzyskać listę działających strąków w klastrze.
• Z tej listy skopiuj identyfikator zasobnika dla Oracle Cloud Infrastructure Service Broker.
• Użyj dzienników kubectl, aby pobrać dzienniki z zasobnika.

Użytkownicy, którzy używają Oracle Cloud Infrastructure Service Broker do tworzenia instancji usług Oracle Cloud Infrastructure, takich jak instancja bazy danych ATP, muszą mieć rolę, która ma uprawnienia do tworzenia tych usług. Na przykład upewnij się, że masz w dzierżawie Oracle Cloud Infrastructure zasadę, która wygląda następująco:

Pozwól grupie OCI-Service-Broker-Group zarządzać autonomiczną bazą danych w przedziale

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