Containers and Kubernetes

Get Involved. Join the Conversation.

Topic

    Joydeepta Bhattacharjee
    Kubernetes on Oracle OCI OKE : Quick Developer handouts
    Topic posted July 13, 2019 by Joydeepta BhattacharjeeRed Ribbon: 250+ Points, last edited July 25, 2019, tagged Containers, Docker, Kubernetes, Registry, Tip 
    99 Views, 3 Comments
    Title:
    Kubernetes on Oracle OCI OKE : Quick Developer handouts
    Summary:
    This would be constant effort to derive a ideal architecture and reference to derive a K8 MSA architecture with side car facilities like service mesh etc. for developers and architects to relate to Op
    Content:

    In preparation of Oracle Cloud Infra based Micro-services platform with Kubernetes as a reference standpoint , trying to consolidate salient steps to built a resilient MS architecture. We can explore setting up Istio sidecar implementation as well with this for better governance and delivery but this tutorial would be more focused from developer angle hosting a consistent infrastructure to create development environment with 2 worker nodes of considerable size for hosting multiple containers. Below is a basic block diagram for creating a Kubernetes Infrastructure. To understand more on detail of Istio over OKE please refer the attached link

    http://www.ateam-oracle.com/istio-on-oke

    https://blogs.oracle.com/cloudnative/monitoring-and-visualization-prometheus-and-grafana

    The installation can also be done with clear articulated steps as per Helm Charts which helps to bundle and install almost all the required components.

    Now, based on the understanding of the current version of OKE provisioned we could architect a below reference diagram of Kubernetes over OCI stack. The OCI Image Registry would contained the build docker images of the app to be pulled into the Kubernetes PODs during runtime while bringing the containers up and running, On left the control plane has been shown with Master node showing up the api server, etcd database to store runtime information of pods and scheduler which are the internal components and have been incorporated as the Kubernetes release by community. On right hand side we have data plane to host application containers and services managed by Kubectl tool as the Worker nodes. We have provisioned only two worker nodes in OCI OKE with optimum sizing to host a minimal spring boot based micro service app. The default Ingress Load-balancer also shipped as part of Kubernetes. The API server inbuilt as part of Master Node architecture is responsible for routing the requests from outside the Kube cluster to the pods through the scheduler selected by the runtime on basis of present snapshot in etcd store.

    As a part of side car features there could be extra installation and configuration service mesh like Istio or monitoring tools like Prometheus and Grafana etc. These are all open source tools supported by Kubernetes community and provides lots of interesting features which also can be articulated in due time. Kubernetes has become a breakthrough inception for container orchestration with large set of features and capabilities and many vendors like Azure, Amazon, Oracle has started embracing and slowing maturing their stacks in a phenomenal diversification. Container orchestration has become very important in cloud fraternity to adapt to horizontal scaling, fault tolerance, automation and what more, The OCI native monitoring capability along with Kubernetes dashboard to configure metric and alters is also going in an interesting turn around to combine bare metal computation capability of vendor with global community driven Ops stack with many native options. IT is advisable to provision both the master and workers across multiple AD’s to give better availability and redundancy as well within a region for a Compartment assigned to the OCI account of customer. In fact as Oracle document quotes below “To ensure high availability, Container Engine for Kubernetes creates the Kubernetes Control Plane on multiple Oracle-managed master nodes (distributed across different availability domains in a region where supported).”

    Steps to Provisioning VM & configure workers and other basic installations:

    Document link from Oracle is pretty straight forward to create OCI OKE cluster

    https://docs.cloud.oracle.com/iaas/Content/ContEng/Tasks/contengcreatingclusterusingoke.htm

    Steps to Configure the OKE cluster:

    To create a cluster, you must either belong to the tenancy's Administrators group, or belong to a group to which a policy grants the CLUSTER_MANAGE permission.

    Once the cluster gets configured with all default setup we are now ready to create and deploy a service instance in the pod through the Master node of OCI OKE cluster. We can leverage Developer cloud services to build the code, create the docker image of the spring boot code from Job definition in CI-CD pipeline in Developer Cloud. Before that we would also create a deployment or pod definition configuration file in .yml which would finally been loaded approximately in a dockerized solution.

    Now lets go in detail to help creating the pods from the My-Services from a OCI Navigation in left and connect to the developer cloud services provisioned from console. The developer cloud services with current release has been a phenomenal to create a complete native pipeline to build both spring boot rest api and UI services , create images and then deploy in OKE clusters configured with it's cloud native Jobs configured. A typical JOB configured in the cloud native build pipeline has steps which can be configured from console for docker login, maven build , docker build and push image to Registry. I am not aware if Oracle still allows to integrate 3 rd party registry which is needed for interoperability between various cloud vendors.

    Once the image is built and pushed successfully versioned in the Image repository , the next step in the pipeline is to review the yaml in git for deployment and pod creation specific to Kubernetes shipped to specific Kubernetes vendor. The Kubernetes tooling has already been installed in Cloud VM in connection with master would now be utilized to sequentially create the pods with specific docker image runtime and provision in default inbuilt load balencer Ingress as part of Kubernetes setup . A typical docker image to build a spring boot api and create a pod and service to publish through Kubectl are sampled out as below. In developer cloud service under a typical project home all the artifacts and build jobs are organised so the specific user accessing devcs should have desired role for above visibility :

    Docker File in Spring boot Project context root, with a poc to update db store in Oracle Autonomous db cloud would be :

    FROM openjdk:8-jdk-alpine
    VOLUME /tmp
    ADD ./src/main/resources/Wallet_KXX /tmp/Wallet_KXX--- Wallet to securily connect the oracle db autonomous instance from a docker runtime
    COPY target/FirstPOCService-0.0.1-SNAPSHOT.jar app.jar
    ENTRYPOINT ["java","-Djava.security.egd=file:/dev/./urandom","-jar","/app.jar","--debug"]
    

    while the pod yaml to create a service type loadbalencer to register in OOTB Ingress with Kubernetes is as below .

     

    apiVersion: apps/v1beta1
    kind: Deployment
    metadata:
      name: app-dbboot-deployment
    spec:
      replicas: 1
      selector:
        matchLabels:
          app: app
      template:
        metadata:
          labels:
            app: app
        spec:
          containers:
            - name: appdbtest
              image: ".............../firstspringpocdbimage:1.1"
         imagePullPolicy: "Always"
              ports:
                - containerPort: 8099 #Endpoint is at port 80 in the container
          imagePullSecrets:
            - 
              name: CCCC
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: springbootapp-db-service
    spec:
      type: LoadBalancer #Exposes the service as a node port
      ports:
      - port: 80
        protocol: TCP
        targetPort: 8099
      selector:
        app: app
    
    
    

    Now , the typical steps to be executed ultimately to bring into life the pods as and that with the mighty Devcs automation is as below :

    echo "" >> $HOME/.oci/config
    echo "pass_phrase=bXXXX" >> $HOME/.oci/config
    cat $HOME/.oci/config
    mkdir -p $HOME/.kube
    oci ce cluster create-kubeconfig --cluster-id ocid.XXXXX--file $HOME/.kube/config --region eu-F>>>
    export KUBECONFIG=$HOME/.kube/config
    kubectl get pods
    kubectl config view
    kubectl get nodes
    kubectl delete service springbootapp-po-service
    kubectl delete deployment app-po-deployment
    kubectl create -f ./PO/po/springboot_db_deploy.yml
    sleep 60
    kubectl get services  springbootapp-po-service
    kubectl get pods

    This would be added as a Unix shell connected in built step and running below commands with kubectl . These are typical commands common to any K8 managed service by any cloud vendor and runs gracefully oracle as expected.

    ------------------------------

    Once this run successfully the Job logs under the specific build would list down the URL endpoint in the console itself and we dont need to really login to oci cli and bother with Black screen syndrome. I would also like to provide some experience around publishing a nginx container with angular app running on it in same way down the line so let's be on. Now those who are interested looking for further contribution and challenges you are facing to adopt this might K8 by Oracle stack. , meanwhile.

    Further , we have now used a Ingress-Nginx load balencer and using the service name which is created on deployment of the Pod could remove the dependency of communication between pods and services through IP . We would recommend to create pod deployment with service_type = cluster_ip and decouple it from OCI native load balencer. Rather , we would download an Nginx image as a reverse proxy in front in a pod and configure the routing rule to different backend pods from there. Optionally we can define a host in Ingress resource and edit /hosts/resolve.conf or update in Oracle public dns to expose it like test.Client_domain.com. I would like to preserve this blog link for all of us which can help in future

     

     

    Image:

    Comment

     

    • Joydeepta Bhattacharjee

      Let's are request the K8 SMEs in Oracle to comment internally the best practices and tools to help in several enablers to attend service resiliency , discovery , fault tolerence , auto scaling and communication standard between multiple api's and from UI. I am requesting Oracle Experts to contribute as there are several topics like CQRS , gRPC communication , messaging etc. are over discussed but not standardised from Oracle OKE perspective.

    • Joydeepta Bhattacharjee

      I have checked the kube-dns and tried to debug with following :"

      kubectl describe services kube-dns --namespace kube-system , kubectl describe svc my-api  but when i exec(kubectl exec -it second-pod) to a pod and wget the other pod it's not reached? I also connected a busy-box image to debug the kube-dns networking between pods.