Applications In Kubernetes Require Unique Care And Considerations
Resources are best when decoupled
if an API currently does a few "processes" that could each be unique and decoupled, K8s works best when each "process" gets broken-out into its own container/pod etc - many implementation pattern(s) could be applied here
Resource connection parameters are best when extracted into "environment variables": things like...
K8s DOES offer StatefulSets, which are one way to deal with resources that need to be more "persistent"
An "allow all" approach is default in K8s for resource communication
restricting resource communication from, say, a db to a frontend proxy server (when the db only needs to allow inbound requests from an api) is a choice and requires specifc effort to do so
labels might be the best "go-to" for identifying and "selecting" resources between one another
deployments "select" containers by label
pods can be more "picky" about which node they get deployed onto with nodeSelectors, which select labels on nodes
labels can "group" resources together to meet company + organization needs (a "frontend" label present on several frontend pods, a "blue/green" set of labels for blue/green deployments for a "growth" team, an "analytics" label for an internal-analytics team across several log pods, etc)
labels can be used to interact with items via kubectl
