Showing posts with label API. Show all posts
Showing posts with label API. Show all posts

Apigee

Posted by Manish Panchmatia on Wednesday, August 16, 2023 Labels: , , / Comments: (0)

 1. integrated developer portal


2. convert a set of API into product: R/W access, rate per second, and how to use it. mix and match methods, operatoins from different APIs. code as pricing model. bronze/silver/gold customer. break out APIs in different packages. 


3. Security

out of box policy

- authentication

- authorization

- rate limit

- spikers

- JSON based threat

- XML based threat

- use other Google cloud tool

-- cloud armor for DDoS

   It sops absuive or bot traffic ASAP, before it enters into system. 

New Advance API security feature 

- Identify mis configured API. 

-- security score for API

-- recommended action

-- abuse of API detection

-- API security dashboard for quick investigation and resolution

- Bot detection: API traffic pattern


4. Application Integration : 50+ connectors to 3rd party services,

API hub: API catalogue and API LCM


5. Measure and tune APIs: Analytic


6. engage and innovate with partner to create digital eco system. 


7. full API LCM platform

- builder façade

- caching


Refernece: https://www.youtube.com/watch?v=KfJoQAKoQiM

Kube API and CRDs

Posted by Manish Panchmatia on Monday, January 10, 2022 Labels: , , / Comments: (0)

k api-resources

- Name
- Short name
- API version
- Namespaced (Boolean)
- Kind
- Verbs

k api-versions

* API not managed by controller
SubjectAccessReview It represent operation on object

* Kind has set of versions. All Kind are organized in group.

* We have multiple versions for a Kind

1. served version: List of versions available in API

2. Decodable version: Kube-API server knows how to decode that version. We can create object for specific kind with version x and retrieve object for same kind, with version y. When version change, schema also change. Kube-API server does schema conversion. 

3. storage version = encodable version: as per etcd

4. We can get preferred version with
k get --raw /apis/GROUP
For Example:
k get --raw /apis/networking.k8s.io

kubectl request with preferred version

* (1) Kube-API server (2) kube clients e.g. kubectl (3) client-go maintains mapping of resource types (e.g. pods) and kind (Pod) . Then REST end point is constructed as follows

- /apis/GROUP/VERSION/RESOURCE/NAME to get a cluster-scoped object
- /apis/GROUP/VERSION/namespaces/NAMESPACE/RESOURCETYPE/NAME to access a namespace-scoped object.

Without specifying NAME, we get KindList (e.g. ServiceList)

* Along with CRD, we define:
- group, kind, resource type
- versions: served version, storage version (used at etcd), decodable version, preferred version generally same as storage version. 
- namespace scoped or cluster scoped. This is scope for object, not for API. 
- URL endpoint

* Verbs

- get, list : GET
- watch : GET ....?watch=
- create, update: PUT
- patch: PATCH

* Generated values
- name : If generatedName is set
- creationTimestamp
- deletionTimestamp
- UID
- resourceVersion
- Any field set by mutating webhook
- port, IP for service object

Reference

The evolution of Ingress through the Gateway API

Posted by Manish Panchmatia on Saturday, September 26, 2020 Labels: , , / Comments: (0)

We have three types components. 

1. Transparent Proxies: sidecar, kube-proxy
2. Cloud LB: GCP, Azure, AWS
3. Middle Proxies: nginx, HAProxy, Envoy

Now their functionalities are overlapping 

In K8s, Ingress is simple L7 description 

Roles: 
1. Infrastructure Provider 
2. Cluster Operator / NetOps / SRE 
3. Applicatoin DEveloper 

In case of Ingress, Infrastructure Provider provides IngressClass. No role for SRE. Application Developer defines Ingress and Service

In case of Gateway API, Infrastructure Provider provides GatewayClass. It is associated with type of LB. SRE provides Gateway implementation. Application Developer defines Route and Service

We have K8s objects like

1. GatewayClass
2. Gateway provides: Exposure and access, LB
3. Route: HTTP, TCP, UDP, SNI and TLS: HTTPS, TLS
4. Service about grouping and selection 

API groups
1. Core: Must be supported
2. Extended: Feature specific. May be supported, must be portable
3. Implementation specific: Not K8s API schema. No guarantee for portability

Gateway contains route. Route can be CRD. 
Earlier we had single ingress resource. Now it splits in Gateway and Route. So there may be conflict. E.g. same host, same path in multiple routes. 

Extension Points in Alpha
1. GatewayClass parameters for LB configuration
2. Gateway.Listener have ExtensionRef to customize listener properties
3. Route: Custom filter via ExtenstionRef. Backend is more than Services, like ingress

ExtenstionRef is for CRD. 

Reference:

K8s API

Posted by Manish Panchmatia on Monday, August 17, 2020 Labels: , , / Comments: (0)

The K8s APIs are grouped as follows:
  1. api
  2. apis
  3. healthz
  4. logs
  5. metrics
  6. version


Out of them, first two are related to cluster functionalities. "api" is also called "core api" and "apis" are called "named api". They are defined as "" in RBAC. The named api (apis) are further classified as following resource groups: 
  1. admission
  2. admissionregistration.k8s.io
  3. apiextensions.k8s.io
  4. apiregistration.k8s.io
  5. apps
  6. auditregistration
  7. authentication.k8s.io
  8. authorization.k8s.io
  9. autoscaling
  10. batch
  11. certificates.k8s.io
  12. coordination.k8s.io
  13. core
  14. discovery
  15. events.k8s.io
  16. extensions
  17. flowcontrol
  18. imagepolicy
  19. monitoring.coreos.com
  20. networking.k8s.io
  21. node.k8s.io
  22. policy
  23. rbac.authorization.k8s.io
  24. scheduling.k8s.io
  25. settings
  26. storage.k8s.io
  27. testdata
One can perform following actions (verbs) on these resource groups, if RBAC policy allows. 
  1. list
  2. get
  3. create
  4. delete
  5. update
  6. watch
As per K8s 1.17, the K8s resources are grouped as follows: 


 The below table indicates, composition relationships among all K8s objects, as per K8s 1.17



Reference: 
https://kubernetes.io/docs/reference/
https://kubernetes.io/docs/reference/kubectl/overview/
https://kubernetes.io/docs/concepts/overview/working-with-objects/object-management/
https://github.com/kubernetes/community/blob/master/contributors/devel/sig-api-machinery/strategic-merge-patch.md
https://www.cncf.io/blog/2020/03/17/how-to-setup-role-based-access-to-kubernetes-cluster/
https://github.com/kubernetes/kubernetes/issues/7856

 https://kubernetes.io/docs/concepts/overview/kubernetes-api/
https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md
https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api_changes.md